mustflow 2.85.4 → 2.99.0

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

@@ -78,6 +78,12 @@ 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."next-action-menu"]
+category = "workflow_contracts"
+route_type = "adjunct"
+priority = 72
+applies_to_reasons = ["unknown_change", "docs_change", "workflow_change", "mustflow_docs_change", "package_metadata_change"]
+
 [routes."proactive-risk-surfacing"]
 category = "workflow_contracts"
 route_type = "event"
@@ -234,6 +240,30 @@ route_type = "adjunct"
 priority = 73
 applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "public_api_change", "performance_change", "security_change", "privacy_change", "data_change", "docs_change"]
 
+[routes."api-failure-triage"]
+category = "bug_failure"
+route_type = "primary"
+priority = 72
+applies_to_reasons = ["unknown_change", "command_failure", "behavior_change", "public_api_change", "performance_change", "data_change", "docs_change"]
+
+[routes."auth-flow-triage"]
+category = "bug_failure"
+route_type = "primary"
+priority = 74
+applies_to_reasons = ["unknown_change", "command_failure", "behavior_change", "security_change", "privacy_change", "data_change", "docs_change"]
+
+[routes."docker-runtime-triage"]
+category = "bug_failure"
+route_type = "primary"
+priority = 73
+applies_to_reasons = ["unknown_change", "command_failure", "behavior_change", "performance_change", "data_change", "docs_change"]
+
+[routes."ci-pipeline-triage"]
+category = "bug_failure"
+route_type = "primary"
+priority = 75
+applies_to_reasons = ["unknown_change", "command_failure", "workflow_change", "mustflow_config_change", "docs_change", "test_change", "package_metadata_change", "release_risk", "performance_change", "security_change"]
+
 [routes."app-startup-performance-review"]
 category = "general_code"
 route_type = "adjunct"
@@ -522,6 +552,12 @@ route_type = "primary"
 priority = 67
 applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "docs_change", "public_api_change", "data_change", "security_change", "privacy_change", "package_metadata_change", "release_risk"]
 
+[routes."rag-pipeline-triage"]
+category = "general_code"
+route_type = "primary"
+priority = 72
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "docs_change", "public_api_change", "data_change", "performance_change", "security_change", "privacy_change", "package_metadata_change", "release_risk"]
+
 [routes."llm-token-cost-control-review"]
 category = "general_code"
 route_type = "primary"
@@ -618,6 +654,18 @@ route_type = "primary"
 priority = 86
 applies_to_reasons = ["code_change", "data_change", "migration_change", "behavior_change", "public_api_change", "test_change", "docs_change", "security_change", "performance_change"]
 
+[routes."search-index-integrity-review"]
+category = "data_external"
+route_type = "primary"
+priority = 74
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "public_api_change", "performance_change", "data_change", "docs_change", "package_metadata_change", "release_risk"]
+
+[routes."vector-search-integrity-review"]
+category = "data_external"
+route_type = "primary"
+priority = 73
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "public_api_change", "performance_change", "data_change", "docs_change", "package_metadata_change", "release_risk"]
+
 [routes."dependency-upgrade-review"]
 category = "data_external"
 route_type = "primary"
@@ -834,6 +882,12 @@ route_type = "adjunct"
 priority = 81
 applies_to_reasons = ["ui_change", "performance_change", "behavior_change", "code_change", "web_asset_change"]
 
+[routes."motion-system-contract-review"]
+category = "ui_assets"
+route_type = "adjunct"
+priority = 83
+applies_to_reasons = ["ui_change", "behavior_change", "code_change", "performance_change", "test_change", "docs_change", "web_asset_change"]
+
 [routes."frontend-state-ownership-review"]
 category = "ui_assets"
 route_type = "adjunct"

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: 5
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: rust-code-change
@@ -101,9 +101,14 @@ instead of treated as incidental.
    - before using newer APIs, build an API-specific MSRV ledger instead of relying on a broad release bucket. Examples that need exact checking include `cfg_select!`, match `if let` guards, `core::range` items, `Vec::push_mut`, `assert_matches!`, and `debug_assert_matches!`;
    - do not use any newer API unless the declared MSRV, edition, CI matrix, docs.rs metadata, and toolchain path support that exact API;
    - keep experimental, nightly-only, target-specific, or edition-specific behavior behind explicit gates or fallbacks instead of calling it general Rust advice.
-5. Prefer flatter control flow when the MSRV supports it: use `let else` for early validation, let chains for related optional/result guards, and match `if let` guards for state-machine refinements. Remember that guard patterns do not satisfy match exhaustiveness; keep the fallback arm meaningful.
-6. In tests, prefer `assert_matches!` over `assert!(matches!(...))` when the MSRV supports it and the failed value has useful `Debug` output. Import it explicitly from `std` or `core`; do not assume it is in the prelude.
-7. 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. For Rust 2024 or edition migration work, review semantics instead of treating the edition as formatting:
+   - inspect `unsafe extern` blocks, unsafe attributes such as exported symbols or custom sections, `unsafe_op_in_unsafe_fn`, and public unsafe docs together;
+   - check `if let` scrutinee temporaries and tail-expression temporaries around locks, `RefCell`, guards, files, network handles, and other `Drop` values;
+   - review macro fragment specifiers, especially expression fragments whose accepted syntax changes by edition, and use older-edition fragments only when the macro intentionally rejects newer forms;
+   - treat automatic edition rewrites as candidate diffs that still need human review of unsafe, macro, pattern, temporary lifetime, docs, and examples.
+6. Prefer flatter control flow when the MSRV supports it: use `let else` for early validation, let chains for related optional/result guards, and match `if let` guards for state-machine refinements. Remember that guard patterns do not satisfy match exhaustiveness; keep the fallback arm meaningful.
+7. In tests, prefer `assert_matches!` over `assert!(matches!(...))` when the MSRV supports it and the failed value has useful `Debug` output. Import it explicitly from `std` or `core`; do not assume it is in the prelude.
+8. 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.
 8. 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`.
 9. Before adding `Arc<Mutex<_>>`, verify multiple owners truly need shared mutable state. For read-mostly snapshots, prefer ownership-preserving choices such as `Arc::make_mut`, immutable swaps, or explicit reload boundaries. Keep critical sections short, document lock order when relevant, and do not hold a lock guard across `.await`, I/O, callbacks, or user code.
 10. Choose initialization primitives by input and failure semantics: use `LazyLock` for no-argument static lazy values that may poison permanently on panic, and `OnceLock` when boot-time or test-time code supplies the value or panic poisoning must not become the recovery policy.
@@ -135,6 +140,7 @@ Reject or revise the patch when any of these appear without strong local justifi
 - New large `clone()` calls, clone-then-borrow code, loop clones, or state clones used only to appease ownership errors.
 - New `Arc<Mutex<AppState>>`-style shared bags, locks held across `.await`, or async I/O resources shared mainly by mutex.
 - New version-gated Rust API usage without API-specific MSRV, `rust-version`, edition, toolchain, CI, or fallback evidence.
+- Rust 2024 edition changes accepted without reviewing unsafe extern blocks, unsafe attributes, `unsafe_op_in_unsafe_fn`, temporary drop scopes, and macro fragment behavior where those surfaces exist.
 - New `LazyLock` initialization for recoverable runtime configuration where permanent panic poisoning would be the wrong failure policy.
 - New `spare_capacity_mut` plus `set_len` without a narrow, proven initialization invariant.
 - New public `impl Trait`, `Deref`, GAT, workspace resolver, feature, or `rust-version` change without public API and compatibility review.

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

@@ -0,0 +1,181 @@
+---
+mustflow_doc: skill.search-index-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: search-index-integrity-review
+description: Apply this skill when keyword search, full-text search, Elasticsearch, OpenSearch, Lucene-style indexes, search APIs, indexing pipelines, aliases, bulk indexing, refresh visibility, analyzers, mappings, synonyms, autocomplete, pagination, shard failures, search quality, or search performance are created, changed, reviewed, or failing. Use vector-search-integrity-review first for vector-only or semantic retrieval mechanics, and use rag-pipeline-triage first when a RAG failure is not yet localized to search retrieval.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.search-index-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Search Index Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review search as an end-to-end index and query contract, not as "the cluster is green."
+
+The core question is whether a source record can be changed, accepted by the indexing path, become visible through the same API users call, rank as expected, stay isolated by tenant and filters, and remain fast under realistic query shapes.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code creates or changes search ingestion, indexing jobs, bulk writes, index aliases, refresh policy, index templates, mappings, analyzers, keyword or text fields, synonyms, autocomplete, query builders, filters, sort, pagination, highlighting, source filtering, result shaping, search caches, or search observability.
+- Search is missing documents, returning stale data, returning partial results, ranking the wrong document, showing zero results, leaking tenant data, slowing down, timing out, rejecting writes, or behaving differently through direct search, backend API, and UI.
+- A review needs index visibility, read/write alias, bulk item errors, shard failure, mapping drift, analyzer, synonym, golden-set, p95 or p99 latency, slow-log, query fingerprint, shard fan-out, cache, refresh, segment merge, disk watermark, or search SLO evidence.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only vector, semantic, embedding, ANN, reranking, or vector hybrid mechanics; use `vector-search-integrity-review` first.
+- The task is an end-to-end RAG failure and it is not yet clear whether ingestion, retrieval, context assembly, prompt construction, generation, citation validation, or answerability failed; use `rag-pipeline-triage` first.
+- The task is only API transport, CORS, SDK, gateway, auth, or cache failure before the search boundary is known; use `api-failure-triage`.
+- The task is ordinary database query performance with no search index, analyzer, ranking, alias, or indexing path.
+- The requested evidence would require dumping private queries, customer documents, raw personal data, or production result pages into docs, tests, commits, or reports. Use safe IDs, hashes, synthetic fixtures, aggregate counts, or redacted examples.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Symptom classification: source not indexed, write not visible, wrong alias, partial shard result, wrong exact match, wrong full-text match, ranking drift, zero results, stale delete, tenant leak, autocomplete failure, deep-page failure, slow query, bulk rejection, mapping conflict, or UI/API mismatch.
+- Source-to-search ledger: source id, tenant, category, status, update time, indexing request time, bulk item result, indexed document id, direct lookup result, first search-visible time, rank, delete or tombstone state, and visibility lag.
+- Query contract ledger: user-facing API path, direct search request, API-transformed request, UI result shaping, index or alias, tenant and permission filters, analyzed fields, exact fields, sort, pagination mode, source fields, highlight fields, cache state, and expected result ids.
+- Index contract ledger: read alias, write alias, index templates, mappings, analyzers, normalizers, synonym sets, dynamic mapping policy, refresh policy, shard and replica plan, segment or merge state, disk watermark risk, and rollover or reindex status.
+- Quality ledger: representative queries, expected results, acceptable alternatives, zero-result expectations, Precision@K, Recall@K, MRR or ranking metric, before/after comparison, click or behavior metric limitations, and golden-set fixture status.
+- Performance ledger: cold and warm latency, p50, p95, p99, search server time, API time, UI time, query phase, fetch phase, response size, shard fan-out, thread-pool active/queue/rejected, slow-log or query-profile evidence, cache hit or miss, and retry behavior.
+- Privacy ledger: raw query text, document text, tenant ids, user ids, behavior analytics, search logs, highlights, and whether evidence can be stored safely as synthetic fixtures, ids, hashes, summaries, or aggregate metrics.
+
+<!-- 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.
+- Existing search adapters, query builders, index templates, mapping fixtures, golden sets, telemetry, and tests have been searched before changing search behavior.
+- Raw private document text, queries, user behavior, and tenant-identifying payloads are not copied into repository artifacts unless they are safe synthetic fixtures.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten search canaries, indexing ledgers, bulk item error handling, alias checks, mapping and analyzer fixtures, exact-versus-full-text tests, tenant and permission filter tests, golden-set tests, synonym regression tests, pagination guards, query fingerprint metrics, search latency metrics, docs, and directly synchronized templates.
+- Add focused synthetic fixtures that encode expected exact search, full-text search, analyzer behavior, synonym behavior, filtered search, tenant isolation, zero-result behavior, pagination stability, and ranking order.
+- Do not change analyzer, synonym, refresh, alias, shard, cache, or ranking settings blindly. First preserve source-to-search, query-contract, quality, and performance evidence.
+- Do not force every write to refresh immediately unless the product contract explicitly needs synchronous visibility and the indexing cost is accepted.
+- Do not treat search metrics as permission checks. Authorization and tenant filters must remain enforced outside and inside the search query path as the product requires.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the failure before tuning.
+   - Separate source missing, indexing rejected, write not visible, wrong alias, direct lookup mismatch, exact-search mismatch, full-text mismatch, ranking drift, partial shard result, API/UI transformation, stale cache, and slow query.
+   - If the symptom is only "cluster green but users cannot find it," require source-to-search evidence.
+2. Add or inspect a search canary when the system supports it.
+   - A unique canary document should pass through the same write path and user-facing search API as real data.
+   - Record accepted time, first visible time, rank, index or alias, tenant or filter context, and not-found evidence.
+3. Check bulk and ingestion outcomes per item.
+   - A batch-level success is insufficient. Inspect item-level errors, mapping conflicts, version conflicts, rejected writes, shard failures, retries, and failed ids.
+   - Preserve failed source ids or safe hashes so reindex and reconciliation can target real misses.
+4. Reconcile source and index by slices.
+   - Compare counts and checksums by tenant, date, category, status, or other ownership boundary.
+   - Total count equality can hide one tenant missing and another duplicated.
+5. Split direct lookup, exact search, and full-text search.
+   - Direct lookup success with search failure points toward refresh, alias, mapping, analyzer, filter, query, or API transformation.
+   - Exact keyword failure and full-text failure are different contracts.
+6. Check read and write aliases.
+   - Expand aliases to concrete indexes, write index, filters, routing, rollover state, and reindex targets.
+   - A new index receiving writes while search reads the old alias is an indexing visibility bug, not a ranking bug.
+7. Treat partial shard results as correctness evidence.
+   - Record `timed_out`, total shards, successful shards, failed shards, and partial-result policy.
+   - If partial results are not a valid product state, fail the request instead of silently returning incomplete search.
+8. Compare direct search, backend API, and UI output.
+   - Direct search isolates engine behavior.
+   - Backend API adds query builders, permission filters, caches, response shaping, and pagination.
+   - UI adds sorting, dedupe, local cache, page state, and display filtering.
+9. Inspect mappings and analyzers before changing queries.
+   - IDs, emails, status codes, tags, and exact filters usually need keyword-like fields.
+   - Human text usually needs text analysis. Use analyzer evidence or fixtures to prove tokenization for punctuation, case, hyphen, Korean spacing, product codes, and mixed alphanumeric text.
+10. Review synonym and ranking changes against a golden set.
+    - Synonyms can improve one query and break many others.
+    - Compare representative queries before and after; include zero-result, typo, ambiguous, category, brand, long natural-language, and high-value queries.
+11. Explain surprising ranks only for bounded cases.
+    - Inspect why one expected document ranked below another for a small failing sample.
+    - Do not enable expensive explain or profile behavior for broad production traffic.
+12. Separate query, fetch, API, and UI latency.
+    - p50, p95, and p99 must be grouped by search type, index, route, role, tenant class, and query fingerprint where safe.
+    - Fetch time, source size, highlight fields, nested fields, and response shaping can dominate score calculation.
+13. Fingerprint query shapes.
+    - Remove raw IDs, dates, user text, and tenant secrets before grouping.
+    - Store query family, index, role, shard count, cache state, source fields, sort, and filter shape so one feature cannot hide across millions of unique queries.
+14. Check shard fan-out, thread pools, segments, cache, and disk.
+    - Search across hundreds of tiny shards, stale segments, merge backlog, cold caches, search queue rejections, hot shards, and disk watermarks can look like application bugs.
+    - Separate cold and warm measurements; cached benchmarks are not full search evidence.
+15. Review refresh and visibility policy.
+    - Indexing success is not search visibility.
+    - Use synchronous visibility only for writes whose user contract needs it; otherwise define acceptable visibility lag and measure it.
+16. Review pagination and result payloads.
+    - Avoid deep offset pagination as a default product contract.
+    - Use stable tie-breakers for cursor-like pagination, and limit source fields and highlights to what the UI needs.
+17. Keep vector and hybrid boundaries explicit.
+    - If dense vectors, ANN, reranking, hybrid score fusion, or Recall@K drives the failure, switch to `vector-search-integrity-review` for that slice.
+    - If the bug is ordinary keyword indexing, alias, analyzer, source filtering, or shard partials, keep this skill as the primary route.
+18. Define numeric SLOs and destructive drills when in scope.
+    - Useful examples include indexing-to-search-visible p95, search p99, zero-result rate, partial shard failure rate, top-result duplication, golden-set metric, bulk item failure rate, and reindex reconciliation lag.
+    - Live node kills, disk pressure, alias mistakes, mapping conflicts, and mass reindex drills are manual unless the command contract declares them.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The search symptom, source-to-search ledger, query contract, index contract, quality ledger, performance ledger, and privacy boundary are explicit.
+- Bulk item errors, source/index reconciliation, direct lookup, exact search, full-text search, aliases, partial shards, API/UI transformation, mappings, analyzers, synonyms, ranking, pagination, source payload, shard fan-out, thread-pool pressure, cache state, refresh visibility, segments, disk, and SLO evidence are fixed or reported where relevant.
+- Search claims are backed by configured tests, fixtures, golden-set evidence, static review, safe canary evidence, or labeled manual-only or missing.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured tests that cover search contract, tenant isolation, filters, mappings, analyzer fixtures, golden-set metrics, docs, or template surfaces. Report missing live search cluster, slow-log, reindex, canary, load, or production-index evidence instead of inventing live diagnostics.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the query contract cannot be reconstructed, report the missing source, alias, filter, analyzer, ranking, or API transformation evidence before changing search settings.
+- If evidence contains raw private query text, document text, personal data, behavior analytics, or tenant-identifying data, redact to synthetic fixtures, ids, hashes, safe summaries, or aggregate metrics.
+- If the fix requires live index rebuild, production reindex, alias flip, cluster setting change, slow-log enablement, profile API on real traffic, or destructive drill outside the command contract, report the manual boundary.
+- If configured verification fails, preserve the failing intent and output tail, then fix only the localized search contract or test expectation.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Search index integrity reviewed
+- Symptom, source-to-search ledger, query contract, index contract, quality ledger, performance ledger, and privacy boundary
+- Bulk, reconciliation, lookup, exact/full-text, alias, shard, API/UI, mapping, analyzer, synonym, ranking, pagination, payload, shard fan-out, thread-pool, cache, refresh, segment, disk, and SLO findings
+- Fix applied or recommended
+- Evidence level: canary evidence, golden-set evidence, configured-test evidence, static review risk, manual-only, missing, or not applicable
+- Command intents run
+- Skipped search diagnostics and reasons
+- Remaining search-index risk

package/templates/default/locales/en/.mustflow/skills/service-boundary-architecture/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.service-boundary-architecture
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: service-boundary-architecture
-description: Apply this skill when service boundaries, modular-monolith boundaries, data ownership, queue/event boundaries, multi-tenant isolation, failure flow, operational recovery, or large-scale architecture split decisions are designed, reviewed, or changed.
+description: Apply this skill when service boundaries, modular-monolith boundaries, data ownership, queue/event boundaries, multi-tenant isolation, failure flow, independent deployment, operational recovery, disaster recovery, service split evidence, team ownership, cost, toil, or large-scale architecture split decisions are designed, reviewed, or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -39,6 +39,7 @@ This skill protects against the common failure mode where a system is split by n
 - A task designs, reviews, documents, or changes service boundaries, modular-monolith boundaries, bounded contexts, team ownership, API ownership, event ownership, queue ownership, or data ownership.
 - A monolith is being prepared for future split, a microservice split is proposed, or a service/module boundary is causing deploy, data, incident, or team coordination pain.
 - The task touches cross-service transactions, outbox/inbox patterns, idempotency, retries, timeouts, caches, read models, search models, shared databases, operational tools, manual correction, observability, tenancy, hot keys, or failure recovery.
+- A boundary claim needs proof from recent co-change history, independent deployability, dependency direction, database write ownership, synchronous call depth, queue backlog behavior, graceful shutdown, health probe correctness, version compatibility, restore or DR drills, least-privilege access, config blast radius, cost, toil, or team bottlenecks.
 - Architecture docs, decision records, onboarding docs, or skills need durable guidance for large-system design and operational readiness.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -57,6 +58,7 @@ This skill protects against the common failure mode where a system is split by n
 - Data ownership map: which module or service is the source of truth for each core fact, identifier, status, ledger, permission, tenant record, event, and read projection.
 - Current or proposed communication paths: direct calls, APIs, events, queues, shared databases, shared caches, batch jobs, search indexes, analytics stores, files, and admin tools.
 - Failure flows: duplicate requests, partial success, timeout, retry, consumer crash, queue backlog, dead-letter handling, external provider uncertainty, reconciliation, and manual correction.
+- Boundary proof ledger: last 3 months of PR co-change by repository, service, schema, deployment pipeline, and team; independent deploy test; dependency cycle map; table write ownership; synchronous call count; non-core dependency failure behavior; timeout and retry budget; queue oldest age; saturation curve; noisy-neighbor evidence; graceful shutdown; health probe split; old/new version compatibility; trace continuity; user-facing SLOs; local dev setup cost; ADR rationale; least-privilege access; config blast radius; restore and DR drill; cost per feature or customer; toil and approval bottlenecks.
 - Consistency expectations: strong consistency, eventual consistency, tolerated delay, stale reads, cache invalidation, read/write split, search delay, and deletion or retention rules.
 - Tenant, authorization, observability, deployment, migration, and operations requirements.
 - Configured verification intents and any existing architecture decision records or context files.
@@ -82,25 +84,32 @@ This skill protects against the common failure mode where a system is split by n
 
 1. Name the business capabilities and the facts each capability owns. For every core fact, identify exactly one source of truth and the owner responsible for correcting it.
 2. Split first by reason to change, not by noun. Keep code together when it changes together; split only when ownership, release cadence, scale, compliance, failure isolation, or team autonomy makes the boundary useful.
-3. Prefer a modular monolith with hard internal boundaries when the team is still discovering the domain. Draw future split lines early, but do not pay distributed-system costs before the boundary pressure is real.
-4. Reject shared database ownership. If another service or module needs data, choose an API, event, read projection, export, or explicitly owned query surface instead of direct table coupling.
-5. Design failure flows before the happy path. Cover partial success, duplicated requests, timeout, unknown external outcome, consumer crash, queue backlog, dead-letter handling, replay, reconciliation, and manual recovery.
-6. Require idempotency for commands that create, charge, reserve, approve, issue, grant, cancel, refund, redeem, or mutate durable state. Use stable request keys and return the previous result for duplicate keys.
-7. Treat queues as storage and backpressure, not magic. Define retry policy, exponential backoff or jitter, max attempts, retention, dead-letter ownership, consumer scaling, ordering expectations, replay safety, and loss tolerance.
-8. Every network call across the boundary needs a timeout, bounded retry policy, fallback or failure result, duplicate-safety story, and observability identifiers.
-9. Treat caches as a consistency tradeoff. Declare which stale values are acceptable, max staleness, invalidation owner, tenant and permission visibility, and whether the cache is allowed to become authority.
-10. Model authorization, tenant isolation, audit, and data visibility at the boundary. Tenant ID must travel through APIs, queues, caches, logs, files, reports, and admin tools when the system is multi-tenant.
-11. For event-driven boundaries, use past-tense fact events such as `OrderCreated` or `PaymentApproved`. Do not disguise commands as events. Include event ID, version, occurred time, publisher, subject, causation or request ID, correlation or trace ID, and compatible schema evolution rules.
-12. Separate transaction data from search, reporting, analytics, and screen-shaped read projections when their consistency, indexing, query, or retention needs diverge.
-13. Define tolerated delay with numbers. Replace vague "real-time" claims with accepted latency or freshness windows such as seconds, minutes, or batch cadence.
-14. Check hot keys and noisy neighbors. Define per-tenant, per-customer, per-room, per-campaign, or per-product limits, queue separation, worker pool separation, connection caps, and external API call caps when one key can dominate load.
-15. Keep domain rules in the owning domain layer. Do not scatter refund windows, cancellation rules, entitlement checks, inventory reservations, or admin overrides across controllers, UI, workers, and jobs.
-16. Plan migrations with expand, dual-write or compatibility, backfill, read switch, verification, and contract removal. Do not rename or remove shared fields in one deployment step.
-17. Plan deletion and retention before data is created. Identify legal retention, anonymization, log masking, backup retention, search/read-model cleanup, and audit exceptions.
-18. Make observability a product feature. Connect API, queue, worker, external provider, database, and admin operations with trace, request, correlation, causation, job, and tenant identifiers. Prefer p95, p99, error rate, queue age, backlog, dependency failure rate, and business success rate over averages.
-19. Make deployment and rollback a boundary decision. Use feature flags, canaries, partial exposure, compatibility windows, and kill switches for risky boundary changes.
-20. Provide operational tools for reality: reconcile external state, retry or quarantine failed messages, correct user/account/order state, revoke permissions, inspect provider responses, and undo manual changes with audit and approval when required.
-21. Record the decision: selected boundary, rejected alternatives, reason, assumptions, failure modes, data owner, operational owner, verification, and revisit triggers.
+3. Prove whether the proposed boundary is real.
+   - Mine recent PRs or change records when available: count repositories, services, DB schemas, deployment pipelines, and teams touched by one small requirement.
+   - Try the independent-deploy thought experiment: if one boundary cannot ship without another service version, shared library, DB migration, frontend deploy, or meeting, it is not independent yet.
+   - Draw dependency direction and cycles. Cycles usually mean the responsibility and data boundary is wrong, not merely that imports need cleaning.
+   - Count how many synchronous services and stores must succeed for one user action. If the answer is "many, or humans fix the database," the consistency boundary may be split in the wrong place.
+4. Prefer a modular monolith with hard internal boundaries when the team is still discovering the domain. Draw future split lines early, but do not pay distributed-system costs before the boundary pressure is real.
+5. Reject shared database ownership. If another service or module needs data, choose an API, event, read projection, export, or explicitly owned query surface instead of direct table coupling. Table write ownership should be explicit for every core fact.
+6. Design failure flows before the happy path. Cover partial success, duplicated requests, timeout, unknown external outcome, consumer crash, queue backlog, dead-letter handling, replay, reconciliation, and manual recovery.
+7. Require idempotency for commands that create, charge, reserve, approve, issue, grant, cancel, refund, redeem, or mutate durable state. Use stable request keys and return the previous result for duplicate keys.
+8. Treat queues as storage and backpressure, not magic. Define retry policy, exponential backoff or jitter, max attempts, retention, dead-letter ownership, consumer scaling, ordering expectations, replay safety, loss tolerance, oldest-message age, and catch-up rate.
+9. Every network call across the boundary needs a timeout, bounded retry policy, fallback or failure result, duplicate-safety story, observability identifiers, and a request-level budget so retries do not multiply across layers.
+10. Treat caches as a consistency tradeoff. Declare which stale values are acceptable, max staleness, invalidation owner, tenant and permission visibility, and whether the cache is allowed to become authority.
+11. Model authorization, tenant isolation, audit, and data visibility at the boundary. Tenant ID must travel through APIs, queues, caches, logs, files, reports, and admin tools when the system is multi-tenant. Service accounts should have only the DB, queue, storage, and API permissions the boundary needs.
+12. For event-driven boundaries, use past-tense fact events such as `OrderCreated` or `PaymentApproved`. Do not disguise commands as events. Include event ID, version, occurred time, publisher, subject, causation or request ID, correlation or trace ID, and compatible schema evolution rules.
+13. Separate transaction data from search, reporting, analytics, and screen-shaped read projections when their consistency, indexing, query, or retention needs diverge.
+14. Define tolerated delay with numbers. Replace vague "real-time" claims with accepted latency or freshness windows such as seconds, minutes, or batch cadence.
+15. Check hot keys and noisy neighbors. Define per-tenant, per-customer, per-room, per-campaign, or per-product limits, queue separation, worker pool separation, connection caps, and external API call caps when one key can dominate load.
+16. Check saturation and graceful degradation. Drive load past normal capacity in a bounded test plan when available, and identify the first bottleneck: worker pool, DB pool, locks, thread pool, queue, disk, external quota, or cache stampede.
+17. Keep domain rules in the owning domain layer. Do not scatter refund windows, cancellation rules, entitlement checks, inventory reservations, or admin overrides across controllers, UI, workers, and jobs.
+18. Plan migrations with expand, dual-write or compatibility, backfill, read switch, verification, and contract removal. Do not rename or remove shared fields in one deployment step. Old and new versions should tolerate unknown fields, missing fields, old messages, and new schema during rollout.
+19. Plan deletion and retention before data is created. Identify legal retention, anonymization, log masking, backup retention, search/read-model cleanup, and audit exceptions.
+20. Make observability a product feature. Connect API, queue, worker, external provider, database, and admin operations with trace, request, correlation, causation, job, and tenant identifiers. Prefer p95, p99, error rate, queue age, backlog, dependency failure rate, and business success rate over averages.
+21. Make deployment, rollback, shutdown, and health checks boundary decisions. Use feature flags, canaries, partial exposure, compatibility windows, kill switches, readiness/liveness/startup separation, graceful drain, and rollback-forward plans for risky boundary changes.
+22. Provide operational tools for reality: reconcile external state, retry or quarantine failed messages, correct user/account/order state, revoke permissions, inspect provider responses, and undo manual changes with audit and approval when required.
+23. Prove recovery, cost, and toil. A backup is not a boundary guarantee until it is restored in a clean environment. DR, config rollback, secret or certificate recovery, per-feature cost, repeated manual work, and single-team or single-person approval bottlenecks should be measured or reported.
+24. Record the decision: selected boundary, rejected alternatives, reason, assumptions, failure modes, data owner, operational owner, verification, cost, toil, and revisit triggers.
 
 <!-- mustflow-section: review-rejection-criteria -->
 ## Review Rejection Criteria
@@ -110,6 +119,9 @@ Reject or revise the design when:
 - A service or module boundary has no named data owner.
 - Two owners write the same core fact without a conflict rule.
 - A service reads another service's tables or cache as normal behavior.
+- A small requirement routinely changes many repositories, services, schemas, pipelines, or teams.
+- A service cannot be deployed, rolled back, or tested without synchronized changes in another boundary.
+- Dependency graphs contain cycles with no explicit ownership decision.
 - The design shows only the happy path.
 - Retries lack timeout, backoff, jitter, max attempts, idempotency, or failure ownership.
 - A queue has no dead-letter, retention, replay, ordering, or backlog policy.
@@ -117,6 +129,8 @@ Reject or revise the design when:
 - Events are imperative commands instead of past-tense facts.
 - Event schemas lack version, event ID, occurred time, publisher, and correlation or causation identifiers.
 - Tenant, permission, audit, or data-retention boundaries are added after the fact.
+- Health checks only prove process liveness, graceful shutdown is untested, or old and new versions cannot run together.
+- Backup, restore, DR, least privilege, config rollback, cost, or toil claims have no proof path.
 - Architecture choice is justified by tooling fashion instead of ownership, failure, scale, compliance, or team autonomy.
 - Manual operations can mutate critical state without audit, approval, and reversal or reconciliation path.
 
@@ -126,7 +140,7 @@ Reject or revise the design when:
 - Data ownership and source-of-truth boundaries are explicit.
 - Boundary split is justified by change reason, ownership, scale, compliance, failure isolation, or team autonomy.
 - Failure handling, idempotency, retry, queue, cache, event, and observability contracts are defined or explicitly deferred.
-- Tenant, authorization, deletion, retention, migration, deployment, and operational recovery risks are checked or reported.
+- Tenant, authorization, deletion, retention, migration, deployment, graceful shutdown, health checks, version compatibility, restore, DR, cost, toil, and operational recovery risks are checked or reported.
 - Decision records explain why this boundary was chosen, what alternatives were rejected, and when to revisit.
 
 <!-- mustflow-section: verification -->
@@ -160,7 +174,7 @@ Use broader configured checks when the boundary change affects templates, public
 - Boundary checked
 - Data owners and source-of-truth notes
 - Failure, idempotency, queue, cache, and event notes
-- Tenant, auth, retention, observability, deployment, and operations notes
+- Co-change, independent deploy, dependency, data ownership, sync-call, saturation, noisy-neighbor, tenant, auth, retention, observability, deployment, health, shutdown, version compatibility, restore, DR, cost, toil, and operations notes
 - Files changed
 - Command intents run
 - Skipped checks and reasons

package/templates/default/locales/en/.mustflow/skills/test-suite-performance-review/SKILL.md

@@ -121,6 +121,10 @@ resources are saturated, and what evidence keeps a faster path trustworthy?"
      shard tail, and idle-worker time.
    - Report p50 and p95 per test or file when available. Average-only timing hides the last slow
      shard, and the last slow shard decides CI wall time.
+   - When the command contract exposes `test_related_profile`, run it before policy changes that
+     depend on local verification timing. Then read the retained evidence with
+     `mf script-pack run test/performance-report summarize --json` before changing scheduling,
+     caching, timeout, worker, fixture, or selected-test behavior.
 2. Classify the bottleneck.
    - Discovery bottleneck: full tree scans, broad classpath scans, fixtures and generated files in
      search paths, or missing precomputed test manifests.
@@ -282,6 +286,11 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 test-suite behavior. If the repository exposes a profiling or cached-test intent, use it only when
 the command contract marks it configured, oneshot, and agent-allowed.
 
+When a profiling intent has run, prefer the read-only `test/performance-report` script-pack as the
+first report surface. Its `next_actions` field should guide whether the next safe step is collecting
+profile evidence, resolving previous failures, inspecting slow intents or phases, reviewing timeout
+pressure, or investigating selected-test fallback behavior.
+
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
 

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.typescript-code-change
 locale: en
 canonical: true
-revision: 5
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: typescript-code-change
@@ -95,18 +95,22 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 15. In TypeScript source that targets native Node ESM, write relative imports using the emitted runtime specifier, usually `.js`, such as `import { createApp } from "./app.js"` from `app.ts`. Do not write extensionless relative imports or `.ts` runtime specifiers unless a declared loader, bundler, or runtime explicitly owns that behavior.
 16. Use `moduleResolution: "Bundler"` only when a bundler such as Vite, esbuild, Rollup, or a framework build system owns final module resolution. Do not use bundler resolution to model code that Node will execute directly without that bundler.
 17. If ESM/CJS behavior changes, verify package `type`, `main`, `module`, `browser`, `exports`, condition order, extension rules, generated JS, and generated declaration files together.
-18. Inspect generated declarations when package surfaces change. Declaration files must not leak source-only aliases, private paths, workspace-only package names, unpublished internal paths, or accidental public re-exports.
-19. For TypeScript 6 migration work, treat deprecation warnings as future TypeScript 7 removal risk. `ignoreDeprecations` is a temporary compatibility valve, not proof that the project is ready for 7.0. Prefer removing deprecated options and updating resolver or module choices to match the project runtime.
-20. Treat TypeScript 6 `--stableTypeOrdering` as a migration comparison tool for declaration and error-order differences, not as a permanent performance-neutral default. If it changes errors or declaration output, look for inference or declaration-stability issues instead of snapshotting noise.
-21. For TypeScript 7 migration work, keep the tracks separate:
+18. For `tsconfig` updates, make defaults explicit when they affect emitted shape, ambient types, or module semantics. Check `rootDir`, `include`, `exclude`, `types`, `lib`, `target`, `module`, `moduleResolution`, `verbatimModuleSyntax`, `noUncheckedSideEffectImports`, declaration output, and framework wrapper defaults together instead of relying on a compiler-major default.
+19. Treat `types` as an ambient-global allowlist. Add only the runtime or test environment globals the project actually uses, such as Node, Bun, DOM, Vitest, Jest, or Playwright. Do not restore broad ambient discovery just to hide missing imports or environment drift.
+20. Use import attributes, subpath imports, and deferred module evaluation only when the runtime, bundler, and compiler track all support the exact syntax. `import defer` is a side-effect and startup-order choice, not a generic lazy-loading trick; use it only for namespace imports whose module evaluation can safely wait until first export access.
+21. Use `using` or `await using` only when the target runtime or transform path supports explicit resource management and the object really owns a disposable resource. Do not replace visible `try/finally`, context-manager, or framework cleanup contracts with `using` if the surrounding lifecycle, error propagation, or generated JS cannot be verified.
+22. Inspect generated declarations when package surfaces change. Declaration files must not leak source-only aliases, private paths, workspace-only package names, unpublished internal paths, or accidental public re-exports.
+23. For TypeScript 6 migration work, treat deprecation warnings as future TypeScript 7 removal risk. `ignoreDeprecations` is a temporary compatibility valve, not proof that the project is ready for 7.0. Prefer removing deprecated options and updating resolver or module choices to match the project runtime.
+24. Treat TypeScript 6 `--stableTypeOrdering` as a migration comparison tool for declaration and error-order differences, not as a permanent performance-neutral default. If it changes errors or declaration output, look for inference or declaration-stability issues instead of snapshotting noise.
+25. For TypeScript 7 migration work, keep the tracks separate:
    - TS6 stable API track: `@typescript/typescript6` and `tsc6` for compiler API, transformer, ESLint, framework wrapper, and peer-dependency compatibility.
    - TS7 RC compiler track: `typescript@rc` and `tsc` for RC compiler verification.
    - TS7 nightly track: `@typescript/native-preview` and `tsgo` for nightly diagnostics only.
    - Future TS7 stable track: stable `typescript` once upstream publishes TypeScript 7 on the normal stable path.
-22. Keep compiler API consumers, language-service plugins, custom transformers, and framework typecheck wrappers on the TS6 API track until their owners explicitly support the TS7 API surface. Treat TS7 RC `tsc` as compiler verification, not proof that JavaScript compiler API consumers can migrate.
-23. When comparing TS6 `tsc6`, TS7 RC `tsc`, and optional TS7 nightly `tsgo`, classify differences before editing code: real type error, declaration emit order or printback noise, unsupported option, unsupported API, watch or incremental behavior gap, language-service gap, generated-output drift, or framework wrapper mismatch.
-24. Do not treat faster TS7 RC or nightly results as sufficient verification. Keep the repository's existing `tsc`, `tsc6`, or framework typecheck as the compatibility baseline until repository policy explicitly adopts a different compiler track.
-25. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
+26. Keep compiler API consumers, language-service plugins, custom transformers, and framework typecheck wrappers on the TS6 API track until their owners explicitly support the TS7 API surface. Treat TS7 RC `tsc` as compiler verification, not proof that JavaScript compiler API consumers can migrate.
+27. When comparing TS6 `tsc6`, TS7 RC `tsc`, and optional TS7 nightly `tsgo`, classify differences before editing code: real type error, declaration emit order or printback noise, unsupported option, unsupported API, watch or incremental behavior gap, language-service gap, generated-output drift, or framework wrapper mismatch.
+28. Do not treat faster TS7 RC or nightly results as sufficient verification. Keep the repository's existing `tsc`, `tsc6`, or framework typecheck as the compatibility baseline until repository policy explicitly adopts a different compiler track.
+29. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
 
 <!-- mustflow-section: assertion-policy -->
 ## Assertion Policy
@@ -154,6 +158,7 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Validator schemas and exported types are duplicated without a single source of truth.
 - Generated declarations expose source-only aliases, internal module paths, workspace-only packages, or accidental barrel exports.
 - Package entry metadata changes without checking runtime entry, type entry, declaration output, and supported resolver modes.
+- `tsconfig` defaults, ambient `types`, import attributes, `import defer`, or explicit resource management syntax are adopted without runtime, bundler, compiler-track, and generated-output evidence.
 - `skipLibCheck` or weakened strictness is used as release validation for a library/package.
 - TypeScript 6-to-7 migration warnings are silenced instead of classified and either fixed or reported.
 - TS7 RC or nightly output differences are accepted as harmless without classification.