mustflow 2.103.21 → 2.103.31

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.bun-code-change
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: bun-code-change
-description: Apply this skill when 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.
+description: Apply this skill when Bun runtime code, Bun.serve or Elysia-on-Bun server behavior, Bun package manager behavior, bun.lock, bunfig.toml, Bun test runner behavior, Bun bundling, Bun compile, Bun TypeScript execution, Bun-specific APIs, Docker deployment, or Bun runtime compatibility is created, changed, reviewed, or upgraded.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -29,15 +29,15 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Preserve Bun's separate roles as runtime, package manager, script runner, test runner, bundler, transpiler, and Node-compatible environment without mistaking one successful role for another.
+Preserve Bun's separate roles as runtime, package manager, script runner, test runner, bundler, transpiler, compiler, server runtime, and Node-compatible environment without mistaking one successful role for another.
 
 <!-- mustflow-section: use-when -->
 ## Use When
 
 - `bun.lock`, `bun.lockb`, `bunfig.toml`, `packageManager: "bun@..."`, Bun install settings, `trustedDependencies`, Bun workspace behavior, or Bun lockfile migration changes.
-- Bun runtime code or config changes, including `Bun.*`, `Bun.serve`, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.$`, `bun:sqlite`, `#!/usr/bin/env bun`, Bun preload, Bun `.env` behavior, or `bun run --bun`.
+- Bun runtime code or config changes, including `Bun.*`, `Bun.serve`, Elysia-on-Bun `serve` settings, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.$`, `bun:sqlite`, `#!/usr/bin/env bun`, Bun preload, Bun `.env` behavior, or `bun run --bun`.
 - Bun test runner behavior changes, including `bun test`, `bun:test`, `[test]` in `bunfig.toml`, snapshots, mocks, preload, isolation, coverage, sharding, or parallelism.
-- Bun bundling, compile, transpiler, build target, JSX settings, path aliases, TypeScript runtime execution, or library packaging with Bun changes.
+- Bun bundling, compile, transpiler, build target, JSX settings, path aliases, TypeScript runtime execution, single executable output, Docker images, PORT binding, observability instrumentation, or library packaging with Bun changes.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -54,6 +54,7 @@ Preserve Bun's separate roles as runtime, package manager, script runner, test r
 - Bun ownership files: `bun.lock`, `bun.lockb`, `bunfig.toml`, npm, pnpm, or Yarn lockfiles that coexist with Bun, CI install commands, Docker install and runtime commands, and `oven-sh/setup-bun` usage.
 - Bun config sections: `[install]`, `[test]`, top-level preload, env, define, loader, JSX, and run settings.
 - Runtime and compatibility surfaces: `Bun.*`, `bun:test`, `node:*`, `.node`, `node-gyp`, lifecycle scripts, Prisma, sharp, Playwright, esbuild, native binary packages, streams, workers, child processes, crypto, filesystem watch, and shebangs.
+- Server and deployment surfaces: `Bun.serve`, Elysia `serve` config, idle timeout, WebSocket config, backpressure limits, `SO_REUSEPORT`, clustering, compile target, CPU and libc assumptions, Docker base image, build context, distroless output, `PORT` env handling, OpenTelemetry or instrumentation, and reverse proxy config.
 - TypeScript and package surfaces: `tsconfig*.json`, `@types/bun`, `types: ["bun"]`, module resolution, path aliases, JSX runtime, declaration output, build targets, package exports, and command contract entries.
 
 <!-- mustflow-section: preconditions -->
@@ -63,6 +64,7 @@ Preserve Bun's separate roles as runtime, package manager, script runner, test r
 - Do not treat Bun package installation as proof that Bun runtime behavior works.
 - Do not treat Bun runtime execution, Bun transpilation, Bun tests, or Bun bundling as TypeScript typechecking or declaration generation.
 - Treat lockfile, trusted dependency, build target, and package entry changes as release-sensitive unless proven internal.
+- Treat Elysia-on-Bun deployment settings as runtime contracts, not local development conveniences.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -70,6 +72,8 @@ Preserve Bun's separate roles as runtime, package manager, script runner, test r
 - Keep Bun-specific APIs in Bun-owned runtime files, adapters, tests, or package entrypoints.
 - Keep Bun package manager changes aligned with `bun.lock`, `bunfig.toml`, CI, Docker, and workspace ownership.
 - Preserve existing Node, browser, edge, Jest, Vitest, TypeScript, and package-consumer contracts unless the task explicitly asks to migrate them.
