fdeops 3.5.0

package/skills/fde/references/sketch.md

@@ -0,0 +1,40 @@
+# 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.
+
+**Read first:** `context.md`, `reality.md`. Load `terrain.md` only if the prototype touches the existing codebase.
+
+## Method (you do this work)
+
+**0. Name the killer assumption.** With the FDE: "What's the belief that kills the project if it's wrong?" Prototype **that** - not the pretty demo.
+
+**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.
+
+**3. AI directions - test these before anything else:**
+- Data: available, clean, sufficient volume? Synthetic-data prototypes say nothing about production behaviour.
+- Environment: are external model calls even allowed here?
+- Latency: acceptable against real user expectations, not ideal conditions?
+- Is AI the right tool at all - or is this a data-quality or process problem wearing an AI costume?
+
+**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.
+
+## Artifact
+
+**`prototype-log.md`** - what was built, shown, the actual reaction, what was learned (including kills - a killed prototype that saved three weeks is a win worth recording).
+
+**`business-case.md`** - scored use case, cost of inaction, success metrics, trade-offs, the 3-sentence pitch. `plan` builds around this file.
+
+## Checkpoint
+
+Tell the FDE: did the riskiest assumption hold · what the customer's reaction actually revealed · proceed / pivot / kill · the 3-sentence case if proceeding. The pitch is written for the person who can say yes or no.
+
+## Principles
+
+- Speed of learning beats code quality. Never more than a day.
+- Show it rough. Polish misleads.
+- Prototype the killer assumption, not the demo.
+- Kill fast; log the learning.

package/skills/fde/references/stakeholder-radar.md

@@ -0,0 +1,68 @@
+# stakeholder-radar - 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.
+
+**Read first:** `stakeholders.md`, `context.md`. Load `trust-profile.md` only if sacred-data boundaries affect who gets told what.
+
+The org chart tells you who reports to whom. The stakeholder radar tells you who actually decides, who blocks quietly, and who's about to escalate. FDEs who read the org chart get blindsided; FDEs who read the room stay ahead.
+
+## Method (you do this work)
+
+**1. Map the five roles - every engagement has them, sometimes in one person:**
+
+| Role | How to spot them | What they need from you |
+|------|-----------------|------------------------|
+| **Sponsor** | Signed the SOW, owns the budget, asks "are we on track" | Progress in their units (cost saved, risk retired), never technical detail |
+| **Champion** | Wants you to succeed, opens doors, warns you about politics | Early wins they can point to - makes them look right for backing you |
+| **Gatekeeper** | Controls access: repos, environments, meetings, introductions | Respect for their process; go around them and they close every door |
+| **Resistor** | Sceptical, protective, or threatened - not necessarily wrong | To be heard first; resistors who feel consulted become the strongest allies |
+| **Ghost** | Named on the project, never in the room - either checked out or operating above you | Find out which. A checked-out ghost is noise. A ghost operating above you is the real decision-maker. |
+
+**2. Track signal, not sentiment.** A stakeholder's signal is what they *do*, not what they say:
+
+| Signal | Evidence (not vibes) |
+|--------|---------------------|
+| **Green** | Responds same-day, shares context unprompted, introduces you to their people |
+| **Amber** | Response time doubles, defers decisions, "let me check with…" when they used to decide alone |
+| **Red** | Stops responding, routes around you, a new person you've never met starts asking questions |
+
+**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.
+
+**4. Detect the invisible escalation.** Three markers:
+- Questions shift from "what are you building" to "when will it be done" - someone above is asking.
+- A meeting gets shortened or cancelled - they're meeting without you.
+- A new stakeholder appears with no introduction - they were sent to check.
+
+When you see any of these: tell the FDE immediately, recommend a proactive conversation with the sponsor before the invisible meeting becomes visible.
+
+**5. The passed-over team - the most dangerous and most valuable stakeholder.**
+
+In every engagement where an external FDE was brought in, an internal team was passed over. They know the codebase better than you, they know the politics better than you, and they resent your presence. Three moves:
+
+- **Ask what they tried.** Before your first standup. Their previous approach is the real requirements doc.
+- **Use their language.** In every meeting. They hear their words coming back and they feel consulted, not replaced.
+- **Make them look right.** Credit their prior work in your artifacts. They protect you if they feel respected; they wait for your mistake if they don't.
+
+## Artifact
+
+**`stakeholders.md`** - updated with evidence-dated signal changes:
+```markdown
+| Who | Role | Signal | Last evidence | Notes |
+|-----|------|--------|---------------|-------|
+| <name> | sponsor | green | responded same-day with budget approval (Jun 12) | owns renewal decision |
+| <name> | resistor→champion | amber→green | shared API docs unprompted after we used their naming (Jun 14) | was passed-over lead |
+```
+
+Signal changes get a dated evidence note. A signal that moved without evidence logged is a guess, not radar.
+
+## Checkpoint
+
+One line per stakeholder who changed signal this week. If nobody changed: "Map stable - next check <date>." If a ghost appeared or a resistor went quiet: name it, recommend the move, and update `context.md` with the action.
+
+## Principles
+
+- Signals are evidence-based, not feeling-based. "Seemed distant" doesn't move a signal; "stopped responding to three messages" does.
+- The 48-hour rule: amber is a same-day response, not a next-week note.
+- The passed-over team is your most important relationship. Win them first.
+- Every engagement has a ghost. Find them before they find you.
+- A stakeholder map that hasn't been updated in two weeks is fiction.

