fdeops 5.0.0 → 5.1.1

package/skills/fde/references/rescue.md

@@ -1,23 +1,23 @@
 # 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. Trust fires get the same urgency as outages.
+**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:** `context.md`, `risks.md` only. Pull specific module context only once you know what you're looking at.
+**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." Something always changed; "nothing changed" means nobody's looked:
+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:** no fix until the cause is named. A symptom patch is the second incident.
+**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.** Roll back? Disable the broken path? Route around it? Buy time before diagnosing. The instinct to fix fast causes the second incident.
+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. **Assume maximum blast radius.** The unrecognised integration in the stack trace is load-bearing until proven otherwise.
+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.
@@ -28,20 +28,20 @@ git log --since="6 hours ago" --format="%ad %an %s" --date=relative
 
 **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:** the stakeholder who goes quiet is not losing interest - **they are escalating above you.** Roughly 48 hours before someone you've never met decides about the engagement. Respond same-day.
+**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:** do NOT push harder on delivery - more commits won't warm a cold sponsor. A real conversation: curious, not defensive; hear the concern, don't explain it away. Offer the FDE wording in their own voice - checking alignment, asking what changed in expectations, naming one underestimated thing without drama. Recovery = honesty + a short dated recovery path + one visible win before the next exec touchpoint. Log what was said and agreed in `decisions.md` before the day ends.
+**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. **Stop the work.** Every further line builds on a known-wrong foundation.
+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. **Conversation before the day ends.** Not email: "We need twenty minutes. We found something important." Waiting reads as concealment.
+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. **Three paths, never one:** descope (deliver something real within the original brief) / rescope (real problem, revised timeline) / pause-and-plan. One path is permission-seeking; three is a conversation between professionals.
-6. **Reset in writing** - update `success.md` and `reality.md`, get explicit acknowledgement - before building resumes.
+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.
 
