fdeops 3.9.20 → 3.10.2

package/mcp/recipes/granola.md

@@ -2,16 +2,19 @@
 
 **Use when:** meeting notes live in Granola (or a similar notes MCP). FDEOps does not ship a Granola server — you add whichever MCP/export path you trust.
 
+Daily path if the notes are already in chat or on disk: paste to `@fde debrief` or [file.md](./file.md). This recipe is only for **pull**.
+
 ## Setup (once)
 
-1. Install / enable a **Granola (or notes) MCP** in Cursor/Claude per that product’s docs.
-2. Add the FDEOps **sink** MCP (`fdeops-ingest`) — [../fdeops-ingest/README.md](../fdeops-ingest/README.md).
-3. Reload MCP / restart the agent host.
-4. Test: `@fde what can you pull?` — agent should see both sink tools and the notes source tools.
+1. Enable a **Granola (or notes) MCP** in Cursor/Claude per that product’s docs.
+2. Reload MCP / restart the host.
+3. Test: `@fde what can you pull?` — notes-source tools should appear.
+
+The sink is **`fde ingest` in this bound workspace.** You do not need `fdeops-ingest` MCP for daily pull.
 
 ### Example mcp.json shape (illustrative)
 
-Replace `granola-mcp` command/args with whatever the real server documents. FDEOps only needs *some* tool that returns transcript text.
+Replace command/args with whatever the real Granola MCP documents. FDEOps only needs *some* tool that returns transcript text.
 
 ```json
 {
@@ -22,19 +25,12 @@ Replace `granola-mcp` command/args with whatever the real server documents. FDEO
       "env": {
         "GRANOLA_API_KEY": "from-your-secrets"
       }
-    },
-    "fdeops-ingest": {
-      "command": "node",
-      "args": ["/absolute/path/to/fdeops/mcp/fdeops-ingest/server.js"],
-      "env": {
-        "FDEOPS_ENGAGEMENT": "/Users/you/fde-engagements/acme/.fde"
-      }
     }
   }
 }
 ```
 
-**No Granola MCP available?** Export transcript to a file → follow [file.md](./file.md).
+**No Granola MCP available?** Export transcript to a file → [file.md](./file.md).
 
 ## Pull phrase
 
@@ -44,15 +40,15 @@ Replace `granola-mcp` command/args with whatever the real server documents. FDEO
 
 ## Agent steps
 
-1. Capability check — if no notes/Granola tools, run connect flow (`ingest-connect.md`).
-2. Fetch transcript via source MCP (or ask which meeting).
-3. `ingest_stage` / `fde ingest stage --source granola --title "…"`.
-4. Propose → confirm → apply. Never auto-apply.
+1. Capability check — notes-source tools present?
+2. Fetch transcript text (ask which meeting if ambiguous).
+3. `fde ingest stage --source granola --title "<short>"` then propose → confirm → apply.
+4. Extract decisions/risks/next — do not dump the raw transcript into `.fde/`.
 
 ## Common fails
 
 | Symptom | Fix |
 |---------|-----|
-| Agent says it can’t reach Granola | MCP not saved / host not reloaded / wrong env key |
-| Wrong client inbox | Set `FDEOPS_ENGAGEMENT` or bind workspace (`fde resume --init`) |
-| Empty propose | Agent must rewrite `.debrief-propose` with type prefixes |
+| No Granola tools | Source MCP not loaded — they save + reload |
+| Wrong meeting | One clarifying question, then fetch |
+| Wrong engagement | `fde resume` in this workspace before staging |

package/mcp/recipes/notion.md

@@ -1,13 +1,14 @@
 # Recipe: Notion docs / meeting notes
 
-**Use when:** useful engagement notes live in Notion. FDEOps does not ship a Notion server — use a Notion MCP (or export markdown).
+**Use when:** useful engagement notes live in Notion. FDEOps does not ship a Notion server — use a Notion MCP (or export markdown). We do not write back to Notion.
 
 ## Setup (once)
 