package/skills/fde/references/status.md

@@ -0,0 +1,30 @@
+# status - the sponsor update that keeps the engagement alive
+
+**Enter when:** the weekly update is due, an exec asks "where are we," or the FDE says "I need to send Dana something." This artifact decides renewals; engineers underinvest in it.
+
+**Read first:** `success.md` (the yardstick), `delivery.md`, `decisions.md`, `risks.md`, `context.md`. Gather the week's facts: `fde receipts` for agreements, `git log --since='7 days ago' --oneline` for shipped work.
+
+## Method (you do this work)
+
+1. **Lead with value in their units** - time saved, errors prevented, revenue protected, risk retired. Never "completed the API endpoint"; always what the endpoint *does for the business*.
+2. **Progress against `success.md`** - the agreed definition of done, not a task list. On / ahead / behind, with the why in one line.
+3. **Bad news first, never buried.** A risk the sponsor learns from your update is managed; a risk they learn from their staff is a trust fire. Each risk: one line + what you're doing about it + what you need from them.
+4. **The ask, explicit.** Access, a decision, an introduction, a sign-off. Updates without asks train sponsors to skim.
+5. **Next week in three bullets.** What they'll see, when, and the next touchpoint.
+
+One page maximum. Exec voice: no jargon, no hedging, every claim traceable to the memory (`(shipped Tue, delivery.md)`). Draft in the **FDE's voice, for the FDE to send** - never send anything yourself.
+
+## Artifact
+
+Append the draft to `delivery.md` under `## Status - <date>` (the running record the close phase and dashboard read). Note in `context.md`: status drafted, awaiting FDE review/send.
+
+## Checkpoint
+
+Walk the FDE through the two highest-stakes lines - the worst risk and the biggest ask - and confirm the framing matches what the sponsor can hear right now (check `stakeholders.md` signal first: a red-signal sponsor gets a different opening than a green one).
+
+## Principles
+
+- No surprises: anything the sponsor would be angry to learn later goes in this update.
+- Value in their units, progress against the agreed yardstick, one page.
+- An update without an ask is a missed move.
+- You draft; the FDE sends. Their voice, their relationship.

package/skills/fde/references/test-on-legacy.md

