fix(handoff): route a task's reporting channel with the task

[stoneevenson-biz]

The defect

A brief pins its home into the reporting command (bin/fm-brief.sh):

FM_HOME='<home>' FM_STATE_OVERRIDE='<home>/state' bash '<home>/bin/fm-status.sh' '<id>' "<state>: ..."

That pin is load-bearing — it is what stops a secondmate's own FM_HOME from diverting an escalation — but it does not follow the item when the item moves. bin/fm-backlog-handoff.sh moved the backlog line and left the pin behind, so the destination home owned the task and the origin owned the channel.

Observed on fmx-boot-e3, routed to the fmx-plat secondmate and still pointing at the main home's state/<id>.status. Two consequences: reports land where the owning supervisor's watcher never looks, and both homes carry records for one task.

What changed

The item's data/<key>/ dir now travels with its backlog line, and every fm-status.sh reporting command inside its brief is retargeted at the destination home — root as FM_HOME, state dir as FM_STATE_OVERRIDE, the destination's own bin/fm-status.sh when it has one (otherwise the existing script path is kept, since the pins are what decide where the line lands).

Three decisions worth calling out:

• It is a normalisation, not a diff. Every reporting command is rewritten to the destination whatever it said before, and this runs for every requested key — including one already in the destination backlog. So re-running the handoff is the repair path for an item routed before this existed: bin/fm-backlog-handoff.sh <secondmate-id> <item-key> converges it in place. No one-off sweep is needed, and items already routed are not left broken.
• It is narrow. Only the fm-status.sh invocation and quoted <key>.status paths are touched. A blanket substitution would also rewrite the task description, which names the origin home for the crewmate's own reasons — corrupting the work to fix the reporting would be the worse defect.
• It fails loudly rather than half-routing. After rewriting, the brief is re-read: any surviving origin pin aborts the handoff and rolls back. A brief that moved while its channel did not is exactly the defect being fixed.

Safety properties held

Every existing refusal still refuses, now with files inside the transaction. The destination copy lands before anything is removed from the origin, so a failure anywhere rolls back to the item being whole in the origin.

• ## In flight entries refused — and their briefs do not travel;
• an unmatched key aborts atomically — neither backlog touched and the brief still whole in the origin;
• a destination lacking or mismatching .fm-secondmate-home is refused and not written into;
• idempotent — a re-run duplicates no line and leaves an already-retargeted brief byte-identical;
• a destination that already holds its own data/<key>/ keeps it (retargeted, unclobbered); the origin's stale copy is named in the output rather than removed, since deleting a dir this script did not place there is not a mechanical move.

Gates

Both frozen, both registered while genuinely red (first_observed_red stamped by a verify run with the implementation absent).

• gate-t4-routed-brief-reports-to-destination — proves the channel moved, not that a string changed. It scaffolds a real ship brief with the real bin/fm-brief.sh, hands the item off, then extracts the destination brief's own reporting command and runs it, asserting the line landed in the destination home's state dir and not the origin's. Three arms: an item routed with its brief, an item routed before this existed (the repair path), and a destination with no fm-status.sh of its own.
• gate-t4-handoff-safety-preserved — each pre-existing refusal re-proven with a brief dir present in every arm.

gates/verify.sh reports exactly the two declared reds — gate-l2-loop-audit-level and m1-hook-registered — and no others. The nine gates the sweep demoted from frozen to green were re-frozen; gates/ledger.json diffed against origin/main shows no gate demoted and none vacuous.

Spec: docs/specs/2026-09-01-routed-brief-home.md

🤖 Generated with Claude Code

https://claude.ai/code/session_01HigQ4ZWEsJGLFkQjo5NEV3