mustflow 2.116.3 → 2.117.0

package/templates/default/locales/en/.mustflow/skills/agent-runtime-isolation-review/SKILL.md

@@ -0,0 +1,196 @@
+---
+mustflow_doc: skill.agent-runtime-isolation-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: agent-runtime-isolation-review
+description: Apply this skill when a long-running agent system must keep durable workflow state outside short-lived workers, split work across capability-specific queues, run model-directed shell, browser, file, package, or code activity in ephemeral sandboxes, inject narrow temporary credentials, broker production effects, and choose isolation by blast radius and maximum tolerable loss.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.agent-runtime-isolation-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Agent Runtime Isolation Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep state long-lived while keeping execution processes and authority short-lived. Separate the
+trusted control plane from model-directed compute so a worker crash, poisoned context, dependency,
+shell command, browser page, or credential misuse cannot inherit the lifetime and blast radius of
+the whole workflow.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- An agent runtime executes shell commands, code, package operations, browsers, files, previews,
+  data transformations, external tools, or untrusted content.
+- A logical task lasts longer than one process, container, sandbox, model context, credential, queue
+  lease, or worker allocation.
+- The design chooses between a long-lived process and durable workflow plus queued activities,
+  shared workers and per-task sandboxes, containers and stronger isolation, or direct production
+  credentials and a policy broker.
+- Isolation cost, startup cost, state rehydration, task granularity, retry loss, incident frequency,
+  blast radius, or maximum tolerable loss affects architecture.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main problem is generic durable workflow state, callbacks, timers, or compensation with no
+  model-directed execution plane; use `durable-workflow-orchestration`.
+- The main problem is broker acknowledgement, redelivery, ordering, DLQ, or worker loss; use
+  `queue-processing-integrity-review`.
+- The main problem is child-process timeout, output, argv, environment, or termination inside one
+  trusted execution boundary; use `process-execution-safety`.
+- The main problem is deciding whether multiple runtime agents outperform one; use
+  `agent-runtime-multi-worker-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Control-plane ledger: workflow state, event history, plan, policy, approvals, identities, budgets,
+  audit, billing, recovery, artifact registry, and which trusted service owns each item.
+- Execution-plane ledger: worker image and identity, sandbox type, lifetime, task input, mounts,
+  writable paths, output artifacts, processes, ports, packages, browser, network, and cleanup proof.
+- Queue ledger: capability class, admission, concurrency, priority, lease, heartbeat, timeout, retry,
+  cancellation, backpressure, worker pool, and production-mutation separation.
+- Credential ledger: issuer, subject, tenant, resource, effect, audience, expiry, call and cost limit,
+  injection path, revocation, persistence rule, and broker boundary.
+- Task-boundary ledger: independently verifiable outcome, serialized state, artifact references,
+  rehydration cost, failure and restart rate, idempotency, unknown outcome, compensation, and
+  checkpoint or split decision.
+- Isolation ledger: public versus private inputs, untrusted code or content, secret access, host and
+  network exposure, production authority, candidate isolation levels, direct and operating cost,
+  incident likelihood, expected loss, maximum loss, and organizational survival limit.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Identify the durable source of truth before shortening worker lifetime. Process memory, a browser
+  profile, a prompt transcript, or a sandbox filesystem is not durable workflow authority by itself.
+- Classify every input, mount, credential, network target, artifact, and external effect before
+  selecting an isolation level.
+- Refresh provider sandbox, runtime, pricing, persistence, credential, and network behavior before
+  embedding exact claims. Do not copy example costs, durations, or checkpoint formulas into policy.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  workers, sandboxes, packages, browsers, cloud mutations, or production credentials.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine control and execution plane separation, durable state, task queues, worker admission,
+  sandbox manifests, mounts, output directories, ephemeral credentials, network policy, artifact
+  validation, policy brokers, idempotent commit, cleanup, tests, docs, routes, and templates.
+- Replace persistent all-purpose workers with capability-specific pools or per-task sandboxes when
+  risk and operating evidence support the split.
+- Do not expose host-wide sockets, root authority, user home directories, long-lived cloud keys,
+  production database administration, or broad filesystem and network access to model-directed
+  compute as a convenience shortcut.
+- Do not treat a container boundary alone as authorization, tenant isolation, production approval,
+  or protection against every host escape.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Separate logical lifetime from process lifetime. Keep one durable workflow identity, event or
+   state history, approvals, budgets, and effect ledger across processes. Rebuild transient clients,
+   prompts, caches, browsers, and sandboxes for each admitted activity.
+2. Keep the control plane trusted. Let it own the agent loop, model routing, policy, approvals,
+   identity, audit, billing, recovery, and authoritative run state. Put model-directed file, shell,
+   package, browser, and preview work in an execution plane with narrower authority.
+3. Choose activity boundaries by recoverability, not arbitrary time or one model turn. A good unit
+   produces an independently verifiable artifact or state transition, can start from serialized
+   state and references, is safe to retry or reconcile, and does not repeat completed external
+   effects after failure.
+4. Balance unit size from local evidence. Count sandbox startup, serialization, queue, cache warm-up,
+   and rehydration cost against expected lost work, timeout, context contamination, and failure
+   recovery. Use measured restart and rehydration behavior; do not impose a universal duration.
+5. Route activities by capability. Separate read-only browsing, private-data reading, CPU build,
+   GPU work, package execution, and production mutation so concurrency, priority, network, image,
+   budget, and retry policy can differ. Do not let one general queue imply every capability.
+6. Build a minimal sandbox manifest. Mount only required inputs, default them to read-only, provide a
+   distinct bounded output area, use an allowlisted environment, declare packages and ports, and
+   exclude host caches, homes, sockets, credentials, and unrelated repositories.
+7. Keep credentials short-lived and task-scoped. Inject them at runtime from a trusted broker, bind
+   tenant, resource, effect, audience, expiry, and budget, prevent persistence in prompts, files,
+   snapshots, logs, images, and artifacts, and revoke them when the task ends or policy changes.
+8. Deny network by default where practical. Allow only declared package mirrors, data sources, APIs,
+   callbacks, or artifact stores. Apply DNS, redirect, private-address, credential-forwarding, and
+   egress policy at a trusted boundary rather than asking the model to comply.
+9. Validate artifacts before export. Check schema, hashes, provenance, sensitive content, executable
+   files, links, permissions, ownership, and expected output path before moving results into trusted
+   storage or a later workflow stage.
+10. Broker high-impact effects outside the sandbox. Let the worker propose a normalized change; let
+    a trusted policy service re-evaluate current identity, target, state, approval, idempotency, and
+    capability before executing or handing the action to a human.
+11. Make queued execution replay-safe. Persist intent before dispatch, keep effect identity stable,
+    use idempotency keys or reconciliation, heartbeat genuinely long work, fence stale workers, and
+    preserve UNKNOWN outcomes. Route broker settlement details to
+    `queue-processing-integrity-review` and workflow recovery to
+    `durable-workflow-orchestration`.
+12. Choose isolation from blast radius and maximum loss, not compute price alone. Compare direct and
+    fixed isolation cost with expected incident reduction, but exclude any level whose worst
+    credible loss exceeds the organization's declared survival limit.
+13. Match isolation to workload. Public read-only tasks with no secrets or host value may use a
+    lighter boundary; private repositories, untrusted pages, arbitrary packages, shell, browser, or
+    customer data need stronger task isolation; production IAM, payments, DNS, and destructive
+    infrastructure need a separate account, project, tenant, or brokered control plane as applicable.
+14. Verify teardown. Stop process trees, revoke credentials, close ports, expire leases, preserve
+    bounded diagnostics, export only admitted artifacts, and record whether filesystem, network,
+    mount, snapshot, and secret cleanup was confirmed or remains uncertain.
+15. Test containment and recovery. Cover worker crash before and after effects, stale lease,
+    duplicate delivery, unknown outcome, poisoned input, forbidden mount, blocked egress, expired
+    credential, secret-in-artifact rejection, sandbox escape signal, artifact tampering, cleanup
+    failure, and resume in a fresh worker.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Durable workflow truth survives worker and sandbox loss without depending on process memory.
+- Model-directed compute receives only task-scoped mounts, network, credentials, capabilities, and
+  lifetime.
+- High-impact external effects are revalidated and committed by a trusted broker with idempotency or
+  reconciliation.
+- Isolation choice accounts for blast radius and maximum tolerable loss as well as direct cost.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer raw container, VM, queue, browser, cloud, package, network, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If durable truth lives only in one process or sandbox, stop claiming resumability.
+- If credential, mount, network, or output scope cannot be bounded, keep the task manual or move it
+  to a stronger isolated environment.
+- If an external effect lacks idempotency or outcome reconciliation, disable automatic replay and
+  preserve manual-review state.
+- If cleanup cannot be confirmed, quarantine the environment and revoke authority before reuse.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Control and execution plane boundary
+- Durable state, activity, queue, worker, and artifact decisions
+- Sandbox, mount, network, credential, and cleanup contract
+- Policy broker, idempotency, reconciliation, and high-impact effect boundary
+- Isolation cost, blast radius, maximum loss, and survival-gate findings
+- Command intents run and skipped checks
+- Remaining agent-runtime isolation risk

package/templates/default/locales/en/.mustflow/skills/agent-runtime-multi-worker-review/SKILL.md

@@ -0,0 +1,180 @@
+---
+mustflow_doc: skill.agent-runtime-multi-worker-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: agent-runtime-multi-worker-review
+description: Apply this skill when a production LLM agent runtime may use several agents or workers and must decide whether independent parallelism justifies coordination cost, then define orchestrator-worker topology, specialized roles, capability separation, artifact ownership, independent evidence, correlated-error controls, bounded fan-out, and central verification.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.agent-runtime-multi-worker-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Agent Runtime Multi-Worker Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Use multiple runtime agents only when independently solvable work, parallel context capacity, or
+specialized tools create more accepted value than planning, communication, duplication, ownership,
+and correlated-error cost. Keep the default architecture single-agent until evidence supports the
+extra topology.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A production agent runtime adds lead agents, managers, worker agents, peer agents, debate,
+  independent reviewers, candidate generators, judges, or distributed research workers.
+- A task may split by source, customer, document set, package, hypothesis, candidate solution, or
+  another independently verifiable work unit.
+- The design must choose worker count, topology, role diversity, task ownership, communication,
+  artifact handoff, result aggregation, verification, or stop conditions.
+- A claim says multi-agent execution improves quality, coverage, throughput, latency, or reliability
+  enough to justify extra tokens, infrastructure, coordination, and failure surface.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Several coding agents coordinate files, worktrees, commands, and merges for one repository task;
+  use `multi-agent-work-coordination`.
+- One runtime parent already has a justified child set and the main risk is join, cancellation,
+  deadlines, cleanup, or late results; use `structured-concurrency-supervision-review`.
+- The main risk is durable resume, queues, short-lived workers, or sandbox isolation; use
+  `agent-runtime-isolation-review`.
+- The main risk is tool authority, approval, external effects, or one agent's autonomy envelope; use
+  `agent-execution-control-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Work-unit ledger: total work, independent units, dependency graph, shared context, expected output,
+  independent validator, merge rule, and serial critical path.
+- Benefit ledger: single-agent baseline, coverage, quality, latency, throughput, task value, backlog,
+  and accepted-outcome improvement attributable to parallel workers rather than extra total compute.
+- Coordination ledger: planning, delegation, communication, context transfer, duplicate work,
+  conflict resolution, merge, verification, supervision, and fixed operating cost.
+- Topology ledger: orchestrator, workers, reviewers, verifier, allowed communication edges, worker
+  admission rule, fan-out and depth budgets, wait policy, cancellation, and terminal owner.
+- Role ledger: unique information, tools, model, search strategy, permissions, evaluation criterion,
+  artifact owner, and forbidden overlap for each role.
+- Correlation ledger: shared model, prompt, source, memory, retrieval, tool, evaluator, failure domain,
+  and how supposedly independent conclusions remain correlated.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Prove that at least one meaningful work unit can be completed and validated without continuous
+  access to another worker's hidden context.
+- Establish a single-agent baseline under a comparable total-compute and outcome contract before
+  attributing a gain to topology.
+- Do not copy benchmark worker counts, token multipliers, break-even sizes, or universal formulas
+  into runtime policy. Calibrate from the product's task distribution and operating evidence.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  worker spawning, model calls, production traffic, or background agent loops.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine worker admission, orchestrator-worker topology, delegation schemas, role and
+  capability boundaries, artifact stores, central verification, independent review, correlation
+  metrics, fan-out and depth budgets, cancellation, tests, docs, route metadata, and templates.
+- Replace peer-to-peer debate with bounded independent work and one aggregation owner when debate
+  does not provide unique evidence.
+- Do not add workers merely because a task is difficult, long, or uses many tokens.
+- Do not let several agents jointly own one authoritative artifact or external effect.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Start from the single-agent baseline. Record accepted outcomes, latency, cost, failures, and
+   context limits under the same task mix and total-compute accounting used for the candidate.
+2. Decompose by independently completable and verifiable work units, not by arbitrary prompt turns.
+   Reject parallelization when most steps share one evolving context, mutate the same authority, or
+   depend on subtle upstream judgment.
+3. Model the break-even qualitatively and quantitatively from local evidence. Count parallel quality
+   or time value, then subtract planning, communication, duplication, ownership misses, conflict,
+   verification, retry, and operating cost. If marginal benefit is non-positive, keep one agent.
+4. Prefer a star topology. Let one orchestrator issue bounded work orders, let workers return
+   independent artifacts or structured findings, and let one verifier or merge owner accept or
+   reject them. Avoid all-to-all conversation whose message count and repeated context grow rapidly.
+5. Give roles distinct information or capability. Separate sources, tools, models, search strategies,
+   permissions, hypotheses, or evaluation criteria. Multiple copies of one prompt and source set are
+   correlated samples, not independent experts.
+6. Define one owner per artifact and effect. Workers may propose or review; the named owner admits
+   the result, resolves conflict, and owns terminal state. Consensus does not erase accountability.
+7. Preserve independent judgment before aggregation. Do not reveal peer answers to reviewers before
+   their initial assessment when independence matters. Record shared failure domains and avoid
+   treating majority vote as strong evidence when errors are correlated.
+8. Use durable artifacts, not transcript relays. Store source-backed findings, patches, datasets,
+   reports, hashes, or typed records under stable references; pass lightweight references and
+   summaries to the orchestrator to reduce telephone-game loss and context duplication.
+9. Bound admission from task evidence. Set active worker, queued worker, depth, tool-call, token,
+   cost, and wall-clock budgets from expected independent units and resource capacity. Stop adding
+   workers when remaining units overlap, coordination dominates, or the verifier becomes the
+   bottleneck.
+10. Make completion policy explicit. Choose all-required, quorum, first-valid, best-of-N under an
+    external validator, or partial result. Define timeout, cancellation, late-result rejection,
+    missing-worker behavior, and which failures can preserve useful artifacts.
+11. Keep capabilities task-scoped and attenuation-only. A worker receives only the sources, tools,
+    resources, effects, budget, and lifetime needed for its work unit. Worker failure must not trigger
+    automatic privilege escalation.
+12. Verify centrally with deterministic checks first. Use tests, schemas, source agreement,
+    database state, checksums, invariants, or other independent evidence before an LLM judge. Keep
+    creator, reviewer, and final authority distinct for high-impact outcomes.
+13. Evaluate topology against the baseline. Attribute gains separately to extra compute, parallelism,
+    role specialization, tool diversity, and verifier quality. Measure duplication, handoff loss,
+    correlated failures, verifier load, orphan work, and cost per accepted outcome.
+14. Route runtime lifetime and sandbox design to `agent-runtime-isolation-review`; route child join
+    and cancellation mechanics to `structured-concurrency-supervision-review`; route outcome and
+    trajectory grading to `agent-eval-integrity-review`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Multi-worker execution is enabled only for independently solvable and verifiable units with a
+  measured advantage over a comparable single-agent baseline.
+- Communication is bounded, artifact ownership is singular, and correlated votes are not presented
+  as independent proof.
+- Fan-out, depth, capability, cost, wait, cancellation, and terminal ownership are explicit.
+- One central owner verifies and admits worker results.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer raw worker, model, queue, load, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If work units cannot be independently validated, serialize them under one owner.
+- If worker roles differ only by name, reduce the worker set or redesign the evidence split.
+- If communication or verification cost dominates the measured benefit, return to the single-agent
+  baseline.
+- If artifact or effect ownership is ambiguous, stop admission until one terminal owner is named.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Single-agent baseline and multi-worker decision
+- Independent work units, dependencies, and validators
+- Topology, roles, capabilities, communication, and artifact ownership
+- Correlation, fan-out, wait, cancellation, and terminal policies
+- Cost-per-accepted-outcome and attribution findings
+- Command intents run and skipped checks
+- Remaining runtime multi-worker risk

