fdeops 5.1.0 → 5.1.1

package/README.md

@@ -34,7 +34,7 @@ Help me prepare for the first meeting. Here is the brief: …
 
 `fde` asks for the information needed next and uses the relevant instructions. As work progresses, it can help you investigate delays, compare approaches, implement a change, test it, and prepare a customer update. You do not have to choose a skill at each step.
 
-Naming the customer starts a local project record at `~/fde-engagements/client01/.fde/`. It keeps the brief, decisions, evidence and next actions together. Review proposed agreements and corrections before saving them. [How customer records work](#keep-a-customer-record).
+For an ongoing project, naming the customer starts a local record at `~/fde-engagements/client01/.fde/`. It keeps the brief, decisions, evidence and next actions together. Review proposed agreements and corrections before saving them. [How customer records work](#keep-a-customer-record).
 
 ### Use just one task
 
@@ -77,7 +77,7 @@ Use the skill that matches the work in front of you. All skills are individually
 
 These examples are starting points, not a required sequence. The catalog also covers inherited projects, business cases, incidents, recovery, source connections and multiple customer records. `fde` uses the same instructions and loads additional detail only when needed.
 
-**Which mode should I choose?** Use an individual skill for a specific task. Use `fde` when you want help across several tasks and a continuing customer record. Installing a skill makes it available independently; it does not remove its real input requirements. For example, `dashboard` needs records to display, while `debrief` can review pasted notes without saving anything.
+**Which mode should I choose?** Use an individual skill for a specific task. Use `fde` when you want help selecting the next task or maintaining a continuing customer record. You can also ask it for a one-off result without creating records. Installing a skill makes it available independently; it does not remove its real input requirements. For example, `dashboard` needs records to display, while `debrief` can review pasted notes without saving anything.
 
 <a name="how-skills-work"></a>
 
@@ -125,7 +125,13 @@ Open a customer's record and copy an action into your agent to continue. Run the
 
 ## Fit it to the project
 
-For a small task, use the supplied notes or code and return the result. For an ongoing project, use the customer record. For enterprise work, include the relevant teams, access rules, release checks and operating responsibilities in the plan.
+Start with the work in front of you:
+
+| Project | How to use FDEOps |
+|---|---|
+| Small fix or analysis | Give a task skill the relevant notes or code. Get the result and its verification; no customer record is required. |
+| Customer integration or ongoing delivery | Use `fde` to connect discovery, implementation, tests and updates in one continuing record. |
+| Enterprise engagement | Work within the customer’s existing access, change-control and operating processes. Record who can approve each decision and what evidence they require. |
 
 The pack includes implementation, integration, debugging and QA instructions. It uses the repository's existing tools. It does not supply customer credentials, infrastructure, specialist approvals or production authority.
 

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.0",
+  "version": "5.1.1",
   "private": true,
   "description": "Thin stdio MCP sink for FDEOps ingest (stage \u2192 propose \u2192 apply). Zero runtime dependencies.",
   "bin": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops",
-  "version": "5.1.0",
+  "version": "5.1.1",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "bin": {
     "fdeops": "bin/install.js",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "fdeops",
-  "version": "5.1.0",
+  "version": "5.1.1",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "author": {
     "name": "Subash Natarajan",

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

@@ -3,7 +3,7 @@
   "version": 1,
   "files": {
     "SKILL.md": "6ccada100587e370639f468328795839c15a063b7ada4ed2f31794ba9e6c1c4c",
-    "references/land.md": "be633eefbfdb202638f4a04ba2f1320ef69a5af33f7aa685a3c7d95aa5d5c6f9",
+    "references/land.md": "7a82ac999d23b51b602cd815777a853c4879ca8be40dc6c84c66f154d1f77951",
     "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

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

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

@@ -3,10 +3,10 @@
   "version": 1,
   "files": {
     "SKILL.md": "19f32ecae72b96ee19cb87658ddd998cce96ec2e3960255d13fcc2906c6d0b6b",
-    "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/build/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/build/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/debug/.fde-generated.json

@@ -3,10 +3,10 @@
   "version": 1,
   "files": {
     "SKILL.md": "7862670d5c023f0195e0b3fa8b52a3b33796813e53aaad083ae82a9a469e0faa",
-    "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/debug/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/debug/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/earn-trust/.fde-generated.json

@@ -3,7 +3,7 @@
   "version": 1,
   "files": {
     "SKILL.md": "c4152a7ee98027f810c3ab11403dea75dee5aae26da24f84de34630c1fd529b6",
-    "references/earn-trust.md": "a3dc4b44686066fbc94fafa4b2fac3c5120d7940256898cec31279f565b912bb",
+    "references/earn-trust.md": "89df253665d996e28bc7acf785346c50f3062115ffd70fb7ad3300c99eb36ead",
     "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

package/skills/earn-trust/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/evaluate/.fde-generated.json

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