-1. Enable a **Notion MCP** (official or community) with a token that can read the pages you need.
-2. Add **fdeops-ingest** sink — [../fdeops-ingest/README.md](../fdeops-ingest/README.md).
-3. Reload MCP / restart host.
-4. Test: `@fde what can you pull?`
+1. Enable a **Notion MCP** (official or community) with a token that can **read** the pages you need.
+2. Reload MCP / restart host.
+3. Test: `@fde what can you pull?`
+
+The sink is **`fde ingest` in this bound workspace.** `fdeops-ingest` MCP is optional.
 
 ### Example mcp.json shape (illustrative)
 
@@ -20,13 +21,6 @@
       "env": {
         "NOTION_TOKEN": "from-your-secrets"
       }
-    },
-    "fdeops-ingest": {
-      "command": "node",
-      "args": ["/absolute/path/to/fdeops/mcp/fdeops-ingest/server.js"],
-      "env": {
-        "FDEOPS_ENGAGEMENT": "/Users/you/fde-engagements/acme/.fde"
-      }
     }
   }
 }
@@ -42,15 +36,19 @@
 
 ## Agent steps
 
-1. Capability check — Notion tools present?
-2. Fetch page/block text via Notion MCP (ask which page if ambiguous).
-3. Stage with `--source notion`.
-4. Propose → confirm → apply.
+1. Capability check — Notion read tools present?
+2. Fetch page/block text (ask which page if ambiguous).
+3. `fde ingest stage --source notion --title "<short>"` → propose → confirm → apply.
+
+## Never
+
+- Create or edit Notion pages from FDEOps.
+- Ambient-sync a database.
 
 ## Common fails
 
 | Symptom | Fix |
 |---------|-----|
 | 401 / forbidden | Token lacks access to that workspace/page |
-| Huge page dump | Stage full text in `.inbox/`; propose only short dated facts |
-| Wrong engagement | Bind / `FDEOPS_ENGAGEMENT` |
+| Huge page dump | Stage full text in `.inbox/`; apply only short dated facts |
+| Wrong engagement | Bind this workspace before staging |

package/mcp/recipes/slack.md

@@ -0,0 +1,61 @@
+# Recipe: Slack (pull only)
+
+**Use when:** useful context lives in a Slack thread or channel. FDEOps does **not** ship a Slack server, does **not** post messages, and does **not** sync channels.
+
+You add whatever Slack MCP your host already supports. We only accept **text you pulled**, then the same confirm loop as a debrief.
+
+## Setup (once)
+
+1. Enable a **Slack MCP** (official or community) with read access to the threads you need.
+2. Reload MCP / restart the host.
+3. Test: `@fde what can you pull?` — Slack fetch tools should appear. The FDEOps **CLI** (`fde ingest`) is the sink if this workspace is bound; you do not need `fdeops-ingest` MCP for daily use.
+
+### Example mcp.json shape (illustrative)
+
+Replace the Slack server with whatever that MCP actually documents. Do not invent a package name.
+
+```json
+{
+  "mcpServers": {
+    "slack": {
+      "command": "npx",
+      "args": ["-y", "YOUR-SLACK-MCP-PACKAGE"],
+      "env": {
+        "SLACK_BOT_TOKEN": "from-your-secrets"
+      }
+    }
+  }
+}
+```
+
+Optional sink MCP (only if you are not running `fde ingest` from this workspace): see [../fdeops-ingest/README.md](../fdeops-ingest/README.md). Pass `engagement` as the path to this client's `.fde/` (from `fde resume --bind`).
+
+**No Slack MCP?** Copy the thread to a file or paste into chat → [file.md](./file.md) or `@fde debrief`.
+
+## Pull phrase
+
+```text
+@fde pull yesterday's #acme-launch thread into the fieldbook
+```
+
+## Agent steps
+
+1. Capability check — Slack **read** tools present? If not → this recipe, then stop.
+2. Fetch the thread/channel as **text** (ask which channel/thread if ambiguous).
+3. `fde ingest stage --source slack --title "<short>"` (CLI in this bound workspace).
+4. Propose → FDE confirms → apply. Extract decisions/risks/asks — do not dump the thread into `.fde/`.
+
+## Never
+
+- Post, reply, or react in Slack from FDEOps.
+- Background-sync a channel.
+- Auto-apply.
+
+## Common fails
+
+| Symptom | Fix |
+|---------|-----|
+| No Slack tools | Source MCP not loaded — they save + reload; we cannot silent-install |
+| Missing channel | Token/scopes cannot read that workspace — their Slack admin, not FDEOps |
+| Huge dump | Stage full text in `.inbox/`; apply only short dated facts |
+| Wrong client | Bind this workspace (`fde resume`) before staging |

