fdeops 4.1.0 → 5.0.0

package/skills/poc/references/discover.md

@@ -0,0 +1,112 @@
+# discover - Find the problem behind the request
+
+**Enter when:** the customer brief is unclear, the proposed solution may miss the real problem, or a change has exposed an unmapped part of the work.
+
+Apply [task context and evidence](task-context.md) first. Supplied notes are enough to begin. In an existing engagement, use permitted summaries of `context.md`, `brief.md`, `reality.md` and relevant `terrain.md` sections; extend existing findings instead of restarting.
+
+## Choose the depth the task needs
+
+- **Notes or meeting preparation:** return the current steps, observations, hypotheses and a few questions that would change the next decision. No repository scan, workshop or customer-record setup is required.
+- **A specific delivery problem:** follow the affected people, systems and data far enough to explain the break and identify what evidence is missing.
+- **A wider engagement:** map dependencies and decision owners across the involved teams. Examine each candidate problem before choosing where to invest; do not make a full enterprise inventory a prerequisite for one useful finding.
+
+State what you are investigating and which decision it informs. Reuse the user's stated goal. Ask only when a missing answer changes the next action; otherwise proceed with a clearly labelled provisional interpretation.
+
+## Frame the decision
+
+Write a short frame from the evidence available:
+
+| Part | What to establish |
+|---|---|
+| Situation | How people complete this task today |
+| Complication | The observed delay, failure, cost or constraint |
+| Question | The decision that further evidence should help someone make |
+| Possible outcomes | Confirm the brief, change its scope, investigate further or pause |
+
+Keep the question specific and neutral. “What causes requests to wait before assignment?” leaves room for different explanations. “How should we automate assignment?” assumes the solution before establishing the cause.
+
+Name the decision owner when known. An unknown owner or unmeasured baseline is a finding, not a reason to keep questioning indefinitely. Return a provisional frame and identify who or what could verify it. Do not present a new interpretation as agreed scope.
+
+## Trace the work
+
+Follow an ordinary case from arrival to completion, then relevant exceptions. Use the customer's terms for the request, system and people involved.
+
+For each step, establish:
+
+- Who performs it and where the input comes from.
+- What they do, check or decide, and which system they update.
+- Time spent working versus time spent waiting.
+- What happens when information is missing or the normal path fails.
+- Who notices the failure, how they recover, and which record they trust.
+
+Distinguish measured timings from estimates. A team lead's recollection is useful evidence about their experience; it is not a measured baseline. Do not infer that the slowest visible step causes the whole delay without following its dependencies.
+
+Use concrete questions when the supplied material leaves a gap: “Show me the last request that waited a day. What had to happen before someone could take it?” Ask about spreadsheets, manual transfers or other workarounds when there is evidence of them, without assuming they exist.
+
+When a workaround looks surprising, use the targeted history check in [audit](audit.md#before-changing-an-unfamiliar-workaround). History supplies clues, not proof that an old requirement still applies.
+
+## Inspect systems when relevant and permitted
+
+If the question depends on application behavior and code access is authorized, use `fde scan` and targeted file reads. If the CLI is unavailable, use the repository's existing search, Git and test tools. Do not load the whole repository or unrelated customer data.
+
+Follow the actual path: entry point → validation → processing → storage or downstream action. Inspect the code, configuration and tests that can explain the observed discrepancy.
+
+Check existing capability before proposing new work. A disabled feature, frequent edits or a missing nearby test is a lead to investigate, not proof of a root cause. Record the evidence behind any technical risk. When there is no repository access, state that implementation behavior remains unchecked and finish the work possible from the notes.
+
+## Check the data and dependencies the proposed work needs
+
+For each relevant source, establish where it lives, how fresh it is, who controls access, which fields the task needs, and what happens when it is unavailable. Inspect a permitted sample appropriate to the question; report its size and limitations rather than treating a small sample as representative by default.
+
+| Source or connection | Needed for | Freshness and quality evidence | Access owner | Failure or constraint | Next check |
+|---|---|---|---|---|---|
+| Fill only relevant sources | | | Unknown if unconfirmed | | |
+
+Check mappings between systems, supported APIs, permissions and retry behavior where they affect feasibility. A promised export or integration is not yet an available dependency. Record its responsible owner, verification date and required evidence when known; propose missing commitments for confirmation.
+
+For AI work, identify which steps can use deterministic logic, which need model judgment, and which require a human decision. Keep that allocation provisional until the affected owners agree. Establish who would operate the resulting change and what access or training they would need.
+
+## Use a workshop only when it resolves a real disagreement
+
+A short meeting with the relevant decision makers may help when teams describe different problems or constraints. Bring the observed cases and the decision to be made. Ask participants to state their constraints before discussing options.
+
+Summarize areas of agreement and disagreement. A vote or an absence of objections does not establish authority or acceptance. Ask the responsible owner to confirm the decision and record any unresolved objection, next action and date. Draft the summary promptly, then follow the record-confirmation rules before saving it.
+
+## Return a useful discovery result
+
+Use the smallest output that answers the user's request:
+
+1. The current task and the decision under investigation.
+2. What the evidence establishes, with its source.
+3. The working explanation and plausible alternatives.
+4. Relevant exceptions, dependencies or technical risks actually observed.
+5. Missing evidence and the next check that would change the decision.
+
+Do not fill a quota of risks, exceptions or questions. If no system was inspected, do not invent code findings. If several interpretations have failed, reassess the evidence and investigation method rather than blaming the person who wrote the brief.
+
+For a bound engagement, propose updates to the existing records after the discovery result is reviewed:
+
+- `reality.md`: preserve `Working theory`, `Evidence` and `Differs from brief how`; add the decision frame and validation status.
+- `terrain.md`: relevant steps, system behavior, data dependencies and unknowns. Preserve the `## Operating map (exception-led)` section and its columns when recording observed breaks.
+- `assumptions.md`: new or changed assumptions, verification owners and checkpoints.
+
+An operating-map row uses: `Exception / break | Who notices first | What they do today | System of record then | Blast | Evidence`. Preserve the existing schema. If no break has been observed, report that gap; do not fabricate a row to satisfy a readiness check.
+
+For standalone work, return the same findings in the conversation or requested document. No `.fde/` write or initialization is needed.
+
+## Worked example
+
+This example is fictional and uses only supplied meeting notes.
+
+The brief asks for an assistant to draft responses. The supplied notes say drafting takes about four minutes, while requests sometimes wait a day for assignment. The timings come from a team lead; no measured baseline is available.
+
+**Working theory:** assignment delay may matter more than drafting time. **Evidence:** the lead's estimates in the supplied notes, still unverified. **Differs from brief how:** the requested assistant addresses drafting, while the reported delay concerns assignment. **Question:** what causes the assignment delay, and which change would reduce it? **Next check:** trace a sample of recent requests using arrival and assignment timestamps, then ask the people handling delayed cases what prevented assignment.
+
+The discovery result does not reject the assistant or declare an ownership problem solved. It gives the FDE a focused way to find out what to build, change or investigate next. Return this as a short draft for notes-only work; in a bound engagement, propose it for `reality.md` with validation still pending.
+
+## Principles
+
+- Investigate the work before choosing a solution.
+- Keep observations, estimates and hypotheses distinct.
+- Match discovery effort to the decision at hand.
+- Unknown ownership and missing evidence remain explicit.
+- Confirmation comes from the responsible person, never from silence.

package/skills/qa/.fde-generated.json

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "65b965474e847f240138c1ada0ee7d982affc421a24a0a7a37970021f8269a03",
+    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
+    "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
+    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
+    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
+    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

package/skills/{fde-qa → qa}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-qa
+name: qa
 description: Exercise the delivered customer journey using real runtime or browser evidence. Use for functional acceptance testing after implementation, including failure paths.
 ---
 
-# fde-qa
+# qa
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/readout/.fde-generated.json

@@ -0,0 +1,11 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "428eb3b5a062dd32be65a2775fdc65c5ef67e61dc26e34d9067d9f8d5e75c4ad",
+    "references/board-memo.md": "44eb3c27f164da63af694591025b3fc96bb23d149c29de400997c1653e3322f8",
+    "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
+    "references/readout.md": "46856e9452ef3928a394fc89425bf4b9ba912f5586584537345a10f6c3a20903",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+  }
+}

