mustflow 2.27.0 → 2.29.0

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

@@ -0,0 +1,133 @@
+---
+mustflow_doc: skill.public-json-contract-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: public-json-contract-change
+description: Apply this skill when public machine-readable JSON, JSONL, schema-backed reports, stdout/stderr machine output, exit-code semantics tied to JSON output, compatibility fixtures, or documented automation-facing JSON contracts are created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.public-json-contract-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Public JSON Contract Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Protect automation consumers from silent JSON, JSONL, stream, schema, fixture, and exit-code drift.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A command, report, exported file, package artifact, template, fixture, or documented example exposes JSON or JSONL to scripts, tests, schemas, dashboards, release checks, or other non-human consumers.
+- A change adds, removes, renames, retypes, reclassifies, or documents a JSON field, JSONL packet, status value, schema version, path field, timestamp field, error shape, or compatibility fixture.
+- A command's `--json`, `--jsonl`, `--format json`, schema-backed report, stdout/stderr split, or exit-code behavior changes.
+- A compatibility claim depends on old fixtures, schema validation, package inclusion, or examples that users may parse.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The JSON is private in-process data with no public CLI, package, schema, fixture, template, documentation, or test contract.
+- The task changes only human-readable CLI text, color, help wording, warnings, or deprecations; use `cli-output-contract-review`.
+- The JSON is an HTTP, OpenAPI, GraphQL, RPC, or SDK request/response contract; use `api-contract-change`.
+- The task is only a broad template or docs alignment check with no JSON contract; use `contract-sync-check` or a narrower template skill.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Affected command, report, package artifact, fixture, or file path.
+- Output modes: human text, JSON, JSONL, stdout, stderr, redirected or piped behavior, and terminal-only formatting.
+- Exit-code expectations for success, partial success, validation failure, blocked, skipped, deprecated, and internal-error states.
+- Current schema files, schema ids, schema versions, status enums, JSONL packet types, docs examples, package inclusion lists, tests, and old compatibility fixtures.
+- Producer code, downstream parser or validator code when present, and known automation consumers.
+- Compatibility policy or release expectation, including whether a break requires a version bump, deprecation period, or explicit migration note.
+- Relevant command-intent entries for related tests, docs validation, 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.
+- Existing JSON tests, schemas, docs examples, package fixtures, and compatibility fixtures have been inspected before changing the contract.
+- Command execution remains governed by `.mustflow/config/commands.toml`; this skill does not authorize raw commands.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update JSON producer code, schema files, fixtures, package inclusion metadata, docs examples, tests, and templates that describe the same public contract.
+- Add optional fields, compatibility aliases, deprecation metadata, or explicit schema-version notes when they preserve consumers.
+- Do not silently remove, rename, retype, require, reinterpret, or move public JSON fields.
+- Do not mix prose, colors, progress text, or terminal controls into JSON stdout or JSONL streams.
+- Do not route machine-readable results, diagnostics, and errors to streams inconsistently with the documented contract.
+- Do not treat a snapshot or golden file as sufficient proof for JSON compatibility without field, stream, exit-code, and schema assertions.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Identify every public machine-readable surface: command output mode, JSON object fields, JSONL packet types, stdout, stderr, exit code, schema file, fixture, package artifact, docs example, template copy, and compatibility fixture.
+2. Name the source of truth for the contract. Prefer explicit schemas and producer code for JSON shape, command code for exit status and streams, and package metadata for installed fixture availability.
+3. Map each contract surface to its consumer: human reader, script, parser, schema validator, release test, installed template, docs example, dashboard, or downstream repository.
+4. Classify the change as internal-only, additive-compatible, corrective-compatible, deprecating, compatibility-sensitive, or breaking.
+5. Treat these as compatibility-sensitive by default: required field addition, field removal, field rename, field type change, enum or status meaning change, constraint strengthening, object-to-array or array-to-object change, null versus missing-field change, timestamp format change, path normalization change, schema-version change, JSONL packet-type change, stream-routing change, and exit-code meaning change.
+6. Keep machine output pure. JSON stdout must contain parseable JSON only; JSONL must contain one structured JSON object per line; diagnostics, warnings, debug notes, and progress belong on stderr unless the contract says otherwise.
+7. Check JSONL finality. Streaming output should expose stable packet kinds and a final packet that carries completion status, timestamp semantics, and any partial, blocked, skipped, deprecated, or unverified state.
+8. Preserve exit-code meaning. A zero exit code should mean the command's public contract succeeded, not merely that a sub-step executed. Nonzero category changes are breaking unless the repository declares otherwise.
+9. Compare old and new fixtures when compatibility matters. If a `tests/fixtures/schema-backcompat/<version>/public-json-fixtures.json` style fixture exists, keep it parseable and update validation expectations without erasing historical shape.
+10. Use snapshot and golden-output files only as review aids. Add or preserve assertions for field presence, primitive types, enum values, null versus missing semantics, stream split, exit code, and schema validation where existing test structure supports it.
+11. Synchronize schemas, fixtures, examples, package file lists, docs, templates, and release notes when the contract changes. If a surface is intentionally stale or deferred, record why.
+12. Route version impact through the repository versioning policy when the change is breaking, deprecating, package-visible, or template-visible.
+13. Verify with the narrowest configured command intents that cover JSON contract, docs, package, and mustflow metadata changes.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Public JSON and JSONL contracts, schemas, fixtures, package metadata, docs examples, stream routing, and exit-code meanings agree.
+- Compatibility-sensitive changes are explicitly classified.
+- Any skipped backcompat, schema, stream, exit-code, package, docs, or template surface is named with risk.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `test_related`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use broader configured tests when the JSON producer is cross-cutting or no narrower related test covers schema, stream, fixture, and exit-code behavior.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If old fixtures fail, treat the failure as contract drift until the fixture is proven obsolete.
+- If no schema exists for public JSON, preserve existing tests and report the missing schema rather than inventing an unrequested schema system.
+- If only human-output snapshots cover JSON behavior, add focused coverage when the repository test policy supports it or report the missing proof.
+- If stdout and stderr are mixed in machine mode, fix stream routing before claiming automation compatibility.
+- If compatibility is intentionally broken, report affected consumers and version impact before finalizing.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Public JSON or JSONL contract changed
+- Source of truth used
+- Compatibility classification
+- Fields, packet types, status meanings, streams, and exit codes reviewed
+- Schemas, fixtures, docs, tests, packages, and templates synchronized
+- Backcompat fixture coverage checked or missing
+- Command intents run
+- Skipped checks and reasons
+- Remaining JSON contract risk

