mustflow 1.18.16 → 1.31.0

package/templates/default/locales/fr/.mustflow/skills/database-change-safety/SKILL.md

@@ -1,155 +0,0 @@
----
-mustflow_doc: skill.database-change-safety
-locale: fr
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: database-change-safety
-description: Apply this skill when database schema, queries, transactions, ORM models, repositories, stores, indexes, cache-backed read models, retention, pagination, concurrency, idempotency, audit logs, or persistence boundaries are introduced, changed, reviewed, or reported.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.database-change-safety
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Database Change Safety
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Keep database-backed behavior explicit, scoped, recoverable where possible, and verifiable without treating database rows, ORM models, generated caches, or read models as domain truth.
-
-Use the smallest persistence boundary that proves the risk. Do not introduce repositories, services, transactions, migrations, outbox machinery, or read models when a direct scoped query or fixture update is enough.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A schema, migration, table, collection, ORM model, query, repository, store, transaction, index, cache, read model, audit log, or retention rule is introduced or changed.
-- Code reads from or writes to a database, browser storage, cache, local SQLite file, external database, or generated data store.
-- A task changes authorization, tenant scoping, pagination, sorting, soft delete, status filters, idempotency, duplicate handling, retry, or concurrency behavior around persisted data.
-- Documentation, tests, or final reports claim that a database change is safe, fast, indexed, migrated, reversible, idempotent, or verified.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The change is pure in-memory logic with no persisted, cached, indexed, or generated state.
-- The task only changes external protocol mapping and no database-backed state; use `adapter-boundary`.
-- The task only changes file or template migration behavior and no database or persistence surface; use `migration-safety-check`.
-- The change only documents general database advice without touching or claiming project behavior.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- Database role: source of truth, rebuildable cache, read model, runtime state, analytics store, external provider, or browser storage.
-- Data owner and affected tables, collections, stores, indexes, caches, generated files, or read models.
-- Read and write paths, query or ORM behavior, authorization scope, tenant or user scope, and retention expectations.
-- Transaction boundary, idempotency, retry, duplicate-delivery, concurrency, migration, rollback, or rebuild expectations.
-- Local database, ORM, repository, fixture, migration, cache, and test patterns.
-- Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- If database clients, ORM types, rows, browser storage, cache values, or provider data cross into core logic, also use `adapter-boundary`.
-- If hidden construction or global lookup creates the database dependency, also use `dependency-injection`.
-- If schema, data, cache, or generated state changes must move from an old state to a new state, also use `migration-safety-check`.
-- If personal data, authentication, authorization, retention, logs, telemetry, or secret-like values are involved, also use `security-privacy-review`.
-- If index, query-time, startup, package-size, search, count, or read-model performance claims are involved, also use `performance-budget-check`.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Update schema, query, repository, store, transaction, index, cache, read-model, fixture, test, documentation, and directly synchronized template surfaces tied to the task.
-- Add or tighten constraints, scoping, pagination, ordering, idempotency keys, concurrency guards, retention checks, and redaction behavior when the changed surface justifies it.
-- Mark rollback, migration, performance, privacy, or concurrency gaps as unverified when they cannot be proven.
-- Do not expose database rows, ORM models, query builders, or provider clients as domain objects.
-- Do not treat generated caches or read models as source of truth.
-- Do not add broad repository methods that accept arbitrary filters unless authorization, tenant scope, and caller ownership are explicit.
-- Do not call external APIs inside a database transaction unless a local rule explicitly accepts the coupling and a recovery path exists.
-- Do not store raw logs, secrets, hidden reasoning, full transcripts, unnecessary provider payloads, or unbounded personal data in local state or caches.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Classify the database role.
-   - Source of truth: owns current business state.
-   - Rebuildable cache: can be deleted and regenerated from files, provider data, or another source.
-   - Read model: derived for lookup, search, reporting, or dashboard use.
-   - Runtime state: coordinates in-flight work, locks, sessions, jobs, or retries.
-   - Analytics store, external provider, or browser storage: owned outside the core domain boundary.
-2. Identify the data owner and derived surfaces. Name which table, file, provider, event log, configuration, or generated artifact owns each value.
-3. Check schema shape: primary keys, foreign keys, unique constraints, nullable fields, defaults, check constraints, status values, timestamps, soft delete fields, tenant scope, audit fields, and retention rules.
-4. Check query semantics: authorization scope, tenant or user scope, role or visibility filters, deleted or archived rows, draft or unpublished rows, effective dates, null handling, stale-data behavior, and error or absence handling.
-5. Check pagination and ordering. Lists need deterministic ordering; cursor pagination needs a stable tie breaker such as a unique id in addition to a timestamp.
-6. Check transaction boundaries. Keep database writes and external side effects separate by default; use explicit states, an outbox, an action ledger, or reconciliation when both must be coordinated.
-7. Check idempotency, retries, duplicate delivery, and concurrency. Look for webhook duplicates, job retries, import reruns, payment callbacks, optimistic locks, compare-and-swap updates, unique-constraint races, and double state transitions.
-8. Check indexes and workload cost. Match indexes to `WHERE`, `JOIN`, `ORDER BY`, and `GROUP BY` behavior, but account for write cost. Look for N+1 queries, expensive counts, full scans, materialized read-model needs, and search-index boundaries.
-9. Check privacy and retention. Prefer omission or bounded metadata over storing raw payloads. Do not persist secrets, hidden reasoning, full transcripts, unbounded logs, or personal data without a clear product rule and retention path.
-10. Check migration, rollback, and rebuild paths. If a migration claim exists, prove idempotency and recovery with `migration-safety-check` or report the gap. If the store is a cache, name the rebuild source and stale-index detection.
-11. Check tests and fixtures. Reuse or add repository/store tests, migration fixtures, query fixtures, adapter fixtures, permission regressions, idempotency or concurrency regressions, and cache rebuild checks as justified by the risk.
-12. Verify and report. Separate proven behavior from unverified rollback, migration, privacy, performance, live-data, or concurrency risks.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The database role and source of truth are explicit.
-- Database rows, ORM models, generated caches, and read models do not leak into domain truth unless the local architecture intentionally owns that boundary.
-- Queries preserve authorization, tenant or user scope, deterministic ordering, expected absence behavior, and retention rules.
-- Transaction, external side effect, idempotency, duplicate, retry, and concurrency decisions are intentional and reported.
-- Index, query-cost, migration, rollback, rebuild, privacy, and verification claims are tied to evidence or marked as unverified.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `test_related`
-- `test`
-- `lint`
-- `build`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Prefer the narrowest configured test, build, docs, release, or mustflow intent that proves the changed persistence surface. Do not infer raw database, migration, package, or benchmark commands.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the source of truth is unclear, stop changing persistence behavior and report the competing owners.
-- If authorization, tenant scope, soft delete, or retention behavior cannot be confirmed, fail closed or report the missing project rule.
-- If rollback, migration idempotency, rebuild, or stale-cache detection cannot be proven, avoid claiming safety and name the remaining recovery risk.
-- If a performance claim lacks a configured measurement path, report it as unmeasured instead of inventing a budget.
-- If sensitive data appears in queries, fixtures, logs, generated state, package contents, or final output, route that surface through `security-privacy-review` before continuing.
-- If the safest fix would require live data access, destructive migration, dependency installation, or unavailable credentials, stop at that boundary and report the skipped check.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Database role and owner
-- Affected read and write paths
-- Schema, constraint, and query semantics reviewed
-- Authorization, tenant scope, retention, and privacy checks
-- Transaction, idempotency, retry, and concurrency decisions
-- Index, pagination, and performance notes
-- Migration, rollback, dry-run, rebuild, or compatibility status
-- Tests, fixtures, or verification command intents run
-- Skipped checks and reasons
-- Remaining database risk

