docs(backlog): file the shared-scratchpad commit-message hazard (BACKLOG #1440)

[wshallwshall]

Files one backlog item and narrows one existing CLAUDE.md bullet. No engine code, no test file, no workflow change.

What went wrong

A session wrote a commit message to <scratchpad>/msg1.txt, then ran git commit -F <scratchpad>/msg1.txt. Between those two steps another agent overwrote that file with its own message, for a different backlog item. The commit would have carried another item's subject and body. The substitution is invisible in git commit -F output.

The ledger claim gate refused the commit, because the substituted subject cited a number this worktree did not hold. That gate exists for an unrelated reason, and it is the only reader in the chain that compares the message's content against something the session independently knows about itself.

The original framing was wrong, and the row corrects it

The finding was filed as "concurrent sessions in the same project resolve to one directory". They do not. The session-UUID segment partitions top-level sessions correctly. What it does not partition is a session from its own subagents and background tasks, all of which are handed the same path and told it is "session-specific, isolated".

Three measurements, in the row:

• Direct. A marker was written into this session's scratchpad, then a subagent was spawned and asked to quote the scratchpad path from its own system prompt. It returned this session's exact path, listed the directory, found the marker, and wrote beside it. Had the directories differed, the parent's file could not have appeared in its listing.
• The opposite control. If the UUID segment did nothing, every project slug would hold one child. The busiest holds 209.
• Structural. The slug is a function of the working directory, so two seats in different worktrees cannot collide by construction.

A peer manager seat corroborated this independently at n=5 by listing its own scratchpad after four hours of ordinary work: 22 files, one of them its own, the rest deposited by five agents it had spawned. That is the reproduction most readers should use, because it needs ls rather than a deliberately spawned subagent.

The isolation is asymmetric, which is why the mistake is easy

A subagent gets its own git worktree, branch and .venv. Every cheap signal it can consult says isolated. The one directory that is actually shared is the one it is told is private.

Remedy

Write any file whose content is later fed to a command into your own worktree, under a name that cannot collide, and delete it after. The CLAUDE.md bullet already said "inside the project"; it now says which directory, names the scratchpad as the wrong place, and gives the reason.

The per-worktree git directory looks like the ideal home and is not: it sits under the primary checkout's path, so worktree_gate.ps1 refuses a Write there. That was found by trying it, after a first draft of both the row and the CLAUDE.md line recommended it.

The scratchpad mechanism itself is untouched. It is harness behaviour, not repository behaviour.

Checks run

Run here and passing: backlog_status_check (429 live items, each declaring exactly one status), forbidden-content leak scan, dangling_citation_check, backlog_citation_check, claude_section_check, ledger_check, plus the full pre-commit hook set on every commit. Targeted pytest: 143 passed across test_backlog_status_check, test_backlog_citation_check, test_ledger_check, test_link_resolution, test_cp1252_console_safety.

Not run here, and needing a reader: every hosted-runner leg. This worktree has no .venv, so the tests above ran on a sibling interpreter and the extras-gated modules (fhir, dicom, x12, xml, webauthn) were never collected. That is fine for a documentation change and is stated rather than implied.

verdict_divergence_check exits 1 on this branch. It also exits 1 on main: the three divergent items are #340, #1003 and #1266, all present on main and untouched here, and this item carries no prose re-score. The script is neither a pre-commit hook nor referenced by any workflow.

Conflict resolution

main took ten commits touching docs/BACKLOG.md while this branch was held, and both sides append at the tail. Resolved by taking main's file whole and re-appending the #1440 block after #1439. No existing item was edited; the diff against main is CLAUDE.md and the new item only.

Notes for the reviewer

• The two colliding paths are deliberately not published in the row. They carry a host account name and worktree slugs; the forbidden-content gate blocked the first commit on exactly those lines, and its own message says a real host string must be removed rather than allowlisted. The row publishes the schematic form and says why.
• One measured claim in the row is second-hand and marked as such: the reported write-then-clobber sequence. The residue on disk was read directly and confirms it.
• BACKLOG #1440 was allocated with scripts/coord/alloc.ps1 and is claimed by this worktree.

🤖 Generated with Claude Code

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 849.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 849 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.
The label is withdrawn automatically once this pull request leaves the state.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.