package/templates/default/locales/en/.mustflow/skills/automation-investment-case-review/SKILL.md

@@ -0,0 +1,173 @@
+---
+mustflow_doc: skill.automation-investment-case-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: automation-investment-case-review
+description: Apply this skill when deciding whether an AI agent, workflow automation, internal tool, or operational integration is economically worth building, expanding, replacing, or retiring by comparing expected cost per accepted outcome, human alternatives, supervision, failure recovery, maintenance, break-even volume, throughput value, effective lifetime, NPV, and independent safety gates.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.automation-investment-case-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Automation Investment Case Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Decide whether automation produces cheaper accepted outcomes, useful capacity, or strategic value
+after supervision, failure recovery, maintenance, redesign, and safety costs are included. Prevent a
+cheap model call or impressive throughput demo from being mistaken for a viable operating system.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A team asks whether to build, buy, expand, replace, or retire an AI agent, workflow automation,
+  integration, internal tool, or operational pipeline.
+- A proposal compares automation cost with human work, headcount, outsourcing, queue delay,
+  conversion, revenue, SLA, error cost, or throughput.
+- The decision needs expected cost per accepted outcome, break-even volume, implementation and
+  maintenance cost, effective lifetime, scenario analysis, discounting, or NPV.
+- A claimed saving excludes supervision, retries, manual review, incident response, rejected output,
+  redesign, vendor changes, security, compliance, or rollback cost.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only optimizes LLM token spend, prompt caching, model routing, or per-request inference
+  cost inside an already-approved product; use `llm-token-cost-control-review`.
+- The task only analyzes cloud infrastructure spend; use `cloud-cost-guardrail-review`.
+- The task only selects a vendor, framework, runtime, or platform; use
+  `technology-stack-selection` and use this skill only for the investment model.
+- The task only evaluates technical agent quality or safety; use the matching agent, eval, security,
+  privacy, or rollout skill. Economic return never overrides a failed safety gate.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Outcome contract: one accepted business outcome, rejection or correction rule, quality floor,
+  latency or SLA, volume, demand pattern, current backlog, and value owner.
+- Automation cost ledger: model, tool, API, compute, storage, network, observability, licenses,
+  implementation, integration, data preparation, eval, security, compliance, supervision, manual
+  review, failure recovery, incident response, support, maintenance, retraining, migration, and exit.
+- Human comparator: labor time and loaded cost, tooling, management, training, queue delay, error and
+  rework rates, review, escalation, coverage, turnover, and capacity constraints.
+- Reliability ledger: success, accepted without correction, accepted after correction, rejected,
+  silent failure, duplicate or harmful effect, rollback or compensation, incident probability, and
+  cost distribution.
+- Investment assumptions: up-front cost, recurring cost, volume scenarios, adoption ramp, effective
+  lifetime before redesign, discount rate, residual value, opportunity cost, and confidence range.
+- Safety gate: legal, privacy, security, authorization, irreversibility, human-oversight, audit, and
+  rollback requirements that must pass independently of ROI.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Define accepted outcome and the current alternative before comparing model or vendor prices.
+- Refresh price, wage, contract, volume, error, and lifecycle assumptions from current authoritative
+  sources when the decision is current or material.
+- Label unknowns and ranges. Do not turn a vendor benchmark, example number, or one pilot into a
+  universal production rate.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize
+  purchases, contracts, staffing changes, production rollout, or releases.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine decision records, assumptions, cost models, scenario tables, break-even analysis,
+  NPV models, evidence links, sensitivity analysis, safety gates, tests for calculation logic, docs,
+  route metadata, and synchronized templates.
+- Separate measured, quoted, estimated, inferred, and unknown values.
+- Do not embed universal numeric thresholds, vendor prices, wage rates, error rates, discount rates,
+  or useful-life assumptions in reusable policy.
+- Do not convert throughput into value unless demand, queue, revenue, SLA, risk, or another binding
+  constraint makes extra completed work valuable.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define one accepted outcome. Count the business result that passes the quality and safety bar,
+   not a model response, tool call, attempted task, or superficially completed workflow.
+2. Model automation expected variable cost per accepted outcome. Include ordinary execution,
+   supervision, review, retries, rejected work, failure recovery, rollback or compensation, and the
+   probability-weighted tail of incidents. Preserve distributions where rare failures dominate.
+3. Add fixed and step-fixed costs. Include design, implementation, integration, data work, evals,
+   security, compliance, rollout, training, change management, monitoring, maintenance, vendor and
+   model migrations, and decommissioning.
+4. Build the human or current-system comparator on the same outcome contract. Include loaded labor,
+   tools, review, rework, delay, error cost, escalation, management, training, and capacity limits.
+   Do not compare automation's perfect-path variable cost with a human's fully loaded cost.
+5. Separate substitution, assistance, and new capability. An assistant may save minutes without
+   removing a role; a new service may create demand rather than replace cost; a constrained queue may
+   make throughput valuable even when unit cost is higher.
+6. Value throughput only when a binding constraint exists. Tie added capacity to observed backlog,
+   avoided SLA penalties, faster cash collection, additional conversion or revenue, reduced risk,
+   or another evidence-backed outcome. Otherwise report it as unused headroom.
+7. Calculate break-even with ranges. Compare fixed investment with the expected per-accepted-outcome
+   advantage across conservative, base, and optimistic volume, quality, supervision, and failure
+   scenarios. Report when the denominator is zero, negative, or too uncertain for a meaningful
+   break-even point.
+8. Use effective lifetime, not accounting optimism. Estimate how long the automation remains useful
+   before a product redesign, policy change, provider change, data drift, integration replacement,
+   or maintenance burden requires material reinvestment.
+9. Discount scenario cash flows when timing matters. Show NPV and payback under explicit assumptions,
+   including ramp-up, delayed benefits, recurring maintenance, redesign, migration, and exit cost.
+10. Run sensitivity and threshold analysis. Identify which assumptions can reverse the decision:
+    accepted-outcome rate, review time, incident cost, volume, demand value, maintenance burden,
+    vendor pricing, lifetime, or discount rate. Ask for evidence on those first.
+11. Keep safety as a hard independent gate. Reject, narrow, or keep human execution when the design
+    cannot meet authorization, privacy, legal, irreversible-effect, audit, reconciliation, or
+    rollback requirements, even if the expected financial return is positive.
+12. Choose a reversible next step. Prefer a bounded pilot or shadow measurement that resolves the
+    largest decision uncertainty without creating an irreversible operational dependency. Define
+    the evidence required to expand, redesign, pause, or stop.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Automation and the current alternative use the same accepted-outcome definition.
+- Variable, fixed, supervision, failure, maintenance, redesign, and exit costs are visible.
+- Break-even, throughput value, effective lifetime, and NPV use explicit ranges and evidence levels.
+- Safety and legal feasibility remain hard gates independent of financial return.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`docs_validate_fast`, `test_release`, and `mustflow_check`. Use narrower configured calculation,
+data-quality, or decision-record checks when available. Do not infer purchasing, billing, staffing,
+production, deployment, or vendor commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If accepted outcome, comparator, volume, or safety gate is missing, report the case as
+  non-decision-ready instead of manufacturing a return.
+- If one uncertain assumption dominates the result, provide the threshold at which the decision
+  changes and propose the smallest measurement that can resolve it.
+- If benefits depend on unproven demand or queue value, separate operational capacity from financial
+  benefit.
+- If a positive case requires ignoring rare catastrophic loss, keep the tail risk explicit and hand
+  the safety decision to the named authority.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Accepted outcome and current comparator
+- Fixed, variable, supervision, failure, maintenance, redesign, and exit costs
+- Volume, quality, demand, lifetime, and discount assumptions with evidence levels
+- Break-even, payback, NPV, sensitivity, and throughput-value findings
+- Independent safety-gate result
+- Reversible next experiment and stop or expansion criteria
+- Command intents run and skipped checks
+- Remaining automation-investment uncertainty