fdeops 3.15.0 → 3.15.2

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
 

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 `scope-defense`). 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/sketch.md

@@ -1,6 +1,6 @@
 # sketch - prototype to kill or confirm a direction
 
-**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/stakeholder-radar.md

@@ -28,7 +28,7 @@ The org chart tells you who reports to whom. The stakeholder radar tells you who
 
 **3. The 48-hour rule.** A stakeholder who goes amber has roughly 48 hours before they go red. A stakeholder who goes red is already escalating above you. Respond same-day to amber signals - not with more delivery, with a conversation.
 
-**3b. One name per person.** If the table says "Denise Chen" and Signal history says "Denise" or "D. Chen", trust keys fork and prep lies. Consolidate to one spelling. `fde doctor` flags these identity clusters — treat that as a fix, not a nit.
+**3b. One name per person.** If the table says "Denise Chen" and Signal history says "Denise" or "D. Chen", trust keys fork and prep lies. Consolidate to one spelling. `fde doctor` flags these identity clusters - treat that as a fix, not a nit.
 
 **4. Detect the invisible escalation.** Three markers:
 - Questions shift from "what are you building" to "when will it be done" - someone above is asking.
@@ -76,11 +76,11 @@ One line per stakeholder who changed signal this week. If nobody changed: "Map s
 
 Acme, week 6. Priya's replies have gone from same-day to two days, and a phase-2 go/no-go is scheduled for Thursday.
 
-Two signals, not one feeling: response time doubled *and* a finance analyst nobody introduced started asking when the work completes. That combination is an invisible escalation — someone above Priya is asking, and the meeting is already happening without the FDE.
+Two signals, not one feeling: response time doubled *and* a finance analyst nobody introduced started asking when the work completes. That combination is an invisible escalation - someone above Priya is asking, and the meeting is already happening without the FDE.
 
-Positions: Priya is a supporter under pressure. Marco is a supporter who does not vote. Denise (finance) is the swing, and what she is protecting is not the budget line she cites — it is that her team's escalation started this and she has nothing to show her own director. Raj is a firm opponent on the rewrite question, and no amount of the same argument moves him.
+Positions: Priya is a supporter under pressure. Marco is a supporter who does not vote. Denise (finance) is the swing, and what she is protecting is not the budget line she cites - it is that her team's escalation started this and she has nothing to show her own director. Raj is a firm opponent on the rewrite question, and no amount of the same argument moves him.
 
-Sequence: Denise one-on-one Tuesday with the incident numbers in her units, then Priya Wednesday, so Priya walks in already knowing finance is not going to object. Pre-mortem sentence: *"Denise says 'we still don't know if this actually caught anything'"* — which is precisely why Tuesday exists. `stakeholders.md` records `Priya | sponsor | green→amber | reply latency 1d → 2d, unintroduced analyst (Jul 3)`; `context.md` carries the sequence.
+Sequence: Denise one-on-one Tuesday with the incident numbers in her units, then Priya Wednesday, so Priya walks in already knowing finance is not going to object. Pre-mortem sentence: *"Denise says 'we still don't know if this actually caught anything'"* - which is precisely why Tuesday exists. `stakeholders.md` records `Priya | sponsor | green→amber | reply latency 1d → 2d, unintroduced analyst (Jul 3)`; `context.md` carries the sequence.
 
 ## Principles
 

package/skills/fde/references/status.md

@@ -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?".
@@ -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/trust-engineering.md

@@ -66,7 +66,7 @@ Mistakes happen. What matters is speed and honesty:
 **`trust-profile.md`** - updated sections:
 ```markdown
 ## Trust level
-Current: <level 0–5> as of <date>
+Current: <level 0-5> as of <date>
 Evidence: <what earned this level>
 Next target: <level> - requires: <specific action>
 

package/skills/fde/references/use-case-scoring.md

@@ -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 |
 |-----------|---|---|---|