mustflow 2.39.1 → 2.58.0

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

@@ -0,0 +1,291 @@
+---
+mustflow_doc: skill.cache-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: cache-integrity-review
+description: Apply this skill when code is created, changed, reviewed, or reported and cache behavior can spread stale, wrong, private, overbroad, tenant-crossing, permission-wrong, version-incompatible, or source-overloading values through cache keys, query normalization, key versions, TTL and jitter, soft and hard TTL, stale-while-revalidate, stampede protection, request coalescing, negative caching, invalidation order, list or page caches, tag invalidation, L1/L2 cache layers, Redis fallback, hit/miss observability, value size, eviction policy, TTL-less keys, KEYS/SCAN use, hot keys, Redis Cluster hash tags, HTTP Vary/no-cache/no-store semantics, permission caches, cache warming, or failure-path cache tests.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.cache-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Cache Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review cache changes as truth and failure-boundary changes, not only as speed changes.
+
+A cache is a second truth store. The review question is not only "did the second request get faster?"
+It is "which value can be wrong, who can see it, how long can it survive, how quietly can it spread,
+and what happens to the source system when the cache misses or fails?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code creates, changes, reviews, or reports cache keys, cache reads, cache writes, cache invalidation,
+  cache TTLs, Redis or Memcached use, local in-memory caches, CDN or HTTP cache headers, cache tags,
+  cache warming, cache fallback, negative caching, stale-while-revalidate, request coalescing, or
+  cache observability.
+- A route, worker, query, permission check, feature flag, entitlement, inventory value, search result,
+  listing, feed, recommendation, API response, rendered page, generated artifact, or provider response
+  is cached.
+- Cache behavior can vary by tenant, actor, login state, membership tier, country, language, locale,
+  A/B test, feature flag, adult verification, inventory policy, authorization, subscription, or
+  request headers.
+- A review or final report claims that caching is safe, fast, resilient, correct, isolated, warmed,
+  invalidated, observable, or harmless under deploy, rollback, source failure, Redis failure, or
+  concurrent updates.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The only concern is ordinary repeated work with no stale data, authority, invalidation, permission,
+  tenant, source-protection, or cache-failure risk; use `hot-path-performance-review`.
+- The only concern is object lifetime, cache size, eviction cleanup, or retained memory without data
+  correctness or source-protection risk; use `memory-lifetime-review`.
+- The only concern is HTTP streaming, compression, proxy buffering, or delivery transport behavior;
+  use `http-delivery-streaming` first and this skill only for cache reuse correctness.
+- The task is a broad performance budget, profiling, benchmark, or load-test design; use
+  `performance-budget-check` first and this skill for cache integrity boundaries.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Cache surface: local memory, process L1, external L2, Redis, Memcached, CDN, browser cache, HTTP
+  cache, ORM query cache, generated state, read model, or framework cache.
+- Source of truth: database, provider, file, auth service, entitlement system, inventory source,
+  canonical event stream, generated artifact, or other owner.
+- Cached value shape: detail item, list, page, search result, permission decision, session, rate
+  limit, inventory, feature flag, API response, rendered HTML, or derived aggregate.
+- Key dimensions: tenant, actor, viewer context, login state, membership tier, country, language,
+  locale, A/B test, feature flag, adult verification, inventory policy, authorization state, headers,
+  query parameters, schema version, and value version.
+- Freshness contract: change frequency, stale tolerance, soft TTL, hard TTL, invalidation trigger,
+  source protection need, and deploy or rollback compatibility.
+- Failure and concurrency contract: miss behavior, concurrent miss behavior, source timeout, Redis
+  failure, source failure, negative cache policy, update race behavior, invalidation ordering, and
+  stale serve policy.
+- Observability evidence: hit and miss metrics, miss cost, value size, key count, eviction, expiry,
+  tenant or endpoint breakdown, status-code breakdown, source query time, source call count, and set
+  success.
+- 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 cache authority, key, TTL, invalidation, fallback,
+  observability, or test evidence can be reported without guessing.
+- If cache behavior affects authentication, authorization, personal data, tenant separation, sessions,
+  entitlement, payment, inventory, or admin operations, also use the relevant security, auth, backend,
+  database, or failure-integrity skill.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten cache key construction, query normalization, key versioning, TTL and jitter,
+  soft/hard TTL handling, stale-while-revalidate, request coalescing, singleflight, bounded fallback,
+  load shedding, negative-cache policy, invalidation ordering, version checks, tag invalidation,
+  cache warming, cache observability, and focused tests tied to the changed cache surface.
+- Split cache policy by success, not-found, permission-denied, temporary failure, stale value, and
+  unknown outcome when those outcomes need different behavior.
+- Add tests for tenant separation, permission changes, stale value bounds, concurrent misses, source
+  failures, Redis failures, synchronized expiry, old-version cached values, update races, delete and
+  recreate flows, and deploy rollback when feasible.
+- Do not add speculative cache layers, global flush buttons, unbounded fallback to the source, broad
+  cache bypasses, or TTL guesses without an explicit source-of-truth and stale-tolerance contract.
+- Do not trade authorization, privacy, money, entitlement, inventory, ordering, or user trust for
+  hit rate without explicit product acceptance.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the second truth store. State the source of truth, cached value, allowed stale duration, and
+   whether the cached value is disposable or can affect security, money, entitlement, inventory, or
+   user-visible facts.
+2. Check key truth before speed.
+   - The key must include every dimension that changes meaning or visibility: tenant, actor, viewer
+     context, login state, membership tier, country, language, locale, A/B test, feature flag, adult
+     verification, inventory policy, authorization state, and relevant request headers.
+   - A key such as `product:{id}` is unsafe when the response varies by the viewer.
+3. Check query normalization.
+   - Sort order-insensitive query parameters, remove defaults, normalize types, define empty value
+     handling, and state whether array order is meaningful.
+   - Treat raw `JSON.stringify(query)` as suspect until key stability, default handling, and array
+     semantics are explicit.
+4. Check key version and schema version.
+   - Cache keys or values need a version when response shape, serialization, permission meaning,
+     query semantics, or source fields change.
+   - During deploy and rollback, old and new code must either read both formats safely, reject old
+     values clearly, or use separate versioned keys.
+5. Check TTL as a contract.
+   - TTL is not a guess like "five minutes". Tie it to data change rate, stale tolerance, and source
+     protection.
+   - Add TTL jitter when many keys are filled together so synchronized expiry does not become an
+     expiry bomb.
+   - Separate soft TTL from hard TTL when stale-while-revalidate or stale serve during source failure
+     is allowed.
+6. Check miss collapse and stampede control.
+   - A miss path of `get -> source -> set` is incomplete for hot keys.
+   - Look for lock, lease, singleflight, request coalescing, bounded regeneration, early refresh,
+     prewarm, or another mechanism that stops one expired hot key from sending every caller to the
+     source.
+7. Check negative and failure caching.
+   - Negative cache can protect the source for expensive misses, but success, `404`, `403`, temporary
+     failure, timeout, and unknown outcome need separate TTLs and separate meanings.
+   - Do not let a transient outage become a long-lived "not found" or "not allowed" fact.
+8. Check invalidation ordering.
+   - Delete-before-commit can resurrect old values when another request refills from the old source
+     value before the commit lands.
+   - Prefer commit-after-delete, outbox-driven invalidation, version compare, write-through, or a
+     local pattern that prevents old values from winning after the durable write.
+9. Check update races.
+   - Updating the cache after a write is not automatically safe. A slower older write can overwrite
+     a newer value.
+   - Use updatedAt, monotonic version, CAS, conditional write, compare-and-set, or cache delete when
+     ordering cannot be proven.
+10. Check list, query, and page caches separately from detail caches.
+    - List caches are harder than detail caches because latest, popular, tag, author, search, filter,
+      and page keys all change when one entity changes.
+    - Page-number caches are vulnerable to insertions and deletions. Prefer cursor keys, baseline
+      time, snapshot token, or explicit duplicate and gap behavior for feeds and infinite scroll.
+    - If tag-based invalidation is missing for compound queries, expect global flush pressure and
+      report the operational cost.
+11. Check cache layers.
+    - Local in-memory cache splits truth per server. L1, L2, and DB each need TTL, invalidation,
+      bypass, and failure behavior.
+    - Deleting L2 while L1 survives can leave "sometimes stale" bugs that depend on load-balancer
+      routing.
+12. Check cache outage fallback.
+    - Redis down plus unbounded DB fallback can kill the source. Fallback needs rate limit, load
+      shedding, stale serve, circuit breaker, bulkhead, or another source-protection mechanism.
+    - Decide whether cache failure is disposable or correctness-sensitive. Sessions, permissions,
+      rate limits, inventory, idempotency, and dedupe caches are not ordinary performance caches.
+13. Check Redis keyspace and memory behavior.
+    - Review value size, key size, key schema, bounded key cardinality, max memory, eviction policy,
+      expired keys, evicted keys, and whether TTL-less keys are turning cache into state storage.
+    - `noeviction` makes writes fail at memory limit. `volatile-*` policies only evict keys with TTL,
+      so TTL-less keys can crowd out real cache behavior.
+    - `KEYS *` in application code is a production bomb. Use `SCAN` only from bounded admin or
+      maintenance paths with explicit limits.
+14. Check hot keys and Redis Cluster distribution.
+    - Sharding does not save one hot key. Use replicas, local L1, request coalescing, prewarm,
+      chunking, or workload-specific splitting where semantics allow it.
+    - Redis Cluster hash tags are useful for intentional multi-key locality, but overusing the same
+      tag can force too many keys into one slot.
+15. Check HTTP cache semantics.
+    - If responses vary by `Authorization`, `Cookie`, `Accept-Language`, `Accept-Encoding`, content
+      negotiation, or user context, verify `Vary` and cache-control behavior.
+    - `no-cache` means revalidate before reuse. `no-store` means do not store. Do not use one when
+      the other is required.
+    - Check freshness, validation, private versus public cacheability, CDN behavior, browser behavior,
+      and generated-client or proxy expectations.
+16. Check permission and entitlement caches as security boundaries.
+    - A permission cache, role cache, organization-membership cache, subscription cache, admin cache,
+      or entitlement cache must be invalidated by revocation, role change, organization move,
+      subscription expiry, ownership change, and emergency access changes.
+    - Short TTL alone is not enough for decisions that should fail closed or revoke promptly.
+17. Check cache warming and cold-start behavior.
+    - Deployment, autoscale, failover, and rollback can create synchronized cold caches that push
+      traffic to the source.
+    - Prewarm only keys with clear ownership and backpressure. Do not build an unbounded warming job
+      that becomes the outage.
+18. Check observability.
+    - Hit rate alone lies. Break down hits, misses, stale serves, negative hits, refresh failures,
+      evictions, expirations, and set failures by endpoint, key-pattern, tenant, status-code, and
+      cache layer where useful.
+    - Log or measure miss cost: source query time, source call count, value size, generation time,
+      and set success.
+    - Keep cache metrics labels bounded; put high-cardinality keys in logs or traces only when the
+      repository privacy rules allow it.
+19. Check tests beyond the happy path.
+    - "Second call is faster" is not enough.
+    - Cover concurrent misses, update during read, delete then recreate, source failure, Redis
+      failure, synchronized TTL expiry, old-version cached value, permission change, tenant
+      separation, list invalidation, negative-cache classification, deploy rollback, and cache-layer
+      bypass when those risks exist.
+20. Label evidence honestly. If the repository lacks deterministic cache, Redis, CDN, HTTP, browser,
+    or load tests, report the missing evidence instead of claiming the cache is safe.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Cache source of truth, value shape, key dimensions, stale tolerance, TTL, invalidation, fallback,
+  and observability are explicit or reported as missing.
+- Tenant, viewer, permission, entitlement, feature-flag, locale, query, schema-version, and header
+  variance cannot silently share the wrong value.
+- Stampede, synchronized expiry, negative cache, invalidation ordering, update race, list cache,
+  page cache, tag invalidation, L1/L2 layering, Redis outage, hot key, Redis Cluster, and HTTP cache
+  semantics are fixed or reported where relevant.
+- Permission and entitlement caches fail closed or invalidate promptly where stale values are unsafe.
+- Cache claims are backed by configured evidence or labeled as static review risk, manual-only, or
+  missing evidence.
+
+<!-- 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 covers the changed
+cache key, stale-data, invalidation, fallback, or observability contract. Do not infer raw Redis, CDN,
+browser, server, benchmark, or load-test commands outside the command contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If verification fails, preserve the failing intent, failing assertion or output tail, and the cache
+  contract it exercised before editing again.
+- If key dimensions, source-of-truth ownership, stale tolerance, invalidation trigger, or permission
+  revocation behavior are unknown, report the missing decision instead of adding a cache or guessing a
+  TTL.
+- If safe cache behavior requires a tag index, outbox, versioned read model, CAS support, circuit
+  breaker, bounded fallback, or operational Redis/CDN evidence outside the current scope, report the
+  missing boundary and keep local changes narrow.
+- If deterministic cache proof requires live Redis, CDN, browser, load-test, or production telemetry
+  not configured in `.mustflow/config/commands.toml`, complete available local verification and report
+  the manual evidence gap.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Cache surface reviewed
+- Source of truth, cached value, key dimensions, stale tolerance, TTL, invalidation, and fallback
+  decisions
+- Key normalization, key version, query normalization, viewer context, tenant and permission boundary
+  checks
+- Stampede, negative-cache, invalidation-order, update-race, list/page/tag, L1/L2, Redis, hot-key,
+  HTTP cache, permission-cache, warming, and observability checks where relevant
+- Cache-integrity fixes made or recommended
+- Evidence level: configured-test evidence, static review risk, manual-only, missing, or not applicable
+- Command intents run
+- Skipped cache diagnostics and reasons
+- Remaining cache-integrity risk

