fdeops 3.22.2 → 3.24.0

package/skills/fde/references/dashboard.md

@@ -4,11 +4,11 @@
 
 **Read per engagement:** `reality.md`, `brief.md`, `success.md`, `risks.md`, `decisions.md`, `delivery.md`, `stakeholders.md`. Never `terrain.md` (too large) or `trust-profile.md` (sensitive - stakeholder signals live in `stakeholders.md`).
 
-The visual artifact is rendered by code, not by you. `fde dashboard` reads every `.fde/` folder and writes a self-contained `fieldbook.html` - deterministically, offline, **at zero token cost**. Your job is the judgment the render can't do: which engagement gets tomorrow morning, and why.
+The visual artifact is rendered by code, not by you. Bare `fde dashboard` renders the **bound** engagement into `fieldbook-current.html`. Pass `--all` for every engagement (default file `~/fde-engagements/fieldbook.html`). Deterministic, offline, **at zero token cost**. Your job is the judgment the render can't do: which engagement gets tomorrow morning, and why.
 
 ## Method (you do this work)
 
-0. **First move: `fde status`** - instant heuristic triage (trust-first ordering) across every engagement. Use it as the index; then deep-read only the folders that are red/amber or that the FDE asks about, and apply the full card below.
+0. **First move: `fde status`** - value ledger, then trust, for the bound engagement. Pass `--all` for the portfolio. Use it as the index; then deep-read only the folders that are red/amber/`new` or that the FDE asks about, and apply the full card below.
 1. **Find the engagements:** `~/fde-engagements/*/.fde/` (primary) · workspace `./.fde/` if present · paths the FDE names. Read each folder **separately** - never merge two customers.
 2. **Per engagement, read the card the way a human would:**
    - Name, phase, week
@@ -17,15 +17,15 @@ The visual artifact is rendered by code, not by you. `fde dashboard` reads every
    - Top active risk
    - Last significant action + next step
    - Value delivered so far
-   - **Trust signal** - the most important row: **green** (no adverse signals) / **amber** (a stakeholder gone quiet or routing around the FDE) / **red** (escalation or explicit concern). Technical progress on a red-trust engagement is wasted until trust is addressed.
+   - **Trust signal** - the most important row: **new** (no dated `[signal:]` token - empty is not green) / **green** (someone was asked, and the latest token for that person is green) / **amber** (a stakeholder gone quiet or routing around the FDE) / **red** (escalation or explicit concern). Technical progress on a red-trust engagement is wasted until trust is addressed.
 3. **Triage order:** red trust first, then overdue risks, then stalled delivery. Say which engagement gets tomorrow morning and why.
-4. **Refresh the visual:** run `fde dashboard` to (re)generate `fieldbook.html` (defaults to `~/fde-engagements/fieldbook.html`). It is a deterministic render of the `.fde/` markdown - never hand-write HTML, never paste a model-built page. The session-end hook also refreshes it automatically when an engagement moved, so it is current next time the FDE opens it.
+4. **Refresh the visual:** run `fde dashboard` (add `--all` for the portfolio, `--open` to open the file). Default output is `fieldbook-current.html` for the bound client. It is a deterministic render of the `.fde/` markdown - never hand-write HTML, never paste a model-built page. The session-end hook also refreshes the bound fieldbook when an engagement moved.
 
 Sparse data: the render shows what exists and pads nothing. An empty field honestly shows what hasn't been captured.
 
 ## Artifact
 
-**`fieldbook.html`** - generated by `fde dashboard`, never hand-maintained. One file, opens in a browser, works offline, `<private>` notes redacted. Portfolio grid on top (a card per client: trust, phase, next action, top risk); click a card to drill into that engagement's full memory below.
+**`fieldbook-current.html`** (bound) or **`fieldbook.html`** (`--all`) - generated by `fde dashboard`, never hand-maintained. Opens in a browser, works offline, `<private>` notes redacted. Today plus a left rail of engagements; not a card grid.
 
 ## Checkpoint
 

