mustflow 2.115.17 → 2.116.0

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.credit-ledger-integrity-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: credit-ledger-integrity-review
@@ -47,6 +47,7 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 - The task only reviews general business-rule placement without a balance, ledger, wallet, credit, point, or reconciliation surface; use `business-rule-leakage-review`.
 - The task only designs a generic lifecycle state machine with no ledger, amount, idempotency, balance, reservation, expiry, or reconciliation risk; use `state-machine-pattern`.
 - The task only reviews cache correctness for a non-balance value; use `cache-integrity-review`.
+- The task only reviews soft token, step, concurrency, request-count, or rate budgets that are not prepaid or money-equivalent; use the relevant LLM cost, agent execution, concurrency, or rate-limit skill.
 - The task requires production balance corrections, real refunds, data migrations, or direct database repair without explicit user approval and configured command support.
 
 <!-- mustflow-section: required-inputs -->
@@ -98,6 +99,7 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 16. Consume expiry lots deliberately. When credits expire, inspect FIFO, LIFO, earliest-expiry-first, or policy-specific lot allocation. Record lot-level consumption so later refund and audit can reconstruct the path.
 17. Race expiry and usage. Expiry batches must use the same ledger, lock, idempotency, and conditional update rules as user requests. Flag direct batch subtraction that bypasses wallet safeguards.
 18. Separate reservation from capture. Model reserved, captured, released, failed, expired, cancelled, and partially refunded states when credits are held before final purchase, fulfillment, or external payment completion.
+    - This ledger owns atomic reserve, capture, and release and the balance invariant. Commands and durable workflows may consume those operations but must not redefine balance availability, ownership, or accounting transitions.
 19. Draw allowed state transitions. Prevent arbitrary `status = REFUNDED`, `status = CAPTURED`, or `status = EXPIRED` writes. Each transition should have a guard, cause, effect, and idempotency rule.
 20. Preserve queue ordering or tolerate reordering. If deduction, cancellation, refund, or expiry events use a queue, prove user, wallet, or transaction-level ordering, or make each consumer robust to reordered events.
 21. Treat message redelivery as normal. Producers, queues, schedulers, and webhooks can duplicate events. Consumer-side ledger mutation must be idempotent with durable dedupe records.
@@ -117,6 +119,7 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 - The credit surface has balance, ledger-entry, source identity, atomicity, amount/unit, ownership, expiry/lot, reservation, queue/cache, audit, and reconciliation maps.
 - Any mutable-balance-only path, missing source key, weak idempotency comparison, non-atomic deduction, wrong lock target, float amount, hidden rounding policy, missing DB invariant, duplicate ledger risk, generic refund, expiry race, cache-trusted deduction, stale replica read, unaudited admin adjustment, or missing reconciliation is fixed or reported with evidence.
 - Tests or explicit verification cover the highest-risk concurrency, failure, duplicate, expiry, reservation, refund, cache, and reconciliation paths available in the current scope.
+- Soft operational budgets remain outside this ledger unless they represent prepaid or money-equivalent value.
 
 <!-- mustflow-section: verification -->
 ## Verification

package/templates/default/locales/en/.mustflow/skills/dual-write-consistency/SKILL.md