package/templates/default/locales/en/.mustflow/skills/restricted-handoff-resume/SKILL.md

@@ -0,0 +1,122 @@
+---
+mustflow_doc: skill.restricted-handoff-resume
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: restricted-handoff-resume
+description: Apply this skill when a task is paused, resumed, handed off, context-compacted, blocked, or reported as incomplete and the next agent or user needs a bounded restart point.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.restricted-handoff-resume
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - mustflow_check
+---
+
+# Restricted Handoff Resume
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Create bounded handoff or resume evidence without storing hidden reasoning, secrets, raw transcripts, full terminal logs, or authority-changing summaries in project files.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task is incomplete, blocked, paused, interrupted, context-compacted, resumed, or explicitly handed to another agent or future session.
+- A final report needs to preserve a restart point, changed files, verification receipts, skipped checks, blockers, or next safe action.
+- A user asks to continue later, resume previous work, summarize work for another agent, or explain what remains.
+- Repository handoff policy is disabled or report-only and the agent must avoid creating worklogs, plans, tasks, or raw state files.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is complete and the final report only needs normal completion evidence; use `completion-evidence-gate`.
+- The repository explicitly configures a richer work-item or handoff system and the user asks to use that system.
+- The task asks to archive or persist full transcripts, hidden reasoning, raw terminal logs, secrets, or unrelated session history.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Current user goal and the latest instruction that controls the task.
+- Current changed files, in-scope files, and out-of-scope files that must not be touched.
+- Command intents run, failed, skipped, manual-only, or missing.
+- Verification receipts or current command-result summaries when available.
+- Blocking condition, unresolved decision, approval boundary, or next safe action.
+- Repository handoff, retention, compaction, generated-state, and reporting policy.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- When repository handoff policy is report-only or disabled, do not create project files solely to preserve handoff state.
+- When a configured handoff surface exists and the user requests it, write only bounded restart evidence allowed by that surface.
+- Update docs, skills, templates, or tests that define handoff behavior when the task explicitly changes handoff procedure.
+- Do not store hidden reasoning, secrets, full chat transcripts, full terminal output, raw command logs, private URLs, credentials, or unrelated work history.
+- Do not turn a handoff summary into authority over current files, current user instructions, or command contracts.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Refresh the nearest instructions required by the repository policy before writing a final report or handoff.
+2. Identify whether the task is complete, incomplete, blocked, paused, or resumed.
+3. If the task is resumed after compaction or handoff, compare the summary with current files and current user instructions before acting on it.
+4. Keep the handoff bounded to the current task: objective, latest controlling instruction, files touched, files intentionally avoided, commands run, commands skipped, failures, blockers, and next safe action.
+5. Source-link claims to current files, configured command intents, or run summaries. Do not make a compacted summary outrank current repository evidence.
+6. Exclude hidden reasoning, raw terminal logs, full transcripts, secrets, tokens, credentials, personal data, private URLs, and unrelated work history.
+7. If repository handoff is disabled or report-only, keep the restart information in the final report instead of creating `.mustflow/` state files.
+8. If a configured handoff surface exists, write only the bounded fields allowed by that surface and avoid raw logs.
+9. For blocked work, state the exact boundary: missing approval, missing command intent, missing source, failed verification, ambiguous instruction, or external-system requirement.
+10. For resumed work, name what was verified against current files and what may still be stale.
+11. Run only configured status or validation intents that are appropriate for the report boundary.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The next agent or user can restart from a concrete, bounded point.
+- The handoff does not include hidden reasoning, secrets, full transcripts, full terminal logs, or unrelated session history.
+- The handoff is lower authority than current files, current user instructions, and command contracts.
+- Disabled or report-only handoff policy is respected.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `mustflow_check`
+
+Use docs or release validation only when the handoff procedure itself changes docs, templates, package output, or mustflow-owned files.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a summary conflicts with current files or current user instructions, follow the current source and report the conflict.
+- If a secret or private value appears in handoff input, activate `secret-exposure-response` and omit the value.
+- If the task needs a project handoff file but handoff is disabled or no configured surface exists, keep the handoff in the final report and state the missing surface.
+- If command receipts are missing, report that the command was not verified through mustflow instead of claiming it passed.
+- If the user asks for full raw logs or hidden reasoning, provide a bounded operational summary instead.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Task status: complete, incomplete, blocked, paused, or resumed
+- Latest controlling instruction
+- Files touched and files intentionally avoided
+- Commands run, failed, skipped, manual-only, or missing
+- Verification evidence and stale-summary checks
+- Next safe action or blocking boundary
+- Excluded sensitive or raw content categories
+- Remaining resume risk

