fdeops 3.15.1 → 3.16.0

package/skills/fde/references/ingest.md

@@ -1,8 +1,8 @@
 # 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).
+**Connect / capability (different entry):** "connect a new MCP", "connect Granola/Slack/Notion", "what can you pull?" → `references/connect.md` first. Recipes: `mcp/recipes/` (file, granola, slack, notion).
 
 **Read first:** `context.md` (what's already logged, what's stale). Bind the engagement before staging anything.
 
@@ -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)?
-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.
+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 `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: `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/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.
 
@@ -99,7 +99,7 @@ If `stakeholders.md` already has a `## Signal history` section (it does from the
 
 **`trust-profile.md`** - sacred data (`<private>` tagged), fears heard, AI policy, approval chain. Sensitive: skip for status reads; use CLI/redacted surfaces; never paste raw `<private>` into prompts or subagents.
 
-**`assumptions.md`** - seed every unverified claim from the brief (and the day-1 hypothesis) as rows with blast radius CRITICAL / LOAD-BEARING / CONVENIENCE and status `OPEN`. Do not wait for assumption-audit - land makes the register exist. Example:
+**`assumptions.md`** - seed every unverified claim from the brief (and the day-1 hypothesis) as rows with blast radius CRITICAL / LOAD-BEARING / CONVENIENCE and status `OPEN`. Do not wait for test-assumptions - land makes the register exist. Example:
 
 ```markdown
 | # | Assumption | Blast radius | How we test | Status | Evidence |
@@ -107,7 +107,7 @@ If `stakeholders.md` already has a `## Signal history` section (it does from the
 | 1 | <claim from brief> | CRITICAL | <cheapest falsifying test> | OPEN | (stated, unverified) |
 ```
 
-One falsifiable hypothesis about the real problem also goes at the bottom of `brief.md` - discover / assumption-audit will test it.
+One falsifiable hypothesis about the real problem also goes at the bottom of `brief.md` - discover / test-assumptions will test it.
 
 ## Checkpoint
 
@@ -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/{initiative-triage.md → pick-three.md}

@@ -1,4 +1,4 @@
-# initiative-triage - when 20 things are "urgent," pick the 3 that matter
+# pick-three - when 20 things are "urgent," pick the 3 that matter
 
 **Enter when:** a transformation engagement with a long list of initiatives, the customer's roadmap has more items than weeks, competing teams want different things, or the FDE needs to recommend what to do *first* across a complex programme.
 
@@ -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/plan.md

@@ -2,7 +2,7 @@
 
 **Enter when:** scope is understood and the work needs breaking down - a slice, a phase, or the whole delivery.
 
-**Read first:** `reality.md`, `success.md`, `terrain.md`, `stakeholders.md`. Load `business-case.md` if sketch produced one. Not the full folder.
+**Read first:** `reality.md`, `success.md`, `terrain.md`, `stakeholders.md`. Load `business-case.md` if poc produced one. Not the full folder.
 
 ## Validation gate (confirm understanding, clarify where it elevates)
 
@@ -22,7 +22,7 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 ## Method (you do this work)
 
-**0. Lock scope first.** Read `success.md` and `assumptions.md`. If out-of-scope is undefined, define it now with the FDE - a plan on undefined scope accumulates silent commitments. If any CRITICAL assumption is still `OPEN`, stop and run assumption-audit / discover before sequencing work.
+**0. Lock scope first.** Read `success.md` and `assumptions.md`. If out-of-scope is undefined, define it now with the FDE - a plan on undefined scope accumulates silent commitments. If any CRITICAL assumption is still `OPEN`, stop and run test-assumptions / discover before sequencing work.
 
 **1. Work backwards from success.** What's the last thing that must be true before done? And before that? That's the dependency chain - not a wish list.
 
@@ -30,13 +30,13 @@ 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).
+**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 pick-three).
 
 **Acceptance criteria gate:** no task moves to build without written happy-path AND unhappy-path criteria. Can't write them = the task isn't understood; the open question goes to the customer **before** the task starts. Vague criteria surface later as scope creep and rework.
 
@@ -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/{sketch.md → poc.md}

@@ -1,6 +1,6 @@
-# sketch - prototype to kill or confirm a direction
+# poc - kill or confirm a direction in a day
 
-**Enter when:** a direction needs validating before committing real build time - show something, de-risk, pick between use cases.
+**Enter when:** a direction needs validating before committing real build time - POC, spike, show something, de-risk, pick between use cases. The output is something a sponsor can reject in a room this week, not a polished product.
 
 **Read first:** `context.md`, `reality.md`. Load `terrain.md` only if the prototype touches the existing codebase.
 
@@ -10,7 +10,7 @@
 
 **1. Pick by score when several use cases compete.** Use the scoring model from `discover.md` - (Value × Data readiness) / Complexity. If discover already scored, reuse; never re-score independently.
 
-**2. Build the minimum that tests the assumption.** No error handling, no tests, no polish. Same-day demo if possible. Rough is honest - polish tricks people into believing it's further along than it is.
+**2. Build the minimum that tests the assumption.** No error handling, no polish. Same-day demo if possible. Rough is honest. The POC is done when the person who can say no has seen it and reacted, not when the code looks finished.
 
 **3. AI directions - test these before anything else:**
 - Data: available, clean, sufficient volume? Synthetic-data prototypes say nothing about production behaviour.
@@ -20,7 +20,7 @@
 
 **4. Kill it immediately if:** the assumption is disproven · the customer ignores it (indifference is a signal, not neutrality) · 3 iterations and feedback isn't converging · it works but the customer can't explain or trust the output (unexplainable AI in a high-stakes context is not a solution). When killed: write down what was *learned*, not what was built. The learning is the asset.
 
-**5. Translate to business language** once validated: problem solved, cost of inaction, success in numbers, 2–3 trade-offs. Three sentences max for the stakeholder - can't say it in three, don't understand it yet.
+**5. Translate to business language** once validated: problem solved, cost of inaction, success in numbers, 2-3 trade-offs. Three sentences max for the stakeholder - can't say it in three, don't understand it yet.
 
 ## Artifact
 

package/skills/fde/references/{status.md → readout.md}

@@ -1,4 +1,4 @@
-# status - the sponsor update that keeps the engagement alive
+# readout - the sponsor update that keeps the engagement alive
 
 **Enter when:** the weekly update is due, an exec asks "where are we," or the FDE says "I need to send Dana something." This artifact decides renewals; engineers underinvest in it.
 
@@ -6,16 +6,16 @@
 
 ## Method (you do this work)
 
-**First:** run `fde status`. It prints the value ledger before trust — promised → measured → accepted by, or `claimed, not yet accepted`. Those lines are the Situation. Do not invent a number the CLI did not print.
+**First:** run `fde status`. It prints the value ledger before trust - promised → measured → accepted by, or `claimed, not yet accepted`. Those lines are the Situation. Do not invent a number the CLI did not print.
 
 **Always draft in SCQA.** One page maximum. No other shape.
 
 | Block | What to write | Source |
 |-------|---------------|--------|
-| **S — Situation** | Where we are against `success.md`, in their words | success.md, delivery value ledger |
-| **C — Complication** | What changed, what is at risk, or what we learned (bad news first) | risks.md, assumptions DISPROVED/OPEN, stakeholders signal |
-| **Q — Question / Ask** | The one decision or help you need from them | decisions.md, access/sign-off needs |
-| **A — Answer** | What you recommend / what happens next week (≤3 bullets) | plan Now lane, delivery promised→measured |
+| **S - Situation** | Where we are against `success.md`, in their words | success.md, delivery value ledger |
+| **C - Complication** | What changed, what is at risk, or what we learned (bad news first) | risks.md, assumptions DISPROVED/OPEN, stakeholders signal |
+| **Q - Question / Ask** | The one decision or help you need from them | decisions.md, access/sign-off needs |
+| **A - Answer** | What you recommend / what happens next week (≤3 bullets) | plan Now lane, delivery promised→measured |
 
 Then add, still on the same page:
 1. **Value this week** - from the value ledger: promised → measured (or "pending") → **accepted by whom**, with evidence citation. A measured number nobody on the customer side has agreed to is written as `claimed`, and the Ask never rests on it - if the whole case for the next phase is a claimed number, the real ask this week is "who signs off that this is real?".
@@ -24,7 +24,7 @@ Then add, still on the same page:
 
 Exec voice: no jargon, no hedging, every claim traceable (`(shipped Tue, delivery.md)`). Draft in the **FDE's voice, for the FDE to send** - never send anything yourself.
 
-For board / renewal / sponsor's boss (longer pyramid): use `exec-narrative.md`. Do not invent a second weekly format.
+For board / renewal / sponsor's boss (longer pyramid): use `board-memo.md`. Do not invent a second weekly format.
 
 ## Artifact
 
@@ -36,7 +36,7 @@ Append the draft to `delivery.md` under `## Status - <date>` using the SCQA head
 **C:** ...
 **Q:** ...
 **A:** ...
-**Value ledger:** promised … / measured … / accepted by … (evidence) — or `claimed, unaccepted`
+**Value ledger:** promised … / measured … / accepted by … (evidence) - or `claimed, unaccepted`
 **Kill list reminder:** …
 **Hostile Qs:** 1) … 2) … 3) …
 ```
@@ -49,9 +49,9 @@ Walk the FDE through the Complication and the Ask - confirm the framing matches
 
 Acme, week 3, Priya's Friday update.
 
-**S:** failure routing is live; detection is 12 min against the 4h baseline in `success.md`. **C** leads with the bad news, not the win: the second incident was acked 40 minutes late because the rota has one name on it, and that name was on leave. **Q:** one ask — a second name on the rota by Wednesday. **A:** three bullets, top of the Now lane.
+**S:** failure routing is live; detection is 12 min against the 4h baseline in `success.md`. **C** leads with the bad news, not the win: the second incident was acked 40 minutes late because the rota has one name on it, and that name was on leave. **Q:** one ask - a second name on the rota by Wednesday. **A:** three bullets, top of the Now lane.
 
-Value ledger line: `promised 4h → 15min / measured 12min over 2 incidents / accepted by — (Marco confirmed operationally, finance not yet)` → written as `claimed, unaccepted`, which is what makes the Ask honest rather than a victory lap.
+Value ledger line: `promised 4h → 15min / measured 12min over 2 incidents / accepted by - (Marco confirmed operationally, finance not yet)` → written as `claimed, unaccepted`, which is what makes the Ask honest rather than a victory lap.
 
 Hostile Q prep, from memory not imagination: "why did we pay for alerting we already had?" → the receipt from `decisions.md` and the disabled-alerting finding in `reality.md`. Kill list reminder: the service rewrite is still deferred, accepted by Priya on Jun 12.
 

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/rescue.md

@@ -46,7 +46,7 @@ Customers remember who told them the truth before it cost them money.
 
 ## D. Pivot - the whole direction changed
 
-Not scope-defense (that's someone adding). This is: budget cut, new CTO arrives, strategic priority shift, acquisition changes everything, "we've decided to go a different direction." The engagement's foundation moved.
+Not hold-scope (that's someone adding). This is: budget cut, new CTO arrives, strategic priority shift, acquisition changes everything, "we've decided to go a different direction." The engagement's foundation moved.
 
 **Signals:** new leadership asks "why are we doing this?", the sponsor's boss questions ROI, a competing initiative gets the resources, the quarterly priorities deck doesn't mention your project, the team you're embedded in gets reorganized.
 

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 `hold-scope` - 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/{rollback-drill.md → rollback.md}

@@ -1,4 +1,4 @@
-# rollback-drill - test the escape route before you need it
+# rollback - test the escape route before you need it
 
 **Enter when:** a deploy is planned for the next 48 hours, the FDE says "we can always revert," a previous rollback failed or took too long, or the engagement involves regulated/critical systems.
 

package/skills/fde/references/{handoff-engineering.md → runbook.md}

@@ -1,4 +1,4 @@
-# handoff-engineering - making yourself replaceable is the goal
+# runbook - making yourself replaceable is the goal
 
 **Enter when:** the engagement is entering its final phase, the customer team needs to operate without the FDE, a new FDE is taking over, or the sponsor asks "what happens when you leave?"
 
@@ -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? |
@@ -103,9 +103,9 @@ Rollback: <exact command and expected time>
 - [ ] All access returned or transferred (repos, environments, admin panels)
 - [ ] No personal credentials left in the system (API keys, tokens, SSH keys)
 - [ ] `.fde/` folder handed to the successor or archived with the team
-- [ ] Final status sent to sponsor (see `status.md`)
+- [ ] Final status sent to sponsor (see `readout.md`)
 - [ ] Retrospective completed (see `close.md`)
-- [ ] Patterns extracted (see `pattern-extract.md`)
+- [ ] Patterns extracted (see `encode-pattern.md`)
 
 ## Artifact
 

package/skills/fde/references/{use-case-scoring.md → score-use-cases.md}

@@ -1,8 +1,8 @@
-# use-case-scoring - pick the right battle, not the interesting one
+# score-use-cases - pick the right battle, not the interesting one
 
 **Enter when:** multiple potential use cases compete for attention, the customer says "we want to do everything," a transformation engagement needs a starting point, or the FDE needs to recommend which problem to solve first.
 
-**Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from sketch, load those - they carry forward.
+**Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from poc, load those - they carry forward.
 
 The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
 
@@ -10,7 +10,7 @@ The most dangerous moment in a multi-use-case engagement is when the technically
 
 **1. List every candidate.** From the brief, from discovery conversations, from the FDE's own observations. Include the ones the customer hasn't said aloud but the codebase implies - a high-churn module with no tests is a candidate even if nobody named it.
 
-**2. Score on five dimensions.** Each 1–5, with the scoring rubric below:
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below:
 
 | Dimension | 1 | 3 | 5 |
 |-----------|---|---|---|
@@ -59,7 +59,7 @@ Why this formula:
 
 ## Checkpoint
 
-Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to sketch or plan.
+Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to poc or plan.
 
 ## Principles
 

package/skills/fde/references/ship.md

@@ -47,7 +47,7 @@ Score each dimension green/amber/red. This is the gate, not a suggestion:
 | Dimension | Green | Amber | Red |
 |-----------|-------|-------|-----|
 | **Value bucket** | `success.md` names primary bucket (`cost-save` \| `risk-mitigation` \| `revenue-uplift`) and a baseline→target metric; this slice’s value-ledger row has **Bucket** + **Promised** | Bucket named; **Measured** still `pending` with a pulse date | No bucket, or Promised empty / ticket-theater only |
-| **Audit receipt** | Dated line in `delivery.md` (`## Ship receipts` or ledger Evidence) proving exceptions/operating path were walked — cite `terrain.md` / `reality.md` / `audit.md` | Path described, not verified this ship | No audit receipt for this slice |
+| **Audit receipt** | Dated line in `delivery.md` (`## Ship receipts` or ledger Evidence) proving exceptions/operating path were walked - cite `terrain.md` / `reality.md` / `audit.md` | Path described, not verified this ship | No audit receipt for this slice |
 | **Eval receipt** | **n/a** (no AI on this slice) **or** `evals.md` Verdict SHIP with dated golden run + HITL gate named | Eval pack exists; known fails open with owner + date | AI in scope and no eval receipt |
 | **AI eval pack** | `.fde/evals.md` Verdict SHIP; goldens run this change; critical fails 0; HITL filled if policy requires | Pack exists; run stale vs change log | AI-touching deploy and pack missing / NO-SHIP / HITL required but empty |
 
