fdeops 5.1.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/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/integrate/.fde-generated.json

@@ -3,10 +3,10 @@
   "version": 1,
   "files": {
     "SKILL.md": "ea74e65eff6b189e1e2fb00c3553192116ccc475785eb82bfaee49819610dfd4",
-    "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",

package/skills/integrate/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/integrate/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/poc/.fde-generated.json

@@ -4,12 +4,12 @@
   "files": {
     "SKILL.md": "bceae7ba11c006b3d1e93e330a80cc58eeef55d863cc374653eef8fd124c3056",
     "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
-    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/build.md": "6fa07b15b682119de53c38950f94942a58e4680ab58b24319d77c54a27cd9697",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
     "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
     "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
-    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/integrate.md": "d0de35a783902ca8b4762e3a42a14f467766d56a928c3a5cf11adac2a6ba90ba",
     "references/plan.md": "a86e42f4c35897d48e863b7b00e287c14fe835fc034b729bacadc0401fe4ff45",
     "references/poc.md": "818dc90c2d401819735233ab9d69df171675d75abf8644c403dab7dd1dcf9199",
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",

package/skills/poc/references/build.md

@@ -6,7 +6,7 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Method
 
-1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Preserve unrelated edits and state which dependencies or interfaces the change touches.
+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/poc/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/.fde-generated.json

@@ -3,10 +3,10 @@
   "version": 1,
   "files": {
     "SKILL.md": "65b965474e847f240138c1ada0ee7d982affc421a24a0a7a37970021f8269a03",
-    "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",

package/skills/qa/references/build.md

@@ -6,7 +6,7 @@ Use the permitted context and authority in [task context](task-context.md). This
 
 ## Method
 
-1. Identify the repository, its instructions, working tree, relevant callers, and test commands. Inspect examples before creating abstractions. Preserve unrelated edits and state which dependencies or interfaces the change touches.
+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/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/rescue/.fde-generated.json

@@ -3,7 +3,7 @@
   "version": 1,
   "files": {
     "SKILL.md": "e13cfaec04aa082ba5f253fd62ea70f6ad559a54b0d0f19351d1322e291e91b3",
-    "references/rescue.md": "57cb27e691bffdcee962e6ed37a96e9ff3b1caa976eb8e9170adae70530ea50a",
+    "references/rescue.md": "3af07633b82dc1022bafc86173f6c55da81501317e25c9ac8980cfcb04b27df3",
     "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

package/skills/rescue/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/review/.fde-generated.json

@@ -3,10 +3,10 @@
   "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",

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.