Measured
Read on claude/issue-16398-reconciliation-outside-blocks at 65c55f936 (objectstack-ai/objectstack) — that is, with #16398's correction to the human reconciliation line already in place.
#16398 corrected the enumeration on the human default lane. The same claim is spelled twice more, on the other two output lanes, and both are still short.
Lane 1 — --ran, in runReconciliationLines
⛔ This answers ONE link: what this card DERIVES against what you RAN. It is not a complete
account of what CI runs on the PR — the always-runs tail, the unreachable listing and the
pending-changeset families are each outside the derived total, each printed under its own
heading by a run without --ran.
Three of the five blocks a plain run prints. The artifact rosters and the declared WIDE population are absent, exactly as they were on the human line.
Lane 2 — --commands / --json, in machineReadableOutput (the stderr accounting)
Repro, from a worktree on this repo:
node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack 2> commands.err
grep -c 'WIDE' commands.err # 0
grep -c 'Artifact rosters' commands.err # 1
The stderr accounting prints the artifact-roster block, but the declared WIDE population is never mentioned at all — not as a block, not as a count, and not in the closing disclaimer, which names exactly one block:
⛔ Not a complete account of what CI runs on this PR: the always-runs tail (workflows with no
path filter) is NOT here. Run without --commands/--json for it.
machineReadableOutput already receives widePopulationRows and forwards it to derivationJson, so the --json document carries the rows. The --commands reader gets nothing.
Why this is the same defect, not a cosmetic sibling
#16398 measured the cost on the human lane: PR #16380 round 1 spent a CI round trip on check:wildcard-fallthrough, a family printed in the Declared WIDE population block that the reconciliation line did not point at.
--commands is the lane this file's own header tells consumers to use instead of harvesting the prose — so a whole block of families being absent from it is the same failure on the channel that was supposed to be the safe one.
Suggested remedy (not prescriptive)
#16398's change built the list once, as outsideBlockNames in familyReconciliationLines, from the block counts carried on recon — the lengths of the very arrays that render the two blocks, so the enumeration cannot name a set the output does not contain. Both lanes above can read that one expression rather than growing a third and a fourth prose copy of the list.
That reuse is why this is filed as blocked on it rather than folded into it: each lane needs those counts threaded through a different structure (runReconciliation for lane 1, machineReadableOutput for lane 2), which is a different verification surface from the one #16398's claim declared.
Blocked-by: #16398
Not measured here
Measured
Read on
claude/issue-16398-reconciliation-outside-blocksat65c55f936(objectstack-ai/objectstack) — that is, with #16398's correction to the human reconciliation line already in place.#16398 corrected the enumeration on the human default lane. The same claim is spelled twice more, on the other two output lanes, and both are still short.
Lane 1 —
--ran, inrunReconciliationLinesThree of the five blocks a plain run prints. The artifact rosters and the declared WIDE population are absent, exactly as they were on the human line.
Lane 2 —
--commands/--json, inmachineReadableOutput(the stderr accounting)Repro, from a worktree on this repo:
The stderr accounting prints the artifact-roster block, but the declared WIDE population is never mentioned at all — not as a block, not as a count, and not in the closing disclaimer, which names exactly one block:
machineReadableOutputalready receiveswidePopulationRowsand forwards it toderivationJson, so the--jsondocument carries the rows. The--commandsreader gets nothing.Why this is the same defect, not a cosmetic sibling
#16398 measured the cost on the human lane: PR #16380 round 1 spent a CI round trip on
check:wildcard-fallthrough, a family printed in theDeclared WIDE populationblock that the reconciliation line did not point at.--commandsis the lane this file's own header tells consumers to use instead of harvesting the prose — so a whole block of families being absent from it is the same failure on the channel that was supposed to be the safe one.Suggested remedy (not prescriptive)
#16398's change built the list once, as
outsideBlockNamesinfamilyReconciliationLines, from the block counts carried onrecon— the lengths of the very arrays that render the two blocks, so the enumeration cannot name a set the output does not contain. Both lanes above can read that one expression rather than growing a third and a fourth prose copy of the list.That reuse is why this is filed as blocked on it rather than folded into it: each lane needs those counts threaded through a different structure (
runReconciliationfor lane 1,machineReadableOutputfor lane 2), which is a different verification surface from the one #16398's claim declared.Blocked-by: #16398
Not measured here
--jsonconsumers are affected.widePopulationRowsdoes reachderivationJson, so the rows are in the document; it is the stderr disclaimer beside it that is short.