package/skills/fde/references/debrief.md

@@ -24,14 +24,21 @@
 2. Run `fde debrief --smart <notes.md>` (or `npx fdeops debrief --smart …`).
 3. Open `.debrief-propose`. If lines lack type prefixes, **rewrite them** before showing the FDE, e.g.:
    - `decision: agreed chargebacks stay phase 2 - Priya`
+   - `decision: freeze the API [approved: Priya 2026-09-08]` (optional; missing means unconfirmed)
    - `risk: legal may reopen scope if we slip the SOW date`
    - `contact: Priya pushed hard on Friday deck [signal:amber]`
    - `signer: Priya` (she can say yes; lands in `success.md`)
    - `next: send one-pager before Thursday 9am`
    - unprefixed lines stay context color only
-4. Show the **proposed** routing in plain language (what would become decisions, risks, contacts, next).
-5. On FDE confirm → run `fde debrief --apply`.
-6. On reject → stop; ask what to change; do not apply.
+4. Show the **REVIEW** block first (decided / asked / open / next / signer). That is the one screen to confirm. File routing stays underneath.
+5. In **chat**, after that REVIEW, present a four-row card and omit empty rows:
+   - Decided
+   - Asked / open
+   - Next
+   - Signer
+   Then a **Previously:** line from the record, and **Not yet agreed** for anything still proposed. Ask **Save this update?** Saving means the engineer accepted this as the engagement record, not that the customer approved every ask. Uncertainty stays visible.
+6. On FDE confirm → run `fde debrief --apply`.
+7. On reject → stop; ask what to change; do not apply. Do not rebuild or replace the CLI REVIEW engine.
 
 No invented names or quotes. If the propose looks wrong, fix prefixes with judgment then re-apply or use the fallback path.
 
@@ -46,8 +53,8 @@ If `--smart` is unavailable or you already have clean prefixes:
    - **Risks** - new / confirmed / retired
    - **Open questions** - what to chase next
 2. Format lines as `decision:` / `risk:` / `delivery:` / `contact:` / `next:` / `signer:` (contacts may end with `[signal:green|amber|red]`).
-3. Show that structured version to the FDE for confirmation.
-4. Pipe to `fde debrief` (or write a file and run it).
+3. Show the same **chat card** as the smart path (omit empty rows; Previously; Not yet agreed; **Save this update?**). Do not invent a second confirm surface.
+4. On confirm, pipe to `fde debrief` (or write a file and run it).
 
 One clarifying question max if the dump is ambiguous - then write. Never stall capture on completeness.
 

package/skills/fde/references/discover.md

@@ -18,6 +18,8 @@ Then check - probe ONLY if it prevents wasted discovery:
 
 State your read, let the FDE correct, then discover.
 
+Before asking for facts, inspect the supplied brief and existing redacted records for the answer. Once the decision frame is confirmed and code access is authorized, use the scan below and targeted file reads to resolve technical unknowns. Phrase remaining questions around the discrepancy found: “The queue already exists, but alerts are disabled; who currently checks it?”
+
 ## Brief interrogation (when the hypothesis is still mush)
 
 Use when the "problem" is unfalsifiable, success is undefined, or you cannot name the decision discovery informs. Skip when `reality.md` / `terrain.md` already pin a testable claim and the FDE is ready to dig.
@@ -66,7 +68,7 @@ Do not mark pieces as facts or assumptions here. That is `test-assumptions`. Do
 
 ## Method - part 1: the codebase (you do this work)
 