+- Isolate Bun-only APIs behind runtime-owned adapters when Node, browser, edge, or test portability remains a project contract.
+- Keep server runtime settings explicit when long-lived requests, streaming, WebSockets, uploaded files, generated exports, or reverse proxies are involved.
 - Add focused tests or package checks only when they protect changed Bun runtime, package manager, test runner, build, or public package behavior.
 
 <!-- mustflow-section: procedure -->
@@ -92,10 +96,19 @@ Preserve Bun's separate roles as runtime, package manager, script runner, test r
 10. For Bun bundling and package output, distinguish `bun run build` from direct Bun bundler usage. Confirm script bodies before treating a build as Bun bundling. Choose target and format according to actual consumers; Bun-targeted output is not automatically Node-compatible.
 11. If Node consumers are supported, do not emit package entrypoints that rely on Bun-only APIs, Bun-only wrappers, or Bun-only module resolution unless the package clearly exposes a Bun-specific entry.
 12. Treat Bun runtime as Node-compatible, not Node itself. JavaScriptCore, Node API compatibility gaps, native addons, Node internals, worker options, child process IPC, stream/backpressure, crypto/FIPS, watch behavior, Prisma CLI, sharp, Playwright, and esbuild all need targeted evidence when touched.
-13. Check shebang and runner behavior. A CLI with `#!/usr/bin/env node` may execute under Node even when launched through Bun. Do not call a path Bun-runtime-verified unless the entrypoint actually ran under Bun.
-14. Use Bun's test runner only when the project intentionally uses it or the task targets Bun. Do not silently migrate Jest or Vitest tests to `bun:test`. Treat mocks, snapshots, preloads, globals, path aliases, coverage, isolation, and parallelism as migration-risk areas.
-15. Do not update Bun snapshots as a generic fix. Snapshot updates require intended output change, diff inspection, and a follow-up run without update mode through configured intents.
-16. Choose configured verification intents that cover typecheck, build, tests, package metadata, package artifact risk, docs examples, Bun runtime behavior, Bun test behavior, and mustflow contract checks when available. Report missing frozen install, Bun runtime, Bun test, declaration, package artifact, native dependency, Node compatibility, Docker, or CI verification.
+13. For Bun server changes, check idle timeout and long-lived request behavior. Plain `Bun.serve`, Elysia `serve.idleTimeout`, SSE, streaming AI responses, long uploads, downloads, exports, and quiet proxy connections may need explicit timeout policy.
+14. For WebSocket changes, review `idleTimeout`, `maxPayloadLength`, `backpressureLimit`, `closeOnBackpressureLimit`, compression, and slow-client behavior. A connection opening successfully does not prove memory-safe backpressure behavior.
+15. For multi-core deployment, distinguish single-process Bun behavior from clustered or multi-worker deployment. Treat `SO_REUSEPORT` and same-port multi-process assumptions as platform-sensitive, especially across Linux, macOS, Windows, containers, and hosting platforms.
+16. For `Bun.serve({ routes })`, Elysia mounts, native routes, and framework interop, benchmark or test the actual route structure instead of assuming every request uses the same optimized path.
+17. For `bun build --compile` or single executable output, check target OS, architecture, libc, executable permission, CPU requirements, dynamic files, `.d.ts` or source files used by runtime generators, native addons, and externalized packages.
+18. Do not assume bundling eliminates `node_modules`. Instrumentation, monkey-patching, native modules, dynamic loading, OpenTelemetry, database drivers, and generated clients may require explicit externals and deployed runtime dependencies.
+19. Treat minification as an observability decision. Full minify can damage function-name-based tracing, stack readability, and instrumentation. Prefer smaller minification scopes when tracing or production diagnostics depend on names.
+20. For Docker and platform deploys, verify build context, workspace package copying, final base image, runtime user, executable path, `PORT` environment binding, health checks, signal handling, and reverse proxy expectations.
+21. Treat benchmarks as workload evidence, not framework marketing. Use a load generator and scenario that are fast enough to drive Bun, and include real handler, serialization, database, TLS, proxy, streaming, or WebSocket paths when those paths changed.
+22. Check shebang and runner behavior. A CLI with `#!/usr/bin/env node` may execute under Node even when launched through Bun. Do not call a path Bun-runtime-verified unless the entrypoint actually ran under Bun.
+23. Use Bun's test runner only when the project intentionally uses it or the task targets Bun. Do not silently migrate Jest or Vitest tests to `bun:test`. Treat mocks, snapshots, preloads, globals, path aliases, coverage, isolation, and parallelism as migration-risk areas.
+24. Do not update Bun snapshots as a generic fix. Snapshot updates require intended output change, diff inspection, and a follow-up run without update mode through configured intents.
+25. Choose configured verification intents that cover typecheck, build, tests, package metadata, package artifact risk, docs examples, Bun runtime behavior, Bun test behavior, server timeout behavior, WebSocket backpressure, compile artifact behavior, Docker runtime, and mustflow contract checks when available. Report missing frozen install, Bun runtime, Bun test, declaration, package artifact, native dependency, Node compatibility, Docker, or CI verification.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -104,7 +117,7 @@ Preserve Bun's separate roles as runtime, package manager, script runner, test r
 - Bun lockfile, install, workspace, trust, and lifecycle behavior is aligned with project ownership.
 - Bun runtime, test, bundler, TypeScript, and declaration claims are not conflated.
 - Bun-only APIs do not leak into Node, browser, edge, or shared package surfaces unintentionally.
