mustflow 2.22.16 → 2.22.46

package/templates/default/locales/en/.mustflow/skills/file-path-cross-platform-change/SKILL.md

@@ -0,0 +1,147 @@
+---
+mustflow_doc: skill.file-path-cross-platform-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: file-path-cross-platform-change
+description: Apply this skill when file path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, 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.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.file-path-cross-platform-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# File Path Cross-Platform Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Treat file paths as security boundaries and operating-system contracts, not as ordinary strings.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code accepts, stores, serializes, validates, normalizes, joins, resolves, compares, scans, extracts, uploads, downloads, writes, deletes, locks, packages, or reports paths.
+- Path behavior appears in CLI arguments, API request or response schemas, config files, snapshots, fixtures, generated output, package artifacts, logs, manifests, caches, temp directories, upload or download flows, archive extraction, or scanner output.
+- A change claims path traversal safety, base-directory containment, symlink safety, junction or reparse-point safety, archive extraction safety, atomic write behavior, durable write behavior, lock ownership, cleanup safety, deterministic scanning, or Windows/macOS/Linux compatibility.
+- A test or docs example includes paths that must behave consistently across Windows, macOS, Linux, CI, containers, archives, package artifacts, or user machines.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes in-memory labels and no path is interpreted by an OS, runtime, CLI, API, archive, scanner, package manager, or filesystem helper.
+- The task only changes Git line-ending policy; use `line-ending-hygiene`.
+- A generated artifact is only referenced or packaged and no path validation, path generation, or artifact path contract changes; use `artifact-integrity-check`.
+- The task is only a narrow low-level filesystem helper change with no public path contract; `cross-platform-filesystem-safety` can be used as the narrower adjunct.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Every path input and output, including user input, CLI args, API fields, config fields, archive entries, generated files, temp files, cache paths, lock files, uploaded filenames, download filenames, scanner roots, package artifact paths, and logs.
+- The path owner and trust class: user-controlled, repository-owned, generated, temp, cache, archive-contained, package artifact, external file, or unknown.
+- The base directory or allowed root, expected relative/absolute policy, symlink and reparse-point policy, case-sensitivity policy, invalid-name policy, atomic-write policy, lock policy, archive extraction policy, scanner bounds, cleanup policy, and platform expectations.
+- Current path helpers, safe filesystem wrappers, temp/cache helpers, archive helpers, upload/download helpers, scanners, schema validators, snapshots, and tests.
+- Relevant command-intent entries for build, tests, docs, release, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Existing path helpers and safe filesystem wrappers have been inspected before adding a new helper.
+- Security and privacy review is applied first when paths can expose secrets, personal data, uploaded files, downloaded files, or files outside an owned root.
+- The path contract is classified before editing: internal helper, public CLI, public API, schema, generated output, snapshot, package artifact, archive, upload/download, scanner, temp/cache, lock, or cleanup.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update path validators, path helpers, safe filesystem wrappers, schemas, CLI parsing, API contracts, snapshots, fixtures, docs, tests, package metadata, generated-output paths, archive extraction, scanner bounds, temp/cache handling, locks, and cleanup code that are directly needed for safe path behavior.
+- Prefer existing repository path helpers and one shared path contract over ad hoc string manipulation.
+- Keep path display format stable for users and automation. Prefer repository-relative paths in output unless absolute paths are required for local diagnosis.
+- Do not broaden filesystem access, cleanup roots, scanner roots, archive extraction roots, package artifact globs, or upload/download destinations to make a path bug disappear.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Build a path ledger. List every path field, argument, helper, schema, snapshot, generated output, package artifact, archive entry, upload/download filename, scanner root, temp/cache path, lock file, and cleanup target touched by the change.
+2. Classify each path by trust and owner: trusted repository path, user input, generated state, template path, package artifact, temporary file, cache file, archive-contained path, external path, uploaded name, downloaded name, scanner root, or unknown.
+3. Define the allowed root and representation. Decide whether the contract accepts relative paths, absolute paths, URLs, file URLs, archive entry names, package-relative paths, repository-relative paths, or display-only paths.
+4. Reject dangerous path text before filesystem access: null bytes, empty names where not allowed, absolute paths where relative paths are required, dot segments where not allowed, Windows device names, drive-relative paths, UNC roots, namespace prefixes, alternate data streams, trailing dots or spaces, reserved characters, and mixed separator bypasses.
+5. Treat Windows drive-relative paths such as `C:tmp.txt` as relative to a drive current directory, not as `C:\tmp.txt`.
+6. Treat Windows reserved names as reserved even with extensions. Names such as `CON`, `PRN`, `AUX`, `NUL`, `COM1`, and `LPT1` must not become ordinary user filenames.
+7. Treat macOS and Windows case-insensitive defaults as compatibility risks. Decide whether to reject case-only collisions, preserve spelling, normalize display only, or rely on the host filesystem.
+8. Do not solve containment with string prefixes. Establish the base real path, resolve or canonicalize the candidate parent when possible, then use path-aware relative containment with a separator boundary.
+9. For new files whose final path does not exist yet, canonicalize the existing parent directory and verify that parent remains inside the allowed root.
+10. Recheck symlink, junction, reparse-point, and final-target behavior at the operation boundary where the runtime allows it. Do not claim race-free behavior from normalize-then-open code alone.
+11. For uploads and downloads, separate displayed filename from storage key. Validate extension, size, content type, magic bytes when relevant, path separators, Unicode aliasing, reserved names, collision policy, overwrite policy, and tenant or user ownership.
+12. For archive extraction, validate every entry before extraction. Reject absolute entries, parent traversal, empty names, platform-reserved names, symlink entries unless explicitly supported, hard links unless explicitly supported, duplicate or case-colliding entries, oversized entries, zip bombs, and extraction outside the target root.
+13. Do not call extract-all behavior on untrusted archives unless the helper performs per-entry validation and bounded extraction.
+14. For atomic writes, create the temporary file in the target directory on the same filesystem, use an unpredictable temp name, write, flush, close, replace or rename, and flush the parent directory when the platform and helper support it.
+15. Scope atomicity claims. Cross-filesystem moves, network filesystems, Windows sharing violations, antivirus/indexer locks, and missing directory fsync support can downgrade a claim to best effort.
+16. For Windows replace or rename failures caused by sharing violations, use bounded retry or report the platform limitation. Do not turn every transient lock into silent data loss.
+17. For locks and mutexes, define owner token, stale lock policy, crash recovery, deletion race handling, PID reuse handling, and whether the lock works on local filesystems only. Do not treat a PID file alone as proof of ownership.
+18. For scanners, set max depth, max file count, max file size, binary-file handling, ignored directories, hidden-file policy, permission-error behavior, symlink traversal policy, loop detection, deterministic ordering, and output path format.
+19. For temp and cache paths, keep them under an owned root, avoid global temp rename into a target location, include cleanup bounds, and avoid leaking user data through predictable names.
+20. For CLI, API, schema, snapshot, docs, and package artifact path changes, update every contract surface together. Path spelling, separators, slash policy, absolute/relative policy, escaping, sorting, and error messages are part of the contract.
+21. Add focused tests for the riskiest path shapes: traversal, absolute input, drive-relative input, UNC-like input, reserved names, trailing dots or spaces, case collision, symlink escape, archive traversal, duplicate archive entries, scanner loop, large file cap, and cleanup boundary.
+22. Select verification from the command contract based on risk. Public CLI/API/schema/package artifact changes need broader checks than internal helper-only changes.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Path trust classes, accepted path representation, invalid-name policy, case policy, root boundary, symlink and reparse-point policy, archive policy, upload/download policy, scanner policy, atomic-write policy, lock policy, temp/cache policy, and cleanup policy are explicit.
+- Path contracts are synchronized across helpers, schemas, CLI/API docs, snapshots, fixtures, generated outputs, package artifacts, tests, and reports.
+- Any race-safety, atomicity, durability, lock, or cross-platform claim is scoped to what the current runtime and helpers can actually guarantee.
+- Platform behavior that was not tested is reported as remaining risk.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer focused tests for helper-only path changes. Use release or package checks when CLI output, schemas, snapshots, generated outputs, package artifacts, template paths, or installed workflow files change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If root containment is unclear, stop before writing, deleting, extracting, scanning, or opening and report the ambiguous path owner.
+- If the platform cannot prove symlink-safe behavior, fail closed or report the exact remaining gap.
+- If archive entries cannot be validated before extraction, do not extract the archive.
+- If atomic replace, file fsync, parent directory fsync, no-follow open, lock ownership, or final-target verification is unavailable, downgrade the claim and keep the operation bounded.
+- If Windows, macOS, Linux, container, CI, or network-filesystem behavior differs and cannot be tested, state the untested platform boundary.
+- If cleanup might remove user data or files outside generated state, do not proceed without a tighter owned root.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Path contract changed
+- Path ledger and trust classes
+- Accepted representation and base-root policy
+- Windows, macOS, Linux, archive, upload/download, scanner, lock, temp/cache, atomic-write, and cleanup decisions
+- CLI/API/schema/snapshot/generated-output/package artifact surfaces synchronized
+- Tests or fixtures added or reused
+- Command intents run
+- Skipped platform checks and reasons
+- Remaining file path cross-platform risk

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