package/mcp.json

@@ -0,0 +1,10 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
+  "mcpServers": {
+    "fdeops-ingest": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["${PLUGIN_ROOT}/mcp/fdeops-ingest/server.js"]
+    }
+  }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops",
-  "version": "3.9.20",
+  "version": "3.10.2",
   "description": "Field kit for engineers embedded in client work - a real CLI (recon, memory, portfolio), one @fde skill with field judgment on top, and hooks that make it automatic. Claude Code plugin and any agent that loads skills.",
   "bin": {
     "fdeops": "bin/install.js",
@@ -20,7 +20,9 @@
     "adapters/",
     "mcp/",
     "CLAUDE.md.template",
-    "AGENTS.md"
+    "AGENTS.md",
+    "plugin.json",
+    "mcp.json"
   ],
   "keywords": [
     "claude-code",

package/plugin.json

@@ -0,0 +1,21 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "fdeops",
+  "version": "3.10.2",
+  "description": "Engagement fieldbook for Forward Deployed Engineers: per-client memory in local .fde/ files, one @fde skill, land to close methodology. Local-only, no network.",
+  "author": {
+    "name": "Subash Natarajan",
+    "url": "https://github.com/suboss87"
+  },
+  "homepage": "https://fdeops.io/",
+  "repository": "https://github.com/suboss87/FDEOps",
+  "license": "MIT",
+  "keywords": [
+    "fde",
+    "forward-deployed",
+    "engagement-memory",
+    "client-work",
+    "consulting",
+    "brownfield"
+  ]
+}

package/skills/fde/SKILL.md

@@ -83,8 +83,8 @@ When NOT to interrogate or challenge: unambiguous one-liners, mechanical ops, FD
 | (session entry / where are we) | `fde resume` or use injected TRIAGE; `fde resume --init <name>` only if unbound |
 | Day-1 look at the repo | `fde scan` - then you interpret against the brief |
 | "Debrief these notes" / pastes meeting notes | Prefer `fde debrief --smart <notes>` → **you** (the agent) rewrite `.debrief-propose` with `decision:`/`risk:`/`delivery:`/`contact:`/`next:` prefixes where needed → show FDE → on confirm `fde debrief --apply`. `--smart` is a prefix/keyword gate, not a brain. Fallback: structure prefixed lines yourself, show FDE, then `fde debrief` |
-| "Make sure we're up to date" / "pull relevant info" / "pull from Granola/email/transcript" | Bind engagement; **capability check** (which source MCPs exist this session — never pretend). If missing → connect flow. Else fetch → `fde ingest stage` → `fde ingest propose` → rewrite prefixes → show FDE → on confirm `fde ingest apply`. **Never auto-apply. Never ambient sync.** Detail: `references/ingest.md` |
-| "Connect a new MCP" / "connect Granola/Notion" / "what can you pull?" | Follow `references/ingest-connect.md`: ask which source → emit `mcp.json` from `mcp/recipes/` + sink block → they save/reload in Cursor/Claude → verify tools → optional test stage to `.inbox/` only. You cannot silently install host MCPs. |
+| "Make sure we're up to date" / "pull relevant info" / "pull from Granola/Slack/transcript" | Bind engagement; **capability check** (which *source* MCPs exist — never pretend). If missing → connect flow. Else fetch text → `fde ingest stage` **in this workspace** → propose → rewrite prefixes → show FDE → on confirm `fde ingest apply`. MCP sink is optional; if used, pass `engagement` from `fde resume --bind`. **Never auto-apply. Never push. Never ambient sync.** Detail: `references/ingest.md` |
+| "Connect a new MCP" / "connect Granola/Slack/Notion" / "what can you pull?" | Follow `references/ingest-connect.md`: source MCP only; sink is `fde ingest` here. They save/reload; you cannot silent-install. Paste still works with no MCP. |
 | "Prep me for the meeting with …" / walk-in brief | `fde prep "<short label>"` - present the brief in plain language; do not invent facts missing from `.fde/` |
 | "When did we agree…?" / scope dispute | `fde receipts <term>` - answer with dates; no hit = gap, not proof |
 | "Draft the sponsor update" / how are we doing | `fde status` then follow `references/status.md` for the narrative |
