mustflow 2.115.5 → 2.115.9

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

@@ -0,0 +1,291 @@
+---
+mustflow_doc: skill.deno-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: deno-code-change
+description: Apply this skill when Deno runtime code, deno.json, permissions, deno.lock, JSR or npm imports, tasks, tests, Deno.serve, Workers, WebSockets, compile or desktop output, Node compatibility, Deno Deploy, or Deno-related CI and release behavior are created, changed, reviewed, migrated, or upgraded.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.deno-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Deno Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Deno runtime, permission, module graph, package, type-check, task, test, server, Worker,
+compiled artifact, deployment, and release contracts while making focused changes. Do not treat
+Web-standard APIs, Node compatibility, a successful local run, or a passing CI job as proof that
+the same code has identical permissions, native dependencies, runtime versions, state, and
+deployment behavior everywhere.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Deno TypeScript or JavaScript, `deno.json`, `deno.jsonc`, `deno.lock`, import maps,
+  workspaces, tasks, permissions, lint, formatting, tests, coverage, compile, bundle, desktop, or
+  package metadata changes.
+- `Deno.serve`, HTTP, WebSocket, Worker, subprocess, FFI, filesystem, environment, network,
+  cancellation, async concurrency, KV, Cache API, or storage behavior changes.
+- JSR, `npm:` imports, npm lifecycle scripts, Node compatibility, native addons, package-manager
+  migration, lockfile import, or Deno-backed Node shims change.
+- Deno Deploy, deployment config, build and runtime contexts, preview or production timelines,
+  migrations, environment variables, regions, scaling, or CI/CD changes.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is ordinary TypeScript or JavaScript with no Deno runtime, package, permission, task,
+  test, compile, or deployment boundary.
+- Node, Bun, Cloudflare Workers, another edge runtime, or a framework-owned adapter is the only
+  runtime changed; use its matching skill.
+- The task asks only for the current Deno version; use source-freshness guidance unless code or
+  durable documentation changes too.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Deno version sources, supported runtime range, `deno.json`, lockfile, import map, workspace,
+  task definitions, package-manager files, environment policy, CI matrix, and deployment target.
+- Module ledger: local, JSR, npm, URL, Node built-in, generated, vendored, and dynamic imports;
+  lock and cache policy; lifecycle scripts; native dependencies; and runtime adapter paths.
+- Permission ledger: read, write, net, env, run, ffi, import, system, prompt, permission sets,
+  Worker inheritance, broker usage, audit evidence, OS isolation, and untrusted-code boundary.
+- Execution ledger: run versus check, task graph, test selection, Worker ownership, server isolate
+  count, cancellation, queue bounds, storage ownership, compile identity, and shutdown behavior.
+- Deploy ledger when relevant: Classic versus current platform, builder and runtime versions,
+  source versus dashboard configuration, contexts, timelines, persistent state, migrations,
+  regions, secrets, preview/production smoke, and rollback.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read repository-pinned Deno and deployment evidence before using recent APIs, flags, task fields,
+  permission behavior, Node compatibility, desktop features, or Deploy behavior.
+- Refresh official Deno, JSR, and Deploy sources before preserving exact latest-version, runtime,
+  region, support, deprecation, migration, or shutdown claims. Treat the 2026-07-11 source material
+  as a snapshot, not a permanent current-state contract.
+- Separate stable runtime status from feature status. Desktop packaging, Worker permission options,
+  permission brokers, flags, and deployment behavior can have different stability and availability.
+- Determine whether the target is a local CLI, server, library, compiled binary, desktop app,
+  self-hosted service, or Deno Deploy app before changing configuration or permissions.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Make focused Deno source, config, lockfile, tests, docs, package, CI, compile, and Deploy changes
+  required by the task.
+- Add explicit permission, module, type-check, test, cancellation, storage, migration, and
+  deployment verification when the changed behavior needs it.
+- Preserve repository-pinned runtime, frozen install, lockfile, and compatibility paths unless the
+  task explicitly accepts a migration.
+- Do not add `-A`, broad `--allow-*`, unrestricted lifecycle scripts, floating runtime tags,
+  implicit network imports, native execution, or dashboard-only production changes as shortcuts.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. **Classify runtime, feature, and deployment tracks.**
+   - Record the repository-pinned Deno version, proposed target, feature stability, CI version,
+     compile target, and deployment builder/runtime separately.
+   - Recheck every dated status before use. In the 2026-07-11 snapshot, Deno 2.9 behavior and the
+     announced 2026-07-20 Deploy Classic shutdown were current source facts; neither is an
+     undated future guarantee.
+   - Treat a Node compatibility version as a compatibility target, not proof that Deno is running
+     a Node binary or implements every Node detail.
+2. **Separate execution from type checking and output.**
+   - Deno can execute TypeScript without proving the full type contract. Keep `deno check`, editor
+     diagnostics, tests, declaration output, framework checks, and runtime execution as distinct
+     evidence surfaces.
+   - Check compiler options, JSX, imports, DOM/library types, npm package types, generated types,
+     and package exports against the declared Deno track.
+   - Do not infer runtime globals from successful Node ambient type checking. Import Node globals
+     such as `Buffer` from their explicit `node:` modules when runtime availability matters.
+   - For CommonJS interop, inspect extension, nearest package `type`, conditional exports, selected
+     entry, and the entire ESM graph. A synchronous `require()` boundary cannot consume an ESM
+     graph containing top-level await merely because Deno supports other ESM-from-CJS cases.
+   - Do not infer command authority from `deno.json` tasks. Map project commands to configured
+     mustflow intents.
+3. **Own the module graph and dependency supply chain.**
+   - Distinguish static and analyzable imports from runtime-computed imports and ordinary network
+     access. Permission denial alone does not prove the initial module graph cannot load code.
+   - Use lockfiles, frozen or cached-only policy, approved import hosts, vendoring, and exact
+     package-manager ownership where the repository contract requires reproducibility.
+   - Keep JSR, `npm:`, npm aliases, import maps, `.npmrc`, lockfiles, workspace catalogs, and
+     runtime adapter subpaths synchronized. Do not mix independently pinned Hono core and Deno
+     adapter versions.
+   - Treat `nodeModulesDir` and the node-modules linker as installation architecture, not local
+     convenience. Choose none, auto, or manual from real disk-layout, framework, lifecycle-script,
+     package-manager, and native-addon needs; use hoisting only for a proven compatibility boundary.
+   - Review npm lifecycle scripts and native addons explicitly. A package resolving successfully
+     does not prove its install script ran. Native addons can require a local `node_modules`,
+     narrowly approved install scripts, runtime FFI permission, public Node-API compatibility, and
+     an artifact built for the target OS and architecture.
+   - Inspect conditional `exports` and actual selected entries when Node and Deno differ. Prefer
+     explicit `node:` built-in specifiers over bare names whose resolution can be shadowed by
+     imports or package dependencies.
+   - Treat ignored published `file:` or `link:` dependencies and undeclared hoisted dependencies
+     as package defects. Do not hide them permanently by switching the whole workspace to hoisted layout.
+   - Determine the configuration owner from the command working directory and explicit `--config`
+     contract, not from the source entrypoint path. Keep local tooling, CI, IDE, and deployment on
+     the same intended root.
+   - Distinguish inline `imports` from standard external import maps, exact aliases from slash
+     prefixes, and narrow migration scopes from global dependency policy. Do not use aliases to
+     bypass workspace package `name` and `exports` boundaries.
+   - Keep resolver policy such as lock, linker, node-modules mode, minimum dependency age, script
+     approval, links, and vendoring at the workspace owner. Treat catalogs as npm version policy,
+     not import aliases, and avoid competing catalog owners.
+   - Review a Deno lockfile as additive resolution history. Presence does not prove current reachability;
+     unexpected additions still require supply-chain review, and routine feature changes should
+     not delete and recreate the lockfile merely to remove old entries.
+4. **Review permissions as process-to-OS policy.**
+   - Separate module import permission from runtime file, network, environment, subprocess, FFI,
+     and system access. Record allow and deny scopes, host/port semantics, paths, and prompt policy.
+   - Treat dependencies in one isolate as sharing the application's granted permissions. Deno
+     permissions are not per-package isolation.
+   - Treat Worker permissions as inherited unless the supported runtime and explicit Worker
+     configuration prove they are reduced. A Worker thread alone is not a sandbox.
+   - Treat `--allow-run`, FFI, native addons, writable executable paths, dynamic-loader variables,
+     and permission brokers as escape or authority boundaries requiring OS-level isolation.
+   - Use non-interactive explicit policy in CI and production. Permission prompts and runtime
+     revocation are not durable deployment access control.
+5. **Review tasks, tests, and caching.**
+   - Keep task inputs, outputs, environment variables, dependencies, platform, and external-state
+     assumptions explicit before enabling cached task results.
+   - Do not cache work that depends on undeclared time, network, database, secret, or service state.
+   - Use changed, related, retry, repeat, shard, snapshot, leak-trace, coverage, and concurrency
+     features only when supported by the pinned runtime and repository test contract.
+   - Preserve flaky-test reporting. A retry that later passes is evidence, not a clean first-pass run.
+   - Decide whether type checking belongs to the complete `deno check` graph or the test run. Use a
+     no-check test path only after every production, test, CLI, generated, and conditional entrypoint
+     is covered by the separate check.
+   - Treat changed, related, filtered, and sharded tests as fast feedback, not completeness proof.
+     Dynamic imports, environment, databases, fixtures, shared schemas, and uneven large test files
+     can escape static selection or produce unbalanced shards.
+   - Isolate parallel tests by port, temporary directory, database or KV namespace, account, cache
+     key, and coverage directory. Preserve shuffle seeds and report retries as flakiness evidence.
+   - Refresh sanitizer defaults for the pinned Deno version. In the 2026-07-11 source snapshot,
+     resource and operation sanitizers were no longer safe to assume enabled by default; enable
+     explicit resource, operation, exit, timeout, or leak-trace checks where lifecycle correctness
+     depends on them.
+   - Per-test permission configuration can only narrow the CLI-granted ceiling; it cannot create
+     authority the test process never received. Keep permission-free library tests separate from
+     privileged adapters instead of granting the suite all permissions.
+   - Keep raw coverage collection separate from report generation and shard outputs separate until
+     merge. Review line, branch, and function gaps rather than optimizing one aggregate percentage.
+6. **Review HTTP, WebSocket, Worker, and async behavior.**
+   - Measure CPU-bound parsing, serialization, compression, regex, crypto, and transforms separately
+     from async I/O. `async` does not move CPU work off the isolate.
+   - Use bounded Worker pools and bounded queues for CPU work. Account for structured-clone cost,
+     transferable ownership, Worker permission inheritance, graceful shutdown, and idempotent side effects.
+   - Treat parallel server isolates as independent memory. Keep exact sessions, locks, rate limits,
+     WebSocket rooms, and counters in an appropriate shared external store.
+   - Propagate `AbortSignal` through supported operations. Promise timeout only stops waiting; it
+     does not cancel the original work.
+   - Bound `Promise.all`-style concurrency by connection pools, rate limits, memory, descriptors,
+     and queue capacity.
+   - Preserve stream backpressure end to end. Avoid unbounded buffering, unnecessary string/byte
+     conversion, and per-request custom HTTP clients; reuse owned clients and close them at shutdown.
+   - Cancel or consume unused response bodies, and combine client disconnect with internal deadline
+     signals when downstream APIs support cancellation.
+   - Batch Deno KV reads and atomic writes around real access patterns, and measure FFI dispatch
+     overhead before marking short native calls nonblocking.
+   - Verify automatic compression, HTTP/2, WebSocket upgrade, request-abort semantics, proxy
+     buffering, backpressure, resource closure, and graceful shutdown on the pinned runtime and
+     real deployment path.
+7. **Review compile and desktop artifacts.**
+   - Treat app name, storage directories, included files, permissions, target OS/architecture,
+     WebView versus embedded browser engine, signing, installer format, update behavior, and
+     persistent application identity as public contracts.
+   - Do not assume cross-built desktop output renders identically across system WebViews. Keep
+     renderer choice, asset paths, HMR/dev behavior, binary size, and target smoke tests explicit.
+   - Ensure compiled local storage, caches, or KV identity cannot collide across unrelated apps.
+8. **Review Deno Deploy as a separate platform contract.**
+   - Identify Classic versus the current Deploy platform before applying any guidance. Do not
+     assume projects, KV data, environment variables, domains, tokens, preview URLs, or rollback
+     state migrate automatically.
+   - Separate builder, development, preview, production, and runtime contexts. Verify exact runtime
+     and command availability instead of assuming local or moving CI versions match Deploy.
+   - Treat local filesystem and module memory as instance-local and replaceable. Keep durable
+     correctness state, distributed locks, sessions, rooms, and migration coordination external.
+   - Determine whether source configuration replaces dashboard configuration. Keep the owning
+     source explicit and report dashboard-only fields that cannot be reproduced in source.
+   - Make pre-deploy migrations idempotent and locked. A preview warmup does not prove production
+     context, production data, or the production URL.
+   - Verify production after revision activation and retain a tested rollback route.
+9. **Review JSR publication and downstream consumers.**
+   - Keep package manager and JSR/npm compatibility representation explicit. Test Deno source
+     consumption and generated Node/npm JavaScript and declaration consumption separately.
+   - Use explicit public return and property types where JSR slow-type rules or declaration
+     generation require them.
+   - Treat publication as immutable. Verify version, OIDC/provenance, exact registry visibility,
+     bounded propagation retry, consumer installation, and tag order before completion.
+10. **Verify the real contract.**
+    - Cover type check, tests, permissions, frozen dependency resolution, server cancellation,
+      repeated lifecycle, compiled output, target architecture, and deployment smoke according to
+      the changed surface.
+    - Report missing configured intents rather than running raw servers, deployment commands,
+      installers, network fetches, or publishing commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Runtime, type-check, module graph, permissions, tests, tasks, Workers, storage, compile output,
+  deployment, and publication each have an explicit owner and evidence boundary.
+- Local Deno, Node compatibility, CI, builder, and Deploy runtime versions are not collapsed into
+  one generic Deno environment.
+- Permission grants do not masquerade as package isolation, hostile-code sandboxing, resource
+  limits, or deployment authorization.
+- State and migrations remain correct across isolates, instances, contexts, regions, retries, and rollback.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot intents that cover the changed scope:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the Deno or Deploy track is unclear, preserve existing runtime and deployment behavior and
+  report the missing version or platform evidence.
+- If a dependency requires an npm lifecycle script, native addon, Node binary, or unsupported
+  compatibility behavior, isolate and test that boundary instead of enabling all scripts globally.
+- If permission reduction breaks startup, map the exact access from audit evidence; do not replace
+  the policy with `-A`.
+- If a Deploy migration lacks data, domain, secret, smoke, or rollback evidence, keep the old path
+  active where still possible and report the migration as incomplete.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Deno runtime, feature, CI, compile, and Deploy tracks
+- Module, package, permission, task, test, Worker, and state owners
+- Compatibility, migration, deployment, and rollback decisions
+- Verification evidence and configured intents run
+- Skipped checks and remaining runtime, permission, package, native, or deployment risk

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: 6
+revision: 7
 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, 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.
+- A TypeScript upgrade touches TypeScript 6 transition deprecations, TS6 JavaScript API compatibility, TypeScript 7 stable compiler adoption, `typescript@next` development comparison, native-preview comparison, `@typescript/typescript6`, `tsc6`, `typescript`, `@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
@@ -101,8 +101,14 @@ 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, dev-server, browser-test, and test-runner upgrades as behavior changes when their output, config schema, plugin API, CLI flags, file-serving policy, privileged UI gates, 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: 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.
+14. For TypeScript upgrades, refresh official release and registry evidence before classifying the
+    compiler track. In the snapshot checked on 2026-07-11, TS7 stable used `typescript` and
+    `tsc`, TS6 JavaScript API compatibility used `@typescript/typescript6` and `tsc6`,
+    development builds used `typescript@next`, native preview used
+    `@typescript/native-preview` and `tsgo`, and `typescript@rc` was historical prerelease
+    evidence. Reclassify those tags when current registry metadata changes; never treat development
+    or preview packages as stable replacements merely because they are newer.
+15. For TypeScript 6, review deprecations as TypeScript 7 removal risks. For TS7 stable, review compiler parity, declaration emit, watch/incremental, generated-output, and framework wrapper risks. Use `typescript@next` or `tsgo` only as optional comparison paths. Keep compiler API, transformer, ESLint, language-service plugin, and framework wrapper consumers on the TS6 API compatibility 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.
@@ -117,7 +123,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 TS6 stable API compatibility, TS7 RC compiler verification, TS7 nightly comparison work, and future TS7 stable adoption.
+- TypeScript compiler-track changes distinguish TS7 stable compiler adoption, TS6 JavaScript API compatibility, `typescript@next` development comparison, native-preview comparison, and historical prerelease evidence.
 - Security fixes are narrow unless the user explicitly accepted a broader modernization.
 - Advisory exploit preconditions are checked against local scripts, config, CI, containers, remote workspaces, and docs before an alert is dismissed as development-only or unreachable.
 - Tests and scanners were not weakened to pass the upgrade.
@@ -148,7 +154,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 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 `typescript@next` or native-preview verification is introduced, keep the repository's adopted stable compiler, TS6 API compatibility, and 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 -->

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.elysia-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: elysia-code-change
@@ -74,7 +74,7 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
 
 1. Read server entry, routes, plugins, schemas, auth, cookies, CORS, error handling, OpenAPI, Eden exports, runtime deployment config, and tests.
 2. Build a route inventory for the changed surface.
-3. Treat route schema as the primary contract for runtime validation, TypeScript inference, OpenAPI, and Eden. Avoid duplicating request and response contracts as separate TypeScript interfaces unless a clear external boundary requires it.
+3. Treat route schemas as the primary contract for runtime validation and Eden inference. For OpenAPI, determine whether the project uses runtime schemas, `fromTypes()`, or both; when both are present, runtime schema takes precedence. Avoid duplicating contracts as unrelated interfaces or generated definitions.
 4. Add or update schemas for every external input and meaningful response status, including non-2xx statuses.
 5. For URL and header inputs, remember that params, query, and headers arrive as HTTP strings:
    - use lower-case header schema keys;
@@ -109,7 +109,7 @@ Preserve Elysia schema-first runtime validation, type inference, plugin, auth, e
    - the official Elysia OpenAPI plugin and its docs UI provider are not the same thing as the raw OpenAPI document;
    - confirm the raw OpenAPI JSON path, UI provider, and access policy before telling SDK consumers where to read the spec;
    - if `fromTypes()` or type generation is used, verify production and bundled builds can still read the required `.d.ts`, `projectRoot`, and `tsconfigPath`;
-   - if Standard Schema is used, verify `mapJsonSchema` or equivalent JSON Schema mapping rather than assuming OpenAPI output is complete;
+   - for file uploads, review runtime file validation and OpenAPI conversion separately. Configure `mapJsonSchema` when a Standard Schema implementation cannot produce the required OpenAPI schema, and independently verify runtime file size, MIME, extension, and magic-number policy where those checks are required;
    - remember `withHeader()` documents response headers; it does not enforce that the runtime sets them.
 18. Review Eden Treaty separately from OpenAPI codegen:
    - export `type App = typeof app` from the server boundary;

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.hono-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: hono-code-change
@@ -83,7 +83,7 @@ Preserve Hono route registration, runtime adapter, middleware ordering, validati
 9. For multipart uploads, large JSON, webhooks, raw-body signatures, and file routes, check parser shape, body limits, runtime limits, storage limits, repeated-field behavior, and raw request cloning before changing handlers.
 10. Preserve typed route, RPC, and SDK inference by exporting the route chain actually used by `hc<AppType>()`, keeping handler responses on typed `c.json(payload, status)` paths, and avoiding broad `Context` handler extraction that drops path, validator, or response types.
 11. Keep runtime validation schema, OpenAPI schema, response schema, generated SDKs, and Hono RPC types from becoming separate truths. Choose one canonical contract and verify drift with tests or snapshots when available.
-12. Do not put Node-only, Bun-only, Cloudflare-only, Deno-only, Lambda-only, static-serving, connection-info, WebSocket, or filesystem APIs in shared route modules. Keep runtime entry files thin and pass plain config or adapter functions into shared app code.
+12. Do not put Node-only, Bun-only, Cloudflare-only, Deno-only, Lambda-only, static-serving, connection-info, WebSocket, or filesystem APIs in shared route modules. Keep runtime entry files thin and pass plain config or adapter functions into shared app code. For Deno or JSR imports, keep the Hono core package, middleware, and runtime adapter subpaths on one compatible version; do not mix independently pinned Hono versions in the same app.
 13. For streaming, SSE, WebSocket, cache, ETag, static file, and SSR or JSX routes, check cancellation, abort handling, backpressure, already-started-response errors, header retention, path traversal, cache key and `Vary`, repeated `Set-Cookie`, and adapter header normalization.
 14. Choose configured verification intents that cover type checks, route tests, auth failure, validation failure, CORS/cookie/header behavior, streaming or WebSocket behavior, OpenAPI or SDK generation, and runtime env mocks when available.
 

package/templates/default/locales/en/.mustflow/skills/instruction-conflict-scope-check/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.instruction-conflict-scope-check
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: instruction-conflict-scope-check
@@ -25,7 +25,7 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Resolve conflicting instructions by narrowing authority, edit scope, command scope, and reporting boundaries before work proceeds.
+Resolve conflicting instructions by separating goal ownership, safety constraints, repository scope, command authority, evidence authority, and preferences before work proceeds.
 
 <!-- mustflow-section: use-when -->
 ## Use When
@@ -47,6 +47,7 @@ Resolve conflicting instructions by narrowing authority, edit scope, command sco
 ## Required Inputs
 
 - The conflicting instruction sources and the exact behavior they appear to require or forbid.
+- The type of each claim: goal, safety constraint, repository scope, command authority, evidence claim, reporting rule, preference, or generated hint.
 - The affected scope: repository root, nested project, file paths, command intents, verification, Git operation, migration, or report.
 - The user's direct request and any newer clarifying message.
 - Relevant command-intent contract entries and nearest `AGENTS.md` files for the affected paths.
@@ -69,19 +70,28 @@ Resolve conflicting instructions by narrowing authority, edit scope, command sco
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. List the conflicting sources in priority order: direct user request, host safety rules, nearest repository instructions, mustflow config, skills, preferences, generated state, and lower-priority docs.
+1. Classify each instruction by authority dimension before comparing priority.
+   - Direct user instructions define the requested goal and newer user clarification supersedes older user intent for the same decision.
+   - Host safety and approval rules constrain how the goal may be executed; they are not optional preferences and cannot be displaced by a user request.
+   - The nearest repository instructions define repository-local edit and workflow scope.
+   - `.mustflow/config/commands.toml` is the sole repository command-authority source.
+   - Current source, tests, schemas, remote state, and configured verification provide evidence; generated summaries and caches are secondary evidence.
+   - Skills guide procedure and preferences supply defaults; neither grants command authority.
 2. Identify the affected action: edit, read, verify, command run, commit, push, delete, migration, background process, browser launch, or final report.
-3. Select the nearest applicable repository root and path scope. If a nested repository is involved, reread that repository's instructions before editing there.
-4. Apply the stricter safe rule when safety, secrets, destructive actions, command permission, or repository boundaries conflict.
-5. Treat preferences as defaults only. Do not let preferences authorize commands, commits, pushes, migrations, or edits that higher-priority rules block.
-6. If command authority is unclear, use configured command intents only or report the missing command rather than inferring a raw command.
-7. If the conflict can be resolved by a small documentation or template clarification, update the source that caused confusion and keep the wording subordinate to the canonical contract.
-8. Report the chosen scope, skipped scope, and reason when part of the request cannot be completed safely.
+3. Build an action-specific constraint set instead of one flat source ranking. Record which source requires, permits, narrows, or forbids the action and on which authority dimension.
+4. Compare priority only within the same dimension. Across dimensions, satisfy all compatible constraints together. A user-owned goal can remain valid while a host safety rule forbids one execution method.
+5. Select the nearest applicable repository root and path scope. If a nested repository is involved, reread that repository's instructions before editing there.
+6. Apply the stricter safe rule when safety, secrets, destructive actions, command permission, or repository boundaries conflict. Do not use this rule to let a lower-authority preference erase the requested goal.
+7. Treat preferences as defaults only. Do not let preferences authorize commands, commits, pushes, migrations, or edits that higher-priority rules block.
+8. If command authority is unclear, use configured command intents only or report the missing command rather than inferring a raw command.
+9. If two same-dimension rules remain contradictory after scope and recency are applied, stop and ask for the decision owner or report the unresolved conflict. Do not manufacture a total order across unrelated authority dimensions.
+10. If the conflict can be resolved by a small documentation or template clarification, update the source that caused confusion and keep the wording subordinate to the canonical contract.
+11. Report the chosen scope, skipped scope, and reason when part of the request cannot be completed safely.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
-- The active instruction source, repository root, edit scope, command scope, and skipped scope are clear.
+- Goal owner, active constraints, repository root, edit scope, command scope, evidence basis, and skipped scope are clear.
 - Any changed docs or templates do not create a new self-authorizing policy source.
 - The final report distinguishes completed work from blocked, deferred, or intentionally skipped work.
 
@@ -102,6 +112,7 @@ Use a narrower configured test or docs intent when it better proves the clarifie
 ## Failure Handling
 
 - If two high-priority instructions cannot be reconciled, stop and report the conflict instead of guessing.
+- If a proposed priority order compares different authority dimensions as though they were interchangeable, replace it with an action-specific constraint set before deciding.
 - If the nearest repository root is unclear, inspect read-only status and instruction files before editing.
 - If a command, Git operation, migration, or destructive action lacks authority, do not run it. Report the missing approval or command contract.
 - If validation finds command-permission or authority drift, fix that drift before adding unrelated behavior.
@@ -109,8 +120,8 @@ Use a narrower configured test or docs intent when it better proves the clarifie
 <!-- mustflow-section: output-format -->
 ## Output Format
 
-- Conflicting instruction sources
-- Chosen priority rule and repository scope
+- Conflicting instruction sources and authority dimensions
+- Action-specific constraints, chosen same-dimension priority rule, and repository scope
 - Actions allowed, narrowed, skipped, or deferred
 - Documentation or template clarifications made
 - Command intents run

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.nestjs-code-change
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: nestjs-code-change
@@ -80,12 +80,10 @@ Preserve NestJS module boundaries, dependency-injection ownership, request pipel
 6. Avoid `forwardRef()` as a casual cycle fix. If a cycle appears, inspect the module boundary, extract a port/interface, move shared policy, or report why the explicit cycle is accepted.
 7. Check dynamic modules and async factories. Keep options typed, validate config at the boundary, avoid reading secrets into logs or reports, and make module initialization failure explicit.
 8. Keep request-local data out of singleton provider mutable fields. Current user, tenant, request id, locale, transaction, or per-request cache should travel through request objects, guards, interceptors, CLS-style infrastructure with clear ownership, or explicit method arguments.
-9. Review pipeline order:
-   - middleware runs before guards;
-   - guards decide access before interceptors and pipes complete the handler path;
-   - pipes transform and validate inputs;
-   - interceptors wrap handler execution and response mapping;
-   - filters map thrown exceptions.
+9. Review the complete request lifecycle: middleware runs first, guards authorize next,
+   interceptors enter before pipes and handler execution, pipes transform or validate controller
+   arguments, and interceptors process the return path in reverse order. Exception filters run only
+   for uncaught exceptions and follow their own route, controller, and global resolution order.
 10. Do not treat CORS, Swagger hiding, or route omission from OpenAPI as authorization. Add real guards or report the exposure.
 11. For DTOs, distinguish TypeScript shape from runtime validation. Class decorators, global `ValidationPipe` options, transform behavior, whitelist, forbid settings, nested validation, arrays, dates, enums, partial update DTOs, and file uploads must be checked against real runtime behavior.
 12. For params, query, headers, and cookies, remember that HTTP input starts as strings. Use explicit parse pipes, DTO transform rules, or schema validation rather than relying on TypeScript annotations.

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.node-code-change
 locale: en
 canonical: true
-revision: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: node-code-change
@@ -100,7 +100,7 @@ Preserve the actual Node.js runtime, module, package manager, TypeScript executi
 16. Before using Node APIs in deployment code, classify the target as Node server, Docker, serverless Node, edge runtime, static build, or multi-runtime package. Edge runtimes are not full Node.js runtimes.
 17. Inspect native and install-sensitive dependencies when package metadata or runtime imports touch `.node`, `binding.gyp`, `node-gyp`, `preinstall`, `install`, `postinstall`, `prepare`, optional dependencies, peer dependencies, OS, CPU, libc, or Node ABI boundaries.
 18. Treat optional dependencies and optional peers as absent until code handles absence. Do not require optional packages directly without fallback or error handling that matches the existing project pattern.
-19. Treat the Node permission model as a trusted-code seatbelt, not a sandbox for untrusted code. If permission flags are introduced or changed, map required filesystem, network, child process, worker, native addon, WASI, inspector, and temporary directory access explicitly.
+19. Treat the Node permission model as a trusted-code seatbelt, not a sandbox for untrusted code. Map filesystem paths, network access, child processes, worker threads, native addons, WASI, FFI, and inspector access explicitly. Treat temporary directories as filesystem grants, and use OS-level isolation when malicious code is in scope.
 20. Separate Node performance bottlenecks before choosing a fix. Use available `perf_hooks` or configured evidence to distinguish JavaScript CPU, event-loop delay, external I/O wait, libuv worker-pool saturation, stream backpressure, and GC or allocation churn. Event-loop utilization is not CPU percent; high ELU with low CPU can still mean sync blocking.
 21. Prefer CPU profiles or flame graphs over timing logs for CPU-heavy Node paths. Use profile or configured evidence for parsing, validation, rendering, hashing, compression, crypto, diffing, report generation, sorting, JSON work, formatter creation, or AST work; log timers alone rarely prove the hot stack.
 22. Treat event-loop delay as a tail metric. Check p95 and p99 delay when evidence exists, not only averages. A rare 800ms block can dominate user-visible latency while average delay looks clean.