fdeops 5.1.0 → 5.1.1

package/skills/review/references/integrate.md

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

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

@@ -3,7 +3,7 @@
   "version": 1,
   "files": {
     "SKILL.md": "13640b029f34068b08f2b0532ad7d2bae2d1063eeff17ec85a840bfbf832311e",
-    "references/hold-scope.md": "42b3823f6b49b87b432f81208b0a61115f22340f6a922a4e858012e908c6643d",
+    "references/hold-scope.md": "7779188df1d7f5aef9f878719499f9c0e974deba45289329ae8fa3d62e6c5090",
     "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

package/skills/scope/references/hold-scope.md

@@ -6,51 +6,52 @@
 
 **Read first:** `success.md` (the agreed boundary), `decisions.md`, `context.md`. Load `stakeholders.md` to know who's asking and their signal.
 
-Scope creep is the leading cause of FDE engagement failure - not technical complexity, not timeline pressure. It's silent: no single request feels unreasonable, but twenty reasonable requests add three months. The skill is saying "that's phase two" without the customer hearing "no."
+Small requests can accumulate into material changes to cost, timing or acceptance. Compare the request with the actual agreement before classifying it; an adjacent request may already be in scope, and a clarification is not automatically an addition.
 
 ## Method (you do this work)
 
-**1. Detect before it compounds.** Three patterns that signal creep before it's named:
+**1. Detect before it compounds.** Patterns worth checking against the agreement:
 
-| Pattern | What it sounds like | What's actually happening |
+| Pattern | What it sounds like | What to check |
 |---------|--------------------|--------------------------|
-| **The friendly addition** | "While you're in there, could you also…" | Adjacent work getting absorbed without timeline adjustment |
-| **The evolved requirement** | "Oh, what I actually meant was…" | The original scope was never clear enough - `success.md` needs updating |
-| **The stakeholder swap** | A new person starts requesting features the original sponsor didn't | Power shifted; the real scope is being rewritten informally |
+| **The friendly addition** | "While you're in there, could you also…" | Whether the work is already covered and what it changes |
+| **The evolved requirement** | "Oh, what I actually meant was…" | Whether this clarifies existing acceptance or proposes a change |
+| **The stakeholder swap** | A new person starts requesting features the original sponsor didn't | The requester's authority and whether the request changes the agreed outcome |
 
-**2. The scope receipt.** Every request gets logged with its origin and cost - not as bureaucracy, but as evidence for the conversation that's coming:
+**2. The scope receipt.** Record consequential proposed changes and cumulative impact in the existing task or engagement record. Routine clarifications within confirmed scope can share a concise update; do not add a separate ceremony for each request. Distinguish estimates from measured effort and proposals from decisions:
 
 ```markdown
 ## Scope change - <date>
 Requested by: <who>
 Request: <what, in their words>
-Impact: <hours/days added, what gets pushed>
-Status: absorbed / deferred to phase 2 / needs conversation
+Impact: <estimate with assumptions, or unknown; affected work/risk/acceptance>
+Authority: <applicable agreement/decision source or unknown>
+Status: proposed / confirmed in scope / agreed change / deferred / declined / disputed
 ```
 
-Log via `fde log decision "scope change: <summary> - requested by <who>, impact: <estimate>"` or direct append to `decisions.md`.
+Show consequential judgments and uncertainties for confirmation before saving unless already explicitly confirmed. Use the existing task or `decisions.md` workflow; label an unapproved request as proposed rather than logging it as an agreed scope change.
 
-**3. The three-bucket response.** Never say "no" - say "here's where it fits":
+**3. Recommend a disposition.** Explain the fit and tradeoffs; use the relevant authority for any change:
 
 | Bucket | What you say | When to use |
 |--------|-------------|-------------|
-| **This phase** | "That fits - I'll add it to the current plan. Timeline stays the same." | The request is small and genuinely within the agreed scope |
-| **Next phase** | "That's real - let me capture it properly so it doesn't get lost. It's phase-two work because <reason>." | The request is valid but adds to the timeline |
-| **Separate engagement** | "That's a different problem - it deserves its own brief and its own timeline." | The request is a new project wearing a small-ask costume |
+| **This phase** | "That is covered by the current agreement. Here is its impact on the plan." | The request is within confirmed scope and authority; do not promise unchanged timing without evidence |
+| **Next phase** | "This adds <impact>. I recommend deferring it or agreeing a tradeoff." | The request changes current commitments; a future phase is proposed, not promised |
+| **Separate engagement** | "That's a different problem - it deserves its own brief and its own timeline." | The request requires a materially different outcome, access or commercial agreement |
 
-**The key phrase: "Let me place it."** Not "that's out of scope" (adversarial) or "sure" (absorbed). "Let me place it" signals you're taking it seriously while buying time to assess the real cost.
+Decline a request clearly when it conflicts with policy or the applicable authority rejects it. No wording can substitute for a real scope decision.
 
 **4. The accumulation conversation.** When the scope receipts show a pattern - a material cumulative impact on delivery, cost, risk, or acceptance - the FDE needs a conversation with the sponsor:
 
 Frame it as **protection, not complaint:**
 > "We've absorbed five changes since the original agreement. Each one made sense individually. Together, they've added roughly two weeks. I want to make sure the timeline expectation still matches - should we adjust the delivery date, or reprioritise to keep the original date?"
 
-Evidence-based: point to `decisions.md` scope receipts with dates and requesters. The sponsor who sees the pattern is an ally; the sponsor who discovers the delay at the end is a problem.
+Evidence-based: point to `decisions.md` scope receipts with dates and requesters. Use the actual scope decision-maker; sponsorship alone does not establish delegated authority.
 
 **5. The commercial boundary.** In paid engagements, scope creep silently moves billing and liability:
 
 - If the engagement is time-and-materials: scope creep is the client's money, but flag it - they deserve to know what they're buying.
-- If the engagement is fixed-price: every absorbed scope change is a gift the FDE's company didn't agree to. Surface it to whoever owns the commercials.
+- If the engagement is fixed-price: check the change terms and contingency; material changes may affect margin or commitments. Surface the evidence to whoever owns the commercials.
 - If the engagement has a success fee: scope changes that move the success criteria affect compensation. Log it.
 
 ## Artifact
@@ -69,15 +70,15 @@ Acme, week 5. Nothing has been formally added, and the slice is a week late.
 
 The pattern shows in three requests: a "quick" finance CSV export (Jun 20, half a day, from Denise directly), retry-logic cleanup asked for mid-build (Jun 24, one day, Tom), and a dashboard tile "while you're in there" (Jun 27, half a day). Each sounds reasonable; their cumulative estimates explain part of the slip and need a scope decision.
 
-Three-bucket response, applied while the requests can still be placed: the CSV export fits this phase only with an accepted trade (it displaces the runbook polish), the retry cleanup goes to the kill list in `decisions.md` with the what-breaks reason, and the tile is absorbed because it is genuinely twenty minutes - logged anyway, since an unlogged absorption is the one that gets forgotten in the accumulation conversation.
+Three-bucket response, applied while the requests can still be placed: the CSV export fits this phase only with an accepted trade (it displaces the runbook polish), the retry cleanup goes to the kill list in `decisions.md` with the what-breaks reason, and the tile is absorbed because it is genuinely twenty minutes - included in the existing progress receipt so cumulative impact remains visible.
 
-That conversation happens with Priya when the added work threatens the date, with the receipts on screen: "here are the asks, their estimated impact, and what moved." Not a complaint - a decision she gets to make, with evidence, before the deadline makes it for her.
+That conversation happens with Priya when the added work threatens the date, with the receipts on screen: "here are the asks, their estimated impact, and what moved." Confirm Priya holds the relevant scope authority before treating her response as agreement.
 
 ## Principles
 
-- "Let me place it" is the phrase. Not "no," not "sure."
-- Every scope change gets a receipt. The receipt is the evidence.
+- Compare requests with the agreement before classifying them.
+- Record consequential changes with their source, authority and status; batch routine work.
 - Escalate material impact, not an arbitrary count of requests.
-- Scope creep kills engagements that technical failure couldn't.
-- `success.md` is a contract - update it explicitly or defend it.
-- The FDE who absorbs everything is liked for three weeks and blamed for three months.
+- Missing boundaries do not grant permission to expand scope.
+- `success.md` records agreed scope; it does not replace the governing agreement.
+- Make tradeoffs visible without inventing motives, approval or future commitments.

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

@@ -3,10 +3,10 @@
   "version": 1,
   "files": {
     "SKILL.md": "3ed6862aac292e971af7c0a7f5a68968b89b056be60f3cdc883f51534984c1fc",
-    "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/ship/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/ship/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/who-decides/.fde-generated.json

@@ -4,6 +4,6 @@
   "files": {
     "SKILL.md": "33a822a1e10824461543e296f93e07ed3f8e2eab7a719bcde4bb3bbef597859c",
     "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
-    "references/who-decides.md": "56c577f0984cb69cfb18349fc9194e92dba2b56ead9a527d5e6e887c1219717f"
+    "references/who-decides.md": "fa1f65d921943e76f42284570004a603488905417d96b4bd52dc6c4a11dd5a97"
   }
 }

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