@@ -0,0 +1,170 @@
+---
+mustflow_doc: skill.dual-write-consistency
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: dual-write-consistency
+description: Apply this skill when one logical operation changes durable state and separately publishes, projects, calls, or writes to another independently committed system, including database-plus-broker outbox or inbox flows, CDC, relay workers, event application ledgers, split outcomes, eventual convergence, reconciliation, and crash-point verification.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.dual-write-consistency
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Dual Write Consistency
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep one logical result truthful when it crosses independently committed databases, brokers,
+indexes, files, or providers. Own the delivery and convergence protocol; do not pretend two commits
+are one transaction or that broker delivery alone proves business convergence.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A durable mutation and an event publish, projection update, webhook, provider mutation, or second
+  store write belong to one logical outcome but cannot commit atomically.
+- Code introduces an outbox, inbox, relay, CDC stream, publisher claim, applied-event ledger,
+  reconciliation worker, or eventual-convergence claim.
+- The path can crash between local commit, publish acceptance, publish recording, consumer effect,
+  consumer commit, and broker acknowledgement.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- One database transaction with no independent commit boundary owns the whole invariant; use
+  `transaction-boundary-integrity-review`.
+- The main failure is one logical request repeating; use `idempotency-integrity-review`.
+- The main failure is broker acknowledgement, visibility, prefetch, poison-message, or DLQ behavior;
+  use `queue-processing-integrity-review`.
+- The path is an old/new schema migration dual-write; use `migration-safety-check`.
+- The path is a multi-step resumable saga with waits or compensation; use
+  `durable-workflow-orchestration`.
+- Two writes happen in one local transaction, such as an order row and its audit row. That is not a
+  dual write merely because two tables changed.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Consistency-surface ledger: authoritative mutation, derived destinations, and every independent
+  commit boundary.
+- Identity ledger: operation, event, causation, correlation, aggregate, ordering, payload hash, and
+  schema-version identities.
+- Outbox and inbox ledger: unique keys, states, owner, claim lease, attempts, timestamps, and stale
+  claim recovery.
+- Delivery ledger: producer confirmation, consumer transaction, acknowledgement position,
+  duplication, ordering, and redelivery contract.
+- Convergence ledger: acceptable lag, drift detector, reconciliation owner, repair direction, and
+  operator-visible terminal or unresolved state.
+- Failure-injection ledger: expected durable state after every crash boundary.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the nearest instructions, command contract, source-of-truth model, producer, consumer,
+  persistence schema, and retry or replay paths.
+- Name one authoritative fact and every derived fact. If authority is peer-to-peer or bidirectional,
+  define conflict resolution before implementation.
+- Treat provider, broker, and database guarantees as unverified until matched to the configured
+  code path and current deployment contract.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten outbox, inbox, applied-event, relay-claim, delivery-state, drift-detection,
+  reconciliation, repair-command, and focused crash-injection surfaces.
+- Synchronize event envelopes, schemas, migrations, tests, docs, metrics, and templates that own the
+  same convergence contract.
+- Do not hide split outcomes behind a broad transaction wrapper, memory-only flag, best-effort log,
+  or broker exactly-once marketing claim.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Draw the logical operation and every independent commit boundary.
+2. Choose the source of truth and label each destination authoritative, derived, cached, indexed,
+   externally owned, or observational.
+3. Put the authoritative mutation and outgoing intent record in one local transaction when that
+   store supports it. If not, name the unavoidable gap and repair protocol.
+4. Give each logical event a stable ID, causation ID, correlation ID, aggregate or ordering key,
+   payload hash, and schema version required by its consumers.
+5. Make relay claims durable and bounded. Record owner, lease or generation, attempt, next eligible
+   time, and stale-claim recovery; a process-local lock is not ownership proof.
+6. Treat a crash after publish but before publish-success recording as duplicate-possible. Resume by
+   identity and confirmation or reconciliation, not by assuming the publish failed.
+7. Put the consumer inbox or applied-event unique constraint and irreversible business effect in one
+   transaction when possible. An application-level `if exists` is not durable uniqueness.
+8. Separate per-aggregate ordering from globally unordered delivery. Reject or defer stale events
+   when state depends on sequence; make commutative consumers explicit when order is irrelevant.
+9. Preserve original identity through poison classification, schema rejection, DLQ transfer, and
+   replay. A replay creates a new attempt, not a new logical event.
+10. Define reconciliation for missing, duplicate, stale, unknown, and divergent states. State which
+    side wins, which repair command runs, who approves destructive repair, and how convergence is
+    rechecked.
+    - This skill owns delivery, consumer-application, and projection convergence across independent
+      commits. Route workflow-step, terminal-state, and compensation-state recovery to
+      `durable-workflow-orchestration`.
+11. Distinguish transport settlement, consumer commit, business convergence, and operator closure.
+    Do not report one as proof of the next.
+12. Inject crashes after local commit, before and after publish, after consumer effect, after consumer
+    commit, and before acknowledgement. Also test duplicate, reordered, poison, stale-lease, and DLQ
+    replay paths.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every crash point leaves the operation durably pending, duplicate-safe, reconciliable, or
+  explicitly unresolved; no state silently disappears.
+- Relay and consumer ownership, event application, and repair are protected by durable identities,
+  constraints, leases or generations, and bounded retries.
+- Outbox-only implementations do not claim completion without consumer duplicate control and a
+  reconciliation story.
+- Evidence distinguishes local commit, delivery, application, convergence, and closure.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+- Use configured `changes_status` and `changes_diff_summary` for scope evidence.
+- Use `lint`, `build`, and `test_related` for changed implementation and focused crash paths; use
+  `test` or `test_audit` when shared reliability coverage or test claims require it.
+- Use `docs_validate_fast`, `test_release`, and `mustflow_check` when contracts, templates, package
+  output, or Mustflow surfaces change.
+- Record unavailable broker, multi-process, chaos, or live-provider evidence instead of inventing
+  commands or approving a static claim as runtime proof.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the source of truth or repair direction is unknown, stop convergence edits and report the
+  conflicting authorities.
+- If one split outcome cannot be detected, preserve it as an explicit unknown state and add an
+  operator repair boundary before claiming safety.
+- If an implementation relies only on an outbox, broker exactly-once mode, Redis TTL, logs, or an
+  application check, report the missing durable consumer or reconciliation proof.
+- If verification fails, preserve the crash point and invariant, then use `failure-triage` before
+  broadening the change.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Logical operation, source of truth, and independent commit boundaries
+- Event identity, outbox, relay, inbox, ordering, settlement, and convergence decisions
+- Crash, duplicate, stale-owner, poison, replay, and reconciliation evidence
+- Files changed and compatibility impact
+- Command intents run, skipped checks, and reasons
+- Remaining split-brain or convergence risk