-- Native dependency, shebang, Node compatibility, and package consumer risks are handled or reported.
+- Bun server timeout, WebSocket backpressure, clustering, compile target, Docker, PORT, observability, native dependency, shebang, Node compatibility, and package consumer risks are handled or reported.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -119,7 +132,7 @@ Use configured oneshot command intents when available:
 - `test_release`
 - `mustflow_check`
 
-Report missing frozen install, Bun runtime, Bun test, declaration output, package artifact, Node compatibility, native dependency, CI, Docker, or snapshot review verification intents when those surfaces change.
+Report missing frozen install, Bun runtime, Bun server, WebSocket, compile artifact, Docker, Bun test, declaration output, package artifact, Node compatibility, native dependency, CI, observability, benchmark, or snapshot review verification intents when those surfaces change.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -128,6 +141,8 @@ Report missing frozen install, Bun runtime, Bun test, declaration output, packag
 - If lockfile ownership conflicts, do not run dependency migration or generate a new lockfile unless the task explicitly asks for migration.
 - If Bun runtime execution succeeds but typecheck or declarations are unverified, report that gap instead of claiming TypeScript correctness.
 - If a package works under Bun but claims Node support, repair the Node-compatible entry or report the compatibility risk.
+- If a server works locally but has no timeout, backpressure, port, signal, or Docker evidence, report the deployment risk instead of claiming production readiness.
+- If a single executable works on the build machine only, report target CPU, OS, libc, dynamic dependency, and instrumentation gaps.
 - If a native dependency, lifecycle script, or trusted dependency change cannot be verified, keep the change scoped and report release-sensitive risk.
 
 <!-- mustflow-section: output-format -->
@@ -136,7 +151,7 @@ Report missing frozen install, Bun runtime, Bun test, declaration output, packag
 - Bun role classification
 - Package manager, lockfile, and trust notes
 - Runtime, TypeScript, bundler, and test runner notes
-- Native, shebang, Node compatibility, or package consumer risks
+- Server timeout, WebSocket, cluster, compile, Docker, observability, benchmark, native, shebang, Node compatibility, or package consumer risks
 - Files changed
 - Command intents run
 - Skipped checks and reasons

package/templates/default/locales/en/.mustflow/skills/clarifying-question-gate/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.clarifying-question-gate
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: clarifying-question-gate
@@ -96,6 +96,8 @@ verification, and stop-or-ask boundary.
 - Reversibility classification for each decision: cheap/reversible, moderate, or expensive/hard to
   roll back.
 - A recommended option for each blocking question, with the tradeoff of at least one alternative.
+- Host input capability when known: whether a structured user-input mechanism such as Codex
+  `request_user_input` or MCP elicitation is explicitly available in the current runtime.
 - A request-state decision: `ready`, `ready_with_assumptions`, `needs_confirmation`,
   `blocked_by_conflict`, or `insufficient_evidence`.
 - A normalized task contract when the original request is vague enough to risk drift: goal, current
