[dnth]

Intent

Stop overstated claims with two small text additions in Firstmate's existing owners.
(1) A claim about cause, measurement, completion, or safety carries one confidence word: ran (observed directly: command output, test run, live check), cited (backed by a named file:line, log, or artifact), inferred (reasoned from evidence, not observed), or guess.
(2) A claim may be labelled ran or cited only when the evidence is named next to it; otherwise it is inferred or guess.
Where: (a) the crewmate brief scaffold's acceptance-evidence guidance in bin/fm-brief.sh, so every new ship and scout worker sees it; (b) AGENTS.md section 9 (captain-facing etiquette), one or two sentences, preserving the talk-in-outcomes rule so the words read naturally to the captain, not as jargon; keep AGENTS.md concise per its Maintaining-this-file rules; update only a doc that would otherwise go stale describing the brief text.
Constraints: no new script, gate, checker change, or behaviour change; do not build the rest of data/fm-pstack-bigger-wins/report.md R3; no other files.
Acceptance criteria: AC1 a freshly scaffolded ship brief (--mode no-mistakes) and scout brief (--scout) both contain the four confidence words and the citation rule in their evidence/report guidance, proven by running the scaffold; AC2 AGENTS.md section 9 states the confidence-word and citation rule in at most three sentences without adding internal jargon, proven by the diff; AC3 no new script, gate, check, or behaviour, and the receipt checker, PR check, and all existing tests are unchanged and pass, with the diff touching only bin/fm-brief.sh text, AGENTS.md, and any doc describing the brief text.
Firstmate decision [key=ac3-test-env]: 10 affected suites fail identically on unmodified main commit 338a7ac for environment reasons (missing grok/kimi/pi/omp harnesses, Bun stringWidth version, /tmp fixture ownership), not because of this diff; AC3 is judged from the PR's green CI lanes where those harnesses exist, and the AC3 success receipt is re-recorded from that result.

What Changed

• Add shared claim-confidence guidance to ship acceptance evidence and scout reports: ran, cited, inferred, or guess, with evidence named beside any ran or cited claim.
• Add the same rule to captain-facing etiquette in AGENTS.md, preserving plain-English outcome reporting.

Risk Assessment

✅ Low: The change adds concise guidance to the two required owners, reuses the scaffold text for ship and scout output, and leaves gates, checkers, and tests unchanged.

Testing

Live ship and scout scaffolding, overwrite guards, and focused receipt-check tests passed. An initial missing disposable data directory was corrected before re-driving. Generated Markdown provides the visible evidence; no GUI changed. Broad regression and CI remain with the outer executor under the recorded AC3 decision.

• Live validation: ✅ go - 3 of 3 scenarios driven live against the product

Scenario	Result	Live	Evidence
Scaffold a no-mistakes ship brief and receive all four confidence words plus the adjacent-evidence rule in acceptance guidance	✅ pass	live	Generated ship brief; scaffold-live-transcript.txt
Scaffold a scout brief and receive all four confidence words plus the adjacent-evidence rule in report guidance	✅ pass	live	Generated scout brief; scaffold-live-transcript.txt
Repeat either scaffold for an existing task and receive a refusal with the original brief preserved	✅ pass	live	scaffold-live-transcript.txt

Evidence: Live scaffold commands, generated guidance, and overwrite refusals

$ FM_HOME=<isolated-home> bash bin/fm-brief.sh ship-confidence disposable-project --mode no-mistakes
scaffolded: ~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/ship-confidence/brief.md (ship, mode=no-mistakes; replace {TASK} and every {ACCEPTANCE CRITERION})
exit=0

