mustflow 2.74.1 → 2.74.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustflow",
-  "version": "2.74.1",
+  "version": "2.74.3",
   "description": "Agent workflow documents and CLI for mustflow repository roots.",
   "type": "module",
   "license": "MIT-0",

package/templates/default/i18n.toml

@@ -62,7 +62,7 @@ translations = {}
 [documents."skills.index"]
 source = "locales/en/.mustflow/skills/INDEX.md"
 source_locale = "en"
-revision = 172
+revision = 174
 translations = {}
 
 [documents."skill.adapter-boundary"]
@@ -356,7 +356,7 @@ translations = {}
 [documents."skill.rate-limit-integrity-review"]
 source = "locales/en/.mustflow/skills/rate-limit-integrity-review/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.idempotency-integrity-review"]
@@ -469,13 +469,13 @@ translations = {}
 [documents."skill.dependency-upgrade-review"]
 source = "locales/en/.mustflow/skills/dependency-upgrade-review/SKILL.md"
 source_locale = "en"
-revision = 3
+revision = 4
 translations = {}
 
 [documents."skill.version-freshness-check"]
 source = "locales/en/.mustflow/skills/version-freshness-check/SKILL.md"
 source_locale = "en"
-revision = 6
+revision = 7
 translations = {}
 
 [documents."skill.line-ending-hygiene"]
@@ -517,7 +517,7 @@ translations = {}
 [documents."skill.astro-code-change"]
 source = "locales/en/.mustflow/skills/astro-code-change/SKILL.md"
 source_locale = "en"
-revision = 2
+revision = 3
 translations = {}
 
 [documents."skill.auth-permission-change"]
@@ -571,7 +571,7 @@ translations = {}
 [documents."skill.elysia-code-change"]
 source = "locales/en/.mustflow/skills/elysia-code-change/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.flutter-code-change"]
@@ -625,7 +625,7 @@ translations = {}
 [documents."skill.rust-code-change"]
 source = "locales/en/.mustflow/skills/rust-code-change/SKILL.md"
 source_locale = "en"
-revision = 4
+revision = 5
 translations = {}
 
 [documents."skill.runtime-target-selection"]
@@ -640,6 +640,12 @@ source_locale = "en"
 revision = 1
 translations = {}
 
+[documents."skill.support-surface-advisor"]
+source = "locales/en/.mustflow/skills/support-surface-advisor/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.svelte-code-change"]
 source = "locales/en/.mustflow/skills/svelte-code-change/SKILL.md"
 source_locale = "en"
@@ -649,7 +655,7 @@ translations = {}
 [documents."skill.tailwind-code-change"]
 source = "locales/en/.mustflow/skills/tailwind-code-change/SKILL.md"
 source_locale = "en"
-revision = 3
+revision = 4
 translations = {}
 
 [documents."skill.tauri-code-change"]
@@ -661,13 +667,13 @@ translations = {}
 [documents."skill.typescript-code-change"]
 source = "locales/en/.mustflow/skills/typescript-code-change/SKILL.md"
 source_locale = "en"
-revision = 3
+revision = 4
 translations = {}
 
 [documents."skill.unocss-code-change"]
 source = "locales/en/.mustflow/skills/unocss-code-change/SKILL.md"
 source_locale = "en"
-revision = 3
+revision = 4
 translations = {}
 
 [documents."skill.service-boundary-architecture"]
@@ -775,7 +781,7 @@ translations = {}
 [documents."skill.external-skill-intake"]
 source = "locales/en/.mustflow/skills/external-skill-intake/SKILL.md"
 source_locale = "en"
-revision = 2
+revision = 3
 translations = {}
 
 [documents."skill.github-contribution-quality-gate"]
@@ -930,13 +936,13 @@ translations = {}
 [documents."skill.skill-refresh"]
 source = "locales/en/.mustflow/skills/skill-refresh/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.skill-authoring"]
 source = "locales/en/.mustflow/skills/skill-authoring/SKILL.md"
 source_locale = "en"
-revision = 8
+revision = 9
 translations = {}
 
 [documents."skill.task-instruction-authoring"]

package/templates/default/locales/en/.mustflow/skills/INDEX.md

@@ -2,7 +2,7 @@
 mustflow_doc: skills.index
 locale: en
 canonical: true
-revision: 172
+revision: 174
 authority: router
 lifecycle: mustflow-owned
 ---
@@ -309,6 +309,10 @@ refer to `AGENTS.md` and `.mustflow/config/commands.toml` to implement the most
   rules, public contracts, external I/O, operational safety, failure handling, concurrency,
   data flow, or future change cost could be shaped by early structure decisions. Do not use it for
   surface-only changes or tiny local edits with no boundary pressure.
+- Use `support-surface-advisor` as a primary route before building a product, app, service, CLI,
+  API, SDK, library, desktop app, automation tool, or developer tool when the agent must decide
+  which user, developer, operator, automation, integration, recovery, upgrade, or observability
+  routes are supported now, deferred, or explicitly not supported.
 - Use `secret-exposure-response` as an event route when a real or plausible secret value appears;
   do not treat redaction as proof that rotation, revocation, or history exposure is handled.
 - Use `evidence-stall-breaker` as an event route when the same read, list, search, path, or review
@@ -407,6 +411,7 @@ routes. Event routes stay inactive until their event occurs.
 | Code review or implementation needs transaction-boundary integrity triage for transactions, ORM atomic blocks, unit-of-work code, database write paths, service workflows, command handlers, webhook processors, queue consumers, framework transaction annotations, isolation levels, lock usage, rollback behavior, after-commit side effects, outbox patterns, retry handling, or transactional tests that can break a business invariant even when a transaction exists | `.mustflow/skills/transaction-boundary-integrity-review/SKILL.md` | Business invariant, transaction boundary, decision ledger, durable guard evidence, framework behavior, side-effect ledger, failure and retry evidence, test evidence, and configured command intents | Whole read-decision-write transaction boundaries, durable constraints, atomic upsert or conditional update, affected-row checks, version checks, correct lock target, transaction narrowing, after-commit or outbox side effects, idempotent retry classification, focused tests, and directly synchronized docs or templates | app-only `exists()` or `count` guard, stale read-decision-write, absent-row `FOR UPDATE` gap, `SKIP LOCKED` consistency misuse, READ COMMITTED snapshot myth, REPEATABLE READ engine mismatch, SERIALIZABLE without full retry, deadlock or serialization failure treated as plain 500, swallowed rollback trigger, Spring `rollbackFor` miss, self-invocation bypass, `readOnly` write assumption, inner rollback-only surprise, `REQUIRES_NEW` pool pressure, `NESTED` savepoint confusion, Django nested `atomic()` durability myth, pre-commit email/cache/queue side effect, HTTP API inside transaction, Hibernate flush-as-commit confusion, SQLAlchemy implicit transaction surprise, missing optimistic lock, advisory lock scope leak, wrong transaction manager, or transactional test hiding commit behavior | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Transaction boundary reviewed, invariant and decision ledger, durable-guard/lock/isolation/retry/rollback/side-effect findings, evidence level, verification, and remaining transaction-boundary integrity risk |
 | Code review or implementation needs testability-boundary triage for hidden decision inputs, direct time or randomness, direct I/O, constructor side effects, static or singleton state, oversized private logic, branch policy sprawl, boolean mode flags, broad option objects, implicit environment or request context, void side effects, swallowed errors, log-only outcomes, cache order dependence, ORM lazy loading, transaction and external-call coupling, hidden event publication, fire-and-forget async work, real-time retry waits, nondeterministic collection order, hidden defaults, mixed validation and policy, scattered authorization, framework magic, smart controllers, conditional DTO mapping, mock-heavy classes, call-order assertions, inheritance coupling, or reflection-only tests | `.mustflow/skills/testability-boundary-review/SKILL.md` | User goal, current diff or target files, behavior or decision under test, decision-input ledger, side-effect ledger, observability ledger, test friction evidence, and configured command intents | Explicit inputs, fixed clocks or generators, dependency seams, pure decision cores, shell and adapter boundaries, policy or strategy tables, observable results, deterministic ordering, focused tests, and directly synchronized docs or templates | hidden time/random, constructor work, global state, fat private method, boolean mode flags, broad option object, void side effect, swallowed or log-only failure, cache order dependence, ORM lazy loading, transaction/external call coupling, hidden event publication, fire-and-forget sleeps, real-time retry wait, nondeterministic order, hidden defaults, mixed validation/policy, scattered auth, framework magic, smart controller, conditional DTO policy, five or more mocks, fragile call-order tests, deep inheritance, or reflection-only tests | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `test_audit`, `docs_validate_fast`, `test_release`, `mustflow_check` | Testability boundary reviewed, decision inputs and side effects exposed, observability fixed or recommended, test friction evidence, verification, and remaining testability risk |
 | A coding task has missing intent, scope, domain, data, security, UX, dependency, architecture, or verification decisions that cannot be safely inferred from repository evidence | `.mustflow/skills/clarifying-question-gate/SKILL.md` | User request, inspected repository evidence, unresolved decisions, reversibility classification, recommended option, and tradeoffs | Blocking questions, safe assumptions, and the smallest safe implementation boundary | over-questioning, lazy questions, expensive wrong assumptions, user-owned decision drift, data loss, auth bypass, public-contract drift, dependency bloat, or unverifiable completion | `changes_status`, `changes_diff_summary`, `mustflow_check` | Repository evidence inspected, blocking questions with recommendations, safe assumptions, selected scope, verification, and remaining ambiguity |
+| Product, app, service, CLI, API, SDK, library, desktop app, automation tool, or developer tool work needs a decision about which user, developer, operator, automation, integration, recovery, upgrade, documentation, or observability surfaces are supported now, deferred, explicitly unsupported, or internal-only | `.mustflow/skills/support-surface-advisor/SKILL.md` | Product stage, primary actors, main usage path, integration need, maintenance capacity, public-contract willingness, explicit non-goals, recovery and observability expectations, and current repository evidence | Support-surface plan, selected implementation boundaries, docs, tests, route metadata, core-engine boundary, and directly synchronized templates when installed | support-contract bloat, accidental public API, UI/CLI/API duplicate core logic, hidden integration promise, unsupported automation route, unowned recovery path, stale compatibility promise, or implementation explanation leaking into user-facing UI copy | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Product stage, actors, recommended surfaces, deferred and unsupported surfaces, blocking questions, maintenance and compatibility risks, core engine versus shell boundary, staged plan, verification, and remaining support-surface risk |
 | A task chooses, migrates, rewrites, or justifies a primary language, runtime, framework, compile target, or execution environment | `.mustflow/skills/runtime-target-selection/SKILL.md` | Current runtime surfaces, target options, product or system need, environment constraints, migration boundary, smoke targets, and performance or reliability claims | Decision records, skill procedures, route metadata, migration plans, command-contract proposals, tests, fixtures, docs, and smallest selected migration scaffold | language-preference rewrite, unsupported runtime target, unusable build loop, cache or artifact blowup, missing smoke target, deployment drift, or false performance claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_related`, `test_release`, `mustflow_check` | Decision boundary, candidate targets, environment and build-loop evidence, smoke targets, migration boundary, calibrated claims, verification, and remaining runtime-target risk |
 | Non-trivial code work needs early structure decisions around domain rules, public contracts, external I/O, operational safety, failure handling, concurrency, data flow, or future change cost | `.mustflow/skills/structure-first-engineering/SKILL.md` | User request, target files, project context, core boundary, data flow, expected failures, public contracts, I/O surfaces, and verification contract | Risk block, focused boundaries, DTOs, adapters, pure functions, error models, tests, and directly synchronized docs or contracts | under-designed hard boundary, speculative abstraction, vague service layer, mixed I/O and domain rules, hidden partial failure, or untestable behavior | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Work risk, structure decision, data flow, failure model, I/O and concurrency boundaries, tests, verification, and remaining structure risk |
 | HTTP, REST, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, request/response schema, status code, header, content negotiation, cache header, error envelope, pagination, filtering, sorting, search, generated client, SDK, mock, fixture, or API docs contract is created or changed | `.mustflow/skills/api-contract-change/SKILL.md` | API style, contract source of truth, changed operations, request and response schemas, status and headers, content negotiation, error envelope, auth and permission behavior, pagination/filter/sort/search semantics, generated clients, SDKs, mocks, fixtures, callers, docs, and command contract entries | Routes, handlers, resolvers, validators, schemas, generated clients, SDKs, mocks, fixtures, docs, tests, and directly synchronized examples | route-only change, schema drift, generated-client breakage, hidden breaking change, status or error drift, pagination/search semantic drift, auth/permission drift, cache/header drift, or stale docs examples | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | API contract source, changed operations, compatibility classification, synchronized client/schema/docs/tests surfaces, verification, and remaining API contract risk |
@@ -416,7 +421,7 @@ routes. Event routes stay inactive until their event occurs.
 | Node.js runtime code, package manager ownership, module format, package entry metadata, native dependencies, Node test runner behavior, TypeScript execution mode, or deployment runtime support is created or changed | `.mustflow/skills/node-code-change/SKILL.md` | Node version signals, package manager and lockfile owner, module/package metadata, TypeScript loader, test runner, native dependency, deployment target, and command contract entries | Node runtime code, package metadata, lockfiles, scripts, CI or Docker runtime declarations, test runner config, native dependency handling, docs examples, and directly synchronized package surfaces | newest-Node assumption, package manager drift, ESM/CJS break, blocked deep import, native dependency break, Node native TypeScript overclaim, test runner migration risk, deployment mismatch, or permission-model overclaim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Runtime and package manager decision, module/package entry notes, TypeScript/test runner notes, native/deployment risks, verification, and remaining Node.js risk |
 | Bun runtime code, Bun package manager behavior, `bun.lock`, `bunfig.toml`, Bun test runner behavior, Bun bundling, Bun TypeScript execution, or Bun-specific APIs are created or changed | `.mustflow/skills/bun-code-change/SKILL.md` | Bun role signals, `package.json`, Bun and non-Bun lockfiles, `bunfig.toml`, CI/Docker Bun setup, TypeScript config, Bun APIs, native dependency signals, and command contract entries | Bun runtime code, Bun package manager metadata, lockfiles, `bunfig.toml`, scripts, tests, bundler config, TypeScript/declaration pipeline, package metadata, and directly synchronized docs | Bun role confusion, lockfile drift, trusted dependency overgrant, runtime/package-manager conflation, Bun TypeScript typecheck overclaim, Bun build declaration gap, Node compatibility break, shebang mismatch, or native binary break | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Bun role classification, lockfile/trust notes, runtime/type/build/test notes, Node compatibility risks, verification, and remaining Bun risk |
 | Dockerfiles, `.dockerignore`, Docker Compose files, BuildKit or buildx behavior, container image metadata, tags, entrypoints, health checks, Docker CI workflows, image security scanning, SBOM or provenance settings, registry publishing, or container runtime validation are created or changed | `.mustflow/skills/docker-code-change/SKILL.md` | Docker surfaces, project image shape, base image and platform signals, build context and cache signals, runtime contract, security and supply-chain contract, and command contract entries | Dockerfiles, `.dockerignore`, Compose files, container CI workflow snippets, image metadata, package tests, docs examples, template metadata, and directly synchronized skill routes | cache breakage, secret leak, root runtime, host access escape, dev dependency in final image, mutable tag drift, untrusted CI publish, missing SBOM/provenance, unverified runtime, or false production-readiness claim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Docker surface classification, image/base/cache/stage decisions, secret/user/runtime/Compose/CI supply-chain notes, verification, and remaining Docker risk |
-| TypeScript source, declarations, tsconfig, package exports, module resolution, public API, compiler-version behavior, TypeScript 6-to-7 migration surfaces, native preview tooling, or TypeScript tests are created or changed | `.mustflow/skills/typescript-code-change/SKILL.md` | TypeScript config, compiler track, package entry metadata, target runtime, changed files, declaration and native-preview surfaces, and command contract entries | TypeScript source, declarations, compiler config, exports, tests, native-preview comparison notes, and directly synchronized docs | weakened type safety, module drift, public API drift, unverified declaration output, TypeScript 6 deprecation suppression, or native-preview over-adoption | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, module, type, public API, compiler-version, and native-preview boundary checked, changes made, verification, and remaining TypeScript risk |
+| TypeScript source, declarations, tsconfig, package exports, module resolution, public API, compiler-version behavior, TypeScript 6-to-7 migration surfaces, TypeScript 7 RC or nightly tooling, or TypeScript tests are created or changed | `.mustflow/skills/typescript-code-change/SKILL.md` | TypeScript config, compiler track, package entry metadata, target runtime, changed files, declaration, TS6 API, TS7 RC, and optional TS7 nightly surfaces, and command contract entries | TypeScript source, declarations, compiler config, exports, tests, compiler-track comparison notes, and directly synchronized docs | weakened type safety, module drift, public API drift, unverified declaration output, TypeScript 6 deprecation suppression, TS7 RC over-adoption, TS7 nightly over-adoption, or compiler API track drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, module, type, public API, compiler-version, RC, nightly, and API-track boundary checked, changes made, verification, and remaining TypeScript risk |
 | JavaScript source, module format, package entry, browser or Node runtime, dependency usage, Promise handling, bundler config, or JavaScript tests are created or changed | `.mustflow/skills/javascript-code-change/SKILL.md` | Package metadata, module system, runtime target, entrypoints, changed files, and command contract entries | JavaScript source, package exports, bundler config, dependencies, tests, and docs examples | runtime API leakage, ESM/CJS drift, discarded Promise, dependency bloat, or broken package entry | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime and module boundary checked, async and dependency notes, verification, and remaining JavaScript risk |
 | Python source, package metadata, runtime version, import layout, type checking, linting, CLI entry points, or tests are created or changed | `.mustflow/skills/python-code-change/SKILL.md` | Python version source, packaging files, import layout, lint/type/test config, changed files, and command contract entries | Python source, packaging metadata, imports, type hints, tests, and docs examples | unsupported syntax, import hacks, packaging drift, swallowed errors, or weakened lint/type checks | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, packaging, import, and type boundary checked, verification, and remaining Python risk |
 | PowerShell scripts, modules, command examples, `pwsh` invocations, native-command wrappers, quoting, here-strings, splatting, regex, wildcard, replacement strings, or PowerShell argument passing are created or changed | `.mustflow/skills/powershell-code-change/SKILL.md` | PowerShell version and invocation path, parser layers, native-command boundary, dynamic input boundaries, changed files, and command contract entries | PowerShell scripts, modules, package scripts, CI snippets, docs examples, native-command wrappers, tests, and directly synchronized docs | parser-layer confusion, quote loss, variable over-expansion, metacharacter interpretation, native argv drift, command injection, `--%` overuse, or cross-shell `-Command` breakage | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | PowerShell version and invocation boundary, parser ledger, string/here-string/regex/wildcard/replacement/native argv decisions, verification, and remaining PowerShell risk |
@@ -483,9 +488,9 @@ routes. Event routes stay inactive until their event occurs.
 | Database lock contention review needs to catch blocking visible in the diff, including hot rows, mutable counter caches, balance or stock updates, reservation flows, queue table claiming, `SELECT ... FOR UPDATE`, weaker row-lock choices, optimistic version checks, conditional updates, lock order, deadlock retry, MySQL/InnoDB gap or next-key locks, PostgreSQL row-lock variants, SQL Server lock escalation, long transactions, external calls inside transactions, DDL or metadata lock waits, idle-in-transaction blockers, lock timeout policy, connection-pool waits, or lock observability | `.mustflow/skills/database-lock-contention-review/SKILL.md` | Contended resource, workload concentration, database engine and isolation, lock path, index and predicate shape, transaction width, queue claim model, batch size, timeout and retry policy, observability evidence, and configured command intents | Data-shape changes such as ledgers, reservations, sharded counters, materialized summaries, conditional updates, weaker locks, stable lock order, chunked batches, queue shards, timeout policy, focused tests, docs, and directly synchronized templates | hot-row serialization, parent-counter bottleneck, select-then-update race, over-strong `FOR UPDATE`, missing lock-footprint index, gap-lock insert block, metadata-lock surprise, unordered multi-row deadlock, unchunked write outage, queue head contention, hidden FK parent lock, idle transaction blocking DDL, infinite lock wait, pool starvation, unsafe deadlock retry, or missing blocker/waiter evidence | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Lock-contention surface reviewed, contended resource and workload ledger, lock strength/order/index/queue/batch/DDL/timeout/pool/observability findings, evidence level, verification, and remaining database lock-contention risk |
 | SQLite-specific schema, query, transaction, migration, indexing, extension, WAL, local-file persistence, embedded database, mobile database, browser OPFS/WASM SQLite, cache index, or SQLite runtime behavior is created, changed, reviewed, or reported | `.mustflow/skills/sqlite-code-change/SKILL.md` | SQLite role, runtime and binding, file ownership, storage medium, concurrency shape, schema/type rules, query/index evidence, migration and recovery needs, changed files, and command contract entries | SQLite schema, queries, connection setup, transactions, pragmas, indexes, migrations, fixtures, tests, docs, and directly synchronized templates | wrong runtime assumption, file-lock surprise, WAL overclaim, network filesystem risk, disabled foreign keys, weak type constraints, unsafe raw SQL, query-plan overclaim, sidecar-file data loss, failed migration rebuild, or unverified backup/restore | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | SQLite runtime, storage, WAL/concurrency, schema/type/constraint, query/index, migration, backup/restore, verification, and remaining SQLite risk |
 | PostgreSQL-specific schema, query, transaction, migration, indexing, extension, role, row-level security, connection pooling, replication, backup, restore, managed Postgres, or Postgres runtime behavior is created, changed, reviewed, or reported | `.mustflow/skills/postgresql-code-change/SKILL.md` | PostgreSQL role, version, provider, extension inventory, topology, pooler, schema/type rules, query-plan evidence, transaction/retry rules, migration and recovery needs, changed files, and command contract entries | PostgreSQL schema, queries, migrations, generated SQL, connection setup, pool settings, roles, RLS policies, extensions, tests, docs, and directly synchronized templates | version drift, provider constraint miss, connection storm, lock or rewrite surprise, unsafe online DDL claim, bad pooler assumption, RLS bypass, search-path risk, extension drift, stale replica read, query-plan overclaim, or unverified restore | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | PostgreSQL version/topology, pooling, lock/transaction, schema/type/RLS/role, query/index/statistics, backup/restore, verification, and remaining PostgreSQL risk |
-| Dependency versions, lockfiles, package-manager metadata, workspace constraints, runtime engines, peer dependencies, optional dependencies, security advisory fixes, generated dependency output, framework plugins, TypeScript compiler tracks, CI actions, Docker base images, package manager behavior, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported | `.mustflow/skills/dependency-upgrade-review/SKILL.md` | Dependency name, old and new versions or ranges, direct or transitive path, ecosystem and package manager, declaration files, lockfiles, runtime or toolchain files, advisory or release-note evidence, generated outputs, callers, docs, package output, Docker, CI, or TypeScript compiler-track surfaces, and command contract entries | Package declarations, lockfiles, generated outputs, compatibility code, tests, docs, package metadata, Docker or CI files, TypeScript compiler-track notes, and directly synchronized examples | lockfile churn, hidden transitive replacement, peer or engine break, module-format drift, native or optional package break, framework or generator output drift, unsafe broad security update, weakened tests, Docker or CI runtime drift, native-preview over-adoption, or unreviewed supply-chain change | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Upgrade reason, ecosystem surface, direct and transitive graph changes, compatibility classification, runtime/peer/engine/module/feature/platform/generated-output/compiler-track risks, synchronized surfaces, verification, and remaining dependency-upgrade risk |
+| Dependency versions, lockfiles, package-manager metadata, workspace constraints, runtime engines, peer dependencies, optional dependencies, security advisory fixes, generated dependency output, framework plugins, TypeScript compiler tracks, CI actions, Docker base images, package manager behavior, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported | `.mustflow/skills/dependency-upgrade-review/SKILL.md` | Dependency name, old and new versions or ranges, direct or transitive path, ecosystem and package manager, declaration files, lockfiles, runtime or toolchain files, advisory or release-note evidence, generated outputs, callers, docs, package output, Docker, CI, or TypeScript compiler-track surfaces, and command contract entries | Package declarations, lockfiles, generated outputs, compatibility code, tests, docs, package metadata, Docker or CI files, TypeScript compiler-track notes, and directly synchronized examples | lockfile churn, hidden transitive replacement, peer or engine break, module-format drift, native or optional package break, framework or generator output drift, unsafe broad security update, weakened tests, Docker or CI runtime drift, TS7 RC over-adoption, TS7 nightly over-adoption, or unreviewed supply-chain change | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Upgrade reason, ecosystem surface, direct and transitive graph changes, compatibility classification, runtime/peer/engine/module/feature/platform/generated-output/compiler-track risks, synchronized surfaces, verification, and remaining dependency-upgrade risk |
 | Dependency, package, runtime, framework, tool, command, plugin, service, platform capability, supported-version policy, security patch path, ecosystem maturity claim, maintainer-risk assumption, runtime portability claim, edge or serverless compatibility claim, critical-path library choice, package script, lifecycle hook, binary download, lockfile, audit result, or supply-chain-sensitive dependency surface is assumed, added, removed, imported, invoked, installed, audited, or documented | `.mustflow/skills/dependency-reality-check/SKILL.md` | Assumed dependency or capability, declaration files, version or feature expectation, role criticality, supported-version or end-of-life evidence, patchability expectation, runtime compatibility boundary, maintainer and ecosystem evidence when available, lockfile entry, package script or lifecycle hook, audit or provenance evidence, and relevant command intents | Package metadata, lockfiles, imports, scripts, command contracts, docs, tests, runtime policy notes, portability notes, and reports | unavailable dependency, hallucinated or lookalike package, fragile single-maintainer core dependency, experimental technology in a survival path, unsupported runtime, unclear security patch path, runtime-specific API leakage into core logic, stale version claim, lifecycle script risk, audit suppression, lockfile drift, or install guidance mismatch | `changes_status`, `changes_diff_summary`, `build`, `test_release`, `mustflow_check` | Dependency checked, ecosystem and maintainer-risk boundary reviewed, supported-version, patchability, and runtime-portability boundary reviewed, supply-chain surface reviewed, declarations synchronized, verification, and remaining dependency risk |
-| Generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, TypeScript compiler-track references, Rust release or MSRV references, or migration-sensitive snippets introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, or scaffold commands that may be stale | `.mustflow/skills/version-freshness-check/SKILL.md` | Versioned reference, owning files, repository version policy, approved freshness source, compatibility context, migration risk, TypeScript compiler track or Rust MSRV/toolchain track when relevant, and command contract entries | Package metadata, lockfiles, CI workflows, Dockerfiles, runtime files, framework config, docs, examples, templates, tests, and version-decision reports | stale default version, false latest claim, accidental major migration, repository policy mismatch, unsupported generated example, TypeScript beta/native-preview track confusion, Rust stable/nightly/MSRV confusion, floating-tag drift, or unverified security/support claim | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Versioned surfaces checked, repository policy and freshness source, selected version track, compatibility classification, TypeScript stable/beta/native-preview and Rust stable/nightly/MSRV split when relevant, approval need, synchronized surfaces, verification, and remaining version-freshness risk |
+| Generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, TypeScript compiler-track references, Rust release or MSRV references, or migration-sensitive snippets introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, or scaffold commands that may be stale | `.mustflow/skills/version-freshness-check/SKILL.md` | Versioned reference, owning files, repository version policy, approved freshness source, compatibility context, migration risk, TypeScript compiler track or Rust MSRV/toolchain track when relevant, and command contract entries | Package metadata, lockfiles, CI workflows, Dockerfiles, runtime files, framework config, docs, examples, templates, tests, and version-decision reports | stale default version, false latest claim, accidental major migration, repository policy mismatch, unsupported generated example, TypeScript RC/nightly/API-track confusion, Rust stable/nightly/MSRV confusion, floating-tag drift, or unverified security/support claim | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Versioned surfaces checked, repository policy and freshness source, selected version track, compatibility classification, TypeScript stable/RC/nightly/API-track and Rust stable/nightly/MSRV split when relevant, approval need, synchronized surfaces, verification, and remaining version-freshness risk |
 | External systems, protocols, SDKs, databases, webhooks, queues, files, object storage, signed upload or download URLs, caches, API response models, framework requests or responses, server actions, route handlers, edge functions, worker handlers, AI models, browser storage, search engines, analytics tools, email platforms, no-code tools, observability backends, trace or request context, provider data, or volatile component implementations cross the core boundary or need stable port/adapter translation, change isolation, error mapping, timeout, retry, circuit-breaker, bulkhead, idempotency, reconciliation, security, core-state ownership, vendor portability, or observability handling | `.mustflow/skills/adapter-boundary/SKILL.md` | External system or protocol, inbound/outbound direction, delivery boundary, internal use case, local port/adapter patterns, provider risk, provider failure policy, core-state ownership risk, vendor portability risk, observability identifier policy, API contract risk, change-isolation ledger, preserved consumer contract, changed files, and command contract entries | Ports, adapters, mappers, controllers, workers, stores, gateways, response mappers, telemetry mappers, timeout and retry policies, circuit breakers, bulkhead boundaries, tests, fixtures, assembly wiring, and directly synchronized docs or templates | provider leakage, caller churn from adapter-only changes, framework business-rule leakage, telemetry backend leakage, storage-key leakage, screen-shaped API coupling, pass-through wrapper, SaaS dashboard as truth source, search or analytics policy leakage, queue contract leakage, unclassified external failure, duplicate side effect, unsafe retry, missing timeout, missing circuit breaker, missing bulkhead, unresolved unknown provider outcome, broken identifier propagation, secret or personal-data leak, or untested integration drift | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Boundary classification, change-isolation ledger, preserved consumer contract, delivery adapter responsibility, internal port, provider containment, core-state ownership, vendor portability, validation and mapping, API response mapping, observability identifier flow, timeout/retry/circuit-breaker/bulkhead/idempotency handling, reconciliation behavior, security notes, verification, and remaining provider risk |
 | Tauri frontend invokes, Rust commands, capabilities, permissions, scopes, plugins, filesystem, dialog, shell, opener, updater, sidecar, or mobile native permissions are created or changed | `.mustflow/skills/tauri-code-change/SKILL.md` | Frontend call sites, Tauri config, Rust commands, capability and permission files, plugin config, changed files, and command contract entries | Tauri frontend, Rust commands, capabilities, permissions, scopes, plugins, tests, and docs | broad native permission, untrusted IPC input, filesystem escape, shell or updater risk, or WebView/native boundary drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | IPC, permission, scope, filesystem, shell, updater, and native boundary checked, verification, and remaining Tauri risk |
 | File path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, clone or checkout destinations, scaffold roots, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported | `.mustflow/skills/file-path-cross-platform-change/SKILL.md` | Path ledger, trust classes, accepted path representation, base root, path helpers, safe filesystem wrappers, clone/checkout/scaffold/install/extract outputs, staging and promotion policy, temp/cache helpers, lock policy, archive policy, upload/download policy, scanner policy, CLI/API/schema/snapshot/generated/package surfaces, platform expectations, failure taxonomy, and command contract entries | Path validators, helpers, wrappers, schemas, CLI/API parsing, snapshots, fixtures, docs, tests, generated-output paths, package artifact paths, clone or scaffold destinations, archive extraction, scanner bounds, temp/cache handling, locks, and cleanup code | path traversal, base containment bypass, drive-relative path bug, reserved-name bug, case-collision bug, Unicode-collision bug, Git checkout path-length failure misreported as network or auth, unsafe archive extraction, non-atomic write claim, stale lock, scanner loop, partial-output cleanup data loss, user-selected destination deletion, path contract drift, or package artifact path drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Path contract, path ledger, trust classes, root policy, preflight/staging/promotion decisions, Windows/macOS/Linux/archive/upload/download/scanner/lock/temp/cache/atomic/cleanup decisions, failure taxonomy, synchronized contract surfaces, verification, and remaining path risk |

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.astro-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: astro-code-change
@@ -57,6 +57,7 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 ## Preconditions
 
 - Read Astro config, content config, and the affected route tree before changing routing, content, canonical, RSS, sitemap, or hydration behavior.
+- Identify the Astro major version before applying migration rules. Astro v6 changes must be checked against the v6 upgrade guide instead of inferred from older routing or adapter habits.
 - Identify build-time versus request-time data before adding data access.
 - Identify which UI truly needs browser JavaScript and which UI truly needs framework state before adding a framework island.
 - Treat file movement under `src/pages`, route parameter changes, and content slug changes as URL contract changes.
@@ -73,6 +74,7 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 ## Procedure
 
 1. Read package metadata and Astro config first. Record Astro version, framework integrations, `site`, `base`, `trailingSlash`, `output`, adapter, sitemap integration, MDX integration, and any framework integration.
+   - For Astro v6 migrations, check removed or changed surfaces before editing call sites: `Astro.glob()` replacement with `import.meta.glob()` or content collections, `.cjs` and `.cts` config removal, `astro:ssr-manifest`, `RouteData.generate()`, old adapter hooks, old `NodeApp` paths, Zod 4 schema effects, and numeric dynamic route params.
 2. Read `src/content.config.*` when content, docs, blog, RSS, sitemap, canonical, or route generation is involved. Record each collection name, loader base, schema fields, slug/id policy, draft field, and date fields.
 3. Build a route ledger from `src/pages`: static pages, dynamic pages, rest routes, endpoints, prerendered routes, on-demand routes, and possible route-priority collisions.
 4. Classify the change: static route, dynamic route, endpoint, content collection, integration, adapter, SSR/on-demand, island, script, asset, RSS, sitemap, canonical, or docs/content.
@@ -100,7 +102,7 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 
 - In static output, every dynamic route must have `getStaticPaths`.
 - In on-demand or SSR dynamic routes, do not use `getStaticPaths`; read `Astro.params`, perform the request-time lookup, and handle missing entries with an explicit 404 or redirect path.
-- `getStaticPaths` params must match bracket parameter names exactly and must be strings.
+- `getStaticPaths` params must match bracket parameter names exactly. Param values must be strings, except rest parameters may use `undefined`; numeric params are invalid in Astro 6.
 - Custom slugs containing `/` require a rest route such as a catch-all route. Do not force slash-containing slugs into a single named parameter route.
 - Treat changes under `src/pages` as public URL changes, including endpoint names and extension-bearing endpoint paths.
 - Check route priority when adding static routes, named parameters, rest parameters, catch-all routes, and endpoints that could claim the same URL.
@@ -132,7 +134,7 @@ Reject or revise a change when:
 - `client:only` is used because SSR broke, instead of isolating the browser-only dependency.
 - Static output dynamic routes lack `getStaticPaths`.
 - On-demand or SSR dynamic routes use `getStaticPaths`.
-- Route params do not match bracket names or are not strings.
+- Route params do not match bracket names, non-rest params are not strings, rest params use values other than strings or `undefined`, or Astro 6 routes still rely on numeric params.
 - A content slug with `/` is mapped through a non-rest route.
 - Draft filtering differs between lists, detail pages, RSS, sitemap, or pagination.
 - Canonical URLs are built by ad hoc string concatenation.

package/templates/default/locales/en/.mustflow/skills/dependency-upgrade-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.dependency-upgrade-review
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: dependency-upgrade-review
@@ -40,7 +40,7 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 - A task claims a dependency change is "only patch", "only devDependency", "safe minor", "security-only", "transitive only", "lockfile only", or "no runtime change".
 - A dependency update touches installation, publish output, generated clients, SDKs, native binaries, browser bundles, serverless or edge runtime, ESM/CJS/module format, Python markers, Go module graph, Cargo features, JVM dependency mediation, .NET target frameworks, Ruby/PHP/Swift lockfiles, Docker images, or CI actions.
 - A Python runtime support floor, CI matrix, container image, `requires-python`, standard-library feature expectation, or security-default expectation changes as part of an upgrade.
-- A TypeScript upgrade touches TypeScript 6 transition deprecations, TypeScript 7 native preview, `@typescript/native-preview`, `tsgo`, compiler API consumers, declaration emit, framework typecheck wrappers, or editor language-service behavior.
+- A TypeScript upgrade touches TypeScript 6 transition deprecations, TS6 stable API compatibility, TypeScript 7 RC compiler verification, TypeScript 7 nightly comparison, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API consumers, declaration emit, framework typecheck wrappers, or editor language-service behavior.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -96,8 +96,8 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 11. Treat framework, plugin, code generator, formatter, linter, bundler, ORM, protobuf, OpenAPI, GraphQL, database driver, and test-runner upgrades as behavior changes when their output, config schema, plugin API, CLI flags, or generated code can change.
 12. For Python runtime upgrades, treat `requires-python`, CI matrices, base images, dependency markers, wheels, packaging output, standard-library API availability, and security-default changes as one compatibility contract. Review version-gated standard-library usage and changed defaults before assuming the upgrade is only a dependency resolution change.
 13. For Python upgrades that adopt newer standard-library behavior, call out affected paths such as archive extraction, subprocess handling, async lifecycle, import/resource loading, typing surfaces, data-class shapes, and diagnostic flags. Keep fallbacks or compatibility wording when the repository still supports older interpreters.
-14. For TypeScript upgrades, classify the compiler track explicitly: stable `typescript` and `tsc`, TypeScript 6 transition release, TypeScript 7 native preview via `@typescript/native-preview` and `tsgo`, editor extension preview, or framework-owned wrapper. Do not treat a native preview package as a stable replacement for the `typescript` package unless the repository policy says so.
-15. For TypeScript 6, review deprecations as future TypeScript 7 removals. For TypeScript 7 native preview, review unsupported compiler API, transformer, language-service plugin, watch/incremental, declaration emit, framework wrapper, and generated-output risks before changing dependency declarations or scripts.
+14. For TypeScript upgrades, classify the compiler track explicitly: TS6 stable API track through `@typescript/typescript6` and `tsc6`, TS7 RC compiler track through `typescript@rc` and `tsc`, TS7 nightly track through `@typescript/native-preview` and `tsgo`, future TS7 stable track through the stable `typescript` package, editor extension preview, or framework-owned wrapper. Do not treat a nightly package as a stable replacement for the `typescript` package unless the repository policy says so.
+15. For TypeScript 6, review deprecations as future TypeScript 7 removals. For TS7 RC, review compiler parity, declaration emit, watch/incremental, generated-output, and framework wrapper risks. For TS7 nightly, use `tsgo` only as an optional comparison path. Keep compiler API, transformer, ESLint, language-service plugin, and framework wrapper consumers on the TS6 API track until their owners explicitly support the TS7 API surface.
 16. For new dependencies introduced by the upgrade, invoke the `dependency-reality-check` decision path: license, maintainer risk, provenance, lifecycle scripts, binary downloads, package age, transitive size, supply-chain risk, and replacement path.
 17. For Docker base images and CI actions, review them as dependencies. Check image/action source, version pinning policy, digest use when required, runtime version changes, security patch reason, cache impact, and deployment smoke coverage.
 18. Synchronize dependent surfaces: generated code, snapshots, mocks, fixtures, examples, SDK clients, OpenAPI or GraphQL artifacts, README install guidance, migration docs, changelog, Docker/CI docs, and package publish metadata.
@@ -112,7 +112,7 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 - Direct and transitive changes are understood, not hidden behind lockfile volume.
 - Runtime engine, peer dependency, optional/platform package, feature, module-format, generated-output, and publish-surface risks are classified.
 - Python runtime upgrades classify standard-library availability, changed defaults, packaging output, and security-behavior impact.
-- TypeScript compiler-track changes distinguish stable compiler upgrades from native-preview comparison work.
+- TypeScript compiler-track changes distinguish TS6 stable API compatibility, TS7 RC compiler verification, TS7 nightly comparison work, and future TS7 stable adoption.
 - Security fixes are narrow unless the user explicitly accepted a broader modernization.
 - Tests and scanners were not weakened to pass the upgrade.
 
@@ -142,7 +142,7 @@ Prefer the narrowest configured intent that proves the actual upgraded dependenc
 - If tests fail after an upgrade, do not delete tests, skip tests, loosen assertions, lower coverage, disable scanners, or widen permissions unless the behavior contract intentionally changed and the report says so.
 - If a security upgrade requires broad modernization, split the minimum patch from the modernization when possible.
 - If generated output changes, regenerate from the official generator path and explain the generated diff. Do not hand-edit generated dependency output.
-- If TypeScript 7 native preview is introduced, keep stable TypeScript verification unless the repository explicitly adopts the preview path and all compiler API, framework wrapper, declaration, and generated-output risks are covered.
+- If TS7 RC or nightly verification is introduced, keep the repository's stable, TS6 API, or framework verification unless the repository explicitly adopts the new track and all compiler API, framework wrapper, declaration, and generated-output risks are covered.
 - If configured verification is missing, report the missing command intent instead of inferring a package-manager command.
 
 <!-- mustflow-section: output-format -->
@@ -154,7 +154,7 @@ Prefer the narrowest configured intent that proves the actual upgraded dependenc
 - Compatibility classification: patch, minor, major, pre-1.0, security, toolchain, generated-output, Docker, or CI action
 - Runtime, peer, engine, module, feature, platform, generated-output, and publish-surface risks
 - Python runtime, standard-library, packaging, and changed-default risks when relevant
-- TypeScript compiler-track and native-preview risks when relevant
+- TypeScript compiler-track, RC, nightly, and API compatibility risks when relevant
 - Security advisory and fixed-range notes when relevant
 - Surfaces synchronized
 - Command intents run

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.elysia-code-change
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: elysia-code-change
-description: Apply this skill when Elysia routes, schemas, plugins, decorators, derives, guards, auth, error handling, OpenAPI output, Eden clients, or Bun server behavior are created or changed.
+description: Apply this skill when Elysia routes, schemas, plugins, decorators, derives, resolves, guards, auth, error handling, OpenAPI output, Eden clients, or Bun server behavior are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -33,7 +33,7 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
 <!-- mustflow-section: use-when -->
 ## Use When
 
-- `new Elysia`, route methods, `t.Object`, request or response schemas, `.use`, `.guard`, `.derive`, `.decorate`, `.onError`, auth middleware, OpenAPI, Eden, or Bun server tests change.
+- `new Elysia`, route methods, `t.Object`, request or response schemas, `.use`, `.guard`, `.derive`, `.resolve`, `.decorate`, `.onError`, auth middleware, OpenAPI, Eden, or Bun server tests change.
 - The task adds API routes, plugins, validators, error envelopes, authentication, or generated client contracts.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -59,7 +59,8 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
 
 - Define request and response schemas with the route.
 - Keep framework context at the route boundary and move only framework-free business logic into services.
-- Preserve plugin, decorator, derive, and store inference through Elysia chaining.
+- Preserve plugin, decorator, derive, resolve, and store inference through Elysia chaining.
+- Use `.derive` only for intentional pre-validation context shaping. Use `.resolve` by default for auth, session, user, tenant, permission, or other request-derived values that depend on validated headers, body, query, or params.
 - Keep OpenAPI and Eden clients aligned with route schemas when present.
 
 <!-- mustflow-section: procedure -->
@@ -70,9 +71,14 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
 3. Add or update schemas for every external input and meaningful response status.
 4. Do not annotate handlers with broad `any`, duplicated manual interfaces, or imported `Context` types that erase inference.
 5. Keep request-specific state out of module-level mutable globals.
-6. Centralize expected error envelope and auth failure behavior.
-7. If OpenAPI or Eden is used, confirm the generated contract follows the schema change.
-8. Choose configured verification intents that cover types, server boot, route happy path, validation failure, auth failure, OpenAPI, and Eden inference when available.
+6. For request-derived context, choose the lifecycle hook by validation dependency:
+   - use `.derive` only when transforming raw request context before validation is intentional;
+   - use `.guard()` to apply schema and auth-related validation around a route group;
+   - use `.resolve()` inside the validated chain for user, session, tenant, permission, or other values that depend on validated input;
+   - check the order between `.resolve()` and `beforeHandle` before relying on a value in an auth or permission hook.
+7. Centralize expected error envelope and auth failure behavior.
+8. If OpenAPI or Eden is used, confirm the generated contract follows the schema change.
+9. Choose configured verification intents that cover types, server boot, route happy path, validation failure, auth failure, OpenAPI, and Eden inference when available.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -80,7 +86,7 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
 - Schemas, runtime validation, and inferred types remain one contract.
 - Error and auth responses are consistent.
 - OpenAPI and Eden impact is known.
-- No route relies on unvalidated input or erased context types.
+- No route relies on unvalidated input, pre-validation auth context, or erased context types.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -101,6 +107,7 @@ Report missing route, OpenAPI, or Eden verification intents when relevant.
 
 - If schema and manual types diverge, make schema the source of truth or report the competing contract.
 - If plugin inference breaks after extraction, return context-sensitive code to the Elysia chain or narrow the extraction.
+- If auth or session state is derived before validation through `.derive`, move it to a validated `.guard()` plus `.resolve()` chain or report the validation-order risk.
 - If auth behavior is unclear, stop the route change and inspect or request the auth contract.
 
 <!-- mustflow-section: output-format -->

package/templates/default/locales/en/.mustflow/skills/external-skill-intake/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.external-skill-intake
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: external-skill-intake
-description: Apply this skill when reviewing third-party SKILL.md files, skill packs, awesome lists, or skill installer recommendations before adapting them into mustflow.
+description: Apply this skill when reviewing third-party SKILL.md files, skill packs, awesome lists, GitHub CLI `gh skill` flows, or skill installer recommendations before adapting them into mustflow.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -36,6 +36,7 @@ External web-testing and session-handoff ideas need extra care: they may be usef
 
 - The user provides an outside `SKILL.md`, skill folder, skill pack, awesome list, or GitHub skill repository.
 - The task asks whether mustflow should adopt, import, translate, install, or mirror an external skill.
+- The task reviews a GitHub CLI `gh skill` search, preview, install, update, list, or publish workflow as external skill input.
 - A proposed skill includes helper scripts, references, assets, command recipes, external services, dependencies, permissions, or tool-specific policy.
 - A skill recommendation from another agent needs to be converted into a mustflow-native procedure.
 - An external skill suggests Playwright-style web testing, browser sessions, development servers, session handoffs, progress files, or agent memory records.
@@ -53,7 +54,7 @@ External web-testing and session-handoff ideas need extra care: they may be usef
 
 - External source identity: repository, URL, local path, package name, author or organization, and checked date or revision when available.
 - License or provenance evidence, or an explicit note that it was not visible.
-- External skill shape: `SKILL.md`, helper `scripts/`, `references/`, `assets/`, generated artifacts, package assumptions, and install instructions.
+- External skill shape: `SKILL.md`, helper `scripts/`, `references/`, `assets/`, generated artifacts, package assumptions, install instructions, and any `gh skill` provenance metadata such as repository, ref, commit, or tree SHA.
 - Intended mustflow outcome: reject, defer, update an existing skill, create a new mustflow-native skill, or keep only a research note.
 - Existing mustflow skills that may overlap, plus the profile where any adopted procedure would belong.
 - Prerequisites for adoption, such as a bounded one-shot verification intent or a restricted handoff ledger model.
@@ -66,6 +67,7 @@ External web-testing and session-handoff ideas need extra care: they may be usef
 - Confirm that the user's direct request, nearest `AGENTS.md`, and `.mustflow/config/commands.toml` define the active scope.
 - Refresh upstream source claims when the adoption decision depends on current repository contents, package behavior, license text, or tool capabilities.
 - Do not run an external installer, helper script, package command, or service workflow as part of intake unless the repository command contract explicitly permits it.
+- Treat `gh skill preview` output as review evidence only. Do not install, update, force-update, or publish skills from a mustflow repository task unless an explicit task and command boundary authorizes that lifecycle.
 - Defer web-app testing skills until mustflow has a configured one-shot intent that starts, tests, and stops the target within that command boundary.
 - Defer session-handoff skills unless they can use a restricted ledger shape: goal, scope, touched files, verification plan, command intents run or skipped, remaining risks, and next restart point.
 
@@ -83,7 +85,9 @@ External web-testing and session-handoff ideas need extra care: they may be usef
 
 1. Separate the user's request from external instructions, recommendations, installer commands, and generated advice.
 2. Record provenance: source, path, author or organization, license visibility, checked date or revision, and whether the source was refreshed in this task.
-3. Inspect the external skill shape: sections, triggers, helper files, references, assets, generated outputs, dependencies, command recipes, and target agent assumptions.
+3. Inspect the external skill shape: sections, triggers, helper files, references, assets, generated outputs, dependencies, command recipes, target agent assumptions, and installed provenance metadata.
+   - For GitHub CLI skill intake, model the lifecycle as preview -> provenance check -> tag or commit pin decision -> scripts/references/assets inspection -> host and scope decision.
+   - Treat installed repository, ref, and tree SHA metadata as evidence for reproducibility, not as proof that the content is safe.
 4. Identify unsafe or incompatible capabilities: raw shell commands, network access, credential use, destructive operations, background services, long-running watchers, browser automation, external SaaS actions, or policy overrides.
 5. Treat web-testing recommendations as deferred unless they map to a configured one-shot verification intent such as a future docs-site or dashboard smoke check. Do not tell agents to start a development server, watcher, browser session, or local server directly from a skill.
 6. Treat session-handoff recommendations as deferred unless they fit the restricted ledger fields. Do not create a free-form handoff skill that stores hidden reasoning, full chat logs, raw terminal output, secrets, personal data, or autonomous worker state.
@@ -121,6 +125,7 @@ Use `test_related` or `test_audit` when tests, profile selection, template insta
 
 - If license or provenance is unclear, do not copy the external text or helper files; summarize the idea and report the gap.
 - If the external skill grants command permission, embeds raw commands, or depends on an installer, convert the need into configured command-intent requirements or reject it.
+- If a `gh skill update --dry-run` style check is useful, keep it read-only evidence. Never make `--force` an automatic path for mustflow-owned or locally modified skills because it can overwrite local changes.
 - If the useful idea duplicates an installed mustflow skill, update the existing skill or route instead of adding a new one.
 - If the source cannot be refreshed and freshness matters, keep the decision conservative and report the stale-source boundary.
 - If adapting the skill would require broad localization, dependency, or runtime changes, defer the adoption and capture the narrower prerequisite.
@@ -136,6 +141,6 @@ Use `test_related` or `test_audit` when tests, profile selection, template insta
 - Unsafe or incompatible capabilities found
 - Adoption decision
 - mustflow-native changes made or deferred
-- Deferred prerequisites such as bounded web-smoke intent or restricted handoff ledger
+- Deferred prerequisites such as bounded web-smoke intent, restricted handoff ledger, or explicit external skill lifecycle boundary
 - Command intents run
 - Remaining intake risks

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.rate-limit-integrity-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: rate-limit-integrity-review
@@ -209,9 +209,12 @@ contract, observability, and operator escape hatch?"
     - Emit a machine-readable error code and `Retry-After` when a well-behaved client can wait.
     - If `Retry-After` and `RateLimit` hints disagree, `Retry-After` should govern immediate client
       behavior.
-    - Standards-track `RateLimit` and `RateLimit-Policy` headers may coexist with legacy
-      `X-RateLimit-*`, but do not assume every client or proxy gives legacy headers the same
-      meaning.
+    - `RateLimit` and `RateLimit-Policy` are defined by the active IETF Internet-Draft
+      `draft-ietf-httpapi-ratelimit-headers-11`, intended for Standards Track but not yet an RFC.
+      Treat their structured field details as draft-revision-specific, and refresh the draft before
+      writing durable standards claims.
+    - `RateLimit` and `RateLimit-Policy` may coexist with legacy `X-RateLimit-*`, but do not assume
+      every client or proxy gives legacy headers the same meaning.
     - Do not reveal exact internal capacity, shard counts, provider quotas, attack thresholds, or
       sensitive account state in public responses.
     - During active abuse, silent drop, generic denial, or coarser hints can be safer than a perfect

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

@@ -366,6 +366,12 @@ 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."support-surface-advisor"]
+category = "general_code"
+route_type = "primary"
+priority = 67
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "public_api_change", "docs_change", "product_change", "package_metadata_change"]
+
 [routes."runtime-target-selection"]
 category = "general_code"
 route_type = "primary"

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: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: rust-code-change
@@ -98,7 +98,8 @@ instead of treated as incidental.
      environment and verification choices that must be reported when they dominate iteration cost.
 4. Determine the Rust version contract before using newer syntax or standard-library APIs:
    - treat `rust-version`, edition, `rust-toolchain.toml`, CI matrix, docs.rs metadata, and downstream compatibility notes as the MSRV evidence ledger;
-   - do not use 1.95+ APIs such as `cfg_select!`, match `if let` guards, or `Vec::push_mut`, or 1.96+ APIs such as `assert_matches!` and `core::range`, unless the declared MSRV and toolchain path support them;
+   - 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.
@@ -133,7 +134,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 Rust 1.95+ or 1.96+ API usage without MSRV, `rust-version`, edition, toolchain, CI, or fallback evidence.
+- New version-gated Rust API usage without API-specific MSRV, `rust-version`, edition, toolchain, CI, or fallback evidence.
 - 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/skill-authoring/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.skill-authoring
 locale: en
 canonical: true
-revision: 8
+revision: 9
 lifecycle: mustflow-owned
 authority: procedure
 name: skill-authoring
@@ -75,6 +75,7 @@ Create narrow, repeatable mustflow skill procedures without turning skills into
 8. Reference command intent names only. Do not include raw shell command blocks or claim that the skill authorizes command execution.
 9. Update `.mustflow/skills/INDEX.md` with a compact route that includes trigger, required input, edit scope, risk, verification intents, and expected output.
 10. If the skill is installed by a template, update the canonical skill copy plus installation metadata, package tests, and public docs that list installed files. Do not fan out routine skill edits into every localized skill copy by default; localized skill copies may be absent, and non-source template locales should fall back to the canonical source-locale skill text unless locale-specific skill text is intentionally maintained and translation review is available.
+11. If a portable Agent Skills artifact is part of the task, create or validate it as a derived export, not as the mustflow-native canonical source. Use portable-only top-level fields and string-to-string metadata. A `gh skill publish --dry-run` check may validate the export artifact when available, but `gh skill publish --fix` must be limited to the export directory because it can remove installed provenance metadata and mustflow-native fields.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -109,6 +110,7 @@ If the skill changes tests or behavior-sensitive template output, also use the r
 - Quality gate result and overlap decision
 - Command intents referenced
 - Template or localization metadata updated
+- Portable export validation result when relevant
 - Command intents run
 - Skipped command intents and reasons
 - Remaining overlap, translation, or validation risks

package/templates/default/locales/en/.mustflow/skills/skill-refresh/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.skill-refresh
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: skill-refresh
@@ -65,7 +65,7 @@ source freshness, routing metadata, helper-file alignment, and verification evid
 - Existing behavior contract: trigger, non-trigger, required inputs, allowed edits, outputs,
   command intents, forbidden actions, runtime assumptions, and package boundaries.
 - Runtime target: mustflow-native, Codex-native, Claude-native, portable Agent Skills compatible,
-  or intentionally product-specific.
+  GitHub CLI `gh skill` lifecycle, or intentionally product-specific.
 - Source ledger: repository-owned sources, official upstream sources, external recommendations,
   checked date or revision, and any source that could not be refreshed.
 - Package ledger: `scripts/`, `references/`, `assets/`, relative links, UI metadata, route metadata,
@@ -97,6 +97,8 @@ source freshness, routing metadata, helper-file alignment, and verification evid
 - Do not copy external prose verbatim without a provenance and license decision.
 - Do not add product-specific fields to a portable skill unless the runtime mode intentionally
   supports them.
+- Do not make a mustflow-native canonical skill pretend to be portable by deleting mustflow
+  lifecycle metadata. Export portable Agent Skills as a derived profile instead.
 - Do not write research logs, broad changelogs, or freshness ledgers into the executable skill
   package unless they are required inputs for the skill's operation.
 
@@ -136,6 +138,15 @@ source freshness, routing metadata, helper-file alignment, and verification evid
 6. Decide runtime mode before editing frontmatter or fields. Keep mustflow-native metadata for
    mustflow skills. For cross-runtime skills, separate portable guidance from Codex-native,
    Claude-native, or other product-specific extensions instead of mixing incompatible fields.
+   - mustflow-native canonical skills may keep `mustflow_doc`, `locale`, `canonical`, `revision`,
+     `lifecycle`, `authority`, and structured `metadata.command_intents`.
+   - portable Agent Skills exports should contain only portable top-level fields such as `name`,
+     `description`, optional `license`, optional `compatibility`, optional string-to-string
+     `metadata`, and optional `allowed-tools`.
+   - When exporting portable skills, serialize mustflow-only fields into namespaced string metadata
+     only when useful, convert arrays such as `command_intents` to JSON strings or omit them, and
+     run portable validation only against the exported artifact.
+   - Do not run portable fixers against canonical mustflow sources.
 7. Treat `description` as routing code. Put the strongest positive trigger and the most important
    exclusion near the front. Avoid generic descriptions that overlap with broad authoring, docs, or
    review skills.
@@ -157,6 +168,10 @@ source freshness, routing metadata, helper-file alignment, and verification evid
     laundering, hidden network use, credential access, absolute paths, home-directory scanning,
     prompt injection, symlink escape, broad file writes, or mismatch between prose and script
     behavior.
+    For GitHub CLI skill flows, compare installed tree SHA, current upstream tree SHA, and local
+    modifications as a three-way refresh problem. Treat `gh skill update --dry-run` as read-only
+    evidence when available, and never make `--force` automatic for mustflow-owned or modified
+    skills.
 13. Preserve user edits through a three-way mindset:
     - old baseline;
     - current user-edited skill;
@@ -209,6 +224,8 @@ package output, public docs, or release-sensitive template output changed.
 
 - If the target runtime cannot be identified, keep the refresh portable and report product-specific
   claims as deferred.
+- If portable Agent Skills compatibility is requested, validate a derived export profile instead of
+  weakening the mustflow-native canonical schema.
 - If a source cannot be refreshed and the claim is high drift, omit the claim or mark it as
   snapshot-only instead of embedding it as current.
 - If route overlap is detected, tighten `description`, Use When, and Do Not Use When before adding

package/templates/default/locales/en/.mustflow/skills/support-surface-advisor/SKILL.md

@@ -0,0 +1,156 @@
+---
+mustflow_doc: skill.support-surface-advisor
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: support-surface-advisor
+description: Apply this skill when designing, scoping, implementing, or reviewing an app, service, CLI, API, SDK, library, desktop app, automation tool, or developer tool and the agent must decide which user, developer, operator, automation, integration, recovery, upgrade, documentation, or observability surfaces to expose, defer, or explicitly not support.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.support-surface-advisor
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Support Surface Advisor
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Help agents turn vague product or program-development requests into a bounded support contract. A support surface is not just a feature; once exposed, it becomes a compatibility, documentation, testing, and maintenance promise.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A user asks to build, scope, review, or evolve an app, service, CLI, API, SDK, library, desktop app, automation tool, or developer tool.
+- It is unclear whether the product should expose UI, CLI, programming API, network API, webhooks, plugins, configuration, import/export, docs, logs, diagnostics, test support, recovery, performance limits, security/privacy, accessibility/i18n, or deployment/upgrade support.
+- The user may be a solo founder, inexperienced developer, or product owner who knows the core idea but not the support routes real users will need.
+- Multiple shells could reach the same core behavior, such as UI plus CLI, CLI plus API, or UI plus webhook automation.
+- A support route might accidentally become a public API, stable file format, integration promise, operational runbook, or backward-compatibility burden.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a tiny local bug fix with no product, integration, operation, or public-contract decision.
+- The user has already selected the support surfaces and only asks for implementation inside one route.
+- A narrower API, CLI output, UI, security, data, or release skill already owns the specific changed contract.
+- The work is only visual polish, copy editing, or one-off internal tooling with no exposed support promise.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Product stage: prototype, personal tool, team-internal tool, public SaaS, developer tool, library, CLI, desktop app, or another explicit stage.
+- Primary actors: end users, developers, operators, automation systems, support staff, admins, or third-party services.
+- Main usage path and the job it completes.
+- Integration need: scripts, CI, external services, webhooks, plugins, SDK calls, imports, exports, or manual-only use.
+- Public-contract willingness: which routes the user is ready to document, test, keep compatible, deprecate carefully, and support operationally.
+- Explicit non-goals: routes not supported now and routes kept internal-only.
+- Failure, recovery, upgrade, data movement, observability, security, privacy, accessibility, and localization expectations.
+- Current repository evidence, existing product docs, command contracts, APIs, or public examples when working in an existing codebase.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Treat every exposed support route as a maintenance contract, not as a free feature checkbox.
+- Do not ask for or recommend all support surfaces by default.
+- Distinguish what is supported now, deferred, explicitly not supported, and internal-only.
+- Keep command execution governed by `.mustflow/config/commands.toml`; this skill names intent concepts but does not authorize raw commands.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Ask focused scoping questions and propose a support-surface plan.
+- Update product docs, implementation notes, tests, route metadata, or code boundaries directly tied to the selected support surfaces.
+- Add only the selected surfaces and their tests/docs/contracts when the user asks for implementation.
+- Do not create duplicate business logic in UI, CLI, API, SDK, webhook, or plugin shells.
+- Do not expose internal functions, schemas, logs, error messages, settings, or file formats as public contracts by accident.
+- Do not put internal implementation explanations in user-facing UI copy.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the product stage and primary actors first. Do not recommend surfaces until you know who must use, integrate, operate, or recover the product.
+2. Identify the primary path. Pick the one route users should use first, such as UI for non-technical users, CLI for developer automation, SDK for library consumers, or network API for cross-service integration.
+3. Define the core engine boundary before adding shells.
+   - The core engine owns domain workflow, validation, state transitions, permissions, errors, data movement, and side-effect policy.
+   - UI, CLI, API, SDK, webhook, and plugin shells should translate inputs and outputs, call the core, and present results.
+   - UI, CLI, and API shells must not reimplement the same core rules separately.
+4. Ask only blocking questions. Prefer at most three at a time, with a recommended default when evidence supports it:
+   - Who will use this first: general users, developers, operators, admins, automation, or other services?
+   - What is the main route for the core job right now: UI, CLI, programming API/SDK, network API, or another route?
+   - Do scripts, CI, webhooks, imports, exports, or other services need integration in the next milestone?
+   - Which routes are you willing to keep stable, document, test, and migrate later?
+   - Which routes should be explicitly unsupported for now?
+   - What failure, recovery, upgrade, data movement, logging, privacy, and accessibility level is needed for the first real users?
+5. Use the support surface list as a risk prompt, not a checklist to fill:
+   - UI, CLI, programming API/SDK, network API, webhook/events, plugin/extension, configuration, auth/permissions, import/export, version/backcompat, deprecation/migration, docs/examples, errors/diagnostics, logs/observability, test support, failure recovery, performance/resource limits, security/privacy, accessibility/i18n, deployment/upgrade/recovery.
+6. Classify each relevant surface:
+   - `support_now`: a named actor needs it in the next milestone, the team can maintain it, the contract can be tested, and failure behavior is understood.
+   - `defer`: plausible later value exists, but there is no near-term user, integration, or operational capacity.
+   - `explicitly_not_supported`: exposing it would imply stable API, schema, data, security, operational, or compatibility promises the product is not ready to carry.
+   - `internal_only`: useful behind the scenes but not documented, not stable, and not safe for external reliance.
+7. Apply stage heuristics:
+   - Prototype or personal tool: one primary path, basic configuration, clear errors, a simple export or backup when data matters, and no SDK/webhooks/plugins unless they are the product.
+   - Team-internal tool: UI or CLI, role or environment boundaries, logs, import/export when data moves, upgrade notes, and enough docs for handoff.
+   - Public SaaS: UI, auth/permissions, security/privacy, diagnostics, recovery, observability, deployment/upgrade behavior, and docs; API/webhooks only when customers truly integrate.
+   - Developer tool or CLI: non-interactive execution, help text, exit codes, machine-readable output when scripts need it, configuration precedence, errors, docs, dry-run or test fixtures when side effects matter.
+   - Library or SDK: a narrow public API, typed errors, cancellation/resource cleanup where relevant, version/backcompat rules, examples, tests, and deprecation policy; no UI or network API unless that is the product.
+   - Desktop app: UI, settings, import/export or backup, upgrade/rollback expectations, crash diagnostics, accessibility/i18n baseline, and CLI/API only when automation is a real user need.
+8. Recommend a surface only when it has a real actor, near-term workflow, maintenance owner, compatibility story, and verification path.
+9. Explicitly defer or reject surfaces that duplicate the primary path, create a second core implementation, require unsupported operations capacity, or would lock internal data formats too early.
+10. For user-facing UI text, write natural product language. Do not leak implementation notes such as "this component handles..." or "this feature processes..." into visible copy.
+11. If implementation follows, activate the narrower skill for each selected surface before changing that surface, such as API contract, CLI output, UI quality, security/privacy, data migration, docs, or tests.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The recommended support surfaces are tied to actors, workflows, and maintenance capacity.
+- Deferred and explicitly unsupported surfaces are named instead of left as vague future work.
+- The core engine versus shell boundary prevents duplicated business logic across UI, CLI, API, SDK, webhook, and plugin routes.
+- Compatibility, docs, tests, failure, recovery, security, privacy, observability, accessibility, and upgrade risks are visible for every selected public route.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+When implementation changes code, schemas, templates, package metadata, or tests, also use the narrower configured intent named by the matching implementation skill.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the user cannot name users or a primary path, stop at questions and recommend the smallest reversible default.
+- If a desired route implies an unsupported public contract, mark it `defer` or `explicitly_not_supported` and explain the contract cost.
+- If UI, CLI, API, SDK, webhook, or plugin paths start duplicating core rules, move the rule decision to the core engine boundary before continuing.
+- If implementation requires a support surface whose verification intent is missing, report the missing verification instead of claiming readiness.
+- If the scope expands into every support route, reduce it to one primary route plus the minimum safety surfaces needed for the next real users.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Product stage and primary actors
+- Recommended support surfaces
+- Deferred support surfaces
+- Explicitly unsupported or internal-only surfaces
+- Immediate questions and recommended defaults
+- Maintenance contract and compatibility risks
+- Core engine versus shell boundary
+- Staged adoption plan
+- Follow-up skills needed for implementation
+- Command intents run
+- Skipped checks and reasons
+- Remaining support-surface risk

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.tailwind-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: tailwind-code-change
@@ -34,7 +34,7 @@ Preserve Tailwind static class detection, design tokens, bounded variants, respo
 ## Use When
 
 - Tailwind `class`, `className`, `@apply`, `@theme`, `@source`, `@reference`, config, source scanning, safelist, theme tokens, variants, arbitrary values, or component class composition change.
-- The task touches Tailwind v3/v4 migration, CSS-first configuration, token addition, responsive modifiers, state modifiers, `clsx`/`cn`, CVA-style variant helpers, `source(none)`, `@source inline`, `@source not inline`, or production CSS generation risk.
+- The task touches Tailwind v3/v4 migration, CSS-first configuration, token addition, responsive modifiers, state modifiers, `clsx`/`cn`, CVA-style variant helpers, `source(none)`, `@source inline()`, `@source not inline()`, path `@source`, path `@source not`, or production CSS generation risk.
 - Component APIs accept status, tone, intent, size, column count, color, spacing, or class-related props that affect Tailwind utilities.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -57,7 +57,8 @@ Preserve Tailwind static class detection, design tokens, bounded variants, respo
 
 - Confirm how Tailwind detects source classes before changing class composition, helper-file location, or CSS entry imports.
 - Identify whether the project is using Tailwind v3 config safelists or Tailwind v4 CSS source directives.
-- Identify whether Tailwind v4 source detection is automatic, disabled with `source(none)`, extended with `@source`, or narrowed with `@source not inline`.
+- Identify whether Tailwind v4 source detection is automatic, disabled with `source(none)`, extended with path `@source`, narrowed with path `@source not`, expanded with candidate `@source inline()`, or narrowed with candidate `@source not inline()`.
+- For Tailwind v4 migration, check browser support floors before recommending v4. If the project still supports browsers below Safari 16.4, Chrome 111, or Firefox 128, keep v3.4 as the safer maintenance track unless project policy changes.
 - Identify tokens, variant helpers, and semantic visual states before adding arbitrary values or raw colors.
 - Confirm whether affected components are local one-offs, shared components, or public design-system surfaces.
 
@@ -67,8 +68,9 @@ Preserve Tailwind static class detection, design tokens, bounded variants, respo
 - Use full static class strings that the build can detect.
 - Use existing theme tokens before arbitrary values or raw colors.
 - Use static maps, component extraction, or variant helpers for finite repeated variants.
-- Use safelists or `@source inline` only for finite class candidates that cannot appear in scanned source.
-- Use `@source not inline` or equivalent source policy to block known false-positive candidates when generated CSS would otherwise include unwanted utilities.
+- Use safelists or `@source inline()` only for finite class candidates that cannot appear in scanned source.
+- Use `@source not inline()` to block known false-positive class candidates when generated CSS would otherwise include unwanted utilities.
+- Use path `@source` to add scan sources and path `@source not` to exclude scan sources. Do not confuse those with candidate safelist or blocklist directives.
 - Use `@reference` when component-scoped styles need access to Tailwind theme variables, custom utilities, or variants without duplicating emitted CSS.
 - Use inline styles plus CSS variables for unbounded runtime values such as tenant, database, or user-provided colors.
 - Keep hover, focus-visible, disabled, aria/data, dark, and motion variants aligned with existing component behavior.
@@ -78,12 +80,12 @@ Preserve Tailwind static class detection, design tokens, bounded variants, respo
 
 1. Read Tailwind config or CSS entry, scanning rules, theme tokens, helpers, and nearby components.
 2. Classify the change: token, utility usage, dynamic variant, component extraction, responsive state, accessibility state, or migration.
-3. For Tailwind v4, classify CSS-first configuration before touching utility usage: `@theme`, `@utility`, `@variant`, `@custom-variant`, `@source`, `@source inline`, `@source not inline`, `source(none)`, and `@reference`. Do not apply v3 config instincts to a v4 CSS entry without checking the project pattern.
+3. For Tailwind v4, classify CSS-first configuration before touching utility usage: `@theme`, `@utility`, `@variant`, `@custom-variant`, path `@source`, path `@source not`, candidate `@source inline()`, candidate `@source not inline()`, `source(none)`, and `@reference`. Do not apply v3 config instincts to a v4 CSS entry without checking the project pattern.
 4. Treat every Tailwind class as a complete build-time token. Reject runtime interpolation, concatenation, array joins, or fragment assembly for utilities such as color, spacing, grid count, span, tone, or arbitrary values.
 5. For finite choices, use a static map with semantic keys and full class strings. Good keys describe UI meaning such as `danger`, `muted`, `compact`, or `featured`; bad keys store Tailwind fragments such as `red`, `600`, or `cols-3` for later assembly.
 6. Use a CVA-style variant helper only when a shared component has multiple variant axes, defaults, or compound variants. The helper must still contain full static class strings.
 7. Use safelists only as a last resort for finite candidates that cannot be present in source files. Tailwind v4 projects should express this through the project's CSS source policy; Tailwind v3 maintenance projects may use config safelists when that is the existing pattern. Do not safelist broad palettes or unbounded ranges to avoid fixing a bad component API.
-8. Keep `@source inline` bounded, named, and close to the CSS entry policy. If `source(none)` disables automatic detection, require explicit source includes for every package, app, and external component source that owns utilities. Use `@source not inline` for known false positives instead of relying on accidental absence.
+8. Keep `@source inline()` bounded, named, and close to the CSS entry policy. If `source(none)` disables automatic detection, require explicit path `@source` includes for every package, app, and external component source that owns utilities. Use `@source not inline()` for known false-positive class candidates, and path `@source not` for excluded scan locations, instead of relying on accidental absence.
 9. Use inline style plus a CSS variable bridge for unbounded runtime values from databases, APIs, tenants, CMS content, or user input. Do not try to mint Tailwind class names from unbounded values.
 10. Treat arbitrary values as escape hatches. Allow them for one-off asset alignment, complex grid templates, complex calculations, local CSS variable assignment, or values that cannot be expressed with regular utilities.
 11. Reject arbitrary raw colors in component markup, arbitrary spacing that approximates existing scale values, arbitrary container widths, arbitrary radius or shadow used as a hidden token, and repeated arbitrary values. Repeated values must be promoted to a semantic design token or component variant.
@@ -106,7 +108,7 @@ Preserve Tailwind static class detection, design tokens, bounded variants, respo
 - Dynamic visual state must be represented by exactly one of: static map entry, variant helper entry, explicit safelist entry, or CSS variable bridge.
 - Status, tone, intent, size, density, and column props are closed sets until proven otherwise. Model them as finite typed variants, not string fragments.
 - Production CSS is the contract. If a class only exists after runtime string construction, assume production CSS may omit it.
-- `@source inline`, `@source not inline`, and `source(none)` are part of the production CSS generation contract. Review them as carefully as code that uses utilities.
+- Path `@source`, path `@source not`, candidate `@source inline()`, candidate `@source not inline()`, and `source(none)` are part of the production CSS generation contract. Review them as carefully as code that uses utilities.
 
 <!-- mustflow-section: token-policy -->
 ## Token Policy
@@ -130,7 +132,8 @@ Reject the change when:
 - Component-scoped `@apply` or `@variant` relies on Tailwind globals without the needed `@reference` boundary.
 - A public component exposes unconstrained Tailwind class fragments.
 - A safelist covers broad palettes, broad numeric ranges, or unknown runtime values.
-- `@source inline` covers broad palettes, broad numeric ranges, or unknown runtime values.
+- `@source inline()` covers broad palettes, broad numeric ranges, or unknown runtime values.
+- Tailwind v4 is recommended while the project still promises browsers below the v4 floor such as Safari 16.4, Chrome 111, or Firefox 128.
 - `source(none)` is used without explicit source includes for all utility-owning files.
 - `space-*` is used where wrapped or reordered children require `gap`.
 - Conflicting utilities are present on the same element.

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.typescript-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: typescript-code-change
-description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, compiler-version behavior, TypeScript 6-to-7 migration surfaces, native preview tooling, type safety, or TypeScript tests are created or changed.
+description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, compiler-version behavior, TypeScript 6-to-7 migration surfaces, TypeScript 7 RC or nightly tooling, type safety, or TypeScript tests are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,7 +35,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 
 - `.ts`, `.tsx`, `.mts`, `.cts`, `*.d.ts`, `tsconfig*.json`, package entry metadata, exports, declarations, runtime validators, or TypeScript tests change.
 - The task touches module resolution, ESM/CJS interop, public package API, path aliases, generated declarations, or strict type errors.
-- The task touches TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 native preview comparison, `@typescript/native-preview`, `tsgo`, compiler API use, declaration emit comparison, or editor language-service behavior.
+- The task touches TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 RC comparison, TypeScript 7 nightly comparison, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API use, declaration emit comparison, or editor language-service behavior.
 - The task touches external inputs such as JSON, HTTP responses, environment variables, config files, form data, URL params, local storage, message events, queue payloads, or user-provided objects.
 - A framework component written in TypeScript changes its props, events, routes, loader data, or exported types.
 
@@ -52,7 +52,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - Relevant `package.json`, `tsconfig*.json`, lockfile, build config, test config, and package entry files.
 - Existing source entrypoints, public exports, declaration files, validators, schemas, type tests, and nearby tests.
 - The target runtime and module system: Node, browser, worker, Bun, edge, ESM, CJS, or mixed boundary.
-- TypeScript compiler track and tooling entrypoint when relevant: `typescript` with `tsc`, a TypeScript 6 transition release, `@typescript/native-preview` with `tsgo`, framework typecheck wrappers, editor extension settings, and any compiler API consumers.
+- TypeScript compiler track and tooling entrypoint when relevant: TS6 stable API track through `@typescript/typescript6` and `tsc6`, TS7 RC compiler track through `typescript@rc` and `tsc`, TS7 nightly track through `@typescript/native-preview` and `tsgo`, future TS7 stable track through the stable `typescript` package, framework typecheck wrappers, editor extension settings, and any compiler API consumers.
 - Package API metadata when relevant: `type`, `main`, `module`, `browser`, `exports`, `types`, `typings`, `typesVersions`, `files`, `bin`, `sideEffects`, and documented import paths.
 - Existing verification intents from the repository command contract.
 
@@ -72,7 +72,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - Keep public runtime exports and declaration exports aligned.
 - Add focused tests or type tests only when they protect the changed contract.
 - Use existing schema validators or narrowly scoped type guards and assertion functions for external input boundaries.
-- Compare TypeScript 6 `tsc` and TypeScript 7 native preview `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports both.
+- Compare TS6 `tsc6`, TS7 RC `tsc`, and optionally TS7 nightly `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports those tracks.
 - Do not weaken compiler, lint, module, package, or test boundaries to make the task appear complete.
 
 <!-- mustflow-section: procedure -->
@@ -95,10 +95,15 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 15. 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.
 16. 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.
 17. 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.
-18. For TypeScript 7 native preview work, keep `typescript` and `@typescript/native-preview` separate in dependency, script, editor, and verification surfaces. `tsgo` can compare compiler behavior, but it is not a drop-in promise for compiler API users, language-service plugins, custom transformers, or framework wrappers unless those surfaces are proven compatible.
-19. When comparing `tsc` and `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.
-20. Do not treat faster native preview results as sufficient verification. Keep existing `tsc` or framework typecheck as the compatibility baseline until repository policy explicitly adopts the native compiler path.
-21. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
+18. 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.
+19. 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.
+20. 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.
+21. 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.
+22. 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
@@ -120,7 +125,7 @@ Rejected by default:
 - Implementation `@ts-ignore`.
 - Compiler setting downgrades such as disabling strictness, null checking, indexed access safety, or declaration checking to make the patch pass.
 - Treating TypeScript 6 deprecation suppression as a long-term fix.
-- Replacing stable `tsc` verification with `tsgo` preview verification without an explicit repository policy and compatibility evidence.
+- Replacing stable `tsc`, TS6 `tsc6`, or framework verification with TS7 RC or nightly verification without an explicit repository policy and compatibility evidence.
 
 <!-- mustflow-section: public-api-policy -->
 ## Public API Policy
@@ -148,8 +153,8 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Package entry metadata changes without checking runtime entry, type entry, declaration output, and supported resolver modes.
 - `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.
-- Native preview output differences are accepted as harmless without classification.
-- Compiler API, transformer, language-service, or framework typecheck surfaces are moved to TypeScript 7 native preview without compatibility proof.
+- TS7 RC or nightly output differences are accepted as harmless without classification.
+- Compiler API, transformer, language-service, or framework typecheck surfaces are moved off the TS6 API track without compatibility proof.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -159,7 +164,7 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Runtime exports, type exports, and declaration output agree.
 - Assertions are narrow, justified, and contained.
 - Any public API or module-system risk is reported.
-- TypeScript 6/7 migration, native preview, and compiler-entrypoint risks are classified when relevant.
+- TypeScript 6/7 migration, RC, nightly, stable, and compiler-entrypoint risks are classified when relevant.
 - No type-checking or test guard was weakened without an explicit user request and risk report.
 
 <!-- mustflow-section: verification -->
@@ -176,7 +181,7 @@ Use configured oneshot command intents when available:
 
 If a package API changes, include the configured release or package-surface verification when available.
 
-Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, latest supported TypeScript version, TypeScript 6/7 comparison, native preview comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
+Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, latest supported TypeScript version, TS6/TS7 RC comparison, optional TS7 nightly comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -185,8 +190,8 @@ Report whether configured verification exists for declaration output, package ar
 - If external input has no validation pattern, add a narrow validator/guard/assertion or report the missing boundary instead of casting.
 - If module resolution is unclear, inspect the package and compiler configuration before changing imports.
 - If generated declaration output cannot be inspected, report the package API risk and the missing verification intent.
-- If TypeScript 7 native preview disagrees with stable TypeScript, keep stable TypeScript as the compatibility baseline, classify the difference, and report whether it is a project bug, compiler-preview bug, unsupported feature, or expected declaration/order drift.
-- If a framework, plugin, transformer, or compiler API consumer depends on the JavaScript compiler implementation, do not migrate it to native preview unless the dependency explicitly supports that path.
+- If TS7 RC or nightly disagrees with the repository's TS6 or stable baseline, keep the baseline as the compatibility path, classify the difference, and report whether it is a project bug, compiler bug, unsupported feature, or expected declaration/order drift.
+- If a framework, plugin, transformer, or compiler API consumer depends on the JavaScript compiler implementation, do not move it off the TS6 API track unless the dependency explicitly supports that path.
 - If verification commands are missing, report the missing intents instead of inventing package-manager commands.
 
 <!-- mustflow-section: output-format -->
@@ -196,7 +201,7 @@ Report whether configured verification exists for declaration output, package ar
 - Files changed
 - Type and module safety notes
 - Public API or declaration impact
-- Compiler-version or native-preview notes
+- Compiler-version, RC, nightly, or API-track notes
 - Command intents run
 - Skipped checks and reasons
 - Remaining TypeScript risk

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.unocss-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: unocss-code-change
@@ -56,7 +56,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 
 - Confirm extraction targets before adding utilities or moving class maps.
 - Identify whether the project uses default pipeline extraction, explicit `content.pipeline.include`, `@unocss-include`, safelist, or custom extractors.
-- Identify whether the project uses the classic preset stack, `presetWind4`, theme compatibility tokens, shortcut layers, variant groups, icons, attributify, directives, or framework-specific plugin order.
+- Identify whether the project uses the classic preset stack, `presetWind4`, theme compatibility tokens, shortcut layers, variant groups, icons, attributify, directives, reset packages, compatibility presets, or framework-specific plugin order.
 - Identify whether shortcuts, rules, variants, or safelist entries are design-system vocabulary or one-off hiding places.
 - If the config is unclear, do not introduce attributify, custom rules, custom variants, broad shortcuts, or broad safelists. Use plain `class` utilities with complete static strings.
 
@@ -82,7 +82,16 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 6. Keep safelists small, finite, named, and bounded by approved token lists and maximum generated count. Treat feature-local safelists over 50 classes, shared safelists over 200 classes, or total safelists over 300 classes as design/extraction failures unless explicitly justified.
 7. Do not generate safelists from whole theme objects, full color palettes, all shades, all spacing values, all breakpoints, or broad property and variant multiplication.
 8. Use token allowlists before writing shortcuts, rules, variants, or safelists. Do not use every theme key as an allowed product value.
-9. For Wind4 migration, verify preset choice, theme token migration, preflight ownership, variant behavior, and compatibility with existing Tailwind-like class vocabulary before changing utilities at call sites.
+9. For Wind4 migration, verify preset choice, theme token migration, reset ownership, variant behavior, and compatibility with existing Tailwind-like class vocabulary before changing utilities at call sites. Use a token rename matrix instead of vague "theme review":
+   - `fontFamily` -> `font`;
+   - `borderRadius` -> `radius`;
+   - `easing` -> `ease`;
+   - `breakpoints` -> `breakpoint`;
+   - `verticalBreakpoints` -> `verticalBreakpoint`;
+   - `boxShadow` -> `shadow`;
+   - size scale families that now share spacing -> `spacing`;
+   - `container.maxWidth` -> `containers.maxWidth`.
+   Also check duplicate resets from existing `@unocss/reset` or `normalize.css`, remove `presetRemToPx` when Wind4 covers the behavior internally, and do not combine `presetLegacyCompat` with Wind4 OKLCH color behavior.
 10. Use `extendTheme` or equivalent merge hooks when preserving existing theme tokens matters. Do not replace the whole theme object if the local config expects extension semantics.
 11. Add shortcuts only for repeated product primitives. Prefer static shortcuts when all combinations are known. Dynamic shortcuts must be anchored, token allowlisted, and free of broad catch-all groups.
 12. Do not use shortcuts as one-off wrappers for long class strings in a single screen.
@@ -131,7 +140,9 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 <!-- mustflow-section: preset-icon-shadow-policy -->
 ## Preset, Icon, And Shadow DOM Policy
 
-- Wind4 migration must preserve theme tokens, preflight expectations, variant semantics, and generated CSS size before call-site cleanup.
+- Wind4 migration must preserve theme tokens, reset ownership, variant semantics, generated CSS size, and color behavior before call-site cleanup.
+- Wind4 includes Tailwind 4-style reset behavior. Existing `@unocss/reset` or `normalize.css` imports need duplicate-reset review.
+- Wind4 migration should remove obsolete `presetRemToPx` usage and avoid `presetLegacyCompat` when OKLCH color compatibility matters.
 - Icon utilities are production assets. Verify the chosen icon collections, loader ownership, package footprint, currentColor inheritance, accessibility label path, and whether dynamic icon names require a finite safelist.
 - Shadow DOM and web component styles need an explicit injection owner. Do not assume global utility CSS reaches closed or separately injected roots.
 - Framework plugin order is part of extraction. Svelte, Vue, Astro, MDX, transformers, variant-group handling, and attributify can change whether the token exists before UnoCSS scans it.
@@ -158,7 +169,7 @@ Reject the change when:
 - Custom variants accept arbitrary selectors or themes.
 - Blocklist removes utilities without an actionable developer-facing signal.
 - JSX/TSX attributify lacks prefix, transformer, or type support.
-- Wind4 migration replaces theme or preflight behavior without compatibility review.
+- Wind4 migration replaces theme, reset, color, or preflight behavior without compatibility review.
 - Icon utilities accept unbounded runtime icon names.
 - Shadow DOM utility usage has no style injection owner.
 

package/templates/default/locales/en/.mustflow/skills/version-freshness-check/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.version-freshness-check
 locale: en
 canonical: true
-revision: 6
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: version-freshness-check
@@ -35,7 +35,7 @@ Prevent agents from writing stale external version references from memory, while
 - Generated or edited files introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, toolchain versions, setup actions, scaffold commands, install commands, or migration examples.
 - CI workflows, release workflows, Dockerfiles, package metadata, lockfiles, runtime files, framework configuration, README examples, docs, tests, fixtures, or templates mention external versions such as GitHub Actions refs, Node, Bun, Deno, Python, Rust, Tauri, Astro, Next, SvelteKit, Electron, Docker images, package managers, SDKs, plugins, or generators.
 - Python wording mentions current/stable/support status, Python 3.14+ standard-library APIs, runtime flags, changed default behavior, security defaults, or examples that depend on `requires-python`.
-- TypeScript wording mentions current/stable/beta/native preview status for TypeScript 6, TypeScript 7, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
+- TypeScript wording mentions current/stable/RC/nightly status for TypeScript 6, TypeScript 7, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
 - Go wording mentions current/stable/support status, Go release numbers, `go.mod` language version behavior, `toolchain` behavior, standard-library APIs, `GOEXPERIMENT`, runtime defaults, container behavior, JSON experiments, or examples that depend on a specific Go version.
 - Rust wording mentions current/stable/support status, Rust release numbers, `rust-version`, edition behavior, `rust-toolchain`, Cargo resolver or workspace behavior, standard-library APIs, compiler lints, target behavior, release profiles, or examples that depend on a specific Rust version.
 - HTTP delivery wording mentions current support, baseline status, default behavior, standard status, or compatibility for zstd content coding, compression dictionary transport, SSE/EventSource, WebTransport, WebSocket fallback, HTTP/2, HTTP/3, QUIC, CDN behavior, proxy buffering, or browser transport APIs.
@@ -96,12 +96,12 @@ Prevent agents from writing stale external version references from memory, while
 12. For framework and runtime majors such as Astro, Tauri, Electron, Next, SvelteKit, Node, Bun, Deno, Python, Rust, or Java, check migration notes, config schema, plugin and adapter compatibility, generated files, security model, deployment target, and rollback path before recommending a major change.
 13. For Python standard-library or runtime-behavior claims, refresh official Python documentation before writing durable wording. Check `requires-python`, CI/runtime matrices, and container images before using or recommending version-gated features such as Python 3.14+ `map(strict=True)`, `functools.Placeholder`, `heapq` max-heap helpers, import-timing flag behavior, or changed security defaults.
 14. For Python examples that use newer standard-library APIs, either keep the example behind an explicit runtime floor or provide a supported fallback. Do not call a Python 3.14-only API a general Python best practice when the repository declares lower support.
-15. For TypeScript 6 and 7 claims, refresh official TypeScript sources before writing durable wording. Treat TypeScript 6 stable releases, TypeScript 7 native preview or beta packages, `@typescript/native-preview`, `tsgo`, and future stable `typescript` package behavior as distinct tracks. Do not call native preview output "latest stable TypeScript" just because it is newer.
-16. For TypeScript native-preview examples, make the selected track explicit: side-by-side comparison, beta testing, editor preview, or repository adoption. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive.
+15. For TypeScript 6 and 7 claims, refresh official TypeScript sources before writing durable wording. Treat TS6 stable API track (`@typescript/typescript6`, `tsc6`), TS7 RC compiler track (`typescript@rc`, `tsc`), TS7 nightly track (`@typescript/native-preview`, `tsgo`), and future TS7 stable `typescript` behavior as distinct tracks. Do not call RC or nightly output "latest stable TypeScript" just because it is newer.
+16. For TypeScript examples, make the selected track explicit: TS6 API compatibility, TS7 RC compiler verification, TS7 nightly comparison, editor preview, or repository adoption. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive and keep API consumers on the TS6 API track until support is explicit.
 17. For Go release, toolchain, standard-library, runtime, or experiment claims, refresh official Go release notes or package documentation before writing durable wording. Check the repository's `go` directive, `toolchain` directive, CI/runtime matrix, and container target before using or recommending version-gated features such as expression operands to `new`, `errors.AsType`, `sync.WaitGroup.Go`, `testing/synctest`, `testing.B.Loop`, `os.Root`, `os.OpenInRoot`, `omitzero`, `go.mod` `tool`, `ReverseProxy.Rewrite`, container-aware `GOMAXPROCS`, goroutine leak profiles, `encoding/json/v2`, or `GOEXPERIMENT` APIs.
 18. For Go examples that use newer standard-library APIs or runtime defaults, either keep the example behind an explicit Go version floor or provide a supported fallback. Do not call an experimental `GOEXPERIMENT` feature or a newer `go` directive behavior a general Go best practice when the repository declares lower support.
 19. For Rust release, toolchain, standard-library, Cargo, edition, lint, target, or MSRV claims, refresh official Rust release notes, standard-library docs, the Cargo Book, Rust Reference, or rustc book before writing durable wording. Check `rust-version`, edition, `rust-toolchain.toml`, CI toolchain matrix, target triples, docs.rs metadata, and crate publish policy before using or recommending version-gated features such as let chains, match `if let` guards, `cfg_select!`, `assert_matches!`, `core::range`, `Vec::push_mut`, `HashMap::get_disjoint_mut`, `Option::take_if`, `LazyLock`, `OnceLock`, `workspace.lints`, `resolver = "2"`, Rust 2024 `unsafe_op_in_unsafe_fn`, or release-profile defaults.
-20. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Do not call a Rust 1.95+ or 1.96+ API a general Rust best practice when the repository declares a lower MSRV, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
+20. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Use an API-by-API MSRV ledger for features such as `cfg_select!`, match `if let` guards, `core::range` items, `Vec::push_mut`, `assert_matches!`, and `debug_assert_matches!`; do not collapse them into a single "latest Rust" bucket, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
 21. For HTTP standards, browser APIs, proxy defaults, CDN defaults, and transport support claims, prefer official RFCs, standards bodies, MDN or browser vendor docs, and vendor-owned proxy/CDN documentation. Keep WebTransport, compression dictionary transport, zstd content coding, SSE/EventSource, HTTP/2, HTTP/3, QUIC, and proxy-buffering claims track-specific and dated when support is changing.
 22. For HTTP delivery examples that depend on newer or unevenly supported behavior, require feature detection, fallback behavior, or explicit deployment constraints. Do not present WebTransport, dictionary compression, or zstd negotiation as a universal default when the project still needs browsers, proxies, CDNs, or networks that may not support it.
 23. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
@@ -116,9 +116,9 @@ Prevent agents from writing stale external version references from memory, while
 - Repository-pinned versions are preserved unless the task, policy, and compatibility classification support changing them.
 - Major or migration-required changes are either explicitly approved, deferred with a recommendation, or left unchanged with the risk reported.
 - Python standard-library examples and runtime-default claims match the declared Python support matrix or name the required runtime floor.
-- TypeScript 6 stable, TypeScript 7 beta/native-preview, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
+- TypeScript 6 stable API, TypeScript 7 RC compiler, TypeScript 7 nightly, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
 - Go release, `go.mod` language version, standard-library API, runtime-default, and `GOEXPERIMENT` claims match the declared Go support matrix or name the required runtime floor.
-- Rust release, `rust-version`, edition, standard-library API, Cargo resolver, lint-default, target, and nightly/stable claims match the declared Rust support matrix or name the required runtime floor.
+- Rust release, `rust-version`, edition, standard-library API, Cargo resolver, lint-default, target, and nightly/stable claims match the declared Rust support matrix or name the required API-specific runtime floor.
 - HTTP standard, browser-support, proxy-default, CDN-default, and transport-support claims are not written from stale memory and keep feature detection or fallback boundaries explicit where support varies.
 - Docs and examples do not make unverifiable current-version claims.
 
@@ -144,7 +144,7 @@ Choose the narrowest configured intent that proves the changed versioned surface
 - If official sources conflict, prefer the source that owns the artifact being referenced and report the conflict.
 - If a freshness check requires network, credentials, or a connector that is not available, report the boundary and avoid current-version claims.
 - If a proposed major or migration-required version is better for greenfield work but risky for the existing project, present both choices and ask before changing the project.
-- If TypeScript 7 native preview freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from preview comparison.
+- If TypeScript 7 RC, nightly, or stable freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from comparison-only checks.
 - If Go release or experiment freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, `go` directive adoption, CI support, and `GOEXPERIMENT` adoption separate.
 - If Rust release or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, MSRV adoption, edition adoption, CI support, target support, and nightly or unstable features separate.
 - If HTTP delivery support changes during the task, update wording to a dated or track-specific claim and keep standards, browser support, CDN behavior, proxy defaults, and repository adoption separate.

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.74.1"
+version = "2.74.3"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -93,6 +93,7 @@ creates = [
   ".mustflow/skills/rust-code-change/SKILL.md",
   ".mustflow/skills/runtime-target-selection/SKILL.md",
   ".mustflow/skills/structure-first-engineering/SKILL.md",
+  ".mustflow/skills/support-surface-advisor/SKILL.md",
   ".mustflow/skills/svelte-code-change/SKILL.md",
   ".mustflow/skills/tailwind-code-change/SKILL.md",
   ".mustflow/skills/tauri-code-change/SKILL.md",
@@ -331,6 +332,7 @@ minimal = [
   "task-instruction-authoring",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",
@@ -472,6 +474,7 @@ patterns = [
   "strategy-pattern",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",
@@ -631,6 +634,7 @@ oss = [
   "strategy-pattern",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",
@@ -775,6 +779,7 @@ team = [
   "strategy-pattern",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",
@@ -919,6 +924,7 @@ product = [
   "strategy-pattern",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",
@@ -1078,6 +1084,7 @@ library = [
   "strategy-pattern",
   "structure-discovery-gate",
   "structure-first-engineering",
+  "support-surface-advisor",
   "test-design-guard",
   "test-maintenance",
   "vertical-slice-tdd",