@@ -53,14 +53,14 @@ Not hold-scope (that's someone adding). This is: budget cut, new CTO arrives, st
 
 **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.** Shipped value is not un-shipped by a pivot. Name it: "Here's what's live and working. That value is real regardless of direction."
+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. **Three paths (same pattern as wrong-brief):**
+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. **Re-earn trust fast.** A pivot is a trust moment. The FDE who smoothly redirects gains credibility. The FDE who fights the pivot or pretends nothing changed loses it. Deliver one visible win in the new direction within the first week.
+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.
 
@@ -76,7 +76,7 @@ Stable + log written + one question answered with the FDE: does this change what
 
 - Stabilise before diagnosing.
 - Named unknowns beat assumed knowns. Minimum safe change, one hypothesis.
-- Never production without a tested rollback - even in a crisis.
-- A trust fire is a same-day fire.
+- 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.
-- A pivot is a trust moment - redirect smoothly, don't fight the new reality.
+- Confirm changed scope and authority before acting on a proposed pivot.

package/skills/fde/references/runbook.md

@@ -1,141 +1,73 @@
-# runbook - Write the runbook
+# runbook - Write an operating guide
 
-**Enter when:** the engagement is entering its final phase, the customer team needs to operate without the FDE, a new FDE is taking over, or the sponsor asks "what happens when you leave?"
+**Enter when:** the team needs instructions to operate, diagnose or recover a system, or an engineer is preparing to transfer responsibility.
 
-**Read first:** `delivery.md`, `terrain.md`, `reality.md`, `decisions.md`, `context.md`, `stakeholders.md`. The handoff is built from the full engagement record. Load `trust-profile.md` for operational boundaries.
+Apply [task context](task-context.md). Use supplied operational facts, relevant code and verified procedures. For a bound engagement, retrieve relevant sanitized delivery, dependency and ownership evidence; do not load the full customer record or raw private material.
 
-The mark of a great FDE engagement is that the team can operate without you. A handoff that requires a callback in six weeks means the engagement didn't end - it paused. Handoff engineering is deliberate: it's designed, tested, and verified before the last day.
+## Match the request
 
-## Method (you do this work)
+- **Draft a guide:** write what is known, mark unverified procedures and missing evidence, and return the requested document. No customer record, live access, drill or closure ceremony is required.
+- **Verify an operating guide:** agree the permitted environment and checks, exercise relevant procedures, and record what happened. Do not run a destructive or production drill from a documentation request alone.
+- **Complete a handoff:** use [handoff](close.md) for the wider ownership and acceptance decision. A written guide is one part of that decision, not proof of readiness.
 
-**1. The handoff inventory.** Everything the team needs to operate, categorised:
+## Build the guide from evidence
 
-| Category | What to hand off | Test: can they do it alone? |
-|----------|-----------------|---------------------------|
-| **Code knowledge** | Architecture decisions (`decisions.md`), why the code is shaped the way it is | Team member can explain the three most important design decisions |
-| **Operational** | Deploy, rollback, incident response, monitoring | Team member runs the deploy and rollback procedure independently |
-| **Tribal** | The things only you know - the workaround, the contact, the context | Written in `handoff.md` and reviewed with the person who'll carry it |
-| **Political** | Stakeholder dynamics, approval chains, who to call when | Documented in `stakeholders.md` with signal history |
-| **Data/AI** | Model versions, retraining triggers, drift monitoring, fallback paths | Owner named for each AI component; kill switch documented |
-
-**2. The 2am document.** Written for the person woken up on a Saturday night with zero context:
-
-```markdown
-# Operations runbook - <system name>
-
-## The 3 things that will break (and the fix for each)
-
-### 1. <most likely failure>
-Symptom: <what they'll see>
-Cause: <most likely why>
-Fix: <exact steps, copy-pasteable commands>
-Who to call if this doesn't fix it: <name, contact>
-
-### 2. <second most likely failure>
-...
-
-### 3. <third most likely failure>
-...
-
-## Deploy
-Command: <exact command>
-Time: <how long it takes>
-Verify: <how to confirm it worked>
-Rollback: <exact command and expected time>
-
-## Alerts
-| Alert | Means | Do this |
-|-------|-------|---------|
-| <alert name> | <plain English> | <action or link to detailed runbook> |
-
-## Contacts
-| Who | When to call | How |
-|-----|-------------|-----|
-| <name> | <scenario> | <phone/slack/email> |
-```
-
-**3. The knowledge transfer sessions.** Not a document dump - three structured sessions:
-
-| Session | Focus | Attendees | Duration | Output |
-|---------|-------|-----------|----------|--------|
-| **Architecture walkthrough** | Why, not what. The decisions, the trade-offs, the things that almost went wrong. | Full team | 60-90 min | Recording + Q&A log |
-| **Operational drill** | Deploy, rollback, incident response. They do it, you watch. | On-call team | 60 min | Drill report with confidence level |
-| **Floor drill** | They run the real job (the exception on the operating map) while you watch, hands off. Then they teach the next person. If they cannot, the runbook is a PDF. | Named operator on the floor | 45-60 min | They used the 2am doc during the drill, or the embed is not closed |
-| **Edge-case handover** | The things that aren't in any document. The workarounds, the fragile spots, the "ask Sarah because she's the only one who knows." | Team lead + 1 | 30 min | Additions to `handoff.md` |
-
-**4. The confidence check.** After the knowledge transfer, score the team's readiness:
-
-| Area | Confidence (1-5) | Evidence |
-|------|------------------|----------|
-| Daily operations | | Can they deploy and rollback without help? |
-| Incident response | | Did they complete the drill within acceptable time? |
-| Floor job | | Did the named operator complete Tuesday's real exception without you at the keyboard? |
-| Architecture decisions | | Can they explain why the system is built this way? |
-| AI components (if any) | | Do they know how to monitor, retrain, and disable? |
-| Stakeholder management | | Do they know who to update and how? |
-
-**Average below 3.5 → the handoff is not complete.** Extend, or tell the sponsor the embed is not closed. Do not document the gap and leave.
-
-**5. The successor brief.** If a new FDE is taking over, write a brief that gets them operational in one hour:
+Identify the system, the intended reader and the decisions that reader can make. Follow the actual operating path and include only relevant sections:
 
 ```markdown
-# Successor brief - <engagement name>
-
-## In 30 seconds
-<The real problem, the solution, where it stands>
-
-## Read these files first
-1. context.md - current state
-2. reality.md - the real problem (not the brief)
-3. decisions.md - what was decided and why
-4. stakeholders.md - who matters and their current signal
-5. risks.md - what's dangerous right now
-
-## The three things I wish I'd known on day one
-1. <thing>
-2. <thing>
-3. <thing>
-
-## The one thing that will bite you
-<specific warning>
+# Operating guide - <system>
+Status: Draft / Verified for <environment and scope>
+Evidence: <code, observed run, operator statement or existing document>
+Operating owner: <confirmed role/person and source, or proposed/unconfirmed>
+
+## Normal operation
+What should happen, how often, and how to check it.
+
+## Known failure modes
+Symptom: <what the operator sees>
+Evidence: <what establishes this behavior>
+Cause: <verified cause or explicit unknown>
+Action: <supported steps, constraints and stop conditions>
+Validation: <tested environment/date/result, or unverified>
+Escalation: <confirmed role/channel, or missing>
+
+## Deploy and recover
+Procedure: <verified commands or a source link; do not invent commands>
+Permissions and prerequisites: <required access and safety conditions>
+Check: <expected observable result>
+Recovery: <tested procedure or the missing recovery evidence>
+
+## Monitor and escalate
+Signal: <existing alert or check>
+Meaning: <known interpretation>
+Response: <authorized action and when to escalate>
+
+## Open readiness gaps
+Missing evidence, owner to confirm, and proposed next check.
 ```
 
-**6. The clean exit.** Before the last day:
-
-- [ ] All access returned or transferred (repos, environments, admin panels)
-- [ ] No personal credentials left in the system (API keys, tokens, SSH keys)
-- [ ] `.fde/` folder handed to the successor or archived with the team
-- [ ] Final status sent to sponsor (see `readout.md`)
-- [ ] Retrospective completed (see `close.md`)
-- [ ] Patterns extracted (see `encode-pattern.md`)
+Do not pad the document with an arbitrary number of failures, contacts or commands. A stated retry problem without a known cause should remain an investigation item, not become a fabricated repair procedure. A suggested owner is not an accepted operating responsibility.
 
-## Artifact
+For AI components, include relevant model and configuration versions, evaluation checks, failure limits and the supported way to pause actions. Do not assume retraining or autonomous operation is required.
 
-**`handoff.md`** - the 2am document + the operational inventory. The most important file the engagement produces after the code itself.
+## Verify when requested
 
-**`context.md`** - final update: engagement status, handoff confidence, named gaps.
+Select checks based on the system's actual consequences. For example, the receiving operator may demonstrate normal operation, diagnose a known failure, or recover a failed release in a permitted test environment.
 
-## Checkpoint
+Record each critical capability separately as verified, failed or untested, with evidence. A successful walkthrough cannot compensate for an untested recovery path. Avoid an averaged confidence score that hides a critical gap.
 
-The acid test: "Can the team run this system for 30 days without calling you?" If yes → handoff complete. If no → name exactly what's missing, and either fix it or document the risk for the sponsor.
+If a procedure fails, correct the guide or system within scope and repeat the affected check. If verification is unavailable, deliver the draft with its limits and propose the next check; do not claim the handoff complete or indefinitely extend the engagement yourself.
 
-## The permanent crutch anti-pattern
+## Deliver and retain ownership boundaries
 
-Warning signs you've become a dependency instead of a deliverer:
-- The team defers decisions until you're in the room
-- "Can you just stay one more month?" (translation: the handoff hasn't started)
-- You're the only person who's run the deploy or the rollback
-- The sponsor introduces you as "part of the team" in month 4
-- The customer calls you within a week of "close"
+Return the guide, its verification status and any remaining operating decisions. Save it to the requested location. In a bound engagement, propose updates to `handoff.md` and relevant current-state records under their confirmation rules.
 
-If you see 2+: accelerate the handoff immediately. The longer you stay past usefulness, the harder it is for the team to believe they can operate alone. A great FDE engagement ends with the team forgetting they needed you.
+Access changes, exports of customer records, sponsor messages and closure decisions require their own authorization. A request for a runbook does not authorize these actions. Transfer only the material the recipient is entitled to receive.
 
 ## Principles
 
-- The goal of every engagement is to make yourself replaceable.
-- The 2am document is the real handoff - everything else supports it.
-- Knowledge transfer is four sessions, not a doc dump. The floor drill is the named operator completing Tuesday's real job from the 2am doc, hands off. If they cannot, do not close.
-- A confidence score below 3.5 means the handoff isn't done.
-- The successor brief gets the next FDE operational in one hour or it's too long.
-- Clean exit: no personal credentials left behind, ever.
-- If you're still indispensable after close, the engagement failed on the most important criterion.
+- Write for the person handling the actual failure.
+- Supported procedures beat plausible commands.
+- Draft, tested procedure and accepted ownership remain distinct.
+- Verify critical capabilities individually.
+- Keep private relationship notes and credentials out of an operating guide.

package/skills/fde/references/source-setup.md

@@ -0,0 +1,30 @@
+# Source access for customer notes
+
+Use this guide when `connect` needs a source and when `ingest` cannot reach requested material. Configure only the named source. FDEOps does not bundle source authentication or silently install integrations.
+
+## Start with what is already available
+
+Inspect the current host's tools. Name which requested source can be read and what remains unavailable. A server appearing in a configuration file is not proof that its credentials or scopes work.
+
+For setup, use the source provider's current official documentation and the host's documented connector or MCP configuration. Do not invent package names, API methods, secret values or installation flags. Prefer an existing authenticated connector over adding a second one. Put credentials in the host's supported secret storage; never paste them into a customer record, prompt or report.
+
+## Choose the source path
+
+| Material | First check | If unavailable |
+|---|---|---|
+| Pasted notes or a local export | The user permits this content in the agent; identify the relevant file or text | Ask for the specific missing material, not an integration installation |
+| Meeting notes, such as Granola | A notes tool can read the selected meeting and its source identifier | Use a permitted export or the provider's supported setup |
+| Slack or another chat system | Read access to the specified thread or channel and date range | Ask the user or workspace owner to resolve access; a copied thread is an alternative |
+| Notion or another document system | Read access to the specified page and its linked content when required | Use a permitted document export or resolve the missing page access |
+
+Test a configured source with the smallest requested read. Report setup, connectivity and successful retrieval separately. Do not widen access to an entire inbox or workspace just because one item is unavailable.
+
+## Keep setup separate from record updates
+
+Configuring or testing a source does not require a customer record. Reading requested material does not authorize applying it to one.
+
+For a review-only request, use the permitted supplied or fetched text and return a sourced draft. For staging or saving, select the intended customer record first, then follow [ingest](ingest.md): stage → propose → review → explicit confirmation → apply. Source permissions do not authorize a record update, and the FDEOps CLI itself makes no network calls.
+
+Short notes can use [debrief](debrief.md) directly. Large files should be staged through the CLI when a customer record has been selected. Preserve source IDs and dates when available; absence of a source remains explicit.
+
+FDEOps does not post messages, change source documents, background-sync channels or make recurring pulls through this path. Use the requested read scope only.

package/skills/fde/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/fde/references/who-decides.md

@@ -1,91 +1,63 @@
 # who-decides - Map decision rights
 
-**Enter when:** new stakeholders appear, signals shift mid-engagement, a meeting felt off but you can't say why, or it's been two weeks and the map hasn't been updated.
+**Enter when:** a consequential decision has unclear authority, ownership is disputed, stakeholders change, or observed communication changes affect the next action.
 
-**Read first:** `stakeholders.md`, `context.md`. Load `trust-profile.md` only if sacred-data boundaries affect who gets told what.
+**Read first:** apply [task context](task-context.md), then permitted `stakeholders.md` and `context.md` evidence. Retrieve relevant trust constraints only when access or disclosure is involved.
 
-The org chart tells you who reports to whom. The stakeholder radar tells you who actually decides, who blocks quietly, and who's about to escalate. FDEs who read the org chart get blindsided; FDEs who read the room stay ahead.
+Titles, influence and responsiveness can help you find the right conversation. They do not establish approval authority or explain someone's motives.
 
 ## Method (you do this work)
 
-**1. Map the five roles - every engagement has them, sometimes in one person:**
+**1. Resolve the decisions in front of you.** Reuse the customer's existing agreement, delegation or decision process. For each relevant decision, identify who or what can decide, the scope of that right, its source, and whether it is confirmed, proposed, disputed or unknown. Distinguish budget/scope approval, data/AI-policy approval, release authority, customer acceptance, and operating/recovery responsibility when they differ. Do not require separate people or a full matrix for a routine decision already covered by confirmed authority.
 
-| Role | How to spot them | What they need from you |
-|------|-----------------|------------------------|
-| **Sponsor** | Signed the SOW, owns the budget, asks "are we on track" | Progress in their units (cost saved, risk retired), never technical detail |
-| **Champion** | Wants you to succeed, opens doors, warns you about politics | Early wins they can point to - makes them look right for backing you |
-| **Gatekeeper** | Controls access: repos, environments, meetings, introductions | Respect for their process; go around them and they close every door |
-| **Resistor** | Sceptical, protective, or threatened - not necessarily wrong | To be heard first; resistors who feel consulted become the strongest allies |
-| **Ghost** | Named on the project, never in the room - either checked out or operating above you | Find out which. A checked-out ghost is noise. A ghost operating above you is the real decision-maker. |
+A sponsor naming an operating team is a proposal until that team accepts responsibility. If accounts conflict, record both attributed positions and the unresolved decision; ask the applicable authority to resolve it. Do not choose an owner from seniority, authorship, repository access or silence. Continue authorized work that does not depend on the disputed right.
 
-**2. Track signal, not sentiment.** A stakeholder's signal is what they *do*, not what they say:
+**2. Understand participation.** Identify the sponsor, people helping the work, access/process owners, people raising concerns, and required participants not yet consulted. One person may fill several roles; none must exist merely to complete a taxonomy. Capture their stated concerns and useful knowledge. Opposition may identify a real defect or unaccepted obligation. Being absent does not prove hidden authority or disengagement.
 
-| Signal | Evidence (not vibes) |
-|--------|---------------------|
-| **Green** | Responds same-day, shares context unprompted, introduces you to their people |
-| **Amber** | Response time doubles, defers decisions, "let me check with…" when they used to decide alone |
-| **Red** | Stops responding, routes around you, a new person you've never met starts asking questions |
+**3. Track observable changes.** Compare communication and decisions with the agreed cadence and the person's usual pattern. A delayed reply, shortened meeting or new participant may merit a check; holidays, workload, delegation and scheduling are alternative explanations to escalation. Record the observation separately from any hypothesis. Use green/amber/red only when supported by attributed evidence and its effect on the work; do not derive motives or authority from a color.
 
-**3. The 48-hour rule.** A stakeholder who goes amber has roughly 48 hours before they go red. A stakeholder who goes red is already escalating above you. Respond same-day to amber signals - not with more delivery, with a conversation.
+Choose follow-up timing from the decision deadline and potential impact. An imminent release with a missing owner warrants prompt resolution; an ordinary delayed reply does not have an automatic 48-hour escalation clock. Offer a neutral question such as “Has anything changed in the decision or timing we should account for?” Messages and outreach still require authorization.
 
-**3b. One name per person.** If the table says "Denise Chen" and Signal history says "Denise" or "D. Chen", trust keys fork and prep lies. Consolidate to one spelling. `fde doctor` flags these identity clusters - treat that as a fix, not a nit.
+**4. Learn from the existing team.** Ask what they tried, what constraints remain and what they expect to own. Use established terminology and credit actual contributions. Do not assume the team was passed over, resents outside help, or knows every cause. Verify consequential technical claims through the relevant evidence.
 
-**4. Detect the invisible escalation.** Three markers:
-- Questions shift from "what are you building" to "when will it be done" - someone above is asking.
-- A meeting gets shortened or cancelled - they're meeting without you.
-- A new stakeholder appears with no introduction - they were sent to check.
+**5. Prepare the decision conversation.** For a decision involving several parties, identify unresolved questions, relevant decision rights and needed evidence. Address dependencies in a useful order through existing channels. Record stated objections faithfully; label any possible motivation as an unverified hypothesis only when it matters to the next action. A short pre-mortem can ask “What missing evidence or unresolved responsibility could prevent this decision?” It must not invent an opponent or predict agreement.
 
-When you see any of these: tell the FDE immediately, recommend a proactive conversation with the sponsor before the invisible meeting becomes visible.
+**6. Keep identities consistent.** Use one confirmed spelling per person across the table and contact records. `fde doctor` can flag possible identity clusters; verify that they are the same person before consolidating. Do not erase historical evidence to tidy the display.
 
-**5. The passed-over team - the most dangerous and most valuable stakeholder.**
-
-In every engagement where an external FDE was brought in, an internal team was passed over. They know the codebase better than you, they know the politics better than you, and they resent your presence. Three moves:
-
-- **Ask what they tried.** Before your first standup. Their previous approach is the real requirements doc.
-- **Use their language.** In every meeting. They hear their words coming back and they feel consulted, not replaced.
-- **Make them look right.** Credit their prior work in your artifacts. They protect you if they feel respected; they wait for your mistake if they don't.
-
-**6. Before a decision meeting: pre-wire, then pre-mortem.**
-
-A recommendation that needs several people to say yes is not won in the room; it is won in the week before it. When the FDE is heading into a go/no-go, a budget ask, or anything that visibly costs someone territory:
+## Artifact
 
-- **Sort by position, not by seniority.** Firm supporter / firm opponent / **swing**. Effort goes almost entirely to swings - supporters need reinforcement, not persuasion, and a firm opponent is rarely moved by a louder version of the argument that already failed.
-- **Name what each swing is protecting.** The objection voiced in a meeting is usually a proxy: headcount, budget, credibility, control, or the reporting line that gets messier. Write the underlying motivation next to the stated objection - they are different sentences.
-- **Sequence the conversations.** Whoever makes the others easier to win goes first; whoever is reassured by seeing names already on board goes last. One-on-one for anyone who would lose face conceding in a group.
-- **Pre-mortem the meeting.** "It's Thursday, the meeting went badly - who sank it, and with what sentence?" That sentence is the pre-wire you are missing. If the answer is a specific person's objection, their conversation happens *before* the room convenes, not in it.
+Return the relevant decision rights directly, or update the existing `stakeholders.md` under the confirmed record rules. Link an existing authoritative record instead of duplicating its full contents.
 
-Log the sequence and the pre-mortem sentence in `context.md` as the plan for the week - a pre-wire plan that lives only in the FDE's head is not a plan.
+```markdown
+| Decision / responsibility | Person or mechanism | Scope | Source | Status / next action |
+|---------------------------|---------------------|-------|--------|----------------------|
+| <relevant decision> | <confirmed person/mechanism or unknown> | <system, environment, limit> | <actual agreement/policy/reference> | <confirmed / proposed / disputed / unknown; next step> |
+```
 
-## Artifact
+Keep a compact participation/signal table where it helps:
 
-**`stakeholders.md`** - updated with evidence-dated signal changes:
 ```markdown
 | Who | Role | Signal | Last evidence | Notes |
 |-----|------|--------|---------------|-------|
-| <name> | sponsor | green | responded same-day with budget approval (Jun 12) | owns renewal decision |
-| <name> | resistor→champion | amber→green | shared API docs unprompted after we used their naming (Jun 14) | was passed-over lead |
+| <name> | <observed role> | <supported signal or unknown> | <source and date> | <stated concern / unresolved question> |
 ```
 
-Signal changes get a dated evidence note. A signal that moved without evidence logged is a guess, not radar.
+Preserve the existing `## Signal history` section and its dated `[signal:...]` entries. CLI status, receipts and dashboard read that history; changing the display table alone does not update those signals. Use the existing confirmed contact/debrief workflow for signal changes. Never delete or overwrite history while refreshing the tables.
 
 ## Checkpoint
 
-One line per stakeholder who changed signal this week. If nobody changed: "Map stable - next check <date>." If a ghost appeared or a resistor went quiet: name it, recommend the move, and update `context.md` with the action.
+State the decision that can proceed under confirmed authority and any dependent action still blocked by an unknown or disputed right. Include material observed changes and the next evidence or conversation needed. If nothing relevant changed, reuse the map; no calendar interval alone requires a new review.
 
 ## Worked example
 
-Acme, week 6. Priya's replies have gone from same-day to two days, and a phase-2 go/no-go is scheduled for Thursday.
-
-Two signals, not one feeling: response time doubled *and* a finance analyst nobody introduced started asking when the work completes. That combination is an invisible escalation - someone above Priya is asking, and the meeting is already happening without the FDE.
-
-Positions: Priya is a supporter under pressure. Marco is a supporter who does not vote. Denise (finance) is the swing, and what she is protecting is not the budget line she cites - it is that her team's escalation started this and she has nothing to show her own director. Raj is a firm opponent on the rewrite question, and no amount of the same argument moves him.
+A sponsor requests release on Thursday and names Platform as operator. The Platform lead says the team has not accepted on-call responsibility. The sponsor's slower replies and a new finance participant are observed, but their cause is unknown.
 
-Sequence: Denise one-on-one Tuesday with the incident numbers in her units, then Priya Wednesday, so Priya walks in already knowing finance is not going to object. Pre-mortem sentence: *"Denise says 'we still don't know if this actually caught anything'"* - which is precisely why Tuesday exists. `stakeholders.md` records `Priya | sponsor | green→amber | reply latency 1d → 2d, unintroduced analyst (Jul 3)`; `context.md` carries the sequence.
+Return the map as a draft; when bound and confirmed, save it in `stakeholders.md` and the next action in `context.md`. Record the sponsor's request and Platform's objection with their sources. Existing policy confirms who approves production releases; it does not establish that Platform accepted recovery duties. The release authority row cites that policy; the operating responsibility row remains disputed. Acceptance and data-policy rights are checked only to the extent required by this change, reusing existing evidence. Prepare verification and the release receipt while the responsible parties resolve coverage. Do not infer escalation, assign Platform by title, or turn the sponsor's deadline into deployment permission.
 
 ## Principles
 
-- Signals are evidence-based, not feeling-based. "Seemed distant" doesn't move a signal; "stopped responding to three messages" does.
-- The 48-hour rule: amber is a same-day response, not a next-week note.
-- The passed-over team is your most important relationship. Win them first.
-- Every engagement has a ghost. Find them before they find you.
-- A stakeholder map that hasn't been updated in two weeks is fiction.
+- Resolve scoped authority from evidence; influence is not delegation.
+- Separate observed behavior, stated concerns and possible explanations.
+- Ownership requires applicable agreement, not an unchallenged name in a table.
+- Reuse confirmed decisions and scale follow-up to impact.
+- Preserve attributed history and unknowns; never fabricate agreement.

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

@@ -4,6 +4,6 @@
   "files": {
     "SKILL.md": "f8666990f8b4463af5f29acdb1d1cd5e8fec68119b82a891aa2322a213f37344",
     "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

package/skills/feedback/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/handoff/.fde-generated.json

@@ -5,6 +5,6 @@
     "SKILL.md": "9f08605914670f2c0bd09631d3d40c079e7f63174d1a2607e60ea6eca5d54d93",
     "references/close.md": "095266722624e4bc647628243c8be0e69b02017ef6b4e3a7e7790ec1f53ab7c0",
     "references/encode-pattern.md": "3be7bf9d0f69af31659423c54d6023a4af1556e2ce200fb025bf64d0757de4d8",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

package/skills/handoff/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/ingest/.fde-generated.json

@@ -0,0 +1,12 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "4df02c561ea8d2baf66ac373d67527c8826b72d80bf7b1fedc248c45a572adf9",
+    "references/connect.md": "37ad703ece7fe3596be4d5d3697cc4ba5e6062615f9576733c20d055fc3e4927",
+    "references/debrief.md": "2d2db9a177f5341a9a2721a9d6ea32a6d07e7e982e621429ca408a38bc5617c1",
+    "references/ingest.md": "24880bc3d95cda09ec6c2f5edebd17fba99deb912f93e15c8b715a287283da84",
+    "references/source-setup.md": "a28ae7c6dbb2573a66f31b30b7abca34bc52573fe34d48fff4c7490e4dc85d3e",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}