@@ -271,8 +271,8 @@ Running the engagement and ending it well.
 | Weekly update due, "need to send the sponsor something" | status | `references/status.md` |
 | Demo coming up, show-and-tell, exec walkthrough | demo-prep | `references/demo-prep.md` |
 | Just out of a meeting, raw notes, "they said…", "debrief" | debrief | the debrief verb (above) + `references/debrief.md` |
-| Make sure we're up to date, pull what's relevant, fetch from Granola/Gmail/transcript | ingest | `references/ingest.md` (capability check → stage → propose → confirm → apply) |
-| Connect a new MCP / connect Granola or Notion / what can you pull | ingest-connect | `references/ingest-connect.md` (+ `mcp/recipes/`) |
+| Make sure we're up to date, pull what's relevant, fetch from Granola/Slack/Gmail/transcript | ingest | `references/ingest.md` (capability check → stage → propose → confirm → apply) |
+| Connect a new MCP / connect Granola Slack or Notion / what can you pull | ingest-connect | `references/ingest-connect.md` (+ `mcp/recipes/`) |
 | Prep me for a meeting / walk-in brief / "what should I know before I talk to…" | - | run `fde prep "<label>"`, present in plain language |
 | Sponsor's boss needs a summary, board update, justify continued investment | exec-narrative | `references/exec-narrative.md` |
 | Status across all my customers | dashboard | `references/dashboard.md` |

package/skills/fde/references/assumption-audit.md

@@ -72,6 +72,16 @@ Status values: `OPEN` · `TESTING` · `CONFIRMED` · `DISPROVED` · `PARKED`. A
 
 Tell the FDE: how many assumptions extracted, how many critical, which ones were tested, which changed the direction. If a critical assumption is disproved: recommend the next move (rescope, pivot, or the conversation with the sponsor) before the FDE asks. If any CRITICAL remains OPEN: do not route to plan.
 
+## Worked example
+
+Acme's brief reads cleanly, which is the signal.
+
+Extracted assumptions include one nobody said aloud: *finance would act on an alert*. The whole plan rests on it, and the evidence behind it is a sentence in a kickoff. Blast radius CRITICAL — if false, alerting changes nothing and the engagement delivers a page nobody answers.
+
+Validation is a test, not a discussion, and it is cheap: send one real failure notification to the finance channel and watch what happens. It goes first because highest blast radius × cheapest test is the killer test.
+
+Result: acked in 40 minutes, by Marco, not finance. Assumption DISPROVED, and the plan changes before six weeks are spent on it — the alert needs a rota with an owner, which is a different piece of work than the one that was funded. `assumptions.md` records the status, the evidence, and the date; the finding is presented to the FDE as a fact base, not as "the brief was wrong".
+
 ## Principles
 
 - Every "just" is an assumption. Every "should" is an assumption.

package/skills/fde/references/build.md

@@ -127,12 +127,24 @@ The FDE's job is to make themselves replaceable. Not at handoff - every day. A c
 
 - **`decisions.md`** - each significant choice: what, alternatives considered, why this one. For non-trivial architecture decisions, present three options to the FDE (safe / pragmatic / aggressive) with costs and a recommendation - three options is a real decision; one option is a request for trust. Integration contracts go here too.
 - **`risks.md`** - new risks discovered while building.
