fdeops 5.1.21 → 5.1.23

package/skills/fde/references/plan.md

@@ -4,7 +4,9 @@
 
 **Enter when:** scope is understood and the work needs breaking down - a slice, a phase, or the whole delivery.
 
-**Read first:** `reality.md`, `success.md`, `terrain.md`, `stakeholders.md`. Load `business-case.md` if poc produced one. Not the full folder.
+**Read first, when an engagement record exists:** the relevant parts of `reality.md`, `success.md`, `terrain.md`, and `stakeholders.md`. Load `business-case.md` only when its cost case affects this decision. For standalone work, use the supplied context; absent records are not a blocker.
+
+**Bounded path:** If implementation is requested and authorized, and the outcome, constraints and acceptance checks already support one bounded change, the coordinator can select `build` without a separate planning exercise. An explicit planning request still returns a plan; it does not authorize implementation or require another installed skill. If a bounded task genuinely needs sequencing, give the FDE a brief plan with the next working slice, its boundary, a success and failure check, and the blocking unknown or authority if any. Spend the time on the working result. A single-slice plan does not require a new engagement record, stakeholder map or multi-phase template.
 
 **On an initialized engagement, before a new delivery plan or material scope change:** run `fde doctor --ready`. For standalone planning, check the supplied outcome, scope, acceptance and authority directly; do not initialize records to run this validator. Missing acceptance criteria or authority blocks the affected implementation commitment, not a provisional plan. Draft proposed checks and next steps, mark them pending, and ask only what changes the next action. Use a test/input and observable pass/fail under **Done when:** or **Acceptance check:**. A number, role, or successful demo alone is insufficient. Do not invent missing facts to pass lint. Routine reversible fixes within confirmed scope reuse the existing signer, acceptance criteria, and engineering plan; record verification without reopening settled decisions.
 
@@ -46,7 +48,7 @@ Preserve supplied ticket identifiers and blocking dependencies; do not renumber
 
 **6. Agree useful stakeholder touchpoints.** Name who needs to see which result before the next decision. Reuse the customer's existing review cadence; task count alone does not justify another meeting or imply lost trust.
 
-**7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
+**7. Bound a multi-slice plan.** For a phased engagement, name consequential work excluded from this phase. Do not invent a kill list for one bounded slice. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
 
 Carry the agreed acceptance checks and their source into implementation and verification, preferably by linking the existing record. Added checks may strengthen coverage; changing a threshold or removing a requirement remains a proposal until the appropriate decision-maker approves the change with a dated source. Record what changed and why; a passing weaker test does not satisfy the original agreement.
 
@@ -56,7 +58,7 @@ Carry the agreed acceptance checks and their source into implementation and veri
 
 For standalone planning, return the requested draft or save to the authorized project document. In a bound engagement, propose the plan for **`decisions.md`** under its confirmation rules, or link the existing approved plan; do not duplicate it.
 
-A plan is **not done** until all four blocks exist:
+For a single-slice plan, the brief slice, boundary, acceptance checks, verification and any blocking dependency are enough. Use the full four-block format below when sequencing several slices or decisions with material dependencies, regardless of engagement duration:
 
 ```markdown
 ## Plan - <date>
@@ -92,7 +94,7 @@ In `Who accepted`, distinguish a proposed deferral from an agreement: use `pendi
 Check the plan against every supplied requirement and constraint. Each must map to a task and acceptance check, an explicitly accepted exclusion, or a visible unresolved decision. Do not silently omit a requirement to simplify the plan. Reuse an existing approved plan rather than creating a second coverage record. If no work is deferred, say so; do not invent exclusions to fill the template.
 ## Checkpoint
 
-Walk the FDE through: sequence + why this order, where the fragile work sits, where the touchpoints land, the acceptance gate and **Kill if** on task 1, and the kill list. State who sees the first slice and when, which exclusions are accepted or proposed, and what observation stops task 1. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
+For a single-slice plan, state the first slice, how it will be checked, and what would stop it. For a phased plan, walk the FDE through the sequence, fragile work, useful touchpoints, acceptance gate, and consequential exclusions. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
 
 ## Method - estimation (when the sponsor asks "how long, how much?")
 
