mustflow 2.28.0 → 2.29.0

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

package/templates/default/locales/en/.mustflow/skills/rust-code-change/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.rust-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: rust-code-change
@@ -30,6 +30,11 @@ metadata:
 
 Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and public crate boundaries while making a focused change. A Rust change is successful only when it clarifies ownership and contracts, not when it merely silences the borrow checker.
 
+Rust's compiler feedback can be especially useful for AI-assisted work because it rejects many
+invalid states with concrete errors. That benefit has a real cost: compile time, target-directory
+growth, native toolchain setup, release-profile slowness, and smoke-target selection must be managed
+instead of treated as incidental.
+
 <!-- mustflow-section: use-when -->
 ## Use When
 
@@ -45,10 +50,11 @@ Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and publi
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
 
-- `Cargo.toml`, workspace manifests, lockfile policy, toolchain config, rustfmt, clippy, feature flags, docs.rs metadata, optional dependencies, and CI hints.
+- `Cargo.toml`, workspace manifests, lockfile policy, toolchain config, rustfmt, clippy, feature flags, docs.rs metadata, optional dependencies, build profiles, target directory or cache policy, and CI hints.
 - Relevant `src/lib.rs`, `src/main.rs`, modules, public re-exports, tests, examples, and docs examples.
 - Existing error handling convention and async runtime.
 - Public crate status, minimum supported Rust version, feature support policy, and downstream compatibility expectations when available.
+- Host and build-loop constraints: OS, shell, native toolchain prerequisites, VM or remote-builder use, release profile, LTO, workspace size, disk budget, and configured smoke or focused-check intents.
 - Configured verification intents.
 
 <!-- mustflow-section: preconditions -->
@@ -57,6 +63,9 @@ Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and publi
 - Determine whether the change affects ownership flow, public API, feature gates, optional dependencies, error contract, async runtime, or unsafe invariants.
 - Read local patterns before adding traits, lifetimes, clones, locks, boxed errors, feature bounds, or `Send + Sync + 'static` constraints.
 - Treat `clone`, `Arc<Mutex<_>>`, explicit lifetimes, `'static`, `Box<dyn Error>`, `unwrap`, feature changes, and `unsafe` as suspicious until their contract impact is justified.
+- Identify the intended edit-check-test loop before choosing a broad build. Treat whole-workspace
+  checks, release builds, fat LTO, cross-compiles, and sanitizer-style runs as expensive evidence
+  unless the command contract declares them as the normal focused path.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -66,25 +75,38 @@ Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and publi
 - Keep feature-gated code and public re-exports synchronized.
 - Touch unsafe code only with explicit invariants preserved in nearby comments.
 - Add feature, async, or unsafe verification notes when configured command intents are missing.
+- Keep build cache cleanup, remote compilation, VM escape hatches, and native toolchain repair as
+  explicit environment or manual maintenance decisions. Do not hide them inside ordinary code fixes
+  or verification.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Read Cargo metadata, features, optional dependencies, docs.rs metadata, toolchain config, public exports, relevant modules, and tests.
+1. Read Cargo metadata, features, optional dependencies, docs.rs metadata, toolchain config, build profiles, public exports, relevant modules, and tests.
 2. Classify the change as ownership, API, error, feature, async, unsafe, dependency, or test-only.
-3. Resolve ownership problems in this order: identify the real owner, shrink borrow scopes, fix function signatures to accept references or slices when ownership is unnecessary, distinguish transfer from sharing, then consider clone or shared ownership only when the semantics require it.
-4. Before adding `clone`, verify it is a cheap handle clone such as `Arc`, `Rc`, or `Bytes`, a small intentional value clone, or a true independent ownership split. Reject large collection clones, loop clones, clone-then-borrow code, and whole-state clones made only to satisfy `spawn`.
-5. Before adding `Arc<Mutex<_>>`, verify multiple owners truly need shared mutable state. Keep critical sections short, document lock order when relevant, and do not hold a lock guard across `.await`, I/O, callbacks, or user code.
-6. Use explicit lifetimes only to describe real borrow relationships. Do not add `'static` or `T: 'static` to public APIs merely because an internal task boundary requires it.
-7. Use concrete error enums for library APIs when callers need to classify failures. Keep `Box<dyn Error>` mostly to binaries, examples, tests, prototypes, or explicitly opaque error policies.
-8. Avoid `unwrap` and vague `expect` in production paths. They are allowed only for tests, examples, startup policy, or invariants already proven by nearby code.
-9. If feature flags change, treat default features, no-default builds, all-features builds, optional dependency implicit features, public re-exports, docs examples, and feature-gated trait impls as compatibility surfaces. Features should be additive.
-10. Treat public re-exports, public dependency types, generic bounds, trait item sets, error enum variants, `#[non_exhaustive]`, and MSRV as public API. Tightened bounds, added required trait methods, removed re-exports, or changed error variants require compatibility review.
-11. Do not mix async runtimes. A Tokio crate should not casually gain `async-std` or runtime-specific APIs in library core. Do not call blocking I/O or CPU-heavy work in async paths without an established boundary such as async-native APIs, a blocking pool, or a dedicated worker.
-12. For async spawning, avoid leaking internal `Send + Sync + 'static` requirements into public APIs. Prefer owned task state, smaller spawn boundaries, local task structures, or caller-owned runtime decisions.
-13. Touch `unsafe` only when a safe design cannot express the required behavior. Every unsafe block needs a nearby `SAFETY:` explanation; every public `unsafe fn` needs `# Safety` docs. Keep unsafe scopes small and wrap them in safe abstractions only when callers have no hidden safety obligations.
-14. For FFI, keep Rust ABI types out of C boundaries. Use explicit ownership, `#[repr(C)]` where required, raw pointer plus length pairs, `CStr`/`CString`, RAII wrappers, null handling, panic boundaries, and documented thread-safety evidence before manual `Send` or `Sync`.
-15. Choose configured verification intents that cover format, lint, build, tests, feature combinations, docs, public API, unsafe, and FFI risk when available.
+3. Model the build loop before broad edits:
+   - identify the smallest package, crate, feature set, smoke target, or test that covers the risk;
+   - check whether `target/` or an equivalent cache may grow enough to affect local disk budget;
+   - treat cleaning build caches as a manual maintenance tradeoff because it can turn later
+     compile checks into cold, expensive builds;
+   - on Windows native targets, distinguish ordinary shells from developer toolchain shells when
+     MSVC, SDK, linker, or environment setup is required;
+   - treat VM builds, remote builders, release profiles, fat LTO, and whole-workspace checks as
+     environment and verification choices that must be reported when they dominate iteration cost.
+4. Resolve ownership problems in this order: identify the real owner, shrink borrow scopes, fix function signatures to accept references or slices when ownership is unnecessary, distinguish transfer from sharing, then consider clone or shared ownership only when the semantics require it.
+5. Before adding `clone`, verify it is a cheap handle clone such as `Arc`, `Rc`, or `Bytes`, a small intentional value clone, or a true independent ownership split. Reject large collection clones, loop clones, clone-then-borrow code, and whole-state clones made only to satisfy `spawn`.
+6. Before adding `Arc<Mutex<_>>`, verify multiple owners truly need shared mutable state. Keep critical sections short, document lock order when relevant, and do not hold a lock guard across `.await`, I/O, callbacks, or user code.
+7. Use explicit lifetimes only to describe real borrow relationships. Do not add `'static` or `T: 'static` to public APIs merely because an internal task boundary requires it.
+8. Use concrete error enums for library APIs when callers need to classify failures. Keep `Box<dyn Error>` mostly to binaries, examples, tests, prototypes, or explicitly opaque error policies.
+9. Avoid `unwrap`, vague `expect`, and unbounded `panic!` in production paths. They are allowed only for tests, examples, startup policy, panic-boundary adapters, or invariants already proven by nearby code.
+10. If feature flags change, treat default features, no-default builds, all-features builds, optional dependency implicit features, public re-exports, docs examples, and feature-gated trait impls as compatibility surfaces. Features should be additive.
+11. Treat public re-exports, public dependency types, generic bounds, trait item sets, error enum variants, `#[non_exhaustive]`, and MSRV as public API. Tightened bounds, added required trait methods, removed re-exports, or changed error variants require compatibility review.
+12. Do not mix async runtimes. A Tokio crate should not casually gain `async-std` or runtime-specific APIs in library core. Do not call blocking I/O or CPU-heavy work in async paths without an established boundary such as async-native APIs, a blocking pool, or a dedicated worker.
+13. For async spawning, avoid leaking internal `Send + Sync + 'static` requirements into public APIs. Prefer owned task state, smaller spawn boundaries, local task structures, or caller-owned runtime decisions.
+14. Touch `unsafe` only when a safe design cannot express the required behavior. Every unsafe block needs a nearby `SAFETY:` explanation; every public `unsafe fn` needs `# Safety` docs. Keep unsafe scopes small and wrap them in safe abstractions only when callers have no hidden safety obligations.
+15. For FFI, keep Rust ABI types out of C boundaries. Use explicit ownership, `#[repr(C)]` where required, raw pointer plus length pairs, `CStr`/`CString`, RAII wrappers, null handling, panic boundaries, and documented thread-safety evidence before manual `Send` or `Sync`.
+16. Calibrate performance claims. Do not claim Rust made a system faster from compile success, empty-database timings, warm-cache microbenchmarks, local-only runs, or debug versus release confusion. Require representative data size, concurrency, target hardware, profile, and measurement method before reporting speed claims.
+17. Choose configured verification intents that cover format, lint, build, tests, feature combinations, docs, public API, unsafe, FFI, smoke targets, package artifact, and release-profile risk when available.
 
 <!-- mustflow-section: rejection-criteria -->
 ## Review Rejection Criteria
@@ -96,10 +118,13 @@ Reject or revise the patch when any of these appear without strong local justifi
 - New public `'static`, `Send`, or `Sync` bounds that exist only because an internal task was spawned.
 - New public `Box<dyn Error>` in a library where callers need typed failures.
 - New production `unwrap` or vague `expect` on I/O, parse, environment, network, FFI, lock, or user input paths.
+- New unbounded `panic!` paths, index assumptions, or unchecked slicing in production paths without a documented invariant or panic boundary.
 - Feature changes that remove APIs, change type meaning, rename features, expose internal optional dependency names, or fail default/no-default/all-features reasoning.
 - Public dependency types, re-exports, trait bounds, trait methods, or error enum variants changed without semver review.
 - Async runtime mixing, blocking I/O in async paths, or runtime ownership moved into a library core without a clear boundary.
 - Unsafe blocks without `SAFETY:` comments, unsafe functions without `# Safety`, undocumented manual `Send`/`Sync`, or FFI that exposes Rust layout types across C ABI.
+- Whole-workspace, release, or fat-LTO verification treated as the normal agent loop when a smaller configured smoke or related target should exist.
+- Performance superiority claims based on non-representative workloads, empty databases, local-only timings, or unspecified build profile.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -108,7 +133,9 @@ Reject or revise the patch when any of these appear without strong local justifi
 - Public API, features, optional dependencies, and error contracts are synchronized.
 - Async runtime ownership is preserved and blocking work is isolated.
 - Unsafe and FFI invariants are preserved or no unsafe code was touched.
-- Missing feature, semver, docs, unsafe, or FFI verification is reported.
+- Build-loop cost, target/cache impact, smoke-target coverage, and native toolchain prerequisites
+  are handled or reported.
+- Missing feature, semver, docs, unsafe, FFI, smoke, package, or performance verification is reported.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -122,16 +149,19 @@ Use configured oneshot command intents when available:
 - `docs_validate_fast`
 - `mustflow_check`
 
-Report whether configured feature-combination, documentation, semver, Miri, sanitizer, and downstream-style verification exists when those surfaces change.
+Report whether configured feature-combination, documentation, semver, Miri, sanitizer, smoke-target,
+package artifact, release-profile, and downstream-style verification exists when those surfaces change.
 
 When configured intents exist for these risks, prefer coverage equivalent to:
 
 - formatting and linting
 - workspace checks and tests
+- focused smoke targets for the changed crate, command, API route, or engine invariant
 - default, no-default, all-features, and relevant feature combinations
 - doctests and docs build for public crates
 - public API or semver compatibility checks for published crates
 - Miri or sanitizer-style checks for unsafe, raw pointer, FFI, or manual concurrency primitives
+- representative benchmark or load checks when performance claims are introduced
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -141,11 +171,18 @@ When configured intents exist for these risks, prefer coverage equivalent to:
 - If public API compatibility cannot be verified, report the exact exported symbols, trait bounds, feature gates, or errors at risk.
 - If async runtime or blocking boundaries are unclear, stop that part and inspect the runtime ownership before editing further.
 - If unsafe invariants are unclear, stop that part and request or inspect stronger evidence.
+- If the build loop is too expensive, reduce the verification scope to the configured related or
+  smoke intent when available, or report the missing command contract instead of running broad raw
+  builds.
+- If host toolchain setup is missing, report the prerequisite rather than running global installer,
+  repair, or shell-environment commands.
+- If performance claims lack representative evidence, downgrade or remove the claim.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
 
 - Boundary checked
+- Build-loop, cache, smoke target, and toolchain notes
 - Ownership, feature, async, or unsafe impact
 - Public API or error impact
 - Files changed

package/templates/default/locales/en/.mustflow/skills/secret-exposure-response/SKILL.md