package/templates/default/locales/en/.mustflow/skills/routes.toml

@@ -48,12 +48,36 @@ route_type = "authoring"
 priority = 80
 applies_to_reasons = ["mustflow_config_change", "mustflow_docs_change"]
 
+[routes."command-intent-mapping-gate"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 68
+applies_to_reasons = ["docs_change", "mustflow_docs_change", "mustflow_config_change", "package_metadata_change", "security_change", "release_risk", "unknown_change"]
+
 [routes."cli-output-contract-review"]
 category = "workflow_contracts"
 route_type = "adjunct"
 priority = 65
 applies_to_reasons = ["public_api_change", "behavior_change", "docs_change"]
 
+[routes."public-json-contract-change"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 82
+applies_to_reasons = ["public_api_change", "behavior_change", "docs_change", "test_change", "package_metadata_change", "release_risk"]
+
+[routes."completion-evidence-gate"]
+category = "workflow_contracts"
+route_type = "adjunct"
+priority = 85
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "public_api_change", "test_change", "docs_change", "mustflow_docs_change", "mustflow_config_change", "package_metadata_change", "release_risk"]
+
+[routes."restricted-handoff-resume"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 64
+applies_to_reasons = ["unknown_change", "docs_change", "mustflow_docs_change", "mustflow_config_change", "workflow_change"]
+
 [routes."facade-pattern"]
 category = "architecture_patterns"
 route_type = "primary"
@@ -114,6 +138,18 @@ route_type = "adjunct"
 priority = 42
 applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "public_api_change", "security_change", "privacy_change", "data_change", "migration_change", "package_metadata_change"]
 
+[routes."runtime-target-selection"]
+category = "general_code"
+route_type = "primary"
+priority = 78
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "migration_change", "package_metadata_change", "release_risk"]
+
+[routes."structure-first-engineering"]
+category = "general_code"
+route_type = "adjunct"
+priority = 76
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "data_change", "migration_change", "security_change", "performance_change"]
+
 [routes."cpp-code-change"]
 category = "general_code"
 route_type = "primary"
@@ -228,6 +264,12 @@ route_type = "adjunct"
 priority = 25
 applies_to_reasons = ["public_api_change", "package_metadata_change", "mustflow_config_change"]
 
+[routes."template-install-surface-sync"]
+category = "workflow_contracts"
+route_type = "primary"
+priority = 78
+applies_to_reasons = ["mustflow_docs_change", "mustflow_config_change", "package_metadata_change", "docs_change", "test_change", "release_risk"]
+
 [routes."date-number-audit"]
 category = "workflow_contracts"
 route_type = "adjunct"
