mustflow 2.115.17 → 2.116.1

package/templates/default/locales/en/.mustflow/skills/parser-engineering-review/SKILL.md

@@ -0,0 +1,332 @@
+---
+mustflow_doc: skill.parser-engineering-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: parser-engineering-review
+description: Apply this skill when a lexer, tokenizer, grammar, parser, CST, AST lowering pass, operator table, error recovery path, incremental parser, Unicode source-position layer, large-input path, parser resource limit, or parser fuzz harness is created, changed, reviewed, debugged, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.parser-engineering-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Parser Engineering Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review parser pipelines as product boundaries rather than valid-input recognizers. Preserve source
+truth, produce stable trees and diagnostics, converge after edits, keep position units explicit, and
+fail within bounded CPU and memory on malformed or hostile input.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Lexer rules, modes, trivia, raw or cooked token values, or token spans change.
+- Grammar, parser algorithm, CST shape, AST lowering, operator precedence or associativity,
+  formatter grouping, or semantic handoff changes.
+- Invalid-input diagnostics, repair, synchronization, delimiter handling, or IDE recovery changes.
+- Incremental parsing, source buffers, changed ranges, cancellation, Unicode positions, streaming
+  decode, large-file behavior, parser limits, or fuzzing needs implementation or review.
+- A parser correctness, performance, or security claim needs current code and test evidence.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only consumes or edits an ordinary structured configuration file; use
+  `structured-config-change` or the closest installed route for that format.
+- The task is a broad hot-path or benchmark review with no parser boundary; use the applicable
+  performance skill.
+- The stable parse tree already exists and only domain-state or type modeling changes; use
+  `type-state-modeling-review` or the closest installed route.
+- The task only changes upload, archive, transport, or container limits outside the parser pipeline;
+  use the applicable security or boundary skill.
+- The task is cosmetic formatting with no parse-print, grouping, or source-preservation contract.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The bytes or text accepted, supported encodings, source-position consumers, and maximum expected
+  input size.
+- Lexer rules and modes, grammar or parser code, tree schemas, lowering and formatting paths, and
+  current valid and invalid fixtures.
+- The parser role: batch compiler, editor service, protocol boundary, configuration loader, query
+  engine, or another explicit consumer.
+- Existing resource limits, incremental snapshot model, diagnostics contract, fuzz harness, and
+  configured command intents.
+- For review-only work with incomplete inputs, continue from the supplied artifact only when the
+  visible lexer or parser boundary can support concrete findings. Mark every missing contract,
+  implementation path, fixture, and runtime result as unknown; do not turn those gaps into edits or
+  confirmed defects.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the nearest instructions and command contract before running project commands.
+- Decide whether the task changes language semantics, only implementation, or both. Do not silently
+  change accepted syntax, precedence, recovery, normalization, or compatibility behavior.
+- Record unknown encoding, recovery, or resource-limit behavior as unknown instead of inventing it.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Lexer, parser, grammar, token, CST, AST, lowering, formatter, diagnostic, source-buffer,
+  incremental-analysis, budget, and fuzz-harness files required by the selected parser boundary.
+- Focused fixtures, property tests, benchmarks, schemas, generated-parser inputs, and directly
+  synchronized documentation or templates.
+- Do not replace the parsing algorithm, normalize source text, or widen accepted syntax without
+  evidence that the compatibility, recovery, and resource contracts remain correct.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+### 1. Freeze the parser contract
+
+Write a compact ledger before editing:
+
+- Input boundary: bytes, decoded text, chunks, encoding, and full-consumption rule.
+- Output boundary: lossless CST, AST, semantic value, diagnostics, changed ranges, or combinations.
+- Operating mode: batch, interactive, streaming, strict, compatible, or recovery-first.
+- Compatibility boundary: accepted syntax, contextual keywords, newline rules, normalization, and
+  malformed-input behavior that callers already observe.
+- Risk boundary: expected size, maximum size, latency target, cancellation owner, and untrusted input.
+
+### 2. Map the real pipeline
+
+Trace bytes through decode, source storage, lexing, tokens and trivia, CST, AST lowering, semantic
+validation, formatting, and downstream analysis. Identify every place that copies, decodes,
+normalizes, expands, retries, caches, or converts positions. A limit on only the final parser input
+does not bound earlier transformations.
+
+### 3. Make source and position truth explicit
+
+- Use half-open byte spans as the canonical source anchor when an original byte stream is the input
+  contract. For a text-native host boundary, declare its canonical unit explicitly and retain a
+  lossless mapping to wire bytes whenever decoding, diagnostics, or security claims depend on them.
+  Keep byte offset, UTF-16 offset, Unicode scalar index, line index, and display column as distinct
+  types or named conversions; never compare them as interchangeable integers.
+- Preserve raw source separately from decoded or cooked token values. Maintain a mapping when
+  escapes, normalization, or decoding changes length.
+- Treat NUL as data unless the format forbids it. Recognize a BOM only where the format permits it,
+  normally at stream start. Define CRLF handling and avoid splitting UTF-8 sequences or UTF-16
+  surrogate pairs across chunks and edits.
+- Use grapheme clusters or display width only for user-interface columns. Do not make them the
+  parser's storage coordinate.
+
+### 4. Enforce lexer progress and fidelity
+
+- Require every lexer step to reach EOF, consume at least one input unit, or emit a bounded
+  synthetic token while changing state. An error token must cover real input unless it represents a
+  declared zero-width insertion.
+- Declare longest-match behavior and lexical precedence. Separate prefix, infix, postfix, trivia,
+  contextual keyword, and mode-specific decisions instead of relying on rule order folklore.
+- Make mode stacks and restart checkpoints serializable when incremental lexing is supported.
+- Preserve token raw spans, trivia, invalid bytes or characters, and recovery provenance needed by a
+  lossless CST and precise diagnostics.
+
+### 5. Separate CST, AST, and semantic meaning
+
+- Let a lossless CST account for every source byte exactly once through tokens, trivia, skipped
+  input, and error nodes. Represent missing tokens as zero-width nodes at a precise insertion point.
+- Lower CST to AST in a separate pass. Preserve explicit grouping when formatting, refactoring, or
+  diagnostics depend on the user's parentheses.
+- Keep name resolution, type rules, assignment validity, and other semantic rejection outside the
+  syntax layer unless the grammar contract explicitly owns them.
+
+### 6. Choose the parser algorithm from the operating contract
+
+- Prefer recursive descent with Pratt parsing for a new deterministic language with complex
+  expressions, readable recovery, and hand-maintained grammar.
+- Prefer PEG when ordered choice and long contextual prefixes are central, while budgeting memoized
+  state and making cuts or commits explicit.
+- Prefer IELR or LR when a large declarative grammar and conflict reports are more valuable than
+  hand-written control flow.
+- Use GLR only for genuine ambiguity that the product intends to preserve or resolve later. Budget
+  parse-forest growth and ambiguity work explicitly.
+
+Do not choose from a slogan such as "fastest parser." Judge recovery quality, output shape,
+incremental restart state, grammar evolution, ambiguity, and hostile-input cost together.
+
+### 7. Make operator behavior executable
+
+- Store each operator's left binding power, right binding power, fixity, chain policy, grouping
+  restrictions, and AST constructor in one executable table used by parser tests and formatter logic.
+- In a Pratt loop that continues while the next left binding power is at least the current minimum,
+  encode left associativity as `lbp = p, rbp = p + 1` and right associativity as
+  `lbp = p, rbp = p`. Verify the actual loop comparison before applying this formula.
+- Parse prefix, infix, and postfix roles separately. Treat calls, indexing, member access, and other
+  postfix forms as a repeatable chain.
+- Decide exponent-versus-unary binding, comparison chaining, non-associative operators, ternary or
+  mixfix delimiters, forbidden operator-group mixing, and newline restrictions explicitly.
+- Test AST shape for operator pairs and triples. Evaluation tests alone can hide a wrong tree when
+  values happen to coincide.
+
+### 8. Make speculation transactional
+
+Use mark, rewind, and commit semantics for ambiguous prefixes. Do not publish diagnostics, mutate
+symbol state, allocate irreversible semantic objects, or advance shared cursors before commitment.
+Bound speculative work and memoization under the same parser budget.
+
+### 9. Recover with bounded progress
+
+- At every recovery site, consume input, insert one declared missing token, synchronize to a bounded
+  set, or exit the current production. Cap insertions, deletions, repairs, diagnostics, and skipped
+  distance.
+- Make synchronization sets depend on grammar context and delimiter depth. Track open delimiters so
+  an inner error does not discard an outer construct.
+- Preserve Missing and Error nodes plus repair provenance. Suppress cascades that are downstream of
+  the same repair, but do not hide independent errors.
+- Emit structured diagnostics with stable code, primary span, related spans, expected items, repair,
+  and fix confidence. Never use a prettier message as a substitute for a correct span and tree.
+
+### 10. Prove incremental convergence
+
+- Use immutable, versioned snapshots. Apply the exact edit to the old tree and discard results whose
+  source version is stale.
+- Store enough restart state for lexical mode, delimiter or indentation context, and parser state.
+  Reparse until both token content and restart state converge; a fixed character radius is not a
+  correctness boundary.
+- Prefer relative subtree positions and aggregate lengths so a prefix edit does not rewrite every
+  following absolute offset. Use rope, piece-tree, or equivalent chunked storage instead of forcing
+  a full source string.
+- Make parsing cancellable and expose changed ranges. Invalidate downstream semantic dependencies
+  from those ranges rather than recomputing everything or trusting subtree reuse alone.
+- Compare incremental output with a fresh full parse after edit sequences, including edits near
+  quotes, comments, escapes, indentation, delimiters, and mode transitions.
+
+### 11. Bound storage and large-input work
+
+- Avoid per-callback or per-node source copies. Define whether callbacks borrow stable chunks and how
+  long those chunks remain valid.
+- Prefer compact nodes, arenas, tree buffers, and indexed side tables over one heavyweight object per
+  token or node. Measure retained source, token, tree, diagnostic, and downstream-analysis memory.
+- Support partial parsing only with a declared incomplete-tree contract and cancellation behavior.
+- Measure p50, p95, and p99 edit latency, bytes reread, nodes reused, allocations, post-processing
+  time, and peak memory. Throughput on one clean file is not incremental-performance evidence.
+
+### 12. Share one hostile-input budget
+
+Define one `ParseBudget` that follows the input through decode, decompression or expansion, lexing,
+parsing, recovery, and post-processing. Include applicable counters such as `wireBytes`,
+`decodedBytes`, `expandedBytes`, `tokenCount`, `nodeCount`, `maxDepth`, `maxContainerItems`,
+`scalarBytes`, `numberDigits`, `workUnits`, and a deadline.
+
+Declare what charges each counter, whether the charge occurs before allocation or side effects, and
+the stable error returned on exhaustion. Pass the same budget object or a bounded child view through
+nested and composed parsers; do not reset counters at transformation or subgrammar boundaries.
+
+- Count while reading or producing data, not after materializing it. Bound expansion by absolute
+  bytes, ratio, operation count, and nesting depth.
+- Bound breadth as well as nesting: token count, node count, container items, scalar length, numeric
+  digits, repairs, diagnostics, and retained chunks.
+- Charge work units for scans, backtracking, memo entries, ambiguity branches, decode operations, and
+  recovery attempts. A wall-clock timeout is a final stop, not the primary complexity model.
+- Use a linear-time regular-expression engine or structurally safe patterns for untrusted text.
+  Streaming does not remove token-count or retention limits.
+- Validate and execute the same immutable parse result for the same source version. Reusing the same
+  parser implementation for an unvalidated second parse is not sufficient. If reparsing is
+  unavoidable, revalidate input identity, source version, limits, and the exact result before any
+  side effect. Isolate complex native or generated parsers in a process when a crash or memory fault
+  must not take down the caller.
+- Apply aggregate concurrency budgets, bounded logs, and no automatic retry for deterministic parser
+  exhaustion.
+
+### 13. Build a parser-specific test matrix
+
+Cover all applicable lanes:
+
+- Valid corpus, invalid corpus, and near-valid single insert, delete, and replace mutations.
+- Token-span coverage, lossless CST reconstruction, parse-print-parse grouping, and full-consumption
+  properties.
+- Operator pair and triple AST matrices, postfix chains, ternary forms, comparison chains, and
+  forbidden mixes.
+- Full-parse versus incremental-parse differential tests over versioned edit sequences.
+- One-shot input versus multiple chunk partitions, including boundaries inside multibyte sequences,
+  escapes, numbers, comments, and delimiters.
+- Normalized differential oracles against an independent implementation when available, plus
+  round-trip and metamorphic properties that do not require identical internal trees.
+- Structured grammar-aware mutation, sanitizer or fault-injection lanes where supported, and
+  boundary cases immediately below, at, and above every budget.
+- Growth-rate checks for time, work units, allocations, and retained bytes. Preserve the triggering
+  phenomenon while shrinking failures, then keep the minimized input as a regression seed.
+
+### 14. Implement the narrowest complete correction
+
+Change the smallest owning layer that restores the contract, then synchronize dependent lexer,
+tree, lowering, formatter, diagnostic, incremental, budget, test, documentation, and template
+surfaces. Do not fix a parser bug only in a downstream consumer that leaves other callers exposed.
+
+### 15. Verify each claim
+
+Use the narrowest configured intents that cover the changed language, generated parser, tests,
+documentation, and release surface. Distinguish directly verified behavior, code-supported
+inference, and remaining unknowns. A passing valid corpus does not prove recovery, incrementality,
+Unicode correctness, or hostile-input safety.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Input is consumed fully or rejected explicitly, and every preserved source unit has an accountable
+  raw span.
+- Lexer, speculation, recovery, and incremental reparsing have observable progress or budget exits.
+- Position units and conversions are explicit at every external boundary.
+- Operator grouping is defined by executable data and proven by AST-shape tests.
+- Incremental results are compared against full parses across state-changing edits.
+- Malformed, wide, deep, expanding, and chunked inputs have bounded fixtures and budget behavior.
+- Verification records separate results, supported inferences, skipped checks, and remaining risk.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+- Inspect the change with `changes_status` and `changes_diff_summary` when configured.
+- Use `lint` and `build` when parser source, generated grammar, or type contracts change.
+- Prefer `test_related`; use `test` when shared parser behavior or broad fixtures change, and
+  `test_audit` when test-selection or coverage claims need evidence.
+- Use `docs_validate_fast` for changed documentation, `test_release` for packaged grammar, template,
+  or public parser surfaces, and `mustflow_check` for Mustflow document or contract changes.
+- Record unconfigured, blocked, timed-out, or environment-dependent checks instead of replacing them
+  with raw commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the accepted language or compatibility contract is unclear, stop semantic edits and report the
+  smallest disputed examples with their current trees and diagnostics.
+- If the parser can fail to advance, exhaust a budget, overflow recursion, or retain unbounded input,
+  treat it as a correctness or availability defect before tuning messages or throughput.
+- If incremental and full parses disagree, disable or narrow reuse at the smallest unsafe boundary;
+  do not bless the incremental tree from visual similarity.
+- If position units cannot be mapped exactly, preserve raw spans and mark derived positions unknown
+  rather than guessing a column.
+- If a configured verification fails, preserve the failure output, activate the applicable failure
+  triage procedure, and do not broaden the change until the failure is classified.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+Report:
+
+- Parser role and contract boundary.
+- Source, token, tree, operator, recovery, incremental, Unicode, storage, and budget decisions that
+  were applicable.
+- Files changed and compatibility behavior preserved or intentionally changed.
+- Positive, boundary, counterexample, chunking, differential, and resource-limit evidence.
+- Configured verification intents and results.
+- Remaining ambiguity, unverified scale, environment limits, and residual parser risk.
+- For review-only work, report files changed and verification intents as none or not run, rather
+  than implying that an implementation or runtime check occurred.

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