@@ -0,0 +1,125 @@
+---
+mustflow_doc: skill.secret-exposure-response
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: secret-exposure-response
+description: Apply this skill when a real or plausible secret, token, credential, private key, session value, password, connection string, or sensitive key material appears in repository files, generated artifacts, logs, command output, screenshots, fixtures, docs, package output, or final reports.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.secret-exposure-response
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Secret Exposure Response
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Handle secret-looking exposure as an incident-style containment task instead of an ordinary security review or cosmetic redaction.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A real or plausible API key, token, private key, password, session cookie, OAuth credential, service-account value, connection string, signing secret, webhook secret, certificate key, recovery code, or production-like credential appears.
+- Secret-looking material appears in tracked files, untracked files, generated artifacts, logs, command output, screenshots, fixtures, docs, templates, package output, cache, run receipts, or final reports.
+- A task asks to remove, redact, report, package, publish, screenshot, paste, or summarize content that includes possible credential material.
+- A previous command or tool output exposed sensitive values and the next response or edit could copy them further.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only adds placeholder environment variable names or fake examples; use `config-env-change` for normal config work.
+- The task is a broad security review with no exposed or plausible credential value; use `security-privacy-review`.
+- The value is clearly non-secret test data and cannot be confused with a real credential after inspecting the surrounding context.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Exposure surface: file, generated artifact, command output, screenshot, docs, fixture, package output, cache, or final report.
+- Secret type if inferable without repeating the value.
+- Whether the surface is tracked, untracked, generated, public, packaged, ignored, local-only, or already shared outside the repository.
+- Scope of allowed remediation: redaction, deletion, placeholder replacement, docs rewrite, fixture rewrite, package-output cleanup, or report-only.
+- Whether rotation, revocation, history rewrite, provider dashboard action, or user action is required but outside the current command contract.
+- Relevant command-intent contract entries for status, diff, docs, package, release, or mustflow validation.
+
+<!-- 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
+
+- Remove, redact, or replace exposed values with safe placeholders in in-scope files.
+- Update docs, fixtures, templates, tests, examples, generated-package inputs, or final-report wording to avoid re-exposure.
+- Add local fake-value conventions only where they prevent recurrence and match repository style.
+- Do not print, quote, copy, commit, push, publish, or package the secret value.
+- Do not rotate, revoke, rewrite Git history, delete backups, or contact providers unless the user explicitly requests that action and the repository contract supports it.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Stop ordinary work long enough to contain copying. Do not repeat the secret value in messages, patches, logs, docs, or final reports.
+2. Classify the exposure surface without echoing the value: tracked file, untracked file, generated artifact, docs, fixture, package output, command output, screenshot, cache, run receipt, or final report.
+3. Determine whether the value is real, plausible, fake, or unknown from surrounding context without making a false safety claim.
+4. Remove or replace the value in in-scope repository files using a safe placeholder that cannot be mistaken for a real credential.
+5. Check nearby examples, docs, templates, fixtures, generated-package inputs, and final-report text for copied variants of the same value.
+6. If the value may have entered generated artifacts, package output, screenshots, run receipts, logs, or caches, report the affected surfaces and clean only those that are in scope and allowed.
+7. If the value may be real or already shared, report that rotation or revocation is required. Do not claim redaction alone fixes exposure.
+8. If the secret is tracked in Git history, report the history exposure and do not rewrite history unless explicitly requested.
+9. If the secret is outside the current repository or in a provider dashboard, stop at the boundary and describe the required owner action without revealing the value.
+10. Run the smallest configured verification that covers the changed docs, templates, package, or mustflow contract.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The secret value is not repeated in patches, docs, examples, package inputs, generated artifacts, or final reports.
+- In-scope repository surfaces no longer contain the exposed value.
+- Remaining rotation, revocation, history, package, cache, screenshot, or external-sharing risks are reported without revealing the value.
+- The final report distinguishes redaction from credential invalidation.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use a narrower configured test, build, package, or documentation intent when it better proves the changed exposure surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the value might be real, treat it as real for reporting and avoid echoing it.
+- If remediation requires deleting generated artifacts, rewriting Git history, rotating provider keys, or changing external systems, stop at the approval boundary and report the required owner action.
+- If command output includes the value, summarize only the affected surface and never paste the raw output.
+- If a fixture genuinely needs a secret-shaped value, replace it with an unmistakable fake and document that it is non-functional.
+- If verification would reprint the secret, skip that command and report the reason.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Exposure surfaces reviewed
+- Secret type classification without value
+- Redaction, omission, or placeholder changes made
+- Generated, package, docs, fixture, cache, log, screenshot, and final-report surfaces checked when relevant
+- Rotation, revocation, history, or external-owner actions still required
+- Command intents run
+- Skipped checks and reasons
+- Remaining exposure risk