package/skills/{fde-readout → readout}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-readout
+name: readout
 description: Prepare a sponsor update separating promised outcomes, measured results and customer acceptance. Use for progress readouts or defending a delivery claim.
 ---
 
-# fde-readout
+# readout
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

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

@@ -1,12 +1,14 @@
 # readout - Report the outcome
 
+**Context:** apply [task context and evidence](task-context.md). Standalone readouts use supplied permitted notes and evidence; no engagement binding or CLI command is required.
+
 **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` (value ledger), `decisions.md` (plan + kill list), `assumptions.md` (OPEN criticals), `risks.md`, `context.md`. Gather the week's facts: `fde receipts` for agreements, `git log --since='7 days ago' --oneline` for shipped work.
+**Read first:** `success.md` (the yardstick), `delivery.md` (value ledger), `decisions.md` (plan + kill list), `assumptions.md` (OPEN criticals), `risks.md`, `context.md`. For bound work, gather agreements through `fde receipts`; use permitted repository history only when relevant. A commit shows a code change, not proof of deployment. For standalone work, use the supplied facts and mark missing evidence explicitly.
 
 ## 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 locate the Situation; check their cited records before making the claim. CLI output summarizes recorded text, not independently verified acceptance. Do not invent a number the CLI did not print. If the CLI is unavailable, use the redacted source records and say so.
+**First:** for a bound engagement, run `fde status`. It prints the value ledger before trust - promised → measured → accepted by, or `claimed, not yet accepted`. Check cited records through sanitized CLI views before making the claim. CLI output summarizes recorded text, not independently verified acceptance. For standalone work, build the same distinction from supplied permitted context without running engagement-only commands or initializing records. If a bound CLI is unavailable, use only permitted supplied excerpts and report the limitation. Never infer acceptance or fabricate missing measurements.
 
 **Qualify the evidence before drafting.** For each result, identify baseline source, measurement environment, observation window/sample, and the scope of acceptance. Report an informal baseline as reported and a staging sample as staging; neither establishes realized savings. “Looks good” without what was accepted is not outcome acceptance. Attribute an engineer's note as such; do not turn it into a direct customer receipt. If evidence conflicts, include the conflict and the next verification action rather than choosing the flattering version.
 
@@ -20,8 +22,8 @@
 | **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?".
-2. **Are they using it?** - Situation must say whether the workaround is still open: spreadsheet still running, shadow paste still happening, named operator completed Tuesday's job on the new path without you at the keyboard. A measured metric with the old path still live is `claimed`. That week's Ask is not "fund phase 2." It is "who on their side stops the old way, by when."
+1. **Value this week** - from the value ledger: promised → measured (or "pending") → **accepted by whom**, with evidence citation. An unaccepted measurement stays labeled as measured but unaccepted; do not present it as realized or accepted value. Preserve the actual decision needed: it may be funding a bounded test to resolve uncertainty, rather than asking for sign-off on evidence that does not yet exist.
+2. **Are they using it?** - Situation must say whether the workaround is still open: spreadsheet still running, shadow paste still happening, named operator completed Tuesday's job on the new path without you at the keyboard. If the old path remains live, report its role and remaining effort. Parallel operation may be a deliberate control; do not demand its removal without evidence and authority. Frame the next ask around the actual blocker or uncertainty.
 3. **Kill / defer reminder** - one line from the plan kill list so scope fights stay visible.
 4. **Hostile Q prep** - three questions a skeptical sponsor will ask, with one-line answers from memory.
 

package/skills/review/.fde-generated.json

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "7c8310fbceb8768b6997c758bf041bf97be66a3e8cc1de5df2aa84e2771a374b",
+    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
+    "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
+    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
+    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
+    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

package/skills/{fde-review → review}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-review
+name: review
 description: Review a proposed customer code change against its intended outcome and operational risks. Use for a diff or PR review; report evidence and actionable findings.
 ---
 
-# fde-review
+# review
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/scope/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "13640b029f34068b08f2b0532ad7d2bae2d1063eeff17ec85a840bfbf832311e",
+    "references/hold-scope.md": "42b3823f6b49b87b432f81208b0a61115f22340f6a922a4e858012e908c6643d",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+  }
+}

package/skills/{fde-scope → scope}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-scope
+name: scope
 description: Assess a new customer request against agreed scope, trade-offs and ownership. Use when an engagement expands or a custom feature needs a commitment decision.
 ---
 
-# fde-scope
+# scope
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/ship/.fde-generated.json

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "3ed6862aac292e971af7c0a7f5a68968b89b056be60f3cdc883f51534984c1fc",
+    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
+    "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
+    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
+    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
+    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

package/skills/{fde-ship → ship}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-ship
+name: ship
 description: Prepare or execute an authorized controlled release with verified checks, recovery and an operating owner. Use when a customer increment is ready for deployment.
 ---
 
-# fde-ship
+# ship
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/fde-discover/references/discover.md

@@ -1,254 +0,0 @@
-# discover - Frame the problem
-
-**Enter when:** the brief feels wrong, the real problem is unclear, shadow processes are suspected, or any phase found that the map is missing.
-
-**Read first:** `context.md`, `brief.md`. Load `terrain.md` if it exists - extend it, never regenerate from scratch.
-
-## Validation gate (confirm understanding, clarify where it elevates)
-
-Before discovering, state what you're investigating and why in 2-3 lines:
-
-> "Investigating: [the hypothesis or problem area]. This informs: [the decision it feeds - descope/rescope/pick A over B]. Existing terrain: [what's already mapped vs. what's unknown]."
-
-Then check - probe ONLY if it prevents wasted discovery:
-
-1. **Hypothesis is testable.** If the stated problem is unfalsifiable ("the architecture is wrong") → rephrase it: "I'd narrow this to: [specific testable claim]. That closer to what you're seeing?"
-2. **Discovery feeds a decision.** If there's no named decision → one line: "What changes depending on what we find? That keeps the discovery focused."
-3. **Not repeating previous work.** If terrain.md already covers this area → name it: "Terrain already maps this from Day [X]. Extending it or has something shifted?"
-
-State your read, let the FDE correct, then discover.
-
-Before asking for facts, inspect the supplied brief and existing redacted records for the answer. Once the decision frame is confirmed and code access is authorized, use the scan below and targeted file reads to resolve technical unknowns. Phrase remaining questions around the discrepancy found: “The queue already exists, but alerts are disabled; who currently checks it?”
-
-## Brief interrogation (when the hypothesis is still mush)
-
-Use when the "problem" is unfalsifiable, success is undefined, or you cannot name the decision discovery informs. Skip when `reality.md` / `terrain.md` already pin a testable claim and the FDE is ready to dig.
-
-Same format as land - one Q + GUESS, no checklist:
-
-```
-READ: <the real problem you think exists, in one sentence>
-CONFIDENCE: ~NN% - missing: <what would falsify or confirm it>
-Q: <one question that changes where you dig>
-GUESS: <your answer, so they can correct it>
-```
-
-Stop when you can write the four lines under **Frame the decision first**. If a name, quote, or metric is still missing, write `unknown - ask:` - never invent ops folklore to make the map look complete.
-
-## Frame the decision first
-
-Same SCQA spine as readout (`S → C → Q → A`), aimed at the floor, not a deck. Write it **before** any scan. Confirm with the FDE, then dig.
-
-| Line | What it is | Fail if |
-|------|------------|---------|
-| **Situation** | What they already treat as true - the workaround, the sheet, the owner who left | It could be copied from the RFP |
-| **Complication** | What broke, so they cannot stay here | No tension, or three problems joined by "and" |
-| **Question** | One decision the named signer must make | It smuggles the solution ("how do we add alerting") |
-| **Answer-space** | Shape of a satisfying answer: confirm brief / descope / rescope / pause | A novel, or "insights" |
-
-Tests on **Question** - rewrite until all five hold:
-
-1. **Decision-shaped** - answering it changes what someone does.
-2. **Single** - one thing, not three.
-3. **Scoped** - who, where, by when.
-4. **Answerable** - evidence could settle it in this engagement.
-5. **Neutral** - does not assume the fix.
-
-Cannot write the Question → keep interrogating. Do not `fde scan`. Every later output of this phase aims at that Question. Sub-questions go to the operating map or `assumptions.md`, not into the Question.
-
-## Parts of the problem (decompose only)
-
-After the Question is locked, and **before** `fde scan` or any option: write what the problem is made of. No advice, no playbook, no solution.
-
-If the stated brief hides a deeper job, name that deeper job in one sentence and **wait**. Do not silently replace their problem with yours.
-
-In `terrain.md` under `## Parts`, list the smallest useful pieces that still change what you examine next. Typical cuts: people, process step, system, data, time, cost. For each piece: what it contains, and how it connects to the Question. Stop when a further split would not change where you dig.
-
-Do not mark pieces as facts or assumptions here. That is `test-assumptions`. Do not assemble options here. That is `three-options`.
-
-## Method - part 1: the codebase (you do this work)
-
-**First code move: `fde scan`** - after the Question is locked. It runs everything below deterministically in seconds (churn×tests, "temporary" archaeology, AI components, secrets redacted, previous attempts). Your job is then **interpretation**: read its output against the brief, follow the hotspots into the code, and connect the technical findings to the human signals in part 2.
-
-If the CLI is unavailable, run the manual commands below. Either way: do not load the full codebase into context - scan wide, read deep only on hotspots.
-
-**1. Stack and age.** Language, framework, build system, date of last major upgrade:
-```bash
-git log --reverse --format="%ad" --date=short | head -1   # repo birth
-git log -1 --format="%ad" --date=short                     # last commit
-```
-
-**2. Churn heat - the modules everyone touches but fears:**
-```bash
-git log --since="90 days ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20
-```
-The highest-churn file in a legacy codebase is the one everyone is afraid to refactor but cannot avoid touching. Cross-reference with complexity (file size, nesting) and mark "handle with care."
-
-**3. Test gaps - what's covered, what's a lie:**
-```bash
-find . -path ./node_modules -prune -o -name "*test*" -print | head -30
-```
-Map test files against the churn list. A high-churn module with no test neighbors is a load-bearing wall with no insurance. Spot-read the tests that do exist: tests that pass but assert nothing are worse than no tests - note them.
-
-**4. The "temporary" archaeology** (repeat `--include` per extension - brace globs silently match nothing):
-```bash
-grep -rnE "HACK|FIXME|XXX|temporary|for now|remove this|workaround" \
-  --include="*.js" --include="*.ts" --include="*.py" --include="*.java" \
-  --include="*.go" --include="*.rb" --include="*.cs" --include="*.php" . | head -30
-```
-Temporary code in production is permanent code with an excuse. Each hit is a candidate for "what was never built properly."
-
-**5. AI components - they fail silently:**
-```bash
-grep -rlnE "openai|anthropic|llm|prompt|embedding|vector|inference" \
-  --include="*.js" --include="*.ts" --include="*.py" --include="*.java" \
-  --include="*.go" . | head -20
-```
-Flag every one. AI components don't fail like regular code - they degrade as the world changes. Each needs: model version, fallback path (or note its absence), observability (or note its absence).
-
-**6. Data flow.** Where data enters, how it moves, where it stops. Entry points first: routes, queues, cron, file drops.
-
-**7. Existing capability.** Trace the requested user action through existing code, configuration, tests, and operating workarounds. In `terrain.md`, record what can already be reused and the evidence that it works or fails. Check whether a configuration, ownership, or process change could resolve the observed break. A disabled feature is a lead, not a proven root cause. Keep observations and hypotheses distinct; option selection still belongs to plan / three-options. Summarize the remaining gap in `reality.md`: what works today → what the customer needs → what is still missing, with sources. If existing capability meets the need, say so; do not manufacture a build requirement.
-
-## Method - part 2: the humans (you coach, the FDE asks)
-
-The real spec is what people **do** when the system fails - not what the slide deck says. Arm the FDE with these, in their own words:
-
-- **"How is the team coping today without the fix?"** - the workaround is the honest requirements doc.
-- **Find the spreadsheet.** Almost always there. Whoever maintains it is the best interview in the building.
-- **The hesitation.** When someone says "well, there's also this other thing we do…" - stop them, ask them to finish. The main story is what they're comfortable explaining; the hesitation is the real problem.
-- **"Which part of the codebase do you least want to touch?"** The answer is unanimous and it's the load-bearing wall. Check it against your churn scan - when the human answer and the churn data agree, that's your first map landmark.
-- **Shadow AI.** Someone pasting data into ChatGPT to cope = a real unmet need + an uncontrolled data risk. Note both.
-- **Exception-led operating map.** For each real break (not the slide-deck process): what fails, who notices first, what they do today, and which artifact is trusted in that moment. Prefer exceptions over happy-path swimlanes - the workaround is the operating system. Write rows under `terrain.md` → `## Operating map (exception-led)`. If the section is missing on an older engagement, add it; never regenerate the rest of terrain. When AI is in play, also fill `## Intelligence placement` (deterministic vs LLM judgement vs human approve). **`fde doctor` requires at least one filled exception row before plan/ship/outcome/close** - empty map after discover is a hygiene fail, not optional polish.
-
-## Method - part 3: workshop facilitation
-
-When discovery requires a structured session with multiple stakeholders (alignment, prioritisation, design):
-
-**Before the room:**
-- Define the single decision the workshop must produce - not "discuss options" but "rank the three candidates and commit to one."
-- Cap at 8 people. Every person above 8 halves the probability of a decision.
-- Time-box: 90 minutes max. Anything longer splits into two sessions.
-- Pre-read: one page, sent 48 hours ahead. Nobody will read more.
-
-**In the room (the FDE facilitates, not presents):**
-1. **5 min - frame.** One slide: the decision, the constraint, the deadline. No history lesson.
-2. **15 min - diverge.** Silent post-its (or digital equivalent). Everyone writes before anyone talks - prevents the loudest voice dominating.
-3. **20 min - cluster.** Group themes, name them. The FDE does NOT label - the room labels.
-4. **30 min - converge.** Dot-vote or forced-rank. The FDE counts, the room decides.
-5. **10 min - lock.** State the decision back. "We're saying X. Anyone who can't live with this, speak now." Silence = consent.
-6. **10 min - next steps.** Who does what by when. Written before people stand up.
-
-**After the room:** Summary in `decisions.md` within 2 hours. Decisions decay - what felt clear at 3pm is debatable by 5pm if unwritten.
-
-## Method - part 4: data estate and the pipe
-
-Always map the estate before you score a use case - not only when someone said "AI." A path they cannot feed is a discover miss, not a ship surprise.
-
-**Their words first.** In `terrain.md`, write the names the floor uses for the workaround, the sheet, the exception path, and the person who left. Later plan/ship/review sentences use those names. Do not translate their floor into generic product language.
-
-**The 5 questions (ask the data owner, not the sponsor):**
-1. **Where does data live?** - List every source: databases, warehouses, SaaS exports, spreadsheets, S3 buckets, vendor APIs. Map it.
-2. **How fresh is it?** - Real-time, daily batch, "someone uploads a CSV on Mondays"? Freshness determines what's buildable.
-3. **Who owns it?** - Not "IT" - the named person who can grant access and explain the schema. No named owner: access responsibility remains unverified.
-4. **What's the quality?** - Sample 100 rows from each critical source. Check: nulls, duplicates, format consistency, semantic correctness. A 60% null rate in a key field = that source is fiction.
-5. **What are the governance constraints?** - PII classification, retention policies, cross-border rules, consent basis. One missed constraint = a compliance stop later.
-
-**The pipe (what talks to what).** For each source that a use case depends on, write: the system it flows from and to, the contract (object, table, file, API), whose credentials, what happens when the vendor 500s or the Monday file does not land, and whether the join the sponsor described actually exists. Their IdP, CRM, and warehouse are delivery work when the path needs them - policy questions in `trust-profile.md` are not a substitute.
-
-**The data readiness matrix:**
-
-| Source | Location | Freshness | Owner | Quality (sample) | Governance | Pipe | Verdict |
-|--------|----------|-----------|-------|-----------------|------------|------|---------|
-| _fill per source_ | | | | | | | Ready / Needs work / Blocker |
-
-A use case that depends on a "Blocker" source **or a Blocker pipe** doesn't get scored - it gets a remediation conversation first. `what-breaks` finding an invisible integration at ship is already too late. Write this to `terrain.md` under a `## Data estate` section.
-
-**Promised dependencies are not ready dependencies.** For consequential promises such as "data in two weeks," record or update one dependency entry in `assumptions.md` with the responsible owner, dated verification checkpoint, and evidence needed. Unknown owners or dates stay unknown; propose a checkpoint for confirmation. Link the affected work; if the checkpoint slips, identify what can proceed and what needs replanning. Missing ownership is an unresolved dependency, not proof that the project will fail. On-prem or restricted access is a constraint to investigate, not a red flag by itself.
-
-**Verify the future operator now.** Check the proposed owner in `success.md` against who will actually monitor, recover, and support the result. Record whether they have agreed, access or training gaps, and a practical handoff check there; carry these into `handoff.md` at close. Keep unconfirmed ownership explicit. Reuse supplied evidence and ask only what changes the plan.
-
-## When scope is a transformation, not a single problem
-
-Score every candidate use case before anything gets prototyped:
-
-| Dimension | Question | 1-5 |
-|---|---|---|
-| Business value | What does it cost them unsolved? | |
-| Complexity | How hard to build safely? (5 = hardest) | |
-| Data readiness | Available, clean, sufficient volume today? | |
-
-**Score = (Value × Data readiness) / Complexity.** Highest score gets prototyped first (hand to `poc`). A 5-value/1-complexity/5-readiness case scores 25; a 5-value/5-complexity/2-readiness case scores 2 - they look identical on a whiteboard. Never let a technically interesting use case override the score.
-
-## Artifact (this IS the memory - write it as you work)
-
-**`reality.md`** - the readout the FDE takes into the sponsor meeting. Keep the three schema lines the dashboard reads (`Working theory` / `Evidence` / `Differs from brief how`). Then the decision frame:
-
-```markdown
-# Reality (actual problem)
-**Working theory:** <the real problem, one sentence>
-**Evidence:** <workaround/data/quote, source, day>
-**Differs from brief how:** <delta, with evidence>
-**Situation:** <what the floor already treats as true>
-**Complication:** <what forces a decision now>
-**Question:** <one decision-shaped sentence>
-**Answer-space:** confirm brief / descope / rescope / pause - and what a yes looks like
-**Implication for build:** <first change they can see>
-**Validated with:** <who, when>
-```
-
-**`terrain.md`** - the map every later phase loads:
-```markdown
-# Terrain
-**Stack:** <lang/framework/build, age>
-**Hotspots (handle with care):** <file - churn n/90d - tests: none/weak/ok - why it matters>
-**AI components:** <file - model - fallback? - observability?>
-**Data flow:** <entry → transform → store → exit>
-**Test landscape:** <covered / gaps / lies>
-**Unknowns:** <named explicitly - an honest gap beats a confident guess>
-
-## Operating map (exception-led)
-| Exception / break | Who notices first | What they do today | System of record then | Blast | Evidence |
-|-------------------|-------------------|--------------------|----------------------|-------|----------|
-| <break> | <role> | <workaround> | <sheet/DB/person> | CRITICAL / LOAD-BEARING / CONVENIENCE | <who/day> |
-```
-
-Every line carries its evidence. `(churn: 47/90d)` `(ops lead, Day 5)` `(stated, unverified)`.
-
-**`assumptions.md`** - update statuses from what discovery proved or disproved. Seed any new OPEN assumptions the brief never named. CRITICAL + OPEN must be named in the checkpoint.
-
-## Checkpoint (before any build)
-
-Present to the FDE, five things, one paragraph each - no padding:
-1. The Question, then the real problem, with the two strongest pieces of evidence.
-2. The top 3 risk areas of the codebase, one line of why each.
-3. What must not be touched without characterisation tests.
-4. The exception-led operating map: the two breaks that matter most, who owns the workaround, and where shadow systems live.
-5. The Answer-space: confirm brief / descope / rescope - and the decision it puts in front of the sponsor.
-
-If discovery revealed the problem is 3× the brief: the FDE tells the customer **before** telling themselves it's manageable. Lead with evidence, offer three paths (descope / rescope / pause-and-plan), confirm any reset in writing - update `success.md` and `brief.md` before continuing.
-
-## If you've formed three wrong reads
-
-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` keeps the schema, then the frame. **Working theory:** 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. **Differs from brief how:** alerting existed last year and was disabled - adding it again without an owner reproduces the same outcome. **Situation:** Marco re-runs the job every morning and the spreadsheet is truth when it fails. **Complication:** two silent failures since March already hit finance, and the author of the module left in February. **Question:** should Priya fund a named owner on the failure path, or fund alerting and accept the same miss in six months? **Answer-space:** fund ownership / fund alerting-as-theatre / pause until she names who acks. `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 leads with that Question, not a tour of the repo.
-
-## Principles
-
-- The brief is a hypothesis until evidence confirms it.
-- No scan until the Question is one decision the signer must make.
-- The workaround is more honest than the requirements document.
-- Churn data + the human's "don't touch that" pointing at the same module = the map is true.
-- Never modify code before the terrain map exists.
-- Scan wide, read deep only on hotspots.
-
-Before changing a surprising workaround, use the targeted history check in [audit](audit.md#before-changing-an-unfamiliar-workaround). Inspect only the implicated file or region; commit messages supply clues, not proof of current requirements.