mustflow 2.103.22 → 2.103.32

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/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

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

@@ -0,0 +1,272 @@
+---
+mustflow_doc: skill.godot-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: godot-code-change
+description: Apply this skill when Godot projects, scenes, nodes, GDScript, C# scripts, Resources, Autoloads, signals, groups, save/load systems, rendering, physics, UI, input, exports, plugins, editor tools, or Godot version migrations are created, changed, reviewed, or upgraded.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.godot-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Godot Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Godot scene ownership, node lifecycle, Resource sharing, Autoload boundaries, signal flow,
+save/load integrity, rendering budgets, physics stability, export behavior, and version migration
+assumptions while making focused game or editor-tool changes.
+
+Godot work is not "script changes plus some scenes". Many failures come from scene-tree coupling,
+shared Resources mutated as instance state, Autoloads used as global storage, hidden signal
+connections, per-frame tree searches, blocking loads, save files written into `res://`, or renderer
+settings changed without profiling evidence.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `project.godot`, `.tscn`, `.tres`, `.res`, `.gd`, `.gdshader`, `.cs`, export presets, addons,
+  editor plugins, import settings, input maps, autoloads, groups, scenes, nodes, Resources, or
+  Godot-specific tests change.
+- Scene composition, ownership, instancing, inherited scenes, node paths, unique names, exported
+  NodePath references, groups, signals, tweens, animations, UI Controls, Containers, camera,
+  rendering, physics, input, save/load, or export templates are created, changed, reviewed, or
+  upgraded.
+- GDScript typing, `await`, signals, callables, `@onready`, `@export`, `ResourceLoader`,
+  `ResourceSaver`, `FileAccess`, `DirAccess`, `ConfigFile`, threaded loading, or Autoload behavior
+  affects runtime paths.
+- A Godot 3.x to 4.x migration, Godot 4.x minor upgrade, renderer change, platform export change,
+  mobile/XR/input change, or plugin compatibility change is part of the task.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The repository does not use Godot and only changes general assets, docs, or game design prose.
+- Generic C#, Rust, C++, JavaScript, or shader code changes have no Godot scene, resource, engine,
+  export, editor, or runtime lifecycle effect; use the matching language or asset skill instead.
+- The task only updates external version prose; use source-freshness guidance unless this procedure
+  itself changes.
+- Generated import files, caches, exported builds, or `.godot/` state should be regenerated by a
+  declared command rather than edited.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Godot version, renderer, platform targets, export presets, project settings, input map, autoload
+  list, addon/plugin list, script language mix, and relevant official docs for the version in use.
+- Scene ledger: entry scene, affected `.tscn` files, node ownership, instanced scenes, inherited
+  scenes, unique names, NodePaths, groups, signals, animation players, tweens, UI Containers,
+  physics nodes, cameras, lights, materials, Resources, and save/load participants.
+- Runtime ledger: `_ready`, `_enter_tree`, `_exit_tree`, `_process`, `_physics_process`, input
+  callbacks, threaded loading, timers, deferred calls, scene transitions, queue/free behavior, and
+  profiler or frame-time evidence when performance is claimed.
+- Data ledger: user data paths, save schema version, migration path, atomic write strategy,
+  Resource cache behavior, config defaults, validation rules, and untrusted file boundaries.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read project settings, affected scenes, scripts, Resources, autoload declarations, export presets,
+  and tests before editing.
+- Identify the Godot major/minor version before applying version-specific syntax, migration, or
+  export guidance. Do not mix stable docs for one branch, latest docs for another branch, and blog
+  examples as if they were one source.
+- Apply language-specific skills alongside this skill when C#, C++, Rust/GDExtension, shader, or
+  package/tooling behavior changes outside the Godot boundary.
+- Apply security, data, performance, UI, accessibility, or release skills when the change touches
+  save-file trust, networked games, monetized state, rendering budgets, UI behavior, or export
+  artifacts.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep scenes independently instantiable where practical. Parent nodes may coordinate children, but
+  child scenes should not hard-code distant parents, sibling internals, or `/root/Main` paths.
+- Keep nodes for objects with lifecycle, transforms, notifications, or scene-tree behavior. Use
+  Resources, RefCounted, plain data, or DTOs for definitions and serializable state.
+- Keep Autoloads limited to true process-wide services such as scene transition, save service,
+  audio bus control, settings, telemetry facade, or platform integration.
+- Keep runtime-mutated Resources duplicated, local-to-scene, or separated from authoring data.
+- Keep user-writable data under `user://`, not `res://`.
+- Keep version-specific guidance behind a version gate and omit durable exact "latest" claims unless
+  refreshed from official sources.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read the Godot version, renderer, export targets, project settings, autoload declarations, input
+   map, addon list, affected scenes, scripts, Resources, shaders, import/export files, and tests.
+2. Apply the Version Gate:
+   - identify current Godot major/minor version and whether the project is 3.x, 4.x, or in a
+     migration window;
+   - use official docs for the branch actually in use before applying syntax, API, renderer, export,
+     or migration behavior;
+   - treat stable docs, latest docs, release notes, blog posts, and pasted upgrade notes as
+     different evidence tracks until reconciled;
+   - for 4.x projects, check obsolete 3.x habits such as `yield`, stringly signal connections,
+     renderer assumptions, old physics behavior, and global singleton patterns before copying code.
+3. Build a scene and ownership ledger:
+   - entry scene, world/UI split, instanced subscenes, inherited scenes, lifecycle owner, cleanup
+     owner, injected dependencies, sibling relationships, NodePaths, groups, signals, and public
+     scene contract;
+   - reject distant relative paths, `/root/Main` reach-through, sibling-to-sibling hard references,
+     and child scenes that cannot run or preview outside one parent unless that coupling is
+     intentional and documented.
+4. Review node lifecycle and runtime order:
+   - distinguish `_enter_tree`, `_ready`, `_exit_tree`, `_process`, `_physics_process`, input
+     callbacks, timers, deferred calls, and scene transition timing;
+   - do not assume a new scene is immediately ready after `change_scene_to_*`;
+   - remember that `queue_free()` is deferred deletion, `remove_child()` is detachment, and
+     `replace_by()` does not automatically free the old node.
+5. Review signals, groups, and flow visibility:
+   - use signals for events, not hidden remote commands;
+   - avoid duplicate connections on scene re-entry and lambdas that cannot be disconnected when
+     lifecycle requires cleanup;
+   - prefer typed signal/callable patterns for maintained 4.x code;
+   - treat `call_group` and `set_group` as broad broadcasts that can stutter when used on many
+     nodes; chunk, defer, or queue high-volume work.
+6. Review Autoload and global state:
+   - keep Autoload APIs narrow and service-like;
+   - avoid putting player health, enemy state, UI control state, per-level state, or transient
+     request data into globals;
+   - do not free Autoloads during normal runtime;
+   - ensure scene transitions through an Autoload have an explicit ordering contract.
+7. Review Resources and serialized data:
+   - remember that path-loaded Resources are cached shared references;
+   - never mutate authoring Resources as per-instance runtime state unless they are duplicated or
+     local-to-scene by design;
+   - keep item definitions, tuning tables, materials, and animation data separate from player save
+     state;
+   - avoid using instance overrides as an untracked data-management system.
+8. Review GDScript and language boundaries:
+   - use static typing on long-lived gameplay systems, save DTOs, inventory, combat math, settings,
+     networking, and scene-transition managers;
+   - avoid per-frame `find_child`, `find_children`, and `find_parent`; cache references with
+     `@onready`, unique names, exported references, or dependency injection;
+   - use `_process` only for per-frame behavior, `_physics_process` for fixed-step physics, and
+     input callbacks for input events.
+9. Review save/load, config, and file I/O:
+   - save state snapshots, not raw node trees;
+   - write user data to `user://`;
+   - put schema, game/content version, slot id, timestamps, and migration path at the save root;
+   - use atomic temp, backup, validate, rename style writes when save loss matters;
+   - treat JSON as readable but type-weak; validate parsed data;
+   - avoid object deserialization from untrusted files, especially object-enabled Variant loading;
+   - use `ConfigFile` for settings, with defaults, validation, apply, and batched save behavior.
+10. Review loading, threads, and deferred work:
+    - use threaded resource requests with status polling before getting the loaded resource;
+    - avoid calling blocking loads during gameplay spikes or UI opening;
+    - do not touch active SceneTree nodes directly from background threads; use deferred calls or a
+      main-thread handoff;
+    - guard shared data with a clear ownership or mutex policy.
+11. Review rendering, UI, physics, and input:
+    - require profiler or frame-time evidence before accepting performance claims;
+    - for 3D, check visibility ranges, occlusion, HLOD/LOD, far plane, light counts, shadows,
+      materials, shader variants, particles, MultiMesh usage, and camera cost;
+    - for 2D, check draw calls, canvas layers, custom drawing invalidation, particles, tilemaps,
+      collision shapes, and physics tick stability;
+    - for UI, keep Container layout separate from animation transforms and avoid wrapper-node
+      sprawl when the current version has a cleaner Control transform path;
+    - for mobile/gamepad/XR, check input mode, focus loss, virtual controls, safe areas, and export
+      target behavior.
+12. Review export and plugin surfaces:
+    - keep export presets, export templates, platform architectures, signing, permissions, splash,
+      icon, native plugin, GDExtension, and addon compatibility explicit;
+    - do not edit generated imports, cache state, or exported binaries as source;
+    - verify release-sensitive export changes with configured package/release checks when available.
+13. Choose configured verification intents that cover scene loading, script parsing/type checks,
+    save/load migration, settings validation, scene transitions, rendering smoke, physics/input
+    behavior, export metadata, and package/template sync when available.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise a change when:
+
+- Godot 3.x syntax, signals, renderer, physics, or singleton patterns are applied to a 4.x project
+  without checking the project version.
+- A subscene reaches distant parents, siblings, or `/root/Main` instead of receiving dependencies
+  through its parent, exported references, groups, or a service boundary.
+- Autoload becomes a catch-all for gameplay, UI, level, save, and platform state.
+- Runtime code mutates shared authoring Resources as if each instance owns a copy.
+- Save files are written under `res://`, lack a schema version, or deserialize trusted objects from
+  user-controlled data.
+- `_process` performs tree searches, heavy polling, loading, group broadcasts, or work that belongs
+  in input callbacks, timers, or cached references.
+- Threads touch live SceneTree nodes directly.
+- Scene transition code assumes old and new scenes are available synchronously after the transition
+  call.
+- Rendering, physics, or memory changes claim performance wins without profiler, frame-time, or
+  target-device evidence.
+- Export preset or platform changes omit target architecture, signing, permission, template, or
+  native-plugin impact.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Scene ownership, node lifecycle, signals, groups, Autoloads, Resources, save/load, config,
+  rendering, physics, input, export, and version assumptions are intentional and reported.
+- Runtime-mutated state is separated from authoring Resources and process-wide services.
+- User-writable files, migrations, atomic writes, and untrusted data boundaries are explicit.
+- Version-specific guidance is refreshed from official sources for the project version or omitted
+  from durable claims.
+- Missing scene, save/load, rendering, physics, input, export, or target-device verification 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 Godot editor import, script parse, scene load, save migration, renderer smoke,
+physics/input, export preset, target-device, or release verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If scene behavior is unclear, build the scene and ownership ledger before changing scripts.
+- If runtime errors mention missing nodes, inspect NodePaths, unique names, scene instancing,
+  lifecycle order, and scene transition timing before adding broader globals.
+- If shared data changes leak across instances, inspect Resource cache, duplication, local-to-scene,
+  instance overrides, and authored-versus-runtime state separation.
+- If save/load fails, inspect path choice, schema version, migration, parse errors, type validation,
+  atomic write behavior, and untrusted object deserialization.
+- If performance cannot be measured by configured intents, report the missing profiler, scene-load,
+  target-device, or export-smoke coverage instead of claiming a performance fix.
+- If official source freshness cannot be checked for a version, release, migration, or export claim,
+  omit the claim from durable skill text and report it as unverified snapshot context.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Godot version, renderer, scene, node, signal, Resource, Autoload, and lifecycle notes
+- Save/load, config, file I/O, threaded loading, and untrusted data notes
+- Rendering, physics, UI, input, export, plugin, and target-platform notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Godot risk