mustflow 2.116.3 → 2.117.0

package/templates/default/locales/en/.mustflow/skills/growth-distribution-integrity-review/SKILL.md

@@ -0,0 +1,247 @@
+---
+mustflow_doc: skill.growth-distribution-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: growth-distribution-integrity-review
+description: Apply this skill when a product changes free-result watermarking or embedded attribution, public-share branding, affiliate or influencer compensation, partner attribution and clawbacks, recurring or lifetime commission, owned-product cross-promotion, portfolio promotion frequency, brand relationship disclosure, incremental acquisition, channel cannibalization, or retained portfolio contribution and must grow distribution without degrading the result users share, paying for natural demand, confusing product identity, or damaging the source product.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.growth-distribution-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Growth Distribution Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review embedded result attribution, commercial partners, and owned-product cross-promotion as
+different distribution mechanisms with one economic standard: incremental retained contribution
+after source-product harm, partner cost, fraud, support, privacy, and brand confusion. Do not turn
+useful output into an ad, grant perpetual commission for nonincremental demand, or call internal
+inventory free when it damages the product that owns the user relationship.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A free result adds, removes, resizes, relocates, or gates a visible service name, watermark, footer,
+  end card, attribution link, metadata mark, removal entitlement, or branded export.
+- A product recruits influencers, creators, affiliates, comparison publishers, agencies, resellers,
+  integration partners, or other commercial acquisition partners and changes fixed fees, CPA,
+  first-payment share, recurring commission, lifetime commission, attribution, or clawbacks.
+- One owned service recommends another through a dashboard, success screen, result surface, account
+  hub, email, notification, modal, interstitial, or contextual next step.
+- A report compares organic acquisition, affiliate CAC, external paid acquisition, cross-promotion,
+  brand lift, portfolio revenue, fatigue, cannibalization, or retained contribution.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a customer-to-customer referral reward, invite code, dual-sided incentive, reward tier,
+  valid-referral event, or self-referral control; use
+  `referral-incentive-integrity-review`.
+- The task is a paid ad or rewarded-ad placement inside a free tier, result gate, ad SDK, premium ad
+  removal, or ad-funded access decision; use `freemium-ad-monetization-review`.
+- The task only changes trademark ownership, generic visual identity, SEO, ad creative, marketing
+  copy, public-relations messaging, or analytics implementation with no distribution policy; use the
+  narrower brand, content, attribution, privacy, security, or data procedure.
+- The task requests jurisdiction-specific affiliate, advertising, tax, contract, privacy, or AI
+  marking advice. Use current qualified authority; this skill supplies the product evidence packet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Artifact ledger: result type, ownership, public or private use, export path, share rate, recipient
+  reach, attribution visibility and persistence, placement, removal, editability, accessibility,
+  quality, privacy, professional-use risk, and AI-origin or provenance requirement.
+- Partner ledger: partner identity and type, audience, channel, content lifetime, claimed reach,
+  attribution window and priority, click, signup, qualification, payment, refund, chargeback,
+  retained revenue, commission, cap, duration, termination, clawback, disclosure, approval, brand
+  safety, prohibited claim, support, tax, contract, and jurisdiction review.
+- Cross-promotion ledger: source and target product, user and job adjacency, product relationship,
+  placement, success state, eligibility, exposure sequence, frequency, suppression, account and data
+  continuity, consent, external-acquisition alternative, and source-product opportunity cost.
+- Causal ledger: pre-exposure assignment, persistent holdout, natural discovery, existing intent,
+  channel overlap, incremental activation and payment, retained contribution, cannibalization,
+  source-product completion and retention, complaints, hides, unsubscribes, and brand-understanding.
+- Economics ledger: partner and creative cost, net revenue, variable service and payment cost,
+  refund, chargeback, support, fraud, commission liability, source-product lost value, external CAC,
+  portfolio contribution, horizon, and uncertainty.
+- Version ledger: artifact policy, campaign, partner contract, attribution rule, disclosure, source
+  and target eligibility, frequency, suppression, experiment, and current authority version.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate embedded attribution, partner compensation, and owned cross-promotion. A shared growth
+  goal does not make their rights, risks, or attribution rules interchangeable.
+- Define the source product's completed value and the incremental target outcome before adding a
+  brand mark, partner payment, or cross-promotion exposure.
+- Assign experiments before the mark or promotion is visible where feasible, and preserve eligible
+  nonsharers, nonclickers, nonbuyers, and source-product abandoners in the relevant denominator.
+- Treat copied watermark sizes, share rates, commission percentages, attribution windows, lifetime
+  terms, exposure counts, fit scores, CAC, and conversion thresholds as hypotheses, not defaults.
+- Refresh current endorsement, advertising, consumer, privacy, accessibility, platform, tax,
+  contract, trademark, and AI-origin marking rules for the relevant role, content, channel,
+  geography, and date.
+- This skill does not authorize live marks, partner recruitment, contracts, payments, tracking,
+  cross-product data sharing, campaigns, experiments, messages, or production changes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine artifact branding eligibility, placement and removal, share and recipient events,
+  partner qualification and compensation, attribution, disclosure, fraud and clawback controls,
+  cross-promotion eligibility and suppression, relationship explanations, experiment assignment,
+  contribution metrics, fixtures, tests, docs, route metadata, and synchronized templates.
+- Replace universal watermarking, gross attributed revenue, last-click poaching, uncapped lifetime
+  commission, source-product interruption, or raw cross-product clicks with bounded rights and
+  causal portfolio economics.
+- Do not insert private identifiers or covert user tracking into exported artifacts, misrepresent
+  authorship, suppress required disclosure, transfer account data without authority, or impair the
+  result users completed merely to make brand removal a paid feature.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split the review into artifact attribution, partner compensation, and owned cross-promotion.
+   Evaluate each independently before comparing their contribution as acquisition channels.
+2. Define the headline result as incremental retained contribution per eligible source user or
+   acquisition opportunity over a declared horizon. Include target revenue and service cost,
+   partner cost, refunds, disputes, fraud, support, source-product lost value, and cannibalization.
+3. Classify the artifact. Estimate whether it is privately stored, internally circulated, sent to a
+   small known group, published repeatedly, or distributed to a broad public audience.
+   Do not infer reach from export count alone.
+4. Build the artifact acquisition path from created result to external share, unique recipient,
+   visible attribution, attributable visit, activated user, payer, and retained contribution. Keep
+   original-user conversion and retention loss in the same calculation.
+5. Use visible branding only when attribution can survive a real public distribution path and its
+   incremental value exceeds quality, sharing, conversion, accessibility, privacy, and support harm.
+   A watermark on a private or low-reach artifact is not a growth engine by default.
+6. Preserve the completed result. Keep branding outside critical content where possible, readable
+   but not dominant, accessible, and compatible with professional use. Never obscure evidence,
+   damage legibility, imply false authorship, or block export solely to force removal payment.
+7. Choose the least harmful attribution carrier that can work. A small footer, end card, adjacent
+   share link, or approved metadata can be a candidate; visible and machine-readable marks solve
+   different problems and neither proves compliance with every current AI-origin rule.
+8. Do not embed user, recipient, prompt, tenant, or private tracking data in exported files. Define
+   whether attribution survives editing, screenshots, transcoding, printing, and platform stripping,
+   and measure the actual recipient path rather than assumed virality.
+9. Classify the partner's continuing work. Short-lived sponsored reach, durable search or tutorial
+   content, ongoing implementation, reseller support, and customer-success work justify different
+   compensation shapes.
+10. Compare fixed production cost, qualified CPA, first-payment share, and bounded recurring share at
+    equal expected budget and qualification quality. Do not call a higher-spend arm more persuasive
+    without separating spend from contract shape.
+11. Calculate partner economics from incremental customers. Exclude or discount existing demand,
+    branded-search interception, leaked coupons, self-referral, duplicate partners, pre-existing
+    accounts, refund-window purchases, and customers who would have converted through another owned
+    or paid channel.
+12. Bind compensation to a qualified event and net revenue. Version attribution priority, window,
+    product scope, refund and chargeback treatment, tax, currency, minimum payout, cap, termination,
+    inactivity, content removal, and clawback before value vests.
+13. Treat lifetime commission as a long-lived liability, not a free acquisition rate. Use it only
+    when the partner continues to create attributable value or service after acquisition and the
+    agreement has explicit scope, activity, cap or review, termination, transfer, audit, and margin
+    protection. A bounded recurring term is a candidate, not a universal duration.
+14. Make commercial relationships clear and conspicuous near the endorsement or link as required by
+    current authority. Train and monitor partners, preserve content evidence, prohibit unsupported
+    claims, and define brand-safety escalation rather than relying only on a platform disclosure UI.
+15. Prevent attribution abuse with deterministic rules and multiple signals. Cover cookie stuffing,
+    forced redirects, toolbar or extension injection, trademark bidding, last-click poaching,
+    coupon leakage, fake leads, duplicate identities, self-dealing, and partner collusion while
+    preserving review and appeal for legitimate conflicts.
+16. Classify source-target fit before cross-promotion. Use audience overlap, adjacent user job,
+    brand promise, account and data relationship, and target readiness as evidence; ownership by the
+    same operator alone does not make two products relevant.
+17. Deliver the source product's primary value before promotion. Prefer a contextual next step after
+    success or in a clearly separate portfolio surface. Do not interrupt first value, active work,
+    checkout, cancellation, safety, privacy, or accessibility flows.
+18. Explain the relationship honestly. State whether the target is another product, an optional
+    companion, or part of a suite; do not imply shared entitlements, identity, data, support, or
+    warranties that the current contract does not provide.
+19. Make cross-product data movement explicit. Define consent, purpose, tenant and account boundaries,
+    deletion, suppression, and access before transferring user input or state. A click may deep-link
+    without silently provisioning or copying private data.
+20. Derive fatigue from marginal value by exposure sequence. Track incremental activation and target
+    contribution against source completion, retention, hides, complaints, unsubscribes, and support
+    after each exposure. Stop when marginal portfolio value is nonpositive; do not copy a universal
+    session, week, or month cap.
+21. Suppress irrelevant repetition. Stop or cool down after conversion, purchase, explicit rejection,
+    repeated nonresponse, source-product distress, target ineligibility, or relationship mismatch.
+    Keep campaign and suppression versions reconstructable across channels.
+22. Compare owned inventory with external acquisition using opportunity cost. Internal exposure is
+    not free: include source-product lost value, displaced product messages, creative and operations,
+    and portfolio cannibalization alongside the target's external incremental CAC.
+23. Use persistent holdouts where feasible to estimate natural sharing, partner incrementality, cross-
+    product discovery, and source-product damage. Observed clicks, attributed revenue, or users of two
+    products do not prove the channel caused portfolio growth.
+24. Promote only a reversible policy that improves incremental portfolio contribution while
+    preserving useful artifacts, honest commercial disclosure, deterministic attribution, partner
+    quality, source-product value, brand clarity, privacy, accessibility, and current authority.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Artifact attribution, partner compensation, and owned cross-promotion remain distinct contracts.
+- Visible branding is limited to an evidence-backed distribution path and does not degrade or
+  misrepresent the completed result.
+- Partner rewards use deterministic attribution, qualified net value, bounded liability, disclosure,
+  fraud controls, clawbacks, and review.
+- Cross-promotion follows source value, explains product relationships, respects account and data
+  boundaries, suppresses fatigue, and includes source-product opportunity cost.
+- Headline growth uses causal portfolio contribution rather than exports, impressions, clicks,
+  attributed gross revenue, or users observed in multiple products.
+
+<!-- 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 live export, affiliate, payment, tracking, campaign, analytics,
+cross-product data, messaging, deployment, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If recipient reach, partner qualification, or source-product damage cannot be measured, keep the
+  policy reversible and report association rather than claiming incremental acquisition.
+- If branding reduces utility, accessibility, privacy, sharing, conversion, or professional use more
+  than attributable retained contribution, remove or narrow it instead of optimizing removal sales.
+- If partner attribution cannot exclude existing intent, refunds, self-dealing, or channel overlap,
+  keep compensation pending or cap it under the current contract; do not grant unbounded liability.
+- If commercial disclosure, claim substantiation, tax, contract, or jurisdiction authority is
+  unresolved, do not launch or expand the affected partner treatment.
+- If cross-promotion improves the target while reducing source or portfolio contribution, reject or
+  narrow the placement even when click-through and target revenue rise.
+- If account or data relationships are ambiguous, use a separate optional link and do not transfer
+  identity or private state.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Artifact type, ownership, distribution path, recipient reach, attribution, placement, removal,
+  quality, accessibility, privacy, AI-origin, and contribution decision
+- Partner type, continuing work, qualification, compensation shape, equal-budget comparison,
+  attribution, disclosure, cap, duration, termination, clawback, fraud, and incrementality decision
+- Source and target product fit, relationship, placement, success state, account and data boundary,
+  frequency, suppression, source-product harm, external-CAC comparison, and portfolio decision
+- Experiment assignment, holdout, horizon, natural demand, cannibalization, retained contribution,
+  guardrails, and uncertainty
+- Files changed
+- Command intents run and skipped checks
+- Remaining growth-distribution risk

