# SUPERSEDES v10 — RECIPIENT AND ATTRIBUTION RESTORED TO liam (operator correction, relayed by doyle B7ZLOLBZ, 2026-09-12) **Read this header before the procedure.** v9 (`HANDOFF-PROCEDURE-v9.md`, sha256 `987569883091f710...`) and v10 (`HANDOFF-PROCEDURE-v10.md`, sha256 `99705af7b58e1b4b...`) are PRESERVED UNMODIFIED beside this file. They are the historical record of a live identity conflict, they are NOT renamed, NOT edited and NOT withdrawn, and they DISAGREE with this file about who the recipient is. That disagreement is deliberate and is itself the record. This file replaces v10 as the OPERATIVE procedure. ## What changed, and only this Every operative occurrence of the recipient name `emphasys` became `liam`, reversing v10's substitution and returning the operative name to v9's. The authority is different from v10's: an OPERATOR CORRECTION, relayed to me by doyle (B7ZLOLBZ), which supersedes doyle's own earlier proposed-sole-executor designation of emphasys (WGV6QFGH). **liam is the elevated executor.** **This is NOT a revert to v9.** v10 carries two corrections doyle issued (XKF7PEQV) that are independent of who the recipient is; both are carried forward here in substance: - the ledger file's absence establishes only that it was absent when checked — NOT that no execution ever occurred; - `QUEUED` means SPOOLED FOR DELIVERY — it is NOT acknowledgment of receipt and NOT evidence it was read. Reverting to v9 would have silently dropped both. No step, bound, ceremony, refusal or ordering was altered in either direction. The one-nonce rule, the ACK requirement, the re-confirm-before-the-firewall-phase rule, the stop-is-not-cancel rule and the missing-receipt-is-UNCERTAIN-COMPLETION rule all stand exactly as doyle ruled them. The ledger path `C:\Users\decid\.claude\liam-handoff-receipts.jsonl` is unchanged and was never changed, in any revision. In v10 it was the one deliberate exception to the rename because it is a FILENAME on disk; under this revision it simply agrees with the operative name again. Measured 2026-09-12: that path did not exist AT THE MOMENT I CHECKED, and that is ALL it establishes. It does NOT establish that no execution ever occurred — earlier A7 elevated actions are reported by the executor session (see the attribution note). Absence of the ledger file is not absence of prior execution. ## The identity conflict — unresolved as fact, resolved as instruction What is RULED: liam is the elevated executor. That is an operator decision and it governs this procedure. It is an instruction about who to address, not a measurement of what happened. What remains UNRESOLVED and is NOT settled by this revision: - Mail addressed to `liam` was measured to arrive at the session that sends as `emphasys`. - That session's own account of the mechanism is a stale listener bound to a PROCESS that outlived a `/clear`, so it READS liam's mail and WRITES as emphasys. It is their REPORTED mechanism. - My independent probe was DEFECTIVE and INCONCLUSIVE — it returned an empty command line for the pid and failed to find even my own listener. It confirmed nothing in either direction. - Challenge `CHAL-681a05382400` (question-only, sent 2026-09-12T11:16Z to emphasys) RETURNED at 2026-09-12T20:13:45Z, addressed to todlando and doyle, preserved verbatim in this directory as `emphasys-ZBYX4LK6-challenge-return-and-ack.txt`. **doyle ruled (PDGP4CHV) that the return DOES NOT CLEAR ADMISSION**; it is preserved as a completed exchange with emphasys and as evidence of reported cross-delivery. It was scoped by doyle to test THAT delivery exchange only — never routing, never historical authorship. **No further challenge resends into that route** (doyle, PDGP4CHV). - The return carries its own honest limits, stated by its author: the session id `96424616-fc54-4d00-a479-6ae7f334f3c8` is HARNESS-ASSERTED and corroborated against that session's filesystem footprint, NOT independently derived; two of their own id-discovery instruments were defective, one returning a different session's id outright. They also withdrew the clear-time listener account as INFERENCE, not measurement. - **Reported cross-delivery, and it cuts directly at this procedure's delivery assumption:** that session reports doyle's message ZXETH2BW — carrying challenge `LIAM-A2-2010` and opening "Reavo identifies you as the elevated executor" — was ALSO delivered into it, and deliberately did not answer it. This is their REPORT of an arrival, not my measurement of one. The envelope inventory and all preserved bodies sit in this directory. Nothing in this revision should be read as having settled the routing question or the authorship question. ## What is still OUTSTANDING — this procedure is not yet cleared to run 1. A FRESH identity acknowledgment from liam, addressed to that endpoint, obtained AFTER this correction. No earlier acknowledgment, from any name, carries over — **including the direct acknowledgment emphasys sent on 2026-09-12 (ZBYX4LK6)**, which accepted the emphasys sole-executor designation that the operator correction has since superseded. That acknowledgment is preserved, and it acknowledges a role this revision no longer assigns. **How it is being obtained — NOT by this procedure's operator** (doyle, A3LRIVTB). A liam-addressed challenge is REPORTED to have arrived at the emphasys session (LIAM-A2-2010, above), so soliciting through that route would prove nothing: the answer would not be self-evidently liam's. doyle has asked lia to arrange DIRECT contact from Reavo's intended liam terminal, and has barred further challenge resends into the contested route (PDGP4CHV). **todlando's no-traffic-to-liam hold REMAINS in force** and this operator does not solicit the acknowledgment. Wait for it to arrive by doyle's arrangement. 2. Fresh readiness for attempt 2. The prior readiness census is STALE — it was measured before a long pause — and the frozen bundle's admission must be re-established, not assumed. Attempt 2 is HELD and **must not be launched**. Any future grant will name liam EXPLICITLY. **All prior elevated grants are CLOSED and do NOT transfer between identities** — including the spent 49768 grant and anything issued under the emphasys designation. ## Attribution note — contested, recorded both ways The three-state on-disk nonce ledger described below, and the two prior A7 elevated actions the timing evidence rests on, were described to me in messages SIGNED emphasys, which stated that this process designed the ledger and had described it earlier under a liam signature line. Under the operator correction the operative executor is liam. I am NOT re-attributing the design or those actions to either name on my own authority: I did not witness them, I did not inspect the ledger, and I did not exercise these branches. They remain a REPORTED MECHANISM whose authorship is CONTESTED. Below, the name refers to the ADDRESSEE of this procedure — liam — and never to a settled finding about who authored what. --- # Supervised handoff procedure — fp-driver-v9.sh **Ruled by doyle, 2026-09-12.** The driver emits a handoff REQUEST FILE and waits; liam 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 liam 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 liam 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; liam reads the rest from the file. 3. **Require an acknowledgment before relying on delivery.** `SENT` is not `SEEN`, and `QUEUED` is SPOOLED — neither is receipt, and neither is evidence the message was read (doyle, XKF7PEQV). **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 liam as unreachable and stop rather than let the clock run out. **Reachability facts must be re-measured, not inherited.** v10 recorded a perch registration AUTH_REFUSED at SessionStart, reachability only through a separately-raised Monitor listener, and tag-borne bodies riding an inject leg that can swallow silently. Those were measured against the endpoint then in use, during the identity conflict. Do NOT carry them forward as facts about liam's endpoint: establish reachability freshly at delivery time. **A re-send is a re-DELIVERY, never a re-AUTHORIZATION.** The same path and nonce sent twice authorizes ONE execution. liam must recognise a duplicate request — same nonce — and respond by returning the receipt that already exists, or by reporting uncertain completion. liam must NOT rerun the command on a re-send. This is a requirement ON THE EXECUTOR; it was stated directly to the endpoint reached before this correction, so it must be RE-STATED to liam and acknowledged. The operator must not assume a re-send is harmless without it. **How the executor session says it implements this — REPORTED MECHANISM, not independently verified** (doyle's framing, 2026-09-12; I have not inspected the ledger or exercised these branches; authorship contested per the attribution note). The hole was raised by that session itself: 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 that session's account of its own behaviour — which is what the operator relies on when reading the answer — not as a guarantee this procedure has proven. 4. **An ACK is a CURRENT availability check, not a guarantee.** liam'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 liam — 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 liam: 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 the executor session's two reported A7 actions (authorship contested — see the attribution note; the TIMINGS are what this bound rests on, not the name attached to them), 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. **A bounded filesystem search is not the record, and its coming back empty does not erase a receipt** (doyle, A3LRIVTB). The attempt-1 cleanup failure is already established in that attempt's record as `rig_daemon_stop_EXIT=3` / `DAEMON_STOP_REFUSED`, followed by authorized residual termination and a cleanup END. A delayed background task re-surfacing that same outcome later is the SAME already-classified event, not a new one. Read the established attempt record first; a file you cannot find afterwards is a gap in your search, not proof the failure went unrecorded. - 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 liam may already have received: the request file exists, liam 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 liam'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 the executor the grant names. - Nothing here grants the run. Field admission is doyle's, and at the time of writing it is HELD and requires FRESH readiness.