package/templates/default/locales/fr/.mustflow/skills/date-number-audit/SKILL.md

@@ -1,116 +0,0 @@
----
-mustflow_doc: skill.date-number-audit
-locale: fr
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: date-number-audit
-description: Apply this skill when a task creates, edits, or reports dates, versions, counts, durations, limits, metrics, benchmarks, prices, percentages, or other numeric facts.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.date-number-audit
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Date and Number Audit
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Prevent code, docs, tests, and final reports from inventing, copying stale, or mis-synchronizing dates and numeric facts.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A change adds, edits, removes, or reports a date, deadline, release version, count, duration, timeout, limit, quota, size, percentage, price, benchmark, score, coverage value, or generated-file total.
-- Documentation summarizes how many commands, files, pages, templates, locales, tests, checks, or supported items exist.
-- A final report or user-facing message depends on a number that may drift after code, template, package, docs, or generated-output changes.
-- A failing check suggests a stale revision, mismatched version, wrong count, outdated date, or inconsistent numeric threshold.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The number is a local variable, loop index, enum value, or test fixture with no public or cross-file meaning.
-- The task only preserves existing numeric text without relying on it.
-- A specialized skill for release versioning, dependency reality, artifact integrity, or source freshness is the narrower match.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The date or numeric fact and every surface that states, derives, or validates it.
-- The source of truth for the value, such as package metadata, template metadata, schema, code constant, generated output, test assertion, or current command result.
-- The acceptable precision and wording when a value is approximate, sampled, local-only, or time-sensitive.
-- Relevant command-intent contract entries for docs, packaging, build, or mustflow validation.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Align dates and numeric facts across source files, generated metadata, tests, documentation, and final reports.
-- Replace exact numbers with bounded or source-linked wording when exactness is not stable.
-- Do not invent a number to make a document feel complete.
-- Do not change behavior thresholds, timeouts, limits, or release versions unless the task and source of truth support the change.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. List the date or numeric facts that the task creates, edits, or reports.
-2. Identify the source of truth for each value before changing dependent surfaces.
-3. Search related code, templates, docs, schemas, tests, and generated metadata for duplicate statements of the same value.
-4. Update dependent surfaces from the source of truth, or mark the value as approximate, local, sampled, or unverified when exact verification is unavailable.
-5. Keep version numbers, template revisions, schema revisions, locale source revisions, package assertions, and public examples synchronized.
-6. Prefer phrasing such as "about", "currently", "at the time of this check", or "from the latest generated output" only when that uncertainty is true and useful.
-7. Run the narrowest configured verification that proves the value and dependent surfaces still agree.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Every public or cross-file date and numeric fact has a named source of truth or an explicit uncertainty note.
-- Tests and metadata that assert numbers are synchronized with the changed source.
-- The final report names any values that were intentionally left approximate or unverified.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Use a narrower configured test, build, or docs intent when it better proves the changed numeric surface.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If two sources disagree, do not guess. Identify the higher-authority source or report the conflict.
-- If a value depends on time, network state, package registry state, generated output, or external data that was not refreshed, state that boundary.
-- If an exact number is unnecessary and expensive to keep current, rewrite the statement to avoid brittle precision.
-- If changing a number affects behavior, activate the relevant code, test, release, or dependency skill before continuing.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Dates or numeric facts audited
-- Source of truth for each value
-- Surfaces synchronized
-- Exact values changed or made approximate
-- Command intents run
-- Skipped checks and reasons
-- Remaining date or numeric risk