@@ -59,13 +59,13 @@ Score each dimension green/amber/red. This is the gate, not a suggestion:
 2. If Verdict is not **SHIP**, or Last run is older than the latest change-log row → **RED.**
 3. If `trust-profile.md` requires human-in-the-loop and the HITL gate has no reviewer → **RED.**
 4. Log in `delivery.md` → `## Ship receipts` before deploy: audit cite + eval receipt.
-5. Non-AI deploys: Eval = **n/a** — do not invent an empty pack.
+5. Non-AI deploys: Eval = **n/a** - do not invent an empty pack.
 
 Write the readiness score (including value + receipts) to `delivery.md` before deploying. The score is the evidence if anything goes wrong.
 
 ## Intent vs diff (before pre-blast)
 
-Ship the change you intended — not the drift that snuck in. Run this on the deploy branch against the **one-line intent** from `decisions.md` / `success.md` (the slice you said you were building).
+Ship the change you intended - not the drift that snuck in. Run this on the deploy branch against the **one-line intent** from `decisions.md` / `success.md` (the slice you said you were building).
 
 ```bash
 git diff <base>...HEAD --stat
@@ -77,22 +77,22 @@ Score every touched path (or logical hunk):
 | Path / change | Verdict | Rule |
 |---------------|---------|------|
 | | **KEEP** | Directly required for the stated intent |
-| | **JUSTIFY** | Adjacent but load-bearing — one sentence why it must ship *now*, or split |
-| | **SPLIT** | Real work, wrong PR — park in `decisions.md` kill/Next; do not deploy with this slice |
-| | **DROP** | Noise (format-only, drive-by rename, unrelated tidy) — revert before ship |
+| | **JUSTIFY** | Adjacent but load-bearing - one sentence why it must ship *now*, or split |
+| | **SPLIT** | Real work, wrong PR - park in `decisions.md` kill/Next; do not deploy with this slice |
+| | **DROP** | Noise (format-only, drive-by rename, unrelated tidy) - revert before ship |
 
-**Any SPLIT or DROP still in the tree = fix-first.** JUSTIFY without a written sentence = treat as SPLIT. Log a one-line receipt in `delivery.md`: `intent vs diff: KEEP n · JUSTIFY n · SPLIT n · DROP n — <intent>`.
+**Any SPLIT or DROP still in the tree = fix-first.** JUSTIFY without a written sentence = treat as SPLIT. Log a one-line receipt in `delivery.md`: `intent vs diff: KEEP n · JUSTIFY n · SPLIT n · DROP n - <intent>`.
 
-This is **code drift**, not stakeholder "also can you…" (that is `scope-defense`). Same family as review Stage 1 — ship refuses green when the diff outgrew the claim.
+This is **code drift**, not stakeholder "also can you…" (that is `hold-scope`). Same family as review Stage 1 - ship refuses green when the diff outgrew the claim.
 
 ## Pre-blast challenge (before the deploy button)
 
-For any non-trivial go-live (shared infra, regulated data, irreversible migration, or first prod touch), run this once before canary — not as theater, as a stop-the-line check:
+For any non-trivial go-live (shared infra, regulated data, irreversible migration, or first prod touch), run this once before canary - not as theater, as a stop-the-line check:
 
 ```
 CLAIM: <what you are about to ship, in one sentence>
 WHY IT MATTERS: <blast radius / who feels pain if wrong>
