fdeops 5.1.0 → 5.1.1

package/skills/fde/SKILL.md

@@ -7,7 +7,7 @@ description: Keeps the engagement record for client work. Use when they name a c
 
 ## Purpose
 
-The **engagement record** for one client, from first meeting to signed outcome. One coordinator; six stages (land → close), with task skills that also work independently. Same methods on greenfield or brownfield engagements. Route from the request; never make the user choose a phase. Confirm, then write `.fde/`. The workspace still compiles and commits. `@fde` does not leave.
+Coordinate customer work from the first brief through implementation, verification and handoff. Select the relevant task instructions; never make the user choose a phase. Work directly on a standalone request, or maintain a confirmed `.fde/` record for an ongoing engagement. Reuse the customer’s tools, decisions and operating process.
 
 ## Task entry
 
@@ -17,22 +17,22 @@ Read `references/task-context.md` first. An explicitly selected task skill (such
 
 - They named a client, pasted notes, or asked what was agreed
 - The brief feels wrong, a sponsor went quiet, or Friday needs the ledger
-- Unbound - ask the name once, then **you** run `fde resume --init`
+- For ongoing client work without a binding, use the supplied name or ask once, then **you** run `fde resume --init`. A standalone request does not enter this setup path.
 
 ## When NOT to use
 
-A one-line typo or compile error in a file that will not ship. On a bound client: stay here for POC, characterisation, the change on their repo, eval, go-live, rollback, and acceptance.
+Ordinary code edits in an unbound repository do not automatically trigger the coordinator. If the user explicitly asks `@fde` for a standalone task, follow Task entry without creating records. On a bound client, use the relevant task for POC, characterization, implementation, evaluation, release or handoff.
 
 ## Use these first
 
 | What's happening | Sentence to say | You run | Then read |
 |---------|-----------------|---------|-----------|
 | **The brief is wrong** | "If this works, who in their company would have to agree that it worked?" | Current entry packet (see Entry below), then discover | `references/discover.md` |
-| **They went quiet** | "Is this a process gap, or a trust problem?" | `fde log contact "…" --signal amber\|red\|green` | `references/rescue.md` |
+| **They went quiet** | "What changed, and what do we know about why?" | Review supplied evidence; confirm any signal update before `fde log contact "…" --signal amber\|red\|green` | `references/rescue.md` |
 | **When did we agree?** | Don't argue from memory. Search the record. | `fde receipts <term>` | - |
 | **What's the outcome?** | A number nobody signed is claimed, not delivered. | `fde status` | `references/readout.md` |
 
-After a meeting: the agent runs `fde debrief --smart`, interprets and reconciles the sanitized proposal, then validates it with `fde debrief --review`. Show the human one concise review of consequential changes and uncertainties → **Save this update?** → `--apply` only after confirmation → verify the saved facts. See `references/debrief.md` for the shared preparation contract. Walk-in: `fde prep`. Friday: `fde status`.
+For a bound engagement update after a meeting: the agent runs `fde debrief --smart`, interprets and reconciles the sanitized proposal, then validates it with `fde debrief --review`. Show the human one concise review of consequential changes and uncertainties → **Save this update?** → `--apply` only after confirmation → verify the saved facts. For standalone meeting analysis, use the review-only path in `references/debrief.md` without CLI setup or saving. Walk-in: `fde prep`. Friday: `fde status`.
 
 ## Ground loop
 
@@ -56,20 +56,22 @@ Use `references/build.md` for implementation, `references/integrate.md` for cust
 
 **FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual task skill directly.
 
-**You (agent):** run the CLI. **Never tell the FDE to type** `fde …`. If unbound, you run `fde resume --init` after one question. Never ask them to run the CLI.
+**You (agent):** run the CLI when the task needs real records. **Never tell the FDE to type** `fde …`. For ongoing work without a binding, use the supplied client name or ask once, then run `fde resume --init`. Never ask them to run the CLI. Standalone drafts and code tasks skip initialization, preferences and record reads.
 
 Fallbacks: `node ~/.claude/fdeops/fde.js …`, then `npx --yes fdeops …`. Skill-only install is not "unavailable."
 
 ## First-use preferences
 
-Run `fde setup --show` before client reads. If unavailable, update the CLI before offering setup. If `configured` is false, bind the named client, then run `fde setup` and present its three questions together: how they work, what would help first, and what to mask. Save their explicit answers; never infer permission to share data. For custom masking, the optional fourth question asks them to enter terms **locally** with `fde setup`, or give a local terms-file path. Do not ask them to paste sensitive names into chat or open that file with model-facing file tools. Pass the path directly to `--terms-file`; inspect only the returned count, never `.preferences.json` or the alias dictionary. If they skip, keep existing defaults.
+For ongoing record-backed work, run `fde setup --show` before client reads. Skip this section for standalone work. If unavailable, use the permitted CLI fallback before offering setup; if none is available, continue from supplied excerpts without claiming record access. If `configured` is false, bind the named client, then run `fde setup` and present its three questions together: how they work, what would help first, and what to mask. Save their explicit answers; never infer permission to share data. For custom masking, the optional fourth question asks them to enter terms **locally** with `fde setup`, or give a local terms-file path. Do not ask them to paste sensitive names into chat or open that file with model-facing file tools. Pass the path directly to `--terms-file`; inspect only the returned count, never `.preferences.json` or the alias dictionary. If they skip, keep existing defaults.
 
 Use `work` to tailor the help: single = focus on the bound client; multiple = portfolio overview with one bound client per write; team = clarify responsibility and handoff, without implying shared storage. `start` chooses the initial route when no more specific request or record determines it: new → land, daily → triage, takeover → audit. Current client evidence and the user's request always take precedence; never restart an existing engagement because of this preference. `masking` selects standard patterns or those plus custom terms. Older technical settings remain valid; offer personal setup when requested rather than resetting them. Do not ask again per client. `fde setup --settings` keeps display, context size and report masking editable. Choices do not configure models or approve client data use.
 
 ## Entry (every session)
 
+This section applies to ongoing record-backed work only. For a standalone request, use Task entry and the selected method; do not run setup, resume or init merely because `@fde` was invoked.
+
 1. After the first-use setup check above, use one current `fde resume` packet (16 KiB by default, 4 KiB with compact setup; a byte ceiling, not a model token count). At each new user turn or task, run `fde resume` unless a fresh session-hook packet was supplied for that entry. Within this entry, reuse that hook packet or a packet from a CLI call made during the current turn/task only if its `ENGAGEMENT:` identity is visible, matches the current client binding, and freshness is certain. Never reuse a packet carried over from an earlier user turn or task: external edits may have changed the record. If the packet is absent, its identity or freshness is uncertain, the binding or engagement state changed since it was loaded (including your own writes or setup/masking changes), or the user asks for a refresh or “where are we,” run `fde resume` before using the context. Do not repeat an immediate entry call solely because the skill, an adapter, or a slash command was loaded. Read client constraints first, then signer, goals, risks, delivery ledger and current context; never substitute a recursive read of `.fde/` or raw transcripts. If truncated or a decision needs evidence, run `fde recall <specific topic>`; narrow the query rather than loading the whole history. `--max-bytes 4096` reduces the allowance for smaller models. `--full` only when the complete log is explicitly needed.
-2. **NO ENGAGEMENT:** ask "What should we call this client?" then **you** init. Pasted notes → debrief after bind.
+2. **NO ENGAGEMENT, ongoing work:** use the supplied client name, or ask "What should we call this client?" then **you** init. Pasted notes for that ongoing record → debrief after bind. Notes requested only for review stay standalone.
 3. Playback 2-3 lines. `hygiene:` → offer `fde doctor`; **never auto-rewrite**.
 4. Route. Read **one** `references/*.md`. Confirm, then write.
 
@@ -79,12 +81,12 @@ Writes need a bind (`FDEOPS_ENGAGEMENT` or registry). Never install fdeops on in
 |----------|---------|
 | where are we | `fde resume` |
 | day-1 look at the repo | `fde scan` |
-| debrief / pasted notes | `fde debrief --smart` → agent reconciliation → one plain-English review → Save this update? → `--apply`. `--smart` is a gate, not a brain. `references/debrief.md` |
+| debrief / pasted notes for a bound record | `fde debrief --smart` → agent reconciliation → one plain-English review → Save this update? → `--apply`. `--smart` is a gate, not a brain. `references/debrief.md` |
 | prep me for … | `fde prep "<label>"` |
 | when did we agree | `fde receipts <term>` |
 | sponsor update / defend the number | `fde defend` |
 | successor / rotation / portable handoff | `fde handoff` (stdout; `--out new-file.md` only after export requested) |
-| they went quiet | `fde log contact "…" --signal amber\|green\|red` |
+| they went quiet | Review evidence with `references/rescue.md`; confirm a signal change before `fde log contact "…" --signal amber\|green\|red` |
 | fieldbook page | `fde dashboard` (`--all` portfolio, `--open` to open the file) |
 | clean up the fieldbook | `fde doctor` - never auto-rewrite |
 | scrub a secret | `fde redact <term>` then `--apply` after confirm |
@@ -98,7 +100,7 @@ Writes need a bind (`FDEOPS_ENGAGEMENT` or registry). Never install fdeops on in
 2. **Deliverable plus memory.** Deliver the requested code, evidence or decision artifact. On a bound engagement, record the confirmed result in the file named by the method. A standalone artifact does not require a `.fde/` folder.
 3. **Evidence.** Without a supplied source, a decision or measurement remains CLAIM. Use `[source: meeting YYYY-MM-DD]`, a PR/URL, transcript ID, or artifact path. The automatic log date is not attribution. ON RECORD means a source was supplied, not that it was authenticated or the customer approved. Never invent a source, signer, or acceptance.
 4. **No invented facts.** People, quotes, meetings, numbers: they said it or the repo shows it. Else `unknown - ask: <question>`.
-5. **Session digest** (end of session and before a PR) - thinking, not the chat. Confirm, then write. Never a transcript dump.
+5. **Bound-engagement session digest** (end of session and before a PR) - relevant conclusions, not the chat. Confirm, then write. Standalone tasks return their requested result without a record digest. Never a transcript dump.
 
    | Digest beat | Lands in |
    |-------------|----------|
@@ -183,7 +185,7 @@ Work names (engage, diagnose, align, deliver, realize, transfer) are the same ma
 |----------|-------|-----------|
 | Realize, weekly update due, "need to send the sponsor something", report the outcome | readout | `references/readout.md` |
 | Demo coming up, show-and-tell, exec walkthrough, prepare the demo | demo-prep | `references/demo-prep.md` |
-| Just out of a meeting, raw notes, "they said…", "debrief", user interviews, workshop notes, capture the meeting | debrief | the debrief verb (above) + `references/debrief.md` |
+| Just out of a meeting, raw notes, "they said…", "debrief", user interviews, workshop notes, capture the meeting | debrief | `references/debrief.md`; review-only for standalone notes, CLI review/apply for a bound record |
 | Make sure we're up to date, pull what's relevant, fetch from Granola/Slack/Gmail/transcript | ingest | `references/ingest.md` (capability check → stage → propose → confirm → apply) |
 | Connect a new MCP / connect Granola Slack or Notion / what can you pull | connect | `references/connect.md` (+ `references/source-setup.md`) |
 | Prep me for a meeting / walk-in brief / "what should I know before I talk to…" | - | run `fde prep "<label>"`, present in plain language |
@@ -229,4 +231,4 @@ Ready to build: check that the supplied facts establish the outcome, constraints
 
 ## Identifier masking
 
-Before reading engagement content in a session, run `fde privacy` to verify runtime support. If the command is unavailable, stop and update the CLI; a new skill alone does not upgrade an older executable. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.
+Before reading stored engagement content, run `fde privacy` to verify runtime support. If unavailable, stop record access and use the permitted CLI fallback; a new skill alone does not upgrade an older executable. A standalone task using supplied permitted context does not need the CLI. If no executable is available, continue useful work from supplied excerpts and report the record-access limitation. Use CLI context and previews for model input. They mask common email, phone, SSN-shaped, and credential patterns by default; aliases remain consistent within the local engagements root. Preserve complete alias tokens when drafting updates; the CLI resolves them locally. Never read the private `.privacy/` dictionary, sealed sidecars, raw sensitive notes, or local dashboard/vault files to recover an identity. Custom masking additionally hides the literal names or terms the user supplied locally, ignoring letter case and matching whole terms. It does not infer variants or discover names. Names, company names, addresses, and unrecognized formats are otherwise not automatically detected: keep sensitive prose in `<private>` blocks. Direct file tools, pasted chat, and upstream source MCPs bypass this boundary.

package/skills/fde/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/fde/references/earn-trust.md

@@ -2,52 +2,39 @@
 
 **Enter when:** new engagement where you don't have full access yet, trust is thin, the customer said "let's start small," or you need to navigate "we don't trust AI-generated code."
 
-**Read first:** `trust-profile.md`, `stakeholders.md`, `context.md`. The trust profile tells you where the walls are; the stakeholder map tells you who built them.
+**Read first:** apply [task context](task-context.md), then retrieve permitted trust constraints, stakeholder evidence and current context. Never read raw private blocks.
 
-Trust is the currency of FDE work. Code quality gets you a second week; trust gets you the engagement. It's earned in small, visible moves - never demanded, never assumed, and never recovered once burned.
+Build confidence through useful work, clear evidence and respect for the customer's process. Relationship confidence and access permissions are separate: a strong relationship does not grant production authority.
 
 ## Method (you do this work)
 
-**1. The trust ladder - every engagement climbs it in order:**
+**1. Establish the access needed now.** Identify the next task, the minimum relevant access, and its actual policy or authorization source. Read-only access, reviewed PRs, branch writes and deployment rights can be granted independently. Reuse permissions already granted for the same scope; do not impose a ladder or ask the customer to re-earn established access. Record missing or disputed rights and continue work that does not depend on them.
 
-```
-Level 0: Observer     → read-only access, watching
-Level 1: Advisor      → recommendations, no code changes
-Level 2: Contributor  → PRs reviewed by their team
-Level 3: Committer    → direct push to feature branches
-Level 4: Owner        → production access, deploy authority
-Level 5: Trusted      → they call you before making decisions
-```
-
-**Never skip a level.** The FDE who asks for production access on day two gets observer access for a month. The FDE who ships a clean PR on day two gets committer access by week two. Each level is earned by demonstrating competence AND respect at the current level.
+**2. Make progress visible.** Choose useful actions for the engagement's stage and agreed cadence:
 
-**2. The first-week trust plays - specific, not generic:**
-
-| Day | Move | Why it works |
-|-----|------|-------------|
-| 1 | Fix a small, visible, annoying bug - something the team has been stepping over (only after `success.md` has a signer, or the FDE overrides with the unknown still visible) | Proves you can ship in their environment without breaking things |
-| 1 | Ask the passed-over team what naming conventions they use - then use them | Shows respect before competence |
-| 2 | Send a one-paragraph status to the sponsor without being asked | Sets the pattern: they hear from you before they have to ask |
-| 3 | Find a genuine risk and flag it without drama | Demonstrates you're protecting them, not performing |
-| 5 | Show a small win to the champion so they can share it upward | Gives them evidence their bet on you was right |
+- Deliver a small verified result within scope, or clarify a consequential unknown when implementation is premature. A quick win does not bypass release gates.
+- Ask the existing team about conventions and prior attempts; credit their contributions without assuming they were passed over.
+- Prepare a concise status update using the agreed channel and audience. Send only within existing communication authority.
+- Flag a supported risk and its consequence without exaggerating urgency.
+- Show results the intended users can evaluate, distinguishing demonstrated behavior from reported satisfaction.
 
 **3. Navigate "we don't trust AI-generated code":**
 
 This is increasingly common. The right response is respect, not persuasion:
 
 - **Ask the policy, don't assume.** "Does your organisation have a position on AI-assisted code in production?"
-- **If prohibited:** work without AI on their code. Use fdeops for engagement memory (`.fde/` files) and your own planning - that's your tooling, not theirs.
+- **If prohibited:** do not load or work on their code with the model. Engagement notes and planning may also contain restricted data; use FDEOps on them only when that use is permitted. Continue with generic or explicitly permitted material, and identify what must be handled outside the AI workflow.
 - **If permitted with review:** every AI-touched line goes through their normal review process. Flag it: "AI-assisted, human-reviewed" in commit messages if they want traceability.
-- **If grey area:** treat as prohibited until someone with authority says otherwise. The cost of asking is zero; the cost of guessing wrong is the engagement.
-- **Never hide it.** An FDE caught using prohibited AI tools loses the engagement and the reputation. Full stop.
+- **If grey area:** treat as prohibited until someone with authority says otherwise. Clarify only the policy needed for the next action and continue work on already permitted material.
+- **Never hide it.** Disclose AI involvement according to the agreed policy; do not represent prohibited use as ordinary local tooling.
 
 **4. Trust recovery - when you've made a mistake:**
 
 Mistakes happen. What matters is speed and honesty:
 
-- **Own it in the first hour.** Not "we found an issue" - "I introduced this bug." Passive voice erodes trust faster than the mistake.
+- **Report promptly under the incident process.** State the known impact and your confirmed contribution. Do not assign yourself or another person a cause before evidence supports it.
 - **Show the fix AND the prevention.** "Here's what happened, here's the fix, here's the test that prevents it next time."
-- **One visible win within 48 hours.** Trust recovery needs a concrete success close to the mistake - not weeks later.
+- **Agree a recovery checkpoint.** Use a verified corrective result and a realistic next update; do not promise a win within an arbitrary window.
 - **Never minimise.** "It was a small bug" is your assessment, not theirs. Let them size it.
 
 **5. The trust account - deposits and withdrawals:**
@@ -65,36 +52,30 @@ Mistakes happen. What matters is speed and honesty:
 
 **`trust-profile.md`** - updated sections:
 ```markdown
-## Trust level
-Current: <level 0-5> as of <date>
-Evidence: <what earned this level>
-Next target: <level> - requires: <specific action>
+## Access and working agreement
+Current: <permitted task, system/environment and limits>
+Source: <actual authorization/policy and date>
+Next need: <access gap or none; responsible decision-maker if known>
 
 ## AI policy
 Status: <prohibited / permitted-with-review / grey-area-treating-as-prohibited>
 Source: <who confirmed, when>
 ```
 
-**`decisions.md`** - log trust-significant moves: "Flagged migration risk to ops lead before they discovered it (Day 3) - trust deposit."
+**`decisions.md`** - record consequential confirmed agreements with their sources. A risk raised is an observed action; increased trust is not established unless supported by the customer's response.
 
 ## Checkpoint
 
-One question to the FDE: "Are we at the right trust level for what we need to do next week?" If not: name the gap, name the move, and put it in `context.md` as the next action.
-
-## The week 2-4 valley
+Check whether the next task has the required access and agreement. Reuse current evidence; if a material gap remains, name the applicable decision and next action.
 
-Week 1 is the honeymoon - everyone's excited, access is fresh, the brief is new. Weeks 2-4 are the valley: novelty wears off, real problems surface, the sponsor's patience shifts from "take your time" to "when do we see results." Most engagements silently fail here, not at ship.
+## Keep expectations current
 
-Counter it:
-- Ship one visible artifact per week, even if discovery isn't done. A terrain map, a risk register, a stakeholder signal update - something the sponsor can point to.
-- Proactive status update at end of week 2 - explicitly name what discovery revealed that wasn't in the brief. This resets expectations with evidence.
-- If still in discovery at week 3: the conversation with the sponsor about scope or timeline reset is overdue. Don't wait for them to ask.
+At the agreed checkpoints, explain what changed, what has been demonstrated and what remains uncertain. If discovery invalidates the expected scope or timeline, surface the evidence when it affects the next decision. A long discovery phase may be appropriate for the work; week numbers alone do not establish impatience or failure.
 
 ## Principles
 
-- Trust is earned in small moves, lost in one. Never skip the ladder.
-- The first-week plays are specific and deliberate - not "be helpful."
-- AI policy: ask, never assume. Prohibited until confirmed.
-- Mistakes happen; hiding them doesn't. Own it in the first hour.
-- The FDE who makes the internal team look right earns trust faster than the FDE who ships the most code.
-- Weeks 2-4 are where engagements silently die. Ship visible artifacts weekly to survive the valley.
+- Earn confidence through observable work; permissions come from applicable authority.
+- Use the customer's conventions and credit actual contributions.
+- AI policy applies to the data and use, including engagement memory.
+- Report mistakes promptly, distinguish known causes from hypotheses, and verify recovery.
+- Choose updates and follow-up timing from impact and the agreed cadence.

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

@@ -2,7 +2,7 @@
 
 **Enter when:** new customer, first meeting, just got the brief, nothing started yet.
 
-**Read first:** `context.md` if it exists, then the supplied brief. Once the engagement type and AI/access policy are known, inspect the supplied repo/docs relevant to the ask before asking questions they can answer. This is a bounded evidence check, not a full discovery scan.
+**Read first:** apply [task context](task-context.md), then permitted `context.md` evidence if it exists and the supplied brief. Once the engagement type and AI/access policy are known, inspect the supplied repo/docs relevant to the ask before asking questions they can answer. This is a bounded evidence check, not a full discovery scan.
 
 ## Validation gate (confirm understanding, clarify where it elevates)
 
@@ -26,27 +26,27 @@ Format - one question at a time, with a guess the FDE can correct:
 
 ```
 READ: <one sentence - what you think they actually need>
-CONFIDENCE: ~NN% - missing: <what still blocks a safe start>
+MISSING: <fact or authority that changes the next action>
 Q: <one focused question>
-GUESS: <your best answer, so they can push back fast>
+POSSIBLE READ: <clearly labeled interpretation, if useful; never guessed authority>
 ```
 
-Wait for the reaction before the next question. Stop when confidence is high enough to write `success.md` without inventing names, or when the FDE says move on. Every answer that is still unknown stays `unknown - ask:` in the artifact - never fill the gap with a plausible stakeholder.
+Wait for the reaction before the next question. Stop when the next authorized action is clear, or when the FDE says move on; unanswered material gaps remain visible. Every answer that is still unknown stays `unknown - ask:` in the artifact - never fill the gap with a plausible stakeholder.
 
 ## Method - part 1: interrogate the brief (you do this work)
 
 Read the brief the FDE gives you. Separate **observed** (source/path and date), **reported** (who said it), and **hypothesis** (how to test it). A requested solution such as “build an agent” is not evidence of the cause. Ask only about gaps that change scope, access, acceptance, or the next investigation. What is **not** in the brief matters as much as what is. Produce the gap list yourself:
 
-- **No named decision-maker** → the FDE will spend two weeks building for someone who can't say yes. Flag it.
-- **"Straightforward cleanup" on an 8-year-old system** → the previous attempt is still visible in git history as a revert. Flag it.
-- **Very tight timeline** → someone already promised the outcome before hiring the FDE. Flag it.
-- **No out-of-scope section** → scope creep is pre-authorized. Flag it.
+- **No named decision-maker** → identify who or what can accept the outcome and the source of that authority; keep it unknown until established.
+- **"Straightforward cleanup" on an 8-year-old system** → inspect permitted relevant history and tests for prior attempts and constraints; age alone proves neither complexity nor a previous failure.
+- **Very tight timeline** → establish the deadline, its source and which commitments are actually agreed.
+- **No out-of-scope section** → clarify material boundaries against the existing agreement. An omission does not authorize additional work.
 
 Write these into `brief.md` as **questions to answer**, not problems - they're what the FDE is walking in to resolve.
 
 Pre-arrival checks to run through with the FDE:
-- Access confirmed? Repo, environment, docs. Waiting for access on day two burns trust.
-- Has someone tried this before? Find out why it failed before assuming this approach is different.
+- Access confirmed for the next task? Repo, environment and docs may have different permissions; identify gaps before dependent work.
+- Has someone tried this before? Establish what happened and what evidence remains; do not assume the attempt failed.
 - Other vendors/teams in scope? Then the FDE is not the only one in the room, even when alone in the meeting.
 - Tech stack recon: job postings, GitHub org - know the stack before they say it.
 
@@ -59,21 +59,21 @@ Intent: coach the FDE's first *customer* conversation - what keeps the sponsor u
 - "Who loses credibility if this goes wrong?"
 - "If nothing changes over the agreed timeframe, what happens, and who bears it?" Record the consequence and its source in `brief.md`; distinguish reported impact from measured cost. Unknown cost stays unknown, not an invented ROI.
 
-Let silence sit. If their fear doesn't match the written brief, the brief is wrong - say so plainly, log it.
+Allow time for an answer. If a stated concern differs from the brief, record the difference and clarify whether it changes the agreed outcome; neither statement automatically supersedes the other.
 
 **Listen for, and capture as you hear it:**
-- **The real decision-maker** - whoever others mention most, especially if not yet met. That's who judges the work.
-- **The previous attempt** - "we tried something similar last year" is the most important sentence in the first meeting. Who was involved? Still there and protective, or gone because of it?
-- **The passed-over internal team** - they know exactly what's wrong, and they resent the FDE's presence. Find them before the first standup, ask what they tried, use their language in every meeting. Make them look right and they protect you; ignore them and they wait for the mistake.
-- **The sacred thing** - "Is there anything in this environment I should treat as untouchable?" The hesitation before the answer is the answer.
+- **Decision rights** - who can approve scope, accept the result and authorize release, as relevant. A frequently mentioned person may be influential; confirm their actual authority and scope.
+- **The previous attempt** - "we tried something similar last year" identifies evidence to investigate. Who was involved, what happened, and which constraints still apply? Do not infer why someone left.
+- **The existing internal team** - ask what they tried, what they know and what they expect to own. Use established terminology and credit their work. Do not assume resentment, displacement or complete knowledge of the problem.
+- **The sacred thing** - "Is there anything in this environment I should treat as untouchable?" Capture the stated boundary and applicable policy; hesitation alone does not identify a restriction.
 - **Exception path (operating map seed)** - "When the happy path breaks this week, what do people actually do - who do they call, what spreadsheet opens, what do they skip?" Capture the break → workaround → who owns it. Do not build a full map on day 1; seed rows later in `terrain.md` → `## Operating map (exception-led)` during discover. Unknowns stay `unknown - ask:`.
 - **AI posture and policy** - tools already in use (sanctioned or shadow), and: "Does your organisation have a policy on AI-generated code? Are there decisions where you would not be comfortable with AI involvement?"
 - **Future operator** - "Who will run this after we leave, and have they agreed?" Record the proposed operator and unresolved ownership in `success.md`, separately from the signer. A sponsor naming a team is not that team accepting responsibility; verify with the operator during discover.
 - **Boundaries in multi-vendor rooms** - who owns what surface, who signs off before a change crosses it.
 
-## The day 1 deliverable
+## An early deliverable
 
-After `success.md` names a signer (or the FDE explicitly overrides with `unknown - ask:` still visible), ship one visible thing before the end of day 1: a small bug fix, a cleanup the team has stepped over, a dashboard tweak, a config improvement. Not because it matters technically - because it proves you can ship in their environment without breaking things. The first deploy sets the trust trajectory for the entire engagement. A day-1 deliverable earns more credibility than a week-3 architecture deck. Skip it until the land gate is met.
+Choose an early useful result within confirmed scope: a verified small fix, a permitted diagnostic, or a concise map of an unresolved problem. Reuse the existing outcome and authority for routine work. A first-day deadline does not grant deployment permission or waive verification; use `ship` for a release. If a missing signer blocks a consequential decision, keep it visible and continue independent preparation.
 
 ## Artifact (write as the conversation is debriefed)
 
@@ -81,7 +81,7 @@ After `success.md` names a signer (or the FDE explicitly overrides with `unknown
 
 **`success.md`** - what done looks like, **primary value bucket** (`cost-save` | `risk-mitigation` | `revenue-uplift`), baseline → target, who actually signs off, what is explicitly out of scope. Record agreement only with its source and scope; otherwise label the target proposed. For each baseline, record source, date/window, environment, and sample size when relevant. An operator recollection is reported, not measured. If no baseline exists, name the measurement owner and cheapest way to obtain it; do not manufacture a number.
 
-For every target number, run the **gaming check** before it is written down: *how could this metric hit its target without the customer being any better off?* There is always an answer, and the answer is what the org will drift toward under pressure. Write the guard next to the metric:
+For every target number, run the **gaming check** before it is written down: *how could this metric hit its target without the customer being any better off?* Identify plausible failure modes without predicting that the customer will exploit them. Write a relevant guard next to the metric:
 
 ```markdown
 | Metric | Baseline → target | Gamed by | Guard |
@@ -89,19 +89,19 @@ For every target number, run the **gaming check** before it is written down: *ho
 | reconciliation alert latency | 4h → 15min | alerting on everything, so nobody reads them | alerts acked by a named owner, ≤2/week |
 ```
 
-A metric with no gaming check is a metric the FDE will be held to and cannot defend. If the customer resists the guard, that is the real conversation - they are attached to the number, not the outcome.
+If a proposed guard is disputed, capture the stated reason and assess its cost and effect on the outcome. Do not infer that the customer values the number over the result.
 
 **`stakeholders.md`**:
 ```markdown
 | Who | Role | Signal | Notes |
 |-----|------|--------|-------|
-| <name> | sponsor / champion / resistor / veto / passed-over | green/amber/red | <evidence, day> |
+| <name> | <observed participation role; authority recorded separately> | green/amber/red | <evidence, day> |
 ```
 If `stakeholders.md` already has a `## Signal history` section (it does from the template), **never delete or overwrite it** when you rewrite this file - it holds the dated `[signal:...]` tokens `fde log contact --signal` and `fde debrief` write, and `fde status`/`fde receipts`/the dashboard read only from that section. Edit the table above it freely; keep the section below intact.
 
 **`trust-profile.md`** - sacred data (`<private>` tagged), fears heard, AI policy, approval chain. Sensitive: skip for status reads; use CLI/redacted surfaces; never paste raw `<private>` into prompts or subagents.
 
-**`assumptions.md`** - seed every unverified claim from the brief (and the day-1 hypothesis) as rows with Kind `UNKNOWN` (or `CONVENTION` if they said "we always"), blast radius CRITICAL / LOAD-BEARING / CONVENIENCE, and status `OPEN`. Do not wait for test-assumptions - land makes the register exist. Example:
+**`assumptions.md`** - seed consequential unverified claims from the brief (and the initial hypothesis) as rows with Kind `UNKNOWN` (or `CONVENTION` if they said "we always"), blast radius CRITICAL / LOAD-BEARING / CONVENIENCE, and status `OPEN`. Do not wait for test-assumptions - land makes the register exist. Example:
 
 ```markdown
 | # | Assumption | Kind | Blast radius | How we test | Status | Evidence |
@@ -113,7 +113,7 @@ One falsifiable hypothesis about the real problem also goes at the bottom of `br
 
 ## Checkpoint
 
-One page back to the FDE: success + value bucket + sign-off owner, out-of-scope boundary, sacred data, stakeholder map with veto power, AI posture, the hypothesis, the top CRITICAL assumptions still OPEN, and any exception-path seeds heard (break → workaround → owner) for discover to map into `terrain.md`. If it doesn't fit one page, the engagement isn't understood yet.
+One page back to the FDE: success + value bucket + sign-off owner, out-of-scope boundary, sacred data, stakeholder map with veto power, AI posture, the hypothesis, the top CRITICAL assumptions still OPEN, and any exception-path seeds heard (break → workaround → owner) for discover to map into `terrain.md`. Keep the summary short and link necessary detail; a complex engagement may need supporting evidence.
 
 If remote: agree how progress and blockers will be shared; use a short call when asynchronous context is insufficient.
 
@@ -121,16 +121,16 @@ If remote: agree how progress and blockers will be shared; use a short call when
 
 Kickoff at Acme payments. Priya (VP Eng) sponsors; the brief says "add monitoring to the reconciliation service."
 
-Asking what happens the week after a perfect delivery gets: "I stop hearing about it from finance." That is the real success statement - not monitoring. The previous attempt surfaces too: the platform team built alerting last year, it was turned off. Raj, who built it, is still there and was not in the kickoff - the passed-over team, found on day 1 rather than at the first standup.
+Asking what happens the week after a perfect delivery gets: "I stop hearing about it from finance." That suggests a concern to clarify alongside the monitoring request. The previous attempt surfaces too: the platform team built alerting last year, it was turned off. Raj, who built it, is still there and was not in the kickoff. Ask for his account of the earlier attempt; his absence does not explain his views.
 
-What gets written: `success.md` with bucket `risk-mitigation`, `reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)`, gaming check `alerting on everything so nobody reads them` → guard `≤2 alerts/week, acked by name`, sign-off Priya. `brief.md` carries the gap list and the hypothesis: *the job is not unmonitored, it is unowned*. `assumptions.md` seeds `"finance would act on an alert" - CRITICAL - OPEN - (stated, unverified)`. `trust-profile.md` records the sacred thing Priya hesitated before naming.
+In this example Priya reports a four-hour baseline and proposes the following target; her acceptance authority still needs its source. What gets written: `success.md` with proposed bucket `risk-mitigation`, `reconciliation failures reach a named owner within 15 min (baseline: 4h, found by finance)`, gaming check `alerting on everything so nobody reads them` → guard `≤2 alerts/week, acked by name`, proposed sign-off Priya until confirmed. `brief.md` carries the gap list and the hypothesis: *the job is not unmonitored, it is unowned*. `assumptions.md` seeds `"finance would act on an alert" - CRITICAL - OPEN - (stated, unverified)`. `trust-profile.md` records the boundary Priya explicitly names, through the permitted privacy-safe workflow.
 
-Day-1 deliverable: fix the log line that swallows the job's exit code. Small, visible, in their environment.
+Early deliverable: verify and fix the log line that swallows the job's exit code within the existing scope. Deployment remains subject to the established release authority and checks.
 
 ## Principles
 
-- Never start technical work before `success.md` exists.
+- Establish the outcome and authority needed for the next action; missing record files do not block useful standalone work.
 - Sacred data tagged `<private>` stays out of model context: use CLI/redacted reads; never paste raw private blocks.
-- The brief is a hypothesis; discover confirms it. Seed `assumptions.md` on day one.
-- The passed-over internal team is the best source of truth, not an obstacle.
+- Treat unverified parts of the brief as hypotheses; discovery may support or overturn them. Record consequential assumptions.
+- Learn from the existing team and verify consequential claims without guessing motives.
 - If the customer cannot define success, that is the first problem to solve.