fdeops 5.1.10 → 5.1.12

package/skills/feedback/references/encode-pattern.md

@@ -4,7 +4,7 @@
 
 **Enter when:** the engagement is closing and reusable patterns exist, a technique worked well and will apply to future clients, the FDE notices themselves doing the same thing on a second engagement, or close identified a pattern worth preserving.
 
-**Read first:** `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `context.md`. Patterns live in what was *done*, not what was planned.
+**Read first:** permitted evidence from `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `patterns.md`, and `context.md`. For a bound engagement, use `fde recall <topic>` to retrieve relevant client patterns and retrospective excerpts; do not load whole directories. Patterns live in what was *done*, not what was planned.
 
 The difference between a 5-year FDE and a 15-year FDE is not talent - it's encoded patterns. The 15-year FDE walks into a new engagement and recognises the situation in minutes because they've seen it before, named it, and know the move. Pattern extraction turns experience into reusable intelligence.
 
@@ -49,7 +49,7 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 | **Specific enough?** | Contains concrete steps, not just principles | "Build trust" / "Communicate well" - too vague to act on |
 | **Repeatable?** | Applies to a class of situations, not just this one | Only worked because of a unique circumstance |
 | **Falsifiable?** | You can tell when the pattern is working or not | No way to measure whether applying it helped |