@@ -157,7 +159,7 @@ First visible slice goes to Marco, not Priya: he is the one whose morning change
 - Fragile zones early. Fail fast.
 - Touchpoints serve the next customer decision and agreed cadence.
 - No written acceptance criteria, no build.
-- No kill list, no finished plan.
+- Make consequential exclusions explicit when work is deferred; a bounded slice needs no invented kill list.
 - No **Kill if** on a Now PR, that PR is hope.
 - Estimates are ranges, not promises. Name the assumptions and the observation that voids them.
 - Migrations: compatibility determines order; verified recovery precedes cutover.

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

@@ -4,13 +4,15 @@
 
 **Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from poc, load those - they carry forward.
 
-The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
+The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring makes assumptions and trade-offs visible; it does not replace evidence or judgment. These ordinal ratings are a discussion aid, not calibrated estimates of value or a reason to override a hard constraint.
 
 ## Method (you do this work)
 
 **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. 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.
+Before ranking work for the proposed step, identify hard feasibility, access, data-permission and policy constraints. Keep blocked or unverified candidates visible with the affected step, owner or authority gap, and evidence needed to reconsider. A high score cannot make dependent work eligible. An authorized design or evidence check may proceed while implementation is blocked; a sponsor's preference does not grant missing API or data permission.
+
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. Reuse discovery's evidence and rationale, rechecking whether the candidates are eligible for the same next step. Do not invent dimension scores from a thin brief - write `unknown`, return a conditional recommendation and ask only what changes the decision.
 
 | Dimension | 1 | 3 | 5 |
 |-----------|---|---|---|
@@ -27,11 +29,11 @@ Score = (Business value × Urgency × Stakeholder alignment) / (6 - Feasibility)
 ```
 
 Why this formula:
-- **Multiplied numerator** - all three must be present. A high-value problem with no urgency or no sponsor scores low because it won't ship.
+- **Multiplied numerator** - a lower rating reduces the score relative to otherwise identical ratings. Because every scale starts at 1, the formula does not establish that urgency, sponsorship or permission is present; eligibility must be checked separately.
 - **Feasibility inverted** - harder problems get a higher denominator, pulling the score down. A feasibility of 5 (easy) gives denominator 1; feasibility of 1 (hard) gives denominator 5.
 - **Data readiness as multiplier** - for data-dependent use cases (ML, analytics). For pure engineering work, set to 3 (neutral) unless data quality is genuinely a factor.
 
-**4. Rank and present.** Sort by score. Present the top 3 to the FDE and the sponsor:
+**4. Rank and present.** Compare eligible candidates; show up to three useful options and list blocked work separately. If an uncertain input could reverse the order, show the plausible alternative rankings and the smallest permitted check that distinguishes them, with its owner or an explicit ownership gap. Do not hide uncertainty in a precise-looking score or delay independent authorized work while waiting. The following scores illustrate a recommendation, not a commitment:
 
 ```markdown
 | Rank | Use case | Value | Urgency | Feasibility | Data | Alignment | Score | Recommend |
@@ -49,7 +51,7 @@ Why this formula:
 **6. Handle the CEO's pet project.** Sometimes the highest-scoring use case isn't the one the most powerful stakeholder wants. That's information, not a problem:
 
 - Present the scores honestly - the stakeholder sees you're being rigorous, not political.
-- If they override: log it in `decisions.md` as a deliberate choice, note the trade-off, and build what they chose. The FDE who was honest about the trade-off is protected when the override creates problems.
+- If the responsible decision-maker overrides the ranking, preserve the choice, source and trade-off under the existing record-confirmation rules. Check capacity and required permissions before dependent work; an override changes preference, not hard constraints or acceptance authority. An unconfirmed choice remains proposed.
 
 ## Artifact
 
@@ -59,12 +61,12 @@ Why this formula:
 
 ## Checkpoint
 
-Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to poc or plan.
+Walk the FDE through the eligible options, relevant blockers and any uncertainty that could reverse the recommendation. Keep the proposed allocation pending the appropriate decision authority; silence is not approval. Reuse existing authorization when it covers the next step. If evidence is insufficient, recommend a bounded distinguishing check rather than automatically proceeding with the highest score.
 
 ## Principles
 
