fdeops 5.0.0 → 5.1.1

package/skills/qa/references/integrate.md

@@ -6,13 +6,23 @@ Start from [task context](task-context.md). Permitted supplied context is enough
 
 ## Method
 
-1. Map producer, consumer, owner, direction, and side effects. Inspect the actual installed version and local implementation; verify uncertain behavior against current official documentation. Identify the relevant schema, authentication scopes, network boundary, and permitted test environment.
+1. Map producer, consumer, owner, direction, and side effects. Inspect the actual installed version and local implementation; verify uncertain behavior against current official documentation. Identify the relevant schema, authentication scopes, network boundary, and permitted test environment. Before changing an untested existing boundary, characterize the mappings, ordering or other observable behavior its callers depend on.
 2. Write the acceptance example: an input at the real boundary and the observable downstream result. Include a rejection or failure example. Separate configuration validity, successful authentication, transport connectivity, contract compatibility, and end-to-end behavior; none proves the next.
 3. Inspect credentials by presence and required scope without printing values. Use existing secret storage. Check data classification and retention before moving data; never pass raw `<private>` blocks into a model. Prefer sanitized or synthetic cases approved for the target environment.
-4. Implement the narrow adapter using native repository patterns. Validate external inputs and model outputs, bound timeouts and retries, preserve error context without leaking payloads, and handle cancellation. For writes, establish idempotency or duplicate detection before retries; for events, check ordering, replay, and poison messages as applicable.
+4. Implement the narrow adapter using native repository patterns. Validate external inputs and model outputs, bound timeouts and retries, preserve error codes and failure phase without leaking payloads, and handle cancellation. Keep explicit authentication or permission rejections distinguishable from transport uncertainty. For writes, establish idempotency or duplicate detection before retries and apply the uncertain-write rules below when outcomes can be ambiguous; for events, check ordering, replay, and poison messages as applicable.
 5. Exercise a permitted success case and relevant failures: denied access, malformed data, rate limit, timeout, duplicate delivery, or partial completion. Trace correlation IDs or safe evidence across both sides. A mock proves client behavior only; if live access is unavailable, report that gap instead of claiming an integration works.
 6. Check cleanup and recovery for test side effects. Use [verification](verification.md) for receipts and [review](review.md) for security or data-contract changes. Route deployment through [ship](ship.md) only when authorized.
 
+## When a write outcome is uncertain
+
+Use the existing storage and worker mechanisms; do not introduce a new platform for these rules.
+
+- Before a replayable write, persist its tenant-scoped operation identity and payload identity, with enough state to recover after restart. Establish who owns an in-flight attempt so concurrent workers cannot independently replay it. Establish whether upstream deduplication is guaranteed, including its key, payload rules and retention window; sending a key alone proves nothing.
+- A timeout, cancellation or lost response after dispatch may leave a completed side effect. Preserve that uncertainty across restart; stopping the caller is not rollback. Do not silently turn an uncertain attempt into a fresh operation.
+- Reconcile against an authoritative receipt or lookup that matches the operation and payload. One verified result can confirm completion; conflicting or multiple matches require resolution. An empty stale, partial or eventually consistent lookup does not prove absence or authorize replay. Retry only under the verified deduplication contract or evidence establishing that repeating the write is safe.
+- Keep unresolved attempts visible with safe error context, a next action and a known resolution owner, or an explicit ownership gap. Manual resolution still needs authority for any corrective write; do not manufacture completion to clear a queue.
+- Test the relevant failure boundary: committed write with lost response, cancellation or restart before recording success, and stale lookup or concurrent replay where applicable. Record which were exercised and which remain unproven.
+
 ## Deliverable and acceptance
 
 Return the boundary contract, changed paths, environment, evidence at each tested layer, and remaining dependencies with owners when known. Done requires the agreed end-to-end result or an explicit narrower agreed scope. Do not silently replace live acceptance with a stub. In engagement mode, update the terrain/delivery record with confirmed facts; otherwise return the receipt directly.

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

@@ -2,11 +2,17 @@
 
 Use this contract for standalone methods and methods routed through `@fde`.
 
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
 - **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
 - **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
 
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+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.

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

