fdeops 5.1.5 → 5.1.7

package/skills/integrate/references/ship.md

@@ -8,7 +8,7 @@ Start from [task context](task-context.md). Standalone work uses supplied permit
 
 Identify the exact outcome, acceptance check, scope, affected users/systems, target environment, recovery mechanism, and who or what is authorized to accept and release it. Reuse confirmed authority and checks for routine work. Do not invent missing signers, permissions, measurements, or acceptance.
 
-For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing binary success or a named customer-side signer blocks that planning progression until resolved. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
+For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing acceptance criteria or a named customer-side signer blocks the affected implementation or release commitment, not a provisional plan or independent preparation. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
 
 A customer delivery checkpoint must let the agreed decision-maker replay and reject the acceptance check through an interface they operate. Prefer their staging; otherwise use an agreed representative environment and disclose its owner and limitations. Local green proves only the local run. Routine fixes may share an agreed checkpoint; no fixed number of changes forces a ceremony.
 
@@ -30,7 +30,7 @@ Before deployment, establish these facts from existing evidence or a necessary c
 | Acceptance | Replayable check and agreed decision-maker/mechanism; record actual acceptance separately from readiness |
 | Data and policy | Permitted data, applicable security/residency/change-window requirements, necessary approvals already recorded or obtained |
 | Recovery | Applicable tested rollback, restore, compensation, or roll-forward within agreed recovery-time/data-loss limits; explicit authority for irreversible effects |
-| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage |
+| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage; applicable [failure-signal delivery evidence](verification.md#operator-response) for paths whose readiness depends on operator response |
 | AI, when applicable | Current applicable SHIP eval evidence, critical failures zero, enforced action boundary and required human review or documented bounded automation |
 
 Check migration compatibility, old/new version coexistence, delayed jobs, caches, and already-emitted side effects where relevant. A code revert does not undo data loss or external writes. Reuse drill evidence only when the mechanism and relevant conditions are unchanged, explaining applicability. If recovery is only a plan, exercise it in a permitted representative environment before release.
@@ -43,7 +43,7 @@ For a coordinated engagement, also connect the release to the agreed value bucke
 
 Execute only when the requested workflow authorizes deployment to this target and the applicable gates are met. Otherwise leave a concrete release candidate, exact deployment/recovery instructions, evidence, and the remaining authorization for review. A permission to implement or test is not permission to publish.
 
-Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
+Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. Capture an applicable pre-rollout operating baseline with its source, environment, load/cohort and window when assessing change. Compare like conditions; keep absolute safety limits even when the baseline is poor. If no comparable baseline exists, name the gap and measurement plan: improvement is unproven, while release depends on the agreed acceptance and safety evidence, not an invented universal baseline gate. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
 
 During rollout inspect health, errors, key user behavior, and side-effect integrity. Halt expansion on breached thresholds or critical harm and apply authorized containment/recovery. Do not continue merely because the deploy command exited successfully.
 
@@ -57,7 +57,7 @@ Before wider exposure, verify expected load/cost, data pipeline behavior, owners
 
 Keep these claims separate: implemented, verified, deployed, measured outcome, and accepted. Include the candidate, target, command/pipeline, applicable checks and unrun checks, review source, evaluation where needed, authority source, recovery evidence, observation, and next owner/action. Attribute acceptance to its actual source and scope. A staging measurement is not production value, and a commit is not deployment.
 
-In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
+In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. If substantial work remains, retain a [recoverable checkpoint](verification.md#recoverable-checkpoint) there. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
 
 ## Worked example
 

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

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

package/skills/integrate/references/verification.md

@@ -6,9 +6,9 @@ Use [task context](task-context.md). This method returns evidence directly or wr
 
 ## Method
 
-1. Translate each claim into the observation that would support or reject it. Reuse agreed acceptance criteria and required repository checks. Select focused checks for changed behavior before broadening to release requirements.
+1. Translate each claim into the observation that would support or reject it. Cite the agreed acceptance criteria and required repository checks. Compare the checks being run with that agreement; flag any weakened threshold or removed requirement without an attributed approval from the appropriate decision-maker. Select focused checks for changed behavior before broadening to release requirements.
 2. Identify the actual repository commands, fixtures, runtime, and environment. Read command behavior before executing it, especially when it can write externally. Use authorized environments and avoid leaking secrets through logs or diagnostic commands.
-3. Run the checks and inspect results, including exit status and relevant output. A running job, test discovery, a mocked response, and a successful real request are different evidence. Record asynchronous completion before claiming success.
+3. Run the checks and inspect results, including exit status and relevant output. A running job, test discovery, a mocked response, and a successful real request are different evidence. Record asynchronous completion before claiming success. Describe a command as executed only when its actual invocation and result are available; an inferred result is not a run.
 4. Bind evidence to the tested revision and working tree. For uncommitted changes record the base revision plus changed paths and an available diff digest or snapshot identifier. For browser/manual checks record the steps, inputs, observed result, and inspected evidence.
 5. After a change, rerun checks whose behavior or assumptions were affected. Reuse prior evidence only when the relevant code, dependencies, data, and environment remain applicable; cite the original run and reason. Never imply reused evidence was rerun.
 6. Label every required check **passed**, **failed**, **blocked**, or **not run**. Include why blocked/not run, impact, and next step. Missing evidence is unproven; it is not an observed failure or a pass.
@@ -28,6 +28,18 @@ Use one compact entry per check or a table with these fields:
 
 Keep implementation, verification, deployment, measured outcome, and customer acceptance distinct. A local pass supports the tested local behavior. An acceptance claim needs an attributed source from the agreed decision-maker or agreed acceptance mechanism. Record no raw `<private>` blocks, credentials, or hidden reasoning.
 
+## Operator response
+
+When readiness depends on a failure signal, verify that a representative failure reaches the responsible operator through the intended route in an approved environment. Record separately whether the route is configured, the signal was delivered, and the operator acknowledged it; configuration alone proves neither delivery nor response. Use an authorized test route or an already approved drill, and identify any difference from the intended operating route. Do not page people or trigger production incidents without authorization. Reuse applicable evidence with attribution; a draft guide can mark this check untested.
+
+## Recoverable checkpoint
+
+For substantial work, keep a compact checkpoint in the existing permitted customer or project task record; if none exists, include it in the returned receipt. Reuse existing task/ticket identifiers when available. Record the task and agreed outcome, repository/branch/revision and dirty state, completed work and check results, pending work and checks, current blocker or `none`, and the exact next action. Link existing evidence rather than copying it into a new tracking artifact. Follow the record's write rules; a checkpoint does not silently change agreed scope or acceptance.
+
+In an ongoing engagement, optionally summarize that checkpoint under an unindented `## Implementation checkpoint` heading in the existing `context.md`, with the next action and task-record path/ID first. Follow the engagement confirmation and privacy rules. `fde resume` surfaces this saved summary without opening the referenced task file; retrieve that source only when permitted. Keep one current checkpoint, and clear or explicitly close it when the work ends. Do not initialize `.fde/` for standalone work or copy the whole backlog.
+
+Update it after meaningful completed slices and before a pause or handoff. On resuming, inspect the actual working tree and relevant evidence before taking the recorded next action; stale status is not proof that work or checks are still applicable.
+
 ## Acceptance
 
 A completion statement cites applicable evidence for its claims and explicitly names material gaps. If required checks fail, investigate or report the blocker; never skip them, edit expectations, or relabel the scope without authority to obtain a green result.

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

@@ -2,9 +2,9 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "a50e9dd53f9ed6896c219f1ef13f52b254eb896cee53a02ed56d40cf77a29a7c",
+    "SKILL.md": "0c51c5421875b17c66c4fdb03a33e3705da52a0c649dd138c4c4cd3f3c92292a",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/task-context.md": "3c0b0083e63a3e667d80fa7641b10eabf88ee729e877f658580cbc07031834ec",
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
     "references/test-assumptions.md": "bf60d8bb4c0701fcffb196d78f7f6c8b1c472fc877fb2caf41058fbf8e2415a1",
     "references/three-options.md": "168fab9fb8ac8de85b0d1fa58e1db17deaa244cdef8c99623a04a0a6c70fe52c"
   }

package/skills/options/SKILL.md

@@ -11,7 +11,11 @@ description: Compare feasible approaches to a customer problem and recommend a p
 
 Compare feasible approaches to a customer problem and recommend a path with costs, constraints and evidence. Use for an architecture or delivery decision, not implementation.
 
-Read [the task context contract](references/task-context.md), then [the method](references/three-options.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+Before investigating or acting:
+1. Read [the task context contract](references/task-context.md).
+2. Read [the method](references/three-options.md).
+
+Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
 
 ## Principles
 

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

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

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

@@ -2,9 +2,9 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "7228088cfea2128c220475fb1b2a417e3aecfb70dbd96a8fcbbc6b652ab0e3a2",
+    "SKILL.md": "88254d8bc2f58f4fcdd610dd7c111854dccf3ef488cfae85a4f81e90e25d1c96",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/plan.md": "4ccc74a3476da1c10bf8c05d249d573bcf73d13b8b6c88bd769635d816d0914b",
-    "references/task-context.md": "3c0b0083e63a3e667d80fa7641b10eabf88ee729e877f658580cbc07031834ec"
+    "references/plan.md": "6c37976169723f93d3554092979569a9640bcf02bd179bad52b17815c1c30f86",
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/plan/SKILL.md

@@ -11,7 +11,11 @@ description: Sequence an understood outcome into verifiable delivery slices with
 
 Sequence an understood outcome into verifiable delivery slices with dependencies, ownership and acceptance checks. Use for delivery planning, estimation or migration strategy.
 
-Read [the task context contract](references/task-context.md), then [the method](references/plan.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+Before investigating or acting:
+1. Read [the task context contract](references/task-context.md).
+2. Read [the method](references/plan.md).
+
+Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
 
 ## Principles
 

package/skills/plan/references/plan.md

@@ -30,6 +30,8 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **Reuse check.** Before sequencing a build, compare the requested solution with the smallest existing capability or operating change that could satisfy the same acceptance test. Cite the relevant repo/config/workaround evidence. Record why reuse is sufficient or insufficient in `decisions.md`; include “no new code” when supported. A request for AI does not establish that a model is needed. If a host engineering pack already has an approved implementation plan, reference it from `decisions.md`; do not generate a parallel user-story backlog.
 
+Preserve supplied ticket identifiers and blocking dependencies; do not renumber them. For a dependency, name what it blocks, its status, and the responsible owner or unresolved question. Keep independent work moving. Reuse the customer's domain terms; define a term in the existing plan or glossary only when ambiguity could change behavior or acceptance. Do not introduce another ticket scheme or glossary by default.
+
 **1. Work backwards from success.** What's the last thing that must be true before done? And before that? That's the dependency chain - not a wish list.
 
 **2. Front-load the fragile.** Check `terrain.md` hotspots. Risky modules go early - fail fast, not in week three.
@@ -44,6 +46,8 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
 
+Carry the agreed acceptance checks and their source into implementation and verification, preferably by linking the existing record. Added checks may strengthen coverage; changing a threshold or removing a requirement remains a proposal until the appropriate decision-maker approves the change with a dated source. Record what changed and why; a passing weaker test does not satisfy the original agreement.
+
 **Acceptance criteria gate:** no task moves to build without written happy-path AND unhappy-path criteria. Can't write them = the task isn't understood; the open question goes to the customer **before** the task starts. Vague criteria surface later as scope creep and rework.
 
 ## Artifact
@@ -55,7 +59,8 @@ A plan is **not done** until all four blocks exist:
 ```markdown
 ## Plan - <date>
 ### Now
-Task N: <outcome, not activity>
+Task <existing ID, or local label when none supplied>: <outcome, not activity>
+Blocked by: <existing task/access/decision + status and owner, or none>
 Delivers: <what someone can see/test>
 Accepts: <happy path> / <unhappy path>
 Touches: <files/systems - blast radius declared upfront>
@@ -138,7 +143,7 @@ Never quietly update tasks. Name the reset: update `reality.md` and `success.md`
 
 Acme, after discover: the reconciliation job is unowned, Marco's spreadsheet is the real fallback.
 
-**Now** is three tasks, not eight. Task 1 is *failures reach a named human* - delivers a page to a rota, accepts "kill the job mid-run → the on-call is paged within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, **Kill if:** a real failure page is acked by nobody on the rota (the *finance would act* assumption, DISPROVED if Marco is the only name that answers), verify by killing it in staging. Value promised: `risk-mitigation - a silent failure becomes a 15-minute one`.
+**Now** is three tasks, not eight. Task 1 is *failures reach a named human* - delivers a page to a rota, accepts "a permitted staging failure → the agreed operator receives the test alert within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, **Kill if:** the approved drill alert is acked by nobody on the rota (the *finance would act* assumption, DISPROVED if Marco is the only name that answers), verify in an approved staging drill with the operator and route agreed beforehand. Record configured, delivered and acknowledged separately; the drill does not authorize production paging. Value promised: `risk-mitigation - a silent failure becomes a 15-minute one`.
 
 The kill list in `decisions.md` is where the plan earns its keep: the rewrite of the reconciliation service that Tom keeps proposing goes there - *deferred, the failure mode is ownership not architecture (Priya accepted, Jun 12)* - along with the finance dashboard finance asked for directly. Both stay visible so the same argument is not re-litigated in week 4 without a receipt.
 

package/skills/plan/references/task-context.md

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

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

@@ -2,22 +2,22 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "bceae7ba11c006b3d1e93e330a80cc58eeef55d863cc374653eef8fd124c3056",
+    "SKILL.md": "f72f8cf960aa85150f85e316bca0f306e3e57c140ed9f49ed9fa04dd0671662f",
     "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
-    "references/build.md": "3f8b5e52eb874ee4e99db5e0b70d1ccca1134f667a39279d6b4e55629832ae75",
+    "references/build.md": "7634abd02b70011b7443a65ea3aaf3cb536ed5b051312aed188f46523deea7f9",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
     "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
     "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
-    "references/plan.md": "4ccc74a3476da1c10bf8c05d249d573bcf73d13b8b6c88bd769635d816d0914b",
+    "references/plan.md": "6c37976169723f93d3554092979569a9640bcf02bd179bad52b17815c1c30f86",
     "references/poc.md": "818dc90c2d401819735233ab9d69df171675d75abf8644c403dab7dd1dcf9199",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
-    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
-    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
-    "references/task-context.md": "3c0b0083e63a3e667d80fa7641b10eabf88ee729e877f658580cbc07031834ec",
+    "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
     "references/test-assumptions.md": "bf60d8bb4c0701fcffb196d78f7f6c8b1c472fc877fb2caf41058fbf8e2415a1",
     "references/three-options.md": "168fab9fb8ac8de85b0d1fa58e1db17deaa244cdef8c99623a04a0a6c70fe52c",
-    "references/verification.md": "62bb4fb40d9b71c6481c57a4564bcc98c4014a8be5d4aedfe1eb3f7f90d5e1f7"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/poc/SKILL.md

@@ -11,7 +11,11 @@ description: Run a bounded customer proof of concept to test a consequential unc
 
 Run a bounded customer proof of concept to test a consequential uncertainty. Use for a spike or pilot with a question and decision deadline, not a full rollout.
 
-Read [the task context contract](references/task-context.md), then [the method](references/poc.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+Before investigating or acting:
+1. Read [the task context contract](references/task-context.md).
+2. Read [the method](references/poc.md).
+
+Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
 
 ## Principles
 

package/skills/poc/references/build.md

@@ -6,7 +6,7 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Method
 
-1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Preserve unrelated edits and state which dependencies or interfaces the change touches. Before changing an untested legacy path, capture the undocumented behavior callers depend on with targeted characterization checks; distinguish behavior to preserve from the intended change.
+1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Follow the repository's branch policy and choose any needed checkout isolation according to that policy and overlapping work. Preserve unrelated edits and state which dependencies or interfaces the change touches. Before changing an untested legacy path, capture the undocumented behavior callers depend on with targeted characterization checks; distinguish behavior to preserve from the intended change.
 2. State the observable outcome, constraints, and acceptance checks. Reuse agreed criteria for routine fixes. If a consequential product choice is unresolved, surface that choice while continuing independent investigation; do not invent acceptance.
 3. Choose the smallest coherent path that demonstrates the outcome through the real entry point. Include the necessary storage, error handling, and interface behavior in that slice. Name the failure that stops expansion and the recovery path for stateful changes.
 4. Implement using the repository's tools and conventions. Search for existing services, fixtures, and validation before adding alternatives. Keep cleanup limited to what makes the changed path understandable; do not expand scope to repair unrelated code. When changing dependencies, inspect the package source, requested version, lockfile changes and repository install-script policy before executing package code. Use the approved package manager and bootstrap controls; do not blanket-enable scripts or apply unrelated dependency upgrades.
@@ -15,6 +15,8 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Deliverable and acceptance
 
+For substantial work, maintain the [recoverable checkpoint](verification.md#recoverable-checkpoint) in the existing task record as slices complete or work pauses.
+
 Return the implemented behavior, relevant paths, evidence, remaining limitations, and any decision needed. Done means the agreed checks have applicable evidence and the change is reviewable; passing tests does not imply deployment or customer acceptance. Committing, opening a PR, merging, and publishing happen only when the requested workflow authorizes those actions.
 
 When coordinated through `@fde`, record implementation and verification in the existing decisions/delivery records under their write rules. Standalone work can return the same receipt directly or use the repository's task record.

package/skills/poc/references/plan.md

@@ -30,6 +30,8 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **Reuse check.** Before sequencing a build, compare the requested solution with the smallest existing capability or operating change that could satisfy the same acceptance test. Cite the relevant repo/config/workaround evidence. Record why reuse is sufficient or insufficient in `decisions.md`; include “no new code” when supported. A request for AI does not establish that a model is needed. If a host engineering pack already has an approved implementation plan, reference it from `decisions.md`; do not generate a parallel user-story backlog.
 
+Preserve supplied ticket identifiers and blocking dependencies; do not renumber them. For a dependency, name what it blocks, its status, and the responsible owner or unresolved question. Keep independent work moving. Reuse the customer's domain terms; define a term in the existing plan or glossary only when ambiguity could change behavior or acceptance. Do not introduce another ticket scheme or glossary by default.
+
 **1. Work backwards from success.** What's the last thing that must be true before done? And before that? That's the dependency chain - not a wish list.
 
 **2. Front-load the fragile.** Check `terrain.md` hotspots. Risky modules go early - fail fast, not in week three.
@@ -44,6 +46,8 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
 
+Carry the agreed acceptance checks and their source into implementation and verification, preferably by linking the existing record. Added checks may strengthen coverage; changing a threshold or removing a requirement remains a proposal until the appropriate decision-maker approves the change with a dated source. Record what changed and why; a passing weaker test does not satisfy the original agreement.
+
 **Acceptance criteria gate:** no task moves to build without written happy-path AND unhappy-path criteria. Can't write them = the task isn't understood; the open question goes to the customer **before** the task starts. Vague criteria surface later as scope creep and rework.
 
 ## Artifact
@@ -55,7 +59,8 @@ A plan is **not done** until all four blocks exist:
 ```markdown
 ## Plan - <date>
 ### Now
-Task N: <outcome, not activity>
+Task <existing ID, or local label when none supplied>: <outcome, not activity>
+Blocked by: <existing task/access/decision + status and owner, or none>
 Delivers: <what someone can see/test>
 Accepts: <happy path> / <unhappy path>
 Touches: <files/systems - blast radius declared upfront>
@@ -138,7 +143,7 @@ Never quietly update tasks. Name the reset: update `reality.md` and `success.md`
 
 Acme, after discover: the reconciliation job is unowned, Marco's spreadsheet is the real fallback.
 
-**Now** is three tasks, not eight. Task 1 is *failures reach a named human* - delivers a page to a rota, accepts "kill the job mid-run → the on-call is paged within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, **Kill if:** a real failure page is acked by nobody on the rota (the *finance would act* assumption, DISPROVED if Marco is the only name that answers), verify by killing it in staging. Value promised: `risk-mitigation - a silent failure becomes a 15-minute one`.
+**Now** is three tasks, not eight. Task 1 is *failures reach a named human* - delivers a page to a rota, accepts "a permitted staging failure → the agreed operator receives the test alert within 15 min", touches the job wrapper and the alert config, rollback is re-disable the route, **Kill if:** the approved drill alert is acked by nobody on the rota (the *finance would act* assumption, DISPROVED if Marco is the only name that answers), verify in an approved staging drill with the operator and route agreed beforehand. Record configured, delivered and acknowledged separately; the drill does not authorize production paging. Value promised: `risk-mitigation - a silent failure becomes a 15-minute one`.
 
 The kill list in `decisions.md` is where the plan earns its keep: the rewrite of the reconciliation service that Tom keeps proposing goes there - *deferred, the failure mode is ownership not architecture (Priya accepted, Jun 12)* - along with the finance dashboard finance asked for directly. Both stay visible so the same argument is not re-litigated in week 4 without a receipt.
 

package/skills/poc/references/review.md

@@ -22,6 +22,8 @@ Trace the changed path through its consumers and failure cases:
 - **AI behavior:** outputs remain untrusted, tools enforce allowed actions, and [eval evidence](eval-pack.md) covers the changed behavior and documented authority. Preserve privacy-safe source evidence and concise rationale, never hidden reasoning.
 - **Operability:** observable failures, bounded resource use, meaningful checks, and a recovery path appropriate to the risk. Deployment readiness is assessed separately in [ship](ship.md).
 
+For changes with consequential security impact, map the affected assets, actors and permissions, and trust boundaries. Trace plausible abuse paths through the changed code, identify the controls that stop them, and check those controls or record the missing evidence. Keep this assessment with the existing review receipt and proportional to the change; use a formal threat-model framework only when the project requires or benefits from it.
+
 ## Findings and repair
 
 For each actionable finding give the path/line or precise location, concrete trigger, observed or reasoned failure, impact, and focused correction. Distinguish proven bugs from hypotheses that need a check. Prioritize release blockers over minor concerns; avoid speculative style work.

package/skills/poc/references/ship.md

@@ -8,7 +8,7 @@ Start from [task context](task-context.md). Standalone work uses supplied permit
 
 Identify the exact outcome, acceptance check, scope, affected users/systems, target environment, recovery mechanism, and who or what is authorized to accept and release it. Reuse confirmed authority and checks for routine work. Do not invent missing signers, permissions, measurements, or acceptance.
 
-For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing binary success or a named customer-side signer blocks that planning progression until resolved. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
+For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing acceptance criteria or a named customer-side signer blocks the affected implementation or release commitment, not a provisional plan or independent preparation. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
 
 A customer delivery checkpoint must let the agreed decision-maker replay and reject the acceptance check through an interface they operate. Prefer their staging; otherwise use an agreed representative environment and disclose its owner and limitations. Local green proves only the local run. Routine fixes may share an agreed checkpoint; no fixed number of changes forces a ceremony.
 
@@ -30,7 +30,7 @@ Before deployment, establish these facts from existing evidence or a necessary c
 | Acceptance | Replayable check and agreed decision-maker/mechanism; record actual acceptance separately from readiness |
 | Data and policy | Permitted data, applicable security/residency/change-window requirements, necessary approvals already recorded or obtained |
 | Recovery | Applicable tested rollback, restore, compensation, or roll-forward within agreed recovery-time/data-loss limits; explicit authority for irreversible effects |
-| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage |
+| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage; applicable [failure-signal delivery evidence](verification.md#operator-response) for paths whose readiness depends on operator response |
 | AI, when applicable | Current applicable SHIP eval evidence, critical failures zero, enforced action boundary and required human review or documented bounded automation |
 
 Check migration compatibility, old/new version coexistence, delayed jobs, caches, and already-emitted side effects where relevant. A code revert does not undo data loss or external writes. Reuse drill evidence only when the mechanism and relevant conditions are unchanged, explaining applicability. If recovery is only a plan, exercise it in a permitted representative environment before release.
@@ -43,7 +43,7 @@ For a coordinated engagement, also connect the release to the agreed value bucke
 
 Execute only when the requested workflow authorizes deployment to this target and the applicable gates are met. Otherwise leave a concrete release candidate, exact deployment/recovery instructions, evidence, and the remaining authorization for review. A permission to implement or test is not permission to publish.
 
-Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
+Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. Capture an applicable pre-rollout operating baseline with its source, environment, load/cohort and window when assessing change. Compare like conditions; keep absolute safety limits even when the baseline is poor. If no comparable baseline exists, name the gap and measurement plan: improvement is unproven, while release depends on the agreed acceptance and safety evidence, not an invented universal baseline gate. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
 
 During rollout inspect health, errors, key user behavior, and side-effect integrity. Halt expansion on breached thresholds or critical harm and apply authorized containment/recovery. Do not continue merely because the deploy command exited successfully.
 
@@ -57,7 +57,7 @@ Before wider exposure, verify expected load/cost, data pipeline behavior, owners
 
 Keep these claims separate: implemented, verified, deployed, measured outcome, and accepted. Include the candidate, target, command/pipeline, applicable checks and unrun checks, review source, evaluation where needed, authority source, recovery evidence, observation, and next owner/action. Attribute acceptance to its actual source and scope. A staging measurement is not production value, and a commit is not deployment.
 
-In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
+In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. If substantial work remains, retain a [recoverable checkpoint](verification.md#recoverable-checkpoint) there. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
 
 ## Worked example
 

package/skills/poc/references/task-context.md

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

package/skills/poc/references/verification.md

@@ -6,9 +6,9 @@ Use [task context](task-context.md). This method returns evidence directly or wr
 
 ## Method
 
-1. Translate each claim into the observation that would support or reject it. Reuse agreed acceptance criteria and required repository checks. Select focused checks for changed behavior before broadening to release requirements.
+1. Translate each claim into the observation that would support or reject it. Cite the agreed acceptance criteria and required repository checks. Compare the checks being run with that agreement; flag any weakened threshold or removed requirement without an attributed approval from the appropriate decision-maker. Select focused checks for changed behavior before broadening to release requirements.
 2. Identify the actual repository commands, fixtures, runtime, and environment. Read command behavior before executing it, especially when it can write externally. Use authorized environments and avoid leaking secrets through logs or diagnostic commands.
-3. Run the checks and inspect results, including exit status and relevant output. A running job, test discovery, a mocked response, and a successful real request are different evidence. Record asynchronous completion before claiming success.
+3. Run the checks and inspect results, including exit status and relevant output. A running job, test discovery, a mocked response, and a successful real request are different evidence. Record asynchronous completion before claiming success. Describe a command as executed only when its actual invocation and result are available; an inferred result is not a run.
 4. Bind evidence to the tested revision and working tree. For uncommitted changes record the base revision plus changed paths and an available diff digest or snapshot identifier. For browser/manual checks record the steps, inputs, observed result, and inspected evidence.
 5. After a change, rerun checks whose behavior or assumptions were affected. Reuse prior evidence only when the relevant code, dependencies, data, and environment remain applicable; cite the original run and reason. Never imply reused evidence was rerun.
 6. Label every required check **passed**, **failed**, **blocked**, or **not run**. Include why blocked/not run, impact, and next step. Missing evidence is unproven; it is not an observed failure or a pass.
@@ -28,6 +28,18 @@ Use one compact entry per check or a table with these fields:
 
 Keep implementation, verification, deployment, measured outcome, and customer acceptance distinct. A local pass supports the tested local behavior. An acceptance claim needs an attributed source from the agreed decision-maker or agreed acceptance mechanism. Record no raw `<private>` blocks, credentials, or hidden reasoning.
 
+## Operator response
+
+When readiness depends on a failure signal, verify that a representative failure reaches the responsible operator through the intended route in an approved environment. Record separately whether the route is configured, the signal was delivered, and the operator acknowledged it; configuration alone proves neither delivery nor response. Use an authorized test route or an already approved drill, and identify any difference from the intended operating route. Do not page people or trigger production incidents without authorization. Reuse applicable evidence with attribution; a draft guide can mark this check untested.
+
+## Recoverable checkpoint
+
+For substantial work, keep a compact checkpoint in the existing permitted customer or project task record; if none exists, include it in the returned receipt. Reuse existing task/ticket identifiers when available. Record the task and agreed outcome, repository/branch/revision and dirty state, completed work and check results, pending work and checks, current blocker or `none`, and the exact next action. Link existing evidence rather than copying it into a new tracking artifact. Follow the record's write rules; a checkpoint does not silently change agreed scope or acceptance.
+
+In an ongoing engagement, optionally summarize that checkpoint under an unindented `## Implementation checkpoint` heading in the existing `context.md`, with the next action and task-record path/ID first. Follow the engagement confirmation and privacy rules. `fde resume` surfaces this saved summary without opening the referenced task file; retrieve that source only when permitted. Keep one current checkpoint, and clear or explicitly close it when the work ends. Do not initialize `.fde/` for standalone work or copy the whole backlog.
+
+Update it after meaningful completed slices and before a pause or handoff. On resuming, inspect the actual working tree and relevant evidence before taking the recorded next action; stale status is not proof that work or checks are still applicable.
+
 ## Acceptance
 
 A completion statement cites applicable evidence for its claims and explicitly names material gaps. If required checks fail, investigate or report the blocker; never skip them, edit expectations, or relabel the scope without authority to obtain a green result.

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

@@ -2,9 +2,9 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "b58e4c788ad2c3e83d8266556023b4046bdc489d3050e3fcb414504825082210",
+    "SKILL.md": "07e8a3b485762e6b6897472fe4c934cb63ed0240d8258761be445729714d782d",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
     "references/pick-three.md": "fa5a5f6db94c72c5a1c6419276d0f7c13ff3067ce075a074af020f736fe3fad8",
-    "references/task-context.md": "3c0b0083e63a3e667d80fa7641b10eabf88ee729e877f658580cbc07031834ec"
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/prioritize/SKILL.md

@@ -11,7 +11,11 @@ description: Choose up to three immediate priorities from competing initiatives.
 
 Choose up to three immediate priorities from competing initiatives. Use when everything is urgent and the customer needs a defensible order with explicit deferrals.
 
-Read [the task context contract](references/task-context.md), then [the method](references/pick-three.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+Before investigating or acting:
+1. Read [the task context contract](references/task-context.md).
+2. Read [the method](references/pick-three.md).
+
+Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
 
 ## Principles
 

package/skills/prioritize/references/task-context.md

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

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

@@ -2,15 +2,15 @@
   "generator": "bin/generate-skills.js",
   "version": 1,
   "files": {
-    "SKILL.md": "65b965474e847f240138c1ada0ee7d982affc421a24a0a7a37970021f8269a03",
-    "references/build.md": "3f8b5e52eb874ee4e99db5e0b70d1ccca1134f667a39279d6b4e55629832ae75",
+    "SKILL.md": "ee9d9ccd8b1ccb982e390530bc193d446a6fdb3a1d630276d6dcd00cf9033948",
+    "references/build.md": "7634abd02b70011b7443a65ea3aaf3cb536ed5b051312aed188f46523deea7f9",
     "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
-    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
-    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
-    "references/task-context.md": "3c0b0083e63a3e667d80fa7641b10eabf88ee729e877f658580cbc07031834ec",
-    "references/verification.md": "62bb4fb40d9b71c6481c57a4564bcc98c4014a8be5d4aedfe1eb3f7f90d5e1f7"
+    "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/qa/SKILL.md

@@ -11,7 +11,11 @@ description: Exercise the delivered customer journey using real runtime or brows
 
 Exercise the delivered customer journey using real runtime or browser evidence. Use for functional acceptance testing after implementation, including failure paths.
 
-Read [the task context contract](references/task-context.md), then [the method](references/qa.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+Before investigating or acting:
+1. Read [the task context contract](references/task-context.md).
+2. Read [the method](references/qa.md).
+
+Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
 
 ## Principles
 

package/skills/qa/references/build.md

@@ -6,7 +6,7 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Method
 
-1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Preserve unrelated edits and state which dependencies or interfaces the change touches. Before changing an untested legacy path, capture the undocumented behavior callers depend on with targeted characterization checks; distinguish behavior to preserve from the intended change.
+1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Follow the repository's branch policy and choose any needed checkout isolation according to that policy and overlapping work. Preserve unrelated edits and state which dependencies or interfaces the change touches. Before changing an untested legacy path, capture the undocumented behavior callers depend on with targeted characterization checks; distinguish behavior to preserve from the intended change.
 2. State the observable outcome, constraints, and acceptance checks. Reuse agreed criteria for routine fixes. If a consequential product choice is unresolved, surface that choice while continuing independent investigation; do not invent acceptance.
 3. Choose the smallest coherent path that demonstrates the outcome through the real entry point. Include the necessary storage, error handling, and interface behavior in that slice. Name the failure that stops expansion and the recovery path for stateful changes.
 4. Implement using the repository's tools and conventions. Search for existing services, fixtures, and validation before adding alternatives. Keep cleanup limited to what makes the changed path understandable; do not expand scope to repair unrelated code. When changing dependencies, inspect the package source, requested version, lockfile changes and repository install-script policy before executing package code. Use the approved package manager and bootstrap controls; do not blanket-enable scripts or apply unrelated dependency upgrades.
@@ -15,6 +15,8 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Deliverable and acceptance
 
+For substantial work, maintain the [recoverable checkpoint](verification.md#recoverable-checkpoint) in the existing task record as slices complete or work pauses.
+
 Return the implemented behavior, relevant paths, evidence, remaining limitations, and any decision needed. Done means the agreed checks have applicable evidence and the change is reviewable; passing tests does not imply deployment or customer acceptance. Committing, opening a PR, merging, and publishing happen only when the requested workflow authorizes those actions.
 
 When coordinated through `@fde`, record implementation and verification in the existing decisions/delivery records under their write rules. Standalone work can return the same receipt directly or use the repository's task record.

package/skills/qa/references/review.md

@@ -22,6 +22,8 @@ Trace the changed path through its consumers and failure cases:
 - **AI behavior:** outputs remain untrusted, tools enforce allowed actions, and [eval evidence](eval-pack.md) covers the changed behavior and documented authority. Preserve privacy-safe source evidence and concise rationale, never hidden reasoning.
 - **Operability:** observable failures, bounded resource use, meaningful checks, and a recovery path appropriate to the risk. Deployment readiness is assessed separately in [ship](ship.md).
 
+For changes with consequential security impact, map the affected assets, actors and permissions, and trust boundaries. Trace plausible abuse paths through the changed code, identify the controls that stop them, and check those controls or record the missing evidence. Keep this assessment with the existing review receipt and proportional to the change; use a formal threat-model framework only when the project requires or benefits from it.
+
 ## Findings and repair
 
 For each actionable finding give the path/line or precise location, concrete trigger, observed or reasoned failure, impact, and focused correction. Distinguish proven bugs from hypotheses that need a check. Prioritize release blockers over minor concerns; avoid speculative style work.

package/skills/qa/references/ship.md

@@ -8,7 +8,7 @@ Start from [task context](task-context.md). Standalone work uses supplied permit
 
 Identify the exact outcome, acceptance check, scope, affected users/systems, target environment, recovery mechanism, and who or what is authorized to accept and release it. Reuse confirmed authority and checks for routine work. Do not invent missing signers, permissions, measurements, or acceptance.
 
-For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing binary success or a named customer-side signer blocks that planning progression until resolved. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
+For an initialized engagement, run `fde doctor --ready` before a new delivery plan or material scope change. Missing acceptance criteria or a named customer-side signer blocks the affected implementation or release commitment, not a provisional plan or independent preparation. A passing doctor validates record structure, not connectivity, release readiness, or customer acceptance. Standalone work evaluates the supplied contract directly.
 
 A customer delivery checkpoint must let the agreed decision-maker replay and reject the acceptance check through an interface they operate. Prefer their staging; otherwise use an agreed representative environment and disclose its owner and limitations. Local green proves only the local run. Routine fixes may share an agreed checkpoint; no fixed number of changes forces a ceremony.
 
@@ -30,7 +30,7 @@ Before deployment, establish these facts from existing evidence or a necessary c
 | Acceptance | Replayable check and agreed decision-maker/mechanism; record actual acceptance separately from readiness |
 | Data and policy | Permitted data, applicable security/residency/change-window requirements, necessary approvals already recorded or obtained |
 | Recovery | Applicable tested rollback, restore, compensation, or roll-forward within agreed recovery-time/data-loss limits; explicit authority for irreversible effects |
-| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage |
+| Operations | Named release/recovery owner, runbook appropriate to risk, health and business signals, stop thresholds, observation coverage; applicable [failure-signal delivery evidence](verification.md#operator-response) for paths whose readiness depends on operator response |
 | AI, when applicable | Current applicable SHIP eval evidence, critical failures zero, enforced action boundary and required human review or documented bounded automation |
 
 Check migration compatibility, old/new version coexistence, delayed jobs, caches, and already-emitted side effects where relevant. A code revert does not undo data loss or external writes. Reuse drill evidence only when the mechanism and relevant conditions are unchanged, explaining applicability. If recovery is only a plan, exercise it in a permitted representative environment before release.
@@ -43,7 +43,7 @@ For a coordinated engagement, also connect the release to the agreed value bucke
 
 Execute only when the requested workflow authorizes deployment to this target and the applicable gates are met. Otherwise leave a concrete release candidate, exact deployment/recovery instructions, evidence, and the remaining authorization for review. A permission to implement or test is not permission to publish.
 
-Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
+Use the customer's established pipeline and rollout mechanism. Select canary, staged exposure, blue/green, or direct rollout according to actual risk and platform capabilities; do not impose a universal cohort sequence. Define advance/abort thresholds and observation window before starting. Capture an applicable pre-rollout operating baseline with its source, environment, load/cohort and window when assessing change. Compare like conditions; keep absolute safety limits even when the baseline is poor. If no comparable baseline exists, name the gap and measurement plan: improvement is unproven, while release depends on the agreed acceptance and safety evidence, not an invented universal baseline gate. If another operator must execute, record their handoff and report deployment pending until there is evidence it happened.
 
 During rollout inspect health, errors, key user behavior, and side-effect integrity. Halt expansion on breached thresholds or critical harm and apply authorized containment/recovery. Do not continue merely because the deploy command exited successfully.
 
@@ -57,7 +57,7 @@ Before wider exposure, verify expected load/cost, data pipeline behavior, owners
 
 Keep these claims separate: implemented, verified, deployed, measured outcome, and accepted. Include the candidate, target, command/pipeline, applicable checks and unrun checks, review source, evaluation where needed, authority source, recovery evidence, observation, and next owner/action. Attribute acceptance to its actual source and scope. A staging measurement is not production value, and a commit is not deployment.
 
-In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
+In engagement mode, write confirmed implementation/decisions and delivery receipts under the existing record rules. Standalone work returns the same receipt or uses the repository's permitted release record. If substantial work remains, retain a [recoverable checkpoint](verification.md#recoverable-checkpoint) there. Committing, pushing, opening a PR, publishing, and notifying others are actions governed by the user's workflow, not mandatory steps imposed by this method.
 
 ## Worked example
 

package/skills/qa/references/task-context.md

@@ -18,3 +18,7 @@ Only locate the CLI when the selected task needs it. Check `fde` on PATH and its
 If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
 
 Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.
+
+## Identifier masking
+
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.