-- Score replaces opinion. Visible arithmetic beats invisible judgment.
-- All three conditions (value, urgency, alignment) must hold - or the use case won't ship.
+- Scores expose assumptions; evidence and eligible scope govern the recommendation.
+- A numerical advantage cannot override a hard constraint or unknown permission.
 - The technically interesting problem that scores low gets deferred, not pursued.
 - Present the model; let the human decide. If overridden, log the trade-off.
 - A use case with no active sponsor is a research project, not an engagement deliverable.

package/skills/fde/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -5,6 +5,6 @@
     "SKILL.md": "7d49a9e89736e35c2aaf10c78b10be365bdf91af1aaf99430de6069e96069d55",
     "agents/openai.yaml": "6b8d024e9ea9676a2607b76a6f1fcd2fbcba585af2990b1172dbdb8cec0364c6",
     "references/encode-pattern.md": "10fc5679752f0ea0b4d3004e4c7e282bb17f9b496ab99e5c7aae04ac942fb3c1",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd"
   }
 }

package/skills/feedback/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -6,7 +6,7 @@
     "agents/openai.yaml": "93ac049cf1a9d0fdfdf67d34ca6d3dd33800e91334f38bb303828eab8c4b3aaf",
     "references/close.md": "4c75697bb7c85af3b4054bf427d0f265d388972a3139f1e25a1bc9f56ac65cf4",
     "references/encode-pattern.md": "10fc5679752f0ea0b4d3004e4c7e282bb17f9b496ab99e5c7aae04ac942fb3c1",
-    "references/land.md": "87dfffc8e39d35eaf23d510ba7e9913d48e90d2705eb9155ab192d12ea98d18d",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
+    "references/land.md": "f33f1b9e03a3c23c39ffce925a8f8b956b48a53982f55246752a48a317cb084d",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd"
   }
 }

package/skills/handoff/references/land.md

@@ -4,6 +4,8 @@
 
 **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.
 
+**Bounded engagement:** A new customer does not automatically require a full landing exercise. For a single-outcome task or simulation of any duration, use the supplied brief to establish the outcome, deadline, permitted inputs, acceptance and next authorized action. If those are clear, route to the working task immediately. If one material gap remains, investigate that gap; do not build a stakeholder map or populate engagement files for their own sake. A simulated stakeholder does not justify invented meetings or approval chains. Keep actual data and release authority checks where they affect the work.
+
 ## Validation gate (confirm understanding, clarify where it elevates)
 
 Before landing, state what you know in 2-3 lines:
@@ -12,7 +14,7 @@ Before landing, state what you know in 2-3 lines:
 
 Then check - probe ONLY if it prevents a bad start:
 
-1. **Engagement speed.** If timeline is unclear → weave it in naturally: "Is this days, weeks, or months? That shapes how much structure we set up now."
+1. **Deadline and scope.** Ask about timing only when it changes the next action: "What result is needed by when?" Use uncertainty, dependencies, risk and access to choose the necessary structure; duration alone does not decide it.
 2. **Existing context.** If `.fde/` already exists → one line: "There's existing engagement memory here. Continuing this or starting fresh?"
 3. **Access.** If the FDE is about to start work → one line: "Got repo and environment access sorted, or is that still pending?"
 

package/skills/handoff/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -8,6 +8,6 @@
     "references/debrief.md": "2e8e929f1c741e1a7250ad720dfa2196e1f8b14ae84f17e406c38910b9b83376",
     "references/ingest.md": "2aaf948f6ae19fb472a2bf101b8064fc04e3c1103b874455b5a4457b5c69cf86",
     "references/source-setup.md": "a28ae7c6dbb2573a66f31b30b7abca34bc52573fe34d48fff4c7490e4dc85d3e",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd"
   }
 }