-| **Monday bag?** | You would refuse the next similar embed without this in your bag - a named move plus an artifact you can drop on day one (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." Patterns that only live in this client's `.fde/` do not compound |
+| **Useful again?** | A named move plus an artifact you could use when the situation and policy permit (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." No concrete move or conditions for reuse |
 
 **4. Classify by stage.** Patterns sort into the same stages as the skills:
 
@@ -69,17 +69,15 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 - After modification: increment minor version with what changed and why
 - After contradiction: note the counter-example, adjust the "watch out for" section
 
-**6. Cross-engagement pattern mining.** Only when explicitly authorized for the named engagements and permitted by each customer's data policy. Keep records separate; use sanitized CLI packets or targeted recall in each authorized context, never raw file comparisons. Otherwise extract a candidate from the current permitted context only.
+**6. Review before reuse.** Client patterns and retrospectives remain in that client's record. Recall relevant evidence with `fde recall <topic>` and check the situation trigger, applicability, counterexamples, and current policy before applying a move. Previous success is historical evidence, not present authority or proof of fit.
 
-- Compare permitted problem summaries - do the same problems recur?
-- Compare permitted decision summaries - are the same decisions being made?
-- Compare permitted lessons - are the same lessons being learned twice?
+Cross-client reuse requires an explicitly approved generalization exported to a user-chosen destination, permitted by the source customer's data policy. Review exactly what will leave the record before export. Do not automatically scan other clients, export patterns, or maintain a shared library. In the receiving engagement, use only the approved export and recheck applicability, counterexamples, and that customer's policy before reuse; do not pull the source client record into its context.
 
 A pattern learned twice is a process failure. Encoding it prevents the third time.
 
 ## Artifact
 
-**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A shared library is a separate, authorized export: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations.
+**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A cross-client export is separate and explicitly approved, to a user-chosen destination: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations with their limits and counterexamples.
 
 **`retrospectives/YYYY-MM-DD-<engagement>.md`** - reference to which patterns were extracted from this engagement.
 
@@ -93,4 +91,4 @@ Present the extracted patterns to the FDE: "From this engagement, I've identifie
 - Patterns are steps, not principles. "Build trust" isn't a pattern; "fix a small visible bug on day one" is.
 - Every pattern needs a situation trigger - the FDE must recognise when it applies.
 - Version substantive changes. State the evidence and limits; repeated use is not automatic confirmation.
-- The pattern library is the FDE's compound interest. It's what separates 5 years of experience from 1 year repeated 5 times.
+- Keep client evidence local to its record; share only explicitly approved generalizations.

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

@@ -4,8 +4,9 @@
   "files": {
     "SKILL.md": "c4ac99ee1517c0674e5324b289521116c58a9e0ac3de22c229be8da83438f4db",
     "agents/openai.yaml": "93ac049cf1a9d0fdfdf67d34ca6d3dd33800e91334f38bb303828eab8c4b3aaf",
-    "references/close.md": "b3dbc1ecef12ee1c9d298e32a21d87ce61c9f6c88039d7a8b19970c6e3f21254",
-    "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
+    "references/close.md": "fa3579e02e2434273941ab158b5807bedaddefaa4b820a0f1cb29b1459c20f31",
+    "references/encode-pattern.md": "9740d97faa8491d168410916c9003ea9a651a1507da186dcb29ce6e58eba6773",
+    "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/handoff/references/close.md

@@ -6,31 +6,38 @@ For a standalone handoff draft, use the supplied notes and project evidence; no
 
 **Enter when:** the engagement is ending - the customer team must run this without the FDE.
 
-**Read first:** for standalone work, use the supplied permitted operating notes, evidence and ownership; no engagement binding or CLI command is required. For a bound engagement, use bounded `fde handoff` or `fde resume`, then targeted `fde recall` for missing evidence. Never initialize records merely to draft a handoff. Build the picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for code paths needed by the successor.
+**Read first:** for standalone work, use the supplied permitted operating notes, evidence and ownership; no engagement binding or CLI command is required. For a bound engagement, use bounded `fde handoff` or `fde resume`, then `fde recall <topic>` for relevant client patterns, earlier retrospectives, and missing evidence. Never initialize records merely to draft a handoff. Build the picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for code paths needed by the successor.
 
-The engagement doesn't end at ship. It ends when the customer can maintain what was built without calling.
+A handoff transfers the ability to operate the system, not just its files.
 
-## Method (you do this work, with the FDE's answers)
+## Match the requested output
 
-**0. The opening question:** "What will bite them when you're gone?" Their answer shapes everything written below.
+- **Draft a handoff:** return the operating summary, evidence and gaps from supplied context. Do not require a retrospective, initialized record or completed value measurement to produce a useful draft. Missing evidence limits readiness claims, not drafting. Follow steps 0, 3 and relevant operating details in 4, then check the draft as a lookup tool. Skip the closure-only steps and artifacts.
+- **Assess readiness or close the engagement:** apply the close gates below. Reuse existing evidence and agreed acceptance rather than restarting the engagement.
 
-**1. The retrospective.** Work through, blame-free and specific:
+Lead with what is being transferred, what the receiving team can demonstrably do, what is untested, and the next action with its owner or ownership gap. A document can be ready for review while operational handover remains incomplete.
+
+## Method
+
+**0. Find the operating gap.** Use supplied evidence to identify what still depends on the departing engineer. Ask “What will bite them when you’re gone?” only if the answer would change the handoff; do not repeat information already supplied.
+
+**1. Closure only: the retrospective.** Work through, blame-free and specific:
 - Did the real problem match the brief? (Compare `brief.md` vs `reality.md` - you have the receipts.)
 - Which trust moments mattered?
 - What did the codebase teach that `terrain.md` didn't know at the start?
 - Which risk almost became real?
 - AI components: did they behave in production? What failure modes did the prototype hide? Is the team equipped to maintain them?
 
-**1b. Value + receipts close gate (refuse green close if any fail):**
+**1b. Closure/readiness assessment only: value + receipts gate (refuse green close if any fail):**
 - Primary value bucket in `success.md` matches what the sponsor funded; at least one ledger row has **Measured** (not forever-`pending`) with evidence **and a named customer-side owner in Accepted by** for that bucket - or the retrospective explicitly records “not measured; sponsor accepted pending.” A measured-but-unaccepted number closes as `claimed`; say so in the retrospective rather than closing green on arithmetic nobody signed.
 - The receiving team has accepted the operating responsibilities with a source. Critical operating capabilities (such as access, failure triage, recovery and disabling an AI action) are recorded as verified, failed or untested under the receiving team's intended access. Reuse applicable accepted ownership and drill evidence; a lookup exercise or a run using only the departing FDE's credentials is insufficient. Unresolved critical gaps prevent green closure.
 - Audit receipt exists for the final shipped path (exceptions/operating map walked; cite file).
 - Eval receipt: **n/a if no AI**, else final scoped eval result + operating owner and required human-review or bounded-automation authority recorded; kill switch / fallback named in `handoff.md`.
 - One line in the retrospective: which bucket moved, by how much, vs baseline.
 
-**2. The pattern.** Anything that happened here and will happen again - a compliance approach, a migration pattern, a stakeholder dynamic - gets encoded for reuse. Use [encode-pattern](encode-pattern.md) to distinguish candidate patterns from supported ones and protect customer data.
+**2. Closure only: the pattern.** Anything that happened here and may happen again - a compliance approach, a migration pattern, a stakeholder dynamic - is a candidate for the client's `patterns.md`. Use [encode-pattern](encode-pattern.md) to record applicability, counterexamples, and evidence. Cross-client generalizations need explicit approval and a user-chosen export destination under the applicable policy; closing an engagement does not authorize an automatic scan or export.
 
-**3. The handoff.** Operational knowledge for the person woken at 2am, not technical documentation: the 3 things that will break and the fix for each · who holds the tribal knowledge · what each alert means · deploy and rollback in plain language. AI components additionally: model version, what normal output looks like (so drift is recognisable), fallback behaviour, who owns evaluation and corrective changes, and how to disable or contain the AI path using the supported fallback. Do not assume retraining is available or appropriate.
+**3. The handoff.** Operational knowledge for the person woken at 2am, not technical documentation: the relevant observed failures, their recovery steps and any untested procedure · who holds the tribal knowledge · what each alert means · deploy and rollback in plain language. AI components additionally: model version, what normal output looks like (so drift is recognisable), fallback behaviour, who owns evaluation and corrective changes, and how to disable or contain the AI path using the supported fallback. Do not assume retraining is available or appropriate.
 
 **4. Transformation engagements - four extra answers in `handoff.md`:**
 - Who owns AI governance after the FDE leaves? (Who can pull a model from production?)
@@ -40,7 +47,9 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Artifact
 
-**`retrospectives/YYYY-MM-DD-<engagement>.md`** - one file per close (separate files make cross-engagement patterns scannable). **`patterns.md`** - reusable patterns extracted. **`handoff.md`** - the 2am document.
+For a draft-only request, return the handoff in the requested format with evidence gaps and readiness status. Do not create retrospective or pattern artifacts. The following record destinations apply when closing a bound engagement under its write rules.
+
+**`retrospectives/YYYY-MM-DD-<engagement>.md`** - one file per close, retaining dated lessons for targeted recall within this client. **`patterns.md`** - client pattern candidates and evidence. **`handoff.md`** - the 2am document, including the deployed revision and the policy, access, and ownership evidence current at handoff. If the project reopens, use [land](land.md) to recheck these before dependent action; closure evidence remains historical.
 
 ## Checkpoint
 
@@ -48,7 +57,7 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 If the operator is unavailable, a fresh reviewer can attempt the same lookup using only the permitted draft and task. Report this as a simulated clarity check, not operator validation, customer approval, or a green close. Claim independent review only if a separate reviewer actually performed it; identify the reviewer and evidence available. If none is available, perform a labeled self-check and report independent review as unperformed. Use one focused pass for a consequential handoff; do not add a committee or a second approval ritual.
 
-Direct assessment to the FDE: did the engagement achieve `success.md` · 2-3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
+For closure or readiness assessment, report to the FDE: did the engagement achieve `success.md` · 2-3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
 
 ## Worked example
 
@@ -58,7 +67,7 @@ Retrospective against the receipts: `brief.md` asked for monitoring, `reality.md
 
 The close gate bites in a useful way. The ledger shows detection at 12 minutes measured across two real incidents, but **Accepted by** is empty - Marco confirmed it in Slack, but Denise, the recorded acceptance owner, has not accepted the result. Her authority comes from the agreed acceptance record, not her finance title or the fact that she raised the original problem. So it closes as `claimed` with a one-line retrospective note and a named next step, rather than a green close on a number the agreed acceptance owner has not accepted.
 
-`handoff.md` is written for the person woken at 2am: the three things that break, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job - credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* - it has now happened twice.
+`handoff.md` is written for the person woken at 2am: the observed failure modes, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job - credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* - it has now happened twice.
 
 ## Principles
 

package/skills/handoff/references/encode-pattern.md

@@ -4,7 +4,7 @@
 
 **Enter when:** the engagement is closing and reusable patterns exist, a technique worked well and will apply to future clients, the FDE notices themselves doing the same thing on a second engagement, or close identified a pattern worth preserving.
 
-**Read first:** `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `context.md`. Patterns live in what was *done*, not what was planned.
+**Read first:** permitted evidence from `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `patterns.md`, and `context.md`. For a bound engagement, use `fde recall <topic>` to retrieve relevant client patterns and retrospective excerpts; do not load whole directories. Patterns live in what was *done*, not what was planned.
 
 The difference between a 5-year FDE and a 15-year FDE is not talent - it's encoded patterns. The 15-year FDE walks into a new engagement and recognises the situation in minutes because they've seen it before, named it, and know the move. Pattern extraction turns experience into reusable intelligence.
 
@@ -49,7 +49,7 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 | **Specific enough?** | Contains concrete steps, not just principles | "Build trust" / "Communicate well" - too vague to act on |
 | **Repeatable?** | Applies to a class of situations, not just this one | Only worked because of a unique circumstance |
 | **Falsifiable?** | You can tell when the pattern is working or not | No way to measure whether applying it helped |
-| **Monday bag?** | You would refuse the next similar embed without this in your bag - a named move plus an artifact you can drop on day one (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." Patterns that only live in this client's `.fde/` do not compound |
+| **Useful again?** | A named move plus an artifact you could use when the situation and policy permit (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." No concrete move or conditions for reuse |
 
 **4. Classify by stage.** Patterns sort into the same stages as the skills:
 
@@ -69,17 +69,15 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 - After modification: increment minor version with what changed and why
 - After contradiction: note the counter-example, adjust the "watch out for" section
 
-**6. Cross-engagement pattern mining.** Only when explicitly authorized for the named engagements and permitted by each customer's data policy. Keep records separate; use sanitized CLI packets or targeted recall in each authorized context, never raw file comparisons. Otherwise extract a candidate from the current permitted context only.
+**6. Review before reuse.** Client patterns and retrospectives remain in that client's record. Recall relevant evidence with `fde recall <topic>` and check the situation trigger, applicability, counterexamples, and current policy before applying a move. Previous success is historical evidence, not present authority or proof of fit.
 
-- Compare permitted problem summaries - do the same problems recur?
-- Compare permitted decision summaries - are the same decisions being made?
-- Compare permitted lessons - are the same lessons being learned twice?
+Cross-client reuse requires an explicitly approved generalization exported to a user-chosen destination, permitted by the source customer's data policy. Review exactly what will leave the record before export. Do not automatically scan other clients, export patterns, or maintain a shared library. In the receiving engagement, use only the approved export and recheck applicability, counterexamples, and that customer's policy before reuse; do not pull the source client record into its context.
 
 A pattern learned twice is a process failure. Encoding it prevents the third time.
 
 ## Artifact
 
-**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A shared library is a separate, authorized export: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations.
+**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A cross-client export is separate and explicitly approved, to a user-chosen destination: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations with their limits and counterexamples.
 
 **`retrospectives/YYYY-MM-DD-<engagement>.md`** - reference to which patterns were extracted from this engagement.
 
@@ -93,4 +91,4 @@ Present the extracted patterns to the FDE: "From this engagement, I've identifie
 - Patterns are steps, not principles. "Build trust" isn't a pattern; "fix a small visible bug on day one" is.
 - Every pattern needs a situation trigger - the FDE must recognise when it applies.
 - Version substantive changes. State the evidence and limits; repeated use is not automatic confirmation.
-- The pattern library is the FDE's compound interest. It's what separates 5 years of experience from 1 year repeated 5 times.
+- Keep client evidence local to its record; share only explicitly approved generalizations.

package/skills/handoff/references/land.md

@@ -0,0 +1,138 @@
+# land - Interrogate the brief
+
+**Enter when:** new customer, first meeting, just got the brief, nothing started yet, or an old or closed project is reopening.
+
+**Read first:** apply [task context](task-context.md), then permitted `context.md` evidence if it exists and the supplied brief. Once the engagement type and AI/access policy are known, inspect the supplied repo/docs relevant to the ask before asking questions they can answer. This is a bounded evidence check, not a full discovery scan.
+
+## Validation gate (confirm understanding, clarify where it elevates)
+
+Before landing, state what you know in 2-3 lines:
+
+> "New engagement: [client name]. Timeline: [days/weeks/months or 'not clear yet']. Starting with: [what the FDE has told you so far - the brief, the context, the ask]."
+
+Then check - probe ONLY if it prevents a bad start:
+
+1. **Engagement speed.** If timeline is unclear → weave it in naturally: "Is this days, weeks, or months? That shapes how much structure we set up now."
+2. **Existing context.** If `.fde/` already exists → one line: "There's existing engagement memory here. Continuing this or starting fresh?"
+3. **Access.** If the FDE is about to start work → one line: "Got repo and environment access sorted, or is that still pending?"
+
+State your read, let the FDE correct, then land.
+
+**Reopening an old or closed project:** after the privacy-safe context check, use `fde recall <topic>` for relevant client patterns, retrospectives, and prior decisions. Treat old evidence as historical. Before dependent action, recheck current AI/data policy, access, decision and operating owners, and the deployed revision against current permitted evidence. Record changes and unknowns; an old approval or successful drill does not establish present authority or readiness. Continue independent preparation while material gaps are resolved.
+
+## Brief interrogation (only when the brief is thin)
+
+Use this when the ask is conventional or underspecified - missing who decides, why now, what success looks like, or the binding constraint. **Do not** run it when the FDE already gave a clear brief, is mid-flow, or asked for speed over verification.
+
+Format - one question at a time, with a guess the FDE can correct:
+
+```
+READ: <one sentence - what you think they actually need>
+MISSING: <fact or authority that changes the next action>
+Q: <one focused question>
+POSSIBLE READ: <clearly labeled interpretation, if useful; never guessed authority>
+```
+
+Wait for the reaction before the next question. Stop when the next authorized action is clear, or when the FDE says move on; unanswered material gaps remain visible. Every answer that is still unknown stays `unknown - ask:` in the artifact - never fill the gap with a plausible stakeholder.
+
+## Method - part 1: interrogate the brief (you do this work)
+
+Read the brief the FDE gives you. Separate **observed** (source/path and date), **reported** (who said it), and **hypothesis** (how to test it). A requested solution such as “build an agent” is not evidence of the cause. Ask only about gaps that change scope, access, acceptance, or the next investigation. What is **not** in the brief matters as much as what is. Produce the gap list yourself:
+
+- **No named decision-maker** → identify who or what can accept the outcome and the source of that authority; keep it unknown until established.
+- **"Straightforward cleanup" on an 8-year-old system** → inspect permitted relevant history and tests for prior attempts and constraints; age alone proves neither complexity nor a previous failure.
+- **Very tight timeline** → establish the deadline, its source and which commitments are actually agreed.
+- **No out-of-scope section** → clarify material boundaries against the existing agreement. An omission does not authorize additional work.
+
+Write these into `brief.md` as **questions to answer**, not problems - they're what the FDE is walking in to resolve.
+
+Pre-arrival checks to run through with the FDE:
+- Access confirmed for the next task? Repo, environment and docs may have different permissions; identify gaps before dependent work.
+- Has someone tried this before? Establish what happened and what evidence remains; do not assume the attempt failed.
+- Other vendors/teams in scope? Then the FDE is not the only one in the room, even when alone in the meeting.
+- Tech stack recon: job postings, GitHub org - know the stack before they say it.
+
+## Method - part 2: the first conversation (you coach, the FDE asks)
+
+Intent: coach the FDE's first *customer* conversation - what keeps the sponsor up at night, personally, not the project charter. You already inspected the supplied brief and any authorized repo/docs. This is before *their* laptop in the room / before a deep build, not before you read evidence. Failure talk surfaces truth faster than "requirements." Angles in the FDE's own words:
+
+- "Before you open the laptop - what would make this a bad engagement for *them*, not just a delayed project?"
+- "What are they afraid you'll miss?"
+- "Who loses credibility if this goes wrong?"
+- "If nothing changes over the agreed timeframe, what happens, and who bears it?" Record the consequence and its source in `brief.md`; distinguish reported impact from measured cost. Unknown cost stays unknown, not an invented ROI.
+
+Allow time for an answer. If a stated concern differs from the brief, record the difference and clarify whether it changes the agreed outcome; neither statement automatically supersedes the other.
+
+**Listen for, and capture as you hear it:**
+- **Decision rights** - who can approve scope, accept the result and authorize release, as relevant. A frequently mentioned person may be influential; confirm their actual authority and scope.
+- **The previous attempt** - "we tried something similar last year" identifies evidence to investigate. Who was involved, what happened, and which constraints still apply? Do not infer why someone left.
+- **The existing internal team** - ask what they tried, what they know and what they expect to own. Use established terminology and credit their work. Do not assume resentment, displacement or complete knowledge of the problem.
+- **The sacred thing** - "Is there anything in this environment I should treat as untouchable?" Capture the stated boundary and applicable policy; hesitation alone does not identify a restriction.
+- **Exception path (operating map seed)** - "When the happy path breaks this week, what do people actually do - who do they call, what spreadsheet opens, what do they skip?" Capture the break → workaround → who owns it. Do not build a full map on day 1; seed rows later in `terrain.md` → `## Operating map (exception-led)` during discover. Unknowns stay `unknown - ask:`.
+- **AI posture and policy** - tools already in use (sanctioned or shadow), and: "Does your organisation have a policy on AI-generated code? Are there decisions where you would not be comfortable with AI involvement?"
+- **Future operator** - "Who will run this after we leave, and have they agreed?" Record the proposed operator and unresolved ownership in `success.md`, separately from the signer. A sponsor naming a team is not that team accepting responsibility; verify with the operator during discover.
+- **Boundaries in multi-vendor rooms** - who owns what surface, who signs off before a change crosses it.
+
+## An early deliverable
+
+Choose an early useful result within confirmed scope: a verified small fix, a permitted diagnostic, or a concise map of an unresolved problem. Reuse the existing outcome and authority for routine work. A first-day deadline does not grant deployment permission or waive verification; use `ship` for a release. If a missing signer blocks a consequential decision, keep it visible and continue independent preparation.
+
+## Artifact (write as the conversation is debriefed)
+
+**`brief.md`** - what they said, who sent the FDE, the timeline, **and the gap list**.
+
+**`success.md`** - what done looks like, **primary value bucket** (`cost-save` | `risk-mitigation` | `revenue-uplift`), baseline → target, who actually signs off, what is explicitly out of scope. Record agreement only with its source and scope; otherwise label the target proposed. For each baseline, record source, date/window, environment, and sample size when relevant. An operator recollection is reported, not measured. If no baseline exists, name the measurement owner and cheapest way to obtain it; do not manufacture a number.
+
+For every target number, run the **gaming check** before it is written down: *how could this metric hit its target without the customer being any better off?* Identify plausible failure modes without predicting that the customer will exploit them. Write a relevant guard next to the metric:
+
+```markdown
+| Metric | Baseline → target | Gamed by | Guard |
+|--------|-------------------|----------|-------|
+| reconciliation alert latency | 4h → 15min | alerting on everything, so nobody reads them | alerts acked by a named owner, ≤2/week |
+```
+
+If a proposed guard is disputed, capture the stated reason and assess its cost and effect on the outcome. Do not infer that the customer values the number over the result.
+
+**`stakeholders.md`**:
+```markdown
+| Who | Role | Signal | Notes |
+|-----|------|--------|-------|
+| <name> | <observed participation role; authority recorded separately> | green/amber/red | <evidence, day> |
+```
+If `stakeholders.md` already has a `## Signal history` section (it does from the template), **never delete or overwrite it** when you rewrite this file - it holds the dated `[signal:...]` tokens `fde log contact --signal` and `fde debrief` write, and `fde status`/`fde receipts`/the dashboard read only from that section. Edit the table above it freely; keep the section below intact.
+
+**`trust-profile.md`** - sacred data (`<private>` tagged), fears heard, AI policy, approval chain. Sensitive: skip for status reads; use CLI/redacted surfaces; never paste raw `<private>` into prompts or subagents.
+
+**`assumptions.md`** - seed consequential unverified claims from the brief (and the initial hypothesis) as rows with Kind `UNKNOWN` (or `CONVENTION` if they said "we always"), blast radius CRITICAL / LOAD-BEARING / CONVENIENCE, and status `OPEN`. Do not wait for test-assumptions - land makes the register exist. Example:
+
+```markdown
+| # | Assumption | Kind | Blast radius | How we test | Status | Evidence |
+|---|------------|------|--------------|-------------|--------|----------|
+| 1 | <claim from brief> | UNKNOWN | CRITICAL | <cheapest falsifying test> | OPEN | (stated, unverified) |
+```
+
+One falsifiable hypothesis about the real problem also goes at the bottom of `brief.md` - discover / test-assumptions will test it.
+
+## Checkpoint
+
+One page back to the FDE: success + value bucket + sign-off owner, out-of-scope boundary, sacred data, stakeholder map with veto power, AI posture, the hypothesis, the top CRITICAL assumptions still OPEN, and any exception-path seeds heard (break → workaround → owner) for discover to map into `terrain.md`. Keep the summary short and link necessary detail; a complex engagement may need supporting evidence.
+
+If remote: agree how progress and blockers will be shared; use a short call when asynchronous context is insufficient.
+
+## Worked example
+
+Kickoff at Acme payments. Priya (VP Eng) sponsors; the brief says "add monitoring to the reconciliation service."
+
+Asking what happens the week after a perfect delivery gets: "I stop hearing about it from finance." That suggests a concern to clarify alongside the monitoring request. The previous attempt surfaces too: the platform team built alerting last year, it was turned off. Raj, who built it, is still there and was not in the kickoff. Ask for his account of the earlier attempt; his absence does not explain his views.
+
+In this example Priya reports a four-hour baseline and proposes the following target; her acceptance authority still needs its source. What gets written: `success.md` with proposed bucket `risk-mitigation`, `reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)`, gaming check `alerting on everything so nobody reads them` → guard `≤2 alerts/week, acked by name`, proposed sign-off Priya until confirmed. `brief.md` carries the gap list and the hypothesis: *the job is not unmonitored, it is unowned*. `assumptions.md` seeds `"finance would act on an alert" - CRITICAL - OPEN - (stated, unverified)`. `trust-profile.md` records the boundary Priya explicitly names, through the permitted privacy-safe workflow.
+
+Early deliverable: verify and fix the log line that swallows the job's exit code within the existing scope. Deployment remains subject to the established release authority and checks.
+
+## Principles
+
+- Establish the outcome and authority needed for the next action; missing record files do not block useful standalone work.
+- Sacred data tagged `<private>` stays out of model context: use CLI/redacted reads; never paste raw private blocks.
+- Treat unverified parts of the brief as hypotheses; discovery may support or overturn them. Record consequential assumptions.
+- Learn from the existing team and verify consequential claims without guessing motives.
+- If the customer cannot define success, that is the first problem to solve.

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "63cc6cef59cadd45b36a080ac97f1d0bc8e777b12f39a9a6f62b63dfb5029b2d",
     "agents/openai.yaml": "20f8c8f7ab4bc2730260052e378a86c062b503a3ba26fd4b7a37559756b0f756",
-    "references/build.md": "03c52eda90642c62053b53ef1e85c97b4e647600f454aee9da0e415c9d98903e",
+    "references/build.md": "4ebea9776605f79f902d9bf83a065e4cded191d7b5f8defcf58c054514fc34f5",
     "references/debug.md": "3273a921a98522431ae821a283814897270c719cbfab83d14b99175537d869e5",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "1cb7a60d7545b0bf224fce678a04ce6ccdf368c47877d9c8e4dc4272bb0d5b0c",

package/skills/integrate/references/build.md

@@ -20,7 +20,7 @@ Use existing services, fixtures, validation, and repository conventions before a
 
 ## Demonstrate the behavior
 
-Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
+Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Derive expected results from the agreed behavior or an independent fixture, not by repeating the implementation in the assertion; a passing test must be capable of detecting a wrong result. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
 
 Inspect the final diff against the agreed outcome. Update affected existing documentation and examples when public behavior, interfaces, configuration, or operating steps change. Exercise relevant commands or state what could not run. For substantial or risky work, use [review](review.md) with a separate reviewer when available; label a self-check honestly. Reverify affected behavior after repairs.
 

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

@@ -5,7 +5,7 @@
     "SKILL.md": "f72f8cf960aa85150f85e316bca0f306e3e57c140ed9f49ed9fa04dd0671662f",
     "agents/openai.yaml": "d5b07161e8fd27eae7af233da4b872719cf723696cbb30614909bcbf6550bbf3",
     "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
-    "references/build.md": "03c52eda90642c62053b53ef1e85c97b4e647600f454aee9da0e415c9d98903e",
+    "references/build.md": "4ebea9776605f79f902d9bf83a065e4cded191d7b5f8defcf58c054514fc34f5",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
     "references/debug.md": "3273a921a98522431ae821a283814897270c719cbfab83d14b99175537d869e5",
     "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",

package/skills/poc/references/build.md

@@ -20,7 +20,7 @@ Use existing services, fixtures, validation, and repository conventions before a
 
 ## Demonstrate the behavior
 
-Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
+Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Derive expected results from the agreed behavior or an independent fixture, not by repeating the implementation in the assertion; a passing test must be capable of detecting a wrong result. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
 
 Inspect the final diff against the agreed outcome. Update affected existing documentation and examples when public behavior, interfaces, configuration, or operating steps change. Exercise relevant commands or state what could not run. For substantial or risky work, use [review](review.md) with a separate reviewer when available; label a self-check honestly. Reverify affected behavior after repairs.
 

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "ee9d9ccd8b1ccb982e390530bc193d446a6fdb3a1d630276d6dcd00cf9033948",
     "agents/openai.yaml": "6c551dbdb5f0d27f908cc6de580a5f0a840dca1e01e1d3feaedd81bd349d8dc9",
-    "references/build.md": "03c52eda90642c62053b53ef1e85c97b4e647600f454aee9da0e415c9d98903e",
+    "references/build.md": "4ebea9776605f79f902d9bf83a065e4cded191d7b5f8defcf58c054514fc34f5",
     "references/debug.md": "3273a921a98522431ae821a283814897270c719cbfab83d14b99175537d869e5",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "1cb7a60d7545b0bf224fce678a04ce6ccdf368c47877d9c8e4dc4272bb0d5b0c",

package/skills/qa/references/build.md

@@ -20,7 +20,7 @@ Use existing services, fixtures, validation, and repository conventions before a
 
 ## Demonstrate the behavior
 
-Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
+Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Derive expected results from the agreed behavior or an independent fixture, not by repeating the implementation in the assertion; a passing test must be capable of detecting a wrong result. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
 
 Inspect the final diff against the agreed outcome. Update affected existing documentation and examples when public behavior, interfaces, configuration, or operating steps change. Exercise relevant commands or state what could not run. For substantial or risky work, use [review](review.md) with a separate reviewer when available; label a self-check honestly. Reverify affected behavior after repairs.
 

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "5a03a3842983d32da658da2e36466f64ad2474af2b189f71e596c586e91bc502",
     "agents/openai.yaml": "d928b571b9ebbb29ea8acd2e38769087288e2500f0ce9ab7f20f3f57a0e3d8d2",
-    "references/build.md": "03c52eda90642c62053b53ef1e85c97b4e647600f454aee9da0e415c9d98903e",
+    "references/build.md": "4ebea9776605f79f902d9bf83a065e4cded191d7b5f8defcf58c054514fc34f5",
     "references/debug.md": "3273a921a98522431ae821a283814897270c719cbfab83d14b99175537d869e5",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "1cb7a60d7545b0bf224fce678a04ce6ccdf368c47877d9c8e4dc4272bb0d5b0c",

package/skills/review/references/build.md

@@ -20,7 +20,7 @@ Use existing services, fixtures, validation, and repository conventions before a
 
 ## Demonstrate the behavior
 
-Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
+Add or update automated coverage when meaningful and feasible, including the relevant failure path. Check that existing tests actually exercise the change. Derive expected results from the agreed behavior or an independent fixture, not by repeating the implementation in the assertion; a passing test must be capable of detecting a wrong result. Explain manual-only coverage and its limits. Run focused checks, then required repository checks; use [QA](qa.md) for the affected journey when appropriate and [eval-pack](eval-pack.md) for uncertain model behavior. Record evidence and unrun checks with [verification](verification.md).
 
 Inspect the final diff against the agreed outcome. Update affected existing documentation and examples when public behavior, interfaces, configuration, or operating steps change. Exercise relevant commands or state what could not run. For substantial or risky work, use [review](review.md) with a separate reviewer when available; label a self-check honestly. Reverify affected behavior after repairs.
 

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

@@ -4,8 +4,9 @@
   "files": {
     "SKILL.md": "36843356c2e89e2a9205a4edf47afb8fd489d2f719c72241e3fdc3209829d2d8",
     "agents/openai.yaml": "53922bbe55ba23dc812c9bef311fbef238e2e25252100bdac7a8bd4f6c5e2780",
-    "references/close.md": "b3dbc1ecef12ee1c9d298e32a21d87ce61c9f6c88039d7a8b19970c6e3f21254",
-    "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
+    "references/close.md": "fa3579e02e2434273941ab158b5807bedaddefaa4b820a0f1cb29b1459c20f31",
+    "references/encode-pattern.md": "9740d97faa8491d168410916c9003ea9a651a1507da186dcb29ce6e58eba6773",
+    "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
     "references/runbook.md": "d32a40113941c603b97f09eabfd0e25afd25129102c6b07fa91a04fb4f8e93e7",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
     "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"

package/skills/runbook/references/close.md

@@ -6,31 +6,38 @@ For a standalone handoff draft, use the supplied notes and project evidence; no
 
 **Enter when:** the engagement is ending - the customer team must run this without the FDE.
 
-**Read first:** for standalone work, use the supplied permitted operating notes, evidence and ownership; no engagement binding or CLI command is required. For a bound engagement, use bounded `fde handoff` or `fde resume`, then targeted `fde recall` for missing evidence. Never initialize records merely to draft a handoff. Build the picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for code paths needed by the successor.
+**Read first:** for standalone work, use the supplied permitted operating notes, evidence and ownership; no engagement binding or CLI command is required. For a bound engagement, use bounded `fde handoff` or `fde resume`, then `fde recall <topic>` for relevant client patterns, earlier retrospectives, and missing evidence. Never initialize records merely to draft a handoff. Build the picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for code paths needed by the successor.
 
-The engagement doesn't end at ship. It ends when the customer can maintain what was built without calling.
+A handoff transfers the ability to operate the system, not just its files.
 
-## Method (you do this work, with the FDE's answers)
+## Match the requested output
 
-**0. The opening question:** "What will bite them when you're gone?" Their answer shapes everything written below.
+- **Draft a handoff:** return the operating summary, evidence and gaps from supplied context. Do not require a retrospective, initialized record or completed value measurement to produce a useful draft. Missing evidence limits readiness claims, not drafting. Follow steps 0, 3 and relevant operating details in 4, then check the draft as a lookup tool. Skip the closure-only steps and artifacts.
+- **Assess readiness or close the engagement:** apply the close gates below. Reuse existing evidence and agreed acceptance rather than restarting the engagement.
 
-**1. The retrospective.** Work through, blame-free and specific:
+Lead with what is being transferred, what the receiving team can demonstrably do, what is untested, and the next action with its owner or ownership gap. A document can be ready for review while operational handover remains incomplete.
+
+## Method
+
+**0. Find the operating gap.** Use supplied evidence to identify what still depends on the departing engineer. Ask “What will bite them when you’re gone?” only if the answer would change the handoff; do not repeat information already supplied.
+
+**1. Closure only: the retrospective.** Work through, blame-free and specific:
 - Did the real problem match the brief? (Compare `brief.md` vs `reality.md` - you have the receipts.)
 - Which trust moments mattered?
 - What did the codebase teach that `terrain.md` didn't know at the start?
 - Which risk almost became real?
 - AI components: did they behave in production? What failure modes did the prototype hide? Is the team equipped to maintain them?
 
-**1b. Value + receipts close gate (refuse green close if any fail):**
+**1b. Closure/readiness assessment only: value + receipts gate (refuse green close if any fail):**
 - Primary value bucket in `success.md` matches what the sponsor funded; at least one ledger row has **Measured** (not forever-`pending`) with evidence **and a named customer-side owner in Accepted by** for that bucket - or the retrospective explicitly records “not measured; sponsor accepted pending.” A measured-but-unaccepted number closes as `claimed`; say so in the retrospective rather than closing green on arithmetic nobody signed.
 - The receiving team has accepted the operating responsibilities with a source. Critical operating capabilities (such as access, failure triage, recovery and disabling an AI action) are recorded as verified, failed or untested under the receiving team's intended access. Reuse applicable accepted ownership and drill evidence; a lookup exercise or a run using only the departing FDE's credentials is insufficient. Unresolved critical gaps prevent green closure.
 - Audit receipt exists for the final shipped path (exceptions/operating map walked; cite file).
 - Eval receipt: **n/a if no AI**, else final scoped eval result + operating owner and required human-review or bounded-automation authority recorded; kill switch / fallback named in `handoff.md`.
 - One line in the retrospective: which bucket moved, by how much, vs baseline.
 
-**2. The pattern.** Anything that happened here and will happen again - a compliance approach, a migration pattern, a stakeholder dynamic - gets encoded for reuse. Use [encode-pattern](encode-pattern.md) to distinguish candidate patterns from supported ones and protect customer data.
+**2. Closure only: the pattern.** Anything that happened here and may happen again - a compliance approach, a migration pattern, a stakeholder dynamic - is a candidate for the client's `patterns.md`. Use [encode-pattern](encode-pattern.md) to record applicability, counterexamples, and evidence. Cross-client generalizations need explicit approval and a user-chosen export destination under the applicable policy; closing an engagement does not authorize an automatic scan or export.
 
-**3. The handoff.** Operational knowledge for the person woken at 2am, not technical documentation: the 3 things that will break and the fix for each · who holds the tribal knowledge · what each alert means · deploy and rollback in plain language. AI components additionally: model version, what normal output looks like (so drift is recognisable), fallback behaviour, who owns evaluation and corrective changes, and how to disable or contain the AI path using the supported fallback. Do not assume retraining is available or appropriate.
+**3. The handoff.** Operational knowledge for the person woken at 2am, not technical documentation: the relevant observed failures, their recovery steps and any untested procedure · who holds the tribal knowledge · what each alert means · deploy and rollback in plain language. AI components additionally: model version, what normal output looks like (so drift is recognisable), fallback behaviour, who owns evaluation and corrective changes, and how to disable or contain the AI path using the supported fallback. Do not assume retraining is available or appropriate.
 
 **4. Transformation engagements - four extra answers in `handoff.md`:**
 - Who owns AI governance after the FDE leaves? (Who can pull a model from production?)
@@ -40,7 +47,9 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Artifact
 
-**`retrospectives/YYYY-MM-DD-<engagement>.md`** - one file per close (separate files make cross-engagement patterns scannable). **`patterns.md`** - reusable patterns extracted. **`handoff.md`** - the 2am document.
+For a draft-only request, return the handoff in the requested format with evidence gaps and readiness status. Do not create retrospective or pattern artifacts. The following record destinations apply when closing a bound engagement under its write rules.
+
+**`retrospectives/YYYY-MM-DD-<engagement>.md`** - one file per close, retaining dated lessons for targeted recall within this client. **`patterns.md`** - client pattern candidates and evidence. **`handoff.md`** - the 2am document, including the deployed revision and the policy, access, and ownership evidence current at handoff. If the project reopens, use [land](land.md) to recheck these before dependent action; closure evidence remains historical.
 
 ## Checkpoint
 
@@ -48,7 +57,7 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 If the operator is unavailable, a fresh reviewer can attempt the same lookup using only the permitted draft and task. Report this as a simulated clarity check, not operator validation, customer approval, or a green close. Claim independent review only if a separate reviewer actually performed it; identify the reviewer and evidence available. If none is available, perform a labeled self-check and report independent review as unperformed. Use one focused pass for a consequential handoff; do not add a committee or a second approval ritual.
 
-Direct assessment to the FDE: did the engagement achieve `success.md` · 2-3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
+For closure or readiness assessment, report to the FDE: did the engagement achieve `success.md` · 2-3 lessons that matter · is the pattern worth encoding · is the handoff complete or where are the gaps. Also: value bucket + audit receipt green; eval **n/a or green**. Pending Measured without sponsor acceptance = gap, not green close. Honest - a gap named now is cheaper than a callback in six weeks.
 
 ## Worked example
 
@@ -58,7 +67,7 @@ Retrospective against the receipts: `brief.md` asked for monitoring, `reality.md
 
 The close gate bites in a useful way. The ledger shows detection at 12 minutes measured across two real incidents, but **Accepted by** is empty - Marco confirmed it in Slack, but Denise, the recorded acceptance owner, has not accepted the result. Her authority comes from the agreed acceptance record, not her finance title or the fact that she raised the original problem. So it closes as `claimed` with a one-line retrospective note and a named next step, rather than a green close on a number the agreed acceptance owner has not accepted.
 
-`handoff.md` is written for the person woken at 2am: the three things that break, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job - credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* - it has now happened twice.
+`handoff.md` is written for the person woken at 2am: the observed failure modes, what the page means, how to re-run manually the way Marco does, and who holds the tribal knowledge (Raj, who built the original job - credited, because he protects it now). `patterns.md` gets *"unowned job" presents as "unmonitored job"* - it has now happened twice.
 
 ## Principles
 

package/skills/runbook/references/encode-pattern.md

@@ -4,7 +4,7 @@
 
 **Enter when:** the engagement is closing and reusable patterns exist, a technique worked well and will apply to future clients, the FDE notices themselves doing the same thing on a second engagement, or close identified a pattern worth preserving.
 
-**Read first:** `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `context.md`. Patterns live in what was *done*, not what was planned.
+**Read first:** permitted evidence from `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `patterns.md`, and `context.md`. For a bound engagement, use `fde recall <topic>` to retrieve relevant client patterns and retrospective excerpts; do not load whole directories. Patterns live in what was *done*, not what was planned.
 
 The difference between a 5-year FDE and a 15-year FDE is not talent - it's encoded patterns. The 15-year FDE walks into a new engagement and recognises the situation in minutes because they've seen it before, named it, and know the move. Pattern extraction turns experience into reusable intelligence.
 
@@ -49,7 +49,7 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 | **Specific enough?** | Contains concrete steps, not just principles | "Build trust" / "Communicate well" - too vague to act on |
 | **Repeatable?** | Applies to a class of situations, not just this one | Only worked because of a unique circumstance |
 | **Falsifiable?** | You can tell when the pattern is working or not | No way to measure whether applying it helped |
-| **Monday bag?** | You would refuse the next similar embed without this in your bag - a named move plus an artifact you can drop on day one (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." Patterns that only live in this client's `.fde/` do not compound |
+| **Useful again?** | A named move plus an artifact you could use when the situation and policy permit (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." No concrete move or conditions for reuse |
 
 **4. Classify by stage.** Patterns sort into the same stages as the skills:
 
@@ -69,17 +69,15 @@ The difference between a 5-year FDE and a 15-year FDE is not talent - it's encod
 - After modification: increment minor version with what changed and why
 - After contradiction: note the counter-example, adjust the "watch out for" section
 
-**6. Cross-engagement pattern mining.** Only when explicitly authorized for the named engagements and permitted by each customer's data policy. Keep records separate; use sanitized CLI packets or targeted recall in each authorized context, never raw file comparisons. Otherwise extract a candidate from the current permitted context only.
+**6. Review before reuse.** Client patterns and retrospectives remain in that client's record. Recall relevant evidence with `fde recall <topic>` and check the situation trigger, applicability, counterexamples, and current policy before applying a move. Previous success is historical evidence, not present authority or proof of fit.
 
-- Compare permitted problem summaries - do the same problems recur?
-- Compare permitted decision summaries - are the same decisions being made?
-- Compare permitted lessons - are the same lessons being learned twice?
+Cross-client reuse requires an explicitly approved generalization exported to a user-chosen destination, permitted by the source customer's data policy. Review exactly what will leave the record before export. Do not automatically scan other clients, export patterns, or maintain a shared library. In the receiving engagement, use only the approved export and recheck applicability, counterexamples, and that customer's policy before reuse; do not pull the source client record into its context.
 
 A pattern learned twice is a process failure. Encoding it prevents the third time.
 
 ## Artifact
 
-**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A shared library is a separate, authorized export: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations.
+**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A cross-client export is separate and explicitly approved, to a user-chosen destination: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations with their limits and counterexamples.
 
 **`retrospectives/YYYY-MM-DD-<engagement>.md`** - reference to which patterns were extracted from this engagement.
 
@@ -93,4 +91,4 @@ Present the extracted patterns to the FDE: "From this engagement, I've identifie
 - Patterns are steps, not principles. "Build trust" isn't a pattern; "fix a small visible bug on day one" is.
 - Every pattern needs a situation trigger - the FDE must recognise when it applies.
 - Version substantive changes. State the evidence and limits; repeated use is not automatic confirmation.
-- The pattern library is the FDE's compound interest. It's what separates 5 years of experience from 1 year repeated 5 times.
+- Keep client evidence local to its record; share only explicitly approved generalizations.