package/templates/default/locales/en/.mustflow/skills/idempotency-integrity-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.idempotency-integrity-review
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: idempotency-integrity-review
@@ -60,6 +60,9 @@ deduplicates the operation or rejects the stale result?"
 ## Required Inputs
 
 - Operation identity ledger: logical operation, attempt, effect, actor, tenant, target resource, business operation type, canonical payload hash, idempotency key, event ID, message ID, provider object ID, batch key, scheduler run key, and retry source.
+- Workflow identity ledger when plans can change: `workflow_id`, `plan_id` or plan version,
+  `step_id`, stable `effect_id`, per-try `attempt_id`, causation ID, correlation ID, and the rule that
+  decides whether a replan represents the same admitted business intent or a new one.
 - Ordering and authority ledger: aggregate key, ordering scope, observed state, expected state, aggregate version, sequence, generation, fencing token, gap policy, stale-result decision, and authoritative conditional write.
 - Side-effect ledger: every charge, refund, balance change, stock change, coupon issue, shipment, email, notification, entitlement, status transition, file write, queue publish, cache change, provider call, and audit entry.
 - Durable dedupe evidence: unique constraints, idempotency table, inbox table, outbox table, applied event table, ledger source key, conditional update, state guard, provider idempotency key, and response record.
@@ -93,7 +96,11 @@ deduplicates the operation or rejects the stale result?"
 1. Name the logical operation, not only the endpoint.
    - POST, PATCH, DELETE, webhook, queue consumer, scheduler, batch replay, retry wrapper, and callback handlers can all carry the same duplicate-intent risk.
    - Ask what "same intent" means in business terms: same order payment attempt, same refund, same point grant, same coupon redemption, same shipment, same notification, same state transition, same imported row, or same provider event.
