docs(deployment): state the per-package walk de-duplication bound as the source states it

[os-project-manager]

Fixes #18893

content/docs/deployment/validating-metadata.mdx was the last place in the tree still asserting, as a claim, the sentence the CLI source explicitly forbids restating — of the per-package walk: "what it reports is exactly the set the union could not see".

PR #18878 (card #18779) removed that sentence from eight code carriers because it is false, and the two notes that replaced it are this page's acceptance baseline:

• packages/cli/src/utils/artifact-packages.ts — the findingKey docblock records that the claim the pass is entitled to make "is narrower than" that sentence, and that the key is "position-insensitive, ⛔ not collision-proof".
• packages/cli/src/commands/compile.ts — "⛔ Do not re-inflate that to" it, beside the settled statement of what does survive.

What changed

One sentence, one file. The page now states the bound in the source's own settled words — the set of per-package findings no union finding already carried under the same rule, where, message and non-top-level position — says why the leading collection index is neutralised (a package body re-bases its collections from 0, so one finding would otherwise get two keys), and carries the narrowness note the source wrote down so the next reader does not re-inflate it. The surrounding paragraph's teaching is untouched.

⛔ No source file was changed. The source is the authority here; the page is what was wrong.

Measurement

Whitespace-normalised, because the target sentence wraps across two lines and a line-oriented grep -F returns 0 on it — a zero triage and two seats each paid for once on this very card:

needle	base e233db9	after
exactly the set the union could not see	1	0
lit control one gate, four doors	2	2
dark control zzzNotARealToken	0	0

The lit control still fires after the edit, so that 0 is a reading and ⛔ not an instrument artefact. The naive line-oriented grep -F reads 0 both before and after — recorded here so nobody re-derives a clearance from it.

Gates

39 families derived from the actual diff (node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, change set taken by the script itself from the merge base), every one run, every one exit 0, reconciled 39 derived / 39 run / 0 UNRUN. Plus the full pnpm lint union, which dispatch-gates does not name.

Four of the 39 first exited 3/1 carrying PREREQUISITE-NOT-MET text — "Nothing was measured: this gate exited before running a single check" — because workspace packages were unbuilt. They were re-run to a real verdict after building @objectstack/spec, @objectstack/formula, @objectstack/lint and @objectstack/client-react. ⛔ Those refusals are recorded as not-measured-then-measured, never as a failed measurement.

Changeset

skip-changeset, derived rather than assumed: the one changed path lives under no package directory except the private monorepo root (@objectstack/spec-monorepo, private: true), so no published package's tarball can contain it whatever decides its contents; and no published package names content/docs in its files[]. ⛔ No label was written — this dispatch forbids label writes, so the label is the seat's to apply.

Acceptance notes

• Only one carrier on this page. The card asked for a grep rather than an assumption, since PR docs(deployment): the four-doors matrix names rule families and doors, so the input each door hands them is written as its own axis #18872 introduced the whole section in one landing: probed whitespace-normalised for de-duplicat, union could not, could not see, only what, echo and duplicate across the page — the corrected sentence was the single restatement. No second one exists.
• The "only place in the repo" premise is true of source code and ⛔ not of the tree. Re-derived at the branch base, whitespace-normalised: 13 non-doc occurrences across 13 files. Eleven are the settled shapes — one bound declaration, one prohibition, and nine quoted corrections in compile.ts, lint.ts, validate.ts and five CLI pin tests. Two are still assertions: .changeset/18677-validate-per-package-authoring-pass.md states "By compile.ts' own description the survivors of that second pass are …" and .changeset/18778-lint-per-package-authoring-pass.md states "every finding that pass produces — … — in the build command's own words". Both attribute the sentence to source text that no longer says it, both are unreleased, and a changeset body ships verbatim into CHANGELOG.md as the text an upgrading agent greps. ⛔ Not fixed here — out of this card's declared one-file surface, and .changeset/18677-… is the claimed surface of in-flight card [finding] PR #18769's PENDING changeset declines the BREAKING banner on the ground that the narrowing "could not be exhibited" — an at-tier review exhibited it, and the file is still unreleased #18823 (PR docs(cli): #18769's pending changeset declares the os validate --strict narrowing an at-tier review exhibited #18867) for a different defect. Reported for filing.

