mustflow 2.25.2 → 2.27.0

package/package.json

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

package/templates/default/i18n.toml

@@ -56,7 +56,7 @@ translations = {}
 [documents."skills.index"]
 source = "locales/en/.mustflow/skills/INDEX.md"
 source_locale = "en"
-revision = 87
+revision = 89
 translations = {}
 
 [documents."skill.adapter-boundary"]
@@ -191,6 +191,12 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.bun-code-change"]
+source = "locales/en/.mustflow/skills/bun-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.cpp-code-change"]
 source = "locales/en/.mustflow/skills/cpp-code-change/SKILL.md"
 source_locale = "en"
@@ -203,6 +209,12 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.docker-code-change"]
+source = "locales/en/.mustflow/skills/docker-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.elysia-code-change"]
 source = "locales/en/.mustflow/skills/elysia-code-change/SKILL.md"
 source_locale = "en"
@@ -239,6 +251,12 @@ source_locale = "en"
 revision = 2
 translations = {}
 
+[documents."skill.node-code-change"]
+source = "locales/en/.mustflow/skills/node-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.python-code-change"]
 source = "locales/en/.mustflow/skills/python-code-change/SKILL.md"
 source_locale = "en"

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

@@ -2,7 +2,7 @@
 mustflow_doc: skills.index
 locale: en
 canonical: true
-revision: 87
+revision: 89
 authority: router
 lifecycle: mustflow-owned
 ---
@@ -101,6 +101,9 @@ routes. Event routes stay inactive until their event occurs.
 | A coding task has missing intent, scope, domain, data, security, UX, dependency, architecture, or verification decisions that cannot be safely inferred from repository evidence | `.mustflow/skills/clarifying-question-gate/SKILL.md` | User request, inspected repository evidence, unresolved decisions, reversibility classification, recommended option, and tradeoffs | Blocking questions, safe assumptions, and the smallest safe implementation boundary | over-questioning, lazy questions, expensive wrong assumptions, user-owned decision drift, data loss, auth bypass, public-contract drift, dependency bloat, or unverifiable completion | `changes_status`, `changes_diff_summary`, `mustflow_check` | Repository evidence inspected, blocking questions with recommendations, safe assumptions, selected scope, verification, and remaining ambiguity |
 | HTTP, REST, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, request/response schema, status code, header, error envelope, pagination, filtering, sorting, search, generated client, SDK, mock, fixture, or API docs contract is created or changed | `.mustflow/skills/api-contract-change/SKILL.md` | API style, contract source of truth, changed operations, request and response schemas, status and headers, error envelope, auth and permission behavior, pagination/filter/sort/search semantics, generated clients, SDKs, mocks, fixtures, callers, docs, and command contract entries | Routes, handlers, resolvers, validators, schemas, generated clients, SDKs, mocks, fixtures, docs, tests, and directly synchronized examples | route-only change, schema drift, generated-client breakage, hidden breaking change, status or error drift, pagination/search semantic drift, auth/permission drift, or stale docs examples | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | API contract source, changed operations, compatibility classification, synchronized client/schema/docs/tests surfaces, verification, and remaining API contract risk |
 | C++ source, headers, modules, native build metadata, toolchains, package managers, public headers, shared or static libraries, ABI surfaces, generated bindings, FFI, tests, or benchmarks are created or changed | `.mustflow/skills/cpp-code-change/SKILL.md` | Owning target, compilation identity, build front door, changed consumed surface, public API/ABI/FFI/binding surfaces, ownership and lifetime contracts, and command contract entries | C++ source, headers, modules, build metadata, package metadata, generated bindings, FFI code, tests, benchmarks, and directly synchronized docs | target drift, source API break, binary ABI break, undefined behavior, lifetime bug, build-graph drift, generated-binding drift, FFI memory bug, unverified modern C++ feature, or false performance claim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Owning target, compilation identity, highest compatibility risk, ownership/lifetime/UB/concurrency notes, public API/ABI/FFI/binding impact, verification, and remaining C++ risk |
