fdeops 3.15.1 → 3.16.0

package/skills/fde/references/{assumption-audit.md → test-assumptions.md}

@@ -1,4 +1,4 @@
-# assumption-audit - pressure-test the brief before building on it
+# test-assumptions - pressure-test the brief before building on it
 
 **Enter when:** the brief feels too neat, the customer is very confident about the solution (not the problem), someone says "we just need…" about a complex system, or discover surfaced contradictions between what was said and what the codebase shows.
 
@@ -76,11 +76,11 @@ Tell the FDE: how many assumptions extracted, how many critical, which ones were
 
 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.
+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".
+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
 

package/skills/fde/references/{incremental-build.md → thin-slices.md}

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

package/skills/fde/references/{options-analysis.md → three-options.md}

@@ -1,4 +1,4 @@
-# options-analysis - three paths, not one recommendation
+# three-options - three paths, not one recommendation
 
 **Enter when:** a significant technical or strategic decision needs to be made, the FDE is asked "what should we do?", the team is stuck between approaches, or a fork in the engagement requires the sponsor's input.
 
@@ -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/{blast-radius.md → what-breaks.md}

@@ -1,4 +1,4 @@
-# blast-radius - know what breaks before you touch it
+# what-breaks - know what breaks before you touch it
 
 **Enter when:** about to make a change on a system you don't fully understand, touching a high-churn module from `terrain.md`, modifying shared infrastructure (auth, database, messaging), or the FDE asks "what could go wrong?"
 
@@ -26,7 +26,7 @@ CONTAINED  → Only the module you're changing is affected
              Rollback: revert the PR
              Example: changing a utility function with no external callers
 
-ADJACENT   → 2–5 callers or one downstream system affected
+ADJACENT   → 2-5 callers or one downstream system affected
              Rollback: revert the PR + verify downstream
              Example: changing an API response format used by the frontend
 
@@ -38,7 +38,7 @@ IRREVERSIBLE → Cannot be rolled back without data loss or manual intervention
                Example: data migration, dropping a column, changing encryption keys
 ```
 
-**3. The blast-radius declaration.** Before writing any code, state it explicitly in `decisions.md`:
+**3. The what-breaks declaration.** Before writing any code, state it explicitly in `decisions.md`:
 
 ```markdown
 ## Blast radius: <change name>
@@ -72,7 +72,7 @@ Time to detect: <5 minutes via error rate alert
 
 ## Artifact
 
-**`decisions.md`** - the blast-radius declaration, filed before the change starts. Updated if the blast radius grew during implementation.
+**`decisions.md`** - the what-breaks declaration, filed before the change starts. Updated if the blast radius grew during implementation.
 
 **`risks.md`** - new risks discovered during the trace (the invisible integrations, the midnight cron job).
 

package/skills/fde/references/{stakeholder-radar.md → who-decides.md}

@@ -1,4 +1,4 @@
-# stakeholder-radar - reading the room before it reads you
+# who-decides - reading the room before it reads you
 
 **Enter when:** new stakeholders appear, signals shift mid-engagement, a meeting felt off but you can't say why, or it's been two weeks and the map hasn't been updated.
 
@@ -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/templates/.fde/assumptions.md

@@ -1,6 +1,6 @@
 # Assumptions
 
-<!-- Brief claims that are not yet evidence. Land seeds; assumption-audit / discover update. -->
+<!-- Brief claims that are not yet evidence. Land seeds; test-assumptions / discover update. -->
 
 | # | Assumption | Blast radius | How we test | Status | Evidence |
 |---|------------|--------------|-------------|--------|----------|