mustflow 2.38.0 → 2.58.0

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

@@ -0,0 +1,283 @@
+---
+mustflow_doc: skill.error-message-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: error-message-integrity-review
+description: Apply this skill when code is created, changed, reviewed, or reported and error messages, error codes, validation errors, parse errors, API or CLI error envelopes, public user-facing errors, logs, structured diagnostics, exception wrapping, provider errors, retryability, idempotency errors, queue or batch failures, partial failures, permission errors, conflict errors, impossible-state errors, security redaction, support-facing IDs, monitoring fields, or troubleshooting text need review for actionability, recoverability, observability, stable contracts, and safe disclosure.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.error-message-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Error Message Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review error messages as recovery and evidence contracts, not as friendly prose.
+
+The review question is not "does this sound nice?" It is "when this fails, can the user, caller,
+operator, support person, monitoring rule, or future developer know what action failed, why it was
+rejected, what was expected, what actually happened, whether retry is safe, where to look, and what
+must not be leaked?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code review, implementation, or refactor work touches error text, error codes, exception classes,
+  validation messages, parse errors, API error envelopes, CLI errors, queue or batch job errors,
+  webhook failures, provider errors, retry behavior, idempotency errors, conflict errors, logs,
+  structured diagnostics, support codes, user-facing messages, docs examples, or tests that assert
+  failure output.
+- A change adds or modifies `throw`, `catch`, error wrapping, logging, redaction, public error
+  mapping, provider response mapping, status codes, retry flags, error-code enums, validation
+  aggregation, or troubleshooting guidance.
+- A review needs to decide whether to use `failure-integrity-review`, `security-privacy-review`,
+  `api-contract-change`, `cli-output-contract-review`, `result-option`, `test-design-guard`,
+  `business-rule-leakage-review`, or `backend-reliability-change`.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main issue is whether failure leaves false success or partial state; use
+  `failure-integrity-review` first.
+- The main issue is API schema, status, or response compatibility; use `api-contract-change` first
+  and this skill for the error content contract.
+- The main issue is CLI stdout/stderr, exit code, JSON, JSONL, help text, or automation output; use
+  `cli-output-contract-review` first and this skill for error content quality.
+- The main issue is secret, personal data, or disclosure risk with no changed error surface; use
+  `security-privacy-review`.
+- The change only adjusts private debug wording that is not emitted, logged, tested, documented, or
+  consumed by humans or automation.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User goal, current diff or target files, and every changed error surface.
+- Error audience ledger: end user, API caller, CLI user, support agent, operator, queue worker,
+  dashboard, monitoring rule, developer log, provider dashboard, or test fixture.
+- Error contract ledger: stable code, message, HTTP status or exit code, machine fields, retryable
+  flag, cause, support ID, request ID, correlation ID, provider code, and documentation link.
+- Disclosure ledger: public versus internal message, safe identifiers, sensitive values, masking,
+  raw provider payloads, stack traces, SQL, environment values, tokens, personal data, and secrets.
+- Recovery ledger: expected value, actual value, failed operation, reason, next action, retry policy,
+  idempotency state, partial failure state, and escalation path.
+- Relevant command-intent contract entries for tests, lint, build, docs, release, and mustflow checks.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the
+  current scope.
+- Required inputs are available, or missing audience, contract, disclosure, or recovery evidence can
+  be reported without guessing.
+- If the review finds concrete false-success, security, API, CLI, result-type, backend reliability,
+  or business-rule risk, use the narrower skill before editing that part.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten stable error codes, expected and actual fields, failed-operation context, reason,
+  safe identifiers, retryability, idempotency metadata, provider metadata, parse position, range
+  details, conflict details, partial-failure summaries, structured log fields, public/internal error
+  mapping, and focused tests.
+- Preserve causes while redacting public responses and unsafe logs.
+- Split public user messages from internal diagnostic messages when one string cannot safely serve
+  both audiences.
+- Update docs, fixtures, API examples, CLI tests, support text, or dashboards that depend on the
+  same error contract.
+- Do not add raw secrets, personal data, full provider payloads, stack traces, SQL, environment
+  values, internal hostnames, hidden reasoning, or exploit hints to public or broadly retained
+  messages.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Reject empty failure labels.
+   - Messages like `"failed"`, `"invalid value"`, `"bad request"`, `"upload failed"`, and
+     `"something went wrong"` are usually evidence-free.
+   - Name the failed operation, the reason, and the condition that would have succeeded.
+2. Require `expected` and `actual` when a value is rejected.
+   - Prefer "expected status to be one of [draft, published], got archived" over "invalid status".
+   - Use machine fields as well as readable text when the output has structured form.
+3. Put the failed action in the message.
+   - "user not found" is weaker than "cannot create invoice because user 123 was not found".
+   - Include operation context such as invoice creation, webhook parsing, migration application, or
+     provider synchronization.
+4. Explain cause, not only result.
+   - "upload rejected because file size 28MB exceeds limit 20MB" is actionable.
+   - "upload failed" repeats what the caller already knows.
+5. Add human-readable work context.
+   - Prefer context such as "while syncing Stripe customer", "while parsing webhook payload", or
+     "while applying migration 202406_add_plan_id".
+   - Function names alone rarely explain the failed business or operational action.
+6. Split public and internal messages.
+   - Public messages should be safe and user-actionable.
+   - Internal logs should keep diagnostic fields such as provider, providerCode, status, requestId,
+     operation, attempt, duration, and cause.
+7. Redact sensitive values.
+   - Treat email, phone, token, session, card, address, personal identifiers, request bodies, SQL,
+     secrets, and credentials as unsafe unless a narrow redaction policy says otherwise.
+   - Mask, hash, truncate, or omit values according to the local privacy rule.
+8. Keep safe identifiers.
+   - Removing sensitive data does not mean removing all evidence.
+   - Preserve safe identifiers such as userId, orderId, requestId, jobId, tenantId, provider,
+     providerRequestId, fileId, and operation name when useful.
+9. Expose retryability deliberately.
+   - A timeout can be retryable; validation failure usually is not.
+   - Queue, batch, webhook, payment, provider, and external API errors should expose retryable,
+     attempt, maxAttempts, nextRunAt, or deadLetter state when relevant.
+10. Stop abusing "try again later".
+    - If the user can fix input, say what to fix.
+    - If the user cannot fix it, provide a safe request or support ID and make sure internal logs can
+      find the failure.
+11. Separate stable error codes from messages.
+    - Messages may change; codes should remain stable for search, docs, support macros, monitoring,
+      API clients, dashboards, and tests.
+    - Prefer domain codes such as `PAYMENT_CARD_DECLINED`, `USER_EMAIL_ALREADY_EXISTS`, and
+      `WEBHOOK_SIGNATURE_INVALID` over only `BAD_REQUEST` or `INTERNAL_ERROR`.
+12. Avoid overbroad error code buckets.
+    - HTTP status and CLI exit code categories are not enough.
+    - A domain error code should name the actual failure class.
+13. Choose validation aggregation intentionally.
+    - Form validation can report multiple field errors at once.
+    - Authentication, authorization, account discovery, and security-sensitive validation may need
+      intentionally vague or single-error output to avoid giving attackers hints.
+14. Put location in parse errors.
+    - JSON, CSV, SQL, regex, config, markdown, and template parse errors should include line,
+      column, byte offset, field path, or nearby token when safe.
+    - "parse failed" is not enough for recovery.
+15. Put bounds in range errors.
+    - Include current value and allowed range: "max 100 items allowed, got 143".
+    - For durations, sizes, counts, quotas, price limits, and attempts, include units.
+16. Include time basis in time errors.
+    - "expired" is too thin.
+    - Include relevant timestamps, timezone or UTC basis, server time, and clock-skew context when
+      safe and useful.
+17. Preserve provider diagnostics in structured form.
+    - Wrap external errors into local domain errors without losing provider, providerCode, status,
+      requestId, retryability, and sanitized response category.
+    - Do not dump raw provider payloads into public responses or broad logs.
+18. Preserve original causes.
+    - `catch (e) { throw new Error("failed") }` destroys evidence.
+    - Link causes, suppressed errors, or structured cause fields so stack, category, and provider
+      context survive safely.
+19. Control template string composition.
+    - Ad hoc `"Invalid " + field + " for " + thing` messages often become unsearchable, broken, or
+      inconsistent.
+    - Prefer named error constructors, controlled templates, and structured fields.
+20. Structure logs for machines.
+    - Keep human text, but put `error_code`, `user_id`, `order_id`, `tenant_id`, `provider`,
+      `retryable`, `attempt`, `duration_ms`, and `request_id` in fields.
+    - Do not make operations parse prose with regular expressions.
+21. Keep user messages free of internal jargon.
+    - Users usually do not need to see internal system names, buckets, regions, class names, or
+      provider implementation details.
+    - Internal logs may need those details after redaction.
+22. Make permission errors intentionally safe.
+    - Sometimes "not found" is safer than "forbidden" because it avoids confirming resource
+      existence.
+    - Decide disclosure policy for authentication, authorization, ownership, tenant, and account
+      discovery errors.
+23. Ban vague impossible-state text.
+    - "this should never happen" does not help.
+    - Name the broken invariant: "expected exactly one active subscription for user 123, found 2".
+24. Name concurrency conflict facts.
+    - "conflict" is weak.
+    - Include version, idempotency key, lock owner, reservation id, stock unit, or expected/current
+      state when safe: "version conflict: expected document version 17, got 19".
+25. Include idempotency history.
+    - "duplicate request" is not enough in payment and order flows.
+    - Include key, prior operation, prior resource, and prior status when safe.
+26. Put attempts in job and queue errors.
+    - "job failed on attempt 3 of 5; next retry at ..." tells operators whether to wait or act.
+    - Include dead-letter state when the job will not retry.
+27. Represent partial failure honestly.
+    - For bulk work, say how many succeeded and failed.
+    - Include failed item identifiers when safe, or a retrievable failure report id.
+28. Test error contracts.
+    - Avoid over-snapshotting prose, but test stable error codes, expected and actual fields,
+      retryable, redaction, parse location, provider metadata, and support IDs where consumers rely
+      on them.
+29. Ask the 30-second action question.
+    - What can the receiver do in the next 30 seconds?
+    - Fix input, request permission, retry, wait, inspect request ID, search provider dashboard,
+      send support code, or stop and escalate should be clear.
+30. Check architecture ownership.
+    - Error quality depends on error type, code taxonomy, public/internal mapping, logging fields,
+      redaction, retry policy, docs, monitoring, and tests.
+    - If every call site invents messages, add or recommend a shared error boundary instead of
+      polishing one string.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The failed operation, reason, expected value, actual value, and next safe action are explicit when
+  they can be safely disclosed.
+- Public and internal error surfaces are separated where disclosure or debugging needs differ.
+- Stable error codes and machine fields exist for consumers that need search, monitoring, support,
+  API handling, CLI automation, dashboards, or documentation.
+- Sensitive values are redacted while safe identifiers and correlation fields remain available.
+- Causes, retryability, idempotency, provider details, parse location, range bounds, time basis,
+  conflict facts, attempts, and partial failure state are preserved where relevant.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `test_audit`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer tests that assert stable codes, structured fields, redaction, retryability, cause preservation,
+and contract shape instead of full prose snapshots unless the repository already treats prose as a
+public contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the audience, disclosure policy, retry policy, or code taxonomy is unknown, report the missing
+  contract rather than inventing one silently.
+- If improving the message would expose sensitive data, choose safe identifiers and internal
+  diagnostics instead.
+- If a command fails, use `failure-triage` before further edits.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Error message integrity reviewed
+- Error surfaces and audiences
+- Error code and message contract
+- Expected, actual, operation, cause, retryability, idempotency, provider, parse, range, time,
+  conflict, attempt, or partial-failure findings
+- Public/internal split and redaction notes
+- Fixes made or recommendation
+- Tests or behavior evidence
+- Command intents run
+- Skipped checks and reasons
+- Remaining error-message integrity risk

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