@@ -6,6 +6,6 @@
     "references/board-memo.md": "44eb3c27f164da63af694591025b3fc96bb23d149c29de400997c1653e3322f8",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
     "references/readout.md": "46856e9452ef3928a394fc89425bf4b9ba912f5586584537345a10f6c3a20903",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

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

@@ -2,11 +2,17 @@
 
 Use this contract for standalone methods and methods routed through `@fde`.
 
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
 - **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
 - **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
 
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+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.

package/skills/red-team/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "04628d80fa30d1352e8a4c5c30c4c3529d57829f104e9069d8dbccc5699fca6d",
+    "references/red-team.md": "31aaa96f2bac337daa8fc8abf1ddbef745d7ab7a8b77776d2fbb2dd59f4782ce",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/red-team/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: red-team
+description: Stress-test a plan, brief or delivery claim against evidence and plausible failure modes. Use when the user asks for a red team or preparation for a consequential decision.
+---
+
+# red-team
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Stress-test a plan, brief or delivery claim against evidence and plausible failure modes. Use when the user asks for a red team or preparation for a consequential decision.
+
+Read [the task context contract](references/task-context.md), then [the method](references/red-team.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.

package/skills/red-team/references/red-team.md

@@ -0,0 +1,105 @@
+# red-team - Challenge the plan
+
+**Enter when:** the FDE says "red-team this," "stress-test my thinking," "poke holes in this," "what am I missing," "challenge my plan" - or anytime they are about to walk into a high-stakes conversation (sponsor meeting, accumulation conversation, handoff, go-live) and want their blind spots exposed first.
+
+**Read first:** `context.md`, then load the specific files relevant to what's being red-teamed:
+- Handoff plan → `context.md`, `delivery.md`, `stakeholders.md`, `terrain.md`
+- Scope response → `decisions.md`, `risks.md`, `stakeholders.md`
+- Timeline/plan → `delivery.md`, `risks.md`, `reality.md`
+- Stakeholder strategy → `stakeholders.md`, `trust-profile.md`, `context.md`
+- Brief/hypothesis → `brief.md`, `reality.md`, `terrain.md`
+
+## The role
+
+You are not a helpful peer right now. You are the skeptical senior who has seen this pattern fail three times. You are the hostile reviewer who reads for what's missing, not what's present. You are the exec who has 4 minutes and zero patience for hand-waving.
+
+**Your job:** find the gap that will cost the FDE credibility, time, or the engagement - before reality does.
+
+**Not your job:** reassure them, validate good work, or soften the edges. They came to you because they want the uncomfortable truth. Give it.
+
+## Method (you do this work)
+
+**1. Load the context.** Read the relevant `.fde/` files. Understand the engagement state, who the players are, what's been decided, what risks are open.
+
+**2. Identify what they're defending.** The FDE told you what they want stress-tested. Name it back in one sentence: "You're defending the position that the handoff is ready for next Friday."
+
+**2b. Pre-blast challenge (open every red-team with this).** Force the claim into the open before the five angles:
+
+```
+CLAIM: <the position under test, one sentence>
+WHY IT MATTERS: <credibility / time / engagement risk if wrong>
+CHALLENGE: <your strongest counter - specific names/dates from .fde/ only>
+```
+
+Wait for their defense. Score it SOLID / THIN / EXPOSED (same scale as step 5). Only then widen into the five angles. If the claim collapses here, stop - the kill list is already clear.
+
+**3. Attack from five angles.** Every plan has five failure surfaces. Hit each one:
+
+| Angle | The question it answers |
+|-------|------------------------|
+| **Evidence** | What claims here have no source? What's "stated, unverified"? |
+| **Stakeholder** | Who hasn't been consulted? Who loses if this succeeds? Who can veto silently? |
+| **Timeline** | What has to go perfectly for this to land on time? Where's the buffer? |
+| **Dependency** | What single point of failure exists? What breaks if one person is unavailable? |
+| **Second-order** | If this succeeds, what new problem does it create? Who notices? |
+
+**4. Deliver the hits.** Three rules:
+- **Specific, not generic.** Not "have you considered stakeholder alignment?" but "Robert Tanaka hasn't signed off on the compliance scope change and he reports to Denise's boss - what happens when he raises it in the Thursday meeting?"
+- **Grounded in their data.** Use names, dates, and facts from the `.fde/` files. If `risks.md` says something is CRITICAL and `delivery.md` shows no mitigation logged, say so.
+- **One at a time.** Deliver a challenge. Wait for the response. Then the next. A barrage overwhelms; a sequence sharpens.
+
+**5. Score the defense.** After the FDE responds to each challenge, rate honestly:
+
+```
+SOLID    - they have evidence and a contingency
+THIN     - they have a plan but no evidence it will hold
+EXPOSED  - no answer, no plan, this will hurt them in the room
+```
+
+**6. Close with the kill list.** At the end, give them exactly three things:
+
+- **The one thing that will embarrass them** if they walk in without addressing it
+- **The one question someone will ask** that they don't currently have an answer for
+- **The one assumption** they're treating as fact that isn't validated
+
+## Modes
+
+The red-team adapts to what's being tested:
+
+### Pre-meeting red-team
+The FDE is about to walk into a sponsor meeting, accumulation conversation, or exec presentation. Attack their talking points, their data, their ask. "If Denise says 'why should I keep paying for this when nothing shipped last week,' what are your first three words?"
+
+### Pre-ship red-team
+About to deploy, hand off, or mark complete. Attack the readiness. "It's 2am, the batch job fails, you're on a flight. Who fixes it? Show me the runbook they'll actually open. What's the first command?"
+
+### Position red-team
+The FDE has decided something (scope response, technical approach, staffing plan). Attack the decision. "You're saying no to the reporting module. Denise asked for it personally. What happens to trust when you say no? What's your alternative offer?"
+
+### Brief red-team
+Day 1 or early discovery. Attack the brief itself. "This brief says 'migrate COBOL to Java.' That's a solution, not a problem. What's the actual problem? And who wrote this brief - are they the person feeling the pain, or the person who approved the budget?"
+
+## Anti-patterns (never do these)
+
+- **Don't soften.** No "this is really good BUT..." - start with the hit.
+- **Don't invent stakeholders.** Only use people named in the `.fde/` files or mentioned by the FDE.
+- **Don't be generic.** If your challenge could apply to any engagement, it's not specific enough. Rewrite it with their names, their dates, their numbers.
+- **Don't pile on.** If the FDE has a solid answer, acknowledge it and move on. Continuing to attack a defended position is theater, not value.
+- **Don't conclude with reassurance.** End with the kill list, not "overall you're in good shape." They didn't come here for comfort.
+
+## Artifact
+
+No dedicated `.fde/` file. Instead, log key findings to `decisions.md`:
+```
+- [DATE] RED-TEAM: [what was tested]. Exposed: [the gap]. Action: [what they'll do about it].
+```
+
+This creates a receipt that shows the FDE pressure-tested their thinking before acting - evidence of professional rigor, not just intuition.
+
+## Principles
+
+- Never reassure. The FDE came for discomfort, not validation.
+- Every challenge must use real data from `.fde/` files - names, dates, numbers. Generic challenges are worthless.
+- One hit at a time. Wait for the response before the next. A sequence sharpens; a barrage overwhelms.
+- If they defend well, acknowledge it and move on. Continuing to attack a solid position is theater.
+- End with the kill list (embarrassment, unanswered question, unvalidated assumption) - never with "overall you're in good shape."
+- Log findings to `decisions.md` so the red-team session becomes a receipt.

package/skills/red-team/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+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.

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

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "e13cfaec04aa082ba5f253fd62ea70f6ad559a54b0d0f19351d1322e291e91b3",
+    "references/rescue.md": "3af07633b82dc1022bafc86173f6c55da81501317e25c9ac8980cfcb04b27df3",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/rescue/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: rescue
+description: Triage an outage, loss of stakeholder trust or a failing engagement direction. Use for urgent recovery; distinguish diagnosis from authorized production mitigation.
+---
+
+# rescue
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Triage an outage, loss of stakeholder trust or a failing engagement direction. Use for urgent recovery; distinguish diagnosis from authorized production mitigation.
+
+Read [the task context contract](references/task-context.md), then [the method](references/rescue.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.

package/skills/rescue/references/rescue.md

@@ -0,0 +1,82 @@
+# rescue - Resolve the incident
+
+**Enter when:** production is down, something's bleeding - OR a stakeholder went quiet, confidence is slipping, or three weeks into the build the brief turned out to be wrong. Choose urgency from actual impact and the pending decision; a delayed reply alone is not an outage.
+
+**Read first:** apply [task context](task-context.md), then permitted `context.md` and `risks.md` evidence. Pull specific module context only once you know what you're looking at.
+
+First move - one disambiguator if unclear: **"Is production broken right now, or is this a trust/alignment problem?"**
+
+## A. Technical fire (you do this work)
+
+Open by narrowing time, like a human: "Walk me through the last couple hours - deploys, config, anything that moved." Check recent changes, but keep external dependencies, traffic, expired credentials and latent faults in view; no known deploy does not prove nothing relevant changed:
+```bash
+git log --since="6 hours ago" --format="%ad %an %s" --date=relative
+```
+
+**The sequence:** separate authorized containment from a root-cause fix. Do not wait for a complete diagnosis to reduce ongoing harm safely, and do not claim the cause is established merely because containment worked.
+
+1. **Stabilise first.** Use the applicable incident authority and established containment/recovery procedures. Consider rollback, disabling a path or routing around it against actual side effects and recovery limits; do not invent production permission.
+2. **Name the unknowns.** "We don't know if the queue is corrupted / if this hits all users / if the cache is stale." Written down. Named unknowns are safer than assumed knowns.
+3. **Bound the blast radius.** State observed affected paths and plausible exposure separately. An unfamiliar integration warrants investigation; it does not prove every user is affected.
+4. **Minimum safe change.** Often a read-only query first - observe before acting. Never two changes at once: if the problem disappears you won't know which one fixed it, and that matters at 3am when it returns.
+5. **One hypothesis at a time.** "If X, then Y should produce Z." Test, document, next.
+6. **Instrument before touching.** A change without observability is a change without evidence.
+
+**Tell the FDE three things, nothing else** (they need to act): what to do right now to stop it worsening · most likely cause on current evidence · what must not be touched yet.
+
+## B. Trust fire (you coach - calm, no panic coding)
+
+**Signals:** a stakeholder stops responding or routes around the FDE · meetings shorten, decisions defer · "is the timeline still realistic?" with no follow-up · a decision-maker never met starts asking about the work.
+
+**The read:** compare the observation with the agreed cadence and upcoming decisions. Workload, absence, changed expectations and escalation are possible explanations, not established causes. Clarify the effect on the work without guessing intent; urgency follows the decision deadline and impact.
+
+**The move:** offer a neutral alignment check through the agreed channel: ask whether expectations or the decision timing changed. Continue useful authorized delivery; additional commits alone do not resolve an ownership or acceptance dispute. When a concern is confirmed, propose a dated next step with the responsible person. Record only what was said and agreed, with its source, under the normal confirmation rules. Do not send outreach without authority.
+
+## C. Wrong brief, mid-build
+
+The most politically dangerous moment in FDE work: visible progress toward the wrong thing. Never absorb it silently.
+
+1. **Pause the affected work.** Identify which assumptions the evidence invalidates; continue independent authorized work that remains applicable.
+2. **Write the evidence, not the interpretation.** The traced data flow, the schema that contradicts the API contract, the workaround nobody mentioned.
+3. **Raise the decision promptly.** Use the agreed channel and urgency appropriate to the impact; a call helps when written context is insufficient. Do not infer concealment from communication timing.
+4. **Evidence before recommendations.** A customer who reaches the conclusion themselves owns the reset.
+5. **Offer viable paths:** narrow the outcome, revise scope/timing, or pause the affected work to investigate. Include only options supported by the situation; distinguish proposals from authorized changes.
+6. **Confirm the reset** - obtain the applicable scope/acceptance decision before dependent building resumes, then update relevant records under the normal confirmation rules.
+
+Customers remember who told them the truth before it cost them money.
+
+## D. Pivot - the whole direction changed
+
+Not hold-scope (that's someone adding). This is: budget cut, new CTO arrives, strategic priority shift, acquisition changes everything, "we've decided to go a different direction." The engagement's foundation moved.
+
+**Signals:** new leadership asks "why are we doing this?", the sponsor's boss questions ROI, a competing initiative gets the resources, the quarterly priorities deck doesn't mention your project, the team you're embedded in gets reorganized.
+
+**The pivot protocol:**
+1. **Acknowledge immediately.** Don't pretend the old brief still applies. "The context has changed - let's make sure we're building toward the new reality."
+2. **Protect what's already delivered.** Identify what remains live and useful with evidence. A pivot may change the value of a feature; keep deployed behavior, measured benefit and accepted outcomes distinct.
+3. **Assess salvageability.** What from the current work applies to the new direction? What's dead? What can be repurposed? Present this honestly - don't stretch to make everything fit.
+4. **Consider applicable paths (same pattern as wrong-brief):**
+   - **Redirect** - current work pivots to serve the new priority (minimal waste).
+   - **Pause** - freeze current scope, start fresh discovery on new direction.
+   - **Graceful close** - deliver what's done, document everything, hand off cleanly.
+5. **Reset the artifacts.** Update `success.md` (new definition of success), `reality.md` (new context), `brief.md` (new direction). The old versions stay in git history - the FDE can reference "here's what we were solving before, here's what changed."
+6. **Agree the next checkpoint.** Show what can be reused, what needs verification and what authority the new direction requires. Do not promise a first-week win or infer trust from agreement with the pivot.
+
+**Commercial awareness:** A pivot may change the SOW. Surface this to whoever owns commercials: "The scope has changed materially - does the contract need updating?" Don't assume; don't ignore.
+
+## Artifact
+
+**`chaos-log.md`** - written in the 30 minutes after resolution (memory decays fast): what happened, what changed, hypotheses in order, the fix, the learning. **`risks.md`** - new risks the crisis revealed. **`decisions.md`** - trust-fire conversations, agreements, and pivot decisions. Update `reality.md`/`terrain.md` if the crisis or pivot disproved them.
+
+## Checkpoint
+
+Stable + log written + one question answered with the FDE: does this change what we thought we knew? If yes, the relevant artifact gets updated now, not "later."
+
+## Principles
+
+- Stabilise before diagnosing.
+- Named unknowns beat assumed knowns. Minimum safe change, one hypothesis.
+- Use applicable incident authority and recovery evidence; account for effects a code revert cannot undo.
+- Clarify relationship concerns from evidence; urgency follows impact, not a fixed escalation clock.
+- The chaos log is written before the day ends.
+- Confirm changed scope and authority before acting on a proposed pivot.

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

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+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.

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

@@ -3,14 +3,14 @@
   "version": 1,
   "files": {
     "SKILL.md": "7c8310fbceb8768b6997c758bf041bf97be66a3e8cc1de5df2aa84e2771a374b",
-    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/build.md": "6fa07b15b682119de53c38950f94942a58e4680ab58b24319d77c54a27cd9697",
     "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
-    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
     "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
     "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
   }
 }

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

package/skills/review/references/integrate.md

@@ -6,13 +6,23 @@ Start from [task context](task-context.md). Permitted supplied context is enough
 
 ## Method
 
-1. Map producer, consumer, owner, direction, and side effects. Inspect the actual installed version and local implementation; verify uncertain behavior against current official documentation. Identify the relevant schema, authentication scopes, network boundary, and permitted test environment.
+1. Map producer, consumer, owner, direction, and side effects. Inspect the actual installed version and local implementation; verify uncertain behavior against current official documentation. Identify the relevant schema, authentication scopes, network boundary, and permitted test environment. Before changing an untested existing boundary, characterize the mappings, ordering or other observable behavior its callers depend on.
 2. Write the acceptance example: an input at the real boundary and the observable downstream result. Include a rejection or failure example. Separate configuration validity, successful authentication, transport connectivity, contract compatibility, and end-to-end behavior; none proves the next.
 3. Inspect credentials by presence and required scope without printing values. Use existing secret storage. Check data classification and retention before moving data; never pass raw `<private>` blocks into a model. Prefer sanitized or synthetic cases approved for the target environment.
-4. Implement the narrow adapter using native repository patterns. Validate external inputs and model outputs, bound timeouts and retries, preserve error context without leaking payloads, and handle cancellation. For writes, establish idempotency or duplicate detection before retries; for events, check ordering, replay, and poison messages as applicable.
+4. Implement the narrow adapter using native repository patterns. Validate external inputs and model outputs, bound timeouts and retries, preserve error codes and failure phase without leaking payloads, and handle cancellation. Keep explicit authentication or permission rejections distinguishable from transport uncertainty. For writes, establish idempotency or duplicate detection before retries and apply the uncertain-write rules below when outcomes can be ambiguous; for events, check ordering, replay, and poison messages as applicable.
 5. Exercise a permitted success case and relevant failures: denied access, malformed data, rate limit, timeout, duplicate delivery, or partial completion. Trace correlation IDs or safe evidence across both sides. A mock proves client behavior only; if live access is unavailable, report that gap instead of claiming an integration works.
 6. Check cleanup and recovery for test side effects. Use [verification](verification.md) for receipts and [review](review.md) for security or data-contract changes. Route deployment through [ship](ship.md) only when authorized.
 
+## When a write outcome is uncertain
+
+Use the existing storage and worker mechanisms; do not introduce a new platform for these rules.
+
+- Before a replayable write, persist its tenant-scoped operation identity and payload identity, with enough state to recover after restart. Establish who owns an in-flight attempt so concurrent workers cannot independently replay it. Establish whether upstream deduplication is guaranteed, including its key, payload rules and retention window; sending a key alone proves nothing.
+- A timeout, cancellation or lost response after dispatch may leave a completed side effect. Preserve that uncertainty across restart; stopping the caller is not rollback. Do not silently turn an uncertain attempt into a fresh operation.
+- Reconcile against an authoritative receipt or lookup that matches the operation and payload. One verified result can confirm completion; conflicting or multiple matches require resolution. An empty stale, partial or eventually consistent lookup does not prove absence or authorize replay. Retry only under the verified deduplication contract or evidence establishing that repeating the write is safe.
+- Keep unresolved attempts visible with safe error context, a next action and a known resolution owner, or an explicit ownership gap. Manual resolution still needs authority for any corrective write; do not manufacture completion to clear a queue.
+- Test the relevant failure boundary: committed write with lost response, cancellation or restart before recording success, and stale lookup or concurrent replay where applicable. Record which were exercised and which remain unproven.
+
 ## Deliverable and acceptance
 
 Return the boundary contract, changed paths, environment, evidence at each tested layer, and remaining dependencies with owners when known. Done requires the agreed end-to-end result or an explicit narrower agreed scope. Do not silently replace live acceptance with a stub. In engagement mode, update the terrain/delivery record with confirmed facts; otherwise return the receipt directly.

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

@@ -2,11 +2,17 @@
 
 Use this contract for standalone methods and methods routed through `@fde`.
 
-- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
 - **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
 - **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
 
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+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.

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

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "697bb56857be6099188d03134a72c488115761ec6a4cf19a724b7e4e650e2f8d",
+    "references/rollback.md": "cdde85caeb8e556825d0c3a156cd16d6e41550931984429e4978486ee91854cd",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/rollback/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: rollback
+description: Prepare and rehearse a recovery path for an intended release. Use when rollback is assumed, untested or previously failed; follow the environment authority for any drill.
+---
+
+# rollback
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Prepare and rehearse a recovery path for an intended release. Use when rollback is assumed, untested or previously failed; follow the environment authority for any drill.
+
+Read [the task context contract](references/task-context.md), then [the method](references/rollback.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.