package/skills/ingest/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -11,7 +11,7 @@
     "references/qa.md": "41de4d70827c83291efa217e97d777f62ec2849827687fbba7e4b1d17484b87e",
     "references/review.md": "8fa35eacdc04d5e818e046e6da8f61f126e08d9c6a1073b2eaa19f72d4bfea3a",
     "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd",
     "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/integrate/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -5,7 +5,7 @@
     "SKILL.md": "0c51c5421875b17c66c4fdb03a33e3705da52a0c649dd138c4c4cd3f3c92292a",
     "agents/openai.yaml": "ff5da2d5215943e5c4e2a1339c11101035ed2741ded38e443af5180239e2a24b",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd",
     "references/test-assumptions.md": "977acbf88dc0468afeb0fb222fae88100ee6a5078a729e0651c28a45870e3925",
     "references/three-options.md": "2c979027c09af936f9a50446721e344f15e3e3bf43d3c1b7b0b85240747168c4"
   }

package/skills/options/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -5,7 +5,7 @@
     "SKILL.md": "88254d8bc2f58f4fcdd610dd7c111854dccf3ef488cfae85a4f81e90e25d1c96",
     "agents/openai.yaml": "09f79a8a6f59741be07ae42adb9187ef790c1c4dd0341adc22ca70cd043e9ac1",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/plan.md": "f5c456b5e2c00a6a44fdf94935b143f3b5271c31187bf06d09eae724f9d466fa",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
+    "references/plan.md": "5f0330ab7195a5dec406463824b2c00dd013b70626ec52f7de4dfa0d401c1575",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd"
   }
 }

package/skills/plan/references/plan.md

@@ -4,7 +4,9 @@
 
 **Enter when:** scope is understood and the work needs breaking down - a slice, a phase, or the whole delivery.
 
-**Read first:** `reality.md`, `success.md`, `terrain.md`, `stakeholders.md`. Load `business-case.md` if poc produced one. Not the full folder.
+**Read first, when an engagement record exists:** the relevant parts of `reality.md`, `success.md`, `terrain.md`, and `stakeholders.md`. Load `business-case.md` only when its cost case affects this decision. For standalone work, use the supplied context; absent records are not a blocker.
+
+**Bounded path:** If implementation is requested and authorized, and the outcome, constraints and acceptance checks already support one bounded change, the coordinator can select `build` without a separate planning exercise. An explicit planning request still returns a plan; it does not authorize implementation or require another installed skill. If a bounded task genuinely needs sequencing, give the FDE a brief plan with the next working slice, its boundary, a success and failure check, and the blocking unknown or authority if any. Spend the time on the working result. A single-slice plan does not require a new engagement record, stakeholder map or multi-phase template.
 
 **On an initialized engagement, before a new delivery plan or material scope change:** run `fde doctor --ready`. For standalone planning, check the supplied outcome, scope, acceptance and authority directly; do not initialize records to run this validator. Missing acceptance criteria or authority blocks the affected implementation commitment, not a provisional plan. Draft proposed checks and next steps, mark them pending, and ask only what changes the next action. Use a test/input and observable pass/fail under **Done when:** or **Acceptance check:**. A number, role, or successful demo alone is insufficient. Do not invent missing facts to pass lint. Routine reversible fixes within confirmed scope reuse the existing signer, acceptance criteria, and engineering plan; record verification without reopening settled decisions.
 
@@ -46,7 +48,7 @@ Preserve supplied ticket identifiers and blocking dependencies; do not renumber
 
 **6. Agree useful stakeholder touchpoints.** Name who needs to see which result before the next decision. Reuse the customer's existing review cadence; task count alone does not justify another meeting or imply lost trust.
 
-**7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
+**7. Bound a multi-slice plan.** For a phased engagement, name consequential work excluded from this phase. Do not invent a kill list for one bounded slice. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
 
 Carry the agreed acceptance checks and their source into implementation and verification, preferably by linking the existing record. Added checks may strengthen coverage; changing a threshold or removing a requirement remains a proposal until the appropriate decision-maker approves the change with a dated source. Record what changed and why; a passing weaker test does not satisfy the original agreement.
 
@@ -56,7 +58,7 @@ Carry the agreed acceptance checks and their source into implementation and veri
 
 For standalone planning, return the requested draft or save to the authorized project document. In a bound engagement, propose the plan for **`decisions.md`** under its confirmation rules, or link the existing approved plan; do not duplicate it.
 
