fdeops 4.1.1 → 5.1.0

package/skills/who-decides/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "33a822a1e10824461543e296f93e07ed3f8e2eab7a719bcde4bb3bbef597859c",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
+    "references/who-decides.md": "56c577f0984cb69cfb18349fc9194e92dba2b56ead9a527d5e6e887c1219717f"
+  }
+}

package/skills/who-decides/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: who-decides
+description: Map stakeholders, decision rights, influence and blockers from supplied evidence. Use when ownership is unclear or the stakeholder landscape changes.
+---
+
+# who-decides
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Map stakeholders, decision rights, influence and blockers from supplied evidence. Use when ownership is unclear or the stakeholder landscape changes.
+
+Read [the task context contract](references/task-context.md), then [the method](references/who-decides.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.

package/skills/who-decides/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
+
+Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/who-decides/references/who-decides.md

@@ -0,0 +1,91 @@
+# who-decides - Map decision rights
+
+**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.
+
+**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.
+- 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.
+
+**6. Before a decision meeting: pre-wire, then pre-mortem.**
+
+A recommendation that needs several people to say yes is not won in the room; it is won in the week before it. When the FDE is heading into a go/no-go, a budget ask, or anything that visibly costs someone territory:
+
+- **Sort by position, not by seniority.** Firm supporter / firm opponent / **swing**. Effort goes almost entirely to swings - supporters need reinforcement, not persuasion, and a firm opponent is rarely moved by a louder version of the argument that already failed.
+- **Name what each swing is protecting.** The objection voiced in a meeting is usually a proxy: headcount, budget, credibility, control, or the reporting line that gets messier. Write the underlying motivation next to the stated objection - they are different sentences.
+- **Sequence the conversations.** Whoever makes the others easier to win goes first; whoever is reassured by seeing names already on board goes last. One-on-one for anyone who would lose face conceding in a group.
+- **Pre-mortem the meeting.** "It's Thursday, the meeting went badly - who sank it, and with what sentence?" That sentence is the pre-wire you are missing. If the answer is a specific person's objection, their conversation happens *before* the room convenes, not in it.
+
+Log the sequence and the pre-mortem sentence in `context.md` as the plan for the week - a pre-wire plan that lives only in the FDE's head is not a plan.
+
+## 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.
+
+## Worked example
+
+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.
+
+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.
+
+## 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-discover/.fde-generated.json

@@ -1,10 +0,0 @@
-{
-  "generator": "bin/generate-skills.js",
-  "version": 1,
-  "files": {
-    "SKILL.md": "ca2ab4e5d01f8715b344e0726a692aa6bc66a599a45ebea37b7f8e05f71b1e65",
-    "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
-    "references/discover.md": "6fc143a4224248c496b209bf36509c2f1aac7872aa0c0ba82656a94d0dee0f66",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
-  }
-}

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.

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

@@ -1,9 +0,0 @@
-{
-  "generator": "bin/generate-skills.js",
-  "version": 1,
-  "files": {
-    "SKILL.md": "c70af27393a64319c7113cf100328b05bc317b0b95aba73ac5f3c77976ba24d9",
-    "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
-  }
-}

package/skills/fde-feedback/references/task-context.md

@@ -1,12 +0,0 @@
-# Task context and evidence
-
-Use this contract for standalone methods and methods routed through `@fde`.
-
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
-- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
-- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
-- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
-- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
-- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
-
-Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/fde-handoff/references/task-context.md

@@ -1,12 +0,0 @@
-# Task context and evidence
-
-Use this contract for standalone methods and methods routed through `@fde`.
-
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
-- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
-- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
-- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
-- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
-- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
-
-Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/fde-integrate/references/task-context.md

@@ -1,12 +0,0 @@
-# Task context and evidence
-
-Use this contract for standalone methods and methods routed through `@fde`.
-
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
-- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
-- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
-- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
-- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
-- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
-
-Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/fde-options/references/task-context.md

@@ -1,12 +0,0 @@
-# Task context and evidence
-
-Use this contract for standalone methods and methods routed through `@fde`.
-
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
-- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
-- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
-- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
-- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
-- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
-
-Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.