From 6085ab9d99db2c04d938fb72d7b5b5267bcc07aa Mon Sep 17 00:00:00 2001
From: atom <seal161285@gmail.com>
Date: Mon, 5 Oct 2026 13:21:34 +0800
Subject: [PATCH] docs(qa): refresh qa/SKILL.md, keep every rule and drop the
 history

qa/SKILL.md is the fomo-qa skill that Claude, Codex, Antigravity and Grok load
as instructions. Next to its rules it carried dated decisions, incident and
audit write-ups, issue and PR pointers used as provenance, "used to" and "now"
notes, a retired-flag remark and superseded examples. Each is rewritten in
place so the rule stands alone; nothing is added, and no rule is dropped or
weakened.

- frontmatter description: 956 -> 450 characters; what the skill does, its
  triggers, and the pointer to the product skill fomo-kernel. The rationale
  half (purpose, mechanism list) is gone; every rule in it is stated in the
  body.
- 68 in-place edits across the body. Past-tense observations of one run become
  present-tense statements of the route's behaviour only where the engine or a
  test guarantees them (QUESTION_POLICY, test_review_v2's reconciled status);
  a candidate's `grounding` is stated as present when the engine has one.
- two dates stay because deleting them would change what an agent does: the
  as-of stamp on how generic visualization tools treat a supplied <style>
  (2026-07-21) and on the case-id lists of acceptance issue #486 (2026-07-29).
  Example values in templates are untouched.
- the issue and PR numbers that only said where a rule came from are gone;
  #486, the live acceptance issue an operator must read, stays.

Locks kept: the gate count and the seven-name roster, CJK only on the
description line and the trigger bullet, every `# qa-trace:` fence and its
replay, the placeholder map, the "Continuing in the same campaign" section.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---
 qa/SKILL.md | 122 ++++++++++++++++++++++++++--------------------------
 1 file changed, 60 insertions(+), 62 deletions(-)

diff --git a/qa/SKILL.md b/qa/SKILL.md
index e8ec76b..9aba59d 100644
--- a/qa/SKILL.md
+++ b/qa/SKILL.md
@@ -1,21 +1,19 @@
 ---
 name: fomo-qa
-description: Prepares a clean, consistent QA environment for dogfooding fomo-kernel and walks the real product routes — review, refresh, and what follows — as one continuous campaign in a single conversation. Use when the user says /fomo-qa, "dogfood fomo-kernel", 跑一次 fomo QA, 走一次復盤驗收, 準備乾淨的測試環境, 幫我 QA fomo-kernel. Its purpose is to kill the rework that comes from every session testing a different environment: a fixed version gate (test only on the latest origin/main, refuse when behind) + a clean detached dogfood worktree (never used for development) + a simulated new user (a dogfood-only coach root, cleared with qa_env.sh reset, never the real ~/.trade-coach) + standardized data sources (real trades / mock persona / test-drive). This is the acceptance tool used while developing and maintaining fomo-kernel, not the product itself; to review a real user's trades, use the product skill fomo-kernel instead. Never touches the real records in investment_note.
+description: Prepares a clean, consistent QA environment for dogfooding fomo-kernel and walks the real product routes — review, refresh, and what follows — as one continuous campaign in a single conversation. Use when the user says /fomo-qa, "dogfood fomo-kernel", 跑一次 fomo QA, 走一次復盤驗收, 準備乾淨的測試環境, 幫我 QA fomo-kernel. Maintainer tooling for developing fomo-kernel, not the product itself — to review a real user's trades, use the product skill fomo-kernel instead.
 ---
 
 # fomo-qa
 
 This makes "prepare a clean, consistent fomo-kernel dogfood environment" a procedure. **It is a QA tool for development and maintenance**, answering "I changed the engine — walking through as a real user would, is the experience right?", and it guarantees every run tests **the same thing**: the latest `origin/main`.
 
-**This is the mandatory standard path for every fomo-kernel dogfood (v1, fixed 2026-07-20)** — every dogfood starts here. Do not improvise an environment on the spot.
+**This is the mandatory standard path for every fomo-kernel dogfood** — every dogfood starts here. Do not improvise an environment on the spot.
 
-**Cross-client contract source (since 2026-07-21)**: `docs/qa-runbook.md` in the `kol_collector/fomo-kernel` repository (PR #275) defines what counts as a compliant QA run — **seven** gates (version gate / isolated root / receipt throughout / verdict+verify / archived manifest / privacy lint / **findings disposition**). A session missing any of them is not a QA run and its conclusions may not be cited. The seventh was added on 2026-07-27 (#417): a session passing the first six while leaving behind no replayable asset is exactly what this loop actually looked like for a year. That `docs/qa-runbook.md`, together with the repo-root `AGENTS.md`, **must stay independent of this skill and of any personal registry** — fomo-kernel is a public product a stranger clones on any machine, and cannot assume they have this skill. When the two disagree, the runbook wins.
+**Cross-client contract source**: `docs/qa-runbook.md` in the `kol_collector/fomo-kernel` repository defines what counts as a compliant QA run — **seven** gates (version gate / isolated root / receipt throughout / verdict+verify / archived manifest / privacy lint / **findings disposition**). A session missing any of them is not a QA run and its conclusions may not be cited. `docs/qa-runbook.md`, together with the repo-root `AGENTS.md`, **must stay independent of this skill and of any personal registry** — fomo-kernel is a public product a stranger clones on any machine, and cannot assume they have this skill. When the two disagree, the runbook wins.
 
-**What this skill is**: the runbook's seven gates automated into a repeatable procedure plus the `qa_env.sh` tool, for ting's own maintenance of fomo-kernel. Since 2026-07-21 it is reachable through `ai-harness`'s discovery registry, so Claude, Codex and Antigravity all call the same canonical content under the same name `fomo-qa` (see `ai-harness/inventory/fomo-qa.json`). **It is not for anyone else** — an external user has no such skill and needs none; they follow the public `docs/qa-runbook.md` above.
+**What this skill is**: the runbook's seven gates automated into a repeatable procedure plus the `qa_env.sh` tool, for ting's own maintenance of fomo-kernel. It is reachable through `ai-harness`'s discovery registry, so Claude, Codex and Antigravity all call the same canonical content under the same name `fomo-qa` (see `ai-harness/inventory/fomo-qa.json`). **It is not for anyone else** — an external user has no such skill and needs none; they follow the public `docs/qa-runbook.md` above.
 
-> Why it exists: a 2026-07-19 audit found 17 of 18 worktrees behind main (the worst by 28 commits). Dogfood had been running on development worktrees each pinned to its own base — testing some past slice of the product, with no way to learn afterwards which slice. "It runs" is not "it tested the latest version". This skill blocks that mechanically (issue #250).
-
-> **Its place in the eval system**: this is also the execution procedure that `docs/eval-design.md`'s evidence level **4 (human review)** and observation surface 1 (content-free interaction receipts) had always lacked. A walkthrough ends by producing a `ux_receipt` owner verdict, turning the layer eval currently marks "pending owner dogfood" into a machine-readable annotation that accumulates. **Since 2026-07-27 it produces one more thing**: step 6 converts every miss into a replayable episode under `evals/episodes/`, so a dogfood produces a permanent regression asset rather than a one-off observation — that is what "what we get is stable enough to keep" means.
+> **Its place in the eval system**: this is the execution procedure for `docs/eval-design.md`'s evidence level **4 (human review)** and observation surface 1 (content-free interaction receipts). A walkthrough ends with a `ux_receipt` owner verdict, a machine-readable annotation that accumulates; Step 6 converts every miss into a replayable episode under `evals/episodes/`, so a dogfood leaves a permanent regression asset rather than a one-off observation.
 
 ## When to use it
 
@@ -25,21 +23,21 @@ This makes "prepare a clean, consistent fomo-kernel dogfood environment" a proce
 
 **Not** for reviewing a real user's trades — that is the product skill `fomo-kernel`. This skill only makes the acceptance environment clean and consistent; the walkthrough itself still follows the product's `SKILL.md`.
 
-## Coverage (v1, fixed — do not claim beyond it)
+## Coverage (do not claim beyond it)
 
-This round verifies **L1: environment consistency + engine CLI contract + agent walkthrough behavior**. Completing `/fomo-qa` means "the engine and agent behavior were verified on the latest version". It does **not** mean "the user's experience was verified on every client". The following are **known follow-ups, out of this procedure**; do not claim the experience is green after a run (that is precisely the false-pass trap in [#230](https://github.com/atomchung/fomo-kernel/issues/230)):
+This procedure verifies **L1: environment consistency + engine CLI contract + agent walkthrough behavior**. Completing `/fomo-qa` means "the engine and agent behavior were verified on the latest version". It does **not** mean "the user's experience was verified on every client". The following are **known gaps, outside this procedure**; do not claim the experience is green after a run:
 
-- **L2 card visuals** (next round): the card HTML is never actually rendered in a browser and compared by screenshot (today even `test_card_html.py` makes string assertions and takes zero screenshots). Visual consistency, layout and dark mode can only be eyeballed.
-- **L3 interaction delivery** (partly an inherent ceiling): "the option buttons really appeared and the user could really click them" is a client-layer fact (Claude native options vs typing by hand in Codex) and cannot be verified headlessly. Here we verify only the contract layer — the card text was pasted into the conversation, the questions were presented — which `tools/ux_receipt.py` can carry. The native-interaction half on Codex is #230's ceiling and rests on the owner's manual verdict.
-- **A general HTML interaction document + the fastest plain-text completion experience**: next round.
+- **L2 card visuals**: the card HTML is never actually rendered in a browser and compared by screenshot. Visual consistency, layout and dark mode can only be eyeballed.
+- **L3 interaction delivery** (partly an inherent ceiling): "the option buttons really appeared and the user could really click them" is a client-layer fact (Claude native options vs typing by hand in Codex) and cannot be verified headlessly. Here we verify only the contract layer — the card text was pasted into the conversation, the questions were presented — which `tools/ux_receipt.py` can carry. The native-interaction half on Codex rests on the owner's manual verdict.
+- **A general HTML interaction document + the fastest plain-text completion experience**: not covered.
 
 ## Hard isolation guardrails (read first, non-negotiable)
 
 1. **Never touch the real records**: `~/Side_project/investment_note/` holds ting's real investment records. Only the "real trades" data source reads **one** CSV there, read-only; nothing else is read or written.
-2. **Coach state is isolated to a dogfood-only root, and the real one is not reachable**: dogfood always uses a separate `~/.trade-coach-dogfood`, fully apart from the `~/.trade-coach` you use with the real product. Clear it with `qa_env.sh reset` (which backs up first and fail-closed refuses to touch the real root or investment_note). The real `~/.trade-coach` is managed only by `reset-fomo-coach.sh`; the dogfood procedure never touches it. Never hand-write an `rm` against any coach root. **`TRADE_COACH_HOME` routes writers only** — it never stopped anything reading the real root, and in #557 an agent that judged the isolated root unfamiliar and empty read the real ledger on its own initiative. Step 0's `isolate` closes that path by replacing `HOME`, and is a gate rather than a request. A dogfood root that looks empty is a fresh dogfood root; never go looking for a fuller one, and never compose an absolute path to the real one — that is the one hole this lane cannot close.
+2. **Coach state is isolated to a dogfood-only root, and the real one is not reachable**: dogfood always uses a separate `~/.trade-coach-dogfood`, fully apart from the `~/.trade-coach` you use with the real product. Clear it with `qa_env.sh reset` (which backs up first and fail-closed refuses to touch the real root or investment_note). The real `~/.trade-coach` is managed only by `reset-fomo-coach.sh`; the dogfood procedure never touches it. Never hand-write an `rm` against any coach root. **`TRADE_COACH_HOME` routes writers only** — it does not stop anything from reading the real root, so an agent that finds the isolated root unfamiliar and empty can read the real ledger on its own initiative. Step 0's `isolate` closes that path by replacing `HOME`, and is a gate rather than a request. A dogfood root that looks empty is a fresh dogfood root; never go looking for a fuller one, and never compose an absolute path to the real one — that is the one hole this lane cannot close.
 3. **Work only in the dogfood worktree**: every engine command runs inside the detached worktree created by `qa_env.sh up`. `qa_env.sh` is itself fail-closed and only operates on a worktree whose path contains `dogfood`, so a slip cannot discard another session's uncommitted work.
 4. **Do not change product code**: QA reads, it does not edit. If the walkthrough finds a bug, write it down and open an issue; do not fix it in the dogfood worktree (it is detached and exists to be tested, not developed).
-5. **Public text passes the privacy lint first (bought by the #274 incident)**: the repository is public, and real tickers, specific amounts, or `TICKER#date#seq` position ids **must never** appear in an issue, PR, comment or commit message — text channels count, not just files. If this QA session used real trade data, run every draft destined for GitHub through the lint first (from `skills/fomo-kernel/` inside the dogfood worktree):
+5. **Public text passes the privacy lint first**: the repository is public, and real tickers, specific amounts, or `TICKER#date#seq` position ids **must never** appear in an issue, PR, comment or commit message — text channels count, not just files. If this QA session used real trade data, run every draft destined for GitHub through the lint first (from `skills/fomo-kernel/` inside the dogfood worktree):
 
    ```bash
    python3 tools/privacy_lint.py --against ~/Side_project/investment_note/trades/fomo/trades.csv /tmp/draft.md
@@ -59,7 +57,7 @@ This round verifies **L1: environment consistency + engine CLI contract + agent
 
 ### Step 0 — Isolate this shell, then the version gate (read-only)
 
-`qa_env.sh` **refuses every command** until the shell it runs in has the account's own coach root out of reach (#557), so this line comes before everything else — including `status` — and has to be repeated in every later shell of the campaign:
+`qa_env.sh` **refuses every command** until the shell it runs in has the account's own coach root out of reach, so this line comes before everything else — including `status` — and has to be repeated in every later shell of the campaign:
 
 ```bash
 eval "$(~/.claude/skills/fomo-qa/qa_env.sh isolate)"
@@ -67,7 +65,7 @@ eval "$(~/.claude/skills/fomo-qa/qa_env.sh isolate)"
 
 It exports the dogfood `TRADE_COACH_HOME` **and** replaces `HOME` with a throwaway directory, so that `~/.trade-coach` — the path `review.py`, `coach.py`, `tools/ux_receipt.py` and any improvised shell command all compose by default — names nothing. Every value in the block is resolved against the account's real home *before* the override, which is why the repo, the dogfood worktree, the receipt archive, `git`'s configuration and Python's user-installed packages keep working after it. Export any `FOMO_DOGFOOD_*` overrides for a concurrent session **before** this line, while `$HOME` is still the account's own.
 
-It is a bounded guarantee, and reporting it as more than that is the failure it was written against: an absolute path typed on purpose still reaches the real root, and only running the campaign in a container would change that. Do not type one.
+It is a bounded guarantee; do not report it as more than that: an absolute path typed on purpose still reaches the real root, and only running the campaign in a container would change that. Do not type one.
 
 ```bash
 ~/.claude/skills/fomo-qa/qa_env.sh status
@@ -93,7 +91,7 @@ cd ~/Side_project/kol_collector/fomo-kernel-dogfood/skills/fomo-kernel
 
 Steps 0–3 are the **campaign** setup: one worktree, one isolated root, one client/model/effort identity, one acceptance campaign. They happen **once**. Everything after them is a **route run** — one `first_review`, one `refresh`, one `weekly_review` — and a conversation may contain several, each with its own receipt and its own archived `run_id`.
 
-Three identities that are deliberately not one-to-one (#544):
+Three identities that are deliberately not one-to-one:
 
 | | What it is | How many |
 |---|---|---|
@@ -103,7 +101,7 @@ Three identities that are deliberately not one-to-one (#544):
 
 **Never merge route runs into one receipt.** A `first_review` owes two cards and a cash anchor, a `refresh` owes a card-free change surface and no cards at all — one mixed trace could satisfy neither verifier. The reusable unit is the campaign, not the receipt.
 
-**Step 0's `isolate` already routed the whole toolchain into the dogfood-only coach root** — `review.py`, `coach.py` and `tools/ux_receipt.py` **all three** honor `TRADE_COACH_HOME` (ux_receipt since the #269 fix, merged in PR #275), so that one export keeps `prepare`/`preview`/`finalize`/`data-status` and the receipt consistent throughout. If this is a new shell, re-run it before anything else:
+**Step 0's `isolate` already routed the whole toolchain into the dogfood-only coach root** — `review.py`, `coach.py` and `tools/ux_receipt.py` **all three** honor `TRADE_COACH_HOME`, so that one export keeps `prepare`/`preview`/`finalize`/`data-status` and the receipt consistent throughout. If this is a new shell, re-run it before anything else:
 
 ```bash
 eval "$(~/.claude/skills/fomo-qa/qa_env.sh isolate)"
@@ -115,9 +113,9 @@ eval "$(~/.claude/skills/fomo-qa/qa_env.sh isolate)"
   ~/.claude/skills/fomo-qa/qa_env.sh reset   # back up, then clear the dogfood root to a fresh new user
   ```
 
-- **Simulate a returning user** (runs weekly-review / due-revisit): do **not** reset. Keep the dogfood coach state left by a previous campaign and go straight to Step 3. **Lesson from 2026-07-20: a freshly reset session can never test memory continuity or problem-ledger continuity** (memory is `not_applicable`, and an empty prior problem ledger will not "catch" you). Verifying "did last time's problem follow up?" requires a book that already has a finalized review behind it — do not mistake its absence for a fix working.
+- **Simulate a returning user** (runs weekly-review / due-revisit): do **not** reset. Keep the dogfood coach state left by a previous campaign and go straight to Step 3. **A freshly reset session can never test memory continuity or problem-ledger continuity** (memory is `not_applicable`, and an empty prior problem ledger will not "catch" you). Verifying "did last time's problem follow up?" requires a book that already has a finalized review behind it — do not mistake its absence for a fix working.
 
-Confirm with the user which one to simulate; default to "brand-new user" when unsure. This is a **campaign-level** choice, made once. It is not re-asked before each route run: a campaign that opened fresh and then finalized a `first_review` **is** a returning user for everything that follows, without a reset and without leaving the conversation. That is the cheapest way to reach the returning-user routes, and since #544 it is the documented one.
+Confirm with the user which one to simulate; default to "brand-new user" when unsure. This is a **campaign-level** choice, made once. It is not re-asked before each route run: a campaign that opened fresh and then finalized a `first_review` **is** a returning user for everything that follows, without a reset and without leaving the conversation. That is the cheapest way to reach the returning-user routes.
 
 **This isolation must survive into every later shell** — if commands each start a new shell, re-run the `isolate` line in every one, for every route run in the campaign. `qa_env.sh` refuses when it has not been; the engine and receipt commands do not, because they are product commands a real user runs against their own root, so a shell that quietly lost it writes the dogfood run into the real book. Establish it first, every time.
 
@@ -165,7 +163,7 @@ Below is a **complete, directly copyable `first_review` trace**. The order is a
 python3 tools/ux_receipt.py start --session-id <ID> --client claude --route first_review \
   --adapter validated_widget --question-mode native_options --card-mode widget
 
-# 1) Cash anchor (#357): exactly once on first_review / weekly_review, and where it goes
+# 1) Cash anchor: exactly once on first_review / weekly_review, and where it goes
 #    follows the outcome. `found_in_source` is read out of the statement during prepare, so
 #    it must come before the first question and the first card — recording it later is
 #    judged out of order. When the source carries no balance the plan says so
@@ -177,12 +175,12 @@ python3 tools/ux_receipt.py event --session-id <ID> --event cash_anchor_checked
 
 # 2) One row per question asked. Question text never enters the trace: a question from a
 #    validated dynamic surface records "source + sha256 of the presented text" instead, and
-#    the two must appear together (this replaces the removed --question-id).
+#    the two must appear together.
 python3 tools/ux_receipt.py event --session-id <ID> --event question_presented \
   --mode native_options --surface-source validated_dynamic --surface-digest <64-hex-digest>
 
 # 3) Record this the instant the user answers the last required question, before running
-#    preview — it is #236's measurement start for "answered → card".
+#    preview — it starts the "answered → card" measurement.
 python3 tools/ux_receipt.py event --session-id <ID> --event answers_received
 
 # 4) Cards are always "artifact first, presented second", and both rows need --stage
@@ -192,7 +190,7 @@ python3 tools/ux_receipt.py event --session-id <ID> --event card_presented \
   --stage preview --mode widget
 
 # 5) Record when the "pick a rule / write your own / skip" choice is shown.
-#    --grounding-check-file is required (#293)
+#    --grounding-check-file is required
 python3 tools/ux_receipt.py event --session-id <ID> --event rule_choice_presented \
   --mode native_options --grounding-check-file <grounding-check.json>
 
@@ -217,12 +215,12 @@ python3 tools/ux_receipt.py event --session-id <ID> --event card_presented \
 }
 ```
 
-A candidate with no `grounding` omits the field entirely (like `candidate_1`) — **do not invent a sentence to fill it**. That is precisely the half #293 cannot catch and only a human can hold.
+A candidate with no `grounding` omits the field entirely (like `candidate_1`) — **do not invent a sentence to fill it**. That is precisely the half the mechanical check cannot catch and only a human can hold.
 
-**The `weekly_review` route carries one extra opener, and `verify` enforces it** (the trace above is `first_review`; do not copy the opener into it). When `prepare` selects `weekly_review`, show the user the rule agreed last time **before the first question and the first card**. Two rows differ from the trace above — that opener, and the cash anchor. This trace deliberately shows the other cash shape: a source with no balance row, so the plan came back `absent`, and the balance was asked for in the same message as a preview card. Where the outcome row lands from there depends on the outcome (#663), because only one of the two recomputes anything:
+**The `weekly_review` route carries one extra opener, and `verify` enforces it** (the trace above is `first_review`; do not copy the opener into it). When `prepare` selects `weekly_review`, show the user the rule agreed last time **before the first question and the first card**. Two rows differ from the trace above — that opener, and the cash anchor. This trace deliberately shows the other cash shape: a source with no balance row, so the plan came back `absent`, and the balance was asked for in the same message as a preview card. Where the outcome row lands from there depends on the outcome, because only one of the two recomputes anything:
 
 - `declined` — nothing recomputes, so the card that asked the question is also the settled one, and the row sits **after** it, exactly as before.
-- `provided` — always triggers `add-cash` and a recompute, so the card the user actually used to choose or skip the rule is the one rendered *afterward*, never the one that asked. The trace's one `stage=preview` artifact/`card_presented` pair is reserved for that later, settled card, so the row sits **before** it: record `cash_anchor_checked --cash-outcome provided` when the user answers, run `add-cash` and rerun `preview` on the session it returns — keeping THIS session id for the whole trace, since a receipt records one conversation, not one engine session — and only then record the deferred `artifact_generated`/`card_presented` pair for the card that recompute produced. The first, pre-cash card was real and the user did see it; it simply gets no artifact/presentation row of its own, because it is an intermediate interaction, not the accepted decision artifact. A pair recorded before this row would receipt that superseded card instead, which `verify` now refuses by name.
+- `provided` — always triggers `add-cash` and a recompute, so the card the user actually chooses or skips the rule from is the one rendered *afterward*, never the one that asked. The trace's one `stage=preview` artifact/`card_presented` pair is reserved for that later, settled card, so the row sits **before** it: record `cash_anchor_checked --cash-outcome provided` when the user answers, run `add-cash` and rerun `preview` on the session it returns — keeping THIS session id for the whole trace, since a receipt records one conversation, not one engine session — and only then record the deferred `artifact_generated`/`card_presented` pair for the card that recompute produced. The first, pre-cash card was real and the user did see it; it simply gets no artifact/presentation row of its own, because it is an intermediate interaction, not the accepted decision artifact. A pair recorded before this row would receipt that superseded card instead, which `verify` refuses by name.
 
 This trace shows `provided`. Everything else — questions, answers received, both card stages, rule choice — is copied verbatim, with the preview pair moved to follow the cash row instead of preceding it:
 
@@ -240,7 +238,7 @@ python3 tools/ux_receipt.py event --session-id <ID> --event memory_presented \
 python3 tools/ux_receipt.py event --session-id <ID> --event question_presented --mode native_options
 python3 tools/ux_receipt.py event --session-id <ID> --event answers_received
 # The FIRST preview (holdings-only) renders and is shown here, in one message with the
-# rule choice and the cash question — a real, user-visible step. #663: it is an
+# rule choice and the cash question — a real, user-visible step. It is an
 # intermediate interaction, not the accepted decision artifact, so it gets no
 # artifact_generated/card_presented row of its own; only the cash answer is recorded now.
 # The user gave a balance, so run `review.py add-cash --session-id <ID> --cash <json>` and
@@ -259,7 +257,7 @@ python3 tools/ux_receipt.py event --session-id <ID> --event artifact_generated \
 python3 tools/ux_receipt.py event --session-id <ID> --event card_presented --stage final --mode widget
 ```
 
-The wrap-up has the same shape as Step 5, except **`--memory` must be `pass` or `fail`**: a weekly session does not accept `not_applicable`, and `verify --require-owner-verdict` refuses it — memory continuity is the entire reason this route exists, so it may not be waived as inapplicable. This block is written out in full rather than pointing back at Step 5 precisely because that difference is the part copying would miss, and it only bites at the moment of archiving:
+The wrap-up has the same shape as Step 5, except **`--memory` must be `pass` or `fail`**: a weekly session does not accept `not_applicable`, and `verify --require-owner-verdict` refuses it — memory continuity is the entire reason this route exists, so it may not be waived as inapplicable. This block is written out in full because that difference is the part a copy of Step 5 would miss, and it only bites at the moment of archiving:
 
 ```bash
 # qa-trace: weekly_review
@@ -284,11 +282,11 @@ python3 engine/review.py preview  --session-id <ID> --answers /tmp/answers.json
 python3 engine/review.py finalize --session-id <ID> --answers /tmp/answers.json --narrative /tmp/narrative.json
 ```
 
-Three differences from `first_review` decide the trace, and all three were read off a real run rather than assumed:
+Three differences from `first_review` decide the trace:
 
-- **No cash anchor row.** The route's contract does not carry the #357 pre-flight, because the snapshot envelope declares `cash` inline (`references/ux-receipt.md` says so, and `verify` demands `cash_anchor_checked` only on `first_review` / `weekly_review`). Recording one here proves nothing that the envelope did not already state.
-- **No question rows.** The observed plan came back with `question_queue: []` and `card_plan.question_policy` of `{"min": 0, "max": 0, "route": "snapshot_review"}` — the budget is structurally zero, because a snapshot holds no action history to ask about. Do not manufacture a question or a dynamic surface to fill the gap; the flow says so too.
-- **The rule choice is still reached.** `preview` returned `candidate_rules` with a `grounding` sentence on each candidate, so `--grounding-check-file` is required here exactly as on `first_review`. This is the route's one real control, and it is what `--controls` judges.
+- **No cash anchor row.** The route's contract does not carry the cash-anchor pre-flight, because the snapshot envelope declares `cash` inline (`references/ux-receipt.md` says so, and `verify` demands `cash_anchor_checked` only on `first_review` / `weekly_review`). Recording one here proves nothing that the envelope did not already state.
+- **No question rows.** The plan comes back with `question_queue: []` and `card_plan.question_policy` of `{"min": 0, "max": 0, "route": "snapshot_review"}` — the budget is structurally zero, because a snapshot holds no action history to ask about. Do not manufacture a question or a dynamic surface to fill the gap; the flow says so too.
+- **The rule choice is still reached.** `preview` returns `candidate_rules`, each with a `grounding` sentence when the engine has one, so `--grounding-check-file` is required here exactly as on `first_review`. This is the route's one real control, and it is what `--controls` judges.
 
 Everything else matches `first_review`: both card stages, artifact before card, `--memory not_applicable` (a snapshot review has no prior period to carry, and unlike `weekly_review` this route accepts that value).
 
@@ -301,7 +299,7 @@ python3 tools/ux_receipt.py start --session-id <ID> --client claude --route snap
 
 # 1) No cash_anchor_checked and no question_presented on this route — see above.
 #    The latency marker still belongs here, immediately before `preview`: it is
-#    what makes the wait until the card appears measurable (#236), and on a route
+#    what makes the wait until the card appears measurable, and on a route
 #    that asks nothing it times the authored thesis_updates/narrative going in.
 python3 tools/ux_receipt.py event --session-id <ID> --event answers_received
 
@@ -312,7 +310,7 @@ python3 tools/ux_receipt.py event --session-id <ID> --event artifact_generated \
 python3 tools/ux_receipt.py event --session-id <ID> --event card_presented \
   --stage preview --mode widget
 
-# 3) The rule choice, with its #293 grounding evidence.
+# 3) The rule choice, with its grounding evidence.
 python3 tools/ux_receipt.py event --session-id <ID> --event rule_choice_presented \
   --mode native_options --grounding-check-file <grounding-check.json>
 
@@ -335,7 +333,7 @@ python3 tools/ux_receipt.py verify --session-id <ID> \
 
 ### The `refresh` route: recording the book comes before reviewing it
 
-Once a book exists, a newer holdings view is **not** a review. `prepare --route snapshot_review` refuses any declaration the book-update lane would raise a confirmation for, and names the lane (#530). Its `{"status": "error"}` payload carries this message, observed verbatim on exit code 2:
+Once a book exists, a newer holdings view is **not** a review. `prepare --route snapshot_review` refuses any declaration the book-update lane would raise a confirmation for, and names the lane. Its `{"status": "error"}` payload carries this message on exit code 2:
 
 ```text
 this holdings view has changes only you can settle before the recorded book can
@@ -354,13 +352,13 @@ python3 engine/review.py refresh --snapshot-json /tmp/fomo-kernel-positions.json
   --answers /tmp/refresh-answers.json
 ```
 
-Then come back to the review with the same declaration; the observed rerun of `prepare --route snapshot_review` succeeded and carried `engine_state.snapshot_reconciliation` with `status: reconciled`, because the refresh had already brought the book up to date.
+Then come back to the review with the same declaration; the rerun of `prepare --route snapshot_review` then succeeds and carries `engine_state.snapshot_reconciliation` with `status: reconciled`, because the refresh had already brought the book up to date.
 
 What makes this route's trace different:
 
 - **A refresh creates no session**, so the trace is keyed by the engine's own `refresh_id` (`references/ux-receipt.md`). Declare capabilities only after step 1 has returned one.
 - **No card events at all.** `verify` refuses `artifact_generated`, `card_presented`, `widget_attempt_failed` and `rule_choice_presented` on this route — a card delivery that structurally cannot have happened. What the trace owes instead is a **change surface**.
-- **The question row depends on what the engine raised, and so does the verdict.** Step 1 returns `status: pending_confirmation` with a non-empty `pending_confirmations` (the observed run raised a disappearance and an appearance), or `status: ready` with `pending_confirmations: []` when only small, cash, market or currency differences moved. The first shape presents **one** question covering every raised item — never one per ticker — and its verdict carries `--controls pass|fail`; the second presents no question and its verdict must carry `--controls not_applicable`.
+- **The question row depends on what the engine raised, and so does the verdict.** Step 1 returns `status: pending_confirmation` with a non-empty `pending_confirmations` (for example a disappearance and an appearance), or `status: ready` with `pending_confirmations: []` when only small, cash, market or currency differences moved. The first shape presents **one** question covering every raised item — never one per ticker — and its verdict carries `--controls pass|fail`; the second presents no question and its verdict must carry `--controls not_applicable`.
 - **That `--controls` choice is not recoverable.** Recording `--controls pass` on a refresh that raised nothing is accepted at write time and then rejected by `verify` with `owner controls verdict must be not_applicable on a refresh trace`. The trace is append-only, so the run is void and has to be walked again. Decide it from step 1's `pending_confirmations`, before the verdict, not after.
 
 ```bash
@@ -401,33 +399,33 @@ python3 tools/ux_receipt.py verify --session-id <refresh_id> \
   --require-recorded-owner-verdict --require-owner-verdict --require-timing-integrity --require-findings
 ```
 
-Archive the two receipts separately. The refresh and the review that follows it are one journey and one `--case-id`, so the second archive is `--state-mode continued --parent-run-id <the first run_id>` — a fresh review archived beside a refresh it actually continued would lose exactly the lineage #520 added.
+Archive the two receipts separately. The refresh and the review that follows it are one journey and one `--case-id`, so the second archive is `--state-mode continued --parent-run-id <the first run_id>` — a fresh review archived beside a refresh it actually continued would lose that lineage.
 
-**Three walkthrough rules (from the 2026-07-20 owner_live audit correction; breaking any one voids that QA session)**:
-1. **Declare capability honestly, and try the widget once per session — with the right tool**: the single walkthrough deviation on 2026-07-20 was under-declaring `card_modes` with zero widget attempts. #249's rich HTML card was generated, but the owner saw flat Markdown throughout (the main reason card=fail). A graphical surface must declare `widget`: try the widget first, and on failure record `widget_attempt_failed` before degrading to Markdown — do not let "the artifact was green" stand in for "it was delivered" again.
+**Three walkthrough rules (breaking any one voids that QA session)**:
+1. **Declare capability honestly, and try the widget once per session — with the right tool**: a graphical surface must declare `widget`. Try the widget first, and on failure record `widget_attempt_failed` before degrading to Markdown — do not let "the artifact was green" stand in for "it was delivered".
 
-   **New lesson, 2026-07-21 (see the #230 comments)**: trying the widget does not mean grabbing whatever tool sounds like a renderer. Generic chart/dashboard visualization tools (some MCP `show_widget`/`visualize` tools, for instance) usually carry their own design system and will normalize or strip a large third-party `<style>` block. That is not "the host cannot render rich HTML" — it is the tool behaving as designed, and feeding it the card is using the wrong tool. To verify widget delivery, pick a pipeline that **preserves the supplied `<style>` and HTML as-is without design-system normalization** (for example Claude Code's Artifact-style publishing tools: a page of their own, with no external design system applied). Do not treat a tool as equivalent to what `references/card-delivery.md` calls "graphical surface: render a widget from the engine HTML artifact" merely because its name sounds like "widget". This was mis-diagnosed once — "picked the wrong tool" was reported as "the host has no rendering capability", posted to GitHub as a wrong diagnosis, and corrected only afterwards. Confirm the tool's contract (does it preserve the original CSS?) before concluding.
+   Trying the widget does not mean grabbing whatever tool sounds like a renderer. As of 2026-07-21, generic chart/dashboard visualization tools (some MCP `show_widget`/`visualize` tools, for instance) usually carry their own design system and will normalize or strip a large third-party `<style>` block. That is not "the host cannot render rich HTML" — it is the tool behaving as designed, and feeding it the card is using the wrong tool. To verify widget delivery, pick a pipeline that **preserves the supplied `<style>` and HTML as-is without design-system normalization** (for example Claude Code's Artifact-style publishing tools: a page of their own, with no external design system applied). Do not treat a tool as equivalent to what `references/card-delivery.md` calls "graphical surface: render a widget from the engine HTML artifact" merely because its name sounds like "widget". Confirm the tool's contract (does it preserve the original CSS?) before concluding that the host cannot render rich HTML.
 
    **This tool-selection detail belongs here and must not be promoted into fomo-kernel's `docs/qa-runbook.md`**: that document ships with the public product for any stranger who clones it, and deliberately uses host-agnostic language naming no tool ("if the host can render rich content, try it; on failure degrade to canonical Markdown"). That is correct, because an external user's client has none of these Claude MCP tools and a hardcoded tool name means nothing to them. The operational knowledge of "how to tell whether a tool will normalize your CSS" is a Claude-specific MCP-ecosystem detail and belongs only in this skill (`fomo-qa`, for ting's own maintenance of fomo-kernel, not a public contract). Do not let it slip across while editing the runbook.
-2. **`--language` follows the conversation language**: a Chinese conversation always uses `--language zh-TW` (stated in the product `SKILL.md`'s Language section; forcing `en` in the 2026-07-20 mock session caused the mixed-language output in #262).
-3. **Measure "answered → card"**: the timestamp gap from `answers_received` to the preview `card_presented` is the machine wait in seconds, and it must be reported at wrap-up (#236's re-measurement instrument; `tools/ux_receipt.py --help` is authoritative for events and timestamps).
+2. **`--language` follows the conversation language**: a Chinese conversation always uses `--language zh-TW` (stated in the product `SKILL.md`'s Language section).
+3. **Measure "answered → card"**: the timestamp gap from `answers_received` to the preview `card_presented` is the machine wait in seconds, and it must be reported at wrap-up (`tools/ux_receipt.py --help` is authoritative for events and timestamps).
 
 The complete event sequence lives in the product's `references/interaction-delivery.md` (**arguments per `tools/ux_receipt.py --help`**, which is authoritative over any example written in prose). **What fomo-qa changes is promoting this step from "the product recommends it" to "QA cannot skip it"**, because without a receipt this dogfood leaves no machine-readable evidence and cannot enter eval.
 
-**Known `ux_receipt.py` CLI traps** (2026-07-21; two consecutive walkthroughs hit one each, recorded so they are not repeated):
+**Known `ux_receipt.py` CLI traps**:
 - `artifact_generated` must come **before** the `card_presented` of the same stage, and be recorded the moment the action happens. Backfilling it later — even with correct content — is still judged by `verify` as "card was marked presented before its artifact existed", and an append-only trace has no way back: the session can only be voided and redone. Do not defer receipt-writing to the end of the walkthrough.
-- `start --question-mode`/`--card-mode` declare only the capabilities this client has **in addition** (`native_options`/`widget`). The two universal fallbacks `plain_text`/`markdown_inline` are added by `start` itself ([PR #298](https://github.com/atomchung/fomo-kernel/pull/298), merged), and passing them by hand collides with the `--adapter plain_text` check that only the universal fallbacks may be declared.
+- `start --question-mode`/`--card-mode` declare only the capabilities this client has **in addition** (`native_options`/`widget`). The two universal fallbacks `plain_text`/`markdown_inline` are added by `start` itself, and passing them by hand collides with the `--adapter plain_text` check that only the universal fallbacks may be declared.
 - **`--adapter` defaults to `plain_text`**, and the `plain_text` adapter may declare **only** the universal fallbacks. So "declared `native_options`/`widget` but passed no `--adapter`" fails at the very first `start`. Pass `--adapter validated_widget` for a graphical surface, or `--adapter native_options` for native options without a widget.
-- **The enum cannot express "widget cards but plain-text questions"** ([#337](https://github.com/atomchung/fomo-kernel/issues/337)): `--adapter` binds question capability and card capability into one three-tier enum, and `validated_widget` requires `native_options` as well. On such a host — able to embed HTML but with no native interactive controls — the honest move is to declare `--adapter plain_text` without `widget`, and record "card delivery capability was under-declared" as a finding for that session. **Do not misreport `native_options` to satisfy the enum**: that would make the receipt claim an interactive capability the user never got, which is exactly what #230 exists to prevent.
+- **The enum cannot express "widget cards but plain-text questions"**: `--adapter` binds question capability and card capability into one three-tier enum, and `validated_widget` requires `native_options` as well. On such a host — able to embed HTML but with no native interactive controls — the honest move is to declare `--adapter plain_text` without `widget`, and record "card delivery capability was under-declared" as a finding for that session. **Do not misreport `native_options` to satisfy the enum**: that would make the receipt claim an interactive capability the user never got.
 - `findings_recorded` must come **before** `owner_verdict`: the verdict is the session's last event, and a disposition recorded after it is judged a backfill. This is also why Step 6's episodes are converted during the walkthrough rather than at wrap-up.
 - `response_mode`/`response_provenance` apply only to question kinds that support a private surface, such as `headline_motive`/`add_thesis`. Engine-rendered kinds like `due_revisit`/`rule_breach` must not carry those two fields in their answer object at all; doing so reports "own-words mapping is not enabled for this kind".
 
 The QA mindset — watch for these while walking (record what you find; do not fix it here):
-- Are the questions on target? Anything irrelevant asked, or a key motive missed? (#238's line of inquiry)
-- How long did the machine take from "answered" to "card"? Too long? (#236's 5–10 minute wait; watch how many times preview was rejected and rewritten.) Measure it with rule 3's receipt timestamp gap, not by feel.
+- Are the questions on target? Anything irrelevant asked, or a key motive missed?
+- How long did the machine take from "answered" to "card"? Too long? (Watch how many times preview was rejected and rewritten.) Measure it with rule 3's receipt timestamp gap, not by feel.
 - Does the card copy hallucinate numbers? Is the honest disclosure right? Is the rule connected to actual holdings?
 - Do Taiwanese stocks / mixed markets / cash / date formats hit any edge-case error?
-- **When presenting the candidate rule choice, did the agent quietly reword or invent a `grounding`?** (2026-07-21 lesson, see #293.) `flows/*.md` states that a candidate rule's `grounding` must be quoted verbatim and that a candidate without one may not have a sentence invented for it. **The mechanical check covers only half**: `verify` catches "the engine supplied a `grounding` but the presented text does not contain it verbatim" (#293), comparing against the `--grounding-check-file` you supplied yourself. It **cannot** catch "the candidate had no `grounding` and the agent invented one" — there is no engine text to compare against, and `ux_receipt.py`'s `_grounding_fidelity()` documents that half as an accepted limitation. So the human check remains necessary, aimed at exactly that half: before presenting, read `card_plan.candidate_rules` yourself and confirm each candidate's `grounding` came from the engine and was not written by you.
+- **When presenting the candidate rule choice, did the agent quietly reword or invent a `grounding`?** `flows/*.md` states that a candidate rule's `grounding` must be quoted verbatim and that a candidate without one may not have a sentence invented for it. **The mechanical check covers only half**: `verify` catches "the engine supplied a `grounding` but the presented text does not contain it verbatim", comparing against the `--grounding-check-file` you supplied yourself. It **cannot** catch "the candidate had no `grounding` and the agent invented one" — there is no engine text to compare against, and `ux_receipt.py`'s `_grounding_fidelity()` documents that half as an accepted limitation. So the human check remains necessary, aimed at exactly that half: before presenting, read `card_plan.candidate_rules` yourself and confirm each candidate's `grounding` came from the engine and was not written by you.
 
 ### Step 5 — Close out this route run (the campaign stays open)
 
@@ -463,11 +461,11 @@ This step ends **one route run**, not the conversation. Archive is not a stop si
      --campaign 'issue:#486' --case-id M0-F1 --state-mode fresh
    ```
 
-   The `--case-id` values are defined by the acceptance issue, never invented here: #486's are `M0-F1`…`M0-F6` (one per user flow) since its 2026-07-29 ruling, plus `M0-T01`…`M0-T10` for the contract lane. Read the issue before the first archive of a campaign — an id that looks plausible but names nothing leaves a manifest that cannot be checked off against anything.
+   The `--case-id` values are defined by the acceptance issue, never invented here: as of 2026-07-29, #486's are `M0-F1`…`M0-F6` (one per user flow), plus `M0-T01`…`M0-T10` for the contract lane. Read the issue before the first archive of a campaign — an id that looks plausible but names nothing leaves a manifest that cannot be checked off against anything.
 
    Archiving produces a **run manifest** (`<run_id>.manifest.json`) recording this dogfood's full provenance: `engine_version` (`main-<sha>`), `agent.client`, `agent.model`, `agent.effort`, `data_source`, `human_involvement`, `owner_verdict`, `receipt_sha256`, plus **which acceptance case this session actually tested**: `campaign` / `case_id` / `state_mode` / `parent_run_id`. Model and effort are host labels supplied explicitly at archive time; the script never infers them from the client name, the commit, the chat context, or anything downstream. Missing any of them, or filling `unknown`/`default`, makes archive fail closed. This lets the report compare models and efforts separately rather than averaging them into one pass rate.
 
-   **Case and state lineage (#520)**: a receipt that verifies proves only that this session's presentation was real. It cannot say which case was tested or what state it started from. Without that, two individually valid manifests still cannot prove #486's matrix was walked rather than the same easy case run five times. So archive now enforces three things:
+   **Case and state lineage**: a receipt that verifies proves only that this session's presentation was real. It cannot say which case was tested or what state it started from. Without that, two individually valid manifests still cannot prove #486's matrix was walked rather than the same easy case run five times. So archive enforces three things:
 
    | Argument | Value | Rule |
    |---|---|---|
@@ -476,7 +474,7 @@ This step ends **one route run**, not the conversation. Archive is not a stop si
    | `--state-mode` | `fresh` \| `continued` | Did this session start from a clean root, or continue an archived earlier run |
    | `--parent-run-id` | the previous session's `run_id` | **Only** for `continued`; supplying it on `fresh` is refused |
 
-   `--parent-run-id` must name a manifest that **actually exists** in the receipt directory, or archive fails closed — lineage pointing at nothing is a claim, not evidence. Conversely it is only an evidence chain, not proof that every byte of state is correct (that belongs to #492, if operational evidence ever justifies it). Old manifests are never backfilled or retro-attributed; `report` labels them `legacy-unattributed`.
+   `--parent-run-id` must name a manifest that **actually exists** in the receipt directory, or archive fails closed — lineage pointing at nothing is a claim, not evidence. Conversely it is only an evidence chain, not proof that every byte of state is correct. Old manifests are never backfilled or retro-attributed; `report` labels them `legacy-unattributed`.
 
 2. **Report which version was tested**: `main@<sha>` + data source + the simulated user state + the "answered → card" seconds (the receipt timestamp gap).
 3. **What you found**: write each one down. If it is genuinely a bug or a gap, check `gh issue list` for duplicates and open an issue (do not fix it in the dogfood worktree). **If this session used real trade data, every issue or comment draft must pass guardrail 5's `privacy_lint.py` with exit 0 before posting.** Add a row for significant conclusions following `EVALS.md`'s "Regression record" convention (the receipt is the machine-readable ledger, `EVALS.md` the human-readable one).
@@ -489,7 +487,7 @@ This step ends **one route run**, not the conversation. Archive is not a stop si
 
 ### Step 6 — Convert every miss into a replayable episode (gate 7, the last step before the verdict)
 
-**`archive-receipt` enforces this step**: a receipt with no `findings_recorded` row cannot be archived, so recording where each miss went is part of the walkthrough rather than a wrap-up chore. An issue records that something went wrong; only an episode makes it replayable (#417).
+**`archive-receipt` enforces this step**: a receipt with no `findings_recorded` row cannot be archived, so recording where each miss went is part of the walkthrough rather than a wrap-up chore. An issue records that something went wrong; only an episode makes it replayable.
 
 Convert each miss into an episode **on the spot**, as you find it, rather than batching them at wrap-up: the agent's exact wording is the asset, and it is gone by the next session.
 
@@ -513,9 +511,9 @@ Three things not to get wrong:
 
 ## Continuing in the same campaign
 
-After a route run is archived, **stay here**. The maintainer is now a user with a book, and the next thing they say is the next route run's trigger. Do not re-run Steps 0–3, do not reset, and do not treat the archive as the end of testing (#544: walking four routes used to cost four full ceremonies in four sessions, which is why routes went unwalked).
+After a route run is archived, **stay here**. The maintainer is now a user with a book, and the next thing they say is the next route run's trigger. Do not re-run Steps 0–3, do not reset, and do not treat the archive as the end of testing.
 
-Route the request to the **real command**. Answering it by hand — recomputing holdings, tallying a position, estimating what an addition would do — produces zero evidence and is the exact failure #543 recorded: an ad hoc portfolio question answered outside any lifecycle, 34 turns and a chart nobody asked for.
+Route the request to the **real command**. Answering it by hand — recomputing holdings, tallying a position, estimating what an addition would do — produces zero evidence.
 
 | The maintainer says | Route run to start | Lineage |
 |---|---|---|
@@ -529,7 +527,7 @@ Every continued run archives with `--state-mode continued --parent-run-id <the p
 
 ### The `consider` route: a receipted pre-trade evaluation
 
-`review.py consider` (#544 Slice B, on #479's TradeEvaluation contract) renders no card and mutates no book. Run the real command against the campaign's own book, so the engine computes the consequence rather than the agent estimating it:
+`review.py consider` (the pre-trade `TradeEvaluation`) renders no card and mutates no book. Run the real command against the campaign's own book, so the engine computes the consequence rather than the agent estimating it:
 
 ```bash
 python3 engine/review.py consider --premise /tmp/fomo-kernel-premise.json \
@@ -582,7 +580,7 @@ python3 tools/ux_receipt.py verify --session-id <evaluation_id> \
   --require-recorded-owner-verdict --require-owner-verdict --require-timing-integrity --require-findings
 ```
 
-`--challenge-check-file` points at a transient JSON that never enters the trace, the same nature as `--grounding-check-file`. It pairs the `challenge` block **from the `consider` call's own stdout** with the exact answer text shown, and — since #767 — that same call's `sector_display` block:
+`--challenge-check-file` points at a transient JSON that never enters the trace, the same nature as `--grounding-check-file`. It pairs the `challenge` block **from the `consider` call's own stdout** with the exact answer text shown, and that same call's `sector_display` block:
 
 ```json
 {
@@ -620,11 +618,11 @@ python3 tools/ux_receipt.py verify --session-id <evaluation_id> \
 }
 ```
 
-Paste the challenge verbatim from stdout — a truncated paste is refused rather than read as a smaller obligation, and a `machine_state` value appearing in `presented_text` refuses the evidence outright (#830: those are for a mechanical comparison and are never shown to a person) — and the recorded `challenge_hash` stays auditable afterward: the block is a pure function of the persisted evaluation row, so anyone holding the root can recompute it. `sector_display` is captured from that same stdout the same way, verbatim; it is required whenever the response carried one, and an empty `{}` is how you paste a response that named no largest sector — omitting the key entirely is refused, not read as nothing to check. `disclosures_display` (#739) is a real sibling field on the same stdout — the localized text for each `consequence.disclosures` key, e.g. `cost_basis` above — included here so the pasted check file matches the real response shape; unlike `sector_display`, it is not yet read or verified by this tool, so its presence or absence changes nothing about what `verify` decides.
+Paste the challenge verbatim from stdout — a truncated paste is refused rather than read as a smaller obligation, and a `machine_state` value appearing in `presented_text` refuses the evidence outright (those are for a mechanical comparison and are never shown to a person) — and the recorded `challenge_hash` stays auditable afterward: the block is a pure function of the persisted evaluation row, so anyone holding the root can recompute it. `sector_display` is captured from that same stdout the same way, verbatim; it is required whenever the response carried one, and an empty `{}` is how you paste a response that named no largest sector — omitting the key entirely is refused, not read as nothing to check. `disclosures_display` is a real sibling field on the same stdout — the localized text for each `consequence.disclosures` key, e.g. `cost_basis` above — included here so the pasted check file matches the real response shape; unlike `sector_display`, it is not yet read or verified by this tool, so its presence or absence changes nothing about what `verify` decides.
 
-What the machine half checks, and what stays with the owner's `comprehension` verdict: load-bearing numbers as digits at any display precision, and rule-collision texts / user quotes / excluded-holding tickers verbatim, are machine-decidable; engine-vocabulary strings, boolean triggers, and `unchecked` keys reach the user only as prose in the conversation's language, which no offline comparison can judge — that half is what `comprehension` is for. Whether the answer named the sector in `sector_display`'s own words, rather than in the engine's raw internal label, is also machine-decidable (#767) and never depends on which language the answer used. See `references/ux-receipt.md` ("The second card-free route") for the complete split.
+What the machine half checks, and what stays with the owner's `comprehension` verdict: load-bearing numbers as digits at any display precision, and rule-collision texts / user quotes / excluded-holding tickers verbatim, are machine-decidable; engine-vocabulary strings, boolean triggers, and `unchecked` keys reach the user only as prose in the conversation's language, which no offline comparison can judge — that half is what `comprehension` is for. Whether the answer named the sector in `sector_display`'s own words, rather than in the engine's raw internal label, is also machine-decidable and never depends on which language the answer used. See `references/ux-receipt.md` ("The second card-free route") for the complete split.
 
-Archive like any other continued route run in this campaign: `--state-mode continued --parent-run-id <the preceding accepted run_id>`, same `--campaign`. A `consider` receipt is now formal evidence, and the old "exploratory only" caveat is gone — but a run whose trace fails `verify` is still void and has to be walked again with a fresh receipt; the trace is append-only, so there is no repair.
+Archive like any other continued route run in this campaign: `--state-mode continued --parent-run-id <the preceding accepted run_id>`, same `--campaign`. A `consider` receipt is formal evidence, and a run whose trace fails `verify` is void and has to be walked again with a fresh receipt; the trace is append-only, so there is no repair.
 
 The resolution boundary: `acted` records the user's own word via `consider --resolve`, never a fill. The invitation only ever asks whether the user says they acted, declined, or modified — do not read a recorded `acted` as proof a broker order executed.
 
@@ -642,7 +640,7 @@ Archive's `human` argument decides whether a run counts as real experience evide
 | `agent_with_owner_verdict` | The AI walked the flow; you gave only the final verdict | Partly human |
 | `agent_simulated` (**default**) | Fully AI-simulated, no human | ❌ Contract only, **not an experience signal** |
 
-Unmarked means `agent_simulated` — better to understate credibility than to quietly pass off "the AI attested to itself" as "the user said it was good" (#230's core lesson).
+Unmarked means `agent_simulated` — better to understate credibility than to quietly pass off "the AI attested to itself" as "the user said it was good".
 
 To see pass-rate trends across versions and levels of human involvement: