fdeops 4.1.1 → 5.1.0

package/skills/demo-prep/references/demo-prep.md

@@ -0,0 +1,31 @@
+# demo-prep - Prepare the demo
+
+**Enter when:** a demo, show-and-tell, or exec walkthrough is coming. FDE engagements live demo-to-demo; a flat demo costs more than a slipped task.
+
+**Read first:** `delivery.md` (what actually works), `stakeholders.md` (who's in the room, what they care about, current signals), `success.md` (the promise being demonstrated), `trust-profile.md` (what must never appear on screen).
+
+## Method (you do this work)
+
+1. **Pick the ONE outcome** the room cares about - from `stakeholders.md`, not from what was hardest to build. Engineers demo effort; the room buys outcomes.
+2. **Build the arc:** the problem in their words → before (the pain, ideally the workaround they recognize) → after, **live** → the one number → what's next. Five beats, ten minutes.
+3. **The one number.** Every demo needs a single memorable quantity ("31 spreadsheet rows to zero", "p95 held at 180ms"). Pull it from `delivery.md`; if no number exists, that's a gap to fix *before* the demo, not narrate around.
+4. **Live vs. canned, decided per beat.** Demo live only what has run clean **twice today**. Everything else: recording or screenshot. A live failure in front of a skeptical room undoes three weeks of trust.
+5. **The hard-question sheet.** Write the five toughest questions this room will ask (check `risks.md` and amber/red stakeholders for where they'll push) + one-line answers with evidence. Include the question you're afraid of.
+6. **The failure plan.** If the live path breaks: the pre-recorded fallback, and the one sentence that keeps the room ("let me show you the captured run while that resets").
+7. **Sacred-data sweep.** Nothing from `trust-profile.md` `<private>` on screen - real customer data, carrier rates, PHI, keys. Demo data is staged data.
+
+## Artifact
+
+`delivery.md` under `## Demo plan - <date>`: the arc, live/canned split, the one number, hard-question sheet, fallback. `context.md`: demo scheduled, prep state, what must run clean twice before it.
+
+## Checkpoint
+
+Dry-run the arc with the FDE once, timed. Confirm: the one number lands in the first three minutes; the riskiest beat has a fallback; the opening line is about *their* problem, not our work.
+
+## Principles
+
+- Demo the outcome, never the architecture.
+- One number per demo. Rooms remember numbers, not features.
+- Never demo live what hasn't run clean twice today.
+- Rough is honest in week one; rough is alarming in week four - match polish to engagement stage.
+- Sacred data stays off screen, every time, no exceptions.

package/skills/demo-prep/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/discover/.fde-generated.json

@@ -0,0 +1,10 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "d97d4192064ae4236e03579a65ec7207445624aee8ad41e412fc3dbaaf465ddc",
+    "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
+    "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

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

@@ -1,9 +1,9 @@
 ---
-name: fde-discover
+name: discover
 description: Trace a customer workflow and identify the problem, baseline and evidence gaps. Use for discovery or an unclear customer brief, before choosing a solution.
 ---
 
-# fde-discover
+# discover
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/discover/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/discover/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/earn-trust/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "c4152a7ee98027f810c3ab11403dea75dee5aae26da24f84de34630c1fd529b6",
+    "references/earn-trust.md": "a3dc4b44686066fbc94fafa4b2fac3c5120d7940256898cec31279f565b912bb",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/earn-trust/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: earn-trust
+description: Plan how to earn customer trust and appropriate access. Use when credibility, permissions or AI policy constrain the engagement.
+---
+
+# earn-trust
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Plan how to earn customer trust and appropriate access. Use when credibility, permissions or AI policy constrain the engagement.
+
+Read [the task context contract](references/task-context.md), then [the method](references/earn-trust.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/earn-trust/references/earn-trust.md

@@ -0,0 +1,100 @@
+# earn-trust - Earn access
+
+**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 (only after `success.md` has a signer, or the FDE overrides with the unknown still visible) | 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/earn-trust/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/{fde-integrate → evaluate}/.fde-generated.json

@@ -2,7 +2,7 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "e7d4fd3e324fe60e1794dc79f532e8f72fb7524fe9cecb215d4c3f82e7b58688",
+    "SKILL.md": "6a8f9490294e1a055c25984955d011db23ebb1eb2fb4f8634584d1455331425e",
     "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
     "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
@@ -10,7 +10,7 @@
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
     "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
     "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
   }
 }

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

@@ -1,9 +1,9 @@
 ---
-name: fde-evaluate
+name: evaluate
 description: Evaluate an AI workflow against representative cases and its permitted actions. Use for model, retrieval or agent evaluation; tests do not grant release authority.
 ---
 
-# fde-evaluate
+# evaluate
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/evaluate/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/fde/SKILL.md

@@ -11,7 +11,7 @@ The **engagement record** for one client, from first meeting to signed outcome.
 
 ## Task entry
 
-Read `references/task-context.md` first. An explicitly selected `fde-*` task runs directly; do not wrap it in another coordinator or repeat entry. For a one-off task with supplied context, use the relevant method without initializing `.fde/`. For ongoing client work use the bounded entry and memory contract below. Missing record files alone are not a reason to restart discovery.
+Read `references/task-context.md` first. An explicitly selected task skill (such as `discover` or `build`) runs directly; do not wrap it in another coordinator or repeat entry. For a one-off task with supplied context, use the relevant method without initializing `.fde/`. For ongoing client work use the bounded entry and memory contract below. Missing record files alone are not a reason to restart discovery.
 
 ## When to use
 
@@ -54,7 +54,7 @@ Use `references/build.md` for implementation, `references/integrate.md` for cust
 
 ## Human surface vs agent plumbing
 
-**FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual `fde-*` skill directly.
+**FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual task skill directly.
 
 **You (agent):** run the CLI. **Never tell the FDE to type** `fde …`. If unbound, you run `fde resume --init` after one question. Never ask them to run the CLI.
 
@@ -126,7 +126,7 @@ Direct. Their words. No "Certainly." Playback 2-4 lines, then act. One question
 
 New embed: sprint / standard / programme changes depth, not which skills exist. Before first code: safe place to break things, plus AI-code policy. Before go-live: who needs to know, what's the rollback. Before a sponsor artifact: as-is or gut-check first.
 
-Muddy signal: name it ("discover or rescue - leaning X"). Never a phase-picker interview. Default: land if new, audit if takeover.
+Muddy signal: name it ("discover or rescue - leaning X"). Never a phase-picker interview. Default: brief if new, audit if takeover.
 
 ## Routing - 6 stages
 
@@ -136,11 +136,11 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 
 | You hear | Skill | Reference |
 |----------|-------|-----------|
-| Engage, onboarding, starting fresh, new customer, first meeting, just got the brief, set product strategy, define success metrics, scope the brief | land | `references/land.md` |
+| Engage, onboarding, starting fresh, new customer, first meeting, just got the brief, set product strategy, define success metrics, scope the brief | brief | `references/land.md` |
 | Taking over, previous consultant left, joining mid-project | audit | `references/audit.md` |
 | Need to understand who matters, who decides, map decision rights, who blocks quietly | who-decides | `references/who-decides.md` |
 | Need to earn access, navigate AI policy, build credibility | earn-trust | `references/earn-trust.md` |
-| "Also can you…", scope expanding, timeline unchanged, hold scope, scope the brief after kickoff | hold-scope | `references/hold-scope.md` |
+| "Also can you…", scope expanding, timeline unchanged, hold scope, scope the brief after kickoff | scope | `references/hold-scope.md` |
 
 ### Discover
 
@@ -157,8 +157,8 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 |----------|-------|-----------|
 | Align, break this down, what order, sequence the delivery, align the plan | plan | `references/plan.md` |
 | Sponsor needs justification, need to defend budget or timeline, build the business case | business-case | `references/business-case.md` |
-| Significant decision, multiple approaches, "what should we do?", generate solutions, generate options, not the playbook, from the surviving facts | three-options | `references/three-options.md` |
-| 20 things are "urgent," need to pick the 3 that matter, prioritize three | pick-three | `references/pick-three.md` |
+| Significant decision, multiple approaches, "what should we do?", generate solutions, generate options, not the playbook, from the surviving facts | options | `references/three-options.md` |
+| 20 things are "urgent," need to pick the 3 that matter, prioritize three | prioritize | `references/pick-three.md` |
 
 ### Ship
 
@@ -172,6 +172,7 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 | Exercise the customer journey, browser acceptance, functional QA | qa | `references/qa.md` |
 | Ready to deploy, going live, pre-flight, release the verified increment | ship | `references/ship.md` |
 | Review this change, review the pull request, is it safe, does it match what we agreed | review | `references/review.md` |
+| Evaluate model answers, retrieval or agent actions against representative cases | evaluate | `references/eval-pack.md` |
 | Diff grew / scope creep in the PR / "did we only build what we said" / KEEP JUSTIFY SPLIT DROP | review (+ ship if going live) | `references/review.md` Stage 1 · `references/ship.md` Intent vs diff |
 | Wrap the session / share the thinking / catch teammates up / before I open the PR | (memory contract - session digest) | SKILL.md **Session digest** - write TL;DR + decisions/why into `.fde/`; no transcript sync |
 | "We can always revert" - need to actually test the escape route, rehearse rollback | rollback | `references/rollback.md` |
@@ -184,7 +185,7 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 | Demo coming up, show-and-tell, exec walkthrough, prepare the demo | demo-prep | `references/demo-prep.md` |
 | Just out of a meeting, raw notes, "they said…", "debrief", user interviews, workshop notes, capture the meeting | debrief | the debrief verb (above) + `references/debrief.md` |
 | Make sure we're up to date, pull what's relevant, fetch from Granola/Slack/Gmail/transcript | ingest | `references/ingest.md` (capability check → stage → propose → confirm → apply) |
-| Connect a new MCP / connect Granola Slack or Notion / what can you pull | connect | `references/connect.md` (+ `mcp/recipes/`) |
+| Connect a new MCP / connect Granola Slack or Notion / what can you pull | connect | `references/connect.md` (+ `references/source-setup.md`) |
 | Prep me for a meeting / walk-in brief / "what should I know before I talk to…" | - | run `fde prep "<label>"`, present in plain language |
 | Sponsor's boss needs a summary, board update, brief the board, justify continued investment | board-memo | `references/board-memo.md` |
 | Status across all my customers, view the portfolio | dashboard | `references/dashboard.md` |
@@ -194,9 +195,9 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 | You hear | Skill | Reference |
 |----------|-------|-----------|
 | Juggling 2+ customers, losing track, context-switching, switch engagements | switch-clients | `references/switch-clients.md` |
-| Transfer, wrapping up, handoff, making yourself replaceable, transfer operations | close | `references/close.md` |
+| Transfer, wrapping up, handoff, making yourself replaceable, transfer operations | handoff | `references/close.md` |
 | Engagement ending, team needs to operate without you, write the runbook | runbook | `references/runbook.md` |
-| Something worked well and will apply to future engagements, encode the pattern | encode-pattern | `references/encode-pattern.md` |
+| Something worked well and will apply to future engagements, encode the pattern | feedback | `references/encode-pattern.md` |
 | "Red-team this," "stress-test my plan," poke holes, challenge the plan, what am I missing | red-team | `references/red-team.md` |
 | "What did we agree about X?", scope dispute, receipts | - | run `fde receipts <term>`, answer with dates |
 

package/skills/fde/references/connect.md

@@ -1,34 +1,24 @@
 # connect - Connect a source
 
-**Enter when:** the FDE says "I want to connect a new MCP", "connect Granola / Slack / Notion", "how do I pull from …", or a pull request fails because no source tools exist.
+**Enter when:** the user asks to connect a notes, chat or document source, or an expected source cannot be read.
 
-**Read first:** `references/ingest.md` (sink contract). Recipes: `mcp/recipes/` (file, granola, slack, notion).
-
-**Who runs setup:** you guide; the **host** (Cursor/Claude) must save MCP config. You cannot silently install servers into the host.
-
-## Honest contract
-
-- **Daily work does not need a source MCP.** Paste notes → debrief. File on disk → `fde ingest`.
-- **Connect means a source**, not FDEOps. Granola/Slack/Notion credentials stay with that MCP. FDEOps never pushes, never ambient-syncs, never stores their tokens.
-- **Sink is the CLI in this bound workspace** (`fde ingest`). `fdeops-ingest` MCP is optional. If you use it, pass `engagement` as the `.fde/` path from `fde resume --bind` (MCP servers often do not inherit the workspace bind).
-- Never invent that Granola/Slack is available if tools are missing. Never auto-apply to `.fde/`.
+Apply [task context](task-context.md). Source setup can run independently of a customer record. Follow [source setup](source-setup.md) for permitted tools, credentials, connectivity checks and export alternatives.
 
 ## Method
 
-1. **Ask one question** - which source? (`file` / `granola` / `slack` / `notion` / other). If "other", ask for the MCP they intend to use. If they just want paste → send them to debrief and stop.
-2. **Capability check (current session)** - list MCP tools you can actually call:
-   - Sink: `fde ingest` CLI (preferred) and/or `ingest_stage`
-   - Source: anything that can **fetch** that system's content (not post)
-   - Say clearly: *available now* vs *needs config*.
-3. **Emit config for the source only** - open `mcp/recipes/<source>.md`. Fill placeholders from *that product's* docs. Tell them to paste secrets into host env - never into `.fde/`.
-4. **Tell them where to paste** - Cursor MCP settings / `mcp.json`. Claude Code: their MCP config. Save → reload MCP / restart session.
-5. **Verify** - after reload: re-run capability check. If source tools appear, offer a **test pull** staged to `.inbox/` only. Stop before apply unless they ask to propose.
-6. **Handoff phrase** - e.g. `@fde pull today's Acme Granola into the fieldbook`.
+1. Identify the source and the material the user wants to read. Inspect the host's actual available tools before recommending setup.
+2. If the source already works, use a narrowly scoped requested read. Do not install another connector.
+3. If setup is needed, verify current provider and host documentation, explain the required access, and make only authorized configuration changes. Never put credentials into prompts or customer records.
+4. Test the selected source and distinguish configuration from successful retrieval. If access is blocked, report the specific limitation and an available file or paste alternative.
+5. If the user also wants to update a customer record, continue with [ingest](ingest.md) after selecting that record. Otherwise stop after the requested setup or read.
 
-## If they only want paste / files
+## Checkpoint
 
-Do not add MCP. Use debrief or [mcp/recipes/file.md](../../../mcp/recipes/file.md).
+Return what is connected, what read was verified, any access gap, and how to request the next pull. Do not claim an integration works from configuration alone or write customer records during setup.
 
-## Checkpoint
+## Principles
 
-Before ending connect: (1) they know paste still works, (2) source reachable or honest gap, (3) they know the pull phrase. Do not write `.fde/` during connect.
+- Existing source tools first; configuration only when needed.
+- Minimum requested read, no ambient synchronization.
+- Credentials stay in supported secret storage.
+- Record updates require their own review and confirmation.

package/skills/fde/references/debrief.md

@@ -2,6 +2,8 @@
 
 **Enter when:** the FDE just left a meeting/call and dumps raw notes, a transcript, or "they said…". Highest-frequency moment in FDE life. Capture within the hour.
 
+**Standalone review:** apply [task context](task-context.md). If the user supplies notes and wants a summary or review, interpret them using **Prepare one update** below and return a draft. Keep requests, confirmed decisions, reported results and unknowns distinct. No CLI or customer record is needed; do not claim anything was saved. Use the bound-record path below only when updating an existing record or when the user asks to start one.
+
 **Large transcripts or emails** sitting in Granola/Gmail/Notion → prefer **`fde ingest stage`** first (via source MCPs the FDE configured), then the same propose → confirm → **`fde ingest apply`** path. See `references/ingest.md`. Pasted short notes stay on this debrief verb.
 
 **Read first:** the bounded `fde resume` packet for the bound client. Use `fde recall` for the specific prior decision, action, or delivery result needed to reconcile this update. Do not reload the whole engagement.