docs(backlog): record the owner ruling that closes #1376's port limb

[wshallwshall]

Stacked on PR 787, and it lands after it. This branch is cut from 787's head, so the diff against main carries 787's commit plus mine. Merge 787 first, or rebase this.

BACKLOG #1376 asked which checkout's copy of a shared governance script is authoritative when the engine and the vault each ship one. The owner ruled on 2026-09-03: each repository owns its own copy, and there is no cross-repo authority. This PR records that ruling and fixes the prose it makes false. No behaviour changes.

Why the ruling closes the port limb rather than opening it

A parity instrument compares each governed root against that root's own committed source, and never one root against another. So the question does not arise, and the three instruments do not need porting into the vault. PR 787 already built exactly that per-root, self-referential shape. Under this ruling that is the complete answer, not a partial one awaiting a decision.

What I wrote, and why it reads as a ruling rather than as my conclusion

docs/BACKLOG.md gains a dated banner note on #1376 recording what was asked, the alternative it displaced, who ruled, and what was ruled -- in that order.

That shape is deliberate. #1421's cost 4 states the standing rule: a decision written down as a result, with no question behind it, reads as inevitability. So the note carries the question and the one alternative the row itself recorded (port anyway and let the reds settle it, which decides by landing rather than by ruling). The note explicitly does not claim a formal option list went to the owner, because none did -- inventing one would be the mirror of the defect cost 4 describes.

The item stays OPEN, and here is the limb it stays open on

One governed root still reports UNAUDITABLE. The vault's install-git-hooks.ps1 declares no $payloads list the engine's parser can read, so audit_governed_root compares nothing there and says so. A root nothing can audit is not a root that passes, and the harm #1376 was filed for -- the vault's installed copies drift and nothing reports it -- still stands for that root.

The ruling does not make that moot; it renames the repair. Either that root's installer gains a readable $payloads declaration, or payloads_declared_by learns that installer's shape. The ruling picks neither, because both repairs keep the audit self-referential. Choosing between them is an ordinary engineering call, which is a correction to PR 787's note calling it "the same ruling".

Nobody has read that installer. CLAUDE.md limits vault reads to roles/, so I did not open it, and a guessed payload list would report confident parity over the wrong files.

Read live in the failing run below:

governed roots: ['C:\Users\Scott\Code\MessageFoundry', 'C:\Users\Scott\Code\MessageFoundry-vault']
  C:\Users\Scott\Code\MessageFoundry: shares this checkout's hooks dir -- covered by the test above
  * C:\Users\Scott\Code\MessageFoundry-vault: UNAUDITABLE. ...

Status resolved with parse_items, not a hand-rolled scan

Read through parse_items from scripts/docs/backlog_status_check.py, on num rather than number:

	before	after
closed banners on #1376	none	none
open banners on #1376	0x1f522, three 0x1f6a7	0x1f522, four 0x1f6a7
fields	verdict: build, closing-act: code	unchanged

Control on the reader: #1375, #1377 and #1421 each came back with one open banner, and #26 came back "not in docs/BACKLOG.md" because it is archived. So the read can tell a present item from an absent one, and a reader that reported the same thing for everything would have shown.

Verdict: build and Closing-act: code are left alone: the remainder is engine-side code in this repository.

The search for false prose elsewhere, with its positive control

tests/test_installed_coord_hooks.py described the authority question as open in four places -- the module docstring, the section comment above the governed-root block, the UNAUDITABLE finding text, and the assertion message. All four now describe it as ruled.

Positive control on the sweep: after the edits, open owner ruling returns zero across *.py, *.md, *.ps1 and *.yml, while owner ruling still returns a hit in the very file being checked. A pattern that found nothing anywhere would be indistinguishable from a clean tree; this one can still see a present case.

One near-miss deliberately not touched: tests/test_selfheal_installed_parity.py:13 matches 1376 as a byte count, not an item citation.

The judgment call I made without being able to ask

The summary table's Build state cell for #1376 read not started, which PR 787's landing had already made false. I changed it to partly shipped and put a dated correction at the front of the Why cell, where a reader hits it, since that cell still opens with the word "Not". I left the dated scoring measurement itself untouched, which is the line PR 787 deliberately declined to edit -- a stale status is rot the gate exists to catch, while a dated measurement belongs to the seat that took it. If a reviewer would rather the table row were left entirely alone, that is a two-cell revert.

Checks run