package/templates/default/locales/en/.mustflow/skills/durable-workflow-orchestration/SKILL.md

@@ -0,0 +1,167 @@
+---
+mustflow_doc: skill.durable-workflow-orchestration
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: durable-workflow-orchestration
+description: Apply this skill when one business outcome spans multiple commands, persisted entities, services, callbacks, timers, approvals, retries, or compensations and must resume after process loss or deployment through a versioned durable workflow instance.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.durable-workflow-orchestration
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Durable Workflow Orchestration
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Own long-running progress across several transaction and resource boundaries. Make workflow state,
+waits, retries, compensation, forward recovery, resume compatibility, and operator intervention
+durable without pretending external effects can be rolled back like one database transaction.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- One business goal crosses two or more commands, persisted entities, services, or providers.
+- The flow waits for callbacks, timers, approvals, retries, leases, or human intervention.
+- A process restart or deployment must resume the exact safe step without repeating completed
+  external effects.
+- The design uses a saga, process manager, workflow instance, durable checkpoint, compensation, or
+  manual-recovery state.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- One accepted intent and local commit boundary is the whole operation; use `command-pattern`.
+- One entity transition table owns the lifecycle; use `state-machine-pattern`.
+- The main failure is a database-and-publish split; use `dual-write-consistency`.
+- The main failure is queue settlement, duplicate logical delivery, or child-task lifetime; use
+  `queue-processing-integrity-review`, `idempotency-integrity-review`, or
+  `structured-concurrency-supervision-review` respectively.
+- LLM autonomy, tool choice, or approval of model-directed work is the main concern; use
+  `agent-execution-control-review` and apply this skill only to the durable workflow underneath it.
+- An order with one local `PENDING -> PAID -> SHIPPED` transition table is not automatically a
+  durable workflow. A callback-driven payment and fulfillment process across checkpoints is.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Workflow identity and definition-version ledger.
+- Step ledger: input snapshot, command ID, dependency, deadline, attempt, owner, allowed next events,
+  and durable completion evidence.
+- Effect classification ledger: `reversible`, `compensatable`, `forward-recovery-only`, or
+  `manual-intervention`.
+- Checkpoint and resume-compatibility ledger for code, state schema, configuration, and policy.
+- Compensation ledger linking each compensating command to its original effect and idempotency key.
+- Timer, lease, cancellation, late-event, terminal-state, and reconciliation ledgers.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the nearest instructions, command contract, participating commands and state machines,
+  persistence model, queue or timer path, external effects, operator tools, and current tests.
+- Name the business outcome and every independently owned participant before designing the workflow.
+- Treat a compensation as a new effect with its own failure modes, never as time reversal.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten workflow instances, step records, checkpoints, timers, leases, compensation
+  commands, resume compatibility, cancellation, manual-intervention, reconciliation, tests, metrics,
+  docs, and directly synchronized templates.
+- Keep individual command payloads and entity transition rules in their owning command and state
+  machine layers.
+- Do not serialize arbitrary runtime objects, closures, clients, credentials, hidden reasoning, or
+  raw conversations as workflow state.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. State the business outcome and list each participant, transaction boundary, external effect, wait,
+   callback, timer, and operator decision.
+2. Check whether one command or one entity state machine is sufficient. Do not introduce a durable
+   workflow for a local sequence that cannot survive or need process loss.
+3. Create a stable workflow instance ID and pin the workflow definition, state schema, code,
+   configuration, and policy versions required for safe resume.
+4. Record each step's normalized input snapshot, command identity, dependency, deadline, attempt,
+   owner, next permitted events, and durable completion evidence.
+5. Persist step completion and the next durable work request atomically where possible. Route any
+   independent commit split through `dual-write-consistency`.
+6. Classify every effect as reversible, compensatable, forward-recovery-only, or
+   manual-intervention. Do not label email, payment, published data, or external user-visible effects
+   rollback-safe without provider-specific proof.
+7. Model compensation as a separate idempotent command tied to the original command, resource,
+   amount or scope, workflow instance, and reason. Give compensation its own retry and terminal state.
+   Use a distinct operation type and idempotency namespace or key for the compensation; never reuse
+   the original effect key without an explicit operation discriminator.
+8. Store semantic workflow state and ledger positions in checkpoints. Rebuild runtime clients and
+   transient caches on resume instead of serializing them.
+9. On resume, verify workflow definition, schema, code, configuration, and policy compatibility.
+   Migrate, continue under the pinned version, or stop for intervention; never guess through drift.
+10. Fence stale owners and reject late callbacks, timers, or completions from an older workflow
+    generation or already-closed step.
+11. Define cancellation separately from compensation. State which pending work stops, which accepted
+    external effects continue, which compensations start, and when cancellation becomes terminal.
+12. Preserve partial completion and compensation failure as observable outcomes such as
+    `FORWARD_RECOVERY_REQUIRED` or `MANUAL_INTERVENTION`, not generic failure or false rollback.
+13. Test restart before and after every step, duplicate and late completion, version drift, timer
+    expiry, stale owner, cancellation, compensation failure, reconciliation, and manual resume.
+    - This skill owns workflow-step, terminal-state, and compensation-state recovery. Route
+      delivery, consumer-application, and projection convergence across independent commits to
+      `dual-write-consistency`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every step has durable identity, owner, state, version, and completion evidence.
+- Resume does not silently replay an already completed external effect.
+- Every reachable branch terminates as succeeded, compensated, forward-recovery-required,
+  cancelled with declared residual effects, or manual-intervention.
+- Workflow orchestration does not replace command, state-machine, delivery, ledger, or policy owners.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+- Use configured `changes_status` and `changes_diff_summary` for scope evidence.
+- Use `lint`, `build`, and `test_related` for implementation and restart fixtures; use `test` or
+  `test_audit` when orchestration is shared or test coverage claims are broad.
+- Use `docs_validate_fast`, `test_release`, and `mustflow_check` for public, package, template, or
+  Mustflow changes.
+- Report unavailable multi-process, deployment-resume, clock, provider, or operator evidence rather
+  than replacing it with raw commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If participant ownership or compensation semantics are unknown, stop workflow expansion and list
+  the missing business decisions.
+- If resume compatibility is unprovable, preserve the run under manual intervention rather than
+  loading it into new code optimistically.
+- If compensation can fail without a terminal recovery path, report the workflow as incomplete.
+- If a configured check fails, preserve the workflow state and failure boundary, then use
+  `failure-triage` before broadening the edit.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Workflow goal, instance identity, definition version, participants, and boundaries
+- Step, checkpoint, timer, lease, cancellation, and resume decisions
+- Effect classifications, compensation commands, and terminal outcomes
+- Restart, duplicate, late-event, drift, compensation, and manual-recovery evidence
+- Files changed and compatibility impact
+- Command intents run, skipped checks, and remaining durable-workflow risk

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