+| Node.js runtime code, package manager ownership, module format, package entry metadata, native dependencies, Node test runner behavior, TypeScript execution mode, or deployment runtime support is created or changed | `.mustflow/skills/node-code-change/SKILL.md` | Node version signals, package manager and lockfile owner, module/package metadata, TypeScript loader, test runner, native dependency, deployment target, and command contract entries | Node runtime code, package metadata, lockfiles, scripts, CI or Docker runtime declarations, test runner config, native dependency handling, docs examples, and directly synchronized package surfaces | newest-Node assumption, package manager drift, ESM/CJS break, blocked deep import, native dependency break, Node native TypeScript overclaim, test runner migration risk, deployment mismatch, or permission-model overclaim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Runtime and package manager decision, module/package entry notes, TypeScript/test runner notes, native/deployment risks, verification, and remaining Node.js risk |
+| Bun runtime code, Bun package manager behavior, `bun.lock`, `bunfig.toml`, Bun test runner behavior, Bun bundling, Bun TypeScript execution, or Bun-specific APIs are created or changed | `.mustflow/skills/bun-code-change/SKILL.md` | Bun role signals, `package.json`, Bun and non-Bun lockfiles, `bunfig.toml`, CI/Docker Bun setup, TypeScript config, Bun APIs, native dependency signals, and command contract entries | Bun runtime code, Bun package manager metadata, lockfiles, `bunfig.toml`, scripts, tests, bundler config, TypeScript/declaration pipeline, package metadata, and directly synchronized docs | Bun role confusion, lockfile drift, trusted dependency overgrant, runtime/package-manager conflation, Bun TypeScript typecheck overclaim, Bun build declaration gap, Node compatibility break, shebang mismatch, or native binary break | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Bun role classification, lockfile/trust notes, runtime/type/build/test notes, Node compatibility risks, verification, and remaining Bun risk |
+| Dockerfiles, `.dockerignore`, Docker Compose files, BuildKit or buildx behavior, container image metadata, tags, entrypoints, health checks, Docker CI workflows, image security scanning, SBOM or provenance settings, registry publishing, or container runtime validation are created or changed | `.mustflow/skills/docker-code-change/SKILL.md` | Docker surfaces, project image shape, base image and platform signals, build context and cache signals, runtime contract, security and supply-chain contract, and command contract entries | Dockerfiles, `.dockerignore`, Compose files, container CI workflow snippets, image metadata, package tests, docs examples, template metadata, and directly synchronized skill routes | cache breakage, secret leak, root runtime, host access escape, dev dependency in final image, mutable tag drift, untrusted CI publish, missing SBOM/provenance, unverified runtime, or false production-readiness claim | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Docker surface classification, image/base/cache/stage decisions, secret/user/runtime/Compose/CI supply-chain notes, verification, and remaining Docker risk |
 | TypeScript source, declarations, tsconfig, package exports, module resolution, public API, or TypeScript tests are created or changed | `.mustflow/skills/typescript-code-change/SKILL.md` | TypeScript config, package entry metadata, target runtime, changed files, and command contract entries | TypeScript source, declarations, compiler config, exports, tests, and directly synchronized docs | weakened type safety, module drift, public API drift, or unverified declaration output | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, module, type, and public API boundary checked, changes made, verification, and remaining TypeScript risk |
 | JavaScript source, module format, package entry, browser or Node runtime, dependency usage, Promise handling, bundler config, or JavaScript tests are created or changed | `.mustflow/skills/javascript-code-change/SKILL.md` | Package metadata, module system, runtime target, entrypoints, changed files, and command contract entries | JavaScript source, package exports, bundler config, dependencies, tests, and docs examples | runtime API leakage, ESM/CJS drift, discarded Promise, dependency bloat, or broken package entry | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime and module boundary checked, async and dependency notes, verification, and remaining JavaScript risk |
 | Python source, package metadata, runtime version, import layout, type checking, linting, CLI entry points, or tests are created or changed | `.mustflow/skills/python-code-change/SKILL.md` | Python version source, packaging files, import layout, lint/type/test config, changed files, and command contract entries | Python source, packaging metadata, imports, type hints, tests, and docs examples | unsupported syntax, import hacks, packaging drift, swallowed errors, or weakened lint/type checks | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, packaging, import, and type boundary checked, verification, and remaining Python risk |

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