-CHALLENGE: <the strongest argument this is not ready — grounded in delivery.md / risks.md / trust-profile.md>
+CHALLENGE: <the strongest argument this is not ready - grounded in delivery.md / risks.md / trust-profile.md>
 VERDICT: proceed | fix-first | sponsor conversation
 ```
 
@@ -116,11 +116,11 @@ grep -rnE "(api[_-]?key|secret|password|token)\s*[:=]\s*['\"][^'\"]{8,}" \
 
 ## Method - the deploy
 
-**Canary:** 1–5% of traffic, ≥10 minutes. Watch error rate, latency, and **the business metric this change affects**. Anything looks wrong → roll back immediately; investigate safely; redeploy when confident. Never investigate during the canary. Then stage up: 5% → 25% → 100%, each confirmed stable.
+**Canary:** 1-5% of traffic, ≥10 minutes. Watch error rate, latency, and **the business metric this change affects**. Anything looks wrong → roll back immediately; investigate safely; redeploy when confident. Never investigate during the canary. Then stage up: 5% → 25% → 100%, each confirmed stable.
 
 **Programme-scale rollout (transformations)** - different problem from one service:
 1. **Pilot** - one team, one use case; success metrics defined *before* it starts (after = fitting metrics to results).
-2. **Limited release** - 3–5 teams, real load; this is where the failure modes the pilot hid show up.
+2. **Limited release** - 3-5 teams, real load; this is where the failure modes the pilot hid show up.
 3. **Broad release** - self-serve onboarding; if teams still need the FDE to start, onboarding isn't finished.
 4. **Enterprise standard** - the FDE is no longer needed for this use case. That's the end state.
 Straight from pilot to standard = a high-profile failure at scale.
@@ -156,7 +156,7 @@ AI components: also define what *normal output* looks like and check a weekly sa
 
 **The scale sequence:**
 1. **Pilot** (1 team, controlled) → prove value, find failure modes
-2. **Limited** (3–5 teams, real load) → prove operability, find scale bugs
+2. **Limited** (3-5 teams, real load) → prove operability, find scale bugs
 3. **Broad** (self-serve onboarding) → prove the team doesn't need the FDE
 4. **Standard** (enterprise default) → the FDE exits this workstream
 
@@ -172,7 +172,7 @@ Adoption isn't a handoff-stage problem - it starts during build. Software that l
 - **Resistance signals.** Watch for: workaround creation (they built a spreadsheet instead of using the tool), drop-off after day 3 (onboarding fails), vocal detractors (one influential skeptic can kill adoption). Address these DURING build, not after launch.
 
 **At launch:**
-- **Champion network.** Identify 2–3 power users per team who adopt early. Support them intensely - they become your multiplier.
+- **Champion network.** Identify 2-3 power users per team who adopt early. Support them intensely - they become your multiplier.
 - **30-60-90 adoption targets.** Week 1: 20% of target users try it. Week 4: 50% use it weekly. Week 12: 80% can't imagine working without it. If week 1 misses → the onboarding is broken. If week 4 misses → the value proposition is wrong.
 - **The "switching cost" test.** If users can still do it the old way, they will. Adoption requires either: the old way is removed, the new way is dramatically better, or management mandates the switch. Know which lever applies.
 
@@ -190,9 +190,9 @@ Before 100%: canary clean, business metric verified, pulse written into `deliver
 
 Acme, shipping the failure-routing slice into a payments environment on a Thursday.
 