package/templates/default/locales/fr/.mustflow/skills/dependency-injection/SKILL.md

@@ -1,161 +0,0 @@
----
-mustflow_doc: skill.dependency-injection
-locale: fr
-canonical: false
-revision: 3
-lifecycle: mustflow-owned
-authority: procedure
-name: dependency-injection
-description: Apply this skill when core or application logic creates, imports, resolves, or hides external dependencies such as databases, APIs, SDKs, filesystems, clocks, random generators, identifiers, loggers, configuration, framework request objects, AI clients, queues, or payment/email providers.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.dependency-injection
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Dependency Injection
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Keep business logic from creating, finding, or importing the tools it needs. External-world objects belong at assembly boundaries; core logic receives narrow ports, explicit values, or request context from the outside.
-
-Dependency injection is not an abstraction quota. Use it to keep replaceable infrastructure, hidden global state, and side effects from leaking into domain and use-case code.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- Core, domain, application, service, or use-case code directly constructs a database client, external SDK, queue, file storage, logger, clock, random generator, identifier generator, AI model client, email sender, payment gateway, HTTP client, or framework object.
-- Code reads `process.env`, current time, random values, UUIDs, files, local storage, global containers, or global loggers away from the assembly boundary.
-- A refactor aims to make behavior easier to test without real databases, network calls, API keys, filesystem writes, current time, or random identifiers.
-- New ports, adapters, provider modules, transaction runners, or composition roots are being introduced.
-- A function's signature hides required collaborators or accepts broad technical objects instead of the narrow capability it actually needs.
-- An optional collaborator should be wired as a real implementation or a safe null, no-op, disabled, identity, empty, deny-all, or failing implementation at the assembly boundary.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The code is a pure function, value object, entity constructor, small data formatter, or internal helper with no external dependency.
-- The task is a disposable one-off script that is not imported, tested, repeated, used in production, or connected to external services.
-- A framework's dependency injection mechanism is already confined to the application boundary and does not leak into domain code.
-- The only change needed is to confirm a package or tool exists; use `dependency-reality-check`.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The target code area and the direct dependency, global state, or hidden collaborator being introduced or removed.
-- The intended business capability and which layer owns the rule: domain, application, infrastructure, adapter, route, worker, or assembly root.
-- Existing local patterns for ports, adapters, fakes, transaction runners, clocks, configuration loading, and test setup.
-- Current changed files and command-intent contract entries relevant to tests, builds, docs, release metadata, 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.
-- If the local structure is unfamiliar, use `pattern-scout` or `codebase-orientation` before introducing new folders or naming conventions.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Define narrow consumer-owned ports where core logic needs external behavior.
-- Move concrete client creation, environment reads, lifecycle setup, and disposal to assembly boundaries.
-- Add infrastructure adapters that implement the ports and translate external rows, responses, errors, and identifiers into internal types.
-- Add local fakes, fixed clocks, fixed identifiers, and contract tests when needed to preserve behavior.
-- Wire optional collaborators with `null-object-pattern` when absence is explicit, safe, and should not leak nullable checks into business logic.
-- Do not add a service locator, global container access, broad application dependency bag, framework decorator in domain code, or speculative interface for every class.
-- When the dependency also crosses an external protocol, provider, database, webhook, queue, file, cache, AI model, or framework boundary, use `adapter-boundary` for the translation and failure-handling rules.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Classify the code under change:
-   - Core logic: domain rules, use cases, state transitions, policy checks, calculations, and business decisions.
-   - Edge logic: routes, controllers, workers, command handlers, adapters, repositories, SDK wrappers, and assembly roots.
-2. Find direct external dependencies before editing. Look for concrete SDK construction, database clients, HTTP clients, file APIs, environment reads, current-time calls, random or UUID generation, global loggers, global containers, framework request or response objects, and external error types.
-3. Decide whether dependency injection is warranted. Inject only collaborators that cross a boundary, are hard to test, may change implementation, or represent hidden global state. Do not wrap pure helpers, value objects, or stable internal data structures just to add ceremony.
-4. Define ports from the consumer's need, not from the provider's API.
-   - Prefer `PaymentGateway`, `UserRepository`, `EmailSender`, `ImageStorage`, or `TextGenerator`.
-   - Avoid provider-shaped ports such as `StripeService`, `PrismaUserStore`, `ResendMailer`, `S3ImageStorage`, or `OpenAITextGenerator` at the core boundary.
-5. Choose the injection style:
-   - Use constructor injection or a dependency object for classes with stable collaborators.
-   - Use function-closure injection for small use cases or function-oriented modules.
-   - Use method parameters for per-call data such as actor, tenant, locale, request id, pagination, filters, or command input.
-   - Use factories only when runtime values decide the implementation, lifecycle, or resource handle.
-6. Keep construction at the assembly boundary. Create concrete clients, load and validate configuration, register containers, open connections, and wire adapters in files such as bootstrap, server setup, worker setup, route setup, module registration, or test setup.
-   - If a dependency is optional and disabled by explicit configuration, choose the real collaborator or the safe neutral implementation here, not inside business logic.
-   - If a dependency is required, validate configuration here and fail early instead of injecting a null object.
-7. Treat time, random values, identifiers, configuration, logging, transactions, and framework objects as dependencies.
-   - For domain decisions, prefer an already captured instant or time context over passing a clock that can be queried inside the domain.
-   - Pass fixed implementations in tests so time, identifiers, and random choices are reproducible.
-8. Keep adapters responsible for translation. Repositories and provider adapters should convert database rows, external responses, external errors, and provider identifiers before returning to core logic.
-9. If the injected collaborator is an external boundary, apply `adapter-boundary` before finalizing the port and adapter. Dependency injection decides how core logic receives the collaborator; adapter boundaries decide how external protocols, data, errors, timeouts, retries, idempotency, security, and observability are translated.
-10. Keep transaction ownership explicit. Inject a transaction runner when a use case needs atomic persistence across multiple repositories. Do not hide transaction boundaries inside repositories when the use case owns the unit of work, and do not call external APIs inside a database transaction.
-11. Reject hidden dependency patterns:
-    - no property injection for required collaborators
-    - no service locator or `container.resolve` in core logic
-    - no process-wide mutable singleton holding request state
-    - no broad `AppDeps` object when a use case needs only a few collaborators
-    - no circular service dependencies unless a smaller use case, shared policy, or event boundary has been considered first
-12. Keep tests honest. Unit tests for core logic should use fakes or fixed collaborators and should not require a real database, real network, real API key, real email, real payment, real filesystem side effect, current time, or random UUID. Test real adapters separately with integration or contract coverage.
-13. Verify with the narrowest configured command intents that cover the changed code, tests, template files, docs, and release metadata.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Core logic declares its collaborators through constructor parameters, function parameters, or narrow context objects.
-- Concrete external implementation creation is easy to find at assembly boundaries.
-- Core logic does not import provider SDKs, database clients, framework request or response objects, global containers, or external provider error types.
-- Tests can replace external collaborators, time, identifiers, and random values without live infrastructure.
-- Adapter boundaries translate external data and failures before they reach core logic.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `test_related`
-- `test`
-- `lint`
-- `build`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Prefer the narrowest configured test or build intent that proves the affected boundary. Use documentation and release checks when templates, skill routes, public docs, package metadata, or installed-file surfaces change.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If extracting a port would duplicate an existing local interface, reuse or narrow the existing local pattern instead of creating a parallel abstraction.
-- If a class needs many collaborators, stop before adding a giant dependency object and look for mixed responsibilities, smaller use cases, or adapter boundaries.
-- If a framework forces decorators or container registration, keep that integration in the application boundary and do not let it shape domain types.
-- If a direct dependency cannot be removed in one safe step, first wrap it at the smallest local boundary and report the remaining leakage.
-- If tests still need real infrastructure after the refactor, report which dependency is still not injectable and why.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Dependency boundary reviewed
-- Direct external dependencies found
-- Injection style selected
-- Ports and adapters added or reused
-- Assembly boundary used
-- External data or error translation handled
-- Tests, fakes, or fixed collaborators added or reused
-- Command intents run
-- Skipped checks and reasons
-- Remaining dependency leakage or lifecycle risk

