# Supervised handoff procedure — fp-driver-v9.sh **Ruled by doyle, 2026-09-12.** The driver emits a handoff REQUEST FILE and waits; emphasys is notification-driven and does not watch the filesystem, so a file-only handoff is structurally invisible to its only recipient and the wait times out with emphasys idle. The fix is **NOT messaging infrastructure inside the driver** — it is a human-supervised delivery step, performed by the driver's operator (todlando), documented here beside the driver and not inside it. **The driver is unchanged. v9 stays at `a9510e1ec86a71266b7f421b90a6a02c5c0f7586f96803c6843133b5b2b0bb12`.** This file adds no code and is not consumed by the driver. ## What the driver does on its own - Writes `$R/handoff/--request.txt`, where `` is `setup` or `teardown` and `` is zero-padded (`001`, `002`). - The request file is **authoritative**: it carries the exact command (`run_exactly:`), the receipt path (`receipt_file:`), both capture paths (`redirect_stdout_to:` / `redirect_stderr_to:`), the nonce, and the receipt's required contents. - Records `HANDOFF_REQUESTED seq= nonce= req=` in `findings.txt`. - Then polls for the receipt every 5s: **900s** in the trial flow, **300s** inside cleanup. A receipt is accepted only if it contains EXACTLY ONE whole line `nonce: `; anything else is rejected by name. On timeout it records `HANDOFF_TIMEOUT` and returns failure. ## What the operator does — the supervised step 1. **Watch for the request.** Tail `findings.txt` for `HANDOFF_REQUESTED`, or watch `$R/handoff/` for a new `*-request.txt`. The 900s/300s clock is already running when that line appears, so this is the one step that must not be left unattended. 2. **Send emphasys the ABSOLUTE PATH and the NONCE. Nothing else.** Do **not** inline the command text: the request file already holds the authoritative command and capture paths, and a second copy in a message is a second source of truth that can disagree with the first. Say which file and which nonce; emphasys reads the rest from the file. 3. **Require an acknowledgment before relying on delivery.** `SENT` is not `SEEN`: emphasys's perch registration was AUTH_REFUSED at SessionStart, they are reachable only through a separately-raised Monitor listener, and tag-borne bodies ride an inject leg that can swallow silently. **No ACK means DELIVERY AND VISIBILITY ARE UNCONFIRMED — it does NOT mean undelivered** (doyle, 2026-09-12). The message may have arrived and the work may already be under way. Re-send on the CLI channel, and if there is still no ACK, treat emphasys as unreachable and stop rather than let the clock run out. **A re-send is a re-DELIVERY, never a re-AUTHORIZATION.** The same path and nonce sent twice authorizes ONE execution. emphasys must recognise a duplicate request — same nonce — and respond by returning the receipt that already exists, or by reporting uncertain completion. emphasys must NOT rerun the command on a re-send. This is a requirement ON EMPHASYS and they have been told it directly; the operator must not assume a re-send is harmless without it. **How emphasys says they implement it — REPORTED MECHANISM, not independently verified** (doyle's framing, 2026-09-12; I have not inspected their ledger or exercised these branches). emphasys raised the hole themselves: if their context clears between the request and a re-send they would not REMEMBER having run it and would rerun with confidence, so the check cannot live in their head. They keep a durable ledger at `C:\Users\decid\.claude\liam-handoff-receipts.jsonl` — deliberately outside a session scratchpad, since those are what a capacity sweep reaps — resolving three states: - receipt for that nonce EXISTS → re-delivery; return the existing receipt, do not run. - no receipt and no pre-execution ledger line → never ran; execute. - ledger line present but no receipt → crashed between execution and receipt; report UNCERTAIN COMPLETION and do NOT rerun. The third state is what makes the uncertain-completion outcome reachable at all. Treat all three as emphasys's account of their own behaviour — which is what the operator relies on when reading their answer — not as a guarantee this procedure has proven. 4. **An ACK is a CURRENT availability check, not a guarantee.** emphasys's reachability dies with their Claude Code session and a clear, compact or harness restart ends it with no signal on this side. An ACK says "alive now"; it promises nothing about five minutes from now. 5. **Let the driver consume the receipt.** Do not write, touch, move or pre-create the receipt file, and do not run the command. The driver matches the nonce itself; the operator's job ends at delivery. ## When to re-confirm emphasys — doyle's ruling, and the reason it is not once - Once **before the run starts**. - Again **after the build completes** and **immediately before the firewall phase**. A single check before a potentially long cold release build proves nothing about the phase that needs emphasys: the build can outlive their session. The check belongs next to the thing it gates. ## Scope must be pre-granted, in doyle's words doyle grants **both** the setup and the teardown command explicitly before field admission. This is not ceremony: measured from emphasys's two real A7 actions, a handoff with scope in hand reaches a receipt in **30–60s** (91s end-to-end including their own verification and reporting), while one needing a scope round-trip took **150s**. The 300s cleanup bound is survivable in the first case and is exactly what the round-trip eats in the second. ## A missing receipt is UNCERTAIN COMPLETION — never permission to retry If the wait times out: - The elevated command **may have run**, partially or fully. Absence of a receipt is absence of a REPORT, not evidence of absence of an EFFECT. - **Do not re-issue the command, and do not relaunch the driver to "try again".** A blind retry of an elevated firewall mutation on an unknown state is how a field run creates the mess it was built to avoid. - The state markers in `$ST` are deliberately left set, and `cleanup-failures.txt` records the failed step. Those are the recovery instruction: read them, establish the actual host state by census, and take the result to doyle. - After a cleanup-phase timeout, assume **bootstrap-owned rules MAY REMAIN** and say so in those words. ## Stopping is not cancelling (doyle, 2026-09-12) After a missing ACK — or any decision to stop — **stop further TRIALS, but keep supervising the requests already outstanding and the cleanup.** Stopping the driver does not cancel an action emphasys may already have received: the request file exists, emphasys may have read it, and the elevated command may be running or finished. Walking away from a stopped driver leaves exactly the state nobody has measured. So: stop issuing new work, keep watching for the receipt and for emphasys's word, and keep the cleanup obligation alive until the host state is established by census. ## What this procedure deliberately does NOT do - No `spt send`, watcher, poller or notification is added to the driver. Delivery is a supervised operator act, not driver behaviour. - No command text is copied into a message. - No receipt is ever authored by anyone but emphasys. - Nothing here grants the run. Field admission is doyle's, and at the time of writing it is HELD.