fdeops 5.1.11 → 5.1.13

package/bin/fde.js

@@ -2611,17 +2611,24 @@ function cmdReceipts(args) {
     const scaffold = new Set((templatesDir() ? readClean(templatesDir(), file) : '').split('\n').map(line => line.trim()))
     const decisionSources = new Map()
     if (file === 'decisions.md') for (const entry of datedDecisions(document)) {
-      for (let line = entry.line; line < entry.line + entry.text.split('\n').length; line++) decisionSources.set(line, entry.text)
+      for (let line = entry.line; line < entry.line + entry.text.split('\n').length; line++) decisionSources.set(line, entry)
     }
+    const seenEntries = new Set()
     document.split('\n').forEach((line, i) => {
       if (!line.toLowerCase().includes(term.toLowerCase())) return
-      const sourceText = decisionSources.get(i + 1) || line
+      const entry = decisionSources.get(i + 1)
+      if (entry && seenEntries.has(entry.line)) return
+      if (entry) seenEntries.add(entry.line)
+      const sourceText = entry ? entry.text : line
       const source = sourceReference(sourceText)
       if (!source && scaffold.has(line.trim())) return
       const sources = sourceReferences(sourceText)
       const attribution = masking.mask(sources.join('; '))
       const displayed = Buffer.byteLength(attribution) <= 320 ? attribution : context.clipMaskedUtf8(attribution, 240) + '… [sources truncated; use fde recall]'
-      const hit = `  ${file}:${i + 1}  ${context.clipMaskedUtf8(masking.mask(line.trim()), 160)}${source ? ` [${sources.length > 1 ? 'sources' : 'source'}: ${displayed}]` : ' [source missing]'}${dirty.has(file) ? '  dirty file - review manual edits' : ''}`
+      const excerpt = masking.mask(entry ? entry.text : line.trim())
+      const excerptLimit = entry ? 1400 : 160
+      const body = context.clipMaskedUtf8(excerpt, excerptLimit) + (Buffer.byteLength(excerpt) > excerptLimit ? ' [excerpt truncated; use fde recall]' : '')
+      const hit = `  ${file}:${entry ? entry.line : i + 1}  ${body}${source ? ` [${sources.length > 1 ? 'sources' : 'source'}: ${displayed}]` : ' [source missing]'}${dirty.has(file) ? '  dirty file - review manual edits' : ''}`
       ;(recordFiles.includes(file) && source ? records : claims).push({ file, hit })
     })
   }
@@ -2643,8 +2650,9 @@ function cmdReceipts(args) {
     }
     return `Selected ${selected.length} of ${hits.length} matching lines; omitted matches require a narrower search.\n` + selected.join('\n')
   }
-  const sections = ['RECEIPTS: a cited record is not proof of customer approval. File line numbers refer to the redacted view. Latest and earliest matching lines are sampled; file order is not authority. Check conflicting records.']
-  if (records.length) sections.push('ON RECORD (dated, source-backed):\n' + select(records))
+  const sections = ['RECEIPTS (dated evidence): a cited record is not proof of customer approval. File line numbers refer to the redacted view. Latest and earliest matching lines are sampled; file order is not authority. Check conflicting records.']
+  if (records.length) sections.push('ON RECORD (source-backed; check stated dates and status):\n' + select(records))
+  if (!records.length && claims.length) sections.push('No source-backed record matched. The notes below do not establish agreement; verify with the relevant decision owner when known.')
   if (claims.length) sections.push('CLAIMS & working notes (verify source and approval before citing):\n' + select(claims))
   if (!records.length && !claims.length) sections.push(`no record of "${term}" - a gap in the record, not proof of absence`)
   process.stdout.write(maskedSections(sections))

package/bin/lib/provenance.js

