fdeops 5.1.6 → 5.1.7

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.6",
+  "version": "5.1.7",
   "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.6",
+  "version": "5.1.7",
   "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.6",
+  "version": "5.1.7",
   "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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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

package/skills/build/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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

package/skills/debug/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

package/skills/earn-trust/.fde-generated.json

@@ -3,7 +3,7 @@
   "version": 1,
   "files": {
     "SKILL.md": "a739454cd58e6beba57877e8b1c0d888d1068617b63959014c7b142fd12d68c3",
-    "references/earn-trust.md": "89df253665d996e28bc7acf785346c50f3062115ffd70fb7ad3300c99eb36ead",
+    "references/earn-trust.md": "ec31c339a39d9a7f3855ff77478684bc1d6cae473362489456f0c17b64c33399",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/earn-trust/references/earn-trust.md

@@ -8,7 +8,7 @@ Build confidence through useful work, clear evidence and respect for the custome
 
 ## Method (you do this work)
 
-**1. Establish the access needed now.** Identify the next task, the minimum relevant access, and its actual policy or authorization source. Read-only access, reviewed PRs, branch writes and deployment rights can be granted independently. Reuse permissions already granted for the same scope; do not impose a ladder or ask the customer to re-earn established access. Record missing or disputed rights and continue work that does not depend on them.
+**1. Establish the access needed now.** Identify the next task, the minimum relevant access, and its actual policy or authorization source. Read-only access, reviewed PRs, branch writes and deployment rights can be granted independently. Reuse permissions already granted for the same scope; do not impose a ladder or ask the customer to re-earn established access. For missing or disputed access, record the blocked task, status, responsible approver or unknown, next action and any supplied expected wait in the existing plan or context. Mark steps that require the FDE or customer to act, such as VPN enrollment or secret provisioning; never collect secret values. Request only what the next task needs and continue independent work.
 
 **2. Make progress visible.** Choose useful actions for the engagement's stage and agreed cadence:
 

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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

package/skills/evaluate/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

package/skills/fde/references/earn-trust.md

@@ -8,7 +8,7 @@ Build confidence through useful work, clear evidence and respect for the custome
 
 ## Method (you do this work)
 
-**1. Establish the access needed now.** Identify the next task, the minimum relevant access, and its actual policy or authorization source. Read-only access, reviewed PRs, branch writes and deployment rights can be granted independently. Reuse permissions already granted for the same scope; do not impose a ladder or ask the customer to re-earn established access. Record missing or disputed rights and continue work that does not depend on them.
+**1. Establish the access needed now.** Identify the next task, the minimum relevant access, and its actual policy or authorization source. Read-only access, reviewed PRs, branch writes and deployment rights can be granted independently. Reuse permissions already granted for the same scope; do not impose a ladder or ask the customer to re-earn established access. For missing or disputed access, record the blocked task, status, responsible approver or unknown, next action and any supplied expected wait in the existing plan or context. Mark steps that require the FDE or customer to act, such as VPN enrollment or secret provisioning; never collect secret values. Request only what the next task needs and continue independent work.
 
 **2. Make progress visible.** Choose useful actions for the engagement's stage and agreed cadence:
 

package/skills/fde/references/plan.md

@@ -30,7 +30,7 @@ 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.
 
-Use existing ticket identifiers when they help connect the plan to implementation and evidence. 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.
+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.
 
@@ -46,6 +46,8 @@ Use existing ticket identifiers when they help connect the plan to implementatio
 
 **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
@@ -57,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>

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

package/skills/fde/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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.
 
@@ -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.
 

package/skills/integrate/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -4,7 +4,7 @@
   "files": {
     "SKILL.md": "88254d8bc2f58f4fcdd610dd7c111854dccf3ef488cfae85a4f81e90e25d1c96",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/plan.md": "324cf48e9ba46b55eb382a93b6836cbd3d8f4df2e899567baa361a5b42c022a4",
+    "references/plan.md": "6c37976169723f93d3554092979569a9640bcf02bd179bad52b17815c1c30f86",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
   }
 }

package/skills/plan/references/plan.md

@@ -30,7 +30,7 @@ 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.
 
-Use existing ticket identifiers when they help connect the plan to implementation and evidence. 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.
+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.
 
@@ -46,6 +46,8 @@ Use existing ticket identifiers when they help connect the plan to implementatio
 
 **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
@@ -57,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>

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

@@ -10,14 +10,14 @@
     "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
-    "references/plan.md": "324cf48e9ba46b55eb382a93b6836cbd3d8f4df2e899567baa361a5b42c022a4",
+    "references/plan.md": "6c37976169723f93d3554092979569a9640bcf02bd179bad52b17815c1c30f86",
     "references/poc.md": "818dc90c2d401819735233ab9d69df171675d75abf8644c403dab7dd1dcf9199",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
     "references/test-assumptions.md": "bf60d8bb4c0701fcffb196d78f7f6c8b1c472fc877fb2caf41058fbf8e2415a1",
     "references/three-options.md": "168fab9fb8ac8de85b0d1fa58e1db17deaa244cdef8c99623a04a0a6c70fe52c",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/poc/references/plan.md

@@ -30,7 +30,7 @@ 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.
 
-Use existing ticket identifiers when they help connect the plan to implementation and evidence. 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.
+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.
 
@@ -46,6 +46,8 @@ Use existing ticket identifiers when they help connect the plan to implementatio
 
 **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
@@ -57,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>

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.
 
@@ -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.
 

package/skills/poc/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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.
 
@@ -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.
 

package/skills/qa/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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

package/skills/review/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -7,6 +7,6 @@
     "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
     "references/runbook.md": "d32a40113941c603b97f09eabfd0e25afd25129102c6b07fa91a04fb4f8e93e7",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/runbook/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.

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

@@ -9,8 +9,8 @@
     "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "55733ca868c00fb22110bc7b3ec7bb6c6451366c795073b19a2bccd30d2764c8",
-    "references/ship.md": "c7fd7774d6ba1f7e9d05b4bfd89bae124bb9bab0079d49c15a025b8b3383f157",
+    "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
     "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
-    "references/verification.md": "18dfaa97b16e8713a99d9686e3a9fef4e0b9bde0f81c87af8fd73dae588543c2"
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

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

package/skills/ship/references/verification.md

@@ -6,7 +6,7 @@ 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. 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.