-A plan is **not done** until all four blocks exist:
+For a single-slice plan, the brief slice, boundary, acceptance checks, verification and any blocking dependency are enough. Use the full four-block format below when sequencing several slices or decisions with material dependencies, regardless of engagement duration:
 
 ```markdown
 ## Plan - <date>
@@ -92,7 +94,7 @@ In `Who accepted`, distinguish a proposed deferral from an agreement: use `pendi
 Check the plan against every supplied requirement and constraint. Each must map to a task and acceptance check, an explicitly accepted exclusion, or a visible unresolved decision. Do not silently omit a requirement to simplify the plan. Reuse an existing approved plan rather than creating a second coverage record. If no work is deferred, say so; do not invent exclusions to fill the template.
 ## Checkpoint
 
-Walk the FDE through: sequence + why this order, where the fragile work sits, where the touchpoints land, the acceptance gate and **Kill if** on task 1, and the kill list. State who sees the first slice and when, which exclusions are accepted or proposed, and what observation stops task 1. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
+For a single-slice plan, state the first slice, how it will be checked, and what would stop it. For a phased plan, walk the FDE through the sequence, fragile work, useful touchpoints, acceptance gate, and consequential exclusions. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
 
 ## Method - estimation (when the sponsor asks "how long, how much?")
 
@@ -157,7 +159,7 @@ First visible slice goes to Marco, not Priya: he is the one whose morning change
 - Fragile zones early. Fail fast.
 - Touchpoints serve the next customer decision and agreed cadence.
 - No written acceptance criteria, no build.
-- No kill list, no finished plan.
+- Make consequential exclusions explicit when work is deferred; a bounded slice needs no invented kill list.
 - No **Kill if** on a Now PR, that PR is hope.
 - Estimates are ranges, not promises. Name the assumptions and the observation that voids them.
 - Migrations: compatibility determines order; verified recovery precedes cutover.

package/skills/plan/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -11,12 +11,12 @@
     "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
     "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
     "references/integrate.md": "1cb7a60d7545b0bf224fce678a04ce6ccdf368c47877d9c8e4dc4272bb0d5b0c",
-    "references/plan.md": "f5c456b5e2c00a6a44fdf94935b143f3b5271c31187bf06d09eae724f9d466fa",
+    "references/plan.md": "5f0330ab7195a5dec406463824b2c00dd013b70626ec52f7de4dfa0d401c1575",
     "references/poc.md": "65c91866037dc034a64484683ad9a329896786f1487265c9fddecd19b09a3039",
     "references/qa.md": "41de4d70827c83291efa217e97d777f62ec2849827687fbba7e4b1d17484b87e",
     "references/review.md": "8fa35eacdc04d5e818e046e6da8f61f126e08d9c6a1073b2eaa19f72d4bfea3a",
     "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd",
     "references/test-assumptions.md": "977acbf88dc0468afeb0fb222fae88100ee6a5078a729e0651c28a45870e3925",
     "references/three-options.md": "2c979027c09af936f9a50446721e344f15e3e3bf43d3c1b7b0b85240747168c4",
     "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"

package/skills/poc/references/plan.md

@@ -4,7 +4,9 @@
 
 **Enter when:** scope is understood and the work needs breaking down - a slice, a phase, or the whole delivery.
 