@@ -0,0 +1,161 @@
+---
+mustflow_doc: skill.execution-ledger-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: execution-ledger-integrity-review
+description: Apply this skill when runs, attempts, leases, approvals, checkpoints, tool or provider effects, receipts, terminal outcomes, resume, reconciliation, or replay depend on an append-only execution ledger rather than ordinary logs or session handoff summaries.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.execution-ledger-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Execution Ledger Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep execution history truthful enough to explain, resume, reconcile, and safely replay decisions.
+Record observable inputs, actions, approvals, attempts, effects, checkpoints, and outcomes without
+turning hidden reasoning, secrets, raw conversations, or full logs into durable authority.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A system must later prove which run, attempt, lease owner, checkpoint, approval, effect, or terminal
+  outcome happened.
+- Resume or reconciliation depends on an operation ledger, execution ledger, semantic checkpoint,
+  effect receipt, result digest, provenance, or replay record.
+- A reliability claim depends on durable execution facts rather than ordinary trace or log lines.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is ordinary logging or trace-field quality; use `backend-log-evidence-review` or
+  `observability-debuggability-review`.
+- The record is a coding-session handoff; use `restricted-handoff-resume`.
+- The record is a credit, payment, accounting, or business balance ledger; use the corresponding
+  ledger-integrity skill.
+- The main concern is duplicate acceptance, workflow step order, compensation, or policy evaluation;
+  use `idempotency-integrity-review`, `durable-workflow-orchestration`, or
+  `policy-decision-integrity-review` respectively.
+- A request ID in logs is not an execution ledger, and an idempotency key alone does not prove which
+  attempt performed an external effect.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Execution identity ledger: run, parent run, logical action, attempt, causation, and correlation.
+- Input and version ledger: safe input digest plus code, configuration, policy, model, provider,
+  tool, and schema versions required to interpret the result.
+- Action and effect ledger: selected action, safe argument digest, approval, effect identity, and
+  pre-effect intent record.
+- Attempt and outcome ledger: owner or lease, start, result digest, receipt, unknown or partial
+  outcome, terminal classification, and supersession.
+- Checkpoint, integrity, retention, privacy, replay, and reconciliation ledgers.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the nearest instructions, command contract, execution path, persistence schema, checkpoint
+  and resume code, effect boundaries, privacy policy, replay path, and current tests.
+- Separate audit, resume, reconciliation, and replay requirements. Do not add an event-sourced domain
+  model when only execution evidence is needed.
+- Treat stored summaries and traces as derived evidence below current source, policy, and durable
+  receipts.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten execution identities, append-only entries, sequence or hash links, lease generations,
+  semantic checkpoints, effect receipts, terminal outcomes, replay inputs, reconciliation, retention,
+  redaction, focused tests, docs, and directly synchronized templates.
+- Add public projections or exports only with their owning public-contract procedure.
+- Do not store hidden reasoning, raw prompts, raw conversations, full terminal output, credentials,
+  secret-bearing tool payloads, or unbounded provider responses as ledger evidence.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. State whether the ledger supports audit, resume, reconciliation, replay, or a bounded combination.
+2. Define stable run, parent, logical action, attempt, causation, correlation, approval, and effect
+   identities. Do not collapse a retry attempt into a new logical action.
+3. Record safe input digests and every code, configuration, policy, model, provider, tool, and schema
+   version needed to interpret the decision and result.
+4. Keep model, provider, and tool content minimal: safe normalized fields, evidence pointers, and
+   digests. Redact or omit raw sensitive payloads before persistence.
+5. Bind approval to the exact actor, resource, action, arguments or digest, policy decision, version,
+   expiry, and effect that it permits.
+6. Append an accepted intent before an external effect and append the observed outcome afterward.
+   Preserve a gap or unknown outcome if the process dies between them.
+7. Separate logical action state from attempts. Record owner, lease or generation, attempt number,
+   deadline, retry reason, supersession, and the terminal attempt that owns the outcome.
+8. Treat timeout or missing response as unknown, not failed, until provider lookup, durable receipt,
+   or reconciliation establishes the result.
+9. Store semantic state and the last committed ledger position in a checkpoint. Reconstruct runtime
+   objects and verify pending effects on resume.
+10. Enforce append-only ordering with unique identities, monotonic sequence or equivalent causal
+    links, durable constraints, and tamper or truncation detection appropriate to the threat model.
+11. Make terminal outcomes monotonic. A late attempt cannot overwrite a succeeded, cancelled,
+    superseded, or manual-review result without an explicit corrective entry.
+12. Replay pure decisions against pinned inputs and inject recorded observations for external calls.
+    Never make replay re-send email, charge money, mutate providers, or publish events implicitly.
+13. Test missing entries, partial append, duplicate outcome, stale lease, late attempt, version drift,
+    unknown provider result, checkpoint gap, tampering, retention expiry, and replay side-effect blocks.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every observable effect links to a logical action, attempt, owner, approval when required, and
+  result or explicit unknown outcome.
+- Resume cannot skip a ledger gap, stale lease, version mismatch, or unresolved effect silently.
+- Replay does not execute external mutations and reports version drift instead of false equivalence.
+- Retained evidence is bounded and privacy-safe without relying on hidden reasoning or raw logs.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+- Use configured `changes_status` and `changes_diff_summary` for scope evidence.
+- Use `lint`, `build`, and `test_related` for implementation and ledger failure fixtures; use `test`
+  or `test_audit` for shared ledger or coverage claims.
+- Use `docs_validate_fast`, `test_release`, and `mustflow_check` for public exports, package, template,
+  or Mustflow changes.
+- Report unavailable database fault injection, provider reconciliation, tamper testing, or retention
+  expiry evidence rather than inventing commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If run, action, attempt, or effect identity cannot be separated, stop replay or resume claims and
+  report the ambiguous identity.
+- If a ledger gap or unknown effect cannot be reconciled, preserve manual-review state; do not mark
+  the run failed and retry automatically.
+- If safe evidence requires storing secrets or raw transcripts, redesign the evidence pointer or
+  digest before persistence.
+- If verification fails, preserve the ledger invariant and use `failure-triage` before changing
+  unrelated runtime code.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Audit, resume, reconciliation, and replay purposes reviewed
+- Run, action, attempt, version, approval, effect, checkpoint, and terminal-outcome decisions
+- Append-only, privacy, retention, unknown-outcome, and replay protections
+- Failure-injection and drift evidence
+- Files changed and public-contract impact
+- Command intents run, skipped checks, and remaining ledger-integrity 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: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: idempotency-integrity-review
@@ -50,6 +50,8 @@ The review question is not "is this POST protected?" It is "if the same business
 - The task is primarily stale shared state, lock scope, or generic interleaving with no duplicate logical operation or retry surface; use `race-condition-review` or `concurrency-invariant-review`.
 - The task is primarily swallowed failures, false success, timeout honesty, queue ack/nack honesty, fallback defaults, or public error contracts; use `failure-integrity-review`.
 - The operation is a pure read with no hidden write, usage charge, read receipt, analytics commitment, cache mutation that matters, external call, or durable side effect.