-   - Separate the stable operation ID from attempt, message, event, effect, trace, worker, and provider IDs. Generate a new attempt ID for a retry without generating a new business operation.
+   - Separate the stable operation ID from attempt, message, event, effect, trace, worker, and provider IDs. Generate a new `attempt_id` for a retry without generating a new business operation.
+   - In a replanning workflow, keep `workflow_id` stable for the workflow, `step_id` stable for the
+     logical step when appropriate, `effect_id` stable for the same admitted business intent across
+     plan versions, and `attempt_id` new for each execution try. A new plan version is not permission
+     to create a duplicate effect.
 2. Start at the side effect.
    - Find calls and writes named like `charge`, `capture`, `refund`, `withdraw`, `grantPoint`, `deductStock`, `issueCoupon`, `sendEmail`, `createShipment`, `publish`, `ack`, `markPaid`, `fulfill`, and local equivalents.
    - For each side effect, ask what happens if the exact surrounding handler runs twice, runs concurrently, or runs after the first response is lost.
@@ -102,6 +109,12 @@ deduplicates the operation or rejects the stale result?"
    - Duplicate key plus changed amount, resource, user, tenant, product, operation, or payload should become a stable mismatch response, not a new operation or silent old response.
    - Do not accept memory-only stores, process-local maps, or Redis TTL alone for operations that can be retried after restart, failover, delayed callback, or TTL expiry.
    - Keep the operation key stable across request, durable operation record, inbox or outbox, external effect, result lookup, and response replay.
