fix(pm): split the governed-merges attribution column three ways

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code

[os-litant]

Fixes#12645

The attribution column was picked on entry.attribution alone, so it covered
three facts with two words. The entry that fell through the gap is the loudest
line the sweep prints: a mainline commit whose subject names no PR. main()
skips it deliberately — if (entry.pr == null) continue; — because there is no
pull request to query, so zero channels were tried, and the column said
every one of them had failed. It also referred the reader to "the attribution
note below", which summariseAttributionFailures never produces for such an
entry: that function groups only entries carrying attributionError, and this
one carries none.

Reproduction — the card's constructed sweep, before and after

A governed PR-less mainline entry, zero API lookups, rendered through
renderReport (no network, no checkout). The 0 API lookup(s) line is printed
from the same report, four lines above the entry.

Before (de4733663, current origin/main at branch point):

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by UNAVAILABLE — every channel failed; see the attribution note below

After:

 scanned 3 mainline commit(s); 0 API lookup(s).
• objectstack-ai/objectstack ⚠️ NO PR NUMBER IN SUBJECT — direct push to main? investigate — docs(adr): kernel object ownership
commit b2d8707f6 @ 2026-08-14T05:40:28+00:00; merged_by NOT LOOKED UP — no PR number in the subject, so there is no pull request to query (not a channel failure)

The change

A new pure exported helper, attributionCell(entry), following this file's
established shape (describeWindow, windowEdgeReason, nextRoundRefLine —
one pure fragment per report region, so --self-test asserts on the words):

1. resolved — a channel answered; the cell names which one. Unchanged.
2. UNAVAILABLE, every channel failed — attributionError is present, so
   channels really were tried. This is now the only branch that points at
   the attribution note, because it is the only one the note is written for.
3. NOT LOOKED UP — no reading was attempted, with the reason read off the
   entry rather than assumed. An absent PR number is the case main()
   produces; an entry that has a PR number yet reaches this branch gets an
   honest residual instead of being told it has no PR number. Asserting an
   untried channel and asserting an absent PR number are the same defect in
   different words, and fixing one by introducing the other would not be a fix.

Report-only, as ruled. No judgment moves: attributionFailed — and with it
the INCOMPLETE exit — is still set by a real channel failure alone, so a PR-less
entry still does not make the sweep incomplete on attribution grounds. The
--json path emits raw entries and is untouched. The direct-push warning is
not weakened; the header block that states a PR-less commit is more
anomalous than any PR merge now also records why its column reads NOT LOOKED UP.

Assertions added (13; --self-test 193 → 206, all green)

Placed beside the two existing fixtures, since the defect was a two-way split
covering three facts and the set is what pins it:

• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note
• and-the-report-prints-none-for-it — summariseAttributionFailures really
  returns nothing for the entry, so the dangling pointer is pinned from both ends
• the-note-pointer-belongs-to-the-every-channel-failed-case-alone
• the-third-case-does-not-soften-the-direct-push-warning
• and-carries-no-resolved-column-caveat
• cell-case-1-resolved-names-its-channel
• cell-case-2-every-channel-failed-needs-an-attributionError
• cell-case-3-no-pr-number-is-nothing-to-query
• cell-residual-never-invents-a-missing-pr-number
• and-the-residual-is-not-a-channel-failure-either
• a-resolved-reading-outranks-a-stale-error

Verification

Everything below ran at 8c5717fb5, the final commit on this branch, under
the shared verify lock.

node scripts/pm/check-governed-merges.mjs --self-test — its own printed
verdict line:

✓ check-governed-merges --self-test: 206 assertions (…the three-way attribution
column (resolved · every-channel-failed · NOT LOOKED UP, and the note pointer
that belongs to the middle one alone)…)
live: the real generator declared 9 output(s) and certified this tree

Reverse verification (expected direction: RED). The fix was committed first,
so the restore leg has a real reference point. The mutation reverted the call
site to the pre-fix two-way ternary; it was proved on disk before anything
was read — deleted-text count 0, injected-text count 1, and the on-disk blob
a7e619a8… differing from the HEAD blob 0b534cd4…. The mutated tree failed
with exactly the three rendering pins that route through the call site:

✗ check-governed-merges --self-test — 3 failure(s)
• a-pr-less-entry-is-NOT-LOOKED-UP-not-a-failed-lookup
• and-it-says-WHY-nothing-was-queried
• a-not-looked-up-entry-points-at-no-attribution-note

The ten attributionCell pins stayed green under that mutation, correctly: the
mutation removed the call, not the helper, so those pins were not exercised by
it. Restore was proved by state rather than by exit code — on-disk blob back to
0b534cd4… and git diff HEAD empty — and the restored tree re-ran green at
206. The script carried a trap … EXIT INT TERM with absolute paths throughout.
No build or dist/ resolution is involved: this module is executed directly by
node from source.

Derived gate union — node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (paths taken by the script from the merge base, not
hand-supplied), giving 11 path-matched families plus the 2 convention-triggered
by a gate-script edit. Run with importer siblings (three modules import from
this file) and the universal control-byte gate; 17 of 17 green:

check:agent-test-spelling · check:bash32-floor · check:cli-command-ids
check:cross-package-test-inputs · check:entry-guard · check:parse-guard
check:pm-governed-merges · check:pnpm-filter-targets · check-ci-filter-parity
check-cross-package-test-inputs · check-skills-token-ratchet
bare-root-worklist --self-test · check:pm-dispatch-gates · check:nul-bytes
check:pm-governed-prose · check-governed-queue-guard --self-test
ci-failure --self-test

check:pm-dispatch-gates printed ✓ dispatch-gates self-test: 719 cases pass.
and check:nul-bytes printed check-nul-bytes: OK (scanned 7018 text file(s) … no raw ASCII control bytes); a separate control-byte scan over the edited file
found no hits.

No changeset. This publishes nothing — internal PM tooling, and a pure bug
fix, which AGENTS.md exempts. It is also this file's own convention: none of the
last five commits touching it carried one.

---

Generated by Claude Code