+- The main failure is divergence after two systems can commit independently; use `dual-write-consistency` first. Keep duplicate delivery and duplicate intent handling here.
+- The main failure is a lying or incomplete run, attempt, checkpoint, or effect receipt; use `execution-ledger-integrity-review`.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
@@ -133,9 +135,9 @@ The review question is not "is this POST protected?" It is "if the same business
     - Use business keys such as `settlement_date + merchant_id`, `campaign_id + user_id`, import file row identity, period key, or run source ID instead of loose "already processed yesterday" checks.
 16. Review outbox and inbox pairing.
     - DB change plus message publish can split when either side succeeds alone.
-    - Use an outbox for durable outgoing effects and an inbox or applied-event record for incoming duplicate delivery when the workflow crosses process boundaries.
+    - Route the convergence protocol for independently committed effects to `dual-write-consistency`. Keep inbox, applied-event, and duplicate-delivery handling in this skill.
 17. Review saga compensation.
-    - Compensation actions such as cancel, refund, release stock, revoke entitlement, or restore credits also need idempotency keys tied to the original action.
+    - Route compensation order and resumable saga state to `durable-workflow-orchestration`. Compensation actions such as cancel, refund, release stock, revoke entitlement, or restore credits still need idempotency keys tied to the original action here.
     - Double compensation can be worse than the original failure.
 18. Review `PROCESSING` and lease recovery.
     - A `PROCESSING` row without lease, heartbeat, timeout, owner, or reconciliation can permanently block retries after a crash.