@@ -0,0 +1,108 @@
+# test-on-legacy - making changes safe on code that has no tests
+
+**Enter when:** the codebase has little or no test coverage, you need to change code where tests are absent or misleading, or `terrain.md` flagged high-churn modules with no test neighbours.
+
+**Read first:** `terrain.md` (the churn heat map), `decisions.md` (the current slice), `context.md`. This skill is the safety net for building on someone else's untested codebase.
+
+Legacy code without tests is a minefield. You can't refactor it because you don't know what it does. You can't add features because you don't know what you'll break. The way through: characterise what exists, wrap the change, prove it works - in that order.
+
+## Method (you do this work)
+
+**1. Characterisation tests first.** Before changing anything, write tests that describe what the code *actually does right now* - including the parts that seem wrong:
+
+```
+The code truncates names at 50 characters.
+  → That seems like a bug, but it might be a contract another system depends on.
+  → Write a test: "truncates names at 50 characters" - that's the characterisation.
+  → NOW you can change the code and know exactly what you've broken.
+```
+
+Characterisation tests answer: "What does this code do?" not "What should this code do?" They're the honest documentation that the README isn't.
+
+**How to write them:**
+1. Pick the function/module you're about to change.
+2. Call it with representative inputs (from production if possible, from logs, from the team's knowledge).
+3. Record what comes back - that's your expected output.
+4. Turn that into an assertion.
+
+```
+# The pattern:
+result = function_under_test(real_input)
+assert result == whatever_it_actually_returned  # characterisation, not specification
+```
+
+**2. The Strangler Fig pattern - wrap, don't rewrite.**
+
+Never rewrite legacy code in place. Instead:
+
+```
+Step 1: New interface wraps the old code (calls through to it)
+  → All existing callers work exactly as before
+  → Your characterisation tests pass
+
+Step 2: New implementation behind the new interface
+  → Old code still there, still callable
+  → Feature flag or config switches between old and new
+
+Step 3: Gradually migrate callers to the new path
+  → Each migration is a small, testable change
+  → Old path remains as fallback
+
+Step 4: Remove old code only when:
+  → No callers remain
+  → New path has been stable for N days
+  → Team agrees it's safe
+```
+
+**3. The test pyramid for legacy engagement work:**
+
+| Level | What to write | How many | Why |
+|-------|-------------|---------|-----|
+| **Characterisation** | What the code does now | 3–5 per module you're changing | Safety net before any change |
+| **Unit** | Your new code's behaviour | 1 per new function/method | Proves your addition works |
+| **Integration** | The seam between old and new | 1–2 per boundary | Proves old and new cooperate |
+| **Smoke** | The critical user path end-to-end | 1 per feature | Proves the user can still do the thing |
+
+**4. Spot the lying tests.** Worse than no tests are tests that pass but verify nothing:
+
+```
+# This test passes and proves nothing:
+def test_process_payment():
+    result = process_payment(mock_everything())
+    assert result is not None  # what does "not None" prove?
+
+# This test is actually testing something:
+def test_process_payment_deducts_from_balance():
+    account = create_account(balance=100)
+    process_payment(account, amount=30)
+    assert account.balance == 70
+```
+
+When you find a lying test: note it in `terrain.md`. Don't fix it unless it's in your slice - but name it, because the next person needs to know.
+
+**5. The "safe to change" checklist.** Before modifying any legacy code:
+
+- [ ] Characterisation tests written for the module being changed
+- [ ] All characterisation tests pass before your change
+- [ ] Your change is wrapped (Strangler Fig), not a rewrite-in-place
+- [ ] New tests cover your new behaviour
+- [ ] All tests (characterisation + new) pass after your change
+- [ ] The diff shows only what you intended to change
+
+## Artifact
+
+**`terrain.md`** - update test-gap assessment: which modules now have characterisation tests, which still don't, which tests are lying.
+
+**`decisions.md`** - log: "Added characterisation tests for <module> before changing <feature>. Coverage state: <before/after>."
+
+## Checkpoint
+
+Before merging any change to legacy code: characterisation tests existed before the change (state which), new tests cover the new behaviour, all pass. If characterisation tests were skipped: that's a finding - state why (time pressure? inaccessible code?) and log the risk.
+
+## Principles
+
+- Characterise before changing. What the code does > what it should do.
+- Wrap, don't rewrite. The Strangler Fig is the safest pattern on legacy code.
+- A lying test is worse than no test. Name it when you find it.
+- The ugly behaviour in the characterisation test might be someone else's contract. Don't "fix" it without asking.
+- Test coverage on legacy code is insurance - buy it before you need it, not after.

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

@@ -0,0 +1,100 @@
+# trust-engineering - earning commit access one move at a time
+
+**Enter when:** new engagement where you don't have full access yet, trust is thin, the customer said "let's start small," or you need to navigate "we don't trust AI-generated code."
+
+**Read first:** `trust-profile.md`, `stakeholders.md`, `context.md`. The trust profile tells you where the walls are; the stakeholder map tells you who built them.
+
+Trust is the currency of FDE work. Code quality gets you a second week; trust gets you the engagement. It's earned in small, visible moves - never demanded, never assumed, and never recovered once burned.
+
+## Method (you do this work)
+
+**1. The trust ladder - every engagement climbs it in order:**
+
+```
+Level 0: Observer     → read-only access, watching
+Level 1: Advisor      → recommendations, no code changes
+Level 2: Contributor  → PRs reviewed by their team
+Level 3: Committer    → direct push to feature branches
+Level 4: Owner        → production access, deploy authority
+Level 5: Trusted      → they call you before making decisions
+```
+
+**Never skip a level.** The FDE who asks for production access on day two gets observer access for a month. The FDE who ships a clean PR on day two gets committer access by week two. Each level is earned by demonstrating competence AND respect at the current level.
+
+**2. The first-week trust plays - specific, not generic:**
+
+| Day | Move | Why it works |
+|-----|------|-------------|
+| 1 | Fix a small, visible, annoying bug - something the team has been stepping over | Proves you can ship in their environment without breaking things |
+| 1 | Ask the passed-over team what naming conventions they use - then use them | Shows respect before competence |
+| 2 | Send a one-paragraph status to the sponsor without being asked | Sets the pattern: they hear from you before they have to ask |
+| 3 | Find a genuine risk and flag it without drama | Demonstrates you're protecting them, not performing |
+| 5 | Show a small win to the champion so they can share it upward | Gives them evidence their bet on you was right |
+
+**3. Navigate "we don't trust AI-generated code":**
+
+This is increasingly common. The right response is respect, not persuasion:
+
+- **Ask the policy, don't assume.** "Does your organisation have a position on AI-assisted code in production?"
+- **If prohibited:** work without AI on their code. Use fdeops for engagement memory (`.fde/` files) and your own planning - that's your tooling, not theirs.
+- **If permitted with review:** every AI-touched line goes through their normal review process. Flag it: "AI-assisted, human-reviewed" in commit messages if they want traceability.
+- **If grey area:** treat as prohibited until someone with authority says otherwise. The cost of asking is zero; the cost of guessing wrong is the engagement.
+- **Never hide it.** An FDE caught using prohibited AI tools loses the engagement and the reputation. Full stop.
+
+**4. Trust recovery - when you've made a mistake:**
+
+Mistakes happen. What matters is speed and honesty:
+
+- **Own it in the first hour.** Not "we found an issue" - "I introduced this bug." Passive voice erodes trust faster than the mistake.
+- **Show the fix AND the prevention.** "Here's what happened, here's the fix, here's the test that prevents it next time."
+- **One visible win within 48 hours.** Trust recovery needs a concrete success close to the mistake - not weeks later.
+- **Never minimise.** "It was a small bug" is your assessment, not theirs. Let them size it.
+
+**5. The trust account - deposits and withdrawals:**
+
+| Deposits (slow, steady) | Withdrawals (fast, expensive) |
+|-------------------------|-------------------------------|
+| On-time status updates | Surprises - especially bad ones they hear from someone else |
+| Using their conventions | "I know better" energy - even when you do |
+| Flagging risks early | Breaking something in production |
+| Crediting the internal team | Taking credit for shared work |
+| Asking before touching sensitive code | Assuming access you haven't been given |
+| Over-communicating during incidents | Going quiet when things are hard |
+
+## Artifact
+
+**`trust-profile.md`** - updated sections:
+```markdown
+## Trust level
+Current: <level 0–5> as of <date>
+Evidence: <what earned this level>
+Next target: <level> - requires: <specific action>
+
+## AI policy
+Status: <prohibited / permitted-with-review / grey-area-treating-as-prohibited>
+Source: <who confirmed, when>
+```
+
+**`decisions.md`** - log trust-significant moves: "Flagged migration risk to ops lead before they discovered it (Day 3) - trust deposit."
+
+## Checkpoint
+
+One question to the FDE: "Are we at the right trust level for what we need to do next week?" If not: name the gap, name the move, and put it in `context.md` as the next action.
+
+## The week 2-4 valley
+
+Week 1 is the honeymoon - everyone's excited, access is fresh, the brief is new. Weeks 2-4 are the valley: novelty wears off, real problems surface, the sponsor's patience shifts from "take your time" to "when do we see results." Most engagements silently fail here, not at ship.
+
+Counter it:
+- Ship one visible artifact per week, even if discovery isn't done. A terrain map, a risk register, a stakeholder signal update - something the sponsor can point to.
+- Proactive status update at end of week 2 - explicitly name what discovery revealed that wasn't in the brief. This resets expectations with evidence.
+- If still in discovery at week 3: the conversation with the sponsor about scope or timeline reset is overdue. Don't wait for them to ask.
+
+## Principles
+
+- Trust is earned in small moves, lost in one. Never skip the ladder.
+- The first-week plays are specific and deliberate - not "be helpful."
+- AI policy: ask, never assume. Prohibited until confirmed.
+- Mistakes happen; hiding them doesn't. Own it in the first hour.
+- The FDE who makes the internal team look right earns trust faster than the FDE who ships the most code.
+- Weeks 2-4 are where engagements silently die. Ship visible artifacts weekly to survive the valley.

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

@@ -0,0 +1,70 @@
+# use-case-scoring - pick the right battle, not the interesting one
+
+**Enter when:** multiple potential use cases compete for attention, the customer says "we want to do everything," a transformation engagement needs a starting point, or the FDE needs to recommend which problem to solve first.
+
+**Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from sketch, load those - they carry forward.
+
+The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
+
+## Method (you do this work)
+
+**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:
+
+| Dimension | 1 | 3 | 5 |
+|-----------|---|---|---|
+| **Business value** | Nice-to-have improvement | Noticeable cost or revenue impact | Existential - they lose customers or face regulatory action without it |
+| **Urgency** | Someday; no deadline | Needed this quarter; mild pressure | Burning now; every week costs real money or trust |
+| **Feasibility** | Requires new infrastructure, skills, or major refactoring | Moderate effort with known patterns | Can be built on existing systems with existing team |
+| **Data readiness** | Data doesn't exist or is deeply unclean | Data exists but needs work; volume uncertain | Available, clean, sufficient volume today |
+| **Stakeholder alignment** | No sponsor; political resistance | One sponsor but competing priorities | Active sponsor with budget and decision authority |
+
+**3. Calculate the score.**
+
+```
+Score = (Business value × Urgency × Stakeholder alignment) / (6 - Feasibility) × Data readiness
+```
+
+Why this formula:
+- **Multiplied numerator** - all three must be present. A high-value problem with no urgency or no sponsor scores low because it won't ship.
+- **Feasibility inverted** - harder problems get a higher denominator, pulling the score down. A feasibility of 5 (easy) gives denominator 1; feasibility of 1 (hard) gives denominator 5.
+- **Data readiness as multiplier** - for data-dependent use cases (ML, analytics). For pure engineering work, set to 3 (neutral) unless data quality is genuinely a factor.
+
+**4. Rank and present.** Sort by score. Present the top 3 to the FDE and the sponsor:
+
+```markdown
+| Rank | Use case | Value | Urgency | Feasibility | Data | Alignment | Score | Recommend |
+|------|----------|-------|---------|-------------|------|-----------|-------|-----------|
+| 1 | Fix payment reconciliation | 5 | 5 | 4 | 3 | 5 | 187.5 | Start here |
+| 2 | Dashboard redesign | 3 | 2 | 5 | 3 | 3 | 54.0 | Quick win if capacity |
+| 3 | ML fraud detection | 5 | 3 | 2 | 2 | 4 | 30.0 | Phase 2 after data prep |
+```
+
+**5. Defend the recommendation, not the model.** The model is a reasoning tool, not a decision. When presenting:
+
+- "The scoring puts payment reconciliation first because it's the only use case where all three conditions hold: the sponsor is active, the problem is burning, and we can build it on the existing system."
+- Never: "The model says X." Models don't decide; people decide with evidence.
+
+**6. Handle the CEO's pet project.** Sometimes the highest-scoring use case isn't the one the most powerful stakeholder wants. That's information, not a problem:
+
+- Present the scores honestly - the stakeholder sees you're being rigorous, not political.
+- If they override: log it in `decisions.md` as a deliberate choice, note the trade-off, and build what they chose. The FDE who was honest about the trade-off is protected when the override creates problems.
+
+## Artifact
+
+**`reality.md`** - the scored use-case table with the recommendation. This is the evidence the sponsor references when justifying the prioritisation upward.
+
+**`decisions.md`** - if the scored recommendation was overridden: what was chosen, by whom, the trade-off accepted.
+
+## Checkpoint
+
+Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to sketch or plan.
+
+## Principles
+
+- Score replaces opinion. Visible arithmetic beats invisible judgment.
+- All three conditions (value, urgency, alignment) must hold - or the use case won't ship.
+- The technically interesting problem that scores low gets deferred, not pursued.
+- Present the model; let the human decide. If overridden, log the trade-off.
+- A use case with no active sponsor is a research project, not an engagement deliverable.

package/templates/.fde/README.md

@@ -0,0 +1,13 @@
+# `.fde/` engagement memory
+
+**Default location (recommended):** `~/fde-engagements/<engagement-name>/.fde/`
+
+Create with:
+
+```bash
+node bin/install.js init <engagement-name>   # from fdeops repo; or npx fdeops@latest init when npm ≥ 3.0.0
+```
+
+Stays on **your machine** - not in shared git by default.
+
+Optional: copy into a workspace only if allowed and `.fde/` is gitignored.

package/templates/.fde/brief.md

@@ -0,0 +1,8 @@
+# Brief (stated problem)
+
+<!-- What they said the problem is. Hypothesis until the discover phase confirms. -->
+
+**Stated problem:**
+**Timeline:**
+**Named decision-maker:**
+**Gaps in the brief (questions to answer):**

package/templates/.fde/context.md

@@ -0,0 +1,14 @@
+# Engagement context
+
+<!-- Loaded every session. Keep compact: state, owner, next action. -->
+
+**Engagement:**
+**Customer:**
+**Phase:** land | discover | build | ship | close
+**Last updated:**
+
+## Current state
+
+## Next action
+
+## Notes for the next session

package/templates/.fde/decisions.md

@@ -0,0 +1,18 @@
+# Decisions and plan
+
+<!-- Plan lives here: PR-sized tasks with verification steps. -->
+
+## Plan
+
+## Decision log
+
+<!-- Use this format for each decision. The rationale is the part that survives the engagement. -->
+
+<!--
+### [Date] Decision title
+- Context: what prompted this decision
+- Options considered: what was on the table
+- Decision: what was chosen
+- Rationale: why this over the alternatives
+- Owner: who approved
+-->

package/templates/.fde/delivery.md

@@ -0,0 +1,7 @@
+# Delivery log
+
+<!-- Business-visible value, not ticket theater. -->
+
+## Shipped
+
+## Running value

package/templates/.fde/reality.md

@@ -0,0 +1,7 @@
+# Reality (actual problem)
+
+<!-- Hypothesis until the discover phase confirms with evidence. -->
+
+**Working theory:**
+**Evidence:**
+**Differs from brief how:**

package/templates/.fde/risks.md

@@ -0,0 +1,5 @@
+# Risk register
+
+| Risk | Status | Owner | Mitigation |
+|------|--------|-------|------------|
+| | open | | |

package/templates/.fde/stakeholders.md

@@ -0,0 +1,10 @@
+# Stakeholders
+
+<!-- Champions, blockers, veto power. Trust signals: quiet = escalate. -->
+
+| Name | Role | Stance | Notes |
+|------|------|--------|-------|
+| | | champion / neutral / resistant | |
+
+**Trust signal:** green | amber | red  
+**Last trust check:**

package/templates/.fde/success.md

@@ -0,0 +1,7 @@
+# Success definition
+
+<!-- Agreed definition of done. Out-of-scope is as important as in-scope. -->
+
+**Done when:**
+**Explicitly out of scope:**
+**Stakeholder who signs off:**

package/templates/.fde/terrain.md

@@ -0,0 +1,7 @@
+# Terrain (codebase map)
+
+<!-- Hotspots, test gaps, fragile zones. Update as you learn - do not load whole repo into context. -->
+
+**Stack:**
+**Hotspots (handle with care):**
+**Test gaps:**

package/templates/.fde/trust-profile.md

@@ -0,0 +1,11 @@
+# Trust profile
+
+<!-- Sacred data, AI policy, approvals. Use <private>...</private> for never-AI content. -->
+
+**AI code policy:**
+**Approval chain:**
+**Data that must never enter AI context:**
+
+<private>
+<!-- Example: cardholder data scope, production credentials paths -->
+</private>