@@ -29,11 +29,12 @@ function datedDecisions(value) {
   for (let i = 0; i < lines.length; i++) {
     const bullet = lines[i].match(/^\s*[-*]\s*\[(\d{4}-\d{2}-\d{2})\]\s*(.+)/)
     const heading = lines[i].match(/^(#{2,3})\s+\[?(\d{4}-\d{2}-\d{2})(?:\]|\s+-)?\s+(.+)/)
+    const named = lines[i].match(/^(#{2,3})\s+((?:Decision:\s*.+|Scope change))\s+-\s+(\d{4}-\d{2}-\d{2})\s*$/i)
     if (bullet) entries.push({ date: bullet[1], text: lines[i].trim(), line: i + 1 })
-    else if (heading) {
+    else if (heading || named) {
       let end = i + 1
       while (end < lines.length && !/^#{1,3}\s/.test(lines[end]) && !/^\s*[-*]\s*\[\d{4}-\d{2}-\d{2}\]/.test(lines[end])) end++
-      entries.push({ date: heading[2], text: lines.slice(i, end).join('\n').trim(), line: i + 1 })
+      entries.push({ date: heading ? heading[2] : named[3], text: lines.slice(i, end).join('\n').trim(), line: i + 1 })
       i = end - 1
     }
   }

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.11",
+  "version": "5.1.13",
   "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.11",
+  "version": "5.1.13",
   "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.11",
+  "version": "5.1.13",
   "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/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

@@ -50,7 +50,7 @@ Scale this to the work: routine fixes reuse agreed scope, signer and acceptance
 | day-1 look at the repo | `fde scan` |
 | debrief / pasted notes for a bound record | `fde debrief --smart` → agent reconciliation → one plain-English review → Save this update? → `--apply`. `--smart` is a gate, not a brain. `references/debrief.md` |
 | prep me for … | `fde prep "<label>"` |
-| when did we agree | `fde receipts <term>` |
+| did we agree / who decided / why did we | `fde receipts <term>` |
 | sponsor update / defend the number | `fde defend` |
 | successor / rotation / portable handoff | `fde handoff` (stdout; `--out new-file.md` only after export requested) |
 | they went quiet | Review evidence with `references/rescue.md`; confirm a signal change before `fde log contact "…" --signal amber\|green\|red` |
@@ -151,7 +151,7 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 | Engagement ending, team needs to operate without you, write the runbook | runbook | `references/runbook.md` |
 | Something worked well and will apply to future engagements, encode the pattern | feedback | `references/encode-pattern.md` |
 | "Red-team this," "stress-test my plan," poke holes, challenge the plan, what am I missing | red-team | `references/red-team.md` |
-| "What did we agree about X?", scope dispute, receipts | - | run `fde receipts <term>`, answer with dates |
+| "Did we agree to X?", "Who decided?", "Why did we choose X?", scope dispute | - | run `fde receipts <term>`; return the decision, person, date, source and later changes; use targeted recall for missing context |
 
 **Overlays - activate alongside any skill on signal, don't wait to be told:**
 
@@ -177,3 +177,9 @@ Ready to build: check that the supplied facts establish the outcome, constraints
 ### 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.
+
+### Answer from the record
+
+A receipt is dated evidence for a claim, not automatic customer approval. For agreement questions, distinguish proposed work, an agreed decision, a later withdrawal and acceptance of a delivered result. Attribute the decision and rationale only when recorded; the person who wrote a note is not necessarily the decision-maker. If the search finds no agreement evidence, say “I found no recorded agreement in the material checked,” show relevant claims as claims, and name who can clarify only when their authority is known. Do not invent a rationale or treat absence as “never agreed.”
+
+For meeting preparation, use `fde prep` as the starting packet, then select unresolved questions and commitments relevant to the meeting's purpose and participants. Include the recorded owner, due/review date and source where available; mark missing fields unknown. Retrieve supporting or conflicting context with targeted recall. Do not turn every old unknown into an agenda item, infer an overdue date, or hide a material blocker merely because its wording does not match the meeting label.

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

@@ -8,29 +8,36 @@ For a standalone handoff draft, use the supplied notes and project evidence; no
 
 **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 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.
+**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,6 +47,8 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Artifact
 
+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/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/handoff/.fde-generated.json

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "c4ac99ee1517c0674e5324b289521116c58a9e0ac3de22c229be8da83438f4db",
     "agents/openai.yaml": "93ac049cf1a9d0fdfdf67d34ca6d3dd33800e91334f38bb303828eab8c4b3aaf",
-    "references/close.md": "55fa64212f20bb828e3d9550dd771258945deb42b2d2c01f2bdb523c835f9034",
+    "references/close.md": "fa3579e02e2434273941ab158b5807bedaddefaa4b820a0f1cb29b1459c20f31",
     "references/encode-pattern.md": "9740d97faa8491d168410916c9003ea9a651a1507da186dcb29ce6e58eba6773",
     "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"

package/skills/handoff/references/close.md

@@ -8,29 +8,36 @@ For a standalone handoff draft, use the supplied notes and project evidence; no
 
 **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 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.
+**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,6 +47,8 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Artifact
 
+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/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,7 +4,7 @@
   "files": {
     "SKILL.md": "36843356c2e89e2a9205a4edf47afb8fd489d2f719c72241e3fdc3209829d2d8",
     "agents/openai.yaml": "53922bbe55ba23dc812c9bef311fbef238e2e25252100bdac7a8bd4f6c5e2780",
-    "references/close.md": "55fa64212f20bb828e3d9550dd771258945deb42b2d2c01f2bdb523c835f9034",
+    "references/close.md": "fa3579e02e2434273941ab158b5807bedaddefaa4b820a0f1cb29b1459c20f31",
     "references/encode-pattern.md": "9740d97faa8491d168410916c9003ea9a651a1507da186dcb29ce6e58eba6773",
     "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
     "references/runbook.md": "d32a40113941c603b97f09eabfd0e25afd25129102c6b07fa91a04fb4f8e93e7",

package/skills/runbook/references/close.md

@@ -8,29 +8,36 @@ For a standalone handoff draft, use the supplied notes and project evidence; no
 
 **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 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.
+**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,6 +47,8 @@ The engagement doesn't end at ship. It ends when the customer can maintain what
 
 ## Artifact
 
+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/scope/.fde-generated.json

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "544424180d2e924e21e98e94c1d6a35c067176ff9876f6c11415638e041f89f5",
     "agents/openai.yaml": "22b669e628e4401c6b042d17fca25f0259593d90a581e232816c140e788306ec",
-    "references/hold-scope.md": "7779188df1d7f5aef9f878719499f9c0e974deba45289329ae8fa3d62e6c5090",
+    "references/hold-scope.md": "651ba25570401ceda8dc518d1037f1644ee09a0166609b93d437164e4dc45837",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/scope/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/ship/.fde-generated.json

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

package/skills/ship/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.