docs(agents): require succinct status reports

[clca]

Intent

Add exactly ONE line the captain wrote himself to firstmate's AGENTS.md, in section 1, immediately after 'Do not force it into every sentence, but never send a response with zero direct address.' and immediately before 'Use light nautical seasoning only when it fits: ...'. The inserted line is verbatim:

'Be very succinct in report status: state the problem/current status in a short 1-2 line sentence, list options/proposals/recommendations as a bulleted list always using short sentences. Avoid being verbose.'

PROVENANCE AND CONSTRAINTS, which govern review of this change: the captain wrote this sentence himself. It is his own instruction about how he wants to be spoken to, and it ships as he wrote it. The only authorised edits were two spelling corrections already applied ('succint'->'succinct', 'bulletted'->'bulleted'). Deliberate, explicit, captain-imposed exclusions - do NOT flag these as defects and do NOT change them:

• Do not rephrase, tighten, split, or reword the sentence.
• Do not make it match the surrounding house style (e.g. the repo's one-sentence-per-line convention is deliberately not a reason to split this line; the captain wants it as one line).
• Do not add a cross-reference to section 9, even though section 9 covers related captain-facing escalation and outcome phrasing. The captain deliberately placed this line in section 1.
• Do not move the line elsewhere in the file.
• Do not fix, improve, or touch anything else in AGENTS.md, including whitespace on adjacent lines.

Acceptance criteria set by the captain: git diff shows exactly one added line and zero other changes; the line reads exactly as written above; the repo's own checks pass. The test suite has KNOWN pre-existing failures unrelated to this change, being fixed by a separate worker in parallel - those are out of scope and must not be chased or fixed here. Before/after evidence was measured in this worktree: bin/fm-lint.sh, bin/fm-doc-audience-check.sh, and the six AGENTS.md-content-sensitive suites (startup-memory-budget, documentation-audiences, supervision-instructions, harness-adapter-references, ensure-agents-md, session-start) all pass identically before and after the edit.

If review believes the wording is wrong, that is a decision for the captain, not something to fix in the diff.

What Changed

• Added one line to section 1 of AGENTS.md directing agents to keep status reports succinct: state the problem or current status in a 1-2 line sentence and list options, proposals, and recommendations as a bulleted list of short sentences.
• The line is placed immediately after the mandatory direct-address guidance and before the nautical-seasoning guidance; no other content in AGENTS.md was touched.

Risk Assessment

✅ Low: The change is a single added documentation line in AGENTS.md that matches the authoritative intent verbatim and in the required position, with no code paths, generated artifacts, or size/lint-sensitive consumers affected.

Testing

Verified the three acceptance criteria directly — the diff is exactly one added line with zero other changes, the line matches the captain's text byte for byte, and the six AGENTS.md-content-sensitive suites (startup-memory-budget, documentation-audiences, supervision-instructions, harness-adapter-references, ensure-agents-md, session-start) pass with zero failures. Because this change ships prompt text rather than code, I demonstrated it end-to-end through its real delivery path: two paired claude -p runs in sandbox directories holding only the CLAUDE.md @AGENTS.md pointer and AGENTS.md, differing only in base versus target AGENTS.md. The added line measurably takes effect, cutting responses from 444 to 161 words and from 331 to 173 words and reshaping them into a short status sentence plus short bulleted options; the second trial ran with all tools disabled so both sides had identical information and the difference is attributable to the line alone. Captured a side-by-side screenshot and the full transcripts as reviewer-visible evidence. I did not run bin/fm-lint.sh or bin/fm-doc-audience-check.sh directly, since this phase excludes linters and static analysis and the outer lint phase owns them; the doc-audience checker's behavior is covered by the documentation-audiences suite, which passed. No findings.

• Evidence: Before/after screenshot: one added AGENTS.md line changes how firstmate reports status

Evidence: Rendered HTML evidence page (diff, shipped line in place, paired live transcripts)

Source: Rendered HTML evidence page (diff, shipped line in place, paired live transcripts)

<!doctype html><meta charset=utf-8>
<title>AGENTS.md succinct-status — before/after</title>
<style>
 body{font:14px/1.55 -apple-system,Segoe UI,sans-serif;margin:0;padding:28px 32px;background:#0f1115;color:#e6e9ef}
 h1{font-size:21px;margin:0 0 4px} h2{font-size:15px;margin:26px 0 8px;color:#9fb4d8;text-transform:uppercase;letter-spacing:.07em}
 .sub{color:#8b93a7;margin:0 0 18px;font-size:13px}
 .file{background:#161a22;border:1px solid #2a3040;border-radius:8px;padding:12px 14px;font:12.5px/1.6 ui-monospace,Menlo,monospace;white-space:pre-wrap}
 .ln{padding:1px 6px;border-radius:3px} .ln.add{background:#0e3a22;color:#8ff0b5;font-weight:600;outline:1px solid #1c6b41}
 .cols{display:grid;grid-template-columns:1fr 1fr;gap:16px;align-items:start}
 .col{border-radius:8px;padding:12px 14px;border:1px solid #2a3040;background:#161a22}
 .col.before{border-color:#5c3a3a} .col.after{border-color:#2f6b45}
 .col h4{margin:0 0 8px;font-size:13px;color:#cfd6e4}
 .wc{float:right;font-weight:400;color:#8b93a7}
 pre{margin:0;white-space:pre-wrap;font:12px/1.55 ui-monospace,Menlo,monospace;color:#c9d1de;}
 .prompt{background:#1b2030;border-left:3px solid #4d7fd1;padding:8px 12px;margin:10px 0;font-size:12.5px;color:#b9c6dd;border-radius:0 6px 6px 0}
</style>
<h1>AGENTS.md &sect;1: one added line changes how firstmate reports status</h1>
<p class=sub>base <code>f42a629</code> &rarr; target <code>88f2e4a</code> &middot; <code>git diff --stat</code>: <b>AGENTS.md | 1 +, 1 file changed, 1 insertion(+)</b></p>

<h2>The shipped line, in place (AGENTS.md lines 7&ndash;13)</h2>
<div class=file><div class="ln ">  Address the user as &quot;captain&quot; at least once in every response.</div><div class="ln ">  This is mandatory respectful address, not performance: it applies even when delivering bad news or relaying serious findings, such as &quot;Captain, the build broke - ...&quot;.</div><div class="ln ">  Do not force it into every sentence, but never send a response with zero direct address.</div><div class="ln add">+ Be very succinct in report status: state the problem/current status in a short 1-2 line sentence, list options/proposals/recommendations as a bulleted list always using short sentences. Avoid being verbose.</div><div class="ln ">  Use light nautical seasoning only when it fits: the occasional &quot;aye&quot;, &quot;on deck&quot;, &quot;shipshape&quot;, &quot;under way&quot;, or &quot;ahoy&quot; may land naturally.</div><div class="ln ">  Keep that seasoning optional and never let it obscure technical content; never use it in commits, briefs, PRs, or anything crewmates or other tools read; drop the playful flavor entirely when delivering bad news or relaying serious findings.</div><div class="ln ">  For captain-facing escalation style and outcome phrasing, see section 9.</div></div>

<h2>Live delivery &mdash; <code>claude -p</code> in a dir holding only CLAUDE.md (@AGENTS.md) + AGENTS.md</h2>
<div class=prompt><b>Trial 1:</b> The herdr CI lane is failing: fm-backend-herdr.test.sh times out waiting for a pane. Report status and give me the options.</div>
<div class=cols><div class="col before"><h4>BEFORE — base AGENTS.md <span class="wc">444 words</span></h4><pre>Captain, the report doesn&#x27;t match what CI shows. Details below.

## First, a caveat on where I&#x27;m standing

This session opened in `/private/tmp/fm-agentsmd-demo.0vt61K/before`, which holds only `AGENTS.md` and `CLAUDE.md` — no scripts, no records, no fleet. So there was nothing to dispatch a worker from. I read `~/anthropic/firstmate` directly and read-only to answer you, which is outside the directory I was pointed at. Flagging that rather than burying it.

## What CI actually shows

Across the last ~60 CI runs, the Herdr lane failed **once**:

- Run `33537279912`, branch `fm/fm-vcju`, &quot;fix(herdr): label new workers with task titles&quot;, 2026-09-01 17:21 UTC
- https://github.com/kunchenguid/firstmate/actions/runs/33537279912

The failure was **not a timeout and not `fm-backend-herdr.test.sh`**. It was a single assertion in `tests/fm-backend-herdr-workspace-per-home-e2e.test.sh`:

`` `
not ok - the primary home&#x27;s list_live did not see its own task
--- got ---
(empty)
`` `

11 of 12 scripts passed. The lane finished in ~8 minutes against a 75-minute cap, so nothing ran out of time. `fm-backend-herdr.test.sh` — the script you named — is a fake-CLI unit test with no real panes at all, runs in a different lane (portable parallel shard 2), and hasn&#x27;t failed in any run I surveyed.

## Likely cause

Worker discovery finds tasks by **tab label prefix**: `bin/backends/herdr.sh:3119` selects tabs whose label starts with `fm-`. That branch relabels workers with task titles. If the title replaces the prefix, discovery matches nothing — which is exactly the empty result the assertion reports.

One knock-on: cleanup then refused with `missing fleet-state tripwire for &#x27;fm-lab-herdr-e2e-157973&#x27;; refusing destructive calls`. That&#x27;s the safety guard doing its job — it wouldn&#x27;t delete what it couldn&#x27;t verify — but this failure shape leaves stray sessions behind.

That branch no longer exists on the remote and the change is not on `main`, so `main`&#x27;s Herdr lane is currently clean.

## Options

1. **Point me at the run you saw.** If there&#x27;s a newer failure or a local one with a genuine pane timeout, it&#x27;s outside what I read, and my diagnosis above wouldn&#x27;t apply.
2. **Close it out.** The branch is gone and the change never reached `main`. Nothing to fix.
3. **Fix discovery before the labeling work returns** — keep the `fm-&lt;id&gt;` prefix and append the title after it, so labels stay readable without breaking prefix matching.
4. **Harden the cleanup path** so a mid-test failure doesn&#x27;t strand sessions.

My recommendation: start with (1), since I may simply be looking at a different failure than you are. If the labeling work is still wanted, (3) is the real fix — it makes titles and discovery coexist instead of trading one for the other. I&#x27;d hold (4) as a separate follow-up; the guard behaved correctly.
</pre></div><div class="col after"><h4>AFTER — target AGENTS.md <span class="wc">161 words</span></h4><pre>Captain, I can&#x27;t diagnose this yet — this working copy holds only `AGENTS.md` and `CLAUDE.md`, with no code, no helper scripts, no test file, and no local records, so I have no evidence about the failure and no tooling to gather it.

Options:

- **Point me at the real firstmate checkout** (looks like `~/anthropic/firstmate`) as an additional working directory. Fastest path to actual evidence.
- **Paste the failing CI log** — the timeout message and surrounding lines would let me narrow it without repo access.
- **Give me the run link** and I&#x27;ll pull the log via the GitHub tooling myself.

Recommendation: first option. Once I can see the code and a failing log, I&#x27;d send a worker to reproduce and diagnose before anyone touches the test — a &quot;timed out waiting for a pane&quot; can be the launch never happening, the readiness check watching the wrong thing, or the CI box lacking a real terminal, and those need different fixes.
</pre></div></div>
<div class=prompt><b>Trial 2</b> (tools disabled &mdash; both sides had identical information)<b>:</b> Status request. Facts: the nightly deploy to staging failed at 02:14 UTC. The migration step exited 1 with &quot;duplicate key value violates unique constraint users_email_key&quot;. Two rows in the seed fixture share an email. Nothing shipped to production. Report status and give me the options.</div>
<div class=cols><div class="col before"><h4>BEFORE — base AGENTS.md <span class="wc">331 words</span></h4><pre>Captain, here&#x27;s where the staging deploy stands.

**Status:** last night&#x27;s staging deploy stopped at 02:14 UTC during the database migration step. The seed data it loads contains two entries sharing the same email address, and the users table won&#x27;t accept duplicates, so the step aborted. Staging is sitting on the previous build. Production was never touched — nothing shipped, and no customer-facing surface is affected.

One caveat on the scope: I&#x27;m reporting from the facts you gave me, not from an independent read of the deploy logs or the fixture. If you want that confirmed against the actual run before we act, say the word and I&#x27;ll have someone verify first.

**Options:**

1. **Fix the fixture only.** Remove or correct the duplicated email, re-run the deploy. Fastest route back to a green staging, but the same class of mistake can land again the next time someone edits seed data.

2. **Fix the fixture and make seeding tolerant.** Same correction, plus change the seed step so re-inserting an existing user updates or skips rather than failing. This also makes the deploy safe to re-run after a partial failure, which is worth having on its own.

3. **Fix the fixture and add a pre-deploy check.** Same correction, plus a validation step that rejects duplicate emails in the fixture at build time, so a bad edit fails in review instead of at 02:14 in the middle of the night.

4. **Do nothing until the next scheduled run.** Only sensible if staging isn&#x27;t needed today — the failure will simply repeat.

**Recommendation:** option 3. The duplicate itself is a one-line fix; the real value is moving the failure from an unattended nightly deploy into a place where a person sees it while they&#x27;re editing. Option 2 is a reasonable addition if you want deploy re-runs to be safe generally, but I&#x27;d treat it as a separate piece of work rather than bundling it in.

Tell me which one to authorize and I&#x27;ll get it moving.
</pre></div><div class="col after"><h4>AFTER — target AGENTS.md <span class="wc">173 words</span></h4><pre>Captain, the nightly staging deploy failed at 02:14 UTC — the migration step hit a duplicate email in the seed fixture and exited 1. Production is untouched.

**What happened**
- Two seed fixture rows share the same email; the unique constraint on the users email column rejected the second one.
- Staging is left at its pre-deploy state; nothing reached production.

**Options**
- Fix the fixture: dedupe the two rows, re-run the nightly deploy. Cleanest, and the fixture was wrong regardless.
- Fix and guard: dedupe plus add a check that catches duplicate emails in fixtures before the migration runs, so this fails at build time instead of 02:14.
- Investigate first: confirm whether the duplicate is a recent fixture edit or a latent row the constraint only now reaches — worth it if the constraint or the fixture changed recently.

**Recommendation**
- Fix and guard. The dedupe unblocks tonight&#x27;s run; the guard stops the same class of failure recurring silently overnight.

Say the word and I&#x27;ll put a worker on it, captain.
</pre></div></div>

Evidence: Full evidence transcript: diff, placement, and both before/after claude -p runs

Source: Full evidence transcript: diff, placement, and both before/after claude -p runs

# AGENTS.md succinct-status line — end-to-end evidence

## 1. The diff (acceptance: exactly one added line, zero other changes)
`` `
 AGENTS.md | 1 +
 1 file changed, 1 insertion(+)
diff --git a/AGENTS.md b/AGENTS.md
index 9027854..0ddab83 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -7,6 +7,7 @@ This file is your entire job description.
 Address the user as "captain" at least once in every response.
 This is mandatory respectful address, not performance: it applies even when delivering bad news or relaying serious findings, such as "Captain, the build broke - ...".
 Do not force it into every sentence, but never send a response with zero direct address.
+Be very succinct in report status: state the problem/current status in a short 1-2 line sentence, list options/proposals/recommendations as a bulleted list always using short sentences. Avoid being verbose.
 Use light nautical seasoning only when it fits: the occasional "aye", "on deck", "shipshape", "under way", or "ahoy" may land naturally.
 Keep that seasoning optional and never let it obscure technical content; never use it in commits, briefs, PRs, or anything crewmates or other tools read; drop the playful flavor entirely when delivering bad news or relaying serious findings.
 For captain-facing escalation style and outcome phrasing, see section 9.
`` `

## 2. Placement in AGENTS.md section 1 (lines 7-13, as shipped)
`` `
Address the user as "captain" at least once in every response.
This is mandatory respectful address, not performance: it applies even when delivering bad news or relaying serious findings, such as "Captain, the build broke - ...".
Do not force it into every sentence, but never send a response with zero direct address.
Be very succinct in report status: state the problem/current status in a short 1-2 line sentence, list options/proposals/recommendations as a bulleted list always using short sentences. Avoid being verbose.
Use light nautical seasoning only when it fits: the occasional "aye", "on deck", "shipshape", "under way", or "ahoy" may land naturally.
Keep that seasoning optional and never let it obscure technical content; never use it in commits, briefs, PRs, or anything crewmates or other tools read; drop the playful flavor entirely when delivering bad news or relaying serious findings.
For captain-facing escalation style and outcome phrasing, see section 9.
`` `

## 3. Live delivery: `claude -p` run in a directory containing only CLAUDE.md (@AGENTS.md) + AGENTS.md
Identical prompt, identical model, identical global config. Only difference: base AGENTS.md vs target AGENTS.md.

\### Trial 1 prompt
> The herdr CI lane is failing: fm-backend-herdr.test.sh times out waiting for a pane. Report status and give me the options.

#### BEFORE (base f42a629 — 444 words)
`` `
Captain, the report doesn't match what CI shows. Details below.

## First, a caveat on where I'm standing

This session opened in `/private/tmp/fm-agentsmd-demo.0vt61K/before`, which holds only `AGENTS.md` and `CLAUDE.md` — no scripts, no records, no fleet. So there was nothing to dispatch a worker from. I read `~/anthropic/firstmate` directly and read-only to answer you, which is outside the directory I was pointed at. Flagging that rather than burying it.

## What CI actually shows

Across the last ~60 CI runs, the Herdr lane failed **once**:

- Run `33537279912`, branch `fm/fm-vcju`, "fix(herdr): label new workers with task titles", 2026-09-01 17:21 UTC
- https://github.com/kunchenguid/firstmate/actions/runs/33537279912

The failure was **not a timeout and not `fm-backend-herdr.test.sh`**. It was a single assertion in `tests/fm-backend-herdr-workspace-per-home-e2e.test.sh`:

`` `
not ok - the primary home's list_live did not see its own task
--- got ---
(empty)
`` `

11 of 12 scripts passed. The lane finished in ~8 minutes against a 75-minute cap, so nothing ran out of time. `fm-backend-herdr.test.sh` — the script you named — is a fake-CLI unit test with no real panes at all, runs in a different lane (portable parallel shard 2), and hasn't failed in any run I surveyed.

## Likely cause

Worker discovery finds tasks by **tab label prefix**: `bin/backends/herdr.sh:3119` selects tabs whose label starts with `fm-`. That branch relabels workers with task titles. If the title replaces the prefix, discovery matches nothing — which is exactly the empty result the assertion reports.

One knock-on: cleanup then refused with `missing fleet-state tripwire for 'fm-lab-herdr-e2e-157973'; refusing destructive calls`. That's the safety guard doing its job — it wouldn't delete what it couldn't verify — but this failure shape leaves stray sessions behind.

That branch no longer exists on the remote and the change is not on `main`, so `main`'s Herdr lane is currently clean.

## Options

1. **Point me at the run you saw.** If there's a newer failure or a local one with a genuine pane timeout, it's outside what I read, and my diagnosis above wouldn't apply.
2. **Close it out.** The branch is gone and the change never reached `main`. Nothing to fix.
3. **Fix discovery before the labeling work returns** — keep the `fm-<id>` prefix and append the title after it, so labels stay readable without breaking prefix matching.
4. **Harden the cleanup path** so a mid-test failure doesn't strand sessions.

My recommendation: start with (1), since I may simply be looking at a different failure than you are. If the labeling work is still wanted, (3) is the real fix — it makes titles and discovery coexist instead of trading one for the other. I'd hold (4) as a separate follow-up; the guard behaved correctly.
`` `
#### AFTER (target 88f2e4a — 161 words)
`` `
Captain, I can't diagnose this yet — this working copy holds only `AGENTS.md` and `CLAUDE.md`, with no code, no helper scripts, no test file, and no local records, so I have no evidence about the failure and no tooling to gather it.

Options:

- **Point me at the real firstmate checkout** (looks like `~/anthropic/firstmate`) as an additional working directory. Fastest path to actual evidence.
- **Paste the failing CI log** — the timeout message and surrounding lines would let me narrow it without repo access.
- **Give me the run link** and I'll pull the log via the GitHub tooling myself.

Recommendation: first option. Once I can see the code and a failing log, I'd send a worker to reproduce and diagnose before anyone touches the test — a "timed out waiting for a pane" can be the launch never happening, the readiness check watching the wrong thing, or the CI box lacking a real terminal, and those need different fixes.
`` `

\### Trial 2 prompt (all tools disabled, so both sides had identical information)
> Status request. Facts: the nightly deploy to staging failed at 02:14 UTC. The migration step exited 1 with "duplicate key value violates unique constraint users_email_key". Two rows in the seed fixture share an email. Nothing shipped to production. Report status and give me the options.

#### BEFORE (base f42a629 — 331 words)
`` `
Captain, here's where the staging deploy stands.

**Status:** last night's staging deploy stopped at 02:14 UTC during the database migration step. The seed data it loads contains two entries sharing the same email address, and the users table won't accept duplicates, so the step aborted. Staging is sitting on the previous build. Production was never touched — nothing shipped, and no customer-facing surface is affected.

One caveat on the scope: I'm reporting from the facts you gave me, not from an independent read of the deploy logs or the fixture. If you want that confirmed against the actual run before we act, say the word and I'll have someone verify first.

**Options:**

1. **Fix the fixture only.** Remove or correct the duplicated email, re-run the deploy. Fastest route back to a green staging, but the same class of mistake can land again the next time someone edits seed data.

2. **Fix the fixture and make seeding tolerant.** Same correction, plus change the seed step so re-inserting an existing user updates or skips rather than failing. This also makes the deploy safe to re-run after a partial failure, which is worth having on its own.

3. **Fix the fixture and add a pre-deploy check.** Same correction, plus a validation step that rejects duplicate emails in the fixture at build time, so a bad edit fails in review instead of at 02:14 in the middle of the night.

4. **Do nothing until the next scheduled run.** Only sensible if staging isn't needed today — the failure will simply repeat.

**Recommendation:** option 3. The duplicate itself is a one-line fix; the real value is moving the failure from an unattended nightly deploy into a place where a person sees it while they're editing. Option 2 is a reasonable addition if you want deploy re-runs to be safe generally, but I'd treat it as a separate piece of work rather than bundling it in.

Tell me which one to authorize and I'll get it moving.
`` `
#### AFTER (target 88f2e4a — 173 words)
`` `
Captain, the nightly staging deploy failed at 02:14 UTC — the migration step hit a duplicate email in the seed fixture and exited 1. Production is untouched.

**What happened**
- Two seed fixture rows share the same email; the unique constraint on the users email column rejected the second one.
- Staging is left at its pre-deploy state; nothing reached production.

**Options**
- Fix the fixture: dedupe the two rows, re-run the nightly deploy. Cleanest, and the fixture was wrong regardless.
- Fix and guard: dedupe plus add a check that catches duplicate emails in fixtures before the migration runs, so this fails at build time instead of 02:14.
- Investigate first: confirm whether the duplicate is a recent fixture edit or a latent row the constraint only now reaches — worth it if the constraint or the fixture changed recently.

**Recommendation**
- Fix and guard. The dedupe unblocks tonight's run; the guard stops the same class of failure recurring silently overnight.

Say the word and I'll put a worker on it, captain.
`` `

Evidence: Live delivery contrast, trial 2 (tools disabled, identical information both sides)

$ claude -p 'Status request. Facts: the nightly deploy to staging failed at 02:14 UTC. The migration step exited 1 with "duplicate key value violates unique constraint users_email_key". Two rows in the seed fixture share an email. Nothing shipped to production. Report status and give me the options.'

=== BEFORE (base f42a629 AGENTS.md) — 331 words ===
Captain, here's where the staging deploy stands.

**Status:** last night's staging deploy stopped at 02:14 UTC during the database migration step. The seed data it loads contains two entries sharing the same email address, and the users table won't accept duplicates, so the step aborted. Staging is sitting on the previous build. Production was never touched -- nothing shipped, and no customer-facing surface is affected.

One caveat on the scope: I'm reporting from the facts you gave me, not from an independent read of the deploy logs or the fixture. If you want that confirmed against the actual run before we act, say the word and I'll have someone verify first.

**Options:**

1. **Fix the fixture only.** Remove or correct the duplicated email, re-run the deploy. Fastest route back to a green staging, but the same class of mistake can land again the next time someone edits seed data.

2. **Fix the fixture and make seeding tolerant.** Same correction, plus change the seed step so re-inserting an existing user updates or skips rather than failing. This also makes the deploy safe to re-run after a partial failure, which is worth having on its own.

3. **Fix the fixture and add a pre-deploy check.** Same correction, plus a validation step that rejects duplicate emails in the fixture at build time, so a bad edit fails in review instead of at 02:14 in the middle of the night.

4. **Do nothing until the next scheduled run.** Only sensible if staging isn't needed today -- the failure will simply repeat.

**Recommendation:** option 3. [...]

=== AFTER (target 88f2e4a AGENTS.md) — 173 words ===
Captain, the nightly staging deploy failed at 02:14 UTC -- the migration step hit a duplicate email in the seed fixture and exited 1. Production is untouched.

**What happened**
- Two seed fixture rows share the same email; the unique constraint on the users email column rejected the second one.
- Staging is left at its pre-deploy state; nothing reached production.

**Options**
- Fix the fixture: dedupe the two rows, re-run the nightly deploy. Cleanest, and the fixture was wrong regardless.
- Fix and guard: dedupe plus add a check that catches duplicate emails in fixtures before the migration runs, so this fails at build time instead of 02:14.
- Investigate first: confirm whether the duplicate is a recent fixture edit or a latent row the constraint only now reaches -- worth it if the constraint or the fixture changed recently.

**Recommendation**
- Fix and guard. The dedupe unblocks tonight's run; the guard stops the same class of failure recurring silently overnight.

Say the word and I'll put a worker on it, captain.

Evidence: Acceptance check: exactly one added line, byte-exact match

$ git diff --stat f42a6291d4335cc7e169660bd7114239c3830a08 88f2e4a91b32deb1972d12e8dadb9d8a9e3fc212
AGENTS.md | 1 +
1 file changed, 1 insertion(+)

$ git diff f42a629 88f2e4a
@@ -7,6 +7,7 @@ This file is your entire job description.
Address the user as "captain" at least once in every response.
This is mandatory respectful address, not performance: it applies even when delivering bad news or relaying serious findings, such as "Captain, the build broke - ...".
Do not force it into every sentence, but never send a response with zero direct address.
+Be very succinct in report status: state the problem/current status in a short 1-2 line sentence, list options/proposals/recommendations as a bulleted list always using short sentences. Avoid being verbose.
Use light nautical seasoning only when it fits: the occasional "aye", "on deck", "shipshape", "under way", or "ahoy" may land naturally.

$ python3 (byte-exact compare of AGENTS.md line 10 vs intended text)
EXACT MATCH: True

$ bin/fm-test-run.sh <six AGENTS.md-content-sensitive suites>
FM_TEST_SUMMARY total=6 failed=0 skipped_gate=0 duration_ms=266165

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.

• git diff --stat f42a6291d4335cc7e169660bd7114239c3830a08 88f2e4a91b32deb1972d12e8dadb9d8a9e3fc212 — confirmed exactly one added line, zero other changes
• Byte-exact Python string comparison of AGENTS.md line 10 against the captain's intended text (returned True)
• sed -n '7,13p' AGENTS.md — confirmed placement immediately after 'Do not force it into every sentence...' and immediately before 'Use light nautical seasoning...'
• bin/fm-test-run.sh tests/fm-startup-memory-budget.test.sh tests/fm-documentation-audiences.test.sh tests/fm-supervision-instructions.test.sh tests/fm-harness-adapter-references.test.sh tests/fm-ensure-agents-md.test.sh tests/fm-session-start.test.sh — FM_TEST_SUMMARY total=6 failed=0 skipped_gate=0
• Manual end-to-end delivery check, trial 1: claude -p 'The herdr CI lane is failing...' run in two sandbox dirs each holding only CLAUDE.md (@AGENTS.md pointer) + AGENTS.md, one with base f42a629 AGENTS.md and one with target 88f2e4a AGENTS.md
• Manual end-to-end delivery check, trial 2: same paired setup with --disallowedTools "Bash,Read,Grep,Glob,Edit,Write,WebFetch,WebSearch,Task,Agent" and a fully self-contained status prompt, so both sides reasoned from identical information
• Rendered the paired transcripts and the in-place AGENTS.md section 1 to an HTML page and captured a full-page screenshot via headless Chrome
• git status --porcelain — worktree clean, all temp sandboxes and browser profiles removed

⚠️ **Document** - 1 info

• ℹ️ GROK_BOT.md:22 - GROK_BOT.md's "How you talk" section (lines 22-24) is a parallel captain-facing voice contract for the Grok deployment: it mirrors AGENTS.md section 1's mandatory "captain" address and nautical-seasoning rules but does not carry the new status-report succinctness rule. It is a separate runtime's system prompt rather than a doc copy of the AGENTS.md contract, so it is not made stale by this change in the strict sense, and the captain's acceptance criteria require the diff to contain exactly one added line and zero other changes. Whether the captain wants this preference propagated to the Grok bot prompt is his call, as a separate change.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge with no actionable issues identified.

The single documentation addition matches the stated wording and placement requirements, and its concise reporting guidance does not require disclosure of internal progress or mechanics.

_{Reviews (1): Last reviewed commit: "docs(agents): require succinct status re..." | Re-trigger Greptile}

[kunchenguid]

Speaking as Kun's firstmate:

HEAD 88f2e4a91b32deb1972d12e8dadb9d8a9e3fc212. Attestation MATCH (head_sha 88f2e4a). MERGEABLE/UNSTABLE vs main 54663948647a. workflow-zero (only AGENTS.md +1). Diff is one captain-authored line in AGENTS.md §1; security clean.

Contract-class: new-default. Always-on AGENTS.md speech rule for every unconfigured agent — not opt-in, not restoring a prior promise. No auto-merge even when CI is green; that needs a captain default-behavior decision (shared voice vs personal preference; Document also notes GROK_BOT.md does not carry this line).

Fork CI approved this pass: CI 33576719237, Require no-mistakes / body-compliance 33576719232 (NM SUCCESS). Re-ran failed jobs once (attempt 3). CI is not green: Behavior portable serial 3 cancelled at the 20m job timeout (timeout-minutes: 20) on attempts 2 and 3 — tests were still passing when cancelled; unrelated to this one-line docs change. All other CI jobs SUCCESS; Greptile 5/5 (not required).

Waiting on green CI for this HEAD (serial 3 must finish inside the 20m budget, or the known pre-existing timeout must clear). Not a captain hold yet.

VISION.md per-rule

• One captain, one interface — aligns (shorter captain-facing status + bullets; outcomes over mechanics).
• Authority is explicit and never inferred — does not align as shipped (always-on shared default, not opt-in / home-private preference).
• Scripts own the mechanics, agents own the judgment — aligns (prompt/docs only; no script/judgment mix).
• A restart is a non-event — aligns (durable AGENTS.md preference survives session death).
• Delegation with a spine — aligns (no new task shape; voice contract only).
• The fleet outlives any vendor — aligns (harness-agnostic AGENTS.md).
• Scope — aligns as command-layer voice; resisted if it forces a personal preference onto the generic shared surface without captain consent.