-**First move: `fde scan`** - it runs everything below deterministically in seconds (churn×tests, "temporary" archaeology, AI components, secrets redacted, previous attempts). Your job is then **interpretation**: read its output against the brief, follow the hotspots into the code, and connect the technical findings to the human signals in part 2.
+**First code move: `fde scan`** - after the Question is locked. It runs everything below deterministically in seconds (churn×tests, "temporary" archaeology, AI components, secrets redacted, previous attempts). Your job is then **interpretation**: read its output against the brief, follow the hotspots into the code, and connect the technical findings to the human signals in part 2.
 
 If the CLI is unavailable, run the manual commands below. Either way: do not load the full codebase into context - scan wide, read deep only on hotspots.
 
@@ -106,6 +108,8 @@ Flag every one. AI components don't fail like regular code - they degrade as the
 
 **6. Data flow.** Where data enters, how it moves, where it stops. Entry points first: routes, queues, cron, file drops.
 
+**7. Existing capability.** Trace the requested user action through existing code, configuration, tests, and operating workarounds. In `terrain.md`, record what can already be reused and the evidence that it works or fails. Check whether a configuration, ownership, or process change could resolve the observed break. A disabled feature is a lead, not a proven root cause. Keep observations and hypotheses distinct; option selection still belongs to plan / three-options.
+
 ## Method - part 2: the humans (you coach, the FDE asks)
 
 The real spec is what people **do** when the system fails - not what the slide deck says. Arm the FDE with these, in their own words:

package/skills/fde/references/earn-trust.md

@@ -25,7 +25,7 @@ Level 5: Trusted      → they call you before making decisions
 
 | Day | Move | Why it works |
 |-----|------|-------------|
-| 1 | Fix a small, visible, annoying bug - something the team has been stepping over | Proves you can ship in their environment without breaking things |
+| 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 |

package/skills/fde/references/ingest.md

@@ -32,7 +32,7 @@ List what you can actually call **this session**:
 4. **List** (optional) - `fde ingest list` shows staged items when you need an id or filename.
 5. **Propose** - `fde ingest propose <id-or-filename>` runs the debrief `--smart` path on the staged body (+ provenance line). Opens `.debrief-propose`.
 6. **Rewrite prefixes** - same as debrief: lines without `decision:` / `risk:` / `delivery:` / `contact:` / `next:` / `signer:` need **you** to rewrite before showing the FDE. `--smart` is a gate, not a brain.
-7. **Show** the proposed routing in plain language. Wait for confirm.
+7. **Show** the same chat card as debrief (decided / asked / open / next / signer; omit empty; Previously; Not yet agreed; **Save this update?**). Wait for confirm. The CLI REVIEW printout is unchanged.
 8. **Apply** - on FDE confirm only → `fde ingest apply` (= `fde debrief --apply`). On reject → stop; ask what to change.
 
 No invented names, meetings, or quotes. If the propose looks wrong, fix prefixes with judgment, then re-show before apply.

package/skills/fde/references/land.md

@@ -2,7 +2,7 @@
 
 **Enter when:** new customer, first meeting, just got the brief, nothing started yet.
 
-**Read first:** `context.md` if it exists. Nothing else until you know what kind of engagement this is.
+**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.
 
 ## Validation gate (confirm understanding, clarify where it elevates)
 
@@ -35,7 +35,7 @@ Wait for the reaction before the next question. Stop when confidence is high eno
 
 ## Method - part 1: interrogate the brief (you do this work)
 
-Read the brief the FDE gives you. What is **not** in it matters as much as what is. Produce the gap list yourself:
+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.
@@ -52,7 +52,7 @@ Pre-arrival checks to run through with the FDE:
 
 ## Method - part 2: the first conversation (you coach, the FDE asks)
 
-Intent: before any tech, learn what keeps the sponsor up at night - personally, not the project charter. Failure talk surfaces truth faster than "requirements." Angles in the FDE's own words:
+Intent: coach the FDE's first *customer* conversation - what keeps the sponsor up at night, personally, not the project charter. You already inspected the supplied brief and any authorized repo/docs. This is before *their* laptop in the room / before a deep build, not before you read evidence. Failure talk surfaces truth faster than "requirements." Angles in the FDE's own words:
 
 - "Before you open the laptop - what would make this a bad engagement for *them*, not just a delayed project?"
 - "What are they afraid you'll miss?"
