mustflow 2.22.16 → 2.22.46

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

@@ -0,0 +1,179 @@
+---
+mustflow_doc: skill.dart-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: dart-code-change
+description: Apply this skill when Dart source, pub package metadata, null safety, async Futures or Streams, isolates, analyzer lints, tests, CLI entry points, or public package APIs are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.dart-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Dart Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Dart null-safety, async, stream, isolate, package API, analyzer, and test boundaries. Treat `!`, `late`, `dynamic`, broad casts, `.cast<T>()`, `.asBroadcastStream()`, and `unawaited()` as risk markers, not fixes.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.dart`, `pubspec.yaml`, `analysis_options.yaml`, lockfiles, `lib`, `bin`, `test`, `example`, or public exports change.
+- The task touches nullable types, `!`, `late`, `dynamic`, casts, raw generics, `Future`, `Stream`, `StreamController`, `StreamSubscription`, isolates, analyzer lints, pub package layout, package exports, `bin` entrypoints, README examples, or package versioning.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is Flutter widget or platform UI behavior; use `flutter-code-change` and this skill only as an adjunct for shared Dart package/API risk.
+- Dart files are read only for orientation.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `pubspec.yaml`, analyzer config, package layout, public export files, `lib/src` exports, examples, README snippets, CLI entrypoints, tests, and lockfile policy.
+- Existing null-safety, async, exception, and package API conventions.
+- SDK constraints, dependency constraints, executables, public dependency types, and versioning policy when package API changes.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Identify whether the change affects public exports, `lib/src` exposure, internal implementation, CLI behavior, async lifecycle, package metadata, or tests.
+- Treat nullable values, decoded data, map lookups, user input, streams, subscriptions, ports, and isolate messages as boundaries that need explicit ownership and validation.
+- Classify any public nullability, callback, `Future<T>`, `Stream<T>`, generic bound, or default-value change before editing.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Narrow nullable values at boundaries and keep core logic non-null where truthful.
+- Use `unawaited` only when detached behavior is intentional, documented, and has local error handling.
+- Cancel subscriptions, close controllers, and document isolate message shape where relevant.
+- Keep public API changes synchronized with examples and docs.
+- Strengthen analyzer boundaries when the project already uses strict linting; do not weaken analyzer or lint rules to pass the current patch.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read package metadata, analyzer config, public exports, nearby implementation, tests, and examples.
+2. Classify the touched boundary: nullability, public API, package layout, async `Future`, `Stream`, isolate, exception mapping, or test-only.
+3. Identify every nullable boundary: JSON decode, HTTP response, DB row, environment variable, CLI args, platform channel, isolate message, external callback, cache miss, map lookup, and dependency lookup.
+4. Accept external or decoded data as `Object?` at the boundary, validate it in a parser or codec layer, and let only typed domain objects leave that boundary. Do not let `dynamic` flow into internal code.
+5. Distinguish missing optional data from invalid required data. Optional business facts may stay nullable; required facts should be validated once and remain non-nullable afterward.
+6. Do not use `!`, `dynamic`, `late`, broad `as` casts, raw generic types, or `.cast<T>()` as shortcuts around design uncertainty.
+7. Allow `!` only when the same local block has a visible guard proving non-null and flow analysis cannot express it. Prefer early return, throw, or local-variable promotion.
+8. Avoid `late` fields for initialization-order problems. Prefer constructor injection, async factory construction, explicit state objects, or stored `Future<T>` initialization. `late final` still needs read-after-initialize evidence when public behavior depends on it.
+9. Replace broad JSON and collection casts with checked parsers that report the failing field path when feasible.
+10. Ensure every `Future` is awaited, returned, stored for later awaiting or cancellation, or intentionally detached with documented `unawaited` plus local error handling.
+11. Use `Future<void>` for public async APIs that complete later or can fail but do not produce a value. Avoid public `void async` except where a framework callback type requires it.
+12. Ensure every stream subscription, controller, sink, timer, socket, file watcher, receive port, or isolate has an owner and explicit shutdown path. Await cleanup futures when the API exposes them.
+13. Do not use `.asBroadcastStream()` to hide accidental multiple listens. Determine whether the source is truly broadcast, or create an explicit fan-out owner.
+14. For `StreamController`, connect external resource creation and pause/resume/cancel behavior to the controller lifecycle when buffering or resource usage matters.
+15. For `async*` functions wrapping external resources or upstream subscriptions, release resources in a `finally` path.
+16. For long-lived isolates, define startup, request and response message shapes, error propagation, shutdown messages, receive-port closing, and isolate termination.
+17. Do not import another package's `src` implementation. Treat symbols exported from this package's public libraries as public API even when their files live under `lib/src`.
+18. If public exports change, update examples, README snippets, CLI smoke surfaces, and tests that represent consumer behavior when present.
+19. Choose configured verification intents that cover analyzer, formatting, tests, package build, dependency bounds, publish dry-run, examples, CLI behavior, and public API risk when available.
+
+<!-- mustflow-section: null-safety-policy -->
+## Null-Safety Policy
+
+- `!`, `late`, `dynamic`, broad `as`, raw generic types, `.cast<T>()`, and nullable-to-non-nullable casts are risk markers.
+- Nullable values should be narrowed at the boundary. Core domain objects should be non-nullable when the value is required.
+- `Object?` is preferred over `dynamic` for raw external input because it forces validation before use.
+- Required fields that are missing should fail at the parser or constructor boundary. Do not make required domain fields nullable only to avoid validation.
+- `late` should not hide initialization order. Use it only when local construction or framework lifecycle makes the initialization proof clear and the risk is reported.
+- Public API nullability changes require compatibility classification before version changes.
+
+<!-- mustflow-section: async-resource-policy -->
+## Async And Resource Policy
+
+- Every future expression must be awaited, returned, stored for later awaiting or cancellation, or intentionally detached with documented `unawaited` and local error handling.
+- `unawaited` must not be used only to silence analyzer warnings. Detached work needs an error sink and a reason.
+- `Future` error handling should be attached before the future completes; prefer straightforward `await` with try/catch where local recovery is needed.
+- Every `StreamSubscription` needs an owner and a lifecycle method that cancels it.
+- Every `StreamController`, sink, timer, socket, watcher, port, or isolate needs an explicit close, cancel, kill, or shutdown path.
+- Long-lived isolates must define message contracts, errors, shutdown, port ownership, and termination behavior.
+
+<!-- mustflow-section: public-api-policy -->
+## Package Public API Policy
+
+Public surface includes importable files under `lib`, exports from the main library, exported `lib/src` symbols, public classes, functions, typedefs, extensions, enums, constructors, fields, getters, setters, generic bounds, callback signatures, future and stream element types, documented errors, and `bin` executables.
+
+- Do not treat `lib/src` as public unless a public library exports it.
+- Do not import another package's `lib/src`.
+- Nullability, required named parameters, default values, generic bounds, callback signatures, `Future<T>` and `Stream<T>` element types, dependency types in public signatures, CLI args, stdout/stderr shape, and exit codes are compatibility-sensitive.
+- If a public API exposes a dependency type, dependency constraints become part of the public contract. Check lower-bound and upper-range compatibility when configured verification exists.
+- README and `example` code are consumer smoke surfaces. Keep them aligned with public API changes.
+- CLI entries under `bin` are public behavior. Command names, args, exit codes, and output formats need compatibility review.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise the patch when any of these appear without explicit evidence and risk reporting:
+
+- New `!`, `late`, `dynamic`, raw generic types, broad `as`, `.cast<T>()`, nullable-to-non-nullable casts, or analyzer ignores used only to make errors disappear.
+- Decoded JSON, platform messages, isolate messages, CLI args, environment values, map lookups, or external callbacks trusted without boundary parsing.
+- Required domain values made nullable instead of validating the boundary.
+- A future expression is neither awaited, returned, stored, nor intentionally detached with error handling.
+- Public `void async` is added where `Future<void>` would preserve completion and error signaling.
+- Stream subscriptions, controllers, ports, timers, sockets, watchers, or isolates are created without cleanup ownership.
+- `.asBroadcastStream()` is used to hide a design problem around multiple listeners.
+- Public nullability, generic bound, callback, `Future<T>`, `Stream<T>`, export, CLI, SDK constraint, dependency constraint, or executable behavior changes without compatibility classification.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Nullability and async ownership are explicit.
+- Public package API impact is known.
+- Analyzer and tests were preserved or skipped with reason.
+- No safety boundary was hidden behind `!`, `dynamic`, `late`, casts, `unawaited`, or analyzer ignores without a risk note.
+- Examples, README snippets, CLI entrypoints, and package metadata are synchronized when public behavior changes.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing package publish or analyzer verification intents rather than inventing tool commands.
+
+When the repository exposes configured intents for these surfaces, cover strict analyzer checks, tests, package dry-run, dependency lower and upper bound checks, example or README analysis, CLI smoke behavior, and consumer-style public-import checks.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If nullable data cannot be narrowed safely, report the missing validation boundary.
+- If stream or isolate lifetime is unclear, avoid adding more asynchronous ownership until the owner is identified.
+- If public API compatibility is unclear, report the consumer risk and the changed public symbols or executables.
+- If analyzer/lint rules block the patch, fix the code or report the real boundary issue instead of weakening analysis.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Nullability, async, stream, or API notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Dart risk

package/templates/default/locales/en/.mustflow/skills/database-migration-change/SKILL.md

@@ -0,0 +1,178 @@
+---
+mustflow_doc: skill.database-migration-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: database-migration-change
+description: Apply this skill when database migration files, schema migration history, ORM schema migrations, generated clients, schema dumps, SQL snapshots, backfills, rolling deploy compatibility, expand-and-contract changes, destructive database changes, migration rollback claims, or production database migration procedures are created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.database-migration-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Database Migration Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep database migrations safe for running systems by checking deploy compatibility, data preservation, backfill behavior, generated artifacts, ORM contracts, and rollback reality.
+
+Do not treat migration authoring as "make a file that applies locally." Treat it as "old code and new code must survive the same database during rollout."
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A database migration file, migration history entry, schema dump, ORM schema, SQL snapshot, generated client, seed, fixture, schema validator, or migration documentation is created or changed.
+- A change adds, removes, renames, splits, merges, backfills, rewrites, validates, constrains, indexes, foreign-keys, type-changes, defaults, nullable rules, enum values, tables, columns, generated columns, triggers, views, functions, row-level policies, or data migrations.
+- A task mentions rolling deploy, expand-and-contract, online migration, backfill, production schema change, rollback, down migration, migration lock, DDL transaction, generated ORM client, migration drift, schema drift, or database migration safety.
+- Prisma, Drizzle, TypeORM, Rails Active Record, Django migrations, Alembic, Diesel, Ecto, Flyway, Liquibase, Knex, Sequelize, SQLx, or another migration tool changes schema, generated output, migration metadata, or deployment behavior.
+- A final report claims a database migration is safe, reversible, applied, validated, production-ready, no-downtime, rollback-safe, or tested from an old schema.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change only edits query logic or persisted data model code without a migration, generated schema artifact, or migration claim; use `database-change-safety`.
+- The migration is not database-backed, such as file layout, template, cache, content, URL, export, import, or platform migration; use `migration-safety-check`.
+- The task only discusses database design without changing or reporting migration behavior.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Source schema, target schema, migration files, migration history table or metadata, generated clients, schema dumps, SQL snapshots, seeds, fixtures, and affected queries.
+- Migration tool and ecosystem: Prisma, Drizzle, TypeORM, Rails, Django, Alembic, Diesel, Ecto, Flyway, Liquibase, Knex, Sequelize, SQLx, raw SQL, or another declared tool.
+- Deployment shape: single-step deploy, rolling deploy, blue-green, multiple app versions, background workers, read replicas, multiple services, serverless functions, mobile clients, or external integrations.
+- Database engine and operational surface: PostgreSQL, MySQL, SQLite, SQL Server, managed database, migration lock behavior, DDL transaction behavior, online DDL options, table size, expected lock time, statement timeout, lock timeout, and restore capability when known.
+- Data preservation needs, compatibility window, backfill size, batch strategy, restart marker, validation query, rollback type, and whether old code can run after the new schema lands.
+- Relevant command-intent entries for build, generated-output checks, tests, docs, release, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- The migration is classified before editing as expand, backfill, switch, contract, destructive, data-only, schema-only, generated-output-only, ORM metadata-only, or rollback documentation.
+- If personal data, tenant isolation, authorization, audit, retention, or secrets are involved, also use `security-privacy-review`.
+- If public API response shape changes because of the migration, also use `api-contract-change`.
+- If file paths or storage keys change with the database migration, also use `file-path-cross-platform-change`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update migration files, ORM schema files, generated client expectations, schema dumps, SQL snapshots, seeds, fixtures, compatibility code, backfill code, validation checks, docs, and tests directly required by the migration.
+- Prefer expand-and-contract for live systems: add compatible shape, backfill safely, switch reads and writes, then contract only after compatibility is proven.
+- Keep destructive cleanup separate from expansion unless the repository explicitly proves a single-step deployment is safe.
+- Do not weaken tests, delete migration history, hand-edit generated client output, suppress migration drift, or claim rollback safety for lossy changes.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the migration surface: schema DDL, data migration, backfill, generated client, schema dump, ORM metadata, seed, fixture, migration docs, or deploy procedure.
+2. Read the tool-specific source of truth before editing.
+   - Prisma: schema file, migrations directory, generated client use, migration history expectations, production deploy flow, and drift behavior.
+   - Drizzle: schema exports, generated SQL, snapshot or meta files, migration journal, generated client or query types, and runtime schema imports.
+   - TypeORM: entity metadata, migration files, data-source config, production synchronization setting, generated SQL, and runtime entity loading.
+   - Rails: migration files, schema dump, model validations, historical migration model usage, seeds, fixtures, callbacks, and deploy order.
+   - Django: migration files, state operations, historical models, schema editor behavior, generated SQL when relevant, and data migration functions.
+   - Alembic or SQLAlchemy: migration revisions, autogenerate output, branch heads, model metadata, downgrade functions, naming conventions, and generated SQL.
+   - Diesel, Ecto, Flyway, Liquibase, Knex, Sequelize, SQLx, and raw SQL: migration history, checked-in SQL, generated metadata, compile-time query checks, rollback files, and schema dumps.
+3. Build a migration ledger: old shape, new shape, rows affected, old code behavior, new code behavior, rollback expectation, generated artifact changes, dependent callers, and validation query.
+4. Classify compatibility.
+   - Old code on old schema.
+   - Old code on expanded schema.
+   - New code on expanded schema.
+   - New code after backfill.
+   - New code after contract.
+   If any required state fails, the migration is not rolling-deploy safe.
+5. For column add, decide nullability, default behavior, backfill strategy, write path, read fallback, index need, and when a future `NOT NULL` or constraint can be enforced.
+6. For column drop, first prove all reads, writes, generated clients, old app versions, jobs, analytics, exports, seeds, fixtures, docs, and external consumers stopped using the column. Treat drop as a contract phase, not as the first migration.
+7. For rename, do not implement rename as drop plus add unless data loss is explicitly intended and approved. Prefer add new column, dual-write or copy, backfill, switch reads, validate, then drop old column later.
+8. For type changes, check whether the database rewrites the table, whether old values can fail conversion, whether indexes or constraints rebuild, whether application serializers change, and whether API or generated client types change.
+9. For nullable and default changes, distinguish schema default from application default. Avoid assuming existing rows are backfilled by a new default.
+10. For constraints and foreign keys, use staged validation when the database supports it. Add the constraint without validating existing rows when appropriate, backfill or repair data, then validate in a separate phase.
+11. For indexes, check table size, write load, lock behavior, concurrent or online index support, uniqueness validation, existing duplicates, and whether generated ORM queries will use the index.
+12. For enum changes, check old code behavior, generated client unions, database enum migration limits, default values, serialization, API compatibility, and whether removing or renaming values requires a data migration first.
+13. For table split, table merge, or relationship rewrite, preserve stable identifiers, foreign keys, audit references, external IDs, permissions, search documents, exports, and old-to-new mapping until all callers switch.
+14. For backfills, make them bounded, restartable, observable, and validated. Define batch size, ordering key, checkpoint, retry behavior, idempotency, timeout, lock expectation, dead-letter or manual review behavior, and validation queries.
+15. Do not run or recommend full-table updates on production-sized data without measured volume, lock expectation, batch plan, timeout policy, and recovery plan.
+16. Keep external side effects out of database migrations unless the repository has an explicit recovery model. Sending emails, calling payment APIs, deleting files, or mutating external providers from a migration usually breaks rollback.
+17. Check generated surfaces after schema changes: ORM clients, types, SQL snapshots, schema dumps, OpenAPI or GraphQL projections, API mocks, fixtures, seeds, admin screens, analytics, ETL, BI queries, and docs examples.
+18. Review ORM-specific traps.
+   - Prisma generated client and migration history must match the migration files that production applies.
+   - Drizzle schema exports and generated SQL or snapshots must not drift.
+   - TypeORM production `synchronize` must not be used as a migration strategy.
+   - Django rename detection and autogeneration must be reviewed so rename does not become delete and create.
+   - Alembic autogenerate output is a candidate, not a reviewed migration.
+   - Rails migrations should not depend on current model callbacks or validations when historical data can outlive current model code.
+19. Decide rollback honestly.
+   - Reversible: schema-only and data-preserving.
+   - Forward-fix preferred: partial live migration can be corrected without restoring.
+   - Restore required: deletes, table merges, generated IDs, hashing, encryption, irreversible type conversions, external side effects, or lossy transforms.
+   Do not promise rollback for changes that cannot reconstruct old values.
+20. Rehearse from the previous production-like schema when possible. A migration that only applies to a freshly generated schema is not enough.
+21. Check dependent surfaces: application code, background jobs, cron tasks, workers, ETL, reports, admin tools, data exports, imports, mobile or older clients, webhooks, API clients, generated SDKs, test fixtures, seeds, docs, and monitoring.
+22. Select verification from the command contract. Major schema changes, generated client changes, rollback-sensitive changes, security-sensitive migrations, and production deployment changes need broader verification than local schema-only edits.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Source schema, target schema, migration files, generated artifacts, schema dumps, seeds, fixtures, and dependent code agree.
+- Expand, backfill, switch, and contract phases are separated or explicitly proven unnecessary.
+- Old-code/new-schema and new-code/expanded-schema compatibility is classified.
+- Backfill and validation behavior is bounded, restartable, and checkable where relevant.
+- Rollback claims distinguish schema rollback, data rollback, app rollback, forward-fix, and restore-required cases.
+- Destructive changes and production lock risks are either deferred, measured, or reported as remaining risk.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer configured migration dry-run, generated-output, schema-diff, or database test intents when the command contract exposes them. Do not invent raw migration commands inside the skill.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If old/new application compatibility is unknown, do not call the migration rolling-deploy safe.
+- If production table size, lock behavior, or validation cost is unknown, report the operation as production-risky.
+- If an autogenerator proposes drop/create for a rename, stop and rewrite the migration plan.
+- If a migration is lossy, do not claim rollback beyond restore or forward corrective migration.
+- If generated clients or schema dumps drift, fix the source of truth and regenerated surfaces together.
+- If configured verification is missing, report the missing command intent instead of inferring package-manager, ORM, or migration-tool commands.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Database migration changed
+- Tool and database engine surface inspected
+- Source schema, target schema, and migration phase
+- Old-code/new-schema and new-code/expanded-schema compatibility
+- Backfill, validation, lock, timeout, and rollback classification
+- ORM/generated client/schema dump/snapshot surfaces synchronized
+- Dependent surfaces checked
+- Command intents run
+- Skipped migration checks and reasons
+- Remaining database migration risk

package/templates/default/locales/en/.mustflow/skills/dependency-upgrade-review/SKILL.md

@@ -0,0 +1,151 @@
+---
+mustflow_doc: skill.dependency-upgrade-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: dependency-upgrade-review
+description: Apply this skill when dependency versions, lockfiles, package manager metadata, security advisory fixes, generated dependency outputs, runtime engine constraints, peer dependency contracts, framework plugins, CI actions, Docker base images, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.dependency-upgrade-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Dependency Upgrade Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review dependency upgrades as runtime, build, security, package, and generated-output contract changes rather than as version-number edits.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A dependency version is upgraded, downgraded, pinned, unpinned, widened, narrowed, replaced, or removed.
+- A lockfile, package manager metadata, workspace constraint, runtime engine, peer dependency, optional dependency, feature flag, or generated dependency output changes.
+- A security advisory, vulnerability scanner, Dependabot, Renovate, package audit, language audit, CI action update, Docker base image update, framework plugin update, formatter/linter/bundler update, ORM update, code generator update, protobuf/OpenAPI generator update, or toolchain update is reviewed or applied.
+- A task claims a dependency change is "only patch", "only devDependency", "safe minor", "security-only", "transitive only", "lockfile only", or "no runtime change".
+- A dependency update touches installation, publish output, generated clients, SDKs, native binaries, browser bundles, serverless or edge runtime, ESM/CJS/module format, Python markers, Go module graph, Cargo features, JVM dependency mediation, .NET target frameworks, Ruby/PHP/Swift lockfiles, Docker images, or CI actions.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- A brand-new dependency is proposed without upgrading an existing declaration; use `dependency-reality-check` first.
+- Code imports or invokes an existing dependency but no dependency metadata, lockfile, runtime version, generated output, or package-manager contract changes.
+- The task only updates prose that mentions a dependency and does not assert supported versions, install commands, runtime behavior, security status, or package metadata.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The dependency or tool being changed, old version or range, new version or range, direct or transitive status, and reason for the change.
+- Ecosystem and package manager: JavaScript or TypeScript, Python, Go, Rust, JVM, .NET, Ruby, PHP, Swift, Docker, CI actions, or another declared system.
+- Package declarations, lockfiles, workspace files, runtime-version files, package-manager config, toolchain files, CI/Docker files, generated outputs, and command contract entries.
+- Release notes, migration notes, changelog, advisory range, fixed range, compatibility notes, or local issue evidence when available from approved context.
+- Impacted runtime paths, build paths, test paths, generated clients, mocks, fixtures, docs examples, deployment images, and package publish output.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- The upgrade is classified before editing as patch, minor, major, pre-1.0, security fix, transitive-only, toolchain-only, generated-output, runtime-engine, CI-image, or broad refresh.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Align dependency declarations, lockfiles, generated outputs, compatibility code, tests, docs, and package metadata that are directly required by the upgrade.
+- Prefer the minimum version change that satisfies the feature or advisory.
+- Keep unrelated modernization, formatting churn, dependency family refreshes, and broad package-manager rewrites out of a narrow upgrade.
+- Do not delete and recreate lockfiles to hide the dependency graph change.
+- Do not weaken tests, scanners, coverage gates, type checks, peer warnings, engine checks, or generated-output assertions to make an upgrade pass.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the upgrade and classify it: direct or transitive, runtime or development, patch/minor/major/pre-1.0/security/toolchain/generated/CI-image, and narrow or broad.
+2. Identify the ecosystem and read the matching declaration surfaces.
+   - JavaScript and TypeScript: package metadata, lockfile, workspace files, package-manager config, runtime version, TypeScript config, bundler/framework/test config, generated clients, and publish files.
+   - Python: project metadata, dependency groups, constraints, lockfiles, requirements files, Python version files, test matrix, build backend, and packaging output.
+   - Go: module files, workspace file, checksum file, vendored module metadata, generated code hooks, tool dependencies, and toolchain expectations.
+   - Rust: manifest, lockfile, toolchain file, cargo config, features, default features, target-specific dependencies, build scripts, generated bindings, and crate publish surface.
+   - JVM, .NET, Ruby, PHP, Swift: manifests, lockfiles, package-manager wrappers, toolchain files, dependency mediation rules, generated artifacts, and publish metadata.
+   - Docker and CI: base image tags or digests, action versions, setup-tool versions, cache keys, matrix versions, deployment image metadata, and runtime smoke surfaces.
+3. Build a dependency ledger before editing: old version, new version, direct or transitive path, source registry or image source, lockfile entry, integrity or checksum, engine or platform requirement, peer or feature changes, optional or platform-specific packages, and generated-output changes.
+4. For patch upgrades, verify that the patch does not change runtime defaults, parser strictness, security behavior, peer requirements, engine support, native binaries, module format, generated output, or install scripts.
+5. For minor upgrades, read release notes or migration notes when available. Check new defaults, deprecations, peer and engine changes, plugin compatibility, generated output, bundle size, runtime adapter behavior, and framework integration behavior.
+6. For major upgrades, treat the change as a migration. Require migration notes, public API change classification, config schema review, CLI flag review, plugin API review, codemod or manual migration notes, full caller review, rollback plan, and broad verification.
+7. For pre-1.0 or calendar-versioned packages, do not trust SemVer labels. Classify risk by actual contract changes and release notes.
+8. For security upgrades, keep the patch narrow. Identify advisory id, affected range, fixed range, direct or transitive path, exploit-relevant code path, minimum patched version, scanner recheck, and whether stricter validation, escaping, TLS, redirect, auth, or parser behavior can break callers.
+9. Review the lockfile as a graph, not a blob. Check direct and transitive replacements, newly introduced packages, removed packages, optional/platform packages, source URLs, integrity or checksum changes, peer resolution, engine requirements, native prebuilds, and postinstall or lifecycle scripts.
+10. Review runtime boundaries that dependency upgrades commonly break: ESM/CJS and package `type`, `exports` and conditional exports, browser/node/edge conditions, Node engine support, Python dependency markers and extras, Go module path changes, Cargo feature unification, native builds, SSR/client split, WebView/native split, and generated client or SDK types.
+11. Treat framework, plugin, code generator, formatter, linter, bundler, ORM, protobuf, OpenAPI, GraphQL, database driver, and test-runner upgrades as behavior changes when their output, config schema, plugin API, CLI flags, or generated code can change.
+12. For new dependencies introduced by the upgrade, invoke the `dependency-reality-check` decision path: license, maintainer risk, provenance, lifecycle scripts, binary downloads, package age, transitive size, supply-chain risk, and replacement path.
+13. For Docker base images and CI actions, review them as dependencies. Check image/action source, version pinning policy, digest use when required, runtime version changes, security patch reason, cache impact, and deployment smoke coverage.
+14. Synchronize dependent surfaces: generated code, snapshots, mocks, fixtures, examples, SDK clients, OpenAPI or GraphQL artifacts, README install guidance, migration docs, changelog, Docker/CI docs, and package publish metadata.
+15. Select verification from the command contract based on risk. Patch and narrow transitive changes can use focused checks when they cover the touched path; major, framework, runtime-engine, generated-output, security-sensitive, Docker, or CI-action updates need broader checks.
+16. Report skipped checks explicitly. If the command contract lacks a dependency graph or package verification intent, do not invent raw package-manager commands; report the missing configured intent.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The final state shows exactly which dependency contract changed and why.
+- The lockfile and declaration files agree.
+- Direct and transitive changes are understood, not hidden behind lockfile volume.
+- Runtime engine, peer dependency, optional/platform package, feature, module-format, generated-output, and publish-surface risks are classified.
+- Security fixes are narrow unless the user explicitly accepted a broader modernization.
+- Tests and scanners were not weakened to pass the upgrade.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured intent that proves the actual upgraded dependency path. Use broader verification for major upgrades, runtime or framework upgrades, security-sensitive dependencies, generated-output changes, publish-surface changes, Docker image changes, CI action changes, and package-manager behavior changes.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If release notes, advisory range, fixed range, or migration guidance are missing, mark the upgrade as higher risk instead of calling it safe.
+- If a lockfile diff introduces unrelated dependency churn, split the change or explain why the graph update is necessary.
+- If peer dependency, engine, optional dependency, native build, or platform warnings appear, resolve or report them. Do not dismiss them because the local machine passed.
+- If tests fail after an upgrade, do not delete tests, skip tests, loosen assertions, lower coverage, disable scanners, or widen permissions unless the behavior contract intentionally changed and the report says so.
+- If a security upgrade requires broad modernization, split the minimum patch from the modernization when possible.
+- If generated output changes, regenerate from the official generator path and explain the generated diff. Do not hand-edit generated dependency output.
+- If configured verification is missing, report the missing command intent instead of inferring a package-manager command.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Dependency upgraded and reason
+- Ecosystem and package manager surface inspected
+- Direct and transitive graph changes
+- Compatibility classification: patch, minor, major, pre-1.0, security, toolchain, generated-output, Docker, or CI action
+- Runtime, peer, engine, module, feature, platform, generated-output, and publish-surface risks
+- Security advisory and fixed-range notes when relevant
+- Surfaces synchronized
+- Command intents run
+- Skipped dependency checks and reasons
+- Remaining dependency upgrade risk

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

@@ -0,0 +1,115 @@
+---
+mustflow_doc: skill.elysia-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: elysia-code-change
+description: Apply this skill when Elysia routes, schemas, plugins, decorators, derives, guards, auth, error handling, OpenAPI output, Eden clients, or Bun server behavior are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.elysia-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Elysia Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Elysia schema-first runtime validation, type inference, plugin, auth, error, OpenAPI, Eden, and Bun runtime boundaries.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `new Elysia`, route methods, `t.Object`, request or response schemas, `.use`, `.guard`, `.derive`, `.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.
+
+<!-- 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.
+- 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.
+- Existing response envelope, status-code contract, and strict TypeScript policy.
+
+<!-- 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.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- 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, and store inference through Elysia chaining.
+- Keep OpenAPI and Eden clients aligned with route schemas when present.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read server entry, routes, plugins, schemas, auth, error handling, OpenAPI, Eden exports, 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. Centralize expected error envelope and auth failure behavior.
+7. If OpenAPI or Eden is used, confirm the generated contract follows the schema change.
+8. Choose configured verification intents that cover types, server boot, route happy path, validation failure, auth failure, OpenAPI, and Eden inference 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 or erased context types.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing route, OpenAPI, or Eden verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- 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 behavior is unclear, stop the route change and inspect or request the auth contract.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Schema and type inference notes
+- Auth, error, OpenAPI, or Eden impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Elysia risk