-**Read first:** `reality.md`, `success.md`, `terrain.md`, `stakeholders.md`. Load `business-case.md` if poc produced one. Not the full folder.
+**Read first, when an engagement record exists:** the relevant parts of `reality.md`, `success.md`, `terrain.md`, and `stakeholders.md`. Load `business-case.md` only when its cost case affects this decision. For standalone work, use the supplied context; absent records are not a blocker.
+
+**Bounded path:** If implementation is requested and authorized, and the outcome, constraints and acceptance checks already support one bounded change, the coordinator can select `build` without a separate planning exercise. An explicit planning request still returns a plan; it does not authorize implementation or require another installed skill. If a bounded task genuinely needs sequencing, give the FDE a brief plan with the next working slice, its boundary, a success and failure check, and the blocking unknown or authority if any. Spend the time on the working result. A single-slice plan does not require a new engagement record, stakeholder map or multi-phase template.
 
 **On an initialized engagement, before a new delivery plan or material scope change:** run `fde doctor --ready`. For standalone planning, check the supplied outcome, scope, acceptance and authority directly; do not initialize records to run this validator. Missing acceptance criteria or authority blocks the affected implementation commitment, not a provisional plan. Draft proposed checks and next steps, mark them pending, and ask only what changes the next action. Use a test/input and observable pass/fail under **Done when:** or **Acceptance check:**. A number, role, or successful demo alone is insufficient. Do not invent missing facts to pass lint. Routine reversible fixes within confirmed scope reuse the existing signer, acceptance criteria, and engineering plan; record verification without reopening settled decisions.
 
@@ -46,7 +48,7 @@ Preserve supplied ticket identifiers and blocking dependencies; do not renumber
 
 **6. Agree useful stakeholder touchpoints.** Name who needs to see which result before the next decision. Reuse the customer's existing review cadence; task count alone does not justify another meeting or imply lost trust.
 
-**7. End with a kill list.** Every plan names what you will **not** do this phase. If everything is "later," you have no plan - you have a wish list. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
+**7. Bound a multi-slice plan.** For a phased engagement, name consequential work excluded from this phase. Do not invent a kill list for one bounded slice. Keep **Now** small enough to review and act on; split by independently verifiable outcomes.
 
 Carry the agreed acceptance checks and their source into implementation and verification, preferably by linking the existing record. Added checks may strengthen coverage; changing a threshold or removing a requirement remains a proposal until the appropriate decision-maker approves the change with a dated source. Record what changed and why; a passing weaker test does not satisfy the original agreement.
 
@@ -56,7 +58,7 @@ Carry the agreed acceptance checks and their source into implementation and veri
 
 For standalone planning, return the requested draft or save to the authorized project document. In a bound engagement, propose the plan for **`decisions.md`** under its confirmation rules, or link the existing approved plan; do not duplicate it.
 
-A plan is **not done** until all four blocks exist:
+For a single-slice plan, the brief slice, boundary, acceptance checks, verification and any blocking dependency are enough. Use the full four-block format below when sequencing several slices or decisions with material dependencies, regardless of engagement duration:
 
 ```markdown
 ## Plan - <date>
@@ -92,7 +94,7 @@ In `Who accepted`, distinguish a proposed deferral from an agreement: use `pendi
 Check the plan against every supplied requirement and constraint. Each must map to a task and acceptance check, an explicitly accepted exclusion, or a visible unresolved decision. Do not silently omit a requirement to simplify the plan. Reuse an existing approved plan rather than creating a second coverage record. If no work is deferred, say so; do not invent exclusions to fill the template.
 ## Checkpoint
 
-Walk the FDE through: sequence + why this order, where the fragile work sits, where the touchpoints land, the acceptance gate and **Kill if** on task 1, and the kill list. State who sees the first slice and when, which exclusions are accepted or proposed, and what observation stops task 1. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
+For a single-slice plan, state the first slice, how it will be checked, and what would stop it. For a phased plan, walk the FDE through the sequence, fragile work, useful touchpoints, acceptance gate, and consequential exclusions. Reuse supplied answers; ask only about a missing or consequentially ambiguous answer.
 
 ## Method - estimation (when the sponsor asks "how long, how much?")
 
@@ -157,7 +159,7 @@ First visible slice goes to Marco, not Priya: he is the one whose morning change
 - Fragile zones early. Fail fast.
 - Touchpoints serve the next customer decision and agreed cadence.
 - No written acceptance criteria, no build.
-- No kill list, no finished plan.
+- Make consequential exclusions explicit when work is deferred; a bounded slice needs no invented kill list.
 - No **Kill if** on a Now PR, that PR is hope.
 - Estimates are ranges, not promises. Name the assumptions and the observation that voids them.
 - Migrations: compatibility determines order; verified recovery precedes cutover.