-- **`delivery.md`** - append a **value ledger** row for every ship: Date | Slice | Bucket | Promised | Measured | Evidence | Rollback. Bucket is `cost-save` / `risk-mitigation` / `revenue-uplift`. "Measured" may be `pending` until the pulse exists - never skip the promised column. Narrative under Shipped is optional color; the ledger is the record status and close read.
+- **`delivery.md`** - append a **value ledger** row for every ship: Date | Slice | Bucket | Promised | Measured | Accepted by | Evidence | Rollback. Bucket is `cost-save` / `risk-mitigation` / `revenue-uplift`. "Measured" may be `pending` until the pulse exists - never skip the promised column. Narrative under Shipped is optional color; the ledger is the record status and close read.
+
+  **Measured is not the same as accepted.** A number the FDE calculated is `claimed` until a named customer-side owner agrees it is real - their finance lead, their ops manager, the person whose budget it moves. Write the name and the date in **Accepted by**; leave it empty and the row reads `claimed`, never "delivered". This is the difference between a benefit that survives the renewal conversation and one the sponsor's CFO deletes in the review.
 
 ## Checkpoint
 
 Before merge: the two-stage review (scope, then safety) has run clean, verification evidence is stated, and the slice is demonstrable. If `trust-profile.md` requires human sign-off on AI-generated code, that sign-off exists.
 