# Acceptance evidence
Before reporting implementation complete, record at least one compact receipt for every acceptance criterion with `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-receipt.sh ship-confidence <criterion> <type> <summary> <result> --outcome <success|failure|negative|zero|skipped|empty|placeholder|weak|accepted-blocked> [options]`.
Only `--outcome success` evidences a criterion; `accepted-blocked` requires a non-empty `--captain-exception "<text>"` (the date plus the captain's own words or the board key that holds them) and accounts for the criterion without evidencing it; every other structured outcome records an unevidenced negative or inconclusive result.
A task with any accepted-blocked criterion is never auto-merged; state those criteria and their exception references plainly in the PR description.
Every claim about a cause, a measurement, completion, or safety carries one confidence word: `ran` (observed directly: command output, a test run, a live check), `cited` (a named file:line, log, or artifact backs it), `inferred` (reasoned from evidence, not observed), or `guess`.
Call a claim `ran` or `cited` only when the evidence is named next to it; otherwise it is `inferred` or `guess`.
Run `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-receipt-check.sh ship-confidence` and do not append `done:` unless its JSON status is `complete`.
The latest receipt per criterion decides it: when a finding or a later test shows a criterion unsatisfied, record a `--outcome failure` receipt for it, fix, and record a fresh `--outcome success`.
Receipts establish that you accounted for every declared criterion; they certify nothing about review, CI, No-Mistakes completion, or merge readiness, so keep summaries and results compact and point to commands or artifacts when useful.
When a cited artifact lives inside this scratch worktree (for example `.qa/evidence/<run_id>/report.json`), copy it into `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/ship-confidence/artifacts/` (gitignored, survives teardown) before `done:` and cite the copied path; worktree-relative paths die with the worktree.


$ repeat scaffold for existing ship-confidence
error: ship task already exists
error: could not atomically scaffold ship task: ~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/ship-confidence
exit=1

$ FM_HOME=<isolated-home> bash bin/fm-brief.sh scout-confidence disposable-project --scout
scaffolded: ~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/scout-confidence/brief.md (scout; replace {TASK})
exit=0

# Definition of done
Write your findings to `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/scout-confidence/report.md`.
The report must stand alone: what you did, what you found, the evidence (commands run, output, file:line references), and what you recommend.
Every claim about a cause, a measurement, completion, or safety carries one confidence word: `ran` (observed directly: command output, a test run, a live check), `cited` (a named file:line, log, or artifact backs it), `inferred` (reasoned from evidence, not observed), or `guess`.
Call a claim `ran` or `cited` only when the evidence is named next to it; otherwise it is `inferred` or `guess`.
Before reporting done, read and follow `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.agents/skills/captain-hold-lifecycle/SKILL.md` and pass its shared completion gate for the report and any visual review.
When the report is complete, append `done: {one-line conclusion} - report at data/scout-confidence/report.md` to the status file and stop.
If your findings reveal work that should ship (e.g. you reproduced a bug and the fix is clear), say so in the report; firstmate may promote this task in place, and you would then receive mode-specific ship instructions as a follow-up message.


$ repeat scaffold for existing scout-confidence
error: ~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/scout-confidence/brief.md already exists
exit=1

Evidence: Generated ship brief

You are a crewmate: an autonomous worker agent managed by firstmate. Work on your own; do not wait for a human.

# Task
{TASK}

# Acceptance criteria
- AC1: {ACCEPTANCE CRITERION}

# Herdr lifecycle declaration - NOT ENABLED
**HARD SAFETY GATE:** this scaffold cannot inspect the task text filled in above.
If the task will start, stop, delete, restart, profile, or otherwise drive Herdr lifecycle behavior, stop and regenerate the brief with `--herdr-lab` before dispatch.
Do not add Herdr lifecycle commands to this unguarded brief by hand.

# Setup
You are in a disposable git worktree of disposable-project, at a detached HEAD on a clean default branch.

**Verify isolation before anything else.** Run `pwd -P` and `git rev-parse --show-toplevel`; both must resolve to the disposable task worktree you were launched in, such as a treehouse pool path or an Orca-managed worktree, not the primary checkout firstmate operates from.
The path check is authoritative: `git rev-parse --git-dir` and `git rev-parse --git-common-dir` can help inspect the repo, but they do not prove you are outside the primary checkout.
If the top-level path is the primary checkout or not the worktree you were launched in, STOP - do not branch or commit here - append `blocked: launched in primary checkout, not an isolated worktree` to the status file and stop.

1. First action: create your branch: `git checkout -b fm/ship-confidence`
2. Run `no-mistakes doctor`; if it reports the repo is not initialized here, run `no-mistakes init`.

# Rules
1. Never push to the default branch. Never merge a PR.
2. Stay inside this worktree; modify nothing outside it.
3. Use gh-axi for GitHub operations and chrome-devtools-axi for browser operations.
4. Report status by appending one line:
   `echo "{state}: {one short line}" >> '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/ship-confidence.status'`
   States: working, needs-decision, blocked, paused, done, failed.
   Each append wakes firstmate, so report sparingly: only phase changes a supervisor
   would act on (setup done, bug reproduced, fix implemented, validation passed) and the
   needs-decision/blocked/paused/done/failed states. No step-by-step FYI progress lines;
   firstmate reads your pane for that.
   A mid-task `working:` line (including setup complete) is nonterminal: do not end the
   turn after it; continue the same stage until a defined `done:` gate under Definition of done.
   Whenever a turn ends while the task's board row is still in flight, the last status line
   must be terminal (`done:`, `failed:`, `needs-decision:`, `blocked:`) or `paused:`,
   landing within 600s of turn-end - never end on silence or a bare `working:`.
   Firstmate's watcher escalates a pane left idle past that bound with its row still in
   flight as `idle-with-open-work`. A `done:` is the delivery claim and must name the
   artifact the Definition of done requires; completion recording and teardown refuse a
   `done:` that carries none.
   Use `paused: {why}` - distinct from `blocked:` - ONLY when you are deliberately idling on a
   known external wait you expect to clear on its own (an upstream release, a rate-limit reset,
   a scheduled window): firstmate then leaves your idle pane alone and rechecks it on a long
   cadence instead of treating it as a possible wedge. Use `blocked:` when you are stuck and need help.
5. If you hit the same obstacle twice, append `blocked: {why}` and stop; firstmate will help.
6. If a decision belongs above the implementation worker (product choices, destructive actions, ask-user findings),
   append `needs-decision: {summary of options}` and stop. Firstmate will reply with the decision.
   A decision or blocker you opened stays open until a `resolved` line carrying its exact key lands; a later `done:` or `working:` line never closes it, even when the answer is what started that work.
   Firstmate's reply normally writes that closing line at answer time; when a blocker or wait clears WITHOUT a firstmate reply, append `resolved: {how it cleared}` yourself (same `[key=<slug>]` if you opened it with one) as you resume.
7. Never stop, restart, or update the shared `no-mistakes` daemon - it is one instance serving
   every lane/home, so restarting it kills other lanes' in-flight pipeline runs. On ANY no-mistakes
   daemon error, append `blocked: {the daemon error}` and stop; only firstmate manages the daemon.

# Firstmate instruction inbox
Firstmate steers you through durable message files in '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/ship-confidence.inbox'.
When a terminal message says an instruction is waiting there - and at any natural checkpoint when you are unsure - list '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/ship-confidence.inbox'/*.msg, read and act on each message in numeric order, then acknowledge each handled message by moving it: `mv '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/ship-confidence.inbox'/NNN.msg '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/ship-confidence.inbox'/handled/`.
The move IS the acknowledgement: without it firstmate rings again and eventually treats you as stuck. An empty or absent inbox needs no action.

# Delegating read-only scouting
When the task benefits from bounded read-only scouting - mapping files, tracing call paths, gathering evidence, or broad pattern searches - delegate that scouting to native subagents instead of grinding through it solo.
On OMP, `omp agents unpack` ships the `scout`/`task`/`reviewer`/`security-reviewer`/`sonic` subagents; `scout` is read-only, `@smol`, and built for parallel search - prefer it for this work.
On other harnesses, use the read-only subagent surface the harness provides; where it provides none, do the scouting yourself.
Subagents scout only: keep every edit, verification run, and evidence receipt in your own main trajectory. You stay accountable for integrating and verifying their output and for recording the receipts your deliverable requires.

# Project memory
If `AGENTS.md` or `CLAUDE.md` already exists, or if this task produced durable project-intrinsic knowledge, run `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-ensure-agents-md.sh .` in the worktree.
Record only project knowledge useful to almost every future session.
For anything the codebase already shows, prefer a pointer to the authoritative file, command, or doc over copying the detail.
If you touch a project `AGENTS.md` that lacks `## Maintaining this file`, add that short self-governance section from `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-ensure-agents-md.sh` in the same pass.
Keep it proportionate: skip `AGENTS.md` edits for trivial tasks that produced no durable project knowledge.

# Acceptance evidence
Before reporting implementation complete, record at least one compact receipt for every acceptance criterion with `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-receipt.sh ship-confidence <criterion> <type> <summary> <result> --outcome <success|failure|negative|zero|skipped|empty|placeholder|weak|accepted-blocked> [options]`.
Only `--outcome success` evidences a criterion; `accepted-blocked` requires a non-empty `--captain-exception "<text>"` (the date plus the captain's own words or the board key that holds them) and accounts for the criterion without evidencing it; every other structured outcome records an unevidenced negative or inconclusive result.
A task with any accepted-blocked criterion is never auto-merged; state those criteria and their exception references plainly in the PR description.
Every claim about a cause, a measurement, completion, or safety carries one confidence word: `ran` (observed directly: command output, a test run, a live check), `cited` (a named file:line, log, or artifact backs it), `inferred` (reasoned from evidence, not observed), or `guess`.
Call a claim `ran` or `cited` only when the evidence is named next to it; otherwise it is `inferred` or `guess`.
Run `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/bin/fm-receipt-check.sh ship-confidence` and do not append `done:` unless its JSON status is `complete`.
The latest receipt per criterion decides it: when a finding or a later test shows a criterion unsatisfied, record a `--outcome failure` receipt for it, fix, and record a fresh `--outcome success`.
Receipts establish that you accounted for every declared criterion; they certify nothing about review, CI, No-Mistakes completion, or merge readiness, so keep summaries and results compact and point to commands or artifacts when useful.
When a cited artifact lives inside this scratch worktree (for example `.qa/evidence/<run_id>/report.json`), copy it into `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/ship-confidence/artifacts/` (gitignored, survives teardown) before `done:` and cite the copied path; worktree-relative paths die with the worktree.

# Definition of done
Delivery contract: mode=no-mistakes
The task is complete only when committed on your branch and every declared acceptance criterion has a receipt.
When you believe it is complete, append `done: {summary}` to the status file and stop.
Firstmate will then start full No-Mistakes validation on this worker.

You drive no-mistakes by responding to its gates, not by implementing fixes.
Follow the guidance no-mistakes itself provides for the mechanics: it loads when you invoke /no-mistakes, and `no-mistakes axi run --help` plus the `help` lines in each `axi` response are authoritative and version-matched to the installed binary.
When starting no-mistakes, make `--intent` preserve all relevant content from this brief's `# Task` section plus every later accepted Firstmate requirement, clarification, constraint, exclusion, and supersession, carrying only each requirement's current accepted form; retain direct requirements instead of substituting a diff summary, and exclude generic operational, status, delivery, and other scaffold boilerplate unless it is task-specific.
Do not hand-edit, commit, or fix findings yourself while a run is active; fix ordinary findings only after Firstmate directs the supported abort and branch-custody return sequence, and when a finding shows a criterion unsatisfied, record its failure receipt before the fix and a fresh success after it.
Firstmate's PR-ready helper reads No-Mistakes' own status for your run - branch, PR URL, full head SHA, and outcome - so never push foreign commits over the pipeline's head.

Two firstmate-specific rules layer on top of that guidance:
- ask-user findings are never yours to answer: escalate to firstmate (rule 6) and stop.
  Report each parked gate as `needs-decision [key=nm-<run>-<step>]: ask-user findings=<id1>,<id2>,...` naming every ask-user finding id the gate presents; PR registration and done acceptance refuse any recorded ask-user resolution that lacks a matching firstmate `resolved [key=nm-<run>-<step>]` record.
  Firstmate applies `ask-user-authority` and obtains any required captain decision.
  When the decision comes back, feed it to the gate with `no-mistakes axi respond` and let the pipeline apply it - do not route the question to "the user" or implement the fix yourself.
- Avoid `--yes`: it would silently bypass firstmate's authority check and any required captain escalation.

After /no-mistakes reports CI green (the CI-ready return point - do not wait for it to keep monitoring in the background until merge), append `done: PR {url} checks green` to the status file and stop. You are finished.
The `done:` line must carry the PR URL - it is the delivery artifact - and PR registration and teardown refuse a `done:` that names none.

Evidence: Generated scout brief

You are a crewmate: an autonomous worker agent managed by firstmate. Work on your own; do not wait for a human.

# Task
{TASK}

# Herdr lifecycle declaration - NOT ENABLED
**HARD SAFETY GATE:** this scaffold cannot inspect the task text filled in above.
If the task will start, stop, delete, restart, profile, or otherwise drive Herdr lifecycle behavior, stop and regenerate the brief with `--herdr-lab` before dispatch.
Do not add Herdr lifecycle commands to this unguarded brief by hand.

# Setup
You are in a disposable git worktree of disposable-project, at a detached HEAD on a clean default branch.
This is a SCOUT task: the deliverable is a written report, not a PR.
The worktree is your laboratory - install, run, edit, and make scratch commits freely; all of it is discarded at teardown.
The report is the only thing that survives, so anything worth keeping must be in it.

# Rules
1. Never push to any remote and never open a PR.
2. Stay inside this worktree; the only files you may write outside it are the report and the status file below.
3. Use gh-axi for GitHub operations and chrome-devtools-axi for browser operations.
4. Report status by appending one line:
   `echo "{state}: {one short line}" >> '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/scout-confidence.status'`
   States: working, needs-decision, blocked, paused, done, failed.
   Each append wakes firstmate, so report sparingly: only phase changes a supervisor
   would act on and the needs-decision/blocked/paused/done/failed states. No step-by-step
   FYI progress lines; firstmate reads your pane for that.
   Whenever a turn ends while the task's board row is still in flight, the last status line
   must be terminal (`done:`, `failed:`, `needs-decision:`, `blocked:`) or `paused:`,
   landing within 600s of turn-end - never end on silence or a bare `working:`.
   Firstmate's watcher escalates a pane left idle past that bound with its row still in
   flight as `idle-with-open-work`. A `done:` is the delivery claim and must name the
   report path; teardown refuses a `done:` that carries none.
   Use `paused: {why}` - distinct from `blocked:` - ONLY when you are deliberately idling on a
   known external wait you expect to clear on its own (an upstream release, a rate-limit reset):
   firstmate then leaves your idle pane alone and rechecks it on a long cadence instead of
   treating it as a possible wedge. Use `blocked:` when you are stuck and need help.
5. If you hit the same obstacle twice, append `blocked: {why}` and stop; firstmate will help.
6. If a decision belongs to a human (product choices, destructive actions),
   append `needs-decision: {summary of options}` and stop. Firstmate will reply with the decision.
   A decision or blocker you opened stays open until a `resolved` line carrying its exact key lands; a later `done:` or `working:` line never closes it, even when the answer is what started that work.
   Firstmate's reply normally writes that closing line at answer time; when a blocker or wait clears WITHOUT a firstmate reply, append `resolved: {how it cleared}` yourself (same `[key=<slug>]` if you opened it with one) as you resume.
7. Never stop, restart, or update the shared `no-mistakes` daemon - it is one instance serving
   every lane/home, so restarting it kills other lanes' in-flight pipeline runs. On ANY no-mistakes
   daemon error, append `blocked: {the daemon error}` and stop; only firstmate manages the daemon.

# Firstmate instruction inbox
Firstmate steers you through durable message files in '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/scout-confidence.inbox'.
When a terminal message says an instruction is waiting there - and at any natural checkpoint when you are unsure - list '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/scout-confidence.inbox'/*.msg, read and act on each message in numeric order, then acknowledge each handled message by moving it: `mv '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/scout-confidence.inbox'/NNN.msg '~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/state/scout-confidence.inbox'/handled/`.
The move IS the acknowledgement: without it firstmate rings again and eventually treats you as stuck. An empty or absent inbox needs no action.

# Delegating read-only scouting
When the task benefits from bounded read-only scouting - mapping files, tracing call paths, gathering evidence, or broad pattern searches - delegate that scouting to native subagents instead of grinding through it solo.
On OMP, `omp agents unpack` ships the `scout`/`task`/`reviewer`/`security-reviewer`/`sonic` subagents; `scout` is read-only, `@smol`, and built for parallel search - prefer it for this work.
On other harnesses, use the read-only subagent surface the harness provides; where it provides none, do the scouting yourself.
Subagents scout only: keep every edit, verification run, and evidence receipt in your own main trajectory. You stay accountable for integrating and verifying their output and for recording the receipts your deliverable requires.

# Definition of done
Write your findings to `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.confidence-live-_gfl0134/data/scout-confidence/report.md`.
The report must stand alone: what you did, what you found, the evidence (commands run, output, file:line references), and what you recommend.
Every claim about a cause, a measurement, completion, or safety carries one confidence word: `ran` (observed directly: command output, a test run, a live check), `cited` (a named file:line, log, or artifact backs it), `inferred` (reasoned from evidence, not observed), or `guess`.
Call a claim `ran` or `cited` only when the evidence is named next to it; otherwise it is `inferred` or `guess`.
Before reporting done, read and follow `~/.no-mistakes/worktrees/dd71c22cc6d7/01M59PN5A7N5Y3Z9VZEST3VWEB/.agents/skills/captain-hold-lifecycle/SKILL.md` and pass its shared completion gate for the report and any visual review.
When the report is complete, append `done: {one-line conclusion} - report at data/scout-confidence/report.md` to the status file and stop.
If your findings reveal work that should ship (e.g. you reproduced a bug and the fix is clear), say so in the report; firstmate may promote this task in place, and you would then receive mode-specific ship instructions as a follow-up message.

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

• Live validation: ✅ go - 3 of 3 scenarios driven live against the product

Scenario	Result	Live	Evidence
Scaffold a no-mistakes ship brief and receive all four confidence words plus the adjacent-evidence rule in acceptance guidance	✅ pass	live	Generated ship brief; scaffold-live-transcript.txt
Scaffold a scout brief and receive all four confidence words plus the adjacent-evidence rule in report guidance	✅ pass	live	Generated scout brief; scaffold-live-transcript.txt
Repeat either scaffold for an existing task and receive a refusal with the original brief preserved	✅ pass	live	scaffold-live-transcript.txt

• Ran bash bin/fm-brief.sh ship-confidence disposable-project --mode no-mistakes with an isolated workspace-local FM_HOME and inspected the generated output contract.
• Ran bash bin/fm-brief.sh scout-confidence disposable-project --scout with the same isolated FM_HOME and inspected the generated output contract.
• Repeated both scaffold commands and verified nonzero exits with byte-for-byte preservation of existing briefs.
• Ran bash tests/fm-receipt-check.test.sh; exited 0.
• Reviewed the base-to-target diff: only AGENTS.md and bin/fm-brief.sh changed; section 9 adds two sentences and preserves the outcomes rule.
• Removed the disposable home and confirmed a clean working tree.

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.