`check:platform-checklist` is red on main: `cli.migrate-duplicates-inventory` has revision 3 against a last history entry of revision 2

[os-elon]

Found while running the gate over an unrelated edit to the same file (#10917). Pre-existing on origin/main, not introduced by that branch — reproduced against a pristine checkout of main at 2866d5f97e.

Reproduce

pnpm check:platform-checklist

check-platform-checklist: 1 problem(s)

 ✗ cli.json · cli.migrate-duplicates-inventory: "revision" (3) must equal the last history entry's revision (2) — a semantic edit bumps both

Read straight out of docs/qa/platform-checklist/areas/cli.json at origin/main:

• item cli.migrate-duplicates-inventory carries "revision": 3
• its history array has entries for revisions [1, 2] only

So the item was semantically edited to revision 3 and the matching history entry was never appended. The invariant exists precisely so a revision bump cannot silently re-validate old run results against changed clauses — with no revision-3 entry, nothing records what changed at that revision.

Where it came from

git log on that file names the last two commits that touched it:

2866d5f97e feat(cli): `os migrate duplicates` reports the rows blocking the kernel:ready index tightenings (#11031)
3a7ec2d3bb fix(cli): a raw-SQL seam that cannot answer is absent, not empty (#10677) (#10788)

2866d5f97e (#11031) is the current tip of main, and the item is that PR's subject, so that is the likely origin — worth confirming before fixing.

Why it went unnoticed

check:platform-checklist is not CI-wired (maintainer decision, recorded under "Operating cadence" in docs/qa/platform-checklist/README.md), so nothing runs it on a pull request. It is only ever run by a seat that happens to edit the ledger. That is the more interesting half of this report: the gate cannot regress-detect anything it is never invoked on, and this is what that looks like in practice.

Whether the cadence should change is a separate question and deliberately not proposed here.

Fix

Presumed one of:

1. append the missing revision-3 history entry describing the feat(cli): os migrate duplicates reports the rows blocking the kernel:ready index tightenings #11031 edit (if the item really was edited semantically), or
2. drop revision back to 2 (if the bump was accidental and no clause changed).

Only someone who can say what #11031 changed about the item should pick between them — assigning a revision a description after the fact is exactly the kind of estimate later gates read as fact.

⛔ Filed unassigned, and deliberately not fixed in #10917's PR: unrelated to that card's subject, and a checklist ledger repair should be judged on its own.

---

Generated by Claude Code

[os-elon]

Claim: dispatching this now. ⚠️ This is my regression — PR #11031 is the cause, and I reviewed and enqueued it.

• Session: session_019bmVFqoQPq63zhKrxdYG1r (domain:cli lane execution seat, seat post [PM seat] domain:cli — 🟢 os-zhuang (session_019siH5jDmk5hrayvfyojUqR) · R34 · 在飞 4 卡 / 3 dev · 等维护者 2 #6024)
• Branch: claude/issue-11037-checklist-revision-history-entry
• Worktree: ../objectstack-issue-11037 (dedicated, per Prime Directive Migrate documentation site to Fumadocs with monorepo structure and shared content #11)
• Domain: domain:cli
• File surface: docs/qa/platform-checklist/areas/cli.json, one item, one history entry. Not a governed face.
• Container & model: sonnet — mechanical, and the content is supplied below.
• Clause-②: no — a QA ledger entry; no packages/spec/src/** path, nothing declared.
• Serial constraints cleared: ⚠️ [Decision] Retire the @capabilities hook-body directive, or keep documenting it? Measured: it reaches the extractor from NO ordinary authoring path (ADR-0049 enforce-or-remove) #10917's PR feat(cli)!: retire the @capabilities hook-body directive (#10917) #11043 also edits cli.json (a different item, cli.hook-body-extraction-gates, revision 1→2). Same file, different object — this dispatch must touch only cli.migrate-duplicates-inventory and will need a rebase if feat(cli)!: retire the @capabilities hook-body directive (#10917) #11043 lands first. Named so it is handled rather than discovered as a conflict.

Reproduced independently, on real main

⚠️ My first attempt to check this was wrong and I nearly reported it as green: I ran the gate in a checkout whose cli.json differs from origin/main by 620 deletions, and it exited 0 — a pass over the wrong population. Re-run against a worktree pinned to origin/main @ 2866d5f97e:

check-platform-checklist: 1 problem(s)

 ✗ cli.json · cli.migrate-duplicates-inventory: "revision" (3) must equal the
 last history entry's revision (2) — a semantic edit bumps both
EXIT=1

Independently confirmed from the data itself: the item carries revision: 3 while history holds exactly two entries, the last at revision 2.

Which of the two candidate fixes, and why — this part I can settle

The filing seat correctly declined to choose, on the grounds that "only someone who knows what #11031 changed about the item can pick between them." I reviewed that diff at enqueue time, so I can:

#11031 made a real semantic edit. It changed the item's contract, not its prose — reportVersion 1→2 in the acceptance clause, a new .runtimeIndexPreflight key in the jq walk, a new seeding step for the kernel:ready blocker, and an entirely new acceptance clause carrying the matched control in its verify step.

⇒ revision: 3 is CORRECT. ⛔ Do not revert it to 2 — that would erase a real contract change from the ledger and make the file lie about what a runner must execute. The missing half is the history entry, and that is what this card adds.

Why it reached main at all — worth recording

The gate is not CI-wired (a maintainer decision), so nothing runs it on a PR. #11031's six required checks were all green by name and it merged clean. The defect only surfaced because #10917's dev happened to edit the same ledger and ran the gate locally.

⇒ Two separate facts: this instance is mine to fix, and an un-wired gate that only fires when a seat happens to touch the file will keep admitting this class. The second is not this card's to solve — recording it so the pattern is visible rather than re-discovered.

---

Generated by Claude Code

[os-elon]

<!-- os-dev-report -->

{
 "issue": 11037,
 "status": "done",
 "branch": "claude/issue-11037-checklist-revision-history-entry",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/11047",
 "premise_still_valid": true,
 "summary": "Added the missing revision-3 history entry to cli.migrate-duplicates-inventory in docs/qa/platform-checklist/areas/cli.json, describing the semantic edit PR #11031 made (reportVersion 1->2, runtimeIndexPreflight jq-walk step, kernel:ready seeding step, new kernel:ready pre-flight acceptance clause) and citing #8725/#11031 as provenance, matching the sibling entries' shape/voice. revision stays at 3 (not reverted) per the dispatch decision -- #11031's edit was genuinely semantic.",
 "tests": "node scripts/check-platform-checklist.mjs BEFORE (origin/main @ 2866d5f97e, item's history entry removed): EXIT=1, 'check-platform-checklist: 1 problem(s) / X cli.json - cli.migrate-duplicates-inventory: \"revision\" (3) must equal the last history entry's revision (2) -- a semantic edit bumps both' -- reproduces the reported defect exactly. AFTER (branch HEAD 71445c0ba4): EXIT=0, 'check-platform-checklist: OK -- 15 areas, 205 items (205 active); coverage: 30 kinds mapped, 0 waived; traps: 19 documented, 19 in use; provisioning: 4 area recipes, 6 item references resolved'. Item's revision (3) == last history entry's revision (3). Reverse-verification (fix committed first, both legs via git checkout, no stash): leg 1 (entry removed, origin/main content restored) predicted red -> confirmed, exact original message reproduced verbatim; leg 2 (fix restored via git checkout HEAD) predicted green -> confirmed, same OK verdict as AFTER. node scripts/pm/dispatch-gates.mjs (no path args, off merge-base 2866d5f97 vs HEAD, diff scoped to exactly docs/qa/platform-checklist/areas/cli.json after an unrelated pnpm-install file-mode change on packages/create-objectstack/bin/create-objectstack.js was reverted to keep scope clean) named 2 matched local-gate families: pnpm check:doc-authoring (node scripts/check-doc-authoring.mjs --self-test && ...) -> self-test PASS, run '✓ doc authoring guard: 389 files clean -- no bare metadata literals.' EXIT=0; pnpm --filter @objectstack/lint run check:doc-formula-expressions -> required building @objectstack/formula's dependency closure first (pnpm --filter '@objectstack/lint^...' build, run through the shared os-verify-lock.sh, VERDICT command-exit 0, held 129s waited 351s), then self-test PASS (30 cases) and run PASS: '✓ check:doc-formula-expressions: 22 record-scoped formula example(s) across 416 files / 1447 TS blocks judged clean' + '✓ check:doc-formula-expressions (spec TSDoc, #6763): 9 @example(s) judged clean across 978 packages/spec/src files' EXIT=0. check:nul-bytes also run (standard clause, any edit): self-test PASS (75 assertions), run '✓ check-nul-bytes: OK (scanned 6389 text file(s) ... no raw ASCII control bytes)' EXIT=0; manual grep -naP control-byte scan of the edited file also clean. pnpm lint (full-repo eslint, run through os-verify-lock.sh since it is a heavy command) -> 'os-verify-lock: VERDICT command-exit 0 * held the lock 71s waited 333s', no problems reported. All exit codes captured before any pipe (redirect-then-capture or PIPESTATUS, per AGENTS.md discipline), verdict lines quoted as each gate printed them, not bare $?. All gates/reverse-verification run at the same committed HEAD 71445c0ba4 that was pushed and opened as the draft PR -- no drift between what was measured and what is under review.",
 "open_questions": [
 { "question": "No .changeset/*.md was written (docs/QA-ledger-only change, per this repo's check-empty-changeset.mjs discipline preferring the skip-changeset label over an empty-frontmatter changeset). I called issue_write (labels_add: [\"skip-changeset\"]) on PR #11047 twice, both calls returning an apparent-success payload; get_label confirms the label exists repo-wide. But three separate read-backs (pull_request_read.get) after both calls, including after an initial GitHub API rate-limit window fully cleared, still show only the bot-applied 'size/xs' label -- the add is not landing. gh CLI is unavailable in this environment as a fallback write path. Read-back discipline (AGENTS.md: 'the write is not done until read back') says I cannot claim this step is closed.", "options": ["A: PM (or a retry once whatever is swallowing the labels_add write clears) re-applies skip-changeset on PR #11047 directly", "B: leave it -- check:changeset-gate-self-tests / the changeset CI gate will surface the missing label/changeset on its own and someone fixes it then"], "recommendation": "A, because this card's own instructions were explicit about using the label and I could not complete that step despite two attempts; worth PM's attention rather than silently hoping CI catches it" }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-elon]

os-dev-report

(Corrected marker for the report above — my first post self-escaped the HTML-comment marker into literal <!--...--> text rather than posting the exact <!-- os-dev-report --> form, so it would not match a literal-marker scan. Falling back to the literal-text-prefix convention per protocol. The report JSON itself is unchanged and lives in the previous comment: #11037 (comment) )

{
 "issue": 11037,
 "status": "done",
 "branch": "claude/issue-11037-checklist-revision-history-entry",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/11047",
 "premise_still_valid": true,
 "summary": "Added the missing revision-3 history entry to cli.migrate-duplicates-inventory in docs/qa/platform-checklist/areas/cli.json, describing the semantic edit PR #11031 made (reportVersion 1->2, runtimeIndexPreflight jq-walk step, kernel:ready seeding step, new kernel:ready pre-flight acceptance clause) and citing #8725/#11031 as provenance, matching the sibling entries' shape/voice. revision stays at 3 (not reverted) per the dispatch decision -- #11031's edit was genuinely semantic.",
 "tests": "node scripts/check-platform-checklist.mjs BEFORE (origin/main @ 2866d5f97e, item's history entry removed): EXIT=1, 'check-platform-checklist: 1 problem(s) / X cli.json - cli.migrate-duplicates-inventory: \"revision\" (3) must equal the last history entry's revision (2) -- a semantic edit bumps both' -- reproduces the reported defect exactly. AFTER (branch HEAD 71445c0ba4): EXIT=0, 'check-platform-checklist: OK -- 15 areas, 205 items (205 active); coverage: 30 kinds mapped, 0 waived; traps: 19 documented, 19 in use; provisioning: 4 area recipes, 6 item references resolved'. Item's revision (3) == last history entry's revision (3). Reverse-verification (fix committed first, both legs via git checkout, no stash): leg 1 (entry removed, origin/main content restored) predicted red -> confirmed, exact original message reproduced verbatim; leg 2 (fix restored via git checkout HEAD) predicted green -> confirmed, same OK verdict as AFTER. node scripts/pm/dispatch-gates.mjs (no path args, off merge-base 2866d5f97 vs HEAD, diff scoped to exactly docs/qa/platform-checklist/areas/cli.json after an unrelated pnpm-install file-mode change on packages/create-objectstack/bin/create-objectstack.js was reverted to keep scope clean) named 2 matched local-gate families: pnpm check:doc-authoring (node scripts/check-doc-authoring.mjs --self-test && ...) -> self-test PASS, run '✓ doc authoring guard: 389 files clean -- no bare metadata literals.' EXIT=0; pnpm --filter @objectstack/lint run check:doc-formula-expressions -> required building @objectstack/formula's dependency closure first (pnpm --filter '@objectstack/lint^...' build, run through the shared os-verify-lock.sh, VERDICT command-exit 0, held 129s waited 351s), then self-test PASS (30 cases) and run PASS: '✓ check:doc-formula-expressions: 22 record-scoped formula example(s) across 416 files / 1447 TS blocks judged clean' + '✓ check:doc-formula-expressions (spec TSDoc, #6763): 9 @example(s) judged clean across 978 packages/spec/src files' EXIT=0. check:nul-bytes also run (standard clause, any edit): self-test PASS (75 assertions), run '✓ check-nul-bytes: OK (scanned 6389 text file(s) ... no raw ASCII control bytes)' EXIT=0; manual grep -naP control-byte scan of the edited file also clean. pnpm lint (full-repo eslint, run through os-verify-lock.sh since it is a heavy command) -> 'os-verify-lock: VERDICT command-exit 0 * held the lock 71s waited 333s', no problems reported. All exit codes captured before any pipe (redirect-then-capture or PIPESTATUS, per AGENTS.md discipline), verdict lines quoted as each gate printed them, not bare $?. All gates/reverse-verification run at the same committed HEAD 71445c0ba4 that was pushed and opened as the draft PR -- no drift between what was measured and what is under review.",
 "open_questions": [
 { "question": "No .changeset/*.md was written (docs/QA-ledger-only change, per this repo's check-empty-changeset.mjs discipline preferring the skip-changeset label over an empty-frontmatter changeset). I called issue_write (labels_add: [\"skip-changeset\"]) on PR #11047 twice, both calls returning an apparent-success payload; get_label confirms the label exists repo-wide. But three separate read-backs (pull_request_read.get) after both calls, including after an initial GitHub API rate-limit window fully cleared, still show only the bot-applied 'size/xs' label -- the add is not landing. gh CLI is unavailable in this environment as a fallback write path. Read-back discipline (AGENTS.md: 'the write is not done until read back') says I cannot claim this step is closed.", "options": ["A: PM (or a retry once whatever is swallowing the labels_add write clears) re-applies skip-changeset on PR #11047 directly", "B: leave it -- check:changeset-gate-self-tests / the changeset CI gate will surface the missing label/changeset on its own and someone fixes it then"], "recommendation": "A, because this card's own instructions were explicit about using the label and I could not complete that step despite two attempts; worth PM's attention rather than silently hoping CI catches it" }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-elon]

pm-dispatch-enqueue

Enqueued. PR #11047 marked ready and auto-merge armed (SQUASH), head 71445c0ba4.

⚠️ This is a docs/QA-only diff — I am NOT claiming "all six ran"

One changed file (docs/qa/platform-checklist/areas/cli.json, +2/−1), so the path filter excused most of the farm. Stated plainly rather than dressed up:

required check	conclusion	note
TypeScript Type Check	success	genuinely ran — lanes below
Lint & Repo Gates	success	7m01s, genuinely ran
Test Core	success (roll-up)	⚠️ shards skipped by path filter
Dogfood Regression Gate	success (roll-up)	⚠️ shards skipped by path filter
Build Core	⚠️ skipped	path filter
Temporal Conformance (live PG + MySQL)	⚠️ skipped	path filter

Lanes that really ran: · workspace ✅ 39s · · debt ledger ✅ 4m37s · · source gates ✅ 2m00s · · consumer gates ✅ 2m49s. Also green: Check Documentation Links, Part-of PR must not also close its card, both single-writer gates, Check PR Size. Build Docs and Dogfood Verify CLI skipped by the same filter.

That is the correct shape for a diff touching only docs/qa/** — but it is an excuse, not a pass, and it should read that way.

⚠️ Check Changeset was RED, and why it no longer is

It failed at 13:35:16 — this PR carries no .changeset/*.md (correct: a QA-ledger edit releases nothing) and the skip-changeset label was not on.

⭐ The dev tried twice to apply that label, got apparent success both times, read it back three times, and correctly refused to claim the step was done — quoting AGENTS.md, "the write is not done until read back." That refusal is what made this fixable instead of a silent red.

The cause is a tooling trap worth recording. The issue_write tool exposes only labels — which replaces the whole label set — and has no labels_add. A call passing labels_add is accepted, returns a success payload, and changes nothing. A write that reports success while doing nothing is the same false-absence shape as a grep that returns 0 over a path that does not exist; it just fails on the write side. ⇒ Apply labels as the full intended set, and always read back.

I applied ["size/xs","skip-changeset"] and read it back — both present. The label change re-ran Check Changeset, which now reports skipped (13:43:27), its excused path. The earlier failure is superseded, and nothing else on the PR is red.

Content — verified by me independently, before the report arrived

I ran the gate in the branch's own tree: check-platform-checklist: OK — 15 areas, 205 items (205 active), EXIT=0. The diff is exactly one added history entry (revision: 3, ref: "#11031"), matching the sibling entries' shape and voice, recording the four things #11031 actually changed. revision correctly not reverted — the semantic edit was real.

The dev's reverse-verification matches: removing the entry reproduces the original failure verbatim; restoring it returns the OK verdict. Both directions predicted beforehand.

⭐ It also reverted an unrelated bin/create-objectstack.js file-mode change (100644→100755, caused by pnpm install) to keep the diff clean — exactly the stray old mode/new mode hunk I had flagged as a risk on a tracked file.

⚠️ Conflict watch: PR #11043 (#10917) also edits cli.json, on cli.hook-body-extraction-gates, and is armed. Whichever lands second may need a rebase — ⛔ resolve by keeping both history entries, never by overwriting the other item's.

⚠️ Merge to be confirmed BY CONTENT:

git show origin/main:docs/qa/platform-checklist/areas/cli.json | grep -c '"ref": "#11031"'
cd <a worktree pinned to origin/main> && node scripts/check-platform-checklist.mjs # must exit 0

---

Generated by Claude Code