@@ -0,0 +1,193 @@
+---
+mustflow_doc: skill.failure-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: failure-integrity-review
+description: Apply this skill when code is created, changed, reviewed, or reported and exception or failure handling can make the system lie about success, state, data, money, permissions, locks, queues, logs, metrics, or user-visible results, including broad catch blocks, swallowed exceptions, log-and-continue paths, return null/false/empty defaults, finally masking, unsafe retry, missing timeout, cancellation swallowing, async task failures, queue ack/nack, lost causes, raw internal errors, partial state changes, transaction rollback, lock/resource cleanup, parsing defaults, fail-open authorization, unsafe cache fallback, fallback defaults, stable error codes, and missing failure-path observability.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.failure-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Failure Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review failure handling by asking what lie the system tells after something fails.
+
+The question is not whether a `try`/`catch` exists. The stronger question is whether a failed step can leave data, state, money, permissions, locks, queues, logs, metrics, or user-visible responses pretending the operation succeeded. Good failure handling makes failure honest, bounded, observable, and recoverable.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code creates, changes, reviews, or reports exception handling, `catch`, `finally`, `retry`, `timeout`, `fallback`, `rollback`, `ack`, `nack`, `close`, `cancel`, `ignore`, `default`, `return null`, `return false`, empty collections, or `log.error` paths.
+- A workflow has multiple steps where one step can fail after another step changed internal state, external state, a transaction, a queue, a cache, a lock, a file, a payment, an entitlement, or a user-visible result.
+- Code handles external APIs, databases, files, streams, locks, queues, async tasks, cancellation, parsing, validation, authentication, authorization, cache fallback, payment, inventory, email, notification, or admin operations.
+- Public API, CLI, UI, queue, or webhook boundaries expose error codes, messages, statuses, responses, acknowledgements, logs, metrics, trace ids, request ids, or incident evidence.
+- A review or final report claims a path is safe, handled, resilient, graceful, retried, rolled back, logged, observable, idempotent, or successful despite possible failures.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only models expected failures, meaningful absence, `null`, `undefined`, boolean flags, or public error envelopes as typed values; use `result-option` first and this skill only for swallowed failures, partial state, or operational honesty.
+- The task only changes backend retries, idempotency, queues, caches, health checks, provider calls, or outbox/inbox behavior; use `backend-reliability-change` first and this skill as an adjunct for failure truthfulness.
+- The task only changes object lifetime or resource cleanup; use `memory-lifetime-review` first and this skill only when cleanup failure can hide the original failure or leave false success.
+- The task only changes authorization, personal data, secret logging, or fail-closed policy; use `security-privacy-review` first and this skill only for error-path integrity around that boundary.
+- The task is a pure calculation with no fallible dependency, side effect, status, observable response, or failure branch.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Failure surface: exception type, error value, rejected promise, timeout, cancellation, parse failure, validation failure, provider response, queue delivery failure, transaction failure, lock failure, cleanup failure, or fallback trigger.
+- Truth surface: what the caller, user, operator, queue, database, cache, ledger, metric, audit log, or downstream service will believe after the failure.
+- State-change ledger: every mutation, external call, enqueue, publish, ack, lock acquire, file write, cache write, status change, response send, and metric/log emission before and after each fallible step.
+- Error classification: expected rejection, validation error, permission denial, transient dependency failure, permanent dependency failure, unknown outcome, programmer bug, corrupted data, or cancellation.
+- Boundary rules: transaction rollback, compensation, idempotency, retry budget, timeout, fallback safety, fail-open or fail-closed behavior, public error code, safe message, cause preservation, redaction, and observability.
+- Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- Required inputs are available, or missing failure, state, rollback, idempotency, timeout, fallback, redaction, or observability facts can be reported without guessing.
+- Existing local patterns for typed errors, result values, transaction wrappers, idempotency, retries, queue consumers, cancellation, cleanup, logging, metrics, and public error envelopes have been searched before adding new shapes.
+- If the failure path crosses money, entitlement, authorization, personal data, external providers, or durable events, also apply the relevant backend, security, database, API, state-machine, or result skill.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Replace swallowed exceptions, log-and-continue paths, and fake success returns with explicit failure propagation, typed error values, rollback, compensation, fail-closed behavior, or honest degraded responses.
+- Split error categories and public error mapping when different failures need different caller behavior, retry behavior, monitoring, or user-visible status.
+- Preserve original causes while keeping raw stack traces, SQL, provider payloads, secrets, tokens, request bodies, and personal data out of public responses and unsafe logs.
+- Add or tighten timeout, retry budget, backoff, jitter, idempotency, cancellation propagation, queue ack/nack, dead-letter, lock release, resource cleanup, and failure-path observability tied to the changed surface.
+- Add focused tests for representative failure branches, partial-step failures, retry exhaustion, timeout, cancellation, rollback, cleanup, fallback, stable error codes, and false-success prevention.
+- Do not fix failure handling with arbitrary sleeps, broad catch-all branches, default values, comments that say "should not happen", or logs that cannot drive operator action.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Ask the lie question first. If this step fails, what will the user, caller, database, cache, queue, ledger, metric, log, or operator believe happened?
+2. Classify every caught failure.
+   - Avoid one broad `catch (Exception)`, `catch (error)`, or equivalent path that erases file-not-found, permission denied, timeout, validation, corrupted data, dependency failure, and programmer bugs into the same behavior.
+   - Separate expected rejection, transient dependency failure, permanent dependency failure, unknown outcome, cancellation, and bug because each needs different propagation, retry, and monitoring.
+3. Reject log-and-continue fake success.
+   - A caught error followed by `return success`, `return null`, `return false`, `return []`, or continuing to the next side effect usually turns failure into a false fact.
+   - Distinguish "no data" from "failed to load data", "not sent" from "sent", and "not applied" from "applied".
+4. Review `finally` and cleanup masking.
+   - Cleanup must run, but cleanup failure should not hide the original failure without preserving it as primary cause or suppressed context.
+   - Check file close, stream close, transaction end, lock release, temp-file cleanup, and connection release paths.
+5. Preserve diagnostic identity without leaking secrets.
+   - Logs should include safe identifiers such as request id, order id, file id, provider name, retry count, state, operation name, and result class when useful.
+   - Do not log passwords, tokens, session cookies, payment details, full request bodies, raw provider payloads, personal data, or full exception graphs unless a narrow redacted retention rule exists.
+6. Check transaction honesty.
+   - Catching inside a transaction and returning normally can commit partial failure.
+   - Fail by throwing or returning an error that forces rollback, or explicitly roll back before converting the error.
+   - If only part of the workflow can be atomic, name the compensation, reconciliation, or manual recovery path.
+7. Check external side-effect ordering.
+   - If internal state says "paid", "sent", "saved", "processed", "approved", or "complete", verify the corresponding external or durable side effect is actually known to have happened.
+   - Unknown provider outcomes need reconciliation before repeating money, entitlement, inventory, or privacy-impacting actions.
+8. Review retry and timeout behavior.
+   - A network timeout often means "unknown outcome", not "safe failure".
+   - Retry only when the operation is idempotent or guarded by durable idempotency. Add bounded attempts, timeout, backoff, jitter, and stop conditions.
+   - Missing timeout means failure may never become an exception; check thread, connection, worker, and pool exhaustion risk.
+9. Preserve cancellation semantics.
+   - `InterruptedException`, `CancellationException`, `AbortError`, cancelled promises, context cancellation, and stop signals are control flow from above, not ordinary failures.
+   - Restore interrupt status, rethrow, return a cancellation result, or propagate the cancellation according to local style.
+10. Check async failure ownership.
+    - For `Promise`, `Future`, `Task`, coroutine, goroutine, thread, event handler, and background job paths, ask who observes the failure.
+    - Avoid fire-and-forget work unless failure is deliberately logged, counted, bounded, and safe to lose.
+11. Review queue and event acknowledgement.
+    - Ack after failure drops work. Blind nack on every failure can poison the queue.
+    - Define retry count, visibility timeout, dead-letter behavior, idempotent consumer state, duplicate handling, and safe operator evidence.
+12. Preserve causes when converting errors.
+    - Wrapping an error should retain the cause or equivalent diagnostic context.
+    - Public errors should expose stable safe codes and messages, while internal logs or traces retain the raw cause under privacy rules.
+13. Separate public and internal error shapes.
+    - Do not leak `NullPointerException`, SQL syntax, S3 access errors, stack traces, filesystem paths, storage keys, or provider payloads through public APIs.
+    - Do not make clients branch on free-form text. Public failure contracts need stable machine-readable codes.
+14. Separate business rejections from system failures.
+    - Insufficient balance, invalid input, duplicate request, and permission denial are not the same as Redis down, DB unavailable, provider timeout, corrupted data, or programmer bugs.
+    - Map input validation to client-correctable errors and system failure to server/dependency errors.
+15. Trace partial state after every fallible line.
+    - After setting `PROCESSING`, writing a DB row, reserving inventory, acquiring a lock, opening a file, sending a response, or publishing an event, ask where state lands if the next line fails.
+    - Close states explicitly as failed, rolled back, pending reconciliation, or unknown instead of leaving them stuck in-progress.
+16. Check locks and resources from the acquisition line.
+    - The release guarantee should start immediately after `lock()`, semaphore acquire, distributed lock acquire, file lock, advisory lock, connection checkout, file open, stream open, temp file create, or cursor open.
+    - Normal-only `close()` paths are failure bugs. Use the local equivalent of scoped resource management.
+17. Review parsing and default values.
+    - A dangerous default value is usually worse than a loud failure for money, quantity, date, role, permission, or policy inputs.
+    - Missing JSON fields, malformed dates, unknown time zones, missing prices, missing quantities, and invalid permissions should not silently become `0`, current time, free, public, allowed, or empty.
+    - Defaults are safe only when the wrong value has bounded harmless impact.
+18. Check fail-open paths.
+    - Authentication, authorization, payment, entitlement, rate limit, destructive admin, and privacy decisions should normally fail closed.
+    - Recommendation, analytics, email, and non-critical display features may degrade only when the fallback cannot change protected state or mislead the user.
+19. Review cache and fallback truth.
+    - Cache failure is a performance problem only when cache data is disposable. If cache stores sessions, permissions, rate limits, inventory, idempotency, or deduplication, failure is a correctness boundary.
+    - Fallback must be a safe degraded value, not a convenient default that can sell for zero, grant access, hide missing data, or mark work complete.
+20. Require failure-path evidence.
+    - Tests should cover DB save failure, external timeout, second-step failure, retry exhaustion, cancellation, malformed input, queue consumer failure, rollback, cleanup, and stable public error code where relevant.
+    - Metrics should expose retry exhaustion, fallback activation, dead-letter insert, compensation failure, unknown provider outcome, and data inconsistency when those states matter.
+21. Report missing evidence honestly. If the repository lacks configured integration, provider, queue, database, chaos, or load checks, complete available verification and name the remaining manual evidence gap.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Failure paths no longer produce false success, false completion, false empty data, false authorization, false delivery, or false durable state.
+- Expected rejection, transient failure, permanent failure, unknown outcome, cancellation, bug, and corrupted data are separated where they affect behavior.
+- Transactions, external side effects, retries, timeouts, queues, locks, resources, parsing defaults, fallbacks, and public error shapes are checked where relevant.
+- Logs, metrics, traces, and audit records provide safe incident evidence without leaking sensitive data.
+- Focused tests or configured verification cover the highest-risk failure branch when feasible.
+
+<!-- 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`
+- `mustflow_check`
+
+Prefer the narrowest configured test, build, docs, release, or mustflow intent that proves false-success prevention and changed failure contracts. Do not infer raw provider, database, queue, load, chaos, server, watcher, or manual incident commands outside the command contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a configured command fails, preserve the failing intent, failing assertion or output tail, and the failure contract it exercised before editing again.
+- If the failure outcome cannot be classified, report the missing domain or operational decision instead of hiding it behind a catch-all branch.
+- If fixing failure integrity requires a transaction boundary, idempotency store, outbox, dead-letter queue, reconciliation job, stable error catalog, or monitoring pipeline outside the current scope, report the missing durable boundary.
+- If deterministic failure proof is not configured, report the missing manual evidence and complete the configured checks that are available.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Failure surface and lie checked
+- Error categories and boundaries reviewed
+- False success, swallowed exception, null/false/empty default, finally masking, transaction, side-effect ordering, retry/timeout, cancellation, async ownership, queue ack/nack, cause preservation, public/internal error shape, partial state, lock/resource cleanup, parsing default, fail-open, cache/fallback, and observability checks where relevant
+- Failure-integrity fixes made or recommended
+- Tests or verification evidence
+- Command intents run
+- Skipped failure diagnostics and reasons
+- Remaining failure-integrity risk