@@ -123,6 +125,8 @@ verification, and stop-or-ask boundary.
   collection, or broad product discovery.
 - Product decisions are separated from engineering responsibilities. Do not ask whether to preserve
   existing style, avoid swallowed errors, add appropriate tests, or follow command contracts.
+- Structured input tools are optional host capabilities. Do not claim they exist, simulate their UI,
+  or depend on them unless the current host explicitly exposes them for this turn or tool call.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -215,22 +219,40 @@ verification, and stop-or-ask boundary.
       and one meaningful alternative;
     - avoid open-ended prompts like "how should I implement this?" unless no responsible options can
       be framed from repository evidence.
-15. Do not ask bad engineering-delegation questions:
+15. Prefer structured user input for real blocking decisions when the host exposes it:
+    - use a structured input tool such as `request_user_input` or MCP elicitation only when it is
+      explicitly listed as available in the current runtime or tool call;
+    - use it for `needs_confirmation` or for a non-blocking `ready_with_assumptions` choice whose
+      answer would materially improve the result without stopping all progress;
+    - ask at most three short questions, and prefer one question when the answer may change the next
+      question;
+    - provide two or three mutually exclusive choices, put the recommended choice first, and include
+      the concrete consequence or tradeoff for each choice;
+    - allow free-form input when the host mechanism supports it, because the listed options are a
+      steering aid rather than a closed product decision;
+    - use auto-resolution only for non-blocking choices with a narrow reversible default, and never
+      for destructive actions, publish or release decisions, credential or secret handling, data
+      deletion or migration, auth or billing policy, dependency adoption, or other explicit
+      confirmation gates;
+    - if no structured input mechanism is available, ask the same blocking decision as a concise
+      normal chat question when host policy allows it; do not invent a fake UI, long questionnaire,
+      or multiple-choice card in prose when the host explicitly forbids that fallback.
+16. Do not ask bad engineering-delegation questions:
     - "Should I add tests?"
     - "Should I handle errors?"
     - "Should I follow existing style?"
     - "Should I check current files?"
     - "Should I preserve existing behavior?"
-16. Use prompt rewriting only as an exception:
+17. Use prompt rewriting only as an exception:
     - the user explicitly asks for a prompt, issue, PR body, work order, or handoff for another
       agent;
     - the current request is too broken to execute and a normalized contract plus confirmation is the
       smallest safe next step.
     Otherwise, show the normalized contract only when it materially reduces drift, then proceed in
     the same conversation.
-17. If no blocking question remains, proceed without ceremony. State only the assumptions that matter
+18. If no blocking question remains, proceed without ceremony. State only the assumptions that matter
     to review or rollback.
-18. If a blocking question remains unanswered, do not implement around it. Offer the smallest safe
+19. If a blocking question remains unanswered, do not implement around it. Offer the smallest safe
     non-blocked action, such as read-only analysis, a plan, a reproduction, or a narrow preparatory
     refactor when another selected skill supports it.
 
@@ -241,6 +263,8 @@ verification, and stop-or-ask boundary.
 - The agent has not asked for facts it could read locally.
 - Expensive, user-owned, security-sensitive, data-affecting, dependency-affecting, and public-contract
   decisions are resolved before implementation.
+- Structured input tools are used only when available and only for bounded decisions that benefit
+  from user choice.
 - Safe assumptions are narrow, reversible, and reported.
 - Any normalized contract preserves the user's original request separately from repository-derived
   facts and safe assumptions.
@@ -288,6 +312,7 @@ run the specific configured verification intents required by the selected implem
 - Normalized task contract, only when needed, with `user_confirmed`, `repository_derived`,
   `safe_assumption`, and `unresolved` source tags
 - Blocking questions asked, with recommendation and tradeoff
+- Question delivery mode: structured host input, normal chat fallback, or not needed
 - Safe assumptions made
 - Decisions intentionally deferred
 - Implementation scope selected

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: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: elysia-code-change
-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.
+description: Apply this skill when Elysia routes, schemas, plugins, decorators, derives, resolves, guards, macros, auth, error handling, OpenAPI or Scalar docs, Eden Treaty clients, streaming, WebSocket, or Bun-backed Elysia server behavior are created, changed, reviewed, or upgraded.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -28,31 +28,34 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Preserve Elysia schema-first runtime validation, type inference, plugin, auth, error, OpenAPI, Eden, and Bun runtime boundaries.
+Preserve Elysia schema-first runtime validation, type inference, plugin, auth, error, OpenAPI, Eden Treaty, lifecycle, streaming, and Bun-backed runtime boundaries.
 
 <!-- mustflow-section: use-when -->
 ## Use When
 