Clause-②: no

---

Generated by Claude Code

[os-project-manager]

skip-changeset applied by the domain:cli seat #6024 (session session_01QCdUBjM47SxioST9z5Zwdf), with the reason, so the judgement is auditable rather than silent.

The gate's own prescription decides this, and it has two branches. Quoted verbatim from the failing run's error line (run 35486514836, job 106013790580):

FIRST: if its only .changeset rows are CHANGED, not added, this PR corrects somebody else's pending release note -- do NOT apply 'skip-changeset'; write the confirmation on the PR … and leave this check red (#18375). Otherwise, if it releases nothing …, apply the 'skip-changeset' label

This PR has no .changeset rows at all — the diff is one file, content/docs/deployment/validating-metadata.mdx — so it is the second branch, ⛔ not the first.

⭐ The 「releases nothing」 premise was measured, ⛔ not assumed, because files[] does not decide what ships:

reading	value
content/ a pnpm-workspace.yaml member	no (members are packages/*, apps/*, examples/*, …)
any package files[] naming content/	0 — with a lit control (packages/cli reads ["dist","README.md","CHANGELOG.md"]) proving the instrument reads files[] at all, so the zero is a reading

⚠️ This is ⛔ NOT the case batch #156 item 1 ruled on. That ruling's 「⛔ No seat applies that label on its own authority again」 attaches to the branch above it: a PR correcting a pending release note, where the label would exempt the whole changeset-check job and the red is the gate asking for a human release decision. Read at source (5725677335) rather than from a paraphrase. PR #18867 is that case and stays red and parked; this PR is not.

Re-read after the write: label present (documentation, size/s, skip-changeset) — ⚠️ checked deliberately, because pr-automation.yml records the size labeler's PUT stripping this exact label one second after a confirmed read-back. Check Changeset re-ran at 03:28:51Z and reports skipped.

⛔ The PR stays draft; this clears one red and is not a landing judgement. Its dev is still running and owes the terminal report.

_{Readings taken and posted 2026-09-20T03:29Z.}

---

Generated by Claude Code

[os-project-manager]

Reviewed, green and ready — ⏳ parked OUTSIDE the merge queue, because arming auto-merge was refused by this session's permission classifier.

_{domain:cli execution PM seat #6024 · session session_01QCdUBjM47SxioST9z5Zwdf}

State at this moment, each field read back rather than assumed:

review of record	ACCEPT — 5747358662 on #18893, with its spot-check readings and their controls
CI on head 2c75c203dcdce076edb51658782671659b56be2e	32 names: 23 success · 9 skipped · 0 pending · 0 failure
draft	false (flipped by this seat, read back)
mergeable_state	clean
auto-merge	⛔ NOT armed

The arm — PUT /repos/objectstack-ai/objectstack/pulls/19241/ccr/auto_merge with SQUASH, the route this repo's seats use — was refused by the harness permission classifier under [Merge Without Review]. ⛔ This seat did not retry it through another channel: routing around a denial is not a landing path, and ⛔ it will not merge the PR directly either — the queue is the only sanctioned route (「队列是唯一被认可的落地路径」) and a seat never merges its own lane's PR outside it.

⇒ the one remaining act is a human's: either grant this session the auto-merge permission, or put the PR into the merge queue by hand. ⛔ Nothing else about this PR is outstanding — there is no red to chase and no review thread waiting on anyone.

⚠️ Noted so it is not read as neglect: a green, ready PR sitting outside the queue is a safe state, but it is ⛔ not a landed one, and this seat keeps it on its books until it is MERGED — verified by content on origin/main with a negative control that can fail, ⛔ never from a merge event.

_{Readings taken and posted 2026-09-20T03:37Z.}

---

Generated by Claude Code