mustflow 2.108.3 → 2.112.1

package/templates/default/locales/en/.mustflow/skills/split-refactor-residual-path-review/SKILL.md

@@ -0,0 +1,176 @@
+---
+mustflow_doc: skill.split-refactor-residual-path-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: split-refactor-residual-path-review
+description: Apply this skill when a refactor splits files, extracts handlers, moves event ownership, relocates state mutations, or claims a responsibility moved, and the review must prove old execution paths, listeners, effects, dispatches, imports, feature-flag fallbacks, tests, and lifecycle cleanup no longer keep the previous behavior alive.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.split-refactor-residual-path-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Split Refactor Residual Path Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review file-splitting and responsibility-moving refactors by proving the old path lost authority.
+
+The main question is not "was a nicer new module added?" It is "can the old file, handler, listener, effect, dispatch, mutation, route, middleware, consumer, or fallback still process the same event or state change?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A PR or local diff splits a file, extracts a component, handler, reducer, service, route, listener, worker, middleware, controller, or event processor.
+- A responsibility is claimed to move from one owner to another, especially event receive, event interpretation, state mutation, side effect, API request, cache update, analytics emission, or cleanup ownership.
+- A previous bug may reappear because old conditions, callbacks, effects, subscriptions, imports, feature flags, fallbacks, or tests still exercise the old path.
+- Review needs to distinguish a true move from code duplication, partial extraction, or a new module that is not connected to the real entrypoint.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a broad behavior-preserving refactor with no file split, handler relocation, state mutation relocation, or old-path risk; use `behavior-preserving-refactor`.
+- The main concern is general module ownership, import direction, DTO leakage, or policy owner placement; use `module-boundary-review`.
+- The task only asks for changed-file risk classification and verification selection; use `diff-risk-review`.
+- The change is a pure rename or formatting-only move with no runtime entrypoint, listener, state, side effect, feature flag, or test routing impact.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Refactor claim: what responsibility moved, from where, to where, and what behavior should remain unchanged.
+- Current diff shape: added files, deleted lines, moved code, old files that remain, imports changed, and tests changed.
+- Residual keyword ledger: old bug keywords, event names, action types, handler names, API calls, state field names, feature flag names, selector names, cache keys, analytics names, route names, job names, and middleware names.
+- Entry and ownership ledger: event receiver, interpreter, state mutator, side-effect owner, external request owner, cleanup owner, and public entrypoints before and after the split.
+- Lifecycle ledger: mount, unmount, remount, route change, modal close, tab switch, reconnect, retry, worker restart, consumer rebalance, or job replay behavior when relevant.
+- Test ledger: existing regression tests, new module unit tests, real-entrypoint integration tests, duplicate-execution tests, cleanup tests, ordering tests, and static boundary rules.
+
+<!-- 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.
+- Existing local patterns for file moves, handler ownership, event routing, state mutations, lifecycle cleanup, feature flags, and tests have been searched before recommending a new pattern.
+- If the residual path affects payments, auth, notifications, persistence, cache truth, concurrency, or UI resurrection, also apply the narrower matching skill for that boundary.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Remove old handlers, conditions, effects, subscriptions, dispatches, emits, mutations, imports, fallback branches, direct API calls, cache updates, analytics calls, or cleanup logic that still own the moved responsibility.
+- Convert the old owner into a pure adapter, delegator, or view when the new owner should interpret and mutate state.
+- Add or tighten boundary guards such as import restrictions, module boundary rules, lint rules, dependency rules, or package exports that prevent the old owner from importing moved event types or handlers.
+- Add focused tests for real entrypoint routing, old-path non-execution, single execution, lifecycle cleanup, ordering, feature-flag fallbacks, and regression scenarios tied to the moved responsibility.
+- Do not keep duplicate old and new paths "for safety" unless the product contract explicitly requires parallel behavior and the diff names the compatibility sunset.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Start with the diff shape.
+   - Compare added files with deleted old responsibility.
+   - Treat a refactor that mostly adds new code while barely deleting old conditions, effects, handlers, cleanup, or side effects as suspected duplication.
+   - Separate mechanical moves from semantic changes before judging correctness.
+2. Name the moved responsibility.
+   - State exactly what moved: receive event, interpret event, update state, perform external request, emit analytics, update cache, route command, validate input, cleanup listener, or publish event.
+   - If the responsibility cannot be named, use `behavior-preserving-refactor` or `module-boundary-review` before editing.
+3. Search residual paths.
+   - Search old bug keywords, event names, action types, handler names, API calls, state fields, feature flags, selectors, cache keys, analytics names, route names, job names, middleware names, and callback names.
+   - Inspect neighborhoods around `onClick`, `onChange`, `addEventListener`, `subscribe`, `dispatch`, `emit`, `useEffect`, `watch`, `listener`, `handler`, `middleware`, `controller`, `route`, `consumer`, `job`, and `callback`.
+   - Treat old imports of moved event types, handlers, mutation helpers, or state fields as evidence that the move may be incomplete.
+4. Check single ownership of the event path.
+   - The old location may pass data through or render output, but it should not still decide what the event means.
+   - Event receiving, event interpretation, state mutation, and external side effects should not be split halfway between old and new owners unless a named compatibility adapter explains why.
+   - If both old and new owners listen to the same event, identify whether one is dead, delegated, compatibility-only, or a duplicate-execution bug.
+5. Trace state mutation authority.
+   - Follow reducers, store mutations, local setters, optimistic updates, query-cache writes, form sync, repository writes, job state, and side-effect acknowledgements.
+   - Reject designs where the new owner changes state and the old owner later recomputes, overwrites, or replays the old value.
+6. Check feature flags and fallback paths.
+   - Review flag on, flag off, legacy mode, mobile, SSR, permission-denied, empty data, error retry, offline, reconnect, old route, and tenant or partner branches.
+   - All supported branches should route the responsibility to the same owner, or the diff should explicitly classify the divergence.
+7. Check dependency direction.
+   - A new event owner should not import old UI internals, container-only constants, private helpers, or test-only wiring from the old location.
+   - Move stable contracts to a shared domain, type, adapter, or public module surface only when that reduces ownership ambiguity.
+8. Review tests for real routing, not only new module correctness.
+   - A unit test that calls the new module directly is not enough when the real user or system event may still enter the old path.
+   - Prefer tests where the real click, route, message, API request, worker event, queue message, or dispatch enters the app and reaches the new owner.
+   - Keep or add the old bug reproduction as a regression guard when the refactor is meant to prevent recurrence.
+9. Add duplicate-execution tests when side effects matter.
+   - Assert one click, request, dispatch, event, analytics call, notification, charge, save, cache update, or job replay is handled once.
+   - Check counts, idempotency keys, emitted events, persistence writes, and external calls rather than only final visible state.
+10. Add lifecycle and cleanup evidence.
+   - Test or inspect mount, unmount, remount, route change, modal close, tab switch, reconnect, consumer restart, and job replay when listeners or subscriptions moved.
+   - Ensure the subscription and cleanup moved together; a split subscription and old cleanup is usually unstable.
+11. Check ordering.
+   - Preserve important sequences such as validate, normalize, update, persist, notify, cleanup, ack, and publish.
+   - If swapping two steps would break correctness, encode that sequence in one owner or a test that observes the ordering.
+12. Add structural guardrails when the old path is easy to reintroduce.
+   - Prefer `no-restricted-imports`, dependency-cruiser, module boundary rules, package exports, or local lint rules over a comment that asks humans to remember.
+   - Guard only the moved responsibility; do not create broad architecture rules unrelated to the current refactor.
+13. Decide the outcome.
+   - If old and new paths both execute, fix the residual path when in scope.
+   - If the residual path is intentional compatibility, document the sunset and tests.
+   - If evidence is insufficient, report the missing entrypoint, lifecycle, flag, ordering, or static-boundary proof.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The old location either no longer owns the moved responsibility, is a pure delegator, or has a documented compatibility role.
+- Real entrypoints route through the new owner.
+- Duplicate listeners, dispatches, state mutations, external requests, cache writes, analytics calls, and cleanup ownership are removed or reported.
+- Feature flags, fallback branches, lifecycle cleanup, ordering, and tests prove the old path cannot silently revive the previous behavior.
+
+<!-- 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`
+
+Use the narrowest configured test, lint, build, docs, release, or mustflow intent that covers the moved responsibility, static boundary guard, template surface, or public contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the old responsibility cannot be located, stop and report the missing residual keyword, entrypoint, or ownership evidence.
+- If tests only call the new module directly, report the real-entrypoint gap before claiming the refactor prevents regression.
+- If removing the old path changes behavior, split the work into a behavior-preserving refactor and a separate behavior change or bug fix.
+- If a boundary rule would block valid callers, narrow the rule to the moved responsibility instead of weakening the review.
+- If a configured command fails, preserve the failing intent and use `failure-triage` before unrelated edits.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Split refactor surface reviewed
+- Moved responsibility and old versus new owner
+- Diff-shape evidence: additions, deletions, moved code, old imports, and old conditions
+- Residual path search terms and findings
+- Event, state mutation, side-effect, feature-flag, lifecycle, cleanup, and ordering evidence
+- Tests added, updated, missing, or intentionally deferred
+- Static boundary guard added or intentionally avoided
+- Fixes made or recommendation
+- Command intents run
+- Skipped checks and reasons
+- Remaining residual-path risk

package/templates/default/locales/en/.mustflow/skills/technology-stack-selection/SKILL.md

@@ -0,0 +1,328 @@
+---
+mustflow_doc: skill.technology-stack-selection
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: technology-stack-selection
+description: Apply this skill when choosing, adding, replacing, upgrading, rejecting, or standardizing a technology stack, framework, runtime, database, cache, queue, auth provider, payment provider, AI provider, SDK, hosting platform, deployment tool, build tool, ORM, observability tool, or vendor integration, especially when the decision affects migration path, rollback path, ecosystem maturity, maintainer risk, debugging surface, lock-in, CI/CD cost, deployment cost, operating toil, or solo-maintainer survivability.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.technology-stack-selection
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_related
+    - test_release
+    - mustflow_check
+---
+
+# Technology Stack Selection
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose technology by whether the project can operate, debug, deploy, upgrade, pay for, and
+replace it for the full expected life of the product.
+
+This skill prevents agents from accepting technology because it is fashionable, fast in a
+benchmark, convenient for a demo, popular in another company's architecture, or attractive to the
+developer. For indie, solo, and small-team projects, the core question is whether the stack can
+keep earning value while the maintainer is tired, busy, away from the codebase, or handling an
+incident without a dedicated platform team.
+
+Treat survival-path decisions as failure-survivability decisions, not feature-implementation
+decisions.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task chooses, compares, adopts, replaces, upgrades, rejects, or standardizes a technology,
+  framework, runtime, database, queue, cache, auth provider, payment provider, AI provider, SDK,
+  hosting platform, deployment tool, build tool, ORM, observability tool, package ecosystem, or
+  vendor integration.
+- A technology is proposed for authentication, authorization, billing, payment, durable data,
+  permissions, deployment, backup, restore, queueing, file storage, customer money, customer data,
+  security, or another survival path.
+- The decision depends on migration path, rollback path, local reproducibility, CI/CD cost,
+  deployment cost, operating toil, observability cost, backup and restore cost, maintainer capacity,
+  hiring availability, lock-in, data export, ecosystem maturity, or debugging surface.
+- A new or experimental technology may belong in a differentiating edge feature, internal tool,
+  read-only path, derived-data path, analytics surface, search layer, recommendation layer, AI
+  layer, or feature-flagged experiment.
+- A stack choice is being justified for solo, indie, small-team, funded-startup, open-source,
+  library, or enterprise contexts where the same technology can be appropriate in one context and
+  dangerous in another.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only edits code within an already selected technology and no new dependency, runtime,
+  vendor, data contract, deployment path, or operational surface is being chosen. Use the matching
+  implementation skill.
+- The task only checks whether a dependency exists, is declared, or is safe to import. Use
+  `dependency-reality-check`.
+- The task only chooses a primary language, runtime, compile target, or execution environment. Use
+  `runtime-target-selection` first, then this skill only for broader stack and operations tradeoffs.
+- A user or repository owner has already mandated the technology. In that case, use this skill only
+  to document constraints, guardrails, migration, rollback, observability, and verification.
+- The task asks for an unconstrained brainstorming list with no adoption decision. Use
+  `idea-triage` or `complex-decision-analysis` when those narrower conditions match.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Decision scope: affected product surface, repository, packages, services, data, deployment,
+  users, operators, and time horizon.
+- Candidate technologies: name, intended role, version range when relevant, adoption type, and
+  whether the candidate is a new stack, replacement, upgrade, or vendor migration.
+- Baseline and boring default: current choice, no-change option, most conventional low-risk option,
+  current pain, current costs, known failure modes, and existing team knowledge.
+- Criticality: `experiment`, `internal_tool`, `customer_facing`, `production_core`, or
+  `irreversible_core`.
+- Reversibility class: `code_only`, `config`, `build_pipeline`, `runtime_dependency`,
+  `persistent_data`, `public_api`, `customer_workflow`, `vendor_contract`, `security_boundary`, or
+  `money_or_permission`.
+- Team and maintainer capacity: solo, indie, small team, funded startup, enterprise, open-source
+  maintainer count, on-call owner, runbook owner, training cost, and hiring or support availability.
+- Evidence: repository patterns, official docs, changelogs, migration guides, security advisories,
+  issue trackers, production incidents, prototypes, CI results, command receipts, pricing pages, and
+  support or SLA evidence when available.
+- Success and failure criteria: what must improve, what must not regress, what would stop the
+  adoption, and what evidence would reverse the recommendation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the
+  current scope.
+- External AI output, blog posts, vendor marketing, popularity signals, benchmark claims, and
+  famous-company usage are evidence candidates only, not authority.
+- Current external facts such as versions, prices, license terms, platform limits, and release
+  status are refreshed through an authorized source path or marked as unverified when they affect
+  the decision.
+- The status quo and a boring default are included unless the user explicitly fixed the option set.
+- A narrower implementation skill will be selected before editing implementation files.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Create or update technology decision records, architecture notes, migration plans, rollback
+  plans, runbook notes, route metadata, skill procedures, template metadata, tests, and docs that
+  directly support the stack decision.
+- Add only the smallest reversible implementation scaffold when the user requests implementation
+  and the decision has passed this skill's gates.
+- Do not install dependencies, run package managers, start services, run benchmarks, perform
+  migrations, deploy, open vendor dashboards, or change cloud resources unless the repository
+  command contract and user request explicitly allow that action.
+- Do not let a score total, popularity, benchmark, developer experience, or novelty override a hard
+  rejection gate.
+
+<!-- mustflow-section: core-definitions -->
+## Core Definitions
+
+`survival_path` means a path where failure can block accounts, money, permissions, durable data,
+deployment, backup, recovery, customer trust, or the maintainer's ability to keep the product alive.
+Typical surfaces include auth, authorization, payment, billing, database, deployment, backup,
+restore, queues, file storage, secrets, customer money, customer data, and operational recovery.
+
+`migration_path` means a staged move from the baseline to the candidate while keeping the product or
+workflow usable. It covers code, data, configuration, deployment, tests, cutover, ownership, and the
+middle state. A big-bang rewrite is not a migration path.
+
+`rollback_path` means a rehearsable return to the previous stable state or a safe degraded state. It
+covers data compatibility, schema compatibility, feature flags, routing, backups, cutover timing,
+customer impact, and the point after which rollback becomes unsafe. Backup alone is not rollback.
+
+`ecosystem_maturity` means the candidate and its surrounding tools can survive ordinary production
+use: docs, changelogs, migration guides, security response, integrations, testing tools, debugging
+tools, production failure knowledge, release cadence, and available operators.
+
+`maintainer_risk` means the risk that the candidate becomes abandoned, unsupported, vendor-captured,
+relicensed, incompatibly changed, underfunded, or dependent on too few people.
+
+`debugging_surface` means the layers and opaque states a maintainer must inspect during failure:
+generated code, runtime magic, plugins, hidden cache, async queues, network boundaries, vendor
+dashboards, local reproducibility, logs, traces, metrics, error codes, and request correlation.
+
+<!-- mustflow-section: hard-rejection-criteria -->
+## Hard Rejection Criteria
+
+Reject a candidate for `production_core` or `irreversible_core` when any condition is true:
+
+- No staged migration path exists.
+- The only migration path is a big-bang rewrite.
+- Rollback depends on luck, manual data surgery, unbounded downtime, or customer-visible data loss.
+- The candidate writes persistent data, events, files, auth state, money records, permission
+  records, cache keys, or public API contracts that the previous system cannot read or safely ignore.
+- The candidate is beta, experimental, preview-only, unstable, deprecated, or vendor-opaque for a
+  customer-facing or core surface.
+- Maintainer risk concentrates on one person, one abandoned project, one unfunded package, or one
+  vendor-controlled API without an adapter, fork, export, or replacement plan.
+- The ecosystem lacks current docs, migration guides, security response, basic integrations, or
+  searchable operational failure knowledge for the intended use.
+- Debugging crosses opaque generated code, hidden runtime state, async infrastructure, or remote
+  vendor behavior without local reproduction, logs, traces, metrics, request IDs, and an error
+  taxonomy.
+- The team cannot operate the technology and has no owner, training plan, runbook, or support plan.
+- License, pricing, data retention, region, privacy, compliance, or security constraints conflict
+  with the project.
+- The candidate solves taste, novelty, resume value, or aesthetic discomfort rather than a real
+  product, operational, security, performance, or maintenance bottleneck.
+- A local reversible problem would become a global architecture commitment.
+
+Do not average scores until hard rejection criteria have been applied.
+
+<!-- mustflow-section: scoring-rubric -->
+## Scoring Rubric
+
+Score each non-rejected candidate from 0 to 5:
+
+- `0`: no evidence, impossible, or actively unsafe.
+- `1`: theoretical, undocumented, or dependent on heroic manual work.
+- `2`: possible with high manual cost, fragile assumptions, or large downtime.
+- `3`: usable with known limits, documented mitigation, and acceptable blast radius.
+- `4`: documented, staged, testable, rehearsable, observable, and owned.
+- `5`: boring, standard, widely proven, easy to operate, easy to replace, and compatible with the
+  project.
+
+Required dimensions:
+
+- Migration path
+- Rollback path
+- Ecosystem maturity
+- Maintainer health
+- Debuggability
+- Operating surface and toil
+- Cost predictability
+- Data ownership and export
+- Security and privacy fit
+
+For `experiment` or `internal_tool`, scores of 2 or 3 can be acceptable when the candidate is
+isolated, timeboxed, feature-flagged, and easy to remove.
+
+For `customer_facing`, require no hard rejection and at least 3 in migration, rollback, ecosystem,
+maintainer health, and debuggability.
+
+For `production_core`, require no hard rejection, at least 4 in migration, rollback, debuggability,
+operating surface, and data ownership, and at least 3 in ecosystem and maintainer health.
+
+For `irreversible_core`, require no hard rejection, at least 4 in every dimension, a named owner,
+and a rehearsed recovery path.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the decision contract: what is being chosen, what is not being chosen, baseline, boring
+   default, owner, time horizon, and affected survival paths.
+2. Classify criticality and reversibility. Raise the evidence bar for persistent data, public APIs,
+   auth, payment, permission, deployment, backup, restore, and customer workflows.
+3. Build the option set. Include the status quo and boring default. Compare no more than three
+   additional candidates unless the user asks for a broader survey.
+4. Build the evidence ledger. Separate facts, inferences, assumptions, and unknowns. Prefer current
+   primary evidence over social proof, benchmark marketing, generated advice, or repeated citations.
+5. Evaluate maintainer life. For solo or indie work, prefer the smallest operating surface: one
+   understandable app path, managed boring infrastructure, simple CI/CD, automatic backups,
+   observable failures, and cheap rollback. Treat maintainer time as a real cost.
+6. Place experimentation at the edge. New or experimental technology belongs in replaceable parts,
+   read-only paths, derived-data paths, internal tools, feature-flagged features, analytics, search,
+   recommendation, or AI differentiators that can fail without corrupting the source of truth.
+7. Assess migration path for each candidate: source, target, compatibility layer, data conversion,
+   dual-run or shadow mode, cutover, validation, owner, blast radius, and stop condition.
+8. Assess rollback path for each candidate: trigger, steps, data preservation, schema compatibility,
+   feature flag or routing control, backup and restore limits, customer impact, irreversible cutoff,
+   and rehearsal requirement.
+9. Assess ecosystem maturity and maintainer risk: docs, changelog, release cadence, security
+   response, issue and PR handling, governance, funding, license stability, support, and exit path.
+10. Assess debugging surface: local reproduction, logs, traces, metrics, request IDs, error codes,
+    generated code, runtime magic, caches, queues, network boundaries, vendor dashboards, and blind
+    spots.
+11. Assess cost and operating surface: fixed cost, variable cost, CI/CD cost, observability cost,
+    backup and restore cost, failure-spike cost, egress, retry storms, log volume, billing meters,
+    and monthly maintainer labor.
+12. Apply hard rejection criteria before scoring. Do not rescue a hard-failed candidate with
+    popularity, performance, developer experience, or future promises.
+13. Score remaining candidates with one sentence of evidence for each dimension. Avoid invented
+    weights unless the user provided a decision model.
+14. Attack the leading candidate. State the strongest reason not to choose it and the smallest
+    evidence that would reverse the recommendation.
+15. Choose exactly one decision state: `adopt`, `adopt_with_constraints`, `experiment_first`,
+    `defer`, `reject`, or `reject_until_evidence_exists`.
+16. Define the next action. For adoption, specify the smallest safe rollout, guardrails, migration,
+    rollback, observability, owner, verification, and stop condition. For experiment, specify the
+    question, timebox, success criteria, failure criteria, cleanup path, and decision-reversing
+    evidence.
+17. Hand off to implementation only after selecting the narrower implementation skill and carrying
+    forward accepted constraints, migration steps, rollback steps, observability, and verification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The recommendation is based on survivability, reversibility, debugging, operating cost, and team
+  capacity, not novelty.
+- Survival-path choices prefer boring proven technology unless the candidate proves a stronger
+  recovery and operating story.
+- Experimental technology is isolated from source-of-truth data, money, permissions, and deployment
+  unless the project explicitly accepts the risk and can roll back.
+- Hard rejection criteria are applied before any score comparison.
+- Migration, rollback, observability, owner, and stop conditions are explicit.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_related`
+- `test_release`
+- `mustflow_check`
+
+Use `docs_validate_fast` when a decision record, architecture note, skill, template, or mustflow doc
+changes. Use `test_related` or `test_release` when installed template behavior, package output, or
+tests change. Use `mustflow_check` when mustflow-owned skills, routes, indexes, templates, or command
+contracts change.
+
+Report missing benchmark, migration, deployment, restore, cloud, vendor, pricing, or observability
+verification instead of inventing raw commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the user provides only a favorite technology and no baseline, compare it with the status quo
+  and a boring default.
+- If evidence is missing for a production-core decision, return `reject_until_evidence_exists` or
+  `experiment_first`, not `adopt`.
+- If rollback is weak, constrain the candidate to experiment, edge usage, or non-core usage.
+- If a mature candidate creates a large debugging surface, require observability and local
+  reproduction before adoption.
+- If maintainer risk is concentrated, require an adapter, fork plan, vendor alternative, or deferral.
+- If cost cannot be estimated across normal, success, and failure-spike scenarios, mark cost
+  predictability as unresolved.
+- If every option fails hard constraints, return `defer`, `reject`, or
+  `reject_until_evidence_exists` and name what would need to change.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Skill selection and overlap decision
+- Decision state: `adopt`, `adopt_with_constraints`, `experiment_first`, `defer`, `reject`, or
+  `reject_until_evidence_exists`
+- Decision scope, baseline, boring default, criticality, reversibility class, owner, and time horizon
+- Candidate matrix with hard-gate result, scores, evidence, mitigations, and verdict
+- Survival-path impact and experimental-edge placement
+- Migration path
+- Rollback path
+- Debugging surface
+- Cost and operating-surface notes
+- Hard rejections and exact criteria
+- Guardrails, owner, runbook, observability, security, privacy, and data-export requirements
+- Experiment plan when the decision is `experiment_first`
+- Command intents run
+- Skipped verification and reasons
+- Remaining risk and decision-reversing evidence