-- `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.
+- `new Elysia`, route methods, `t.Object`, Standard Schema validators, request or response schemas, `.model`, `.use`, `.guard`, `.derive`, `.resolve`, `.decorate`, `.state`, `.macro`, `.onError`, auth middleware, OpenAPI or Scalar docs, Eden Treaty, streaming, WebSocket, or Bun server tests change.
+- The task adds API routes, plugins, validators, error envelopes, authentication, generated client contracts, SDK-facing route paths, runtime deployment settings, or Elysia version-sensitive behavior.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
 
-- The task only edits framework-free service functions called by Elysia routes; use the relevant language or architecture skill.
+- The task only edits framework-free service functions called by Elysia routes; use the relevant language or architecture skill unless route contracts, schemas, lifecycle hooks, OpenAPI, or Eden types also change.
 - Another web framework owns the route surface.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
 
-- Package metadata, Bun lockfile if present, TypeScript config, server entrypoint, route modules, plugin modules, schema/model files, auth/session files, error handling, OpenAPI config, Eden client exports, and tests.
+- Package metadata, Bun lockfile if present, TypeScript config, server entrypoint, route modules, plugin modules, schema/model files, auth/session files, cookie and CORS config, error handling, OpenAPI config, Eden client exports, streaming and WebSocket config, deployment config, and tests.
 - Existing response envelope, status-code contract, and strict TypeScript policy.
+- Current Elysia and plugin version evidence when the task depends on release-specific behavior. Refresh official package or vendor sources before preserving exact "latest" claims.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
 
 - Identify whether schema is the source of truth for runtime validation and type inference.
 - Inventory method, path, params, query, headers, cookies, body, response statuses, auth, and plugin/decorator dependencies.
+- Identify whether the public client contract is Eden Treaty, OpenAPI JSON, generated SDKs, or a mix. Eden uses `typeof app`; OpenAPI SDKs use the OpenAPI document.
+- Identify whether Bun runtime deployment details are in scope. If so, apply `bun-code-change` for Bun-specific runtime, compile, package manager, and deploy risks.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -60,33 +63,78 @@ 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, resolve, and store inference through Elysia chaining.
+- Preserve method chaining or return typed Elysia plugin instances so `typeof app`, decorators, schemas, and lifecycle additions remain visible to Eden and tests.
 - 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.
+- Keep OpenAPI and Eden Treaty clients aligned with route schemas when present.
+- Use `model()` or named schema references for reused schemas in larger route sets when it reduces duplicate schema drift and OpenAPI component churn.
+- Keep reusable plugins explicit with `new Elysia({ name, seed })` when lifecycle deduplication, encapsulation, or dependency visibility matters.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Read server entry, routes, plugins, schemas, auth, error handling, OpenAPI, Eden exports, and tests.
+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. 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. For request-derived context, choose the lifecycle hook by validation dependency:
+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.
+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;
+   - use explicit numeric or boolean coercion schemas such as `t.Numeric()` where the route expects converted URL values;
+   - use array schemas for query arrays instead of relying on caller convention;
+   - distinguish `t.Optional` around an input object from optional properties inside the object.
+6. For file uploads, distinguish `t.File()` behavior from Standard Schema file validation. If using Zod, Valibot, or another Standard Schema, require explicit JSON Schema or file magic-number mapping when OpenAPI or runtime file validation depends on it.
+7. Check body parser ownership. For webhook verifiers, tRPC, oRPC, proxy, or raw-body endpoints, require an explicit raw-body or `parse: 'none'` design instead of letting schema inference consume the request body first.
+8. Reject GET or HEAD bodies as portable public API contracts unless the repository has an explicit non-portable exception. Use query contracts or a POST search/action endpoint instead.
+9. Do not annotate handlers with broad `any`, duplicated manual interfaces, or imported `Context` types that erase inference. Keep Elysia context at the route boundary and pass only validated values into services.
+10. Keep request-specific state out of module-level mutable globals, `.store`, and `.decorate`. Use validated `.resolve` or handler context for user, session, tenant, request id, or permission data.
+11. 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.
+12. Check lifecycle scope and registration order:
+   - hooks generally affect routes registered after them;
+   - plugin lifecycle is local unless scoped or global behavior is explicitly chosen;
+   - `global` scope should be reserved for true app-wide policy, not hidden feature dependencies;
+   - async or lazy plugins may require tests to wait for registered modules before asserting routes.
+13. Treat macros as public route-option APIs. Review their schema, lifecycle, OpenAPI, type-inference, dedupe, and error-response effects before adding or changing macro options.
+14. Centralize expected error envelope and auth failure behavior. Prefer typed `status(...)` return paths for expected route failures when Eden or OpenAPI clients need status-specific types; use `throw status(...)` intentionally when `onError` logging or transformation must run.
+15. Register custom errors and map unknown errors deliberately. Avoid collapsing business, auth, validation, upstream, and server bugs into one unknown 500.
+16. Review security defaults and exposure:
+   - configure CORS origins and credential behavior explicitly;
+   - protect or intentionally expose `/openapi`, `/openapi/json`, Scalar or Swagger UI routes;
+   - do not treat `detail.hide` as access control;
+   - sign and secure session cookies where applicable;
+   - avoid production validation details that leak schema internals.
+17. Review OpenAPI separately from docs UI:
+   - 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;
+   - 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;
+   - keep frontend imports type-only so server runtime code does not enter client bundles;
+   - keep server and client Elysia versions and strict TypeScript settings aligned;
+   - treat route path shape as SDK surface;
+   - handle Treaty `error` before assuming `data` is non-null;
+   - centralize auth headers in Treaty config or request hooks;
+   - split public, admin, internal, WebSocket, and streaming surfaces when one giant `App` type would expose too much or slow typechecking.
+19. Review routing semantics:
+   - static, dynamic, wildcard, optional, group, guard, prefix, mount, and `all()` behavior affect auth, cache, generated clients, and tests;
+   - auto HEAD behavior, explicit HEAD routes, range responses, SSE, and stream headers need separate verification when relevant;
+   - avoid `all()` unless accepting every method is the intended public contract.
+20. If Bun-backed runtime behavior changes, also review Elysia production settings that affect idle timeout, WebSocket backpressure, clustering, compile targets, port binding, Docker build context, and observability. Use `bun-code-change` for Bun-specific edits.
+21. Choose configured verification intents that cover types, server boot, route happy path, validation failure, auth failure, OpenAPI JSON, Eden inference, streaming/WebSocket behavior, and deployment config when available.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - 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, pre-validation auth context, or erased context types.
+- OpenAPI docs UI, raw OpenAPI JSON, generated SDK, and Eden Treaty impact is known and not conflated.
+- No route relies on unvalidated input, pre-validation auth context, request-specific global state, or erased context types.
+- Plugin scope, hook order, macro behavior, and public route path shape are deliberate.
+- Runtime, streaming, WebSocket, or deploy-specific Elysia/Bun risks are handled or reported.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -100,7 +148,7 @@ Use configured oneshot command intents when available:
 - `docs_validate_fast`
 - `mustflow_check`
 
-Report missing route, OpenAPI, or Eden verification intents when relevant.
+Report missing route, OpenAPI JSON, Eden Treaty, streaming, WebSocket, security, Docker, deploy, or runtime verification intents when relevant.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -108,6 +156,10 @@ 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 OpenAPI output looks correct only in development, inspect type generation inputs and production or bundled artifact availability before trusting generated SDKs.
+- If `detail.hide` is used for sensitive routes, add real access control or report the exposure risk.
+- If Eden types require importing server runtime into a frontend bundle, split type-only exports or report the bundling risk.
+- If streaming, WebSocket, or long-lived request behavior is touched without timeout or backpressure evidence, report the operational risk.
 - If auth behavior is unclear, stop the route change and inspect or request the auth contract.
 
 <!-- mustflow-section: output-format -->
@@ -115,7 +167,9 @@ Report missing route, OpenAPI, or Eden verification intents when relevant.
 
 - Boundary checked
 - Schema and type inference notes
-- Auth, error, OpenAPI, or Eden impact
+- Lifecycle, plugin, macro, auth, and error notes
+- OpenAPI, Scalar or Swagger UI, generated SDK, and Eden Treaty impact
+- Bun-backed runtime, streaming, WebSocket, or deployment notes
 - Files changed
 - Command intents run
 - Skipped checks and reasons