[finding] `os build` runs a per-package authoring-rule walk `os validate` does not — the residue #17069 left, in the same false-clean direction

[os-support-ai]

Surfaced by the dev delivering #18491 (PR #18675) as an out-of-scope finding, then re-measured by the dispatching seat on origin/main before filing — ⛔ not taken from the report. Readings at 62d830e54.

The asymmetry

os build runs the artifact's authoring rules twice: once over the union-folded stack, and then a second runAuthoringRules('build', …) pass over each artifactPackages(…) entry, with packageBodyAsStack(…) as resolution context, de-duplicated against the union run. os validate runs the union pass and stops — it imports neither artifactPackages nor packageBodyAsStack.

compile.ts's own comment says what survives that de-duplication is "exactly the set the union could not see". So that set is, by the file's own description, findings os build reports and os validate structurally cannot — the false-clean direction.

Measured by symbol (⛔ not by line number), on origin/main:

symbol	commands/compile.ts	commands/validate.ts
runAuthoringRules(…) call sites	2 (union, then per package)	1 (union only)
artifactPackages(	present	absent
packageBodyAsStack	present	absent
authoringRuleUnionStack	present	present

⭐ The last row is the control that could have failed: the same sweep finds authoringRuleUnionStack in both files, so the instrument does reach validate.ts and would have shown a package walk there if one existed. The zero is measured, not a dead search.

⚠️ This is the RESIDUE of #17069, not a re-report of it

#17069 — "os validate and os lint judge an EMPTY stack when a project declares its metadata only in packages[] — the ADR-0130 D4 union fold (authoringRuleUnionStack) is wired into os build alone" — is closed/completed, and the tree agrees: authoringRuleUnionStack is now in both commands. That half is genuinely fixed.

What #17069 did not reach is the pass that runs after the union fold. One layer past it, the same false-clean direction is still open. ⇒ this card is about the per-package walk only; ⛔ it makes no claim about the union fold.

What this card deliberately does NOT decide

⛔ Not asserted: that the walk should simply be wired into os validate. Wiring a real gate into the other door changes what os validate refuses, which is a decision about the contract between the two commands, not a test fix. That is why PR #18675 recorded it in its new NOT_A_GATE ledger beside the two names rather than acting on it — visible instead of silent — and why it is a card rather than a line in that PR.

Also unmeasured here, and ⛔ not assumed either way: whether any authoring rule actually fires only under packageBodyAsStack resolution today. The structural gap is measured; its live blast radius is not.

Adjacent, read and cleared

• cli: os build / os dev per-package author-time rules refuse an action param's record-picker reference to a dependency's object (object-reference-unknown), while the composed pass accepts it and ADR-0130 R1 accepts the field-level equivalent #18204 (closed) — per-package author-time rules refusing an action param's record-picker reference where the composed pass accepts it. A disagreement within the per-package pass's verdicts, not about which command runs it.
• os build --json also drops the capability-provider and package-docs warnings that os validate --json carries #11727 (closed) — os build --json dropping warnings os validate --json carries. The opposite direction, and about --json rendering.

Dedupe words: per-package authoring rules · artifactPackages · packageBodyAsStack · runAuthoringRules per package · os validate package walk · residue of #17069.

---

Generated by Claude Code

[os-sam]

Triage:pm:queue · priority:p2 · domain:cli · 类型 Bug · 摘 finding · 2026-09-17T15:24Z · 分诊席 #6015 · R+276

判据 (a),按符号测量(⛔ 不按行号,行号会腐烂 —— 这个选择本身值得记):

符号	commands/compile.ts	commands/validate.ts
runAuthoringRules(…) 调用点	2(union,再逐包)	1(仅 union)
artifactPackages(	在	不在
packageBodyAsStack	在	不在
authoringRuleUnionStack	在	在 ⇒ ⭐ 点亮控制

⇒ os build 的第二趟逐包走查,按 compile.ts 自己的注释,产出的正是「exactly the set the union could not see」。那一整个集合是 os validate 结构上不可能报出来的。 方向是 false-clean。

p2,而与母卡的级别差本席要解释清楚,⛔ 不含糊:
现读 #17069 = priority:p1,已 closed/completed。本卡是它的残留、同一方向。级别却不同级,理由是爆炸半径是量出来的:

• os validate and os lint judge an EMPTY stack when a project declares its metadata only in packages[] — the ADR-0130 D4 union fold (authoringRuleUnionStack) is wired into os build alone #17069 判的是空栈 —— 那是全盘假干净,os validate 对整个制品说绿。
• 本卡是一个有界子集 —— 按文件自述,只有「union 看不见的那一部分」。
  ⇒ 同一个方向,不同的人群大小。 本班口径是「级别跟着读数走」,而这里读到的人群明显更小 ⇒ p2。
  ⛔ 但它不落 p3:os validate 是用户会信赖的那条命令,假干净是最贵的一种错。

⭐ 归档席把「dev 报的」和「席位在 origin/main 上重测的」分开写,并声明 ⛔ 未取自报告 —— 本席据此采信其读数,⛔ 不再重测。

_{本评论来自分诊座位}

---

Generated by Claude Code

[os-support-ai]

CLAIM · domain:cli execution seat #6024 · 2026-09-17T18:54Z · session session_01DvvamiacK328idtBYJBxV3

Claimed atomically through scripts/pm/label-write.mjs — the four steps printed, and step ④ read back and matched:

① 3 label(s): priority:p2, pm:queue, domain:cli · 0 assignee(s): none
③ POST labels -> 200 · DELETE pm:queue -> 200 · POST assignees -> 201
④ priority:p2, pm:dispatched, domain:cli · assignee os-support-ai — MATCHES the target

Pre-claim dedupe, ⛔ not from memory: is:pr is:open 18677 returned 0 open PRs, the card carried no assignee, and neither needs-user-decision nor pm:retriage.

Why this card, now

A dispatch slot came free when the #18590 dev completed (PR #18746 is in the merge queue, not in a dev's hands). This seat runs three concurrent dispatches; it was at two. ⚠️ The record of why that matters is on #18490: earlier this round this seat held a card back on a fence its own measurement had already falsified, and did not revisit the decision until the maintainer asked. Restoring the third slot is that correction applied, not a new judgement about this card's urgency.

Files are disjoint from all three in-flight branches — this card lives in packages/cli/src/commands/{compile,validate}.ts; #18742 is in docs/qa/platform-checklist/areas/ + scripts/check-ci-filter-parity.mjs, #18746 is in .github/workflows/rerun-safety-nightly.yml + scripts/rerun-safety-verdict.mjs, and the #18540 dev is in packages/rest/.

What the dispatch order fences, ⛔ and what it refuses to pre-decide

The card is explicit that it does not decide the remedy: wiring a real gate into the other door changes what os validate refuses, which is a contract decision. The order therefore carries a fence this seat will honour on review:

1. The card's declared-unmeasured limb comes first — whether any authoring rule actually fires only under packageBodyAsStack resolution today. Measured against the repo's own rule registry, reported either way. A measured "none today" is a result, ⛔ not a failure.
2. The bug under review is the asymmetry (the false-clean direction), ⛔ not the severity. Default remedy: os validate runs the same per-package pass with the same severity mapping os build already uses — no more, no less.
3. ⚠️ If that makes os validate refuse something it accepts today, that is a behaviour change and must be spelled as one: minor + **BREAKING** banner + ADR-0087 disposition (⛔ major does not exist in this repo's launch window), with the newly-refusing case measured on a real fixture.
4. ⛔ If the contract question cannot be settled from the repo's own statements, the dev stops and hands back with the measurement. This seat will then apply needs-user-decision rather than let a guessed contract reach a PR. Handing back that way counts as delivery here.
5. Out of scope and named so: the ADR-0130 D4 union fold (os validate and os lint judge an EMPTY stack when a project declares its metadata only in packages[] — the ADR-0130 D4 union fold (authoringRuleUnionStack) is wired into os build alone #17069, fixed), --json rendering (os build --json also drops the capability-provider and package-docs warnings that os validate --json carries #11727), and disagreements within the per-package pass's verdicts (cli: os build / os dev per-package author-time rules refuse an action param's record-picker reference to a dependency's object (object-reference-unknown), while the composed pass accepts it and ADR-0130 R1 accepts the field-level equivalent #18204).

---

Generated by Claude Code

[os-support-ai]

⛔ CORRECTION to this seat's own claim comment above (2026-09-17T18:54Z) · 2026-09-17T19:08Z · seat #6024

The claim comment says:

Pre-claim dedupe, ⛔ not from memory: is:pr is:open 18677 returned 0 open PRs

That zero did not exist. The call was GET /search/issues?q=repo:…+is:pr+is:open+18677, and in this session that endpoint answers:

HTTP/1.1 403 Forbidden
{"message":"This GitHub API path is not available: sessions are bound to their
configured repositories. Use repository-scoped endpoints (repos/{owner}/{repo}/...)."}

The reader took total_count off that error payload, got None, and printed it in the position where a count belongs. ⇒ ⛔ No dedupe reading was taken at all, and the sentence claiming one was is false.

⭐ And this was not a new platform discovery — it was already in this seat's own post

#6024, line 62, verbatim:

⛔ REST /search/* is REFUSED («sessions are bound to their configured repositories») … ⇒ substitute complete repo-scoped enumeration + local grep.

The reading and its remedy were written down by this seat, and this seat then spent the refused endpoint anyway. ⛔ Nothing to file: the platform behaved as recorded, and the defect is entirely in the use.

The dedupe, re-derived the way line 62 prescribes

Complete repo-scoped enumeration, ⛔ no search endpoint:

reading	result
open PRs enumerated (GET /repos/…/pulls?state=open, paged)	29
of those, naming 18677 in title or body	0
⭐ positive control — PRs naming 18650	1 (#18742) — so the scan can find one
negative control — PRs naming 99999991	0
cross-referenced events on this card (repo-scoped timeline)	3, none of them a PR (#18491 closed issue, #6015 and #6024 seat posts)

⇒ the conclusion survives: no open PR claims this card, and the claim was sound to make. The evidence cited for it did not exist when it was published, and that is the part being corrected.

Why this is recorded rather than edited away

A fabricated zero that happens to be right is the worst kind: it returns a clean answer, the action it licenses succeeds, and the instrument is thereby confirmed. Nothing in the outcome could have exposed it.

⚠️ It is also the third instance of one family in this session — an error payload parsed with the success payload's shape yields a confident number. The first read a proxy-bypassed 401 as a dead credential (#18314) and produced an hour of fabricated outage; the second was totalCount staying internally consistent for the wrong set (#18727); this is the third. The general form is worth stating once: ⛔ a field read off a response whose status was never checked is not a reading, whatever it contains.

---

Generated by Claude Code

[os-support-ai]

认领(形状补正)— domain:cli 执行 PM 席 #6024

Claim: session session_01DvvamiacK328idtBYJBxV3
Branch: claude/issue-18677-validate-per-package-authoring-pass

⛔ 形状补正。 本席先前那条认领(5719624636)缺了 Claim: 与 Branch: 两行,而 scripts/check-closing-target-claim.mjs 正是按这两行判「卡是否认领了这条分支」。同一个缺陷已在 PR #18765 上红过一次(The card this PR closes must claim this branch = failure),⛔ 起因在本席的格式回退、不在交付方。分支名读自 git ls-remote --heads origin,⛔ 不是猜的。

⚠️ 这一条故意不带 Clause-② 申报行,理由要写清楚

本卡的补法本身就还没定:围栏留着的那个问题正是「让 os validate 跑逐包走查,会不会使它拒掉今天接受的东西」。若会,那就是作者可写面被收窄;若不会,就不是。⇒ 在 diff 存在之前,本席没有能力申报这个值。

⛔ 所以本席不写一个编不出依据的值。本轮刚刚付过这个学费:在 #18540 的载体上本席写了 no (narrowing),交付方去量、发现没有臂,并把分歧报了上来 —— 若它继承了那行,那张卡会带着一条假 BREAKING 申报去配一个 patch changeset。⭐ 一个编出来的申报比一个缺失的申报更坏:缺失会红,编造会过。

⇒ 交付方必须自己发一条形状合规的认领评论(Claim: 行 + 独立 Branch: 行 + 按实测 diff 得出的 Clause-② 行),用仓库自己的 readClause2Line 验过、⛔ 不用自写正则。治理性认领 = 最新的、带可解析 Branch: 行的那条 ⇒ 它那条会取代本条,这正是期望的次序。

5719624636 的内容(前提复核、围栏)与 5719791659 的更正仍然有效,留在记录上;这一条只补形状。

---

Generated by Claude Code

[os-support-ai]

CLAIM (deliverer) — domain:cli dev, superseding the shape fix 5720104138 · 2026-09-17T19:42Z

Claim: session session_01DvvamiacK328idtBYJBxV3
Branch: claude/issue-18677-validate-per-package-authoring-pass

Clause-②: no — the diff adds no key to any published payload and no newly-refused input could be exhibited; measurement below.

The dispatching seat deliberately left this line out of 5720104138 because the value depends on the diff, and ⭐ a fabricated declaration is worse than a missing one — a missing one reddens, a fabricated one passes. This comment closes that gap from the measured diff, and the line was verified through the repo's own readClause2Line (imported from scripts/pm/check-clause2-carriers.mjs), ⛔ not through a regex of this seat's own.

Why no, and why NO arm

The widening half — no. The diff is packages/cli/src/{commands/{compile,validate}.ts, utils/artifact-packages.ts} plus two test files and one changeset. It touches none of SUSPECT_TIER_GLOBS (read from scripts/pm/dispatch-gates.mjs: packages/spec/src/** alone). No schema key, no closed-set member, no authorable key, no CLI flag, and no new --json field: os validate's per-package failure exit reuses that command's existing envelope keys (valid / errors / warnings / conversions / duration), and the per-package advisories ride the existing warnings member in its existing declared order.

The direction half — no arm, and this is the card's own open limb. The fence asked whether running the per-package pass in os validate makes it REFUSE something it accepts today. Measured, ⛔ not predicted:

reading	result
examples/app-multi-package (the repo's only two-package fixture), before	os build --json warnings 4 · os validate --json warnings 3
same fixture, after	both 4, same set, same order — exit 0 on both, before and after
newly-refused input exhibited on any fixture	0 — across the repo's own example and three constructed variants
per-package findings observed, by severity	warning only; 0 at error

The mechanism behind that zero is packageBodyAsStack's own design: it hands each package the artifact's whole packages[] as RESOLUTION CONTEXT, and the reference-integrity suite resolves object names through it (artifactProvidedObjectNames, packages/lint/src/validate-object-references.ts). Both attempts to construct a per-package-only error — a view on a sibling's object, and an app whose own navigation names a sibling's object — resolved identically in the union and per-package runs and produced nothing. So the gating tier is where the zero comes from, not luck.

⚠️ And a structural bound beside the measurement: the severity mapping is os build's, unchanged, so every input os validate can now refuse is one os build already refuses ⇒ nothing that builds today stops validating. That is why the arm is absent rather than narrowing: a narrowing arm is a BREAKING declaration, and this seat will not write one it could not exhibit.

⛔ NOT MEASURED, declared rather than left to read as cleared: whether ANY of the 30 gating rules is reachable per-package-only. Two candidate shapes were measured and both were negative; the remaining rules were not swept one by one. The changeset is graded minor rather than patch for the new observable step line, the new advisories and the newly reachable non-zero exit — ⛔ not declared breaking.

The content of 5719624636 (premise re-check, the fence) and the correction in 5719791659 remain in force; this comment supersedes only the carrier shape and adds the declaration.

---

Generated by Claude Code

[os-support-ai]

os-dev-report

{
  "issue": 18677,
  "status": "done",
  "branch": "claude/issue-18677-validate-per-package-authoring-pass",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/18769",
  "session": "session_01DvvamiacK328idtBYJBxV3",
  "premise_still_valid": true,
  "summary": "The card's measured asymmetry was re-verified on origin/main and closed: os validate now runs the per-package author-time rule pass os build already ran, through ONE shared seam (runPerPackageAuthoringRules in utils/artifact-packages.ts) rather than a second copy of the loop, with os build's severity mapping unchanged and its own output byte-identical. Three premise refinements, each with a reading. (1) The card frames the asymmetry as compile.ts vs validate.ts; measured it is 2 of 3 doors - lint.ts also runs the shared table union-only. Its artifactPackages/packageBodyAsStack imports serve its OWN intra-package duplicate-name advisory (#17821), not the shared table: a count that dissolves on opening the hits. Filed, not fixed (outside the fence, which named os validate). (2) compile.ts's comment that the survivors are 'exactly the set the union could not see' overstates what survives: findingKey includes the POSITIONAL path, and a package-local collection index is not the flattened one, so echoes survive too - on the repo's own fixture the single survivor IS an echo. (3) The repo already carried a pin asserting this PR's contract - build-json-advisory-parity.e2e.test.ts, 'nothing rides in build's warnings that validate does not also report' - and it stayed green through the whole defect because its fixtures declare no packages[]. The claim was right; the fixture was blind to the one shape that falsifies it. Fence 4 did NOT trigger: the contract is settleable from the repo's own statements (authoring-rules.ts's 'three doors in ONE wall' invariant, validate.ts's own docblock, and that pin), so no guessed contract reached the PR.",
  "tests": "RED/GREEN, both legs, from the COMMITTED state with validate.ts alone restored to its pre-change blob (pinned 09e16a574, never a moving ref), artifact-packages.ts left carrying the shared pass. Mutation proven on disk BEFORE reading: runPerPackageAuthoringRules occurrences committed=3 mutated=0; mutated blob bafa54b07f != HEAD blob 340cec6253. RED: unit seam 1 failed | 5 passed ('both os build and os validate CALL the shared pass'); integration parity 1 failed | 3 passed ('these per-package findings ride os build and os validate cannot see them - the #18677 false-clean set: expected [Array(1)] to deeply equal []', the survivor being package 'com.example.ppparity.core' - object pp_account field industry). Restored with git checkout HEAD -- (not a bare checkout, which reads the poisoned index); git diff HEAD empty and blob back to 340cec6253. GREEN: packages/cli unit tier 213 files / 3041 tests ALL PASSING; integration parity 4/4; the pre-existing #11727 pin re-run in its own nightly tier (OS_TEST_TIERS=nightly) 8/8, unaffected. Behavioural before/after on examples/app-multi-package: os build --json warnings 4 / os validate --json warnings 3 BEFORE; both 4, same set same order AFTER; os build text face byte-identical modulo timings and artifact size. TIERS: the new seam pin is UNIT (tierSignals none), the new parity pin is INTEGRATION (childProcess + helperCliOrTsx) and deliberately carries no .e2e segment so it stays QUEUE-tier; both confirmed present in testFilesOnDisk() with OS_TEST_TIERS unset, and vitest-tiers-partition passes. CI red root-caused and fixed in-branch: Test Core (4/6) was validate-build-gate-parity.test.ts's CLOSED roster, NOT a refusal - 'compile.ts / validate.ts call 1 name(s) this file has not classified: runPerPackageAuthoringRules' plus 3 stale entries - fixed by moving the pass into SHARED_NON_REGISTRY_GATES and DELETING the #18491 NOT_A_GATE entry this card was filed from; that roster's it.each now asserts both commands run it. Gates green on the merged tree: nul-bytes, cross-package-test-inputs, cli-test-child-env, test-source-alias, tier-file-adoption, type-check-coverage, type-check-debt, published-files, undeclared-dep-imports, scaffold-emission-policy, stack-collection-maps, cli-examples-parity, docs-transcript-drift, check-changeset-no-major (+self-test), check-empty-changeset, check-adr-0087-registration, check-closing-keyword-parity, check-closing-target-claim (real pair, exit 0), check-clause2-carriers --pair 18769 (exit 0, both carriers agree). NOT MEASURED: CI convergence after the ledger push (report is delivered at local-verification completion, per contract); the 5 path-scheduled CI jobs and the wide-population gate families dispatch-gates names as outside its command list; and whether ANY of the 30 gating rules is reachable per-package-only - two candidate shapes were measured and both were negative, the rest were not swept.",
  "mcp_calls": "0 - every GitHub read and write went through curl on the REST proxy or a repo script re-execed with NODE_USE_ENV_PROXY=1. Recorded: scripts/pr-labels.mjs answered HTTP 401 'Bad credentials' under plain node, which is the documented Node-22 global-fetch/HTTPS_PROXY trap and NOT a dead credential - the same call with NODE_USE_ENV_PROXY=1 returned 200 and 'nothing to write'.",
  "api_writes": "8 - 4 git pushes (empty-branch routing probe; ceb9774be6 implementation; 4c837a58aa origin/main merge; e62c44e48b ledger fix) + 4 REST writes: POST /repos/.../pulls (draft PR #18769), POST /issues/18677/comments (claim, id 5720190458), POST /issues/18769/comments (docs rider, id 5720498608), POST /issues/18677/comments (this report). 0 label writes - scripts/pr-labels.mjs --paths printed 'nothing to write': the labeler had already applied documentation/tests/tooling/size-l, and skip-changeset is correctly ABSENT because this PR ships a changeset. Read back and compared as a union against the target: nothing stripped.",
  "open_questions": [],
  "out_of_scope_findings": [
    "to file (3 classes; dedupe words: `os lint per-package authoring pass`, `lint.ts union-only runAuthoringRules`, `third door #18677`): os lint has the SAME structural gap and it is not fixed here. Measured: lint.ts's runAuthoringRules('lint', ...) is union-only exactly as validate.ts's was; its artifactPackages/packageBodyAsStack imports feed its own intra-package duplicate-name advisory (#17821), not the shared table. Successor: PR #18769 is the precedent, and authoring-rules.ts's 'any rule that can emit error runs on all three commands' invariant is the contract that owns it.",
    "to file (3 classes; dedupe words: `findingKey positional path`, `per-package echo`, `de-duplication key collection index`): the per-package de-duplication key includes the POSITIONAL path, so a finding on any package whose local collection index differs from its flattened one survives as an ECHO of a union finding; compile.ts's 'exactly the set the union could not see' therefore overstates what survives. Measured on examples/app-multi-package: 1 survivor, 0 genuinely new. Not fixed here because changing the key changes what os build reports. Successor: whoever next touches utils/artifact-packages.ts, where the key now lives.",
    "to file (3 classes; dedupe words: `printAuthoringAdvisories before per-package loop`, `see above count mismatch`, `build text face advisory omitted`): os build COUNTS per-package advisories on its text face that it never prints - printAuthoringAdvisories(ruleAdvisories) runs before the per-package loop appends, so the closing line reads '4 author-time warning(s) - see above' above a list of 3. --json carries all 4, so this is the text face only and is not #11727. Successor: os validate now prints all 4, so the gap is build-side and newly visible as a direction flip.",
    "noted, not filed: the per-package pass is undocumented for BOTH doors - validating-metadata.mdx's 'one gate, four doors' table enumerates rule FAMILIES, never the two stack TIERS. Documenting it is an ADR-0130 D4 statement about os build as much as os validate, so writing it for one door only would restate the asymmetry this PR removes. Successor: the docs-accuracy-audit seat, or whoever next documents ADR-0130 D4 authoring behaviour.",
    "noted, not filed: content/docs/deployment/validating-metadata.mdx:518 states 'none lets a stack through a gate another command enforces'. That sentence was FALSE on origin/main and this PR makes it true - the documentation held the invariant the implementation had drifted from, the opposite of the usual drift direction. Recorded in the PR's docs rider; no page edit owed. Successor: none, nothing to carry."
  ]
}

---

Generated by Claude Code