package/templates/default/locales/en/.mustflow/skills/change-blast-radius-review/SKILL.md

@@ -0,0 +1,297 @@
+---
+mustflow_doc: skill.change-blast-radius-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: change-blast-radius-review
+description: Apply this skill when code is created, changed, reviewed, or reported and maintainability needs review by predicting the next-change blast radius, deletion path, policy owner, workflow owner, controller or service responsibility, boolean and option-mode sprawl, scattered domain rules, scattered authorization, state-transition ownership, direct time or randomness, transaction and external-call coupling, retry idempotency, cache-as-truth decisions, config flag combinations, tenant or partner hardcoding, legacy branch isolation, DTO/entity/view model mixing, nullable meaning, swallowed exceptions, low-context logs, implementation-coupled tests, mock-heavy tests, decorative abstraction, premature DRY, hidden ordering dependency, event contract visibility, migration/runtime compatibility, or feature removal boundary.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.change-blast-radius-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Change Blast Radius Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review maintainability by predicting where the next change, failure, retry, migration, or deletion
+will spread.
+
+The review question is not "is this code clean?" It is "if the policy changes, where do I edit;
+if the flow fails halfway, what state remains; if the event runs twice, is it safe; and if the
+feature is removed, what can I delete?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code review, implementation, or refactor work touches domain policies, controllers, services,
+  use cases, workflows, DTOs, entities, view models, authorization, state transitions, persistence,
+  transactions, external APIs, retries, caches, config flags, tenant branches, migrations, events,
+  logging, tests, abstractions, helpers, or legacy compatibility.
+- A single requirement would force edits across several files, layers, modules, frontend code, SQL,
+  jobs, events, cache keys, tests, or docs.
+- A file or service has several unrelated reasons to change under one broad noun such as `Manager`,
+  `Helper`, `Processor`, `Handler`, or `Service`.
+- A review needs to decide whether to use `module-boundary-review`, `structure-first-engineering`,
+  `testability-boundary-review`, `failure-integrity-review`, `cache-integrity-review`,
+  `auth-permission-change`, `state-machine-pattern`, `strategy-pattern`, `result-option`, or
+  `database-migration-change`.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The only concern is module ownership, import direction, DTO leakage, or co-change evidence; use
+  `module-boundary-review` as the primary skill.
+- The task is early implementation structure for a known feature; use `structure-first-engineering`
+  first and this skill only for predicted change-spread evidence.
+- The main issue is deterministic tests or hidden test inputs; use `testability-boundary-review`.
+- The main issue is a specific failure path, cache invariant, authorization boundary, migration,
+  state machine, strategy, result type, or dependency-injection seam; use the narrower skill first.
+- The change is a tiny pure helper with explicit inputs, deterministic output, no policy, no I/O,
+  no shared state, and no meaningful future-change branch.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User goal, current diff or target files, and the requirement or policy that caused the change.
+- Change-reason ledger: which business rule, user flow, data shape, failure path, compatibility
+  rule, tenant exception, or operational behavior would make this code change next.
+- Blast-radius ledger: controllers, services, repositories, entities, DTOs, frontend conditions,
+  SQL, migrations, batches, events, caches, config, tests, docs, and templates touched by one reason.
+- Ownership ledger: source of truth for domain rule, authorization rule, state transition, retry
+  rule, transaction boundary, cache truth, event contract, log context, and data model language.
+- Deleteability ledger: what files, flags, columns, event handlers, cache keys, tests, and branches
+  would need removal if the feature or policy disappears.
+- Test and operations evidence: mocks, call-order assertions, logs, trace IDs, retry/idempotency
+  behavior, migration compatibility, and configured command intents.
+
+<!-- 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 blast-radius, ownership, deleteability, or operational
+  evidence can be reported without guessing.
+- If the review finds a concrete module, failure, cache, authorization, migration, state-machine,
+  testability, or pattern issue, use the narrower skill before editing that part.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Move or name ownership for domain policy, authorization, state transitions, workflow sequencing,
+  retry/idempotency, transaction boundaries, DTO mapping, cache truth, config interpretation, event
+  contracts, logs, migrations, and tests directly tied to the reviewed change-spread risk.
+- Split responsibilities only when the split follows different reasons to change, not because a
+  file is long or the names look untidy.
+- Replace boolean mode flags, trash-can option objects, tenant hardcoding, legacy branches, and
+  premature shared helpers with explicit concepts, named policies, adapters, or duplicated code
+  when that reduces future change spread.
+- Add focused tests that prove a policy owner, state transition, idempotent retry, deletion boundary,
+  migration compatibility, or stable observable outcome.
+- Do not add decorative interfaces, broad service layers, generic managers, speculative factories,
+  or shared helpers that hide rather than reduce the next-change blast radius.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Start with the next likely change.
+   - Ask: "If this requirement changes next month, which files move?"
+   - If one policy edit needs controller, service, repository, SQL, frontend, batch, cache, and test
+     edits, the code is a puzzle, not a boundary.
+2. Count reasons to change, not lines.
+   - A short file can still hold signup, login, points, notification, referral, admin blocking, and
+     reporting rules.
+   - Split by different change reasons, not by noun labels.
+3. Keep controllers as doors, not bosses.
+   - Controllers should parse requests, call an application boundary, and map the result.
+   - Treat controller `if`, `for`, state mutation, external API calls, discount logic, inventory
+     checks, or notification orchestration as workflow leakage.
+4. Reject junk-drawer services.
+   - Broad names such as `OrderService`, `UserService`, `Manager`, `Helper`, `Processor`, and
+     `Handler` often hide unrelated workflows.
+   - Name the actual responsibility or split by workflow owner when changes would not arrive
+     together.
+5. Decode boolean mode flags.
+   - `createUser(user, true)` and `sendNotification(user, true, false)` mean one function already
+     has hidden modes.
+   - Replace modes with named variants, policy objects, strategy objects, or separate functions when
+     behavior contracts differ.
+6. Inspect option objects for combinatorial behavior.
+   - Fields such as `skipValidation`, `dryRun`, `force`, `source`, `mode`, `type`, `retry`,
+     `legacy`, and `includeInactive` can turn one call into many products.
+   - If field combinations change behavior, use explicit mode types or separate boundaries.
+7. Find the policy source of truth.
+   - Repeated rules such as "VIP gets free shipping" across backend, frontend, SQL, batch, and
+     cache code are not harmless duplication.
+   - Name one owner and make other layers consume facts or capabilities from that owner.
+8. Centralize authorization policy.
+   - Scattered checks such as `role == admin`, `ownerId == user.id`, or membership scans make policy
+     changes scary.
+   - Use `auth-permission-change` when action permission needs one policy source and denial tests.
+9. Make state transitions visible.
+   - Status values are not enough. Review where `status = ...` happens and which transitions are
+     legal.
+   - Use `state-machine-pattern` when allowed transitions need to be represented explicitly.
+10. Pull time, randomness, and generated IDs to a boundary.
+    - Direct `new Date()`, `Date.now()`, `LocalDateTime.now()`, UUIDs, random order numbers, random
+      filenames, and generated referral codes hide reproducibility and future policy changes.
+    - Use explicit time, generator, or identifier inputs from the shell.
+11. Draw the transaction boundary.
+    - When several saves happen, ask what remains if the middle save fails.
+    - If the answer is unclear, use `failure-integrity-review` or the relevant database skill before
+      changing behavior.
+12. Separate external calls from committed state.
+    - DB save, payment API, DB save, notification API in one flow creates timeout, retry, and
+      duplicate-effect traps.
+    - Prefer local state plus outbox, idempotency keys, or effect descriptions when the operation
+      must survive partial failure.
+13. Check retry idempotency.
+    - `retry(3)`, queues, webhooks, schedulers, and manual replays are dangerous without a duplicate
+      rule.
+    - Ask what happens when the same event arrives twice.
+14. Reject cache-as-truth for important decisions.
+    - Cache can speed reads, but it should not become the source of truth for authorization, payment
+      eligibility, inventory, or other critical decisions.
+    - Use `cache-integrity-review` when cache freshness or fallback can mislead the decision.
+15. Count config flag combinations.
+    - Flags such as `enableNewPolicy`, `useLegacyFlow`, `skipValidationForPartner`, and
+      `specialCaseTenantIds` can create untested products inside one code path.
+    - Name the supported combinations or isolate the variation behind a policy boundary.
+16. Isolate tenant, partner, country, product, and app-version exceptions.
+    - Hardcoded `tenantId`, `partnerCode`, country code, app version, or product ID branches are
+      product debt, not just conditionals.
+    - Prefer configured capabilities, adapters, policy tables, or explicit exceptions with removal
+      owners.
+17. Keep legacy compatibility out of the new core.
+    - `legacy`, `old`, `v1`, `deprecated`, and `temp` branches inside the main path pull old rules
+      into new code.
+    - Put compatibility in adapters, translators, migration paths, or isolated old-entry boundaries.
+18. Separate data-object languages.
+    - DB entities, API DTOs, view models, external provider payloads, and domain objects should not
+      quietly become the same object.
+    - If one side changes and another side must follow, name the mapping owner.
+19. Give nullable values a reason.
+    - `null` must not mean absence, unknown, failed calculation, forbidden access, and provider
+      timeout at the same time.
+    - Use variants, result types, or explicit fields that tell callers why a value is missing.
+20. Do not hide exceptions as normal data.
+    - `catch (e) { return null }`, `catch (e) { log.warn(...) }`, and empty catches make the system
+      lie far from the failure.
+    - Use visible failure values, typed errors, or explicit degraded modes.
+21. Make logs traceable, not decorative.
+    - Logs like `start` and `failed` without order ID, user ID, request ID, external call ID, tenant,
+      or operation name do not help future maintainers.
+    - Add safe correlation context when it is the only way to connect the failure path.
+22. Keep tests attached to behavior.
+    - Tests that assert private methods, mock call order, or internal collaborator choreography make
+      refactors expensive.
+    - Prefer outcomes, state transitions, persisted commands, emitted events, or public results.
+23. Treat mock count as a change-impact sensor.
+    - More than three mocks deserves a responsibility review.
+    - Five or more mocks usually means the class absorbs too many change directions.
+24. Validate abstraction against real volatility.
+    - Interfaces, factories, strategies, and abstract classes help only when the variation axis is
+      real.
+    - Ask whether there are two real implementations now or a known future swap along this exact
+      axis.
+25. Do not DRY together different futures.
+    - Removing duplication is harmful when two similar blocks change for different reasons.
+    - Keep duplication when it preserves independent policy evolution.
+26. Make required ordering explicit.
+    - Initialization, validation, save, event publication, cache invalidation, notification, and
+      cleanup steps can be order-sensitive.
+    - If swapping two lines would break correctness, encode the sequence in a named workflow,
+      transaction, state transition, or command object.
+27. Treat events as invisible function calls until proven otherwise.
+    - `publish(Event)` hides subscribers, failure behavior, ordering, duplicate delivery, and
+      compatibility.
+    - Name the event contract, listener expectations, idempotency, and failure handling.
+28. Pair migrations with runtime compatibility.
+    - Schema changes, enum additions, defaults, indexes, and backfills must be checked against old
+      code on new schema and new code on old data.
+    - Use `database-migration-change` when deploy order or data backfill matters.
+29. Run the deletion test.
+    - Ask: "If this feature disappears, what do I delete?"
+    - If flags, columns, conditions, events, caches, batch jobs, UI checks, and tests are scattered,
+      the feature is already rooted too deeply.
+30. Pick the smallest boundary repair.
+    - If one owner is missing, introduce that owner.
+    - If one mode is hidden, name that mode.
+    - If the risk is too broad for the current task, report the exact next-change or deletion path
+      that remains unpredictable.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The next likely policy or workflow change has a named owner and a predictable edit path, or the
+  unpredictable spread is explicitly reported.
+- Important side effects, transactions, retries, events, caches, config flags, migrations, and logs
+  have clear owners or remaining risks.
+- Boolean modes, option-object combinations, tenant exceptions, legacy compatibility, and premature
+  shared helpers are either tightened or named as future-change traps.
+- Tests and observability focus on outcomes, state, events, idempotency, and public behavior rather
+  than private choreography.
+- The deletion path for the changed feature or policy is clearer, or the remaining deletion debt is
+  named.
+
+<!-- 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 the narrowest checks that cover the changed owner, behavior, tests, template surface, or
+public contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the blast radius cannot be predicted from current evidence, report the missing owner, hidden
+  dependency, unknown subscriber, migration uncertainty, or deletion path instead of inventing a
+  clean boundary.
+- If the review discovers security, cache, failure, migration, testability, or state-machine risk,
+  switch to the narrower skill before editing that part.
+- If a boundary repair would change behavior, use `behavior-preserving-refactor` or
+  `repro-first-debug` before continuing.
+- If a command fails, use `failure-triage` before further edits.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Change blast radius reviewed
+- Next likely change and owner
+- Files, layers, jobs, caches, events, tests, docs, or migrations in the blast radius
+- Policy, authorization, state, transaction, retry, cache, config, tenant, legacy, DTO, nullable,
+  log, test, abstraction, ordering, event, migration, or deletion findings
+- Fixes made or recommendation
+- Tests or behavior evidence
+- Command intents run
+- Skipped checks and reasons
+- Remaining change-spread or deletion risk