@@ -0,0 +1,143 @@
+---
+mustflow_doc: skill.bun-code-change
+locale: en
+canonical: true
+revision: 1
+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.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.bun-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Bun Code Change
+
+<!-- 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.
+
+<!-- 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 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.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Bun appears only as the local command used by mustflow's configured command intents, and the changed project surface is not Bun-specific.
+- The task changes generic TypeScript type modeling or declaration surfaces without Bun runtime, bundler, package manager, or test runner behavior; use `typescript-code-change`.
+- The task changes generic JavaScript without Bun ownership; use `javascript-code-change`.
+- Elysia route, schema, plugin, OpenAPI, or Eden behavior is the main surface; use `elysia-code-change` first and this skill only for Bun runtime or tooling risks.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `package.json` fields: `packageManager`, `scripts`, `workspaces`, `trustedDependencies`, `overrides`, `resolutions`, `patchedDependencies`, `dependencies`, `devDependencies`, `optionalDependencies`, and package entry metadata.
+- 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.
+- 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 -->
+## Preconditions
+
+- Classify Bun's role before editing. Bun may be only the package manager, only the script runner, only the test runner, only the bundler, the runtime, or several of these at once.
+- 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.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- 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.
+- 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 -->
+## Procedure
+
+1. Classify every Bun signal by role before editing:
+   - `bun install`, `bun add`, `bun remove`, `bun update`, `bun.lock`, `trustedDependencies`, and `[install]` are package manager signals.
+   - `bun <file>`, `bun --watch`, `bun run --bun`, `#!/usr/bin/env bun`, `Bun.serve`, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.$`, and preload settings are runtime signals.
+   - `bun test`, `bun:test`, and `[test]` are test runner signals.
+   - `bun build`, `Bun.build`, `--compile`, and build target settings are bundler or compiler signals.
+   - `bun run <script>` is script execution until the script body proves a more specific role.
+2. Determine package manager ownership from `packageManager`, Bun lockfiles, other lockfiles, CI, Docker, workspace config, and `bunfig.toml`. If `bun.lock` exists, treat Bun as the dependency owner unless current project evidence says otherwise.
+3. Do not delete `bun.lockb`, create `bun.lock`, or switch between npm, pnpm, Yarn, and Bun lockfiles as a side effect. If multiple lockfiles exist, identify whether the state is migration, legacy compatibility, or intentional parallel ownership before editing dependencies.
+4. For Bun installs, check frozen lockfile behavior, workspace filters, linker mode, global virtual store, cache settings, registry settings, overrides, resolutions, patched dependencies, peer dependency behavior, optional dependency behavior, OS, CPU, and libc-sensitive packages when relevant.
+5. Treat `trustedDependencies` as install-time code execution policy. Omitted, explicit array, and empty array each have different trust semantics. Do not broaden trust with a generic trust-all action. If a native package or binary install fails, inspect blocked lifecycle scripts, trust only the required package, and verify with a fresh install and real import or CLI use when a configured intent exists.
+6. Do not claim Bun runs TypeScript as typecheck. Bun runtime execution and `Bun.Transpiler` strip or transform syntax for execution; they do not run the TypeScript checker, emit declarations, or prove generic, JSX, path alias, or public type correctness.
+7. Do not claim Bun bundling replaces TypeScript build output. Bun build output proves bundling for the selected target and format, not `tsc --noEmit`, declaration emit, or downstream TypeScript consumer compatibility.
+8. For TypeScript changes in a Bun project, keep the existing typecheck intent and declaration pipeline. For libraries, inspect declaration output when package exports, path aliases, public types, or build output change. Source-only aliases must not leak into public declarations unless consumers can resolve them.
+9. Align Bun and TypeScript JSX settings when JSX runtime, factory, fragment, or import source changes. TypeScript seeing one JSX runtime while Bun transpiles another is a runtime contract bug.
+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.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Bun's role is explicit: package manager, runtime, script runner, test runner, bundler, transpiler, or mixed.
+- 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.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `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.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If Bun's role is unclear, stop changing runtime or dependency behavior and inspect scripts, lockfiles, `bunfig.toml`, CI, Docker, and entrypoints.
+- 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 native dependency, lifecycle script, or trusted dependency change cannot be verified, keep the change scoped and report release-sensitive risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Bun role classification
+- Package manager, lockfile, and trust notes
+- Runtime, TypeScript, bundler, and test runner notes
+- Native, shebang, Node compatibility, or package consumer risks
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Bun risk

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