-Readiness scoring catches two things the diff does not. The audit receipt is missing: the operating map says Marco's manual re-run is the fallback, and nobody has checked whether the new page fires *before* his morning run or after — if after, the alert changes nothing. That gets walked and cited before deploy. Second, the intent-vs-diff read shows the PR also touches the settlement retry that was deferred in build; it comes out.
+Readiness scoring catches two things the diff does not. The audit receipt is missing: the operating map says Marco's manual re-run is the fallback, and nobody has checked whether the new page fires *before* his morning run or after - if after, the alert changes nothing. That gets walked and cited before deploy. Second, the intent-vs-diff read shows the PR also touches the settlement retry that was deferred in build; it comes out.
 
-Pre-blast challenge: "what does this break if it fires at 3am and nobody acks?" Answer: nothing breaks, but the rota is not yet agreed — so the deploy waits on a name, not on code. That is a one-day slip that prevents a fake green.
+Pre-blast challenge: "what does this break if it fires at 3am and nobody acks?" Answer: nothing breaks, but the rota is not yet agreed - so the deploy waits on a name, not on code. That is a one-day slip that prevents a fake green.
 
 After deploy: `delivery.md` ship receipt with the audit cite, the kill test evidence, and the rollback line. Eval receipt: n/a, no AI in this path.
 

package/skills/fde/references/{multi-customer-ops.md → switch-clients.md}

@@ -1,4 +1,4 @@
-# multi-customer-ops - juggling engagements without dropping any
+# switch-clients - juggling engagements without dropping any
 
 **Enter when:** the FDE is running 2+ engagements simultaneously, context-switching is causing mistakes or delays, a new customer is being onboarded while existing engagements are active, or the FDE says "I'm losing track."
 
@@ -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.