@@ -336,6 +378,18 @@ route_type = "primary"
 priority = 30
 applies_to_reasons = ["security_change", "privacy_change"]
 
+[routes."secret-exposure-response"]
+category = "security_privacy"
+route_type = "event"
+priority = 90
+applies_to_reasons = ["security_change", "privacy_change", "docs_change", "package_metadata_change", "release_risk"]
+
+[routes."provenance-license-gate"]
+category = "security_privacy"
+route_type = "adjunct"
+priority = 58
+applies_to_reasons = ["security_change", "docs_change", "code_change", "package_metadata_change", "release_risk"]
+
 [routes."config-env-change"]
 category = "security_privacy"
 route_type = "primary"
@@ -360,6 +414,12 @@ route_type = "event"
 priority = 20
 applies_to_reasons = ["command_failure"]
 
+[routes."evidence-stall-breaker"]
+category = "bug_failure"
+route_type = "event"
+priority = 70
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "docs_change", "mustflow_docs_change"]
+
 [routes."external-prompt-injection-defense"]
 category = "security_privacy"
 route_type = "adjunct"

package/templates/default/locales/en/.mustflow/skills/runtime-target-selection/SKILL.md

@@ -0,0 +1,203 @@
+---
+mustflow_doc: skill.runtime-target-selection
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: runtime-target-selection
+description: Apply this skill when choosing, migrating, rewriting, or justifying a primary language, runtime, framework, compile target, or execution environment for a feature, service, backend, engine, CLI, desktop app, or large codebase slice.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.runtime-target-selection
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_related
+    - test_release
+    - mustflow_check
+---
+
+# Runtime Target Selection
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose or review a language and runtime target from repository evidence, feedback-loop cost,
+deployment constraints, verification needs, ecosystem maturity, and operational ownership.
+
+This skill prevents "rewrite it in the language the agent likes" decisions. Strong compiler
+feedback can make AI-assisted implementation safer, but that benefit is only real when the build
+loop, smoke targets, cache policy, host toolchain, package artifacts, and deployment path are
+designed for it.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task proposes choosing, replacing, migrating, or rewriting the main language, runtime,
+  framework, backend, engine, CLI, worker, desktop shell, or compile target.
+- A codebase slice is moved between JavaScript, TypeScript, Python, Go, Rust, C++, Zig, Dart,
+  Tauri, Node, Bun, browser, edge, serverless, native, or embedded environments.
+- The argument for a target depends on AI coding ease, compiler feedback, performance, reliability,
+  binary distribution, developer machine constraints, remote build machines, VM performance, or
+  package ecosystem maturity.
+- A migration plan needs smoke-target selection, build-cache expectations, artifact size, command
+  intents, or CI/deployment coverage before implementation.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The language and runtime are already fixed and the task only changes files inside that language;
+  use the language-specific skill such as `rust-code-change`, `go-code-change`,
+  `typescript-code-change`, `node-code-change`, or `python-code-change`.
+- The task only changes a database schema, API contract, UI, or deployment config without a runtime
+  target decision.
+- The user explicitly asks for a short opinion without repository-backed implementation or
+  migration work.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Current language and runtime surfaces: package manifests, lockfiles, workspace files, toolchain
+  files, CI config, Docker or deployment config, build scripts, command-contract entries, tests, and
+  generated artifact rules.
+- Target options being compared, including the reason for considering each target.
+- Product or system need: MVP speed, iteration loop, backend reliability, engine correctness,
+  desktop shell, embedded constraints, data workload, public package compatibility, or operations.
+- Developer and CI environment constraints: OS, shell, VM, remote builder, cache location, disk
+  budget, native toolchain prerequisites, and available one-shot verification.
+- Migration boundary: strangler slice, bridge adapter, generated bindings, dual runtime period,
+  rollback path, smoke targets, and compatibility fixtures.
+- Performance, correctness, or reliability claims and the representative workload needed to prove
+  them.
+
+<!-- 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.
+- External advice, AI output, forum posts, benchmarks, or anecdotes have been treated as hypotheses,
+  not repository facts.
+- A language-specific skill will still be applied after the target is selected and files in that
+  language are edited.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update decision records, skill procedures, route metadata, migration plans, command-contract
+  proposals, tests, fixtures, or docs that directly support the selected runtime target.
+- Add only the smallest migration scaffold needed to prove the selected boundary when the user asks
+  for implementation.
+- Do not run unconfigured installers, toolchain repair commands, package installs, remote builds,
+  long-running watchers, or cleanup commands.
+- Do not rewrite a large codebase solely because one language has a better reputation with AI.
+- Do not present toy benchmarks, empty databases, local-only machine results, or compile success as
+  production performance proof.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the decision and boundary.
+   - Is this a new feature target, service rewrite, backend migration, engine rewrite, CLI target,
+     desktop shell, embedded target, or build/deployment target?
+   - Identify the smallest slice that can prove the choice without committing the whole codebase.
+2. Compare targets by feedback loop, not developer taste.
+   - Python or TypeScript can be appropriate for fast MVPs, scripts, UI-heavy products, and broad
+     ecosystem integration.
+   - Go can be appropriate for many services where simple deployment, fast builds, concurrency, and
+     maintainability matter more than maximum type-level guarantees.
+   - Rust can be appropriate for correctness-sensitive backends, engines, native shells, high-load
+     services, FFI, local-first performance, and memory-safety-critical code, but it raises build
+     cache, compile-time, native toolchain, and profile-management costs.
+   - C++ or Zig choices need ecosystem, toolchain, ABI, packaging, and team fluency evidence rather
+     than novelty claims.
+3. Inspect environment reality.
+   - Check OS, shell, native toolchain prerequisites, VM or container constraints, CI images,
+     remote builders, deployment runtime, and package artifact expectations.
+   - On Windows native Rust or C++ targets, distinguish ordinary shells from developer toolchain
+     shells when MSVC or SDK environment variables are required.
+4. Model the build loop.
+   - Estimate whether the normal edit-check-test loop is seconds, minutes, or hours for the
+     changed slice.
+   - Identify build-cache directories, target or artifact growth, and whether cleanup is a manual
+     maintenance action rather than a routine fix during active development.
+   - Treat expensive settings such as full release optimization, fat LTO, whole-workspace builds,
+     sanitizer runs, and cross-compiles as release or focused verification unless the command
+     contract explicitly declares them as normal checks.
+5. Define smoke targets before migration.
+   - Choose a small set of representative smoke targets: CLI command, API route, worker path,
+     database operation, desktop shell action, FFI boundary, public package import, or engine
+     invariant.
+   - Keep smoke targets stable and bounded so an AI agent can verify progress without compiling or
+     testing the whole world every loop.
+   - Report missing smoke or install verification intents instead of inventing raw commands.
+6. Plan migration boundaries.
+   - Prefer strangler slices, adapters, compatibility fixtures, and dual-run comparison where a
+     large rewrite would otherwise hide regressions.
+   - Identify data formats, public APIs, package entries, generated bindings, config, logs,
+     metrics, and operational handoff surfaces that must stay compatible.
+7. Calibrate performance and correctness claims.
+   - Compiler success proves type and build constraints, not product correctness.
+   - Microbenchmarks, empty databases, local-only measurements, and warm-cache runs are not enough
+     for production claims.
+   - Require representative workload, cold/warm distinction, data size, concurrency, target
+     hardware, build profile, and measurement method before reporting speed superiority.
+8. Select the target or report the blocked decision.
+   - Pick the target only when the runtime fit, feedback loop, verification, deployment, and
+     migration boundary are known enough.
+   - If one of those is missing, report the missing evidence and the safest reversible next slice.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Runtime choice is tied to the project boundary, not generic language preference.
+- Build-loop cost, cache and artifact impact, smoke targets, and verification coverage are explicit.
+- Migration boundary, rollback or compatibility strategy, and unverified claims are named.
+- Language-specific follow-up skills are selected before code in that language changes.
+
+<!-- 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 language-specific configured intents after files in a selected language change. Report missing
+smoke, install, package, cross-target, native toolchain, benchmark, or deployment verification
+instead of inventing raw commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the target decision rests on external anecdotes, treat them as hypotheses and require current
+  repository evidence before editing broad surfaces.
+- If the build loop is too expensive for normal agent iteration, reduce the migration slice, add a
+  configured smoke intent proposal, or report the missing command contract.
+- If native toolchain setup is missing, report the prerequisite instead of running global repair or
+  installer commands.
+- If a performance claim cannot be measured on a representative workload, remove or qualify the
+  claim.
+- If a language-specific skill exposes a stronger risk after selection, follow the narrower skill
+  and revisit the target decision if necessary.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Decision boundary
+- Candidate targets and chosen target
+- Environment and build-loop evidence
+- Smoke targets and verification coverage
+- Migration boundary and compatibility surfaces
+- Performance or correctness claims accepted, downgraded, or deferred
+- Command intents run
+- Skipped checks and reasons
+- Remaining runtime-target risk