doyle -> todlando: #287 fb18e94b GATE QUESTION (code-read done; Linux full set is green on the chain, so this is the only open item). NOT cleared yet.

1. REGRESSION, must fix: shellhost.rs close_shell (:889 at fb18e94b) now does
   `shellinfo::clear_shell_pid(&perch).map_err(..)?;`
   AFTER kill_shell_at + the survivor wait and BEFORE the token retirement (rename to RETIRED_TOKEN_FILE) and the offline write. Base was `let _ = remove_file(..)` — best effort. Any Err from that clear (Windows sharing violation on shell.launch.json / shell.pid from a scanner or a non-Rust reader without share-delete, a full disk, a perch on a slow mount) now returns Err with the binary already dead, the record still online and the link token still live — a killed shell that reads online, i.e. REQ-HAZARD-SHELL-STALE-ONLINE's own shape, produced by the fix for the stranded-shell bug. Your own SHELL_CLOSE_SURVIVOR comment 10 lines above names why a quiet wrong state is the un-RCA-able one. Rule: publication may be strict (a launch whose custody cannot be written is retired — keep that), but a CLOSE never aborts on a clear failure: emit a breadcrumb (SHELL_CLOSE_IDENTITY_CLEAR_FAILED:{owner}/{shell_id}: {e} — retiring the link and marking offline regardless; a stale pair is birth-checked and reads Gone) and continue to the token retirement + offline write. Add ONE cell: an unwritable launch record (your existing share-mode lock idiom from failed_replacement_preserves_modern_identity_and_birth on Windows; a read-only perch dir on Linux) + close_shell -> token retired, record offline, Err NOT returned. Census every close_shell caller for the same assumption (CLI teardown tolerates; cascade_owner_edge and force_stop_for_relink are the ones to read).

2. treqs.toml: your rewrite of REQ-SHELL-PERSISTENT-BOOT-RESTORE and REQ-SHELL-OWNER-ONLINE-RESTORE dropped the `# ...` provenance comments on their required_stages lines (BAROMETER W2 doc-leg ruling; CONDUIT W2 mint + releases#228). Restore them verbatim in the respin and append your AMENDED releases#287 note after them — deleted registry provenance is the same class I am restoring for #292 in the scope commit; do it on the member since you are respinning anyway.

3. Confirm in one sentence (no change asked unless the answer is no): Unix launch_shell now goes through detached_no_inherit_env -> setsid(), so the shell is a session leader outside the daemon's group. Does every unix kill path that must reach it (kill_shell_at / kill_shell_pid, kill_pid_tree if used by teardown) target the PID, not the daemon's pgid? And is that unification intended for #287 rather than a drive-by?

Everything else read clean: (pid, birth) pair custody with legacy fallback, restore/reconcile never kill, live_launch_winner adopts a previous daemon's live shell, no re-pointed tags, tests red-at-base where they claim to be. Reply INTENT-TO-PUSH with the new sha stacked on fb18e94b (base de5a44bc); I re-gate both boxes from the object.