fdeops 5.1.10 → 5.1.12

package/README.md

@@ -12,11 +12,13 @@ FDEOps brings that context into the work, from the first meeting to a system the
 
 [Get started](#quick-start) · [What it helps with](#three-things-it-helps-with) · [Choose a skill](#task-skills) · [Data boundaries](#your-records-your-control) · [Docs](docs/README.md)
 
-<img width="1000" height="586" alt="FDEOps engagement flow from customer discovery through delivery and handover" src="https://github.com/user-attachments/assets/12bbec6a-d0b3-4d03-81aa-4b842731a044" />
+![FDEOps terminal: insurance KYC workshop, build, healthcare client switch, tests and handover](media/chat-demo.gif)
+
+*Fictional customers. Illustrative enterprise conversation with real local review-logic tests. Synthetic data; no live model or customer deployment. [Read the conversation](media/chat-demo.md) · [View a still](media/chat-demo.png).*
 
 ## Quick start
 
-**Use customer-approved data and AI tools.** Your agent may send what it reads to its provider, even though the FDEOps CLI runs locally. If approval is unclear, use fictional data. [Safe setup](SECURITY.md#before-customer-work).
+**Use your customer’s approved AI tools and data.** FDEOps runs locally; your AI agent’s settings determine what reaches its provider. Start with synthetic data until customer access is approved. [Safe setup](SECURITY.md#before-customer-work).
 
 ### Let `fde` coordinate a customer project
 
@@ -34,7 +36,7 @@ checks internal documents, then assigns each request to another team.
 Help me prepare for the first meeting. Here is the brief: ...
 ```
 
-The coordinator uses the relevant instructions as the work changes. You do not need to choose a skill at each step. For an ongoing project, it keeps decisions, evidence and next actions in a local customer record.
+The coordinator selects the right skill as the work changes. For an ongoing project, it keeps decisions, evidence and next actions in a local customer record. You bring the context and make the decisions.
 
 ### Use one skill for one task
 
@@ -50,7 +52,7 @@ Separate decisions, requests and open questions. Return a draft only.
 [Paste notes you are permitted to share.]
 ```
 
-No customer record is needed for this draft. Each task includes its required instructions; you do not need to install `fde` or another pack.
+Each task skill includes the instructions it needs. Use `debrief` on supplied notes without creating a customer record or installing the coordinator.
 
 <details>
 <summary>Installation requirements and alternatives</summary>
@@ -59,7 +61,7 @@ These installation commands use Node.js and Git; the optional record CLI require
 
 </details>
 
-**Try it with fictional data:** `npx fdeops demo` runs sample notes through review and creates a fieldbook without calling an AI model. It requires Node.js 18+ and Git, may download the package, and creates or resets only its separate `.demo` workspace. [Five-minute walkthrough](docs/USAGE.md#new-here-5-minutes).
+**See it in action:** `npx fdeops demo` turns fictional meeting notes into a review and a fieldbook, a browser view of the customer record. No AI model is called. The demo uses Node.js 18+ and Git; `npx` may download the package. It creates or resets its separate `.demo` workspace. [Five-minute walkthrough](docs/USAGE.md#new-here-5-minutes).
 
 ## Three things it helps with
 
@@ -70,9 +72,9 @@ A repository tells you where the code lives. It may not tell you why the custome
 <a name="keep-a-customer-record"></a>
 <a name="how-skills-work"></a>
 
-For an ongoing engagement, FDEOps keeps a separate plain-Markdown record at `~/fde-engagements/<customer>/.fde/`. The coordinator retrieves a bounded summary and looks up details when needed. A saved implementation checkpoint points back to the current task record; the agent checks it before continuing.
+For ongoing engagements, each customer gets a plain-Markdown record at `~/fde-engagements/<customer>/.fde/`. The coordinator loads a short summary and looks up details as needed. Before resuming implementation, it checks the saved next action against the current task and code. Saved lessons are searchable within that customer’s record. Meeting preparation brings back recorded open questions and commitments; sharing a lesson with another customer requires explicit approval.
 
-For example, the fictional demo's `fde resume` output includes these next actions (excerpt):
+From the fictional demo’s `fde resume` output:
 
 ```text
 next: get the reconciliation runbook from Tom before touching anything. [source: meeting 2026-09-10]
@@ -87,13 +89,13 @@ Use [debrief](skills/debrief/SKILL.md) after a meeting and [switch-clients](skil
 
 A stakeholder asks for more scope. A demo looks promising. Neither establishes a new commitment or an accepted result.
 
-FDEOps separates requests, confirmed decisions, reported results and unresolved questions. You review proposed record changes before confirming them. Dates and sources make a claim traceable; they do not authenticate customer approval.
+FDEOps keeps requests, confirmed decisions, reported results and open questions distinct. You review proposed record changes before saving them. Dates and sources keep claims traceable; customer approval still comes from the agreed owner.
 
 For example, these fictional notes:
 
 > Mara agreed to keep CSV upload this phase. Devon asked for real-time sync; Mara has not answered. Two staging runs took 12 minutes. Production has not been measured.
 
-A review should keep those distinctions:
+The review separates them:
 
 | Record | What the notes support |
 |---|---|
@@ -116,9 +118,9 @@ A local test, a deployed change and a customer-accepted result answer different
 | Measured | A result was observed against the agreed measure |
 | Accepted | The agreed owner or mechanism accepted the outcome |
 
-These are separate claims, not five automatic dashboard states.
+The skills use these distinctions when reporting progress; they are not automatic dashboard states.
 
-FDEOps carries the agreed checks into implementation and binds verification to the relevant revision and environment. Release guidance asks for operating limits, recovery evidence and an owner. Missing access or evidence stays visible; a passing local test does not fill that gap.
+FDEOps carries agreed checks into implementation and ties test results to the revision and environment checked. Before rollout, it asks for operating limits, recovery evidence and an owner. You can see what is ready, what is blocked and what still needs verification.
 
 Use [build](skills/build/SKILL.md), [integrate](skills/integrate/SKILL.md), [review](skills/review/SKILL.md), [ship](skills/ship/SKILL.md) and [handoff](skills/handoff/SKILL.md) as needed. [See the tests and their limits](docs/verification.md).
 
@@ -136,7 +138,7 @@ Use [build](skills/build/SKILL.md), [integrate](skills/integrate/SKILL.md), [rev
 | A release or operating handover | `ship`, `runbook`, `handoff` |
 | Meeting notes or a customer update | `debrief`, `readout` |
 
-These are entry points, not a required sequence. Every task can be called directly or selected by `fde`. Some tasks need records to work with: `dashboard` displays saved records, while `debrief` can review supplied notes without saving them. [Full skill catalog](docs/skills-reference.md).
+Start with the task you need, or let `fde` select it. `dashboard` works with saved records; `debrief` can review supplied notes and return a draft. Each skill explains the context it needs. [Full skill catalog](docs/skills-reference.md).
 
 <a name="what-a-working-day-looks-like"></a>
 
@@ -162,13 +164,13 @@ Copy an action into your agent to continue. Regenerate the view after record upd
 
 The CLI reads local files and Git without network calls or telemetry. Installation may download packages. Your AI host controls model connections and may transmit what it reads.
 
-CLI and hook outputs mask common identifier patterns. `<private>` blocks are redacted from those outputs and the dashboard. Local reports retain unmarked identifiers by default. Masking is partial; raw file reads and pasted text bypass it. Anonymisation does not grant permission to use customer material.
+CLI and hook outputs mask common identifier patterns. `<private>` blocks are redacted from those outputs and the dashboard. Local reports retain unmarked identifiers by default. These filters cover FDEOps output, not raw files or text you paste into an agent. Use only approved material, including when anonymised.
 
 You review consequential record updates. Enabled hooks can save mechanical session progress; direct CLI write commands update records when run. [Privacy](PRIVACY.md) · [Security](SECURITY.md) · [Local-model results](docs/verification.md#local-model-results).
 
 ## Who this is for
 
-Forward deployed engineers, consultants and delivery teams working across customer meetings, codebases and operating environments. Start with one task or coordinate an ongoing engagement. The skills use your existing tools and processes; they do not provide infrastructure, access rights or customer approval.
+Forward deployed engineers, consultants and delivery teams working across customer meetings, codebases and operating environments. Bring your existing tools, access and customer agreements. Start with one task or use `fde` throughout the engagement.
 
 ## Go deeper
 

package/bin/check.js

@@ -194,11 +194,11 @@ if (read('package.json').includes('postinstall')) {
 }
 
 const readme = read('README.md')
-if (/session\.gif|demo\.gif/i.test(readme)) {
-  fail('README must not embed session.gif or demo.gif - the recording lives in docs/USAGE.md')
-} else if (/<img /i.test(readme) && !/user-attachments\/assets/.test(readme)) {
-  fail('README <img> must be the GitHub poster (user-attachments), not a local gif')
-} else ok('README is text (no gif)')
+if (!readme.includes('media/chat-demo.gif') || !readme.includes('media/chat-demo.md') || !readme.includes('Fictional customers')) {
+  fail('README must include the chat walkthrough, text alternative and fictional-record disclosure')
+} else if (['chat-demo.gif', 'chat-demo.png', 'chat-demo.json', 'chat-demo.md', 'render-chat-demo.py'].some(name => !fs.existsSync(path.join(root, 'media', name)))) {
+  fail('chat walkthrough must include rendered assets, text, source and renderer')
+} else ok('README chat walkthrough has accessible text and reproducible source')
 
 const usage = read('docs/USAGE.md')
 if (!usage.includes('media/session.gif') || !usage.includes('media/record-session.sh')) {

package/bin/fde.js

@@ -33,6 +33,7 @@ const path = require('path')
 const os = require('os')
 const { execSync, execFileSync } = require('child_process')
 const { createMemoryApi } = require('./lib/memory')
+const { pendingSummary } = require('./lib/follow-through')
 const { createTrustApi } = require('./lib/trust')
 const vault = require('./lib/vault')
 const context = require('./lib/context')
@@ -1462,7 +1463,7 @@ function cmdResume(args) {
     console.log(`NO ENGAGEMENT for this workspace.\nexisting: ${list}\nAsk the human the client name (one question), then run: fde resume --init <client-name>\nDo not tell them to type that command.`)
     process.exit(2)
   }
-  const intro = [resumeTriage(eng), firstActionLine(eng), ...hygieneTriageLines(eng), ...recordDigest(eng)].join('\n')
+  const intro = [resumeTriage(eng), firstActionLine(eng), pendingSummary(readClean(eng, 'context.md')), ...hygieneTriageLines(eng), ...recordDigest(eng)].join('\n')
   const ctx = readClean(eng, 'context.md')
   const savedWork = context.implementationCheckpoint(ctx)
   const checkpoint = stripTemplateNoise(savedWork.checkpoint).trim()
@@ -2710,11 +2711,25 @@ function cmdRecall(args) {
   }
   const eng = resolveEngagement()
   if (!eng) { console.error('no engagement - bind a client before recall'); process.exit(2) }
-  const files = ['context.md', 'trust-profile.md', 'success.md', 'decisions.md', 'risks.md', 'delivery.md', 'stakeholders.md', 'brief.md', 'reality.md', 'assumptions.md', 'terrain.md', 'handoff.md']
+  const files = ['context.md', 'trust-profile.md', 'success.md', 'decisions.md', 'risks.md', 'delivery.md', 'stakeholders.md', 'brief.md', 'reality.md', 'assumptions.md', 'terrain.md', 'handoff.md', 'patterns.md']
+  // Never follow a directory link into another customer's record.
+  const retrospectiveDir = path.join(eng, 'retrospectives')
+  let omitted = false
+  try {
+    if (fs.lstatSync(retrospectiveDir).isDirectory()) {
+      const names = fs.readdirSync(retrospectiveDir).filter(name => {
+        if (!/^\d{4}-\d{2}-\d{2}-.+\.md$/.test(name)) return false
+        try { return fs.lstatSync(path.join(retrospectiveDir, name)).isFile() } catch (_) { return false }
+      }).sort().reverse()
+      omitted = names.length > 100
+      files.push(...names.slice(0, 100).map(name => `retrospectives/${name}`))
+    }
+  } catch (_) {}
   const result = context.recallSections(files.map(file => ({ file, text: readClean(eng, file) })), query, 12, masking.mask)
   process.stdout.write(maskedSections([
     `RECALL - ${eng}\n${result.total ? `${result.sections.length} of ${result.total} matching lines; refine the query if evidence is omitted.` : 'No matching record. This is not proof that the event never happened.'}\nSources are local record assertions; verify dates, supersession and approval scope.`,
     ...result.sections,
+    omitted ? 'Older retrospectives omitted: searched at most the 100 newest dated files.' : '',
   ], maxBytes))
 }
 
@@ -3497,6 +3512,8 @@ function cmdPrep(args) {
   // Grounded brief: only text already in .fde/. No invention (Rowboat meeting-prep rule).
   console.log(`MEETING PREP - ${label}`)
   console.log('(grounded in local .fde/ only - if a fact is missing, it is missing)\n')
+  const pending = pendingSummary(readClean(eng, 'context.md'))
+  if (pending) console.log(masking.mask(pending) + '\n')
   console.log(resumeTriage(eng))
   const owner = readOwner(eng)
   const head = memoryHead(eng)

package/bin/lib/follow-through.js

@@ -0,0 +1,41 @@
+'use strict'
+
+// Explicit checkboxes keep closure human-owned; prose is not inferred as a debt.
+function localDay(now = new Date()) {
+  return [now.getFullYear(), String(now.getMonth() + 1).padStart(2, '0'), String(now.getDate()).padStart(2, '0')].join('-')
+}
+
+function pendingItems(text, today = localDay()) {
+  const items = []
+  let section = ''
+  let fence = ''
+  for (const [index, line] of String(text || '').split('\n').entries()) {
+    if (fence) {
+      if (new RegExp(`^[\\t ]*${fence.char}{${fence.length},}[\\t ]*$`).test(line)) fence = null
+      continue
+    }
+    const opening = line.match(/^ {0,3}(?:(?:[-+*]|\d{1,9}[.)])[\t ]+)?(`{3,}|~{3,})(.*)$/)
+    if (opening && (opening[1][0] !== '`' || !opening[2].includes('`'))) {
+      fence = { char: opening[1][0], length: opening[1].length }
+      continue
+    }
+    const heading = line.match(/^(#{1,2})(?:[\t ]+|$)(.*)$/)
+    if (heading) section = heading[1] === '##' ? heading[2].replace(/[\t ]+#+[\t ]*$/, '').trim().toLowerCase() : ''
+    if (!['commitments', 'open questions'].includes(section)) continue
+    const match = line.match(/^ {0,3}-\s+\[ \]\s+(.+)/)
+    if (!match) continue
+    const due = match[1].match(/\b(?:due|review):\s*(\d{4}-\d{2}-\d{2})\b/i)
+    const date = due && due[1]
+    const valid = date && !Number.isNaN(Date.parse(date)) && new Date(date).toISOString().slice(0, 10) === date
+    items.push(`context.md:${index + 1} [${section}] ${match[1].slice(0, 400)}${valid && date < today ? ' [past recorded due/review date; confirm status]' : ''}`)
+  }
+  return items
+}
+
+function pendingSummary(text) {
+  const items = pendingItems(text)
+  if (!items.length) return ''
+  return `OPEN FOLLOW-THROUGH (${Math.min(items.length, 8)} of ${items.length} recorded items)\n${items.slice(0, 8).join('\n')}\nRecorded items, not a complete agenda. Confirm status and meeting relevance.`
+}
+
+module.exports = { pendingItems, pendingSummary, localDay }

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.10",
+  "version": "5.1.12",
   "private": true,
   "description": "Thin stdio MCP sink for FDEOps ingest (stage \u2192 propose \u2192 apply). Zero runtime dependencies.",
   "bin": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops",
-  "version": "5.1.10",
+  "version": "5.1.12",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "bin": {
     "fdeops": "bin/install.js",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "fdeops",
-  "version": "5.1.10",
+  "version": "5.1.12",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "author": {
     "name": "Subash Natarajan",

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "5d88b9818951f8a8a44c39ad2b36ccdca74fef5e6ed31e67788b50d3ca1bb006",
     "agents/openai.yaml": "8dc0b43545004419bad49e1d50cd3beb968bbcc24baacdaf7fb7304a5fd03bba",
-    "references/land.md": "7a82ac999d23b51b602cd815777a853c4879ca8be40dc6c84c66f154d1f77951",
+    "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/brief/references/land.md

@@ -1,6 +1,6 @@
 # land - Interrogate the brief
 
-**Enter when:** new customer, first meeting, just got the brief, nothing started yet.
+**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.
 
@@ -18,6 +18,8 @@ Then check - probe ONLY if it prevents a bad start:
 
 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.

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

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

package/skills/build/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/debug/.fde-generated.json

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

package/skills/debug/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/evaluate/.fde-generated.json

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

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

@@ -27,8 +27,8 @@ For record-backed work only:
 
 1. Before client reads, run `fde setup --show` and verify `fde privacy` support. If setup is unconfigured or the user requests preferences, follow `references/record-setup.md`. Setup does not authorize sharing customer data.
 2. Use a fresh `fde resume` packet for this turn/task. Reuse a current session-hook packet only when its visible `ENGAGEMENT:` matches the binding and its freshness is certain. Refresh after binding, masking or record changes, or when the user asks where things stand. Do not reuse an earlier turn's packet or repeat the same entry solely because another method loaded.
-3. Read policy, signer, goals, risks and current work. Retrieve omitted or disputed evidence with `fde recall <topic>`; never replace this with raw or recursive record reads. Resume defaults to 16 KiB (4 KiB in compact setup); `--max-bytes 4096` reduces it, and `--full` is for explicitly needed complete context.
-4. For interrupted implementation, inspect the saved checkpoint and follow `references/verification.md#recoverable-checkpoint` before acting. A checkpoint is a dated claim, not a fresh test or permission to execute.
+3. Read policy, signer, goals, risks and current work. Retrieve omitted or disputed evidence, saved lessons and dated retrospectives with `fde recall <topic>`; never replace this with raw or recursive record reads. Resume defaults to 16 KiB (4 KiB in compact setup); `--max-bytes 4096` reduces it, and `--full` is for explicitly needed complete context.
+4. For interrupted implementation, inspect the saved checkpoint and follow `references/verification.md#recoverable-checkpoint` before acting. A checkpoint is a dated claim, not a fresh test or permission to execute. For a returning or closed engagement, apply the reopening check in `references/land.md` before relying on historical access, owners or deployment evidence.
 5. Give a brief playback and load the relevant method below. `hygiene:` means offer `fde doctor`; never auto-rewrite.
 
 The CLI uses local files and Git, without network calls. Install it on the FDE's own machine, never customer infrastructure. The AI host's permissions and provider policy remain separate.
@@ -173,3 +173,7 @@ Ready to build: check that the supplied facts establish the outcome, constraints
 - A missing record or check is an explicit gap, not a reason to fabricate facts or restart discovery.
 - Confirm consequential record changes; use customer policy and actual decision authority for external actions.
 - Report what was achieved, its evidence and remaining limits. Never equate implementation with deployment or acceptance.
+
+### Keep open work visible
+
+For confirmed follow-ups, maintain `## Commitments` and `## Open questions` in the existing `context.md`. Use unchecked bullets for unresolved items and check them only after confirmed resolution. A commitment says who owes what to whom; include a source and `due: YYYY-MM-DD` or `review: YYYY-MM-DD` only when agreed. Preserve unresolved `unknown - ask:` questions here when they affect the next decision. Do not infer a promise from a suggestion. `resume` and `prep` surface these entries with sources; dates prompt a status check, not an invented escalation. For a meeting, select relevant entries and use targeted recall for supporting evidence. Users describe the follow-up naturally; maintain the record for them.

package/skills/fde/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/fde/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/fde/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/fde/references/hold-scope.md

@@ -4,7 +4,7 @@
 
 **Enter when:** "also can you…" mid-build, a stakeholder adds requirements without adjusting timeline, the FDE feels scope creeping but can't name it, or `success.md` no longer matches what's being asked.
 
-**Read first:** `success.md` (the agreed boundary), `decisions.md`, `context.md`. Load `stakeholders.md` to know who's asking and their signal.
+**Read first:** the supplied agreement, acceptance checks and request. In a bound engagement, retrieve the relevant `success.md`, `decisions.md`, `context.md` and decision authority. Missing records do not block a standalone recommendation; identify which boundary or authority remains unconfirmed.
 
 Small requests can accumulate into material changes to cost, timing or acceptance. Compare the request with the actual agreement before classifying it; an adjacent request may already be in scope, and a clarification is not automatically an addition.
 
@@ -66,13 +66,17 @@ Check cumulative impact against the agreed scope and remaining capacity. Recomme
 
 ## Worked example
 
-Acme, week 5. Nothing has been formally added, and the slice is a week late.
+Fictional example: the agreed slice sends missing-document reminders. Sales asks to reject a case automatically after 48 hours, calling it a small rule. Compliance owns acceptance of review controls; no automated rejection has been approved.
 
-The pattern shows in three requests: a "quick" finance CSV export (Jun 20, half a day, from Denise directly), retry-logic cleanup asked for mid-build (Jun 24, one day, Tom), and a dashboard tile "while you're in there" (Jun 27, half a day). Each sounds reasonable; their cumulative estimates explain part of the slip and need a scope decision.
+The code may be small, but the request changes who decides the case outcome. Recommend keeping reminders in the current slice and treating automatic rejection as a separate proposed decision. Do not imply that sales enthusiasm supplies authority or that a future phase is promised. If saved in a bound engagement, the `decisions.md` receipt remains proposed; `success.md` stays unchanged until the appropriate owner agrees.
 
-Three-bucket response, applied while the requests can still be placed: the CSV export fits this phase only with an accepted trade (it displaces the runbook polish), the retry cleanup goes to the kill list in `decisions.md` with the what-breaks reason, and the tile is absorbed because it is genuinely twenty minutes - included in the existing progress receipt so cumulative impact remains visible.
+Reply draft: “The reminder slice stays as agreed. Automatic rejection changes the decision policy, so I would not include it under the current approval. We can assess it with the policy owner, including the exception path and impact on delivery.”
 
-That conversation happens with Priya when the added work threatens the date, with the receipts on screen: "here are the asks, their estimated impact, and what moved." Confirm Priya holds the relevant scope authority before treating her response as agreement.
+For a lower-impact request, reach the same decision from its actual fit, risk and authority, not from how few minutes it takes.
+
+## Return
+
+Give the scope fit, evidence or missing agreement, material impact, recommended disposition, and the decision needed from whom. Include a short customer-facing reply when useful. In standalone mode, return the assessment directly; do not create records or imply that the recommendation was accepted.
 
 ## Principles
 

package/skills/fde/references/land.md

@@ -1,6 +1,6 @@
 # land - Interrogate the brief
 
-**Enter when:** new customer, first meeting, just got the brief, nothing started yet.
+**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.
 
@@ -18,6 +18,8 @@ Then check - probe ONLY if it prevents a bad start:
 
 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.

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "7d49a9e89736e35c2aaf10c78b10be365bdf91af1aaf99430de6069e96069d55",
     "agents/openai.yaml": "6b8d024e9ea9676a2607b76a6f1fcd2fbcba585af2990b1172dbdb8cec0364c6",
-    "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
+    "references/encode-pattern.md": "9740d97faa8491d168410916c9003ea9a651a1507da186dcb29ce6e58eba6773",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }