fdeops 3.15.1 → 3.15.2

package/skills/fde/references/business-case.md

@@ -30,7 +30,7 @@ Keep the drivers explicit. "We estimate $200K savings" means nothing. "3 people
 
 **3. Sensitivity check - name the two drivers that swing the result:**
 
-Every business case has 1–2 variables where a small change flips the outcome. Name them explicitly:
+Every business case has 1-2 variables where a small change flips the outcome. Name them explicitly:
 
 > "This case holds if the team actually reclaims 6+ hours/week per person. If it's only 3 hours, the payback extends from 5 months to 14 months. The validation: measure time-spent before and after pilot with 2 team members."
 
@@ -75,9 +75,9 @@ Acme phase 2 needs funding. The case starts with the cost of doing nothing, not
 
 Anchor: two silent failures since March, each one day of finance reconciliation by hand plus a late close (`reality.md`, Marco's sheet). That is the number the sponsor already believes because her own team reported it.
 
-Driver model the sponsor can trace: incidents/quarter × hours of manual reconciliation × loaded cost, plus the tail risk of a late regulatory close — stated separately, because mixing a certain small number with an uncertain large one is how a case loses credibility.
+Driver model the sponsor can trace: incidents/quarter × hours of manual reconciliation × loaded cost, plus the tail risk of a late regulatory close - stated separately, because mixing a certain small number with an uncertain large one is how a case loses credibility.
 
-Sensitivity names the two drivers that swing it: incident frequency (2/quarter → 1/quarter and the case halves) and whether the manual re-run continues in parallel (if Marco keeps re-running every morning, the saving is theoretical). The second one is the honest weakness, so it is in the case rather than waiting to be found in the room — with the condition that makes it hold: the morning re-run stops after two clean cycles, agreed with Marco.
+Sensitivity names the two drivers that swing it: incident frequency (2/quarter → 1/quarter and the case halves) and whether the manual re-run continues in parallel (if Marco keeps re-running every morning, the saving is theoretical). The second one is the honest weakness, so it is in the case rather than waiting to be found in the room - with the condition that makes it hold: the morning re-run stops after two clean cycles, agreed with Marco.
 
 ## Principles
 

package/skills/fde/references/close.md

@@ -18,7 +18,7 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 - AI components: did they behave in production? What failure modes did the prototype hide? Is the team equipped to maintain them?
 
 **1b. Value + receipts close gate (refuse green close if any fail):**
-- Primary value bucket in `success.md` matches what the sponsor funded; at least one ledger row has **Measured** (not forever-`pending`) with evidence **and a named customer-side owner in Accepted by** for that bucket — or the retrospective explicitly records “not measured; sponsor accepted pending.” A measured-but-unaccepted number closes as `claimed`; say so in the retrospective rather than closing green on arithmetic nobody signed.
+- Primary value bucket in `success.md` matches what the sponsor funded; at least one ledger row has **Measured** (not forever-`pending`) with evidence **and a named customer-side owner in Accepted by** for that bucket - or the retrospective explicitly records “not measured; sponsor accepted pending.” A measured-but-unaccepted number closes as `claimed`; say so in the retrospective rather than closing green on arithmetic nobody signed.
 - Audit receipt exists for the final shipped path (exceptions/operating map walked; cite file).
 - Eval receipt: **n/a if no AI**, else final golden/eval result + HITL owner recorded; kill switch / fallback named in `handoff.md`.
 - One line in the retrospective: which bucket moved, by how much, vs baseline.
@@ -39,17 +39,17 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Checkpoint
 
-Direct assessment to the FDE: did the engagement achieve `success.md` · 2–3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
+Direct assessment to the FDE: did the engagement achieve `success.md` · 2-3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
 
 ## Worked example
 
 Acme, twelve weeks in, the FDE is rolling off.
 
-Retrospective against the receipts: `brief.md` asked for monitoring, `reality.md` proved it was ownership — and the delta is the most useful paragraph in the file, because it is exactly the argument the next engagement will need.
+Retrospective against the receipts: `brief.md` asked for monitoring, `reality.md` proved it was ownership - and the delta is the most useful paragraph in the file, because it is exactly the argument the next engagement will need.
 
-The close gate bites in a useful way. The ledger shows detection at 12 minutes measured across two real incidents, but **Accepted by** is empty — Marco confirmed it in Slack, Denise (finance) never did, and Denise is whose escalation started the engagement. So it closes as `claimed` with a one-line retrospective note and a named next step, rather than a green close on a number nobody with budget agreed to.
+The close gate bites in a useful way. The ledger shows detection at 12 minutes measured across two real incidents, but **Accepted by** is empty - Marco confirmed it in Slack, Denise (finance) never did, and Denise is whose escalation started the engagement. So it closes as `claimed` with a one-line retrospective note and a named next step, rather than a green close on a number nobody with budget agreed to.
 
-`handoff.md` is written for the person woken at 2am: the three things that break, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job — credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* — it has now happened twice.
+`handoff.md` is written for the person woken at 2am: the three things that break, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job - credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* - it has now happened twice.
 
 ## Principles
 

package/skills/fde/references/debrief.md

@@ -12,7 +12,7 @@
 
 - The `fde` CLI is **local, deterministic, no AI**. `--smart` is a **gate + writer**, not a brain.
 - It keeps lines that already have `decision:` / `risk:` / `delivery:` / `contact:` / `next:` prefixes, plus a thin keyword pass (e.g. "we agreed", person+verb lines, "open question").
-- Real messy notes without prefixes often route **0 useful lines** — everything else lands as a context dump. That is expected. **You are the router:** rewrite `.debrief-propose` with type prefixes, then `--apply`.
+- Real messy notes without prefixes often route **0 useful lines** - everything else lands as a context dump. That is expected. **You are the router:** rewrite `.debrief-propose` with type prefixes, then `--apply`.
 - `.debrief-propose` is raw lines only (no routing annotations). "Edit if mis-routed" means **rewrite the line with the right prefix**, not leave a comment in the file.
 
 ## Method (you do this work)
@@ -22,7 +22,7 @@
 1. Save the FDE's notes to a temp `.md` file in the workspace (or pipe stdin).
 2. Run `fde debrief --smart <notes.md>` (or `npx fdeops debrief --smart …`).
 3. Open `.debrief-propose`. If lines lack type prefixes, **rewrite them** before showing the FDE, e.g.:
-   - `decision: agreed chargebacks stay phase 2 — Priya`
+   - `decision: agreed chargebacks stay phase 2 - Priya`
    - `risk: legal may reopen scope if we slip the SOW date`
    - `contact: Priya pushed hard on Friday deck [signal:amber]`
    - `next: send one-pager before Thursday 9am`

package/skills/fde/references/discover.md

@@ -22,16 +22,16 @@ State your read, let the FDE correct, then discover.
 
 Use when the "problem" is unfalsifiable, success is undefined, or you cannot name the decision discovery informs. Skip when `reality.md` / `terrain.md` already pin a testable claim and the FDE is ready to dig.
 
-Same format as land — one Q + GUESS, no checklist:
+Same format as land - one Q + GUESS, no checklist:
 
 ```
 READ: <the real problem you think exists, in one sentence>
-CONFIDENCE: ~NN% — missing: <what would falsify or confirm it>
+CONFIDENCE: ~NN% - missing: <what would falsify or confirm it>
 Q: <one question that changes where you dig>
 GUESS: <your answer, so they can correct it>
 ```
 
-Stop when you can write the decision sentence under **Frame the decision first**. If a name, quote, or metric is still missing, write `unknown - ask:` — never invent ops folklore to make the map look complete.
+Stop when you can write the decision sentence under **Frame the decision first**. If a name, quote, or metric is still missing, write `unknown - ask:` - never invent ops folklore to make the map look complete.
 
 ## Frame the decision first
 
@@ -92,7 +92,7 @@ The real spec is what people **do** when the system fails - not what the slide d
 - **The hesitation.** When someone says "well, there's also this other thing we do…" - stop them, ask them to finish. The main story is what they're comfortable explaining; the hesitation is the real problem.
 - **"Which part of the codebase do you least want to touch?"** The answer is unanimous and it's the load-bearing wall. Check it against your churn scan - when the human answer and the churn data agree, that's your first map landmark.
 - **Shadow AI.** Someone pasting data into ChatGPT to cope = a real unmet need + an uncontrolled data risk. Note both.
-- **Exception-led operating map.** For each real break (not the slide-deck process): what fails, who notices first, what they do today, and which artifact is trusted in that moment. Prefer exceptions over happy-path swimlanes — the workaround is the operating system. Write rows under `terrain.md` → `## Operating map (exception-led)`. If the section is missing on an older engagement, add it; never regenerate the rest of terrain. When AI is in play, also fill `## Intelligence placement` (deterministic vs LLM judgement vs human approve). **`fde doctor` requires at least one filled exception row before plan/build/ship/close** — empty map after discover is a hygiene fail, not optional polish.
+- **Exception-led operating map.** For each real break (not the slide-deck process): what fails, who notices first, what they do today, and which artifact is trusted in that moment. Prefer exceptions over happy-path swimlanes - the workaround is the operating system. Write rows under `terrain.md` → `## Operating map (exception-led)`. If the section is missing on an older engagement, add it; never regenerate the rest of terrain. When AI is in play, also fill `## Intelligence placement` (deterministic vs LLM judgement vs human approve). **`fde doctor` requires at least one filled exception row before plan/build/ship/close** - empty map after discover is a hygiene fail, not optional polish.
 
 ## Method - part 3: workshop facilitation
 
@@ -137,7 +137,7 @@ A use case that depends on a "Blocker" source doesn't get scored - it gets a dat
 
 Score every candidate use case before anything gets prototyped:
 
-| Dimension | Question | 1–5 |
+| Dimension | Question | 1-5 |
 |---|---|---|
 | Business value | What does it cost them unsolved? | |
 | Complexity | How hard to build safely? (5 = hardest) | |
@@ -196,9 +196,9 @@ Stop. Don't form a fourth hypothesis. Three disproven reads means the brief is a
 
 Acme's brief blamed missing monitoring. Discovery goes to the workaround first.
 
-`git log` shows the reconciliation module at 47 commits/90d with no tests, all from one author who left in February. Marco (ops lead) turns out to keep a spreadsheet: every morning he re-runs the job manually and eyeballs the totals — a habit nobody mentioned because to him it is just the job. That spreadsheet is the system of record when the job fails, which is the actual finding.
+`git log` shows the reconciliation module at 47 commits/90d with no tests, all from one author who left in February. Marco (ops lead) turns out to keep a spreadsheet: every morning he re-runs the job manually and eyeballs the totals - a habit nobody mentioned because to him it is just the job. That spreadsheet is the system of record when the job fails, which is the actual finding.
 
-`reality.md`: **Confirmed:** the job has no owner, and the manual re-run masks failures for a day (evidence: Marco's sheet, Day 5; two silent failures since March, finance escalation Mar 14). **Stated brief was wrong because:** alerting existed last year and was disabled — adding it again without an owner reproduces the same outcome. `terrain.md` gets the hotspot row and an operating-map row: `job fails silently → Marco notices next morning → re-runs by hand → spreadsheet is truth → LOAD-BEARING (Marco, Day 5)`.
+`reality.md`: **Confirmed:** the job has no owner, and the manual re-run masks failures for a day (evidence: Marco's sheet, Day 5; two silent failures since March, finance escalation Mar 14). **Stated brief was wrong because:** alerting existed last year and was disabled - adding it again without an owner reproduces the same outcome. `terrain.md` gets the hotspot row and an operating-map row: `job fails silently → Marco notices next morning → re-runs by hand → spreadsheet is truth → LOAD-BEARING (Marco, Day 5)`.
 
 Checkpoint to the FDE names the sponsor decision this creates: fund ownership, or fund alerting and accept the same failure in six months.
 

package/skills/fde/references/eval-pack.md

@@ -1,6 +1,6 @@
 # eval-pack - prove the system before it acts
 
-**Enter when:** the work touches AI/LLM/agents/RAG, or ship/close is blocked because there is no evidence the non-deterministic path is safe. Activate alongside `ai.md`, `sketch`, `build`, or `ship` — not instead of them.
+**Enter when:** the work touches AI/LLM/agents/RAG, or they need to POC a model, or ship/close is blocked because there is no evidence the non-deterministic path is safe. Activate alongside `ai.md`, `sketch`, `incremental-build`, or `ship` - not instead of them.
 
 **Read first:** `trust-profile.md` (AI policy + HITL), `terrain.md` (operating map), `delivery.md`. Create or extend `evals.md`.
 
@@ -14,19 +14,19 @@ Intelligence without evidence is token-maxing with a nicer name. An FDE earns tr
 
 **1. Scope the judgement surface.** One sentence: which step uses model judgement, and what must never be autonomous.
 
-**2. Build a golden set (minimum 5–20 for a slice; prefer 50–100 before broad scale).** For each case:
-- input (sanitized — no `<private>` raw values)
+**2. Build a golden set (minimum 5-20 for a slice; prefer 50-100 before broad scale).** For each case:
+- input (sanitized - no `<private>` raw values)
 - expected outcome or expert-approved acceptance note
 - pass rule (exact / contains / short rubric)
 - source: real historical example / expert label / staged fixture
 
 **3. Score pass/fail, not vibes.** Run the suite. Record count pass / fail. Failures get a failure-mode tag (missing data, wrong record, format drift, hallucination, retrieval miss, unsafe action, other).
 
-**4. Human-in-the-loop gate.** Name which outcomes require human approve before side effects. If none, write why that is allowed under `trust-profile.md` AI policy — do not invent permission.
+**4. Human-in-the-loop gate.** Name which outcomes require human approve before side effects. If none, write why that is allowed under `trust-profile.md` AI policy - do not invent permission.
 
 **5. Ship rule.** Until `evals.md` shows Verdict **SHIP** with a dated run (critical fails = 0) and HITL filled when policy requires it, AI-touching ship stays **fix-first**. Log a one-line eval receipt in `delivery.md` → `## Ship receipts`.
 
-## Artifact — `evals.md`
+## Artifact - `evals.md`
 
 Create on first AI-touching slice (not at `resume --init`). Use the stub in `templates/.fde/evals.md`. Every claim needs a source. Missing evidence → leave the cell `unknown - ask:`, never invent scores.
 
@@ -38,6 +38,6 @@ Present to the FDE: suite size, pass rate, top failure mode, HITL gate, Verdict
 
 - No golden set, no AI ship.
 - Pass/fail beats “looks good.”
-- Failure modes are the product — the happy path is table stakes.
+- Failure modes are the product - the happy path is table stakes.
 - HITL is a gate, not a slide.
 - Non-AI work does not need this file.

package/skills/fde/references/handoff-engineering.md

@@ -58,13 +58,13 @@ Rollback: <exact command and expected time>
 
 | Session | Focus | Attendees | Duration | Output |
 |---------|-------|-----------|----------|--------|
-| **Architecture walkthrough** | Why, not what. The decisions, the trade-offs, the things that almost went wrong. | Full team | 60–90 min | Recording + Q&A log |
+| **Architecture walkthrough** | Why, not what. The decisions, the trade-offs, the things that almost went wrong. | Full team | 60-90 min | Recording + Q&A log |
 | **Operational drill** | Deploy, rollback, incident response. They do it, you watch. | On-call team | 60 min | Drill report with confidence level |
 | **Edge-case handover** | The things that aren't in any document. The workarounds, the fragile spots, the "ask Sarah because she's the only one who knows." | Team lead + 1 | 30 min | Additions to `handoff.md` |
 
 **4. The confidence check.** After the knowledge transfer, score the team's readiness:
 
-| Area | Confidence (1–5) | Evidence |
+| Area | Confidence (1-5) | Evidence |
 |------|------------------|----------|
 | Daily operations | | Can they deploy and rollback without help? |
 | Incident response | | Did they complete the drill within acceptable time? |

package/skills/fde/references/incremental-build.md

@@ -1,6 +1,6 @@
 # incremental-build - thin slices on someone else's codebase
 
-**Enter when:** the build task is larger than a single PR, multiple files or systems are involved, or the FDE needs to show visible progress to a stakeholder every 2–3 days.
+**Enter when:** the build task is larger than a single PR, multiple files or systems are involved, or the FDE needs to show visible progress to a stakeholder every 2-3 days.
 
 **Read first:** `decisions.md` (the plan), `terrain.md` (the danger zones), `context.md`. This skill works *inside* the build phase - it's the execution discipline that makes large features safe on codebases you don't own.
 
@@ -37,27 +37,36 @@ Each vertical slice delivers working functionality the customer can see. Each sl
 
 ```
 Read existing code in the area (search before creating)
-  → Write characterisation tests for what's there (if legacy)
+  → Characterise what is already there (their tests, their runner)
     → Implement the minimal working path
-      → Verify with evidence (tests + typecheck + smallest proving run)
+      → On-site proof (below)
         → Cleanup pass (dedupe, simplify - behaviour unchanged)
           → Self-review against acceptance criteria
-            → Commit with descriptive message
+            → Commit with a message the client's team can read
               → Update decisions.md + delivery.md
 ```
 
+**On-site proof.** A green check on your laptop is not delivery. Before the slice is done:
+
+- Run **their** test command, typecheck, or smallest proving path. Write the command and the result in `delivery.md`.
+- If the signer in `success.md` cannot reject this slice on a screen they already use, it is not proven.
+- Staging they operate beats a local demo. If you have no staging: `unknown - ask:` who owns an environment, then stop pretending it shipped.
+- Model in the path: `eval-pack` until `evals.md` says SHIP. Do not skip because "it looked right in chat."
+
+Do not prove it with a textbook ritual. The proof is whatever this client already believes, plus one new receipt they can replay.
+
 **4. Size discipline.** Each slice targets:
 
 | Metric | Target | Why |
 |--------|--------|-----|
-| Lines changed | 100–300 | Reviewable in one sitting |
-| Time to implement | 30–90 minutes | Testable before context decays |
-| Files touched | 1–5 | Blast radius stays containable |
+| Lines changed | 100-300 | Reviewable in one sitting |
+| Time to implement | 30-90 minutes | Testable before context decays |
+| Files touched | 1-5 | Blast radius stays containable |
 | Tests added | ≥1 per new behaviour | Proves the slice works; guards against regression |
 
 A slice larger than 300 lines → split before implementing. "It's all connected" means the design needs work, not the slice limit.
 
-**5. Stakeholder visibility rhythm.** Every 2–3 slices, something the customer can see:
+**5. Stakeholder visibility rhythm.** Every 2-3 slices, something the customer can see:
 
 - A working endpoint they can hit
 - A UI change they can click
@@ -80,12 +89,12 @@ Technical progress invisible to stakeholders is trust decay. `delivery.md` gets
 
 ## Checkpoint
 
-After each slice: tests pass (state the command and result), acceptance criteria met, blast radius as declared. After every 2–3 slices: stakeholder visibility confirmed - what did they see, and what's their signal?
+After each slice: tests pass (state the command and result), acceptance criteria met, blast radius as declared. After every 2-3 slices: stakeholder visibility confirmed - what did they see, and what's their signal?
 
 ## Principles
 
 - Vertical slices, always. Horizontal layers are untestable until assembled.
-- 100–300 lines per slice. Larger means split first.
+- 100-300 lines per slice. Larger means split first.
 - Every slice is independently revertible. If it isn't, the design is coupled.
-- Visible progress every 2–3 slices. Technical progress alone is trust decay.
+- Visible progress every 2-3 slices. Technical progress alone is trust decay.
 - The ugly code outside your slice stays ugly. That's discipline, not laziness.

package/skills/fde/references/ingest-connect.md

@@ -15,15 +15,15 @@
 
 ## Method
 
-1. **Ask one question** — which source? (`file` / `granola` / `slack` / `notion` / other). If "other", ask for the MCP they intend to use. If they just want paste → send them to debrief and stop.
-2. **Capability check (current session)** — list MCP tools you can actually call:
+1. **Ask one question** - which source? (`file` / `granola` / `slack` / `notion` / other). If "other", ask for the MCP they intend to use. If they just want paste → send them to debrief and stop.
+2. **Capability check (current session)** - list MCP tools you can actually call:
    - Sink: `fde ingest` CLI (preferred) and/or `ingest_stage`
    - Source: anything that can **fetch** that system's content (not post)
    - Say clearly: *available now* vs *needs config*.
-3. **Emit config for the source only** — open `mcp/recipes/<source>.md`. Fill placeholders from *that product's* docs. Tell them to paste secrets into host env — never into `.fde/`.
-4. **Tell them where to paste** — Cursor MCP settings / `mcp.json`. Claude Code: their MCP config. Save → reload MCP / restart session.
-5. **Verify** — after reload: re-run capability check. If source tools appear, offer a **test pull** staged to `.inbox/` only. Stop before apply unless they ask to propose.
-6. **Handoff phrase** — e.g. `@fde pull today's Acme Granola into the fieldbook`.
+3. **Emit config for the source only** - open `mcp/recipes/<source>.md`. Fill placeholders from *that product's* docs. Tell them to paste secrets into host env - never into `.fde/`.
+4. **Tell them where to paste** - Cursor MCP settings / `mcp.json`. Claude Code: their MCP config. Save → reload MCP / restart session.
+5. **Verify** - after reload: re-run capability check. If source tools appear, offer a **test pull** staged to `.inbox/` only. Stop before apply unless they ask to propose.
+6. **Handoff phrase** - e.g. `@fde pull today's Acme Granola into the fieldbook`.
 
 ## If they only want paste / files
 

package/skills/fde/references/ingest.md

@@ -1,6 +1,6 @@
 # ingest - pull large artifacts into the fieldbook loop
 
-**Enter when:** the FDE wants to catch the engagement up from external sources — "make sure Acme is up to date," "pull what's relevant," "grab today's Granola and Denise's last email." Raw transcripts and long emails that are too big to paste usefully.
+**Enter when:** the FDE wants to catch the engagement up from external sources - "make sure Acme is up to date," "pull what's relevant," "grab today's Granola and Denise's last email." Raw transcripts and long emails that are too big to paste usefully.
 
 **Connect / capability (different entry):** "connect a new MCP", "connect Granola/Slack/Notion", "what can you pull?" → `references/ingest-connect.md` first. Recipes: `mcp/recipes/` (file, granola, slack, notion).
 
@@ -11,7 +11,7 @@
 ## Honest contract (read once)
 
 - FDEOps owns the **sink only**: stage raw pulls → propose → confirm → apply. Nothing writes `.fde/` unreviewed.
-- **Source MCPs are the FDE's.** Granola, Slack, Notion, Gmail, custom — whatever they configured in Cursor/Claude. fdeops does not bundle OAuth, connectors, or ambient sync, and **does not push** to those tools.
+- **Source MCPs are the FDE's.** Granola, Slack, Notion, Gmail, custom - whatever they configured in Cursor/Claude. fdeops does not bundle OAuth, connectors, or ambient sync, and **does not push** to those tools.
 - Prefer **`fde ingest` in this bound workspace.** Optional `fdeops-ingest` MCP: pass `engagement` (path to `.fde/` from `fde resume --bind`) because MCP cwd often is not the client workspace.
 - The core `fde` CLI stays local (git + file reads). Source credentials live with that MCP; fdeops never stores them.
 - After apply, raw stays in `.inbox/`; the system of record (`.fde/`) stays thin dated facts.
@@ -20,20 +20,20 @@
 
 List what you can actually call **this session**:
 
-1. **Sink** — `ingest_stage` / `fde ingest` available?
-2. **Sources** — which fetch tools exist (Granola-shaped, Slack, Notion, Drive, file-only)?
+1. **Sink** - `ingest_stage` / `fde ingest` available?
+2. **Sources** - which fetch tools exist (Granola-shaped, Slack, Notion, Drive, file-only)?
 3. Tell the FDE in one line: *I can pull from X; Y is not connected.* If they asked to pull Y and it is missing → switch to `ingest-connect.md`. Never pretend a source exists.
 
 ## Ground loop (you do this work)
 
-1. **Bind** the engagement (`fde resume` / registry). If multiple meetings or threads could apply, ask **one** clarifying question — which meeting, which thread, which date range.
+1. **Bind** the engagement (`fde resume` / registry). If multiple meetings or threads could apply, ask **one** clarifying question - which meeting, which thread, which date range.
 2. **Capability check** (above). Then **fetch** via available source MCP(s). You pull; the CLI does not reach the network.
-3. **Stage** — `fde ingest stage [--source NAME] [--title TEXT] [file|-]` writes raw text into `<engagement>/.inbox/` (outside the memory git ledger).
-4. **List** (optional) — `fde ingest list` shows staged items when you need an id or filename.
-5. **Propose** — `fde ingest propose <id-or-filename>` runs the debrief `--smart` path on the staged body (+ provenance line). Opens `.debrief-propose`.
-6. **Rewrite prefixes** — same as debrief: lines without `decision:` / `risk:` / `delivery:` / `contact:` / `next:` need **you** to rewrite before showing the FDE. `--smart` is a gate, not a brain.
+3. **Stage** - `fde ingest stage [--source NAME] [--title TEXT] [file|-]` writes raw text into `<engagement>/.inbox/` (outside the memory git ledger).
+4. **List** (optional) - `fde ingest list` shows staged items when you need an id or filename.
+5. **Propose** - `fde ingest propose <id-or-filename>` runs the debrief `--smart` path on the staged body (+ provenance line). Opens `.debrief-propose`.
+6. **Rewrite prefixes** - same as debrief: lines without `decision:` / `risk:` / `delivery:` / `contact:` / `next:` need **you** to rewrite before showing the FDE. `--smart` is a gate, not a brain.
 7. **Show** the proposed routing in plain language. Wait for confirm.
-8. **Apply** — on FDE confirm only → `fde ingest apply` (= `fde debrief --apply`). On reject → stop; ask what to change.
+8. **Apply** - on FDE confirm only → `fde ingest apply` (= `fde debrief --apply`). On reject → stop; ask what to change.
 
 No invented names, meetings, or quotes. If the propose looks wrong, fix prefixes with judgment, then re-show before apply.
 
@@ -41,7 +41,7 @@ No invented names, meetings, or quotes. If the propose looks wrong, fix prefixes
 
 | Path | Role |
 |------|------|
-| `~/fde-engagements/<slug>/.inbox/` | Staging for raw pulls. Not the memory ledger. NDA surface — same home tree as `.fde/`. |
+| `~/fde-engagements/<slug>/.inbox/` | Staging for raw pulls. Not the memory ledger. NDA surface - same home tree as `.fde/`. |
 | `~/fde-engagements/<slug>/.fde/` | System of record (unchanged contract). |
 | `.fde/.debrief-propose` | Propose file (shared with debrief). |
 
@@ -56,15 +56,15 @@ fde ingest apply
 
 ## Provenance
 
-When a staged fact came from a named source, carry `via:<source>` on the applied line where useful (e.g. `via:granola`, `via:gmail`). Helps receipts and sponsor disputes later — not mandatory on every context line.
+When a staged fact came from a named source, carry `via:<source>` on the applied line where useful (e.g. `via:granola`, `via:gmail`). Helps receipts and sponsor disputes later - not mandatory on every context line.
 
 ## MCP sink + recipes
 
-Optional `mcp/fdeops-ingest` wraps the same verbs over stdio. Source MCPs remain separate — the FDE adds whichever fetch tools they trust. Setup coach: `ingest-connect.md`. Copy-paste recipes: `mcp/recipes/`.
+Optional `mcp/fdeops-ingest` wraps the same verbs over stdio. Source MCPs remain separate - the FDE adds whichever fetch tools they trust. Setup coach: `ingest-connect.md`. Copy-paste recipes: `mcp/recipes/`.
 
 ## Checkpoint
 
-Before apply, read back the 2–3 most consequential captures in one breath — same as debrief. Confirm which sources you staged and what would land in the record. Then stop.
+Before apply, read back the 2-3 most consequential captures in one breath - same as debrief. Confirm which sources you staged and what would land in the record. Then stop.
 
 ## Principles
 

package/skills/fde/references/initiative-triage.md

@@ -29,15 +29,15 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | **Dependency** | How many other initiatives are blocked waiting for this? | 0 (standalone) → 5 (critical path for 3+ others) |
 | **Cost of delay** | What happens each week this doesn't ship? | 1 (nothing) → 5 (measurable loss or regulatory exposure) |
 
-**Triage score = Impact + Dependency + Cost of delay** (simple sum, 3–15 range).
+**Triage score = Impact + Dependency + Cost of delay** (simple sum, 3-15 range).
 
 **3. Sort into three lanes:**
 
 | Lane | Score | Action |
 |------|-------|--------|
-| **Now** (max 3) | 11–15 | Active work this phase. FDE and team capacity allocated. |
-| **Next** (max 5) | 7–10 | Sequenced for the following phase. Dependencies tracked but not started. |
-| **Later** (unlimited) | 3–6 | Captured, not committed. Revisit at next triage. |
+| **Now** (max 3) | 11-15 | Active work this phase. FDE and team capacity allocated. |
+| **Next** (max 5) | 7-10 | Sequenced for the following phase. Dependencies tracked but not started. |
+| **Later** (unlimited) | 3-6 | Captured, not committed. Revisit at next triage. |
 
 **The cap matters.** "Now" has exactly 3 slots. Not 4, not "3 plus this small one." Discipline is the product.
 
@@ -51,8 +51,8 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 
 | Engagement type | Triage frequency | Trigger for emergency re-triage |
 |----------------|-----------------|-------------------------------|
-| Sprint (1–2 weeks) | Once, at plan | Crisis or sponsor change |
-| Standard (1–4 weeks) | Weekly | New P0 from sponsor |
+| Sprint (1-2 weeks) | Once, at plan | Crisis or sponsor change |
+| Standard (1-4 weeks) | Weekly | New P0 from sponsor |
 | Programme (months) | Bi-weekly | Quarterly review, team change, market shift |
 
 **6. Communicate the triage result.** The output is not just a priority list - it's a commitment:

package/skills/fde/references/land.md

@@ -20,18 +20,18 @@ State your read, let the FDE correct, then land.
 
 ## Brief interrogation (only when the brief is thin)
 
-Use this when the ask is conventional or underspecified — missing who decides, why now, what success looks like, or the binding constraint. **Do not** run it when the FDE already gave a clear brief, is mid-flow, or asked for speed over verification.
+Use this when the ask is conventional or underspecified - missing who decides, why now, what success looks like, or the binding constraint. **Do not** run it when the FDE already gave a clear brief, is mid-flow, or asked for speed over verification.
 
-Format — one question at a time, with a guess the FDE can correct:
+Format - one question at a time, with a guess the FDE can correct:
 
 ```
-READ: <one sentence — what you think they actually need>
-CONFIDENCE: ~NN% — missing: <what still blocks a safe start>
+READ: <one sentence - what you think they actually need>
+CONFIDENCE: ~NN% - missing: <what still blocks a safe start>
 Q: <one focused question>
 GUESS: <your best answer, so they can push back fast>
 ```
 
-Wait for the reaction before the next question. Stop when confidence is high enough to write `success.md` without inventing names, or when the FDE says move on. Every answer that is still unknown stays `unknown - ask:` in the artifact — never fill the gap with a plausible stakeholder.
+Wait for the reaction before the next question. Stop when confidence is high enough to write `success.md` without inventing names, or when the FDE says move on. Every answer that is still unknown stays `unknown - ask:` in the artifact - never fill the gap with a plausible stakeholder.
 
 ## Method - part 1: interrogate the brief (you do this work)
 
@@ -65,7 +65,7 @@ Let silence sit. If their fear doesn't match the written brief, the brief is wro
 - **The previous attempt** - "we tried something similar last year" is the most important sentence in the first meeting. Who was involved? Still there and protective, or gone because of it?
 - **The passed-over internal team** - they know exactly what's wrong, and they resent the FDE's presence. Find them before the first standup, ask what they tried, use their language in every meeting. Make them look right and they protect you; ignore them and they wait for the mistake.
 - **The sacred thing** - "Is there anything in this environment I should treat as untouchable?" The hesitation before the answer is the answer.
-- **Exception path (operating map seed)** - "When the happy path breaks this week, what do people actually do — who do they call, what spreadsheet opens, what do they skip?" Capture the break → workaround → who owns it. Do not build a full map on day 1; seed rows later in `terrain.md` → `## Operating map (exception-led)` during discover. Unknowns stay `unknown - ask:`.
+- **Exception path (operating map seed)** - "When the happy path breaks this week, what do people actually do - who do they call, what spreadsheet opens, what do they skip?" Capture the break → workaround → who owns it. Do not build a full map on day 1; seed rows later in `terrain.md` → `## Operating map (exception-led)` during discover. Unknowns stay `unknown - ask:`.
 - **AI posture and policy** - tools already in use (sanctioned or shadow), and: "Does your organisation have a policy on AI-generated code? Are there decisions where you would not be comfortable with AI involvement?"
 - **Boundaries in multi-vendor rooms** - who owns what surface, who signs off before a change crosses it.
 
@@ -119,9 +119,9 @@ If remote: trust-building takes ~40% longer - push for a short video call before
 
 Kickoff at Acme payments. Priya (VP Eng) sponsors; the brief says "add monitoring to the reconciliation service."
 
-Asking what happens the week after a perfect delivery gets: "I stop hearing about it from finance." That is the real success statement — not monitoring. The previous attempt surfaces too: the platform team built alerting last year, it was turned off. Raj, who built it, is still there and was not in the kickoff — the passed-over team, found on day 1 rather than at the first standup.
+Asking what happens the week after a perfect delivery gets: "I stop hearing about it from finance." That is the real success statement - not monitoring. The previous attempt surfaces too: the platform team built alerting last year, it was turned off. Raj, who built it, is still there and was not in the kickoff - the passed-over team, found on day 1 rather than at the first standup.
 
-What gets written: `success.md` with bucket `risk-mitigation`, `reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)`, gaming check `alerting on everything so nobody reads them` → guard `≤2 alerts/week, acked by name`, sign-off Priya. `brief.md` carries the gap list and the hypothesis: *the job is not unmonitored, it is unowned*. `assumptions.md` seeds `"finance would act on an alert" — CRITICAL — OPEN — (stated, unverified)`. `trust-profile.md` records the sacred thing Priya hesitated before naming.
+What gets written: `success.md` with bucket `risk-mitigation`, `reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)`, gaming check `alerting on everything so nobody reads them` → guard `≤2 alerts/week, acked by name`, sign-off Priya. `brief.md` carries the gap list and the hypothesis: *the job is not unmonitored, it is unowned*. `assumptions.md` seeds `"finance would act on an alert" - CRITICAL - OPEN - (stated, unverified)`. `trust-profile.md` records the sacred thing Priya hesitated before naming.
 
 Day-1 deliverable: fix the log line that swallows the job's exit code. Small, visible, in their environment.
 

package/skills/fde/references/multi-customer-ops.md

@@ -70,7 +70,7 @@ The 3-line context update is the bridge. Without it, the next session starts wit
 | Engagement intensity | Status cadence | Touchpoint type |
 |---------------------|---------------|-----------------|
 | Active build (daily work) | Weekly written + ad-hoc Slack | Status update + visible progress |
-| Light touch (2–3 days/week) | Weekly written | Status update + next week's plan |
+| Light touch (2-3 days/week) | Weekly written | Status update + next week's plan |
 | Monitoring only | Bi-weekly written | Health check + any emerging risks |
 
 **The golden rule: no customer should have to chase you for an update.** Proactive status updates are cheaper than reactive ones - and they protect trust across all engagements.

package/skills/fde/references/options-analysis.md

@@ -76,11 +76,11 @@ Present the three options and the recommendation. One question to the FDE: "Whic
 
 Acme: the reconciliation job needs to survive the FDE leaving. Priya asks "so what should we do?"
 
-Three real paths, not a strawman set. **Safe:** keep the job, add the rota and runbook — two weeks, no new failure modes, does nothing about the 47-commits/90d hotspot. **Pragmatic:** extract the settlement-matching step behind a tested interface — six weeks, retires the untested hotspot, needs Raj's time and he currently opposes it. **Aggressive:** rewrite the service — a quarter, fixes everything, and the same team already abandoned this once.
+Three real paths, not a strawman set. **Safe:** keep the job, add the rota and runbook - two weeks, no new failure modes, does nothing about the 47-commits/90d hotspot. **Pragmatic:** extract the settlement-matching step behind a tested interface - six weeks, retires the untested hotspot, needs Raj's time and he currently opposes it. **Aggressive:** rewrite the service - a quarter, fixes everything, and the same team already abandoned this once.
 
 Same dimensions on each, so comparison is instant, and every cost carries a source: the six-week figure is churn-based, not felt.
 
-Recommendation: pragmatic, conditional — *if* Raj is on the design, otherwise safe, because the aggressive path failed here before for exactly the reason it would fail again. `decisions.md` records the decision, who chose it, and the condition, so week 10's "why aren't we rewriting it" has an answer with a date on it.
+Recommendation: pragmatic, conditional - *if* Raj is on the design, otherwise safe, because the aggressive path failed here before for exactly the reason it would fail again. `decisions.md` records the decision, who chose it, and the condition, so week 10's "why aren't we rewriting it" has an answer with a date on it.
 
 ## Principles
 

package/skills/fde/references/plan.md

@@ -30,11 +30,11 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **3. Slice vertically.** Each task delivers something visible and testable end to end ("user submits form, sees it saved"), never a horizontal layer ("build the database layer").
 
-**4. Size to 30–90 minutes, PR-sized.** Longer = two tasks. Each task implementable, testable, reviewable without a thousand-line diff.
+**4. Size to 30-90 minutes, PR-sized.** Longer = two tasks. Each task implementable, testable, reviewable without a thousand-line diff.
 
 **5. AI components get explicit eval tasks.** "Output validated on 50 real production examples," "fallback tested under model unavailability," "inputs/outputs logging to <destination>" - these are pre-conditions of shipping, in the plan before build starts.
 
-**6. Stakeholder touchpoints every 2–3 tasks.** "Show progress to <name from stakeholders.md>." Not ceremony: a customer who sees small wins stays bought in; silence gets filled with doubt.
+**6. Stakeholder touchpoints every 2-3 tasks.** "Show progress to <name from stakeholders.md>." Not ceremony: a customer who sees small wins stays bought in; silence gets filled with doubt.
 
 **7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Cap **Now** at 3 slices (same discipline as initiative-triage).
 
@@ -83,7 +83,7 @@ Every FDE gets asked this in week one. The honest answer is a range, not a numbe
 2. **Expected case** - normal friction: one discovery changes the plan, one integration takes longer, one approval cycle stalls. This is what to plan against.
 3. **Worst case** - a major unknown surfaces, a dependency fails, a key person is unavailable. This is what to protect against.
 
-**Present as:** "2–4 weeks expected, could stretch to 6 if [named risk]." Never give one number.
+**Present as:** "2-4 weeks expected, could stretch to 6 if [named risk]." Never give one number.
 
 **The sizing table:**
 
@@ -135,9 +135,9 @@ Never quietly update tasks. Name the reset: update `reality.md` and `success.md`
 
 Acme, after discover: the reconciliation job is unowned, Marco's spreadsheet is the real fallback.
 
-**Now** is three tasks, not eight. Task 1 is *failures reach a named human* — delivers a page to a rota, accepts "kill the job mid-run → the on-call is paged within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, verify by killing it in staging. Value promised: `risk-mitigation — a silent failure becomes a 15-minute one`.
+**Now** is three tasks, not eight. Task 1 is *failures reach a named human* - delivers a page to a rota, accepts "kill the job mid-run → the on-call is paged within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, verify by killing it in staging. Value promised: `risk-mitigation - a silent failure becomes a 15-minute one`.
 
-The kill list in `decisions.md` is where the plan earns its keep: the rewrite of the reconciliation service that Tom keeps proposing goes there — *deferred, the failure mode is ownership not architecture (Priya accepted, Jun 12)* — along with the finance dashboard finance asked for directly. Both stay visible so the same argument is not re-litigated in week 4 without a receipt.
+The kill list in `decisions.md` is where the plan earns its keep: the rewrite of the reconciliation service that Tom keeps proposing goes there - *deferred, the failure mode is ownership not architecture (Priya accepted, Jun 12)* - along with the finance dashboard finance asked for directly. Both stay visible so the same argument is not re-litigated in week 4 without a receipt.
 
 First visible slice goes to Marco, not Priya: he is the one whose morning changes, and his confirmation is what makes the sponsor update true.
 
@@ -145,7 +145,7 @@ First visible slice goes to Marco, not Priya: he is the one whose morning change
 
 - Plan from success backwards, not from today forwards.
 - Fragile zones early. Fail fast.
-- Every 2–3 tasks, a stakeholder touchpoint. Trust decays without visibility.
+- Every 2-3 tasks, a stakeholder touchpoint. Trust decays without visibility.
 - No written acceptance criteria, no build.
 - No kill list, no finished plan.
 - Estimates are ranges, not promises. Name the assumptions.

package/skills/fde/references/red-team.md

@@ -28,10 +28,10 @@ You are not a helpful peer right now. You are the skeptical senior who has seen
 ```
 CLAIM: <the position under test, one sentence>
 WHY IT MATTERS: <credibility / time / engagement risk if wrong>
-CHALLENGE: <your strongest counter — specific names/dates from .fde/ only>
+CHALLENGE: <your strongest counter - specific names/dates from .fde/ only>
 ```
 
-Wait for their defense. Score it SOLID / THIN / EXPOSED (same scale as step 5). Only then widen into the five angles. If the claim collapses here, stop — the kill list is already clear.
+Wait for their defense. Score it SOLID / THIN / EXPOSED (same scale as step 5). Only then widen into the five angles. If the claim collapses here, stop - the kill list is already clear.
 
 **3. Attack from five angles.** Every plan has five failure surfaces. Hit each one:
 

package/skills/fde/references/review.md

@@ -12,7 +12,7 @@ Thousands of lines or dozens of unrelated files → **stop**, recommend the spli
 
 ## Stage 1 - did we build what we agreed? (you do this work)
 
-Check the diff against the **one-line intent** in `decisions.md` / acceptance criteria — what was *explicitly decided*, not what seems right:
+Check the diff against the **one-line intent** in `decisions.md` / acceptance criteria - what was *explicitly decided*, not what seems right:
 
 ```bash
 git diff <base>...HEAD --stat
@@ -23,9 +23,9 @@ For each touched path (or logical hunk), assign one verdict:
 | Verdict | Meaning |
 |---------|---------|
 | **KEEP** | Required for the stated intent |
-| **JUSTIFY** | Adjacent but must ship now — write one sentence why, or SPLIT |
-| **SPLIT** | Real work for another PR / Next / kill list — do not merge with this slice |
-| **DROP** | Noise / drive-by — revert before Pass |
+| **JUSTIFY** | Adjacent but must ship now - write one sentence why, or SPLIT |
+| **SPLIT** | Real work for another PR / Next / kill list - do not merge with this slice |
+| **DROP** | Noise / drive-by - revert before Pass |
 
 Also check:
 - Any sacred system from `trust-profile.md` touched?
@@ -34,7 +34,7 @@ Also check:
 
 **Stage 1 fails → stop** if any SPLIT/DROP remains, or JUSTIFY lacks a written sentence. Quality review on out-of-scope code is wasted work. Record the mismatch (and the KEEP/JUSTIFY/SPLIT/DROP tally) in `decisions.md`.
 
-Stakeholder "also can you…" mid-build is `scope-defense` — different axis. This stage is **code vs claim**.
+Stakeholder "also can you…" mid-build is `scope-defense` - different axis. This stage is **code vs claim**.
 
 ## Stage 2 - is it safe to live with?
 
@@ -59,7 +59,7 @@ Five dimensions, line-specific ("line 47 fails under concurrent writes - no lock
 
 ## Before the PR - thinking for the next reader
 
-Code alone loses the "why." Before you call the change reviewable, run the **session digest** from the memory contract (SKILL.md On exit): TL;DR, key decisions & rationale, scope + how you verified, gotchas. Confirm with the FDE, then write into `.fde/` — `decisions.md` / `delivery.md` / `context.md`. Reviewers (or Monday-you) should answer "why this approach?" from the fieldbook, not from a chat transcript. Do **not** dump agent logs into the product repo.
+Code alone loses the "why." Before you call the change reviewable, run the **session digest** from the memory contract (SKILL.md On exit): TL;DR, key decisions & rationale, scope + how you verified, gotchas. Confirm with the FDE, then write into `.fde/` - `decisions.md` / `delivery.md` / `context.md`. Reviewers (or Monday-you) should answer "why this approach?" from the fieldbook, not from a chat transcript. Do **not** dump agent logs into the product repo.
 
 ## Artifact
 
@@ -70,7 +70,7 @@ Code alone loses the "why." Before you call the change reviewable, run the **ses
 ## Principles
 
 - Stage 1 before Stage 2. Wrong scope reviewed well is still wrong scope.
-- KEEP / JUSTIFY / SPLIT / DROP — every path gets a verdict; silent extras fail Stage 1.
+- KEEP / JUSTIFY / SPLIT / DROP - every path gets a verdict; silent extras fail Stage 1.
 - Specific or silent - vague concerns waste everyone's time.
 - No rollback path = first finding.
 - A clean review proves this diff is safe as agreed - not that the feature was right.

package/skills/fde/references/scope-defense.md

@@ -38,7 +38,7 @@ Log via `fde log decision "scope change: <summary> - requested by <who>, impact:
 
 **The key phrase: "Let me place it."** Not "that's out of scope" (adversarial) or "sure" (absorbed). "Let me place it" signals you're taking it seriously while buying time to assess the real cost.
 
-**4. The accumulation conversation.** When the scope receipts show a pattern - typically 3–5 absorbed changes - the FDE needs a conversation with the sponsor:
+**4. The accumulation conversation.** When the scope receipts show a pattern - typically 3-5 absorbed changes - the FDE needs a conversation with the sponsor:
 
 Frame it as **protection, not complaint:**
 > "We've absorbed five changes since the original agreement. Each one made sense individually. Together, they've added roughly two weeks. I want to make sure the timeline expectation still matches - should we adjust the delivery date, or reprioritise to keep the original date?"
@@ -67,9 +67,9 @@ Acme, week 5. Nothing has been formally added, and the slice is a week late.
 
 The pattern shows in three receipts, not one argument: a "quick" finance CSV export (Jun 20, half a day, from Denise directly), retry-logic cleanup asked for mid-build (Jun 24, one day, Tom), and a dashboard tile "while you're in there" (Jun 27, half a day). Each was individually reasonable; together they are the slip.
 
-Three-bucket response, applied at the moment of the third ask rather than in a retrospective: the CSV export goes to Next with an accepted trade (it displaces the runbook polish), the retry cleanup goes to the kill list in `decisions.md` with the blast-radius reason, and the tile is absorbed because it is genuinely twenty minutes — logged anyway, since an unlogged absorption is the one that gets forgotten in the accumulation conversation.
+Three-bucket response, applied at the moment of the third ask rather than in a retrospective: the CSV export goes to Next with an accepted trade (it displaces the runbook polish), the retry cleanup goes to the kill list in `decisions.md` with the blast-radius reason, and the tile is absorbed because it is genuinely twenty minutes - logged anyway, since an unlogged absorption is the one that gets forgotten in the accumulation conversation.
 
-That conversation happens with Priya at three receipts, with the dates on screen: "these are the four asks, here is the two days, here is what moved." Not a complaint — a decision she gets to make, with evidence, before the deadline makes it for her.
+That conversation happens with Priya at three receipts, with the dates on screen: "these are the four asks, here is the two days, here is what moved." Not a complaint - a decision she gets to make, with evidence, before the deadline makes it for her.
 
 ## Principles