package/templates/default/locales/en/.mustflow/skills/llm-token-cost-control-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.llm-token-cost-control-review
 locale: en
 canonical: true
-revision: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: llm-token-cost-control-review
@@ -50,6 +50,9 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - The main risk is cloud account, infrastructure, SaaS, quota, budget, tag, retention, or provider-account spend guardrails outside the model-call payload; use `cloud-cost-guardrail-review`.
 - The main risk is rate-limit fairness, throttling, quota counters, concurrency limits, 429 response behavior, or protected-resource definition; use `rate-limit-integrity-review`.
 - The task only edits user-visible copy and does not affect LLM payload, model choice, retry behavior, or cost telemetry.
+- The budget is prepaid, stored-value, or money-equivalent credit with reserve, capture, and release accounting; use `credit-ledger-integrity-review`.
+- The main contract is provenance for allow, block, downgrade, limit, or obligation decisions; use `policy-decision-integrity-review`.
+- The main contract is accepted-work reservation persistence; use `command-pattern`. This skill owns token estimates, caps, and cost-per-success evidence.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
@@ -67,6 +70,7 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - Output ledger: output schema size, repeated key length, patch versus full-output policy, `max_output_tokens`, reasoning budget, retry repair inputs, validator errors, and incomplete-response handling.
 - Routing ledger: deterministic prefilters, small-model router, expensive-model escalation rule, batch or flex eligibility, predicted-output eligibility, image or file preprocessing, and fallback behavior.
 - Observability ledger: input tokens, cached tokens when exposed by the provider, output tokens, reasoning tokens when exposed or billable, retry count, validation failure count, cache hit rate, cost per successful task, model, endpoint, prompt version, tool version, schema version, and budget breach events.