@@ -0,0 +1,262 @@
+---
+mustflow_doc: skill.docker-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: docker-code-change
+description: Apply this skill when Dockerfiles, .dockerignore files, Docker Compose files, BuildKit or buildx behavior, container image metadata, image tags, container entrypoints, health checks, Docker-based CI workflows, image security scanning, SBOM or provenance settings, registry publishing, or container runtime validation are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.docker-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Docker Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Prevent container image accidents by preserving reproducibility, secret safety, cache behavior,
+runtime correctness, development and production separation, and supply-chain evidence.
+
+This skill is not a Docker syntax guide. It is a safety procedure for changing Docker-based
+application images and local container workflows without silently weakening build, runtime, CI,
+or security contracts.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `Dockerfile`, `Dockerfile.*`, `.dockerignore`, `compose.yaml`, `compose.yml`,
+  `docker-compose*.yml`, or Compose override files are created or changed.
+- Base images, image tags, digest pinning, package-manager install layers, build contexts,
+  multi-stage boundaries, `ENTRYPOINT`, `CMD`, `USER`, `HEALTHCHECK`, `EXPOSE`, labels,
+  environment variables, or build arguments change.
+- BuildKit, buildx, build targets, cache mounts, external cache, multi-platform image builds,
+  Docker-based CI workflows, image publish behavior, registry tags, SBOM, provenance,
+  signing, or image vulnerability scanning changes.
+- Local development Compose services such as databases, Redis, queues, object stores,
+  mail capture, optional debug tools, profiles, volumes, networks, env files, init scripts,
+  or migration jobs change.
+- A language-specific runtime skill mentions Docker base images, native dependency image
+  behavior, container deployment support, or Docker runtime declarations.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes application code that happens to run inside an unchanged container;
+  use the matching language or framework skill.
+- The task only changes generic environment variables, secrets, or deployment settings
+  outside Docker or Compose; use `config-env-change` or the narrower deployment skill.
+- The task designs Kubernetes, ECS, Cloud Run, Nomad, service mesh, registry administration,
+  autoscaling, backup, ingress, TLS, or cloud platform resources beyond verifying that an
+  image is deployable.
+- The task only addresses shell process execution or filesystem path handling outside
+  container files; use `process-execution-safety`, `file-path-cross-platform-change`, or
+  `cross-platform-filesystem-safety`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Container surfaces: Dockerfiles, `.dockerignore`, Compose files, CI workflow files,
+  build scripts or command-contract entries, release workflow files, and registry metadata
+  touched by the change.
+- Project classification: runtime-source app, compiled artifact app, JVM artifact app,
+  static frontend, multi-service app, or mixed image set, with language examples such as
+  Node, Bun, Python, PHP, Go, Rust, C++, and Java.
+- Base image and platform signals: image names, tags, digests, OS family, libc expectations,
+  CPU architecture, native dependencies, required CA certificates, time zone, shell, package
+  manager, and runtime user needs.
+- Build and cache signals: build context, `.dockerignore`, lockfiles, package-manager cache
+  paths, BuildKit mount needs, stage names, build targets, external cache ownership, and
+  CI event or branch conditions.
+- Runtime contract: `USER`, file ownership, writable paths, `ENTRYPOINT`, `CMD`, signal
+  handling, health checks, ports, logs, config injection, read-only filesystem expectations,
+  volumes, and smoke-test path.
+- Security and supply-chain contract: secrets, SSH keys, private registry tokens, Docker socket
+  access, privileged mode, host namespace or host path access, capabilities, security options,
+  vulnerability scan gate, SBOM, provenance, signing, and digest reporting.
+- Configured command intents that can validate syntax, build output, tests, docs, release
+  packaging, and mustflow workflow alignment. Report missing Docker-specific verification
+  intents instead of inventing raw Docker commands.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Classify whether the change affects local development only, CI validation, release images,
+  registry publishing, or deployable runtime behavior before editing.
+- Do not optimize a Dockerfile by blindly minimizing line count or image size. Preserve
+  reproducibility, secret safety, cache behavior, runtime correctness, and dev/prod separation
+  first.
+- Treat Dockerfiles, Compose files, and Docker CI workflows as security-sensitive when they
+  can alter credentials, registry writes, host access, runtime privileges, or supply-chain
+  attestations.
+- Do not assume Docker, buildx, Compose, Scout, Trivy, Grype, or registry credentials are
+  available unless the repository exposes a configured one-shot command intent or the user
+  explicitly accepts an unverified manual path.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update Dockerfiles, `.dockerignore`, Compose files, container-related CI workflow snippets,
+  image metadata, package tests, docs examples, template metadata, and directly synchronized
+  skill routes required by the container contract.
+- Add or tighten non-root runtime users, stage names, `.dockerignore` exclusions, cache-safe
+  copy order, BuildKit secret or cache requirements, health checks, labels, and Compose local
+  dependency wiring when the current project evidence supports the change.
+- Add focused tests or assertions only when they encode the changed container, template,
+  package, or workflow contract.
+- Do not add broad deployment platform design, registry administration, long-running server
+  instructions, raw publish commands, credential material, or command permission to a skill
+  document.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the changed surface: Dockerfile, `.dockerignore`, Compose, CI build workflow,
+   image publish workflow, image metadata, security scan, SBOM/provenance, or runtime smoke
+   path. If several surfaces changed, name the source of truth for each.
+2. Classify the image shape before choosing structure:
+   - Runtime-source apps keep source plus production runtime dependencies.
+   - Compiled artifact apps should usually copy only the binary and required runtime files.
+   - JVM artifact apps should build with a JDK and run with a JRE or equivalent runtime image.
+   - Static frontends should copy only built assets into the serving image when applicable.
+3. Choose base images deliberately. Prefer trusted versioned images over mutable `latest`.
+   Use Debian slim as a conservative default for native dependency compatibility; use Alpine
+   only after libc and native package behavior are verified; use distroless or `scratch` only
+   when CA certificates, time zone, passwd or non-root identity, shell absence, and debugging
+   tradeoffs are explicit.
+4. Treat digest pinning as a reproducibility choice with an update obligation. If a production
+   sample pins a digest, also report the need for an update mechanism such as dependency update
+   automation, base-image rebuild checks, or a scanner policy.
+5. Preserve build cache boundaries. Keep build context small, copy dependency manifests and
+   lockfiles before application source, avoid copying host dependency directories, and keep
+   package-manager caches out of final images. Do not move `COPY . .` above dependency install
+   layers unless the project has no cache-sensitive dependency step.
+6. Check `.dockerignore` whenever build context changes. Exclude VCS metadata, local dependency
+   directories, virtual environments, build output, coverage, caches, local databases, `.env`,
+   credential files, keys, and other files not required by the build.
+7. Use multi-stage boundaries only when they buy cache, artifact, security, or test-target value.
+   Name stages instead of relying on numeric indexes. Remove stages that merely rename the same
+   base without changing cache behavior, artifact flow, runtime base, or verification target.
+8. Ensure final images contain only runtime requirements. Do not leave compilers, package managers,
+   test fixtures, source maps, caches, `git`, `curl`, shell tools, or dev dependencies in final
+   images unless the runtime contract explicitly requires them.
+9. Handle secrets as a hard boundary. Do not put tokens, passwords, SSH keys, cloud credentials,
+   `.npmrc`, `.pypirc`, `.env`, or private registry credentials into `ARG`, `ENV`, labels,
+   image layers, build logs, copied files, or command history. Prefer BuildKit secret or SSH
+   mounts when a configured workflow supports them, and report missing secret-mount verification
+   when it does not.
+10. Preserve runtime correctness. Verify non-root user intent, file ownership, writable paths,
+   entrypoint and command shape, PID 1 signal handling, exposed and published ports, logs to
+   stdout or stderr, health check command availability, required environment variables, and
+   read-only filesystem expectations.
+11. Treat `USER` as a runtime proof obligation, not a text check. If the final image runs as
+   non-root, make sure copied files and runtime write paths are owned or writable by that user.
+   If that cannot be verified, report the missing run evidence.
+12. Keep Compose scoped. Use Compose for local development, integration tests, and narrow
+   production-like checks. Do not turn Compose into a full orchestrator design for TLS,
+   autoscaling, backups, ingress, secret rotation, or platform rollout strategy.
+13. For Compose dependencies, distinguish container start from service readiness. Prefer
+   health checks for databases and queues, app-level retry for runtime dependency loss, named
+   volumes for persistent local data, bind mounts for editable source, profiles for optional
+   tools, and one-shot migration services rather than hiding app migrations inside database
+   image entrypoints.
+14. Review Compose trust and host access. Treat `privileged`, Docker socket mounts, host
+   networking, host PID or IPC namespaces, broad host-path mounts, root users, broad port
+   binding, unconfined security profiles, and missing resource limits as high-risk changes
+   requiring explicit justification.
+15. For CI, separate test builds from publish builds. PR and fork events should not push images,
+   receive registry credentials, write production caches, sign artifacts, or use deployment
+   secrets. Release tags or protected default-branch jobs may publish only after the configured
+   verification path succeeds.
+16. Keep cache ownership safe in CI. Do not let untrusted PRs overwrite default-branch cache
+   refs. Use branch- or event-scoped cache references when the workflow supports external cache.
+   Report cache poisoning risk when the workflow writes shared caches from untrusted code.
+17. Keep image tags traceable. Use immutable commit or digest evidence for deployable artifacts.
+   Treat `latest` as a moving pointer, not a release identity. Release workflows should record
+   the pushed digest and update floating tags only from release or protected branch events.
+18. For release images, require SBOM and provenance when the configured workflow supports them.
+   Report when local-only image loads cannot carry registry attestations and when final published
+   digests were not rechecked after push.
+19. Choose verification through configured intents first. If Docker-specific syntax, build,
+   smoke, inspect, history, vulnerability scan, SBOM, provenance, multi-arch, or registry-pull
+   verification is needed but not configured, report the missing intent instead of running an
+   inferred command.
+20. When reporting completion, separate source edits, image-build evidence, runtime evidence,
+   security scan evidence, supply-chain evidence, registry evidence, and skipped checks. Do not
+   claim a container image is production-ready from source inspection or a successful build alone.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The image shape, base image choice, cache order, stage boundaries, and build context are
+  deliberate and aligned with the language or runtime contract.
+- Secrets are not introduced into Dockerfile instructions, Compose environment, image layers,
+  command history, logs, SBOM, or provenance metadata.
+- Final runtime images avoid root execution and unnecessary build tools unless explicitly justified.
+- Compose remains local or narrowly production-like, with host access and privileged settings
+  justified or rejected.
+- CI image builds separate test, cache, publish, tag, SBOM, provenance, and registry credentials
+  according to event trust.
+- Docker-specific verification evidence is recorded, or missing configured intents are reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Report missing Dockerfile lint, Compose config validation, buildx check, image build, container
+start, health or smoke test, image inspect, history secret scan, vulnerability scan, SBOM,
+provenance, multi-platform manifest, registry push, registry pull, or digest verification intents
+when those surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a build succeeds but runtime start, health, smoke, or non-root write behavior is unverified,
+  report the image as built but not runtime-verified.
+- If a secret appears in `ARG`, `ENV`, copied files, image history, logs, or attestation metadata,
+  remove the leak path before optimizing cache or image size.
+- If Alpine, distroless, or `scratch` breaks native dependencies, CA certificates, time zones,
+  shell availability, or non-root identity, restore a compatible runtime base or report the
+  missing runtime requirement.
+- If Compose uses Docker socket, privileged mode, host namespaces, broad host mounts, root users,
+  or broad port exposure without explicit justification, treat the change as unsafe.
+- If CI publish behavior is triggered from untrusted events, forks, or ordinary PRs, fail closed
+  by disabling push or credentials for that path and report the publish boundary.
+- If Docker-specific tools or registries are unavailable under the command contract, do not invent
+  manual commands; report the missing verification intent and remaining risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Docker surface classification
+- Image shape, base image, cache, and stage decisions
+- `.dockerignore`, secret, user, entrypoint, health, port, and runtime notes
+- Compose trust, volume, network, env, readiness, and migration notes
+- CI cache, tag, publish, SBOM, provenance, registry, and event-trust notes
+- Files changed
+- Command intents run
+- Skipped Docker-specific checks and reasons
+- Remaining Docker risk

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