@@ -0,0 +1,170 @@
+---
+mustflow_doc: skill.policy-decision-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: policy-decision-integrity-review
+description: Apply this skill when a policy object, specification, decision table, rule engine, capability policy, approval rule, limit, masking rule, or default-deny path returns allow, deny, require-approval, downgrade, or obligations from versioned actor, resource, action, context, and budget facts.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.policy-decision-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Policy Decision Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Make allow, deny, approval, downgrade, masking, limit, and obligation decisions deterministic,
+versioned, explainable, conflict-safe, and bound to enforcement. Separate whether an action is
+permitted from how an already permitted action is implemented.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code creates or changes a policy object, specification, decision table, rule engine, approval
+  rule, default-deny rule, capability scope, limit, masking obligation, or policy version.
+- A boolean cannot represent required outcomes such as allow, deny, require approval, downgrade,
+  redact, rate-limit, or continue with obligations.
+- Policy facts, configuration timing, rule precedence, approval delay, or version drift can change
+  the decision between evaluation and effect.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Authentication, session establishment, actor-resource ownership, or permission enforcement is the
+  whole task; use the applicable auth or access-control skill.
+- Code selects an interchangeable implementation such as Stripe versus Adyen; use
+  `strategy-pattern`. Deciding whether an actor may refund under policy version 7 belongs here.
+- A Mustflow command intent grants agent execution authority; use `command-contract-authoring`.
+- One entity transition guard is the whole rule; use `state-machine-pattern`.
+- The task only models invalid domain states or ledger-backed balances; use
+  `type-state-modeling-review` or `credit-ledger-integrity-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Policy-input ledger: actor, resource, action, context, normalized facts, provenance, freshness, and
+  trusted owner.
+- Rule ledger: stable ID, version, predicate, scope, priority, effective window, and obligations.
+- Decision ledger: outcome, reason code, matched rules, obligations, decision ID, and policy version.
+- Conflict and default ledger: precedence, no-match behavior, missing-fact behavior, and fail-open or
+  fail-closed choice.
+- Snapshot and enforcement ledger: pinned version, approval binding, expiry, recheck rule, and exact
+  effect gate.
+- Decision-table, boundary, conflict, stale-fact, and version-change tests.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the nearest instructions, command contract, policy source of truth, fact loaders, enforcement
+  path, approval persistence, configuration or rollout path, and current tests.
+- State the policy question in actor-resource-action terms or another equally bounded decision.
+- Treat raw requests, model output, provider claims, cache entries, and stale summaries as untrusted
+  until normalized by their owning boundary.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten normalized fact types, policy rules, decision tables, structured outcomes, reason
+  codes, obligations, version snapshots, conflict resolution, approval binding, enforcement rechecks,
+  focused tests, docs, and directly synchronized templates.
+- Keep identity proof, external claim translation, command mechanics, state transitions, and balance
+  invariants in their owning procedures.
+- Do not hide rule conflicts behind array order, broad boolean defaults, current-time globals,
+  mutable configuration reads mid-run, or UI-only enforcement.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Write the decision question and enumerate actor, resource, action, context, and requested effect.
+2. Normalize trusted facts before policy evaluation. Record provenance and freshness for tenant,
+   ownership, membership, risk, budget, time, environment, and approval facts.
+3. Return a structured decision containing outcome, reason code, obligations, policy version,
+   decision ID, matched rules, and safe evidence pointers. Do not return only `true` or `false` when
+   callers must approve, mask, downgrade, limit, or explain.
+4. Give every rule a stable ID, version, scope, priority, effective window, and owner. Keep policy
+   meaning out of handler order and provider configuration where possible.
+5. Define conflict precedence for allow, deny, approval, and obligations. State whether deny wins,
+   obligations merge, approval can override, or one scoped rule supersedes another.
+   Human approval must not silently override a deny; require an explicit versioned rule bound to the
+   exact action whenever approval is allowed to supersede another decision.
+6. Define deterministic no-match, missing, stale, and unknown-fact behavior. Security- or
+   money-relevant uncertainty must not become accidental allow.
+7. Pin one policy snapshot for a command or run. Do not read mutable rules repeatedly and combine
+   decisions from different versions without an explicit migration rule.
+8. Bind the decision to the exact actor, resource, action, normalized parameters or digest, policy
+   version, obligations, expiry, and effect it gates.
+   Delegated capabilities must use attenuation only: a child capability may narrow actor or subject,
+   tenant, resource, actions, effects, expiry, call count, or cost, but must never widen its parent
+   grant. Bind the chain to parent capability ID, issuer, policy version, and revocation state, and
+   consume call and cost limits atomically at the trusted effect boundary.
+   Canonicalize normalized parameters before binding or hashing them; define how omitted and default
+   arguments compare so equivalent calls do not produce ambiguous decision identities.
+9. After a long approval wait or material fact change, revalidate the binding or recompute under a
+   declared version rule before executing. Record why an old approval remains valid or expires.
+10. Enforce obligations such as masking, maximum amount, read-only mode, selected region, extra
+    audit, or rate limit at the trusted effect boundary, not only in UI or planning code.
+11. Test the full decision table where bounded, plus boundary values, pairwise rule conflicts,
+    no-match, default deny, missing and stale facts, changed-after-approval, version migration, and
+    decision-to-effect mismatch.
+12. Persist safe decision metadata and reason codes when audit or replay needs them. Avoid raw PII,
+    secrets, model reasoning, or broad request bodies.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every material decision exposes outcome, reason, obligations, version, and binding evidence.
+- No-match, conflict, stale fact, policy drift, and changed-after-approval paths are deterministic.
+- Evaluation and enforcement use the same actor, resource, action, parameters, policy version, and
+  obligations or perform an explicit recheck.
+- Strategy selection, authentication, command authority, lifecycle, and ledger invariants remain in
+  their owning procedures.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+- Use configured `changes_status` and `changes_diff_summary` for scope evidence.
+- Use `lint`, `build`, and `test_related` for policy implementation and decision matrices; use `test`
+  or `test_audit` for shared rule engines or coverage claims.
+- Use `docs_validate_fast`, `test_release`, and `mustflow_check` for public rules, package, template,
+  or Mustflow changes.
+- Report unavailable production-policy, rollout, approval-delay, or authorization evidence instead
+  of inventing commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the policy question, trusted facts, or conflict precedence cannot be named, stop policy edits
+  and report the ambiguous decision.
+- If enforcement cannot bind to the evaluated actor, resource, action, and version, report a TOCTOU
+  gap and do not approve the path from evaluation tests alone.
+- If uncertainty currently allows a sensitive effect, fail closed or require approval according to
+  the declared product rule; do not invent a universal deny when availability policy differs.
+- If verification fails, preserve the decision row and expected obligation, then use
+  `failure-triage` before broadening the change.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Policy question, trusted inputs, source of truth, and snapshot version
+- Rule IDs, precedence, defaults, outcomes, reason codes, and obligations
+- Approval binding, enforcement, expiry, and recheck decisions
+- Decision-table, conflict, stale-fact, drift, and TOCTOU evidence
+- Files changed and compatibility impact
+- Command intents run, skipped checks, and remaining policy-decision risk

package/templates/default/locales/en/.mustflow/skills/public-json-contract-change/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.public-json-contract-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: public-json-contract-change
@@ -43,6 +43,7 @@ Protect automation consumers from silent JSON, JSONL, stream, schema, fixture, a
 - The task changes only human-readable CLI text, color, help wording, warnings, or deprecations; use `cli-output-contract-review`.
 - The JSON is an HTTP, OpenAPI, GraphQL, RPC, or SDK request/response contract; use `api-contract-change`.
 - The task is only a broad template or docs alignment check with no JSON contract; use `contract-sync-check` or a narrower template skill.
+- The JSON is a private persisted workflow/checkpoint or execution-ledger representation; use the owning `durable-workflow-orchestration` or `execution-ledger-integrity-review` skill for meaning, plus `migration-safety-check` for old-to-new schema transformation.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.queue-processing-integrity-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: queue-processing-integrity-review
@@ -49,6 +49,9 @@ The core question is not "is the worker running?" It is "when does this code dec
 - The task is primarily transaction isolation, rollback, outbox, after-commit, or read-decision-write atomicity; use `transaction-boundary-integrity-review` first and this skill for broker settlement.
 - The task is primarily database query speed, cache correctness, API latency, or generic hot-path performance with no broker, worker, or redelivery surface.
 - The queue path is read-only telemetry where dropped or duplicate messages are explicitly acceptable and no state, audit, billing, permission, notification, or external side effect depends on it.
+- The main problem is producer database commit versus broker publish convergence; use `dual-write-consistency` and keep this skill for producer confirmation and consumer settlement evidence.
+- The queued work is a resumable multi-step business workflow with checkpoints, callbacks, or compensation; use `durable-workflow-orchestration`.
+- The main problem is unjoined child tasks, cancellation propagation, deadlines, or orphan work after a handler returns; use `structured-concurrency-supervision-review`.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
@@ -99,10 +102,11 @@ The core question is not "is the worker running?" It is "when does this code dec
    - Require permanent-failure classification, retry count, backoff, jitter, DLQ threshold, and a reason that helps replay or discard safely.
 5. Check producer confirmation.
    - A producer that only calls `send` or `publish` may not know the broker durably accepted the message.
-   - If local DB commit and queue publish are separate, require outbox, transactional publish support, reconciliation, or a reported split-brain risk.
+   - If local DB commit and queue publish are separate, route the convergence protocol to `dual-write-consistency`; do not redefine it as queue settlement.
 6. Review async handler ownership.
    - If processing returns a promise, future, coroutine, goroutine, thread, or background task, settlement must wait for the actual work or explicitly record durable handoff.
    - Fire-and-forget work after ack is message loss unless the handoff itself is durable and observable.
+   - Route parent-child join, cancellation, deadline, and orphan prevention to `structured-concurrency-supervision-review` when the handler spawns child tasks.
 7. Review batch settlement.
    - Batch commit after mixed success can skip failed items.
    - Per-item failure handling, partial commit boundaries, ordered stop-on-failure behavior, or replay-safe idempotency should be explicit.