@@ -71,13 +71,13 @@ Let silence sit. If their fear doesn't match the written brief, the brief is wro
 
 ## The day 1 deliverable
 
-Before the end of day 1, ship one visible thing: 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.
+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.
 
 ## Artifact (write as the conversation is debriefed)
 
 **`brief.md`** - what they said, who sent the FDE, the timeline, **and the gap list**.
 
-**`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. Agreed with the customer, not assumed.
+**`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:
 
@@ -113,7 +113,7 @@ One falsifiable hypothesis about the real problem also goes at the bottom of `br
 
 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.
 
-If remote: trust-building takes ~40% longer - push for a short video call before anything asynchronous.
+If remote: agree how progress and blockers will be shared; use a short call when asynchronous context is insufficient.
 
 ## Worked example
 

package/skills/fde/references/pick-three.md

@@ -61,7 +61,7 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 
 ## Artifact
 
-**`decisions.md`** - the triage table with scores, lanes, **and an explicit Kill / Later commitment**. Dated. Referenced by plan and status.
+**`decisions.md`** - the triage table with scores, lanes, **and an explicit Kill / Later commitment**. Dated. Updates the same Now/Next/Later plan already uses; do not open a second plan section. Referenced by plan and status.
 
 Required closing block (plan will not treat triage as done without it):
 

package/skills/fde/references/plan.md

@@ -24,6 +24,8 @@ An FDE plan is not a sprint backlog. The technical sequence is the easy part. Th
 
 **0. Lock scope first.** Read `success.md`, `assumptions.md`, and the **Question** on `reality.md`. If out-of-scope is undefined, define it now with the FDE - a plan on undefined scope accumulates silent commitments. If any CRITICAL assumption is still `OPEN`, stop and run test-assumptions / discover before sequencing work. If `reality.md` has no Question, stop and finish discover - you are sequencing trivia.
 
+**Reuse check.** Before sequencing a build, compare the requested solution with the smallest existing capability or operating change that could satisfy the same acceptance test. Cite the relevant repo/config/workaround evidence. Record why reuse is sufficient or insufficient in `decisions.md`; include “no new code” when supported. A request for AI does not establish that a model is needed. If a host engineering pack already has an approved implementation plan, reference it from `decisions.md`; do not generate a parallel user-story backlog.
+
 **1. Work backwards from success.** What's the last thing that must be true before done? And before that? That's the dependency chain - not a wish list.
 
 **2. Front-load the fragile.** Check `terrain.md` hotspots. Risky modules go early - fail fast, not in week three.
@@ -57,6 +59,10 @@ Risk: <what could go wrong + fallback>
 Kill if: <the observation that voids this slice - copy from assumptions.md How we test, or the check that means stop>
 Verify: <specific check>
 Value promised: <business unit change this slice claims>
+Baseline: <value + source/date/window/environment, or pending + measurement owner>
+Acceptance owner: <name + authority source, or unknown - ask: who can accept?>
+Evidence to collect: <before/after check, sample/window, environment, and receipt location>
+Reuse: <existing capability used, or evidence it cannot satisfy the criteria>
 
 ### Next
 - ...
@@ -70,6 +76,8 @@ Value promised: <business unit change this slice claims>
 | <rewrite / nice-to-have / political ask> | <evidence> | <name, date> |
 ```
 
+In `Who accepted`, distinguish a proposed deferral from an agreement: use `pending` until a named person accepted this scope with a dated source. Sponsorship alone is not approval of every plan detail.
+
 No kill list → not a finished plan. Reopen with the FDE until the deferrals are written.
 ## Checkpoint
 

package/skills/fde/references/poc.md