@@ -0,0 +1,145 @@
+---
+mustflow_doc: skill.node-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: node-code-change
+description: Apply this skill when Node.js runtime code, package manager ownership, module format, package entry metadata, native dependencies, Node test runner behavior, TypeScript execution mode, or deployment runtime support is created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.node-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Node Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve the actual Node.js runtime, module, package manager, TypeScript execution, test runner, package entry, native dependency, and deployment boundaries.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Node.js runtime code, `node:*` APIs, `process`, `Buffer`, streams, workers, child processes, native addons, Node permission flags, Node test runner behavior, package entry metadata, or deployment runtime support changes.
+- `package.json` Node fields change, including `engines.node`, `devEngines`, `packageManager`, `type`, `main`, `exports`, `imports`, `types`, `typesVersions`, `files`, `bin`, `sideEffects`, or `workspaces`.
+- Node version signals, CI Node setup, Docker Node base images, serverless Node runtime settings, Corepack usage, npm, pnpm, Yarn, or lockfile ownership changes.
+- The task proposes native Node TypeScript execution, ESM/CJS conversion, conditional exports, package manager migration, or Node built-in test runner migration.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes TypeScript type modeling, validators, declarations, or `.ts` source without Node runtime or package entry impact; use `typescript-code-change`.
+- The task only changes plain JavaScript without Node-specific runtime, package, or deployment behavior; use `javascript-code-change`.
+- Bun owns the runtime, package manager, test runner, or bundler behavior being changed; use `bun-code-change`.
+- A narrower framework skill owns the changed route or handler surface, unless Node runtime, package, or deployment behavior is also affected.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Node version signals: `.nvmrc`, `.node-version`, `.tool-versions`, Volta or mise/asdf config, `package.json#engines.node`, `package.json#devEngines`, CI Node matrix, Docker `FROM node:*`, and deployment runtime config.
+- Package ownership signals: `package.json#packageManager`, npm, pnpm, Yarn, Bun, or vlt lockfiles, workspace config, `.npmrc`, `.yarnrc.yml`, Corepack usage, CI install commands, and Docker install commands.
+- Module and package metadata: nearest `package.json#type`, file extensions, `main`, `module`, `exports`, `imports`, `types`, `typings`, `typesVersions`, `files`, `bin`, `sideEffects`, and documented import paths.
+- TypeScript and loader signals: `tsconfig*.json`, `tsx`, `ts-node`, SWC, Babel, Vite, tsup, esbuild, Node native type stripping, path aliases, declaration output, and test or build transforms.
+- Test, native, and deployment signals: package scripts, test runner config, `node:test` usage, native dependency indicators such as `.node`, `binding.gyp`, `node-gyp`, lifecycle scripts, optional dependencies, serverless or edge config, and command contract entries.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine the effective Node runtime before using newer syntax, APIs, or flags.
+- Determine package manager ownership before editing dependencies or lockfiles.
+- Determine Node's actual module loading path before changing imports, file extensions, or package entry metadata.
+- Treat package entry, engine, and lockfile changes as public contract or release-sensitive changes unless proven internal.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep runtime-specific Node APIs in Node-owned files or adapters.
+- Keep package manager changes aligned with the owner already used by CI, Docker, and lockfiles.
+- Keep ESM, CJS, and dual package boundaries explicit and synchronized with declarations, tests, docs examples, and consumer entrypoints.
+- Preserve existing TypeScript build, typecheck, declaration, and loader pipelines unless the task explicitly asks to replace them.
+- Add or update focused tests only when they protect the changed runtime, package, module, native, or deployment contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read runtime version signals before editing. Treat deployment runtime as the hard constraint, CI runtime as the verified constraint, `engines.node` as the compatibility contract, and local version files as developer hints. If these conflict, report the conflict before introducing APIs or syntax that depend on one side.
+2. Do not assume Node Current. Use Current-only APIs only when local tooling, CI, Docker, deployment, package metadata, and intended consumers all prove support for that Current major. For production applications, prefer Active LTS or Maintenance LTS when the project does not declare otherwise.
+3. Determine package manager ownership from `packageManager`, lockfiles, workspace config, CI, and Docker. If `packageManager` and lockfiles disagree, or multiple lockfiles exist, do not rewrite dependencies until the owner and migration intent are clear.
+4. Keep package manager semantics distinct:
+   - npm dependency changes update `package.json` and npm lockfiles; clean CI installs use npm's clean-install mode.
+   - pnpm workspaces and frozen lockfile behavior can affect every workspace even when one package changed.
+   - Yarn PnP, Zero-Install, and immutable installs can make `node_modules` assumptions wrong.
+   - Corepack availability depends on the Node/runtime environment; do not assume it exists in every Node version, image, or CI runner.
+5. Determine Node module loading from Node rules, not preference or `tsconfig` alone. `.mjs` and `.mts` are ESM, `.cjs` and `.cts` are CommonJS, and `.js` or `.ts` follows the nearest package `type` after the project's loader/build path is considered.
+6. Treat `type`, `main`, `exports`, `imports`, file extensions, and conditional export changes as package entry contract changes. Adding `exports` can block deep imports and should be classified as compatibility-sensitive unless all previously supported paths remain exported or the release is intentionally breaking.
+7. For conditional exports, keep condition order deliberate, include a `default` fallback when multi-runtime or bundler consumers are intended, and avoid splitting `import` and `require` into separate stateful implementations unless dual package hazards are tested.
+8. For `imports`, use `#` aliases only for package-internal paths, and keep TypeScript paths, bundler aliases, test runner aliases, and declaration output aligned.
+9. For JSON imports, `require(esm)`, top-level await, `.mts`, `.cts`, `.d.mts`, and `.d.cts`, verify the minimum Node version, TypeScript module resolution, generated output, and consumer path before changing code.
+10. Do not replace an existing TypeScript pipeline with native Node TypeScript execution unless the task explicitly asks for that migration. Node native TypeScript execution is limited type stripping; it does not typecheck, read `tsconfig`, resolve path aliases, emit declarations, downlevel syntax, transform decorators or enums, or support TSX as a full build pipeline.
+11. If native Node TypeScript execution is intentionally used, keep syntax erasable-only, use `import type` for type-only imports, avoid runtime TypeScript features that require transforms, and keep the configured typecheck/build pipeline for application and library code.
+12. Detect the actual test runner from scripts, config files, dependencies, and CI. Do not migrate Jest, Vitest, Playwright, or another runner to `node:test` just because Node has a built-in runner. Watch, coverage, mock, snapshot, worker, and cleanup behavior are runner-specific.
+13. Treat watch mode and snapshot update modes as development or review actions, not final verification. Use the configured oneshot intents and report when no configured runner-specific intent exists.
+14. Before using Node APIs in deployment code, classify the target as Node server, Docker, serverless Node, edge runtime, static build, or multi-runtime package. Edge runtimes are not full Node.js runtimes.
+15. Inspect native and install-sensitive dependencies when package metadata or runtime imports touch `.node`, `binding.gyp`, `node-gyp`, `preinstall`, `install`, `postinstall`, `prepare`, optional dependencies, peer dependencies, OS, CPU, libc, or Node ABI boundaries.
+16. Treat optional dependencies and optional peers as absent until code handles absence. Do not require optional packages directly without fallback or error handling that matches the existing project pattern.
+17. Treat the Node permission model as a trusted-code seatbelt, not a sandbox for untrusted code. If permission flags are introduced or changed, map required filesystem, network, child process, worker, native addon, WASI, inspector, and temporary directory access explicitly.
+18. Choose configured verification intents that cover lint, build, tests, package metadata, release-sensitive package output, docs examples, and mustflow contract checks when available. Report missing consumer fixture, ESM, CJS, TypeScript consumer, native dependency, deployment, or permission verification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Effective Node runtime and package manager ownership are known or explicitly reported as conflicting.
+- Module and package entry changes are synchronized with declarations, tests, docs examples, and consumer surfaces when relevant.
+- Native TypeScript execution is not mistaken for typecheck, declaration emit, or a full build pipeline.
+- Node-only APIs do not leak into browser, edge, Bun, or shared package surfaces unintentionally.
+- Native dependency, lifecycle, optional dependency, and permission-model risks are handled or reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Report missing ESM/CJS consumer, declaration output, package artifact, frozen install, native dependency, deployment runtime, permission-model, or runner-specific verification intents when those surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If runtime signals conflict, do not resolve the conflict by assuming the newest Node version.
+- If package manager ownership conflicts, do not add, remove, or migrate dependencies until the owner is clear.
+- If a package entry change blocks a documented or previously supported import path, restore compatibility or report the breaking-change requirement.
+- If native Node TypeScript execution fails, repair the build/loader boundary instead of weakening typecheck or deleting the TypeScript pipeline.
+- If native dependency installation or optional dependency behavior is unclear, classify the change as release-sensitive and report the missing install or runtime evidence.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Runtime and package manager decision
+- Module and package entry notes
+- TypeScript execution and test runner notes
+- Native, lifecycle, deployment, or permission risks
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Node.js risk

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