package/templates/default/locales/fr/.mustflow/skills/dependency-reality-check/SKILL.md

@@ -1,115 +0,0 @@
----
-mustflow_doc: skill.dependency-reality-check
-locale: fr
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: dependency-reality-check
-description: Apply this skill when a task assumes, adds, removes, imports, invokes, or documents a package, runtime, tool, command, service, or platform capability.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.dependency-reality-check
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - build
-    - test_release
-    - mustflow_check
----
-
-# Dependency Reality Check
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Prevent code, docs, tests, and final reports from assuming unavailable packages, tools, commands, runtimes, services, or platform capabilities.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A change adds, removes, renames, imports, invokes, or documents a dependency, tool, runtime, command, plugin, service, or platform feature.
-- A solution relies on a package manager, binary, environment variable, browser API, operating-system command, hosted service, or optional integration.
-- A generated instruction tells another agent or user to run a tool that may not be declared in the repository.
-- A failure may be caused by a missing install, mismatched version, unsupported runtime, or unavailable command.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task only changes repository-local prose and does not mention tools, runtime behavior, package metadata, or commands.
-- The dependency is already proven by the current task context and no dependency-facing surface changes.
-- The user explicitly asks for a speculative design that should not be implemented or verified yet.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The dependency, tool, command, runtime, service, or platform capability being assumed.
-- Package, lock, config, import, script, command-intent, or documentation files that declare or reference it.
-- The minimum version, capability, or availability claim if one is required.
-- Relevant command-intent contract entries for build, package, test, or documentation verification.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Align dependency declarations, imports, scripts, command metadata, tests, and docs that describe the same capability.
-- Prefer existing repository dependencies and declared command intents before adding new packages or tools.
-- Do not install packages, widen runtime requirements, or introduce new external services unless the user request and repository contract support it.
-- Do not claim a dependency is available just because it exists on the internet or in another project.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Name the assumed dependency or capability and where the task relies on it.
-2. Check the repository declarations first: package metadata, lockfiles, config files, imports, command intents, docs, and templates.
-3. Decide whether the dependency is present, absent, optional, transitive, host-provided, or external.
-4. If present, verify that the requested capability and version expectation match the declared dependency.
-5. If absent, prefer an existing local alternative. Add a new dependency only when it is necessary and within the task scope.
-6. Keep all dependency-facing surfaces aligned: package metadata, lockfiles when intentionally updated, command contract, docs, tests, and installation notes.
-7. Run the narrowest configured verification that proves the dependency path used by the change.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Every dependency or tool claim is backed by a repository declaration, configured command, host boundary, or explicit unverified-risk note.
-- New dependency requirements are reflected in the appropriate metadata and public documentation.
-- The final report states whether the dependency was existing, added, optional, unavailable, or intentionally not verified.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `build`
-- `test_release`
-- `mustflow_check`
-
-Use a narrower configured test, package, or docs intent when it better proves the dependency path.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the dependency is missing, report the missing declaration or command instead of silently adding a workaround.
-- If the declared version lacks the needed capability, report the mismatch and avoid claiming support.
-- If a dependency requires network, credentials, operating-system setup, or service access, stop at that boundary and name the unchecked requirement.
-- If generated docs would instruct users to run undeclared tools, rewrite the docs to use declared commands or mark the tool as a manual prerequisite.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Dependency or capability checked
-- Repository declaration or absence
-- Surfaces synchronized
-- Command intents run
-- Skipped dependency checks and reasons
-- Remaining dependency risk