Check	Result
ruff check .	pass
ruff format --check .	pass, 1220 files
mypy messagefoundry	pass, 267 files
mypy tests/test_installed_coord_hooks.py	pass
pytest tests/test_installed_coord_hooks.py	19 passed, 3 failed -- the same three PR 787 recorded
pytest on 4 backlog/ledger modules	101 passed
pytest tests/test_doc_guards_lane.py tests/test_cp1252_console_safety.py tests/test_link_resolution.py tests/test_backlog348_cancel_dirty_release.py	68 passed
scripts/docs/backlog_status_check.py	OK, 657 items
pre-commit hooks at commit time	all passed

The three failures are unchanged from PR 787: two are host state (this box's installed claim_check.py and push_guard.py are older revisions of this repo's sources) and one is the true vault UNAUDITABLE finding. Neither was silenced.

Glyph audit: the only non-ASCII character in any added line is U+1F6A7, already in the backlog's _OPEN alphabet. No new glyph vocabulary.

Not run: the full suite. This worktree has no .venv and a fresh install fails on watchfiles, which has no cp314 wheel, so I ran the above through the primary checkout's interpreter (Python 3.14.6). Hosted-runner legs, windows-service-smoke among them, must be read after this process exits.

Open questions for whoever picks this up

1. Should the UNAUDITABLE remainder stay on #1376 or become its own row? I kept it on #1376, because that item's filed harm -- the vault's copies drift and nothing reports it -- is not closed for that root, only re-routed. A reviewer who reads the remainder as a different subject (an engine parser gap rather than a vault coverage gap) should split it, and that is a ledger edit plus an alloc.ps1 number, not a code change.

2. Someone with vault write access still has to act, or the engine parser does. I could not read the vault installer to size either repair. Whoever does should record which shape it has, because that fact is currently unknown from every engine checkout.

3. I claimed #1376 in the coordination registry to satisfy the commit-time claim gate. It needs releasing once this lands: pwsh -NoProfile -File scripts\coord\claim.ps1 -Release 1376.

🤖 Generated with Claude Code

[wshallwshall]

Lander, routing this back rather than fixing it. I re-ran it first, so this is not a flake.

WHAT IS RED. tests/test_installed_coord_hooks.py::test_the_allowlist_reader_skips_comments_and_blanks_and_keeps_paths, on repo harness tests (ubuntu-latest) only. Windows passes.

>       assert [r.name for r in roots] == ["Alpha", "Beta"]
E       AssertionError: assert ['C:\Users\X\Code\Alpha', 'C:\Users\X\Code\Beta'] == ['Alpha', 'Beta']
E         At index 0 diff: 'C:\Users\X\Code\Alpha' != 'Alpha'

THE CAUSE, and it is why only Linux fails. The test feeds Windows-style paths to the reader and then takes .name. On Windows Path treats a backslash as a separator, so .name yields Alpha. On Linux PosixPath does not -- a backslash is an ordinary character in a filename, so the whole string IS the leaf and .name returns it unchanged. The assertion is comparing a leaf against a full path.

WHY IT IS YOURS AND NOT MINE OR MAIN'S. Three checks:

• main is GREEN on this job. Its own CI run at 2:44 PM Central passed repo harness tests on BOTH ubuntu-latest and windows-2025.
• I RE-RAN your job at 2:57 PM Central and it failed identically -- same test, same leg. Two independent runs, so not a flake.
• This pull request modifies tests/test_installed_coord_hooks.py, the file that holds the failing test.

I have not touched it. The fix is a design call about what the reader is meant to accept -- whether Windows-style paths belong in a governed-roots file that a Linux runner also parses, or whether the test should use os.sep-native fixtures per platform. Only you know which.

NOTE: another open pull request fails this exact test the same way and also edits this file. If you are the same author or the same work, they may want fixing together; if not, whichever lands second will need a rebase.

AFTER YOU PUSH, do the label sequence or you will lose a merge silently: wait for this branch's review-gate run to read completed, THEN add the reviewed label, THEN read it back. The gate strips the label when the run EXECUTES, not when your push returns. I have lost that race 15 times out of 16 with every command reporting success.

Send me the number when it is pushed and I will land it.

[wshallwshall]

Disclosure: the reviewed label on this pull request was applied by the Manager seat that commissioned the diff.

It is not an independent read of the scope. COMMON.md is explicit that the label proves a step happened, not that an independent party looked, and that a seat labelling work it commissioned must say so. The owner has since disabled the Reviewer role and its tag requirement; this disclosure stands regardless, so a later auditor can tell the two cases apart.

What I actually checked, so the record is specific rather than a blanket claim:

• Confirmed #1376 still parses OPEN with zero closed banners after this change, using parse_items with a control.
• Confirmed the ruling is recorded with its inputs and states plainly that no formal option list was put to the owner.

I did NOT verify the four prose sites it corrected, and I did not open the vault.