+   - Derive or mint keys at a trusted boundary. Do not place raw personal data, secrets, mutable
+     display names, timestamps, or model-generated prose in a key. Prefer opaque random or keyed
+     deterministic identifiers whose canonical request fingerprint is stored separately.
+   - Retain durable idempotency evidence for at least the longest supported client retry, queue
+     redelivery, delayed callback, workflow recovery, manual replay, and business dispute window.
+     Do not copy one universal TTL; name the owning lifecycle and expiry consequence.
 4. Require durable uniqueness at the operation boundary.
    - App-only `if exists return` followed by `insert` is a race. Use a unique constraint, atomic insert, upsert, conditional write, or durable ledger key.
    - Review migrations or schema definitions, not just service code, for keys such as `order_id`, `payment_id`, `refund_id`, `event_id`, `message_id`, `idempotency_key`, `campaign_id + user_id`, and `settlement_date + merchant_id`.
@@ -161,6 +174,9 @@ deduplicates the operation or rejects the stale result?"
 21. Review `PROCESSING` and lease recovery.
     - A `PROCESSING` row without lease, heartbeat, timeout, owner, or reconciliation can permanently block retries after a crash.
     - A stale processing record should recover by verifying side effects and either completing, failing safely, or allowing one fenced owner to continue.
+    - Preserve an explicit `UNKNOWN` or `RECONCILING` state when the external result cannot yet be
+      proved. Do not expire the idempotency record or mint a new effect while reconciliation or
+      manual review still owns the outcome.
 22. Review locks as helpers, not proof.
     - Distributed locks can expire, split ownership, or pause through stop-the-world events.
     - Keep durable uniqueness, conditional writes, state guards, idempotency records, or fencing tokens as the final defense.