+## Worked example
+
+Acme task 1: route reconciliation failures to a named on-call.
+
+Characterisation first — a test that captures what the job does *today* when it exits non-zero (silently succeeds from the caller's perspective). That test fails after the fix, which is the point: it documents the behaviour being changed rather than trusting the diff.
+
+Mid-build, Tom asks to "just also fix the retry logic while you're in there." That is a scope decision, not a request: logged in `decisions.md` with the blast radius (retry touches the settlement path — not in this slice's declared radius) and routed to the plan's Next lane.
+
+Ledger row on ship: `Jun 18 | failure routing | risk-mitigation | 4h → 15min detection | pending | — | staging kill test, PR #212 | disable alert route`. **Accepted by** stays empty until Marco confirms from a real incident — until then the number is claimed, and the status update says so.
+
 ## Principles
 
 - Characterisation tests before modification. Every time.

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

@@ -69,6 +69,16 @@ The sponsor who sees you've identified where the case could break trusts the cas
 
 Walk the FDE through: the cost of doing nothing (anchor), the investment, the return, and the one sensitivity that matters most. If the FDE says "the sponsor won't buy the ROI number" - ask what number they would believe and work backwards from there.
 
+## Worked example
+
+Acme phase 2 needs funding. The case starts with the cost of doing nothing, not the cost of building.
+
+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.
+
+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
 
 - The cost of doing nothing is always the opening move. Anchor before proposing.

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 for that bucket — or the retrospective explicitly records “not measured; sponsor accepted pending.”
+- 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.
@@ -41,6 +41,16 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 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.
+
+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.
+
 ## Principles
 
 - Done = the customer operates without you.

package/skills/fde/references/discover.md

@@ -192,6 +192,16 @@ If discovery revealed the problem is 3× the brief: the FDE tells the customer *
 
 Stop. Don't form a fourth hypothesis. Three disproven reads means the brief is actively misleading - usually the person who briefed doesn't know, or knows and can't say. Change method: stop analysing the system, ask three people separately "if you had to bet on what's actually wrong here, what would you say?" The thing they all hesitate before saying is the real problem.
 
+## Worked example
+
+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.
+
+`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.
+
 ## Principles
 
 - The brief is a hypothesis until evidence confirms it.

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

@@ -1,36 +1,34 @@
 # ingest-connect - wire a source MCP in plain language
 
-**Enter when:** the FDE says "I want to connect a new MCP", "connect Granola / Notion / Drive", "how do I pull from …", or a pull request fails because no source tools exist.
+**Enter when:** the FDE says "I want to connect a new MCP", "connect Granola / Slack / Notion", "how do I pull from …", or a pull request fails because no source tools exist.
 
-**Read first:** `references/ingest.md` (sink contract). Recipe pack: `mcp/recipes/` in the fdeops install (file, granola, notion).
+**Read first:** `references/ingest.md` (sink contract). Recipes: `mcp/recipes/` (file, granola, slack, notion).
 
 **Who runs setup:** you guide; the **host** (Cursor/Claude) must save MCP config. You cannot silently install servers into the host.
 
 ## Honest contract
 
-- FDEOps = **sink** (`fdeops-ingest` / `fde ingest`). Sources = **whatever MCP the FDE adds**.
-- You produce a ready config snippet + steps. They save + reload. Then you verify with a capability check + optional test stage.
-- Never invent that Granola/Notion is available if tools are missing. Never ambient sync. Never auto-apply to `.fde/`.
+- **Daily work does not need a source MCP.** Paste notes → debrief. File on disk → `fde ingest`.
+- **Connect means a source**, not FDEOps. Granola/Slack/Notion credentials stay with that MCP. FDEOps never pushes, never ambient-syncs, never stores their tokens.
+- **Sink is the CLI in this bound workspace** (`fde ingest`). `fdeops-ingest` MCP is optional. If you use it, pass `engagement` as the `.fde/` path from `fde resume --bind` (MCP servers often do not inherit the workspace bind).
+- Never invent that Granola/Slack is available if tools are missing. Never auto-apply to `.fde/`.
 
 ## Method
 
-1. **Ask one question** — which source? (`file` / `granola` / `notion` / other name). If "other", ask for the MCP package or docs URL they intend to use.
+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 present? (`ingest_stage` / `ingest_list` / or `fde ingest` CLI)
-   - Source present? (anything that can fetch that system's content)
+   - 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** — open the matching recipe under `mcp/recipes/<source>.md`. Fill absolute paths:
-   - path to `mcp/fdeops-ingest/server.js` (from this fdeops install)
-   - `FDEOPS_ENGAGEMENT` → this client's `…/<slug>/.fde`
-   - placeholders for source API keys (tell them to paste secrets into host env — do not commit keys into the fieldbook)
-4. **Tell them where to paste** — Cursor: MCP settings / `~/.cursor/mcp.json` (or project MCP). Claude Code: MCP config per their docs. One sentence: save → reload MCP / restart session.
-5. **Verify** — after they confirm reload: re-run capability check. If source tools appear, offer a **test pull** into `.inbox/` only (stage + show list). Stop before apply unless they ask to propose.
-6. **Handoff phrase** — give them the daily line, 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 the sink
+## If they only want paste / files
 
-Still wire `fdeops-ingest` (or rely on CLI). File drops work with [mcp/recipes/file.md](../../../mcp/recipes/file.md) without any source MCP.
+Do not add MCP. Use debrief or [mcp/recipes/file.md](../../../mcp/recipes/file.md).
 
 ## Checkpoint
 
-Before ending connect: (1) sink reachable, (2) source reachable or honest gap, (3) they know the pull phrase. Do not write `.fde/` during connect.
+Before ending connect: (1) they know paste still works, (2) source reachable or honest gap, (3) they know the pull phrase. Do not write `.fde/` during connect.

package/skills/fde/references/ingest.md

@@ -2,7 +2,7 @@
 
 **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/Notion", "what can you pull?" → `references/ingest-connect.md` first. Recipes: `mcp/recipes/` (file, granola, notion).
+**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).
 
 **Read first:** `context.md` (what's already logged, what's stale). Bind the engagement before staging anything.
 
@@ -11,7 +11,8 @@
 ## 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, Gmail, Notion, custom — whatever they configured in Cursor/Claude. fdeops does not bundle OAuth, connectors, or ambient sync.
+- **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,7 +21,7 @@
 List what you can actually call **this session**:
 
 1. **Sink** — `ingest_stage` / `fde ingest` available?
-2. **Sources** — which fetch tools exist (Granola-shaped, Notion, Drive, file-only)?
+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)
@@ -67,6 +68,6 @@ Before apply, read back the 2–3 most consequential captures in one breath —
 
 ## Principles
 
-- Pull on request, not on a schedule. No auto-poll, no vacuum of inbox or Slack.
+- Pull on request, not on a schedule. No auto-poll, no vacuum of inbox or Slack. No posting back.
 - Staging is not memory. Only `--apply` after confirm writes `.fde/`.
 - Large artifact → ingest stage first; pasted short notes → debrief verb directly (`references/debrief.md`).

package/skills/fde/references/land.md

@@ -79,6 +79,16 @@ Before the end of day 1, ship one visible thing: a small bug fix, a cleanup the
 
 **`success.md`** - what done looks like, **primary value bucket** (`cost-save` | `risk-mitigation` | `revenue-uplift`), baseline → target, who actually signs off, what is explicitly out of scope. Agreed with the customer, not assumed.
 
+For every target number, run the **gaming check** before it is written down: *how could this metric hit its target without the customer being any better off?* There is always an answer, and the answer is what the org will drift toward under pressure. Write the guard next to the metric:
+
+```markdown
+| Metric | Baseline → target | Gamed by | Guard |
+|--------|-------------------|----------|-------|
+| reconciliation alert latency | 4h → 15min | alerting on everything, so nobody reads them | alerts acked by a named owner, ≤2/week |
+```
+
+A metric with no gaming check is a metric the FDE will be held to and cannot defend. If the customer resists the guard, that is the real conversation - they are attached to the number, not the outcome.
+
 **`stakeholders.md`**:
 ```markdown
 | Who | Role | Signal | Notes |
@@ -105,6 +115,16 @@ One page back to the FDE: success + value bucket + sign-off owner, out-of-scope
 
 If remote: trust-building takes ~40% longer - push for a short video call before anything asynchronous.
 
+## Worked example
+
+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.
+
+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.
+
 ## Principles
 
 - Never start technical work before `success.md` exists.

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

@@ -72,6 +72,16 @@ The full option details in the same entry or linked to a section in `reality.md`
 
 Present the three options and the recommendation. One question to the FDE: "Which option matches what the sponsor can hear right now?" (A risk-averse sponsor after an incident → conservative. A founder pre-fundraise → ambitious.) If unsure: present all three and let the sponsor decide.
 
+## Worked example
+
+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.
+
+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.
+
 ## Principles
 
 - Three options, never one. One option is a request for trust; three is a real decision.

package/skills/fde/references/plan.md

@@ -131,6 +131,16 @@ Write migration strategy to `decisions.md` under `## Migration`. Each service ge
 
 Never quietly update tasks. Name the reset: update `reality.md` and `success.md`, one paragraph in `decisions.md` - what changed, why, new sequence. An undocumented reset looks like drift; a documented one looks like the FDE caught something important.
 
+## Worked example
+
+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`.
+
+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.
+
 ## Principles
 
 - Plan from success backwards, not from today forwards.

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

@@ -61,6 +61,16 @@ Evidence-based: point to `decisions.md` scope receipts with dates and requesters
 
 Weekly check: count the scope receipts since last conversation. Three or more unaddressed → recommend the accumulation conversation to the FDE. Zero → "scope holding, `success.md` current."
 
+## Worked example
+
+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.
+
+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
 
 - "Let me place it" is the phrase. Not "no," not "sure."

package/skills/fde/references/ship.md

@@ -186,6 +186,16 @@ Adoption isn't a handoff-stage problem - it starts during build. Software that l
 
 Before 100%: canary clean, business metric verified, pulse written into `delivery.md`. Also green: value bucket named, audit receipt dated, eval receipt **n/a or pass**, **intent vs diff clean** (no unresolved SPLIT/DROP). Missing any of those → not green. For enterprise-scale: scale-readiness gate passed before broad rollout.
 
+## Worked example
+
+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.
+
+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.
+
 ## Principles
 
 - A deployment without a tested rollback is reckless.