+- Boundary ledger: token estimates and caps owned here; accepted-work reservation persistence owned by `command-pattern`; prepaid or money-equivalent reserve, capture, and release owned by `credit-ledger-integrity-review`; allow, block, downgrade, and obligation provenance owned by `policy-decision-integrity-review`.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions

package/templates/default/locales/en/.mustflow/skills/migration-safety-check/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.migration-safety-check
 locale: en
 canonical: true
-revision: 8
+revision: 9
 lifecycle: mustflow-owned
 authority: procedure
 name: migration-safety-check
@@ -44,6 +44,7 @@ Keep migrations reversible, scoped, and verified before they affect data, schema
 - Documentation or final reports claim that backup, restore, cache rebuild, index rebuild, or analytics migration is safe, tested, repeatable, or complete.
 - Documentation or final reports claim that a migration is safe, complete, reversible, idempotent, or already applied.
 - A change could make older installed projects, existing lock files, generated files, caches, or user-edited documents incompatible.
+- Persisted workflow, checkpoint, run, attempt, or execution-ledger schema versions need an old-to-new transformation while preserving in-flight data.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -51,6 +52,7 @@ Keep migrations reversible, scoped, and verified before they affect data, schema
 - The change is a small local refactor with no persisted, generated, installed, or user data surface.
 - The task only edits inert documentation and makes no claim about applying or validating a migration.
 - The migration would require live production access, destructive actions, or manual operator approval that is outside the current command contract.
+- The task defines workflow progression, checkpoint semantics, compensation order, run truth, attempt truth, effect truth, or public JSON meaning. Use the owning workflow, execution-ledger, or public-contract skill; this skill owns only the old-to-new transformation.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
@@ -92,6 +94,7 @@ Keep migrations reversible, scoped, and verified before they affect data, schema
 1. Identify the migration surface and classify it as code, schema, data, configuration, template, generated state, cache, package metadata, or documentation.
    For content systems, also classify whether it touches inline page content, body files, frontmatter, lifecycle states, slug history, redirects, taxonomy, assets, facts, claims, sources, site exposure, search index, feeds, sitemaps, analytics events, exports, or public API projections.
 2. Record the source state, target state, expected affected paths, and whether the change must support old and new states during transition.
+   - For persisted workflow, checkpoint, run, attempt, or execution-ledger versions, preserve identity, ownership, terminal-state meaning, and referential links while transforming old records to the new schema. Do not redefine workflow semantics or ledger truth in the migration.
    - Prefer an expand, backfill, switch, and shrink sequence for live schema and API changes: add the new shape, support old and new reads or writes, migrate data, switch readers, then remove the old shape only after compatibility is proven.
    - Treat rollback as more than `down` migration. Distinguish schema rollback, data rollback, app rollback, and operational restore. A `down` file does not recover deleted or overwritten data unless the original values were preserved.
    - Prefer forward-only recovery for live systems: if a change fails after partial application, use a corrective migration or compatibility patch unless a tested restore path proves a rewind is safer.