@@ -12,7 +12,7 @@ A green check on synthetic data is not a validated solution. The person who can
 
 **0b. Pass / fail before you build.** For the test you will run, write three lines in `prototype-log.md` first: what you will actually do (who you talk to, what you show, on whose screen); the result that **kills** this option; the result that keeps it alive. What you would learn either way. If every option's test would fail, name which `assumptions.md` block to reopen - do not invent a fourth playbook.
 
-**1. Pick by score when several use cases compete.** Use the scoring model from `discover.md` - (Value × Data readiness) / Complexity. If discover already scored, reuse; never re-score independently.
+**1. Pick by score when several use cases compete.** Use the scoring model from `discover.md` - (Value × Data readiness) / Complexity. If discover or score-use-cases already produced a ranking, reuse it; never invent a third ranking.
 
 **2. Build the minimum that tests the assumption.** No error handling, no polish. Same-day demo if possible. Rough is honest. The POC is done when the person who can say no has seen it and reacted, not when the code looks finished.
 

package/skills/fde/references/readout.md

@@ -6,7 +6,9 @@
 
 ## Method (you do this work)
 
-**First:** run `fde status`. It prints the value ledger before trust - promised → measured → accepted by, or `claimed, not yet accepted`. Those lines are the Situation. Do not invent a number the CLI did not print.
+**First:** run `fde status`. It prints the value ledger before trust - promised → measured → accepted by, or `claimed, not yet accepted`. Those lines locate the Situation; check their cited records before making the claim. CLI output summarizes recorded text, not independently verified acceptance. Do not invent a number the CLI did not print. If the CLI is unavailable, use the redacted source records and say so.
+
+**Qualify the evidence before drafting.** For each result, identify baseline source, measurement environment, observation window/sample, and the scope of acceptance. Report an informal baseline as reported and a staging sample as staging; neither establishes realized savings. “Looks good” without what was accepted is not outcome acceptance. Attribute an engineer's note as such; do not turn it into a direct customer receipt. If evidence conflicts, include the conflict and the next verification action rather than choosing the flattering version.
 
 **Always draft in SCQA.** One page maximum. No other shape.
 
@@ -23,7 +25,7 @@ Then add, still on the same page:
 3. **Kill / defer reminder** - one line from the plan kill list so scope fights stay visible.
 4. **Hostile Q prep** - three questions a skeptical sponsor will ask, with one-line answers from memory.
 
-Exec voice: no jargon, no hedging, every claim traceable (`(shipped Tue, delivery.md)`). Draft in the **FDE's voice, for the FDE to send** - never send anything yourself.
+Exec voice: no jargon, explicit uncertainty where evidence is incomplete, every claim traceable (`(shipped Tue, delivery.md)`). Draft in the **FDE's voice, for the FDE to send** - never send anything yourself.
 
 For board / renewal / sponsor's boss (longer pyramid): use `board-memo.md`. Do not invent a second weekly format.
 

package/skills/fde/references/review.md

