fdeops 5.1.9 → 5.1.10

package/README.md

@@ -52,8 +52,13 @@ Separate decisions, requests and open questions. Return a draft only.
 
 No customer record is needed for this draft. Each task includes its required instructions; you do not need to install `fde` or another pack.
 
+<details>
+<summary>Installation requirements and alternatives</summary>
+
 These installation commands use Node.js and Git; the optional record CLI requires Node.js 18+. See [installation and upgrades](docs/install.md) for host-specific invocation, the full pack and alternatives. Installing `fde` includes all underlying instructions, but does not add the 35 separate task names to your agent's menu.
 
+</details>
+
 **Try it with fictional data:** `npx fdeops demo` runs sample notes through review and creates a fieldbook without calling an AI model. It requires Node.js 18+ and Git, may download the package, and creates or resets only its separate `.demo` workspace. [Five-minute walkthrough](docs/USAGE.md#new-here-5-minutes).
 
 ## Three things it helps with
@@ -67,6 +72,15 @@ A repository tells you where the code lives. It may not tell you why the custome
 
 For an ongoing engagement, FDEOps keeps a separate plain-Markdown record at `~/fde-engagements/<customer>/.fde/`. The coordinator retrieves a bounded summary and looks up details when needed. A saved implementation checkpoint points back to the current task record; the agent checks it before continuing.
 
+For example, the fictional demo's `fde resume` output includes these next actions (excerpt):
+
+```text
+next: get the reconciliation runbook from Tom before touching anything. [source: meeting 2026-09-10]
+do first: Ask the acceptance owner to review the reported result and its evidence (delivery.md: 1 reported result awaiting acceptance)
+```
+
+The next session can pick up the work while keeping acceptance pending.
+
 Use [debrief](skills/debrief/SKILL.md) after a meeting and [switch-clients](skills/switch-clients/SKILL.md) when changing customers. [How records work](docs/USAGE.md).
 
 ### 2. Keeping a request from becoming an agreement
@@ -94,6 +108,16 @@ This is a draft, not a saved agreement. Use [who-decides](skills/who-decides/SKI
 
 A local test, a deployed change and a customer-accepted result answer different questions.
 
+| Claim | Evidence it needs |
+|---|---|
+| Implemented | The change exists in the identified revision |
+| Verified | Applicable checks passed under stated conditions |
+| Deployed | The intended environment is running the change |
+| Measured | A result was observed against the agreed measure |
+| Accepted | The agreed owner or mechanism accepted the outcome |
+
+These are separate claims, not five automatic dashboard states.
+
 FDEOps carries the agreed checks into implementation and binds verification to the relevant revision and environment. Release guidance asks for operating limits, recovery evidence and an owner. Missing access or evidence stays visible; a passing local test does not fill that gap.
 
 Use [build](skills/build/SKILL.md), [integrate](skills/integrate/SKILL.md), [review](skills/review/SKILL.md), [ship](skills/ship/SKILL.md) and [handoff](skills/handoff/SKILL.md) as needed. [See the tests and their limits](docs/verification.md).

package/adapters/AGENTS.md

@@ -16,7 +16,7 @@ Do **not** load `@fde` for a one-line typo in an unbound repo. On a bound client
 
 Read and write engagement files under the workspace's bound engagement: follow the skill’s entry rule to resolve it (binding created once with `fde resume --init <name>`; default `~/fde-engagements/<name>/.fde/`). `FDEOPS_ENGAGEMENT` (expand `~`) overrides when set. Use `./.fde/` only when the engagement approves it and it is gitignored.
 
-Follow **First-use preferences** and **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
+Follow **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
 
 ## Voice
 

package/adapters/GEMINI.md

@@ -16,7 +16,7 @@ Do **not** load `@fde` for a one-line typo in an unbound repo. On a bound client
 
 Read and write engagement files under the workspace's bound engagement: follow the skill’s entry rule to resolve it (binding created once with `fde resume --init <name>`; default `~/fde-engagements/<name>/.fde/`). `FDEOPS_ENGAGEMENT` (expand `~`) overrides when set. Use `./.fde/` only when the engagement approves it and it is gitignored.
 
-Follow **First-use preferences** and **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
+Follow **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
 
 ## Voice
 

package/adapters/LOCAL-LLM.md

@@ -7,7 +7,7 @@ The FDEOps CLI and offline dashboard need Node.js and Git, not a model. AI-assis
 1. Download FDEOps, your agent host and your model while online. After that, the CLI operates offline. Model/provider configuration belongs to the host; FDEOps does not start or configure an inference server.
 2. From the client workspace, run `node /path/to/fdeops/bin/fde.js resume --init my-client` to create and bind a local record.
 3. Make `skills/fde/SKILL.md` and its references available to the host. Use the host's documented skill/file mechanism. Give it the FDEOps CLI path and permission to read the bound record and execute the requested commands.
-4. Follow **First-use preferences** and **Entry (every session)** in `skills/fde/SKILL.md`, then ask for the next action. Inspect the tool calls, cited records and any proposed writes before trusting the workflow.
+4. Follow **Entry (every session)** in `skills/fde/SKILL.md`, then ask for the next action. Inspect the tool calls, cited records and any proposed writes before trusting the workflow.
 
 Use `fde recall <topic>` for relevant evidence. `resume` and `recall` default to a 16 KiB output ceiling; `--max-bytes 4096` requests a smaller allowance. This limits FDEOps output, not the host's entire context window. Keep unrelated transcripts and tools out of the active context. Private blocks must stay out of direct file reads as well as prompts.
 

package/adapters/README.md

@@ -13,7 +13,7 @@
 | Gemini CLI | `GEMINI.md` | `GEMINI.md` |
 | Cursor | `.cursor/rules/fde.mdc` | `cursor.fde.mdc` |
 | GitHub Copilot | `.github/copilot-instructions.md` | `copilot-instructions.md` |
-| Local LLMs (Ollama, LM Studio, llama.cpp, vLLM) | Load `SKILL.md` as system prompt | [`LOCAL-LLM.md`](LOCAL-LLM.md) (guide) |
+| Local LLMs (Ollama, LM Studio, llama.cpp, vLLM) | Capable agent host with `SKILL.md`, its references, and approved CLI access | [`LOCAL-LLM.md`](LOCAL-LLM.md) (guide) |
 
 `AGENTS.md` is the emerging cross-tool standard - many agents read it, so it doubles as the universal fallback. For local/self-hosted models, see [`LOCAL-LLM.md`](LOCAL-LLM.md).
 
@@ -31,4 +31,4 @@ Defaults to the current directory if no path is given. Existing files are never
 
 ## The principle
 
-The adapter only tells the tool **where the brain is and how to behave**. All 30 skills, the overlays, and the memory contract live once in `skills/fde/SKILL.md`. Update the brain, every platform gets it. That's why fdeops feels native in whatever the FDE already uses, without five things to keep in sync.
+The adapter only tells the tool **where the brain is and how to behave**. The 35 task methods and supporting guidance live in `skills/fde/references/`; `skills/fde/SKILL.md` coordinates them and the memory contract. Update the brain, every platform gets it. That's why fdeops feels native in whatever the FDE already uses, without five things to keep in sync.

package/adapters/copilot-instructions.md

@@ -16,7 +16,7 @@ Do **not** load `@fde` for a one-line typo in an unbound repo. On a bound client
 
 Read and write engagement files under the workspace's bound engagement: follow the skill’s entry rule to resolve it (binding created once with `fde resume --init <name>`; default `~/fde-engagements/<name>/.fde/`). `FDEOPS_ENGAGEMENT` (expand `~`) overrides when set. Use `./.fde/` only when the engagement approves it and it is gitignored.
 
-Follow **First-use preferences** and **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
+Follow **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. Use the CLI for deterministic work - `fde scan | log | receipts | status | dashboard` - instead of improvising shell.
 
 ## Voice
 

package/adapters/cursor.fde.mdc

@@ -21,7 +21,7 @@ Do **not** load `@fde` for a one-line typo in an unbound repo. On a bound client
 
 Read and write engagement files under the workspace's bound engagement: follow the skill’s entry rule to resolve it (binding created once with `fde resume --init <name>`; default `~/fde-engagements/<name>/.fde/`). `FDEOPS_ENGAGEMENT` (expand `~`) overrides when set. Use `./.fde/` only when the engagement approves it and it is gitignored.
 
-Follow **First-use preferences** and **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. The entry packet includes TRIAGE; use it for trust, phase, open risks and next action. Do not invent stakeholders or status.
+Follow **Entry (every session)** in `skills/fde/SKILL.md` for setup, context reuse and refresh. The entry packet includes TRIAGE; use it for trust, phase, open risks and next action. Do not invent stakeholders or status.
 
 You run the CLI for deterministic work - `fde scan | log | debrief | prep | doctor | receipts | status | dashboard` - instead of improvising shell or handing commands to the human.
 

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "5.1.9",
+  "version": "5.1.10",
   "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.9",
+  "version": "5.1.10",
   "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.9",
+  "version": "5.1.10",
   "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/fde/references/switch-clients.md

@@ -1,114 +1,53 @@
 # switch-clients - Switch engagements
 
-**Enter when:** the FDE is running 2+ engagements simultaneously, context-switching is causing mistakes or delays, a new customer is being onboarded while existing engagements are active, or the FDE says "I'm losing track."
+Switch customers without losing the next action or carrying one customer's information into another's work.
 
-**Read first:** Run `fde status --all` for the portfolio view. Then per engagement: `context.md` only - load deeper files only for the engagement being worked on.
+**Use when:** moving between existing engagements, reviewing competing customer needs, or recovering from confused customer context.
 
-The solo FDE running three customers simultaneously is the norm, not the exception. Without a system, the third customer gets the scraps of attention left after the other two have their crises. Multi-customer ops is the discipline of giving each customer the experience of being your only customer.
+Apply [task context](task-context.md). This task needs existing records; do not invent or initialise a customer merely to complete a portfolio view. Check `fde privacy` before record access, then use `fde status --all` for the permitted portfolio summary. Do not read raw `.fde/` files.
 
-## Method (you do this work)
+## Decide what needs attention
 
-**1. The hard boundary: one `.fde/` per customer, always.**
+Use the available evidence to compare customer impact, safety or security incidents, contractual deadlines, blocked work and agreed commitments. A trust signal is a prompt to examine its source, not a fixed countdown or an automatic priority over an incident. A delayed reply does not establish lost trust.
 
-```
-~/fde-engagements/
-  garvey-payments/.fde/    ← Garvey's engagement memory
-  kesterman-freight/.fde/  ← Kesterman's engagement memory
-  rennick-health/.fde/     ← Rennick's engagement memory
-```
+Keep portfolio summaries brief and authorised. Inspect deeper context only for the customer being worked on, through a sanitized `fde resume` packet and targeted `fde recall`. If there is not enough capacity for the competing commitments, name the conflict and the decision-maker who can change priorities. Do not silently deprioritise another customer.
 
-**Never:**
-- Merge two customers' data into one folder
-- Reference one customer's code/data in another's context
-- Load two customers' `.fde/` folders in the same session
-- Copy patterns between customers without stripping identifying information
+## Leave the current engagement recoverable
 
-Cross-contamination is the fastest way to lose two engagements at once.
+Identify what changed, what remains uncertain and the next action. For unfinished implementation, use the existing [recoverable checkpoint](verification.md#recoverable-checkpoint), with its task ID, working-tree state and applicable evidence.
 
-**2. The daily triage.** Every morning, before opening any editor:
+Follow the record's confirmation and CLI write rules. An unconfirmed checkpoint stays a draft; switching customers does not approve it. Keep every update in the current customer's record. Do not automatically commit, stash, discard or move working-tree changes. Preserve them under the repository's policy and the user's existing authority.
 
-```markdown
-## Daily triage - <date>
+## Select the next customer explicitly
 
-| Customer | Trust signal | Top risk | Today's action | Time budget |
-|----------|-------------|----------|---------------|-------------|
-| Garvey | green | Canary blocked on their security ticket | Chase ticket, prep ship checklist | 4h |
-| Kesterman | AMBER | Sponsor went quiet Tue | Proactive conversation TODAY | 2h |
-| Rennick | green | None active | Build slice 3, push PR | 2h |
+1. Identify the requested customer and the intended workspace. If either is ambiguous, resolve that before record access or changes.
+2. Inspect the binding with `fde resume --bind`. Merely opening another editor tab or running bare `fde resume` does not select a different customer.
+3. Confirm the target exists using permitted metadata. Prefer its already-bound workspace. For read-only work, a command-scoped `FDEOPS_ENGAGEMENT=<known-record-path>` selects that existing record without changing the workspace binding; use the same scope for each record command and report that the persistent binding is unchanged. `fde resume --init <existing-client>` can fill missing templates and initialise memory Git as well as bind the workspace. Use it only when those record changes are also authorised; a request to switch alone is not enough. Never guess a missing customer or silently change unrelated host settings.
+4. Get a fresh sanitized `fde resume` packet and verify its visible `ENGAGEMENT:` identity matches the intended customer. Stop on a mismatch; do not continue from the previous customer's packet.
+5. Resume the selected task from current evidence. Check actual repository state before relying on a saved implementation checkpoint. Keep the other customer's files and output out of subsequent tool reads and messages.
 
-Priority order: Kesterman (amber trust), Garvey (deadline), Rennick (steady)
-```
+Changing the binding does not erase earlier conversation context. Use a fresh agent session when the customer's isolation policy requires it or prior sensitive context should not remain available. Do not claim that closing tabs removes information already supplied to a model.
 
-**3. The triage rules.** In order of priority:
+## Communicate within the agreed boundaries
 
-| Priority | Rule | Why |
-|----------|------|-----|
-| **1** | Trust fires first | A green-trust engagement with a deadline can wait 4 hours. An amber-trust engagement cannot wait 4 hours - it's 48 hours from red. |
-| **2** | Deadlines second | Real deadlines (customer-facing, regulatory, contractual) outrank planned milestones. |
-| **3** | Highest-value delivery third | The engagement where today's work produces the most visible outcome. |
-| **4** | Steady-state last | Engagements on track with no urgent needs get allocated remaining time. |
+Use each customer's agreed audience, channel and cadence. Prepare an update when a commitment changes or a material risk needs a decision; send it only within existing communication authority. Explain the effect on that customer's work without disclosing another customer's identity, incident or confidential priorities.
 
-**4. Context-switch protocol.** When moving between customers:
+Reusing a field lesson across customers requires permission as well as removal of identifying and confidential information. Masking alone does not authorise reuse.
 
-```
-BEFORE LEAVING CUSTOMER A:
-  1. Write 3 lines to context.md: where we are, what changed, next step
-  2. Commit or stash any work in progress
-  3. Close all customer A files and browser tabs
+## Worked example
 
-BEFORE STARTING CUSTOMER B:
-  1. Run: fde resume (loads Customer B's engagement)
-  2. Read context.md - where did we leave off?
-  3. Confirm: what's the one thing to accomplish in this block?
-  4. Set a time boundary (e.g., "2 hours on Kesterman, then back to Garvey")
-```
+The FDE is leaving Garvey with an unfinished retry fix and switching to Kesterman. Garvey's `context.md` has a confirmed checkpoint pointing to the existing task and its unrun staging check. The FDE preserves the dirty working tree rather than committing or stashing it automatically. `fde resume --bind` still identifies Garvey, so bare resume would reopen the wrong record. After verifying that Kesterman already exists, the FDE selects its bound workspace or uses a command-scoped selection when record writes are prohibited, then obtains a fresh sanitized packet and checks `ENGAGEMENT:` before continuing. A temporary selection is reported as temporary, not as a changed workspace binding. Kesterman's sponsor has not replied, but the notes show planned leave; that alone does not justify an amber signal. An unconfirmed Garvey update stays a draft for Garvey and is never written into Kesterman's record.
 
-The 3-line context update is the bridge. Without it, the next session starts with "what was I doing?" - that's 20 minutes of re-discovery each time.
+## Completion
 
-**5. The communication cadence.** Each customer gets a rhythm:
+Return the selected customer, whether selection is temporary or persistent, binding evidence, next action, and any unsaved update or unresolved priority. A switch is complete only when the fresh packet identifies the intended customer and the previous work remains recoverable. Standalone portfolio review can return its summary without rebinding or saving anything.
 
-| Engagement intensity | Status cadence | Touchpoint type |
-|---------------------|---------------|-----------------|
-| Active build (daily work) | Weekly written + ad-hoc Slack | Status update + visible progress |
-| Light touch (2-3 days/week) | Weekly written | Status update + next week's plan |
-| Monitoring only | Bi-weekly written | Health check + any emerging risks |
-
-**The golden rule: no customer should have to chase you for an update.** Proactive status updates are cheaper than reactive ones - and they protect trust across all engagements.
-
-**6. Capacity management.** The honest conversation with yourself:
-
-| Situation | Action |
-|-----------|--------|
-| All engagements are steady | Allocate by value; reserve 20% for unplanned |
-| One engagement is on fire | Other engagements get a proactive heads-up: "Focus is on X this week; here's what's planned for you next week" |
-| Two engagements are on fire | Triage - one gets full attention, one gets stabilised, tell the sponsor of the stabilised one what's happening |
-| Three+ are on fire simultaneously | Escalate to your manager/team. Solo capacity is exceeded - communicate before quality drops |
-
-**7. The cross-contamination checklist.** Before every customer interaction:
-
-- [ ] Am I in the right `.fde/` folder?
-- [ ] Am I referencing the right customer's context?
-- [ ] Is the status update addressed to the right person?
-- [ ] Does my current context contain any data from another customer?
-- [ ] Are my browser tabs / code editors pointed at the right customer?
-
-One wrong customer name in a status update damages both relationships.
-
-## Artifact
-
-**`context.md`** (per customer) - the 3-line bridge updated at every context switch. The most-written file in multi-customer ops.
-
-**`fieldbook.html`** - regenerated by `fde dashboard --all` (deterministic, zero tokens) for the portfolio. Bare `fde dashboard` refreshes the bound `fieldbook-current.html`.
-
-## Checkpoint
-
-The daily triage is the checkpoint. One line per customer: signal, priority, today's action. If any customer hasn't been touched in 3+ business days: flag it - silence is noticed.
+For an authorised portfolio view, `fde dashboard --all` regenerates `fieldbook.html`; it does not change customer records. Neither the dashboard nor the agent's summary grants approval for a release or customer communication.
 
 ## Principles
 
-- One `.fde/` per customer. Never merge. Never cross-reference.
-- Trust fires outrank deadlines. A deadline can be renegotiated; trust can't.
-- Write the 3-line context bridge at every switch. 20 seconds saves 20 minutes.
-- No customer should have to chase for an update.
-- Two fires simultaneously is a triage decision. Three is an escalation.
-- The wrong customer name in a status update is a two-customer trust fire.
+- One customer's writes belong in that customer's record.
+- Use sanitized CLI packets; never substitute raw record reads.
+- Verify identity after a switch and preserve unfinished work without inventing authority.
+- Prioritise from impact and commitments, not unsupported trust timelines.
+- A fresh binding is not a fresh model context.

package/skills/switch-clients/.fde-generated.json

@@ -4,7 +4,8 @@
   "files": {
     "SKILL.md": "ebfebe6e5872800c749659aec45af48b2287db2e72c0b914118482e4c73334b5",
     "agents/openai.yaml": "67ecd37a1e5bd57986d800a782aeff8d00171d6d09794b6026d8daf1e2d91e6f",
-    "references/switch-clients.md": "4e8cb763db871b38fece3adaf9d1ac3b995c21dd1d0e463903eaa3854332c389",
-    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5"
+    "references/switch-clients.md": "4c13df4441182f6ef9455e0abed4facdb6d1c99dd5d10de278708f0bc07f631f",
+    "references/task-context.md": "9066514a50043f3ad888d133d4e8b89b7132551e098cf2c80203c458a80126e5",
+    "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/switch-clients/references/switch-clients.md

@@ -1,114 +1,53 @@
 # switch-clients - Switch engagements
 
-**Enter when:** the FDE is running 2+ engagements simultaneously, context-switching is causing mistakes or delays, a new customer is being onboarded while existing engagements are active, or the FDE says "I'm losing track."
+Switch customers without losing the next action or carrying one customer's information into another's work.
 
-**Read first:** Run `fde status --all` for the portfolio view. Then per engagement: `context.md` only - load deeper files only for the engagement being worked on.
+**Use when:** moving between existing engagements, reviewing competing customer needs, or recovering from confused customer context.
 
-The solo FDE running three customers simultaneously is the norm, not the exception. Without a system, the third customer gets the scraps of attention left after the other two have their crises. Multi-customer ops is the discipline of giving each customer the experience of being your only customer.
+Apply [task context](task-context.md). This task needs existing records; do not invent or initialise a customer merely to complete a portfolio view. Check `fde privacy` before record access, then use `fde status --all` for the permitted portfolio summary. Do not read raw `.fde/` files.
 
-## Method (you do this work)
+## Decide what needs attention
 
-**1. The hard boundary: one `.fde/` per customer, always.**
+Use the available evidence to compare customer impact, safety or security incidents, contractual deadlines, blocked work and agreed commitments. A trust signal is a prompt to examine its source, not a fixed countdown or an automatic priority over an incident. A delayed reply does not establish lost trust.
 
-```
-~/fde-engagements/
-  garvey-payments/.fde/    ← Garvey's engagement memory
-  kesterman-freight/.fde/  ← Kesterman's engagement memory
-  rennick-health/.fde/     ← Rennick's engagement memory
-```
+Keep portfolio summaries brief and authorised. Inspect deeper context only for the customer being worked on, through a sanitized `fde resume` packet and targeted `fde recall`. If there is not enough capacity for the competing commitments, name the conflict and the decision-maker who can change priorities. Do not silently deprioritise another customer.
 
-**Never:**
-- Merge two customers' data into one folder
-- Reference one customer's code/data in another's context
-- Load two customers' `.fde/` folders in the same session
-- Copy patterns between customers without stripping identifying information
+## Leave the current engagement recoverable
 
-Cross-contamination is the fastest way to lose two engagements at once.
+Identify what changed, what remains uncertain and the next action. For unfinished implementation, use the existing [recoverable checkpoint](verification.md#recoverable-checkpoint), with its task ID, working-tree state and applicable evidence.
 
-**2. The daily triage.** Every morning, before opening any editor:
+Follow the record's confirmation and CLI write rules. An unconfirmed checkpoint stays a draft; switching customers does not approve it. Keep every update in the current customer's record. Do not automatically commit, stash, discard or move working-tree changes. Preserve them under the repository's policy and the user's existing authority.
 
-```markdown
-## Daily triage - <date>
+## Select the next customer explicitly
 
-| Customer | Trust signal | Top risk | Today's action | Time budget |
-|----------|-------------|----------|---------------|-------------|
-| Garvey | green | Canary blocked on their security ticket | Chase ticket, prep ship checklist | 4h |
-| Kesterman | AMBER | Sponsor went quiet Tue | Proactive conversation TODAY | 2h |
-| Rennick | green | None active | Build slice 3, push PR | 2h |
+1. Identify the requested customer and the intended workspace. If either is ambiguous, resolve that before record access or changes.
+2. Inspect the binding with `fde resume --bind`. Merely opening another editor tab or running bare `fde resume` does not select a different customer.
+3. Confirm the target exists using permitted metadata. Prefer its already-bound workspace. For read-only work, a command-scoped `FDEOPS_ENGAGEMENT=<known-record-path>` selects that existing record without changing the workspace binding; use the same scope for each record command and report that the persistent binding is unchanged. `fde resume --init <existing-client>` can fill missing templates and initialise memory Git as well as bind the workspace. Use it only when those record changes are also authorised; a request to switch alone is not enough. Never guess a missing customer or silently change unrelated host settings.
+4. Get a fresh sanitized `fde resume` packet and verify its visible `ENGAGEMENT:` identity matches the intended customer. Stop on a mismatch; do not continue from the previous customer's packet.
+5. Resume the selected task from current evidence. Check actual repository state before relying on a saved implementation checkpoint. Keep the other customer's files and output out of subsequent tool reads and messages.
 
-Priority order: Kesterman (amber trust), Garvey (deadline), Rennick (steady)
-```
+Changing the binding does not erase earlier conversation context. Use a fresh agent session when the customer's isolation policy requires it or prior sensitive context should not remain available. Do not claim that closing tabs removes information already supplied to a model.
 
-**3. The triage rules.** In order of priority:
+## Communicate within the agreed boundaries
 
-| Priority | Rule | Why |
-|----------|------|-----|
-| **1** | Trust fires first | A green-trust engagement with a deadline can wait 4 hours. An amber-trust engagement cannot wait 4 hours - it's 48 hours from red. |
-| **2** | Deadlines second | Real deadlines (customer-facing, regulatory, contractual) outrank planned milestones. |
-| **3** | Highest-value delivery third | The engagement where today's work produces the most visible outcome. |
-| **4** | Steady-state last | Engagements on track with no urgent needs get allocated remaining time. |
+Use each customer's agreed audience, channel and cadence. Prepare an update when a commitment changes or a material risk needs a decision; send it only within existing communication authority. Explain the effect on that customer's work without disclosing another customer's identity, incident or confidential priorities.
 
-**4. Context-switch protocol.** When moving between customers:
+Reusing a field lesson across customers requires permission as well as removal of identifying and confidential information. Masking alone does not authorise reuse.
 
-```
-BEFORE LEAVING CUSTOMER A:
-  1. Write 3 lines to context.md: where we are, what changed, next step
-  2. Commit or stash any work in progress
-  3. Close all customer A files and browser tabs
+## Worked example
 
-BEFORE STARTING CUSTOMER B:
-  1. Run: fde resume (loads Customer B's engagement)
-  2. Read context.md - where did we leave off?
-  3. Confirm: what's the one thing to accomplish in this block?
-  4. Set a time boundary (e.g., "2 hours on Kesterman, then back to Garvey")
-```
+The FDE is leaving Garvey with an unfinished retry fix and switching to Kesterman. Garvey's `context.md` has a confirmed checkpoint pointing to the existing task and its unrun staging check. The FDE preserves the dirty working tree rather than committing or stashing it automatically. `fde resume --bind` still identifies Garvey, so bare resume would reopen the wrong record. After verifying that Kesterman already exists, the FDE selects its bound workspace or uses a command-scoped selection when record writes are prohibited, then obtains a fresh sanitized packet and checks `ENGAGEMENT:` before continuing. A temporary selection is reported as temporary, not as a changed workspace binding. Kesterman's sponsor has not replied, but the notes show planned leave; that alone does not justify an amber signal. An unconfirmed Garvey update stays a draft for Garvey and is never written into Kesterman's record.
 
-The 3-line context update is the bridge. Without it, the next session starts with "what was I doing?" - that's 20 minutes of re-discovery each time.
+## Completion
 
-**5. The communication cadence.** Each customer gets a rhythm:
+Return the selected customer, whether selection is temporary or persistent, binding evidence, next action, and any unsaved update or unresolved priority. A switch is complete only when the fresh packet identifies the intended customer and the previous work remains recoverable. Standalone portfolio review can return its summary without rebinding or saving anything.
 
-| Engagement intensity | Status cadence | Touchpoint type |
-|---------------------|---------------|-----------------|
-| Active build (daily work) | Weekly written + ad-hoc Slack | Status update + visible progress |
-| Light touch (2-3 days/week) | Weekly written | Status update + next week's plan |
-| Monitoring only | Bi-weekly written | Health check + any emerging risks |
-
-**The golden rule: no customer should have to chase you for an update.** Proactive status updates are cheaper than reactive ones - and they protect trust across all engagements.
-
-**6. Capacity management.** The honest conversation with yourself:
-
-| Situation | Action |
-|-----------|--------|
-| All engagements are steady | Allocate by value; reserve 20% for unplanned |
-| One engagement is on fire | Other engagements get a proactive heads-up: "Focus is on X this week; here's what's planned for you next week" |
-| Two engagements are on fire | Triage - one gets full attention, one gets stabilised, tell the sponsor of the stabilised one what's happening |
-| Three+ are on fire simultaneously | Escalate to your manager/team. Solo capacity is exceeded - communicate before quality drops |
-
-**7. The cross-contamination checklist.** Before every customer interaction:
-
-- [ ] Am I in the right `.fde/` folder?
-- [ ] Am I referencing the right customer's context?
-- [ ] Is the status update addressed to the right person?
-- [ ] Does my current context contain any data from another customer?
-- [ ] Are my browser tabs / code editors pointed at the right customer?
-
-One wrong customer name in a status update damages both relationships.
-
-## Artifact
-
-**`context.md`** (per customer) - the 3-line bridge updated at every context switch. The most-written file in multi-customer ops.
-
-**`fieldbook.html`** - regenerated by `fde dashboard --all` (deterministic, zero tokens) for the portfolio. Bare `fde dashboard` refreshes the bound `fieldbook-current.html`.
-
-## Checkpoint
-
-The daily triage is the checkpoint. One line per customer: signal, priority, today's action. If any customer hasn't been touched in 3+ business days: flag it - silence is noticed.
+For an authorised portfolio view, `fde dashboard --all` regenerates `fieldbook.html`; it does not change customer records. Neither the dashboard nor the agent's summary grants approval for a release or customer communication.
 
 ## Principles
 
-- One `.fde/` per customer. Never merge. Never cross-reference.
-- Trust fires outrank deadlines. A deadline can be renegotiated; trust can't.
-- Write the 3-line context bridge at every switch. 20 seconds saves 20 minutes.
-- No customer should have to chase for an update.
-- Two fires simultaneously is a triage decision. Three is an escalation.
-- The wrong customer name in a status update is a two-customer trust fire.
+- One customer's writes belong in that customer's record.
+- Use sanitized CLI packets; never substitute raw record reads.
+- Verify identity after a switch and preserve unfinished work without inventing authority.
+- Prioritise from impact and commitments, not unsupported trust timelines.
+- A fresh binding is not a fresh model context.

package/skills/switch-clients/references/verification.md

@@ -0,0 +1,45 @@
+# verification - Make a claim replayable
+
+**Enter when:** reporting completion, evaluating an acceptance check, handing work to a reviewer, or preparing a release.
+
+Use [task context](task-context.md). This method returns evidence directly or writes an existing permitted task/engagement record; it never requires `.fde/` initialization.
+
+## Method
+
+1. Translate each claim into the observation that would support or reject it. Cite the agreed acceptance criteria and required repository checks. Compare the checks being run with that agreement; flag any weakened threshold or removed requirement without an attributed approval from the appropriate decision-maker. Select focused checks for changed behavior before broadening to release requirements.
+2. Identify the actual repository commands, fixtures, runtime, and environment. Read command behavior before executing it, especially when it can write externally. Use authorized environments and avoid leaking secrets through logs or diagnostic commands.
+3. Run the checks and inspect results, including exit status and relevant output. A running job, test discovery, a mocked response, and a successful real request are different evidence. Record asynchronous completion before claiming success. Describe a command as executed only when its actual invocation and result are available; an inferred result is not a run.
+4. Bind evidence to the tested revision and working tree. For uncommitted changes record the base revision plus changed paths and an available diff digest or snapshot identifier. For browser/manual checks record the steps, inputs, observed result, and inspected evidence.
+5. After a change, rerun checks whose behavior or assumptions were affected. Reuse prior evidence only when the relevant code, dependencies, data, and environment remain applicable; cite the original run and reason. Never imply reused evidence was rerun.
+6. Label every required check **passed**, **failed**, **blocked**, or **not run**. Include why blocked/not run, impact, and next step. Missing evidence is unproven; it is not an observed failure or a pass.
+
+For performance claims, identify the measured bottleneck and compare before/after runs under comparable workload, environment and cache conditions. Repeat enough to distinguish a change from noise, retain correctness checks, and report unmatched conditions or uncertainty rather than claiming an unsupported improvement. Use the project's existing profiling and benchmark tools.
+
+## Receipt
+
+Use one compact entry per check or a table with these fields:
+
+- Claim / acceptance check and expected result.
+- Exact command and working directory, or manual journey and inputs.
+- Environment, runtime/tool versions when relevant, and fixture/data source.
+- Revision plus working-tree identity; run date/time.
+- Observed result and exit status where available; safe evidence location.
+- Status, limitations, unrun checks, and next step.
+
+Keep implementation, verification, deployment, measured outcome, and customer acceptance distinct. A local pass supports the tested local behavior. An acceptance claim needs an attributed source from the agreed decision-maker or agreed acceptance mechanism. Record no raw `<private>` blocks, credentials, or hidden reasoning.
+
+## Operator response
+
+When readiness depends on a failure signal, verify that a representative failure reaches the responsible operator through the intended route in an approved environment. Record separately whether the route is configured, the signal was delivered, and the operator acknowledged it; configuration alone proves neither delivery nor response. Use an authorized test route or an already approved drill, and identify any difference from the intended operating route. Do not page people or trigger production incidents without authorization. Reuse applicable evidence with attribution; a draft guide can mark this check untested.
+
+## Recoverable checkpoint
+
+For substantial work, keep a compact checkpoint in the existing permitted customer or project task record; if none exists, include it in the returned receipt. Reuse existing task/ticket identifiers when available. Record the task and agreed outcome, repository/branch/revision and dirty state, completed work and check results, pending work and checks, current blocker or `none`, and the exact next action. Link existing evidence rather than copying it into a new tracking artifact. Follow the record's write rules; a checkpoint does not silently change agreed scope or acceptance.
+
+In an ongoing engagement, optionally summarize that checkpoint under an unindented `## Implementation checkpoint` heading in the existing `context.md`, with the next action and task-record path/ID first. Follow the engagement confirmation and privacy rules. `fde resume` surfaces this saved summary without opening the referenced task file; retrieve that source only when permitted. Keep one current checkpoint, and clear or explicitly close it when the work ends. Do not initialize `.fde/` for standalone work or copy the whole backlog.
+
+Update it after meaningful completed slices and before a pause or handoff. On resuming, inspect the actual working tree and relevant evidence before taking the recorded next action; stale status is not proof that work or checks are still applicable.
+
+## Acceptance
+
+A completion statement cites applicable evidence for its claims and explicitly names material gaps. If required checks fail, investigate or report the blocker; never skip them, edit expectations, or relabel the scope without authority to obtain a green result.

package/hooks/run-hook.cmd

@@ -1,3 +0,0 @@
-@echo off
-:: Windows wrapper for session-start (uses PowerShell)
-powershell -ExecutionPolicy Bypass -File "%~dp0session-start"