ruby-dlee · ruby-dlee · Jul 31, 2026 · Jul 31, 2026 · Jul 31, 2026 · Jul 31, 2026
diff --git a/.agents/skills/lavish-decision-boards/SKILL.md b/.agents/skills/lavish-decision-boards/SKILL.md
@@ -40,7 +40,13 @@ A Lavish board is a live surface, so reconcile it against live fleet state befor
 
 ## Serve and verify
 
-1. Serve the board without auto-opening by passing `--no-open` or setting `LAVISH_AXI_NO_OPEN=1`.
+1. Serve the board with `lavish-axi <file> --no-open --no-gate`.
+   `--no-open` suppresses the auto-open, and `LAVISH_AXI_NO_OPEN=1` does the same.
+   `--no-gate` skips the open-time layout curtain, which is the difference between a working board and a blank one.
+   The curtain is CSS, not a hang: Lavish renders the shell with `body.layout-gate-active`, and `body.layout-gate-active iframe#artifact { opacity: 0 }` keeps the artifact invisible while the chrome paints, until the layout audit clears or a safety timer expires.
+   The gate is decided per request from the query string, so `?no-gate=1` on any already-served session URL uncurtains it with no re-serve; `?gate=0` is equivalent.
+   `--no-gate` sets no server-side state - it only stamps `?no-gate=1` onto the URL it prints, so the curtain returns the moment that parameter is dropped.
+   Carry the full printed URL, query string included, through every later step.
 2. Extract the printed session URL without its surrounding double quotes.
    A safe extraction pattern is `grep -oE 'https?://[^ "]+'`; verify that no quote or punctuation trails the URL.
 3. Open every board in its own dedicated Chrome window with `open -na "Google Chrome" --args --new-window "<url>"`.
@@ -49,6 +55,10 @@ A Lavish board is a live surface, so reconcile it against live fleet state befor
    Treat the board as not ready until the tool-authoritative connection signal confirms that it is genuinely connected.
    The transition to connected can take several minutes and is expected; during that lag, do not act on a poll return or prematurely re-serve, re-open, abandon, or otherwise thrash the session.
    Create and select a `chrome-devtools-axi` page for the exact served URL, then use a bounded retry to inspect that page's snapshots.
+   The artifact iframe is sandboxed `allow-scripts allow-forms allow-popups allow-downloads`, without `allow-same-origin`, so parent-frame JS evaluation can never reach into it.
+   Verify board content with a snapshot that crosses frames, never with an expression evaluated against the parent page.
+   Diagnose a board that looks blank with `curl -s <url> | grep -o '<body class="[^"]*"'`: `lavish layout-gate-active` means the curtain is on and `lavish` alone means it is off.
+   The browser tab title is not a gate indicator; verified 2026-07-30, it reads `<artifact title> · Lavish` when the artifact HTML carries a `<title>` and bare `Lavish Editor` when it does not, identically with and without the curtain.
    Pass only after the layout-audit-in-progress indicator has cleared and no layout-issue indicator is present, confirming zero error-severity `layout_warnings` for that board.
    A returned snapshot alone is not success; if the bound expires while the audit remains in progress, treat the board as unverified and do not surface it.
    Consult `chrome-devtools-axi --help` and the relevant command help for current commands and flags.
@@ -59,8 +69,13 @@ A Lavish board is a live surface, so reconcile it against live fleet state befor
 
 ## Protect answers
 
-- Answer preservation takes precedence over the serve-fresh rule while the captain has unsubmitted input.
+- A board in front of the captain is theirs, and that ownership is absolute while it is open.
+- Never navigate, reload, re-serve, or end it, never edit the file behind it, and never run browser automation against that window, including a read-only snapshot.
+- Verification with `chrome-devtools-axi` belongs before the board is surfaced; once the captain has it, the window is off limits too.
+- The test before any action is whether it could change what is on the captain's screen right now; if it could and their input may be unsubmitted, do not do it.
+- Answer preservation takes precedence over the serve-fresh rule while the captain has unsubmitted input; a board showing slightly stale state costs one correction, while a cleared board costs the captain's answers outright.
 - Never edit, refresh, or reload a served board while the captain is answering because doing so clears in-progress input.
+- Fix a problem with a live board server-side or not at all; a per-request option such as `?no-gate=1` is safe because it changes only what a fresh request renders, whereas re-serving or editing the file is not.
 - After submission, reconcile and refresh before continuing; if freshness must be preserved sooner, use only a strategy proven to retain the captain's current input without editing, refreshing, or reloading the served board.
 - When poll feedback arrives, write every annotation to the chosen durable file immediately, before interpreting it, acting on it, or doing anything else.
 - Never rely on poll output or conversation memory as the only copy because ephemeral poll output can be reaped.