@@ -59,7 +59,7 @@ Five dimensions, line-specific ("line 47 fails under concurrent writes - no lock
 
 ## Before the PR - thinking for the next reader
 
-Code alone loses the "why." Before you call the change reviewable, run the **session digest** from the memory contract (SKILL.md On exit): TL;DR, key decisions & rationale, scope + how you verified, gotchas. Confirm with the FDE, then write into `.fde/` - `decisions.md` / `delivery.md` / `context.md`. Reviewers (or Monday-you) should answer "why this approach?" from the fieldbook, not from a chat transcript. Do **not** dump agent logs into the product repo.
+Code alone loses the "why." Before you call the change reviewable, run the **session digest** from the memory contract (SKILL.md Session digest): TL;DR, key decisions & rationale, scope + how you verified, gotchas. Confirm with the FDE, then write into `.fde/` - `decisions.md` / `delivery.md` / `context.md`. Reviewers (or Monday-you) should answer "why this approach?" from the fieldbook, not from a chat transcript. Do **not** dump agent logs into the product repo.
 
 ## Artifact
 

package/skills/fde/references/score-use-cases.md

@@ -10,7 +10,7 @@ The most dangerous moment in a multi-use-case engagement is when the technically
 
 **1. List every candidate.** From the brief, from discovery conversations, from the FDE's own observations. Include the ones the customer hasn't said aloud but the codebase implies - a high-churn module with no tests is a candidate even if nobody named it.
 
-**2. Score on five dimensions.** Each 1-5, with the scoring rubric below:
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. If discover already ranked candidates with (Value × Data readiness) / Complexity, reuse that order; this table extends the conversation. Do not invent dimension scores from a thin brief - write `unknown` and ask.
 
 | Dimension | 1 | 3 | 5 |
 |-----------|---|---|---|

package/skills/fde/references/ship.md

@@ -231,6 +231,8 @@ Straight from pilot to standard = a high-profile failure at scale.
 
 ## Method - after
 
+Keep implementation, test results, deployment, measured outcome, and customer acceptance separate in the receipt. Record the environment, observation window/sample, source, and remaining gaps. A commit is not a deploy; a staging measurement is not realized production value. When the baseline is missing or incomparable, record the observed result and the measurement next step without claiming an improvement. Record acceptance only for what the named person actually accepted, with a dated source; an engineer's summary remains attributed to that summary.
+
 Smoke tests against production. Verify the business metric moved the right way. Then **define the pulse before closing the laptop** - a deploy without a pulse is one you'll hear about only when it breaks:
 
 1. **Metric:** the number that says it's working - "p99 on payment endpoint < 800ms", not "errors low."
@@ -241,7 +243,7 @@ AI components: also define what *normal output* looks like and check a weekly sa
 
 ## Method - scale readiness (pilot proved it, now deploy enterprise-wide)
 
-95% of AI pilots fail to reach production. The gap isn't technical - it's organizational, governance, and infrastructure readiness. This checklist determines whether the pilot is ready to scale.
+A successful pilot does not establish readiness for wider use. Check organizational ownership, governance, and infrastructure alongside technical performance before expanding.
 
 **The scale-readiness gate (all must be YES before broad rollout):**
 
@@ -277,7 +279,7 @@ Adoption isn't a handoff-stage problem - it starts while you are still writing t
 
 **At launch:**
 - **Champion network.** Identify 2-3 power users per team who adopt early. Support them intensely - they become your multiplier.
-- **30-60-90 adoption targets.** Week 1: 20% of target users try it. Week 4: 50% use it weekly. Week 12: 80% can't imagine working without it. If week 1 misses → the onboarding is broken. If week 4 misses → the value proposition is wrong.
+- **Adoption targets agreed before launch.** Define the eligible users, expected usage frequency, observation window, baseline, and owner. A weekly workflow needs a different measure from a quarterly one. Investigate misses with users; usage alone does not establish whether onboarding, access, or value is the cause.
 - **The "switching cost" test.** If users can still do it the old way, they will. Adoption requires either: the old way is removed, the new way is dramatically better, or management mandates the switch. Know which lever applies.
 
 **Write adoption metrics to `delivery.md`:** active users, frequency, drop-off points, resistance signals. This is the evidence for renewal.

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

@@ -2,7 +2,7 @@
 
 **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."
 
-**Read first:** Run `fde status` for the portfolio view. Then per engagement: `context.md` only - load deeper files only for the engagement being worked on.
+**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.
 
 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.
 
@@ -98,7 +98,7 @@ One wrong customer name in a status update damages both relationships.
 
 **`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` (deterministic, zero tokens) to give the portfolio view. Trust-ordered.
+**`fieldbook.html`** - regenerated by `fde dashboard --all` (deterministic, zero tokens) for the portfolio. Bare `fde dashboard` refreshes the bound `fieldbook-current.html`.
 
 ## Checkpoint