@@ -120,6 +120,24 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
 
+[routes."node-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
+
+[routes."bun-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "package_metadata_change"]
+
+[routes."docker-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "security_change", "package_metadata_change", "release_risk"]
+
 [routes."api-contract-change"]
 category = "general_code"
 route_type = "primary"

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.25.2"
+version = "2.27.0"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -21,15 +21,18 @@ creates = [
   ".mustflow/skills/codebase-orientation/SKILL.md",
   ".mustflow/skills/clarifying-question-gate/SKILL.md",
   ".mustflow/skills/astro-code-change/SKILL.md",
+  ".mustflow/skills/bun-code-change/SKILL.md",
   ".mustflow/skills/css-code-change/SKILL.md",
   ".mustflow/skills/cpp-code-change/SKILL.md",
   ".mustflow/skills/dart-code-change/SKILL.md",
+  ".mustflow/skills/docker-code-change/SKILL.md",
   ".mustflow/skills/elysia-code-change/SKILL.md",
   ".mustflow/skills/flutter-code-change/SKILL.md",
   ".mustflow/skills/go-code-change/SKILL.md",
   ".mustflow/skills/hono-code-change/SKILL.md",
   ".mustflow/skills/html-code-change/SKILL.md",
   ".mustflow/skills/javascript-code-change/SKILL.md",
+  ".mustflow/skills/node-code-change/SKILL.md",
   ".mustflow/skills/python-code-change/SKILL.md",
   ".mustflow/skills/rust-code-change/SKILL.md",
   ".mustflow/skills/svelte-code-change/SKILL.md",
@@ -129,15 +132,18 @@ minimal = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -182,15 +188,18 @@ patterns = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -246,15 +255,18 @@ oss = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -323,15 +335,18 @@ team = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -388,15 +403,18 @@ product = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",
@@ -458,15 +476,18 @@ library = [
   "codebase-orientation",
   "clarifying-question-gate",
   "astro-code-change",
+  "bun-code-change",
   "css-code-change",
   "cpp-code-change",
   "dart-code-change",
+  "docker-code-change",
   "elysia-code-change",
   "flutter-code-change",
   "go-code-change",
   "hono-code-change",
   "html-code-change",
   "javascript-code-change",
+  "node-code-change",
   "python-code-change",
   "rust-code-change",
   "svelte-code-change",