diff --git a/.agents/skills/memory-hygiene/SKILL.md b/.agents/skills/memory-hygiene/SKILL.md
@@ -15,9 +15,24 @@ This skill owns entry shape for `data/captain.md` and `data/learnings.md` only.
 `AGENTS.md` section 6 owns knowledge routing and the files' inspect-then-update, rewrite-in-place contract.
 The `/stow` skill owns session sweeps, and `firstmate-coding-guidelines` owns repository-wide knowledge placement and one-owner discipline.
 
+## Promote or delete
+
+Learnings must live where they are read, so this is the first decision on every candidate entry, before any question of wording.
+
+- A rule that should change behavior belongs in the instruction surface that loads at the moment it applies: `AGENTS.md` when every session needs it, or the skill that loads at the triggering moment.
+  Promote it there and do not also keep it here.
+- During `/stow`, `stow/SKILL.md` owns the exception to this routing: file the surfaced rule through that skill's graduation path, and scope any natural skill-owner change separately as deliberate firstmate repository work.
+- Private memory holds only what cannot live in the shared repo: machine-specific and fleet-local facts such as service regions, credential locations, environment drift, and tool quirks specific to this box.
+- Promote or delete is the default outcome for a candidate entry; keeping it is the exception that has to earn itself against those two.
+- A general rule parked in a private file is the failure mode, not a safe backup.
+  Length is not diligence: a file nobody reads at the moment it matters lets its lessons be re-learned the expensive way.
+- Convert an incident narrative to the durable fact plus a one-line `[[pointer]]`, or delete it.
+- Delete stale and superseded entries outright rather than preserving them for safety.
+
 ## Entry standard
 
-- Record only the actionable rule or durable fact.
+- Record only an actionable rule or evidence-backed durable fact, never an inference framed as capability.
+- Require any asserted limit - "cannot", "impossible", "structural" - to cite the exact command and output that proved it and remain re-checkable as configs and permissions change; never write "do not retry" or an equivalent that suppresses falsification.
 - Strip emotion, emphasis, interpersonal interpretation, and incident drama.
 - Do not preserve that anyone was furious, shocked, disappointed, emphatic, or otherwise emotionally affected.
 - Preserve the operational instruction or evidence-backed fact that remains after the mood is removed.
@@ -29,7 +44,7 @@ The `/stow` skill owns session sweeps, and `firstmate-coding-guidelines` owns re
 
 ## Update practice
 
-1. Use `AGENTS.md` section 6 to confirm that the knowledge belongs in one of these private-memory files.
+1. Apply "Promote or delete" first, then use `AGENTS.md` section 6 to confirm that what remains belongs in one of these private-memory files.
 2. Inspect the current file and the candidate owning entry before writing.
 3. Search nearby entries for overlap, stale wording, and superseded variants.
 4. Reduce the new information to one actionable rule or durable fact.
@@ -58,6 +73,8 @@ It drops mood, drama, chronology, and commentary that do not change the rule.
 
 Reject the update if any answer is yes:
 
+- Is it a general rule that belongs in `AGENTS.md` or a skill that loads at the triggering moment?
+- Does it assert a limit without citing the command and output that proved it, or tell a future session not to re-check?
 - Does it describe emotion or intensity instead of changing future action?
 - Does it retell an incident beyond one short example or pointer?
 - Does another entry already own the same rule or fact?

diff --git a/.agents/skills/stuck-crewmate-recovery/SKILL.md b/.agents/skills/stuck-crewmate-recovery/SKILL.md
@@ -34,6 +34,13 @@ Handle permission evidence before the ordinary recovery ladder because approving
 6. After the captain clears the dialog, verify that the pane changes or `bin/fm-crew-state.sh <id>` reports resumed work before returning to supervision.
    If the permission was denied and the task still cannot proceed, use the ordinary ladder below with that denial as evidence.
 
+## Diagnose the layer before fixing
+
+Name the mechanism before applying any remedy, and treat "it is not working" as a symptom rather than a cause.
+State the specific line, flag, call, or process producing the behavior; if you cannot state it, you are guessing.
+Reading the tool's own code, header, or `--help` is cheaper than a round of speculative fixes, and each speculative fix destroys the evidence the next diagnosis needs and commonly breaks something that was working.
+Prove the layer before acting on it: confirm a dead agent from the process tree rather than from elapsed quiet, and confirm a wedge from two samples rather than one.
+
 For a non-permission stall, escalate in order:
 
 1. Peek the pane.