@@ -176,6 +192,8 @@ deduplicates the operation or rejects the stale result?"
 ## Postconditions
 
 - The logical operation and attempt identities, duplicate sources, ordering aggregate, authority token, gap policy, stale-result decision, side effects, durable operation key, payload binding, response replay contract, timeout recovery, processing recovery, queue or webhook dedupe, scheduler or batch dedupe, outbox or inbox boundary, and adversarial tests are explicit.
+- Workflow, plan, step, effect, and attempt identities are separated where replanning exists, and the
+  same admitted business intent keeps one effect identity across plan versions.
 - Duplicate business requests, changed-payload key reuse, concurrent `exists` then `insert`, per-retry operation IDs, duplicate increments, timestamp ordering, sequence gaps, stale state overwrites, cancellation-as-rollback, single-flight-as-proof, provider timeout retries, pre-record external calls, duplicate webhook delivery, queue redelivery, scheduler reruns, double compensation, stuck processing rows, weak locks, and frontend-only guards are fixed or reported.
 - Duplicate safety claims are backed by configured tests, schema evidence, framework evidence, provider documentation matched to current code, or labeled as static review risk.
 

package/templates/default/locales/en/.mustflow/skills/llm-model-routing-integrity-review/SKILL.md

@@ -0,0 +1,183 @@
+---
+mustflow_doc: skill.llm-model-routing-integrity-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: llm-model-routing-integrity-review
+description: Apply this skill when an LLM system selects, cascades, escalates, falls back, or switches models by task, stage, confidence, verifier result, distribution shift, cost, latency, quality, safety, or context handoff and must optimize total cost per accepted outcome without hiding route-specific failures.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.llm-model-routing-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# LLM Model Routing Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose the least expensive model path that still satisfies measured outcome, latency, and safety
+requirements. Prevent a cheap per-call route from becoming expensive after retries and repairs, and
+prevent a strong-model default from becoming an unevaluated permanent tax.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A system adds or changes a model router, small-to-large cascade, escalation threshold, fallback,
+  provider or region route, stage-specific model, ensemble, speculative path, or confidence gate.
+- Planning, retrieval, coding, validation, summarization, classification, or tool-use stages may use
+  different models and context can be lost when the route changes.
+- Routing depends on cost, latency, accepted-outcome probability, external verifier results,
+  uncertainty, risk, task value, traffic volume, or distribution shift.
+- A claim says a smaller model is sufficient, a stronger model is worth the premium, or a routing
+  system pays for its own fixed evaluation and operating cost.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is prompt payload size, cacheability, token budgets, reasoning spend, or retry replay
+  rather than route correctness; use `llm-token-cost-control-review`.
+- The main risk is response speed, streaming, speculative cancellation, or time to first useful
+  output; use `llm-response-latency-review`.
+- The main risk is agent tool authority, approval, side effects, or autonomy; use
+  `agent-execution-control-review`.
+- The main risk is selling standard versus premium outcomes, charging for automatic escalation,
+  task-unit price, managed provider cost, or BYOK packaging; use
+  `llm-product-monetization-review`. Keep this skill for route correctness and total route cost.
+- The task chooses a provider or technology stack for strategic reasons rather than routing requests
+  among already supported models; use `technology-stack-selection`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Outcome contract: accepted task result, deterministic and semantic validators, safety floor,
+  latency objective, abstain or escalation state, and value or loss of a wrong result.
+- Route ledger: task and stage types, candidate models and versions, route features, baseline route,
+  escalation and fallback rules, context handoff, retry owner, route version, and stable assignment.
+- Evidence ledger: per-route accepted-outcome rate, confidence interval or conservative bound,
+  false-accept and false-reject rates, route coverage, sample size, task mix, risk mix, and evaluator
+  independence.
+- Cost and latency ledger: model, router, verifier, retry, repair, handoff, supervision, and fixed
+  evaluation, adapter, monitoring, migration, and maintenance cost.
+- Distribution ledger: training and evaluation distribution, production feature distribution,
+  missing-feature behavior, out-of-distribution detector, drift monitor, and safe fallback.
+- Safety ledger: tasks that require a fixed strong route, deterministic path, human decision, or
+  hard refusal regardless of expected financial utility.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Establish a capable-model baseline and accepted-outcome evaluator before claiming a cheaper route
+  preserves quality.
+- Treat model self-confidence, verbal certainty, token probability, and router score as uncalibrated
+  until matched to external outcome evidence on the current task distribution.
+- Refresh provider model, price, latency, retention, and endpoint claims before embedding exact
+  values. Do not copy benchmark percentages or universal thresholds into reusable policy.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  model calls, traffic routing, billing access, or production rollout.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine route schemas, features, baseline and candidate policies, external verifiers,
+  escalation and abstain states, context handoff, OOD fallback, metrics, eval fixtures, shadow
+  comparisons, tests, docs, route metadata, and synchronized templates.
+- Move deterministic classification, validation, policy, arithmetic, schema checking, and database
+  postconditions out of model routing when code can decide them.
+- Do not weaken quality or safety validators to make a cheaper route appear successful.
+- Do not route high-impact decisions by average utility when a hard safety or authorization gate
+  fails.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the accepted outcome before selecting a model. Include final-state correctness, safety,
+   latency, abstention, and repair rules rather than counting a syntactically valid response.
+2. Establish the baseline with the most capable practical route and current evals. Only then replace
+   bounded task classes or stages with smaller models where accepted outcomes remain sufficient.
+3. Route deterministic work to code first. Do not pay a model or router to decide values that a
+   schema, compiler, test, database lookup, permission engine, or exact rule can determine.
+4. Choose route granularity from real context boundaries. Keep tightly coupled planning and
+   execution on one model when switching would lose hidden constraints or require replaying most of
+   the context. Split classification, retrieval-query generation, formatting, or verification when
+   their inputs and outputs are explicit and independently checkable.
+5. Measure route quality with external evidence. Calibrate router scores against tests, schema and
+   business validation, source agreement, database postconditions, human adjudication, or another
+   independent oracle. Preserve false-accept cost separately from ordinary failure.
+6. Optimize total cost per accepted outcome. Include router, verifier, failed cheap attempts,
+   escalation, retries, repair, context transfer, supervision, latency loss, and fixed operating
+   cost. A lower model price is not a saving when acceptance falls or repair rises.
+7. Apply hard constraints before utility. Authorization, privacy, irreversible effects, safety
+   invariants, and maximum tolerable loss can force a deterministic, strong-model, human, or refusal
+   route even when a cheaper path has positive expected value.
+8. Build cheap-first cascades only when the acceptance gate can reject bad cheap outputs with known
+   false-accept behavior. Without an external verifier, repeated sampling and self-critique do not
+   prove which candidate is correct.
+9. Escalate from observed evidence, not model preference. Use validator failure, missing required
+   facts, task complexity, risk class, OOD state, repeated error signature, or explicit uncertainty
+   features. Do not escalate privileges when escalating model capability.
+10. Handle distribution shift explicitly. Compare production features and outcomes with the route's
+    evaluation distribution. Send missing, novel, drifted, or low-support cases to the safe baseline
+    route, deterministic review, or human owner.
+11. Account for context handoff loss. Version the handoff schema, preserve verified facts and hard
+    constraints, avoid summary-on-summary drift, and measure whether route switches cause omissions
+    or contradictory plans.
+12. Keep route and retry ownership separate. A route change may be a recovery action, but it must
+    share the workflow's attempt budget and idempotency state rather than restarting the task as a
+    new operation.
+13. Compare candidates in shadow or replay before promotion. Pin model and route versions, use the
+    same representative task mix, preserve delayed outcomes, and route rollout details through
+    `agent-release-bundle-rollout-review` when the router is part of an agent bundle.
+14. Recalculate routing economics when traffic, task distribution, models, prices, verifier quality,
+    repair rate, or maintenance burden changes. Route broad investment decisions to
+    `automation-investment-case-review`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every route has an accepted-outcome contract, external evidence, safe fallback, and versioned
+  decision reason.
+- Cost comparisons include failed attempts, verification, escalation, repair, context handoff, and
+  fixed operating cost.
+- OOD and hard-safety cases cannot silently enter a cheap route.
+- Model self-confidence is not treated as outcome probability without calibration.
+
+<!-- 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 provider, model, billing, traffic, eval, or rollout commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If no accepted-outcome evaluator exists, keep the baseline route and report the missing gate.
+- If route evidence is sparse or distribution support is missing, abstain from the cheaper route.
+- If false accepts can create high-impact harm, treat the route as unsafe until a hard gate or human
+  decision closes the boundary.
+- If route savings depend on stale price or benchmark data, mark the economic claim unverified.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Outcome contract and baseline route
+- Candidate route, features, version, and context boundary
+- External calibration, false-accept, OOD, and drift evidence
+- Total cost-per-accepted-outcome and latency findings
+- Hard safety, escalation, fallback, and abstain decisions
+- Command intents run and skipped checks
+- Remaining model-routing risk