package/skills/poc/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -5,7 +5,7 @@
     "SKILL.md": "07e8a3b485762e6b6897472fe4c934cb63ed0240d8258761be445729714d782d",
     "agents/openai.yaml": "3cfc01668b1bc6ec42d429e9730c68fd01520a7d15ea4289dee265e16bcd6b55",
     "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
-    "references/pick-three.md": "fa5a5f6db94c72c5a1c6419276d0f7c13ff3067ce075a074af020f736fe3fad8",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e"
+    "references/pick-three.md": "c64a04fd0724b28701bbe334f444d0df93da4d858de993e82ccae04e48b66db9",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd"
   }
 }

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

@@ -29,23 +29,23 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | **Dependency** | How many other initiatives are blocked waiting for this? | 0 (standalone) → 5 (critical path for 3+ others) |
 | **Cost of delay** | What happens each week this doesn't ship? | 1 (nothing) → 5 (measurable loss or regulatory exposure) |
 
-**Triage score = Impact + Dependency + Cost of delay** (simple sum, 3-15 range).
+**Triage score = Impact + Dependency + Cost of delay** (simple sum, 2-15 range).
 
 **3. Sort into three lanes:**
 
 | Lane | Score | Action |
 |------|-------|--------|
-| **Now** (max 3) | 11-15 | Active work this phase. FDE and team capacity allocated. |
-| **Next** (max 5) | 7-10 | Sequenced for the following phase. Dependencies tracked but not started. |
-| **Later** (unlimited) | 3-6 | Captured, not committed. Revisit at next triage. |
+| **Now** (max 3) | 11-15 | Proposed active work, subject to actual capacity, dependencies and authority. |
+| **Next** (max 5) | 7-10 | Proposed sequencing; dependencies tracked but not started. |
+| **Later** (unlimited) | 2-6 | Captured, not committed. Revisit at next triage. |
 
-**The cap matters.** "Now" has exactly 3 slots. Not 4, not "3 plus this small one." Discipline is the product.
+**The cap matters.** Three is a maximum, not a quota. Use fewer or zero Now items when capacity, unresolved dependencies or required permissions prevent useful authorized work. Check who is available, effort within the phase and shared bottlenecks; one engineer cannot be allocated to several full-capacity initiatives at once. The score bands are a starting point, not automatic lane assignments: high-scoring blocked work waits, and a lower-scoring prerequisite may come first with an explained rationale. Keep uncertain allocations proposed rather than inventing capacity or approval.
 
 **4. Handle the political override.** When a powerful stakeholder pushes a low-scoring initiative into "Now":
 
-- Show the displacement: "Adding X to Now means Y drops to Next. Y is currently blocking Z and W."
-- Let them choose: "Which of the current three should Y replace?" Making the trade-off visible makes the conversation honest.
-- If they override without trading: log it. `decisions.md`: "Initiative X added to Now without displacement by <who>. Capacity impact: <what slows>."
+- Show the capacity and dependency trade-off. If Now is full for the available team, adding X requires deferring work or an explicitly agreed capacity change; a vacant slot alone is not capacity.
+- Ask the responsible decision-maker to resolve the actual choice, without assuming three items are already active. Record the supplied choice and its source under the existing confirmation rules.
+- An override cannot waive required permissions or create capacity. Keep an unresolved request proposed, with its impact, rather than reporting it as an allocated commitment.
 
 **5. Set the triage cadence.** Triage is not a one-time event:
 
@@ -55,15 +55,15 @@ Notice: every stakeholder's initiative is P0 or P1. That's the problem this skil
 | Standard (1-4 weeks) | Weekly | New P0 from sponsor |
 | Programme (months) | Bi-weekly | Quarterly review, team change, market shift |
 
-**6. Communicate the triage result.** The output is not just a priority list - it's a commitment:
+**6. Communicate the triage result.** Distinguish a proposed allocation from an authorized commitment:
 
-> "We're committing to these three initiatives this phase: [A, B, C]. Here's why, here's what they deliver, and here's what's explicitly deferred: [D, E, F, ...]. If priorities change, we re-triage - we don't add without removing."
+> "For the available capacity, I propose [eligible items, or none] this phase. Here's what they deliver, what is blocked or deferred, and which allocation still needs confirmation. Existing agreed work remains agreed; changes need the appropriate decision authority."
 
 ## Artifact
 
-**`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.
+**`decisions.md`** - the triage table with scores, lanes, and proposed or agreed deferrals. Keep status and decision sources explicit. Update the same Now/Next/Later section plan already uses under the record-confirmation rules; do not open a second plan section. Standalone work returns the draft without initializing records.
 
-Required closing block (plan will not treat triage as done without it):
+For a recorded triage result, preserve this closing block. A draft may contain pending allocations and deferrals; missing agreement must not be filled with invented acceptance:
 
 ```markdown
 ## Triage - <date>
@@ -75,21 +75,21 @@ Required closing block (plan will not treat triage as done without it):
 ### Kill / defer (not this phase)
 | Initiative | Why not now | Who accepted |
 |------------|-------------|--------------|
-| ... | ... | <name, date> |
+| ... | ... | <pending, or supplied name, date and source> |
 
-Commitment: we ship only Now. Additions require a removal.
+Allocation: <proposed, or agreed with source>. Now contains only work feasible within the stated capacity and authority. Additions require a capacity and dependency check, and displacement when full.
 ```
 
 **`reality.md`** - if triage revealed that the engagement scope is larger than the timeline supports, update the assessment.
 
 ## Checkpoint
 
-Walk the FDE through: the 3 "Now" initiatives and why, the top "Next" items and what triggers their promotion, and the one initiative that will generate the most political pushback for being in "Later." Prepare the FDE for that conversation.
+Walk the FDE through: the proposed or agreed Now items and available capacity, the Next items and what enables their promotion, and any real trade-off requiring a decision. Explain an empty Now lane when applicable; do not fill it to satisfy the title.
 
 ## Principles
 
-- "Now" has 3 slots. Not 4. Discipline is the product.
-- Every addition requires a removal. Visible trade-offs beat invisible overload.
+- Now has at most three items and must fit actual capacity and dependencies.
+- Every addition requires a capacity check; displace work when full rather than silently overloading the team.
 - Triage is recurring, not one-time. The list changes; the discipline doesn't.
 - A logged override protects the FDE. An unlogged override blames them.
 - The initiative everyone wants but nobody will trade for is the one to watch.

package/skills/prioritize/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.

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

@@ -11,7 +11,7 @@
     "references/qa.md": "41de4d70827c83291efa217e97d777f62ec2849827687fbba7e4b1d17484b87e",
     "references/review.md": "8fa35eacdc04d5e818e046e6da8f61f126e08d9c6a1073b2eaa19f72d4bfea3a",
     "references/ship.md": "95f51772b29de6f7d174f1f7678f15d46a3a5327dcb8facb94288e27907ae92c",
-    "references/task-context.md": "9f995c1fe4d8a27d313b4c008a943fbcdd150029358c70b450dbbfb303a2666e",
+    "references/task-context.md": "3d59235f6b7092c41116457cc54e3e2e67fc0fba7b46b60279bd304be18b10cd",
     "references/verification.md": "8ee2502112a37eedfdacf929041e7b91e9e6fabb007408a1ee2e2992e3af6ff6"
   }
 }

package/skills/qa/references/task-context.md

@@ -3,6 +3,7 @@
 Use this contract for standalone methods and methods routed through `@fde`.
 
 - **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Fit the method to the engagement:** choose the smallest useful next action from the outcome, uncertainty, dependencies, consequence of failure, available access and time. Duration alone does not choose the process: a three-day production change may need more controls than a three-week prototype. Reuse the customer's tools, review cadence and approved evidence; load specialist methods only for a relevant decision or failure. For a simulation, use the supplied actors and constraints without inventing meetings or authority. Expand coordination when dependencies or risk require it, and simplify again when they are resolved. A deadline can reduce scope or change the proposed delivery stage; it cannot silently waive acceptance, data policy or release authority. Judge progress by the requested result and evidence, whether that is a working increment, a resolved decision or a validated finding; record volume is not progress.
 - **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
 - **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
 - **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.