@@ -0,0 +1,116 @@
+---
+mustflow_doc: skill.flutter-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: flutter-code-change
+description: Apply this skill when Flutter widgets, screens, routing, state management, async UI, platform channels, assets, responsive layout, accessibility, or Flutter tests are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.flutter-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Flutter Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Flutter widget, state owner, build purity, async lifecycle, navigation, platform channel, asset, responsive layout, and accessibility boundaries.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Flutter `lib/**.dart`, widgets, screens, routing, state management, platform channels, assets, tests, integration tests, or platform project files change.
+- The task touches `StatefulWidget`, `StatelessWidget`, `setState`, `BuildContext`, navigation, `FutureBuilder`, `StreamBuilder`, controllers, subscriptions, `MethodChannel`, `pubspec.yaml` assets, or responsive layout.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is pure Dart package or CLI logic with no Flutter UI/lifecycle surface; use `dart-code-change`.
+- The task only reads Flutter code for orientation.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `pubspec.yaml`, analyzer config, app root, route config, state management setup, target screen, parent widgets, assets, platform channel files, and tests.
+- Existing state management, navigation, accessibility, theming, and responsive layout conventions.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Identify widget tree owner, state owner, route owner, async source, platform boundary, asset declaration, and verification surface.
+- Keep `build` as UI description, not a side-effect runner.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Put network calls, subscriptions, controllers, timers, analytics, navigation side effects, and snackbars in the proper lifecycle or event boundary.
+- Use the project's existing state management and routing style.
+- Use constraints and layout information rather than device-name assumptions.
+- Dispose controllers, streams, timers, animations, and subscriptions.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read app root, route config, parent widgets, state owner, target widget, platform files, assets, and tests.
+2. Classify the change: widget layout, state, async lifecycle, navigation, platform channel, asset, accessibility, or test-only.
+3. Do not create futures, streams, controllers, listeners, or side effects inside `build`.
+4. Keep `setState` narrow and synchronous; do not put awaited work inside the `setState` callback.
+5. After async gaps, ensure the widget is still mounted before using context or state, and prefer disposing owners so dead widgets are not touched.
+6. Keep navigation consistent with the project's router.
+7. If platform channel or native permission changes, verify Dart interface, native implementation, serialization shape, and error shape together.
+8. Check small width, wide width, long text, text scaling, keyboard/open input states, and screen-reader semantics when relevant.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Widget build remains pure.
+- State owner and async lifecycle are clear.
+- Layout responds to constraints and text scaling.
+- Platform, asset, and accessibility risks are checked or reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing widget, integration, golden, or platform verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a lifecycle fix requires repeated mounted checks, inspect ownership and disposal before adding more guards.
+- If layout only works for one viewport, redesign with constraints before finishing.
+- If platform permissions or channels are unclear, stop that part and inspect native config.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- State, lifecycle, layout, and accessibility notes
+- Platform or asset impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Flutter risk

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

@@ -0,0 +1,156 @@
+---
+mustflow_doc: skill.go-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: go-code-change
+description: Apply this skill when Go source, modules, package APIs, interfaces, errors, goroutines, channels, context propagation, tests, or generated code boundaries are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.go-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Go Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Go package, module, API, error, context, concurrency, and test boundaries without adding needless abstraction.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.go`, `go.mod`, `go.sum`, `go.work`, build tags, generated code, public package API, tests, benchmarks, goroutines, channels, or context propagation change.
+- The task touches interfaces, error wrapping, package structure, concurrency ownership, or module dependencies.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only reads Go files and makes no edit.
+- A generated file is the only affected file and must be regenerated by a declared project command instead of edited manually.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `go.mod`, `go.sum`, `go.work`, build tooling, lint config, and CI hints.
+- All files in the changed package, including `_test.go`, build-tagged files, examples, and generated-file markers.
+- The public API surface when exported identifiers, errors, or package paths change.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Inspect the whole package before adding names or methods.
+- Determine whether the change affects exported API, concurrency ownership, or dependency graph.
+- Identify generated files and avoid direct edits unless explicitly requested.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep interfaces small and preferably owned by the consuming side.
+- Return concrete provider types from provider packages unless the package intentionally hides multiple implementations as its public API.
+- Keep domain and use-case packages free of SQL, HTTP transport, queue, cloud SDK, ORM, and vendor persistence types unless those types are the explicit public API.
+- Preserve context propagation across API and goroutine boundaries.
+- Return actionable errors and wrap causes when callers need `errors.Is` or `errors.As`.
+- Add table-driven tests when they clarify behavior.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read module files, package files, tests, build tags, and generated-code markers.
+2. Classify the change as package API, internal implementation, dependency, error behavior, context flow, concurrency, or test-only.
+3. Check package boundaries before adding a package or interface:
+   - reject shared bucket packages named `common`, `util`, `types`, `interfaces`, `api`, or `models` unless the repository already has a specific local convention with a narrower meaning;
+   - put an interface in the package that consumes the methods, not in the package that merely implements them;
+   - create an interface only after a real consumer needs that exact method set;
+   - shrink an interface to the methods the immediate consumer calls;
+   - reject provider-side interfaces that exist only for mocks;
+   - reject provider constructors that return interfaces by default; prefer concrete exported types such as `*Client`, `*Store`, or `*Service`;
+   - verify that a package split reduces a real dependency direction problem or creates a coherent capability instead of hiding imports.
+4. If exported identifiers or package paths change, classify the public API impact:
+   - treat exported functions, variables, constants, types, methods, struct fields, interfaces, interface method sets, sentinel errors, typed errors, module path, package import path, and minimum Go version as contracts;
+   - assume exported symbols in a v1+ module are public API unless the package is internal or local evidence proves otherwise;
+   - do not remove, rename, or change exported signatures, exported field types, exported interface methods, or observable error behavior without an explicit breaking-change plan;
+   - adding a method to an exported interface is breaking for external implementations even when adding a method to a concrete type would be safe.
+5. Preserve error contracts:
+   - use `errors.Is` and `errors.As` semantics as observable API when documented or already tested;
+   - do not compare error strings;
+   - do not expose dependency sentinel or typed errors through wrapping unless the package intentionally supports them as API;
+   - treat a change between observable wrapping and non-observable formatting as API-sensitive;
+   - add tests for documented sentinel or typed errors when the error behavior changes.
+6. If goroutines or channels change, name the owner, stop condition, cancellation path, wait path, error path, close responsibility, and test synchronization.
+7. Reject fire-and-forget goroutines unless they are owned by a long-lived object with a shutdown path, joined before return, managed by a group with a wait path, or explicitly documented as safely detached.
+8. Preserve context propagation:
+   - request-scoped functions accept `ctx` first and pass it down;
+   - do not store request context in structs;
+   - do not pass nil context;
+   - do not introduce `context.Background()` inside request or operation depth unless it is a true process root with a documented owner;
+   - derived contexts must release their cancel function on every path;
+   - blocking sends, receives, waits, retry loops, worker loops, and external calls must observe cancellation or be proven non-blocking.
+9. Preserve channel ownership:
+   - the sender that knows all sends are complete closes the channel;
+   - receivers do not close borrowed input channels;
+   - multiple senders require a coordinator that closes only after all senders finish;
+   - cancellable pipelines must avoid permanently blocking upstream goroutines when downstream stops early.
+10. Keep timeout policy at request, command, API, or operation boundaries. Do not hide arbitrary sleeps or timeouts in reusable helpers unless that helper explicitly owns the policy.
+11. Keep concurrency tests deterministic. Do not use elapsed real time to wait for goroutine progress; use explicit synchronization, owned lifecycle waits, fake time, or the repository's established concurrency test helper.
+12. If dependency metadata changes, keep module files and dependent tests synchronized. Do not raise the `go` directive, add toolchain requirements, change module path, or introduce direct dependencies unless the task requires it and the final report calls out the support impact.
+13. Choose configured verification intents that cover formatting, tests, race-sensitive behavior, lint, API drift, and module drift when available.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Package ownership and exported API impact are clear.
+- Context, goroutine, channel, and error ownership are explicit.
+- Tests cover the changed behavior without sleeps as synchronization.
+- Module drift is reported when dependency verification cannot run.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+For concurrency-sensitive changes, report whether a configured race or equivalent verification intent exists.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If an import cycle appears, revisit package boundaries instead of adding a workaround package.
+- If a new package becomes a shared bucket, move behavior back to the owning package or name the concrete capability.
+- If a provider-side interface appears only for mocking, delete it or move a minimal interface to the consumer.
+- If tests need sleeps for concurrency, prefer deterministic synchronization or report the gap.
+- If a goroutine has no owner, stop condition, wait path, cancellation path, or error path, do not add it.
+- If a public error stops satisfying documented `errors.Is` or `errors.As` checks, restore the contract or report the breaking-change requirement.
+- If wrapping would expose a dependency error as public API, keep the dependency error internal or document the intentional contract.
+- If a generated file must change but no generator intent exists, report the missing command contract.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Package and API impact
+- Context/concurrency/error notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Go risk

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

@@ -0,0 +1,117 @@
+---
+mustflow_doc: skill.hono-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: hono-code-change
+description: Apply this skill when Hono apps, routes, middleware, validators, RPC clients, bindings, context variables, auth boundaries, or runtime adapters are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.hono-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Hono Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Hono runtime, middleware, validation, context binding, auth, typed route, and response contract boundaries.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `new Hono`, `app.get`, `app.post`, `app.use`, `c.env`, `c.get`, `c.set`, validators, RPC clients, middleware, adapters, or Hono route tests change.
+- The task touches Cloudflare Workers, Bun, Node, edge-compatible routes, bindings, variables, auth middleware, or response schemas.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only touches framework-agnostic service code behind a Hono handler; use the relevant language or architecture skill.
+- Another HTTP framework is used instead of Hono.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Package metadata, TypeScript config, runtime adapter config, worker or server entrypoint, routes, middleware, env/binding types, schemas, client types, and tests.
+- Target runtime matrix: Cloudflare, Bun, Node, edge-compatible, or single runtime.
+- Existing response envelope and error contract.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Confirm runtime before using platform APIs.
+- Identify `Bindings` for runtime-provided values and `Variables` for request-local middleware values.
+- Identify auth, validation, and error response boundaries before adding routes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep runtime-specific APIs isolated behind adapters or runtime-specific files.
+- Register middleware in an order that preserves logging, CORS, security headers, body limits, auth, validation, and handler behavior.
+- Trust only validated request data in handlers.
+- Keep success and failure envelopes consistent.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read app entrypoint, runtime adapter, route modules, middleware, schemas, client type exports, and tests.
+2. Map the route boundary: method, path, runtime, auth, params, query, headers, cookies, body, variables, bindings, response statuses, and content types.
+3. Do not put Node-only, Bun-only, or Cloudflare-only APIs in shared routes.
+4. Keep auth middleware above protected routes and wildcard or fallback routes after specific routes.
+5. Separate `Bindings` from `Variables`; do not store request-local state in globals.
+6. Use validator output rather than rereading unvalidated request bodies.
+7. Preserve typed route or RPC inference by keeping handler responses in the framework's typed response path.
+8. Choose configured verification intents that cover type checks, route tests, auth failure, validation failure, and runtime env mocks when available.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Runtime-specific APIs are isolated.
+- Middleware order and auth boundary are clear.
+- Request validation and response envelope are preserved.
+- Typed route or RPC contract impact is reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing multi-runtime or route-level verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If runtime target is unclear, inspect adapter and deployment config before editing.
+- If a route needs a broader permission, binding, or auth change, switch to the relevant security or contract skill.
+- If typed route inference breaks, repair schema and response shape before adding more routes.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Runtime and middleware notes
+- Validation and response contract notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Hono risk