fix(lavish): remove persistent browser automation anchor

.agents/skills/lavish-decisions/SKILL.md

@@ -57,25 +57,27 @@ Do not pad an item to satisfy a wrapper it does not have.
    ```
 
    For a self-contained browser board, run `bin/fm-lavish-board.sh <decision-id> --home <resolved-absolute-home>` as documented in `tools/lavish/README.md`.
-   Only a successful exit authorizes reporting the board open because the helper checks its answering machinery before it arms pickup or opens Chrome.
-   Then tell the captain the named decision board is open.
+   Only a successful exit authorizes reporting the board open because the helper checks its download and manual-backup machinery before handing the file to the operating system's default browser.
+   Then tell the captain the named decision board is open and ask them to tell firstmate after saving the answer.
    Do not surface or invent a session URL.
 
 The surfaced command is for the captain's shell, not firstmate's environment.
 It must retain the emitted `--home` argument and resolved absolute home path even when firstmate has `FM_HOME` exported.
 Never shorten the command or reconstruct it from a placeholder.
 Always carrying the explicit home is slightly noisier than asking the captain to export `FM_HOME`, but it makes every decision independently runnable and avoids a hidden setup dependency.
-The browser wrapper must receive that same explicit resolved home so its dedicated profile and recovery check stay bound to the decision's fleet home.
+The browser wrapper must receive that same explicit resolved home so the downloaded payload's `home_marker` stays bound to the decision's fleet home.
 
 Do not edit `request.md` or `manifest.toon` after surfacing the decision.
 Their digest and ordered question or item set are the immutable contract.
 
 ## Consume
 
 Firstmate's ordinary wake drain and session start invoke Lavish intake.
+When the captain says a browser board is answered, run one bounded `lavish-axi intake --home <resolved-absolute-home>` immediately rather than waiting for an automated submission prompt; the board intentionally has none.
+The downloaded payload is the landing record until intake validates it into `answer.toon`.
 The answer file is authoritative; the wake record is only a pointer.
 Visible prompt delivery is redundant; `tools/lavish/README.md` owns its home-bound routing and manifest-destination contract.
-If that proof is unavailable, accept the fail-closed refusal and rely on the durable wake path rather than targeting ambient terminal state or asking the captain to submit again.
+If that proof is unavailable, accept the fail-closed refusal and rely on the durable answer path rather than targeting ambient terminal state or asking the captain to answer again.
 
 When a destination appears:
 
@@ -89,9 +91,9 @@ When a destination appears:
 
 Never start a server, create or share a session URL, poll, long-poll, register a filesystem watcher, schedule a timer sweep, or launch a resident server or listener process for Lavish decision capture.
 Do not use upstream `serve`, `poll`, browser, layout-audit, or session-lifecycle commands.
-The sole browser exception is `bin/fm-lavish-board.sh`, which opens a decision-specific profile and arms one ordinary bounded recovery check around the authoritative file protocol.
-Only that helper arms the pickup path; a hand-authored page is not a fallback because its answers cannot reach firstmate.
+The sole browser exception is `bin/fm-lavish-board.sh`, which invokes the operating system's default browser opener and exits without a dedicated profile, automation session, or submission check.
+Only that helper-generated page binds the downloaded answer to the immutable request and fleet home; a hand-authored page is not a fallback because its answers cannot enter the validated intake path.
 
-Every core Lavish command must finish its bounded local file operation and exit.
+Every core Lavish command and the board wrapper must finish its bounded local operation and exit.
 If `lavish answer` reports `answer saved; wake not queued`, do not ask the captain to answer again.
 The next ordinary intake scan recovers the durable unreceipted answer.

.agents/skills/lavish-repair/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: lavish-repair
 description: >-
-  Agent-only recovery playbook for a self-contained Lavish board that fails answerability preflight, does not open in its isolated Chrome session, or submits without pickup.
-  Use before touching a Lavish board's state artifacts or Chrome session during a surface incident.
+  Agent-only recovery playbook for a self-contained Lavish board that fails answerability preflight, default-browser open, interaction, answer download, or bounded intake.
+  Use before touching a generated board or downloaded-answer artifact during a surface incident.
   Do not use it to create or present a decision; use `lavish-decisions` for that.
 user-invocable: false
 metadata:
@@ -11,73 +11,66 @@ metadata:
 
 # Lavish repair
 
-Prove the failing layer before changing state or stopping a process.
-The Lavish fork has no server, session URL, live channel, listener, or poller to repair.
-Never invoke upstream serve, poll, or server-lifecycle commands.
+Prove the failing layer before changing any durable artifact.
+The Lavish fork has no server, session URL, live channel, browser automation session, listener, poller, or armed submission check to repair.
+Never invoke upstream serve, poll, browser, or server-lifecycle commands.
 
 ## Start from the owners
 
-Read `bin/fm-lavish-board.sh`'s header and `--help` output for the current preflight, dedicated-browser, and pickup mechanics.
-Read `tools/lavish/README.md` for the durable decision and payload protocol.
-Load `lavish-decisions` before completing the normal collect and consume workflow.
+Read `bin/fm-lavish-board.sh`'s header and `--help` output for the current preflight and default-browser-open mechanics.
+Read `tools/lavish/README.md` for the durable decision, downloaded payload, and intake protocol.
+Load `lavish-decisions` before completing the normal consume workflow.
 
-Establish the exact decision id, resolved Firstmate home, helper output, and named Chrome session before diagnosing the incident.
-Preserve any downloaded answer JSON, durable pickup payload, and unsubmitted captain input.
+Establish the exact decision id, resolved Firstmate home, helper output, generated HTML path, and browser download location before diagnosing the incident.
+Preserve any downloaded answer JSON, manual payload backup, and unsubmitted captain input.
 Do not edit `request.md` or `manifest.toon`, because their digest and ordered question or item set are immutable.
 
 ## Diagnose in route order
 
 ### 1. Answerability preflight
 
 When the helper refuses an unanswerable board, read its named missing components.
-Do not bypass the preflight, arm pickup by hand, or substitute hand-authored HTML.
+Do not bypass the preflight or substitute hand-authored HTML.
 Resolve checkout or installed-tool version skew against the active helper and Lavish fork before trying the helper again.
 
-The helper has not opened Chrome or armed pickup when this check fails.
+The helper has not invoked the default browser when this check fails.
 Surface the exact terminal fallback emitted by `lavish-axi create` instead of reporting that a board is open.
 
-### 2. Browser launch
+### 2. Browser open
 
-When preflight succeeds but opening Chrome fails, retain the helper's exact error and session name.
-The helper removes the armed check on an open failure, so do not report that submission pickup is active.
-Use current `chrome-devtools-axi` help to inspect only the helper's named isolated session.
-Never attach the board to the captain's main Chrome profile.
-
-If the isolated session cannot be restored safely, use the exact terminal fallback from the creation result.
+When preflight succeeds but the operating system cannot open the generated file, retain the helper's exact error and HTML path.
+Do not launch a dedicated browser profile, Chrome DevTools process, browser automation session, server, or resident helper as a workaround.
+Open the existing self-contained file through the host's ordinary default-browser surface, or use the exact terminal fallback from the creation result.
 
 ### 3. Board interaction
 
-When the board is open but visibly broken, inspect that page in the named isolated session before reloading or reopening it.
-Protect any unsubmitted captain input before a page-level repair.
-If the rendered controls or submit machinery are missing, treat that as generator or version drift and return to the answerability-preflight branch.
-
-### 4. Submission pickup
+When the board opens but is visibly broken, protect any unsubmitted captain input before reloading or reopening the generated file.
+If the rendered controls, review step, download button, or manual payload backup are missing, treat that as generator or version drift and return to the answerability-preflight branch.
+Do not edit the generated page to manufacture an answer path.
 
-The verified browser-profile record is the authoritative pickup route, and a matching download is optional corroboration.
-Keep the helper's existing one-shot check armed so Firstmate's ordinary watcher can recover the record even after the visible browser closes.
-Do not add another storage bridge, filesystem watcher, timer sweep, long poll, or resident process.
+### 4. Downloaded answer
 
-Preserve a matching download for corroboration, but do not treat it as confirmed delivery.
-If the helper emits `lavish-submit: <decision-id> <payload-path>`, preserve that exact durable payload and continue through the `lavish-decisions` consume workflow.
-Confirm receipt only after `lavish-axi collect` validates and saves the answer.
+The board's landing record is `lavish-answer-<decision-id>-<request-digest>.json` in the browser's download location.
+The board also exposes the exact JSON as a manual backup so a blocked automatic download does not erase the completed batch.
+If needed, save that backup under the same filename in the normal or `LAVISH_DOWNLOADS_DIR` location, preserving every byte the board produced.
 
-### 5. Collection
+Do not report automatic delivery or wait for a submission prompt; neither exists.
+Do not add browser-profile storage, an armed check, filesystem watcher, timer sweep, long poll, server, or resident process.
+When the captain says the answer is saved, continue immediately to one bounded intake.
 
-Treat a named `lavish-axi collect` validation error as a payload or immutable-request mismatch, not a browser failure.
-Preserve the rejected payload for diagnosis and do not weaken the schema, key, option, annotation, or request-digest checks.
-Do not ask the captain to answer again when the same valid answer has already been saved durably.
+### 5. Intake and collection
 
-## Process safety gate
+Run `lavish-axi intake --home <resolved-absolute-home>` once and inspect its complete result.
+Intake discovers the home-bound download, validates the schema, decision id, request digest, ordered keys, and declared values, commits `answer.toon`, writes the declared destination, and then writes `receipt.toon`.
+Confirm receipt only after that validated path succeeds.
 
-Prefer the helper's named Chrome-session controls over process signals.
-Never use `pkill -f` or signal a process selected only by a tool-name pattern, because crewmate launch commands can contain the same text.
-If an explicit process signal is genuinely required, list candidates, inspect every candidate's PID, parent, elapsed time, and full command, then signal only one PID whose isolated-session identity is proven.
-Never pipe unfiltered process-search output into `kill`.
-Recheck the named session after the action before considering another signal.
+Treat a named payload or `lavish-axi collect` validation error as a payload or immutable-request mismatch, not a browser failure.
+Preserve the rejected payload for diagnosis and do not weaken the schema, key, option, annotation, home-marker, or request-digest checks.
+Do not ask the captain to answer again when the same valid answer has already been saved durably.
 
 ## Recovery boundary
 
-A surface failure does not erase the durable decision, a downloaded payload, or a collected answer.
+A surface failure does not erase the durable decision, a downloaded payload, a manual payload backup, or a collected answer.
 Use `lavish show` and `lavish inbox` with the explicit Firstmate home to distinguish pending from already answered state.
 Reopen a board only when no submitted payload exists and the captain's unsubmitted input has been protected or is known to be absent.
 If the browser route remains unavailable, the exact `lavish answer ... --home ...` creation fallback keeps the decision answerable without browser infrastructure.

AGENTS.md

@@ -186,7 +186,7 @@ If the digest reported `data/projects.md` as `ABSENT` or disagreeing with what i
 An `ABSENT` `data/captain.md` or `data/secondmates.md` or `data/learnings.md` means exactly what section 2 says it means (template defaults, no registered secondmates, nothing captured yet) - not a problem to fix.
 
 Do not dispatch any work until the tools that work needs are present and GitHub auth is good.
-Use `gh-axi` for all GitHub operations, `chrome-devtools-axi` for all browser operations, and the firstmate-owned `lavish-axi` file protocol for durable captain decisions and annotation boards that must remain answerable asynchronously.
+Use `gh-axi` for all GitHub operations, `chrome-devtools-axi` for browser automation and inspection, and the firstmate-owned `lavish-axi` file protocol for durable captain decisions and annotation boards that must remain answerable asynchronously.
 Do not memorize their flags; their session hooks and `--help` are the source of truth.
 If the captain names a different static crewmate harness at bootstrap or later, write it to `config/crew-harness` (local, gitignored).
 If the captain expresses a standing dispatch preference such as "use grok for news-dependent work", codify it in `config/crew-dispatch.json` instead.
@@ -869,7 +869,7 @@ These skills are not captain-invocable; they are conditional operating reference
 - `firstmate-coding-guidelines` - load before changing firstmate's shared, tracked material, as defined by section 1's list, whether editing directly or briefing a crewmate for a firstmate-repo task.
 - `memory-hygiene` - load before writing, rewriting, pruning, deduplicating, or otherwise leaning `data/captain.md` or `data/learnings.md`.
 - `lavish-decisions` - load before creating, repairing, or presenting a multi-option captain choice, and before asking the captain to comment on material without choosing anything.
-- `lavish-repair` - load when a self-contained Lavish board fails preflight, browser launch, interaction, submission pickup, or collection, and before touching its state artifacts or isolated Chrome session.
+- `lavish-repair` - load when a self-contained Lavish board fails preflight, default-browser open, interaction, answer download, or bounded intake, and before touching a generated board or downloaded-answer artifact.
 - `eks-usage` - load before running `kubectl` or Amazon EKS commands, on an EKS IAM, authenticator, TLS, or connectivity error, or whenever the active cluster or context is uncertain.
 
 ## 14. X mode