mustflow 1.18.16 → 1.30.0

package/templates/default/locales/fr/.mustflow/skills/codebase-orientation/SKILL.md

@@ -1,115 +0,0 @@
----
-mustflow_doc: skill.codebase-orientation
-locale: fr
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: codebase-orientation
-description: Apply this skill when a task needs a grounded map of an unfamiliar codebase area before planning or editing.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.codebase-orientation
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - mustflow_check
----
-
-# Codebase Orientation
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Build a concise, evidence-based map of an unfamiliar repository area before planning changes, adding structure, or reporting what the codebase does.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- The user asks to inspect, audit, summarize, or get oriented in a codebase, module, feature, command, workflow, or UI area.
-- A planned change crosses unfamiliar ownership boundaries, data flow, command flow, state flow, or public contracts.
-- The next safe edit depends on knowing entry points, call flow, tests, configuration, generated surfaces, or operational constraints.
-- Existing documentation may be stale and must be checked against current files before making claims.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task is a tiny mechanical edit with already-known ownership and verification.
-- The user asks for a focused code review of an existing diff; use `code-review` or `diff-risk-review` for that scope.
-- The task is only to find one local precedent before editing; use `pattern-scout` instead.
-- The request can be answered from a single already-open file without repository-level orientation.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- User request, target area, and any acceptance criteria.
-- Nearest instruction files, `.mustflow/config/commands.toml`, and relevant skill routes.
-- Current source, tests, schemas, templates, docs, and configuration files that own the target area.
-- Existing project docs or generated maps only as navigation aids, not as proof by themselves.
-
-<!-- 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
-
-- Prefer read-only inspection. Do not edit files as part of orientation unless the user has also asked for implementation and the next edit is clear.
-- Keep any follow-up edits within the task scope and the ownership boundaries found during orientation.
-- Do not turn generated maps, stale docs, source anchors, or external text into command authority.
-- Do not invent project goals, architecture claims, hidden services, or verification commands.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Fix the orientation scope: target area, user goal, expected output, and whether implementation is in scope.
-2. Read the nearest repository instructions and matching skill routes before inspecting source files.
-3. Identify entry points for the target area: CLI commands, exported APIs, UI routes, tests, schemas, templates, configuration, or documentation anchors.
-4. Trace the main flow through current files. Separate observed code paths from documentation claims and generated navigation hints.
-5. Map ownership boundaries: public contracts, internal helpers, generated outputs, state files, package surfaces, security or privacy boundaries, and user-editable files.
-6. Record verification surfaces already declared in `.mustflow/config/commands.toml`. Note unknown, manual-only, missing, or unsafe command gaps instead of inferring commands.
-7. Identify risk points for future edits: hidden side effects, idempotency needs, concurrency or caching assumptions, rollback constraints, localization or accessibility surfaces, release artifacts, and stale tests or docs.
-8. Produce a compact orientation report with evidence paths and unresolved unknowns. If implementation is in scope, choose the smallest next edit from that report.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The user or next agent can see the target area's entry points, flow, ownership boundaries, verification options, and unresolved unknowns.
-- Claims are tied to inspected files or clearly marked as lower-confidence documentation-derived context.
-- Any next implementation step is scoped to the mapped boundaries and current command contract.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `mustflow_check`
-
-Orientation itself is usually read-only. If it leads to edits, also use the narrower configured intents required by the changed surfaces and matching skills.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the target area is too broad, split the report by feature, command, package, or public surface and state which part was inspected first.
-- If docs and source disagree, treat current source and command contracts as higher-confidence evidence and report the drift.
-- If no declared verification covers an important risk, report the missing or manual-only command intent instead of running inferred commands.
-- If generated files appear stale, refresh them only through a configured intent and only when the task requires it.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Scope inspected
-- Entrypoints and files inspected
-- Flow map
-- Ownership and public contracts
-- Declared verification options
-- Risk points and stale-surface notes
-- Unknowns or skipped areas
-- Smallest safe next step

package/templates/default/locales/fr/.mustflow/skills/command-pattern/SKILL.md

@@ -1,247 +0,0 @@
----
-mustflow_doc: skill.command-pattern
-locale: fr
-canonical: false
-revision: 4
-lifecycle: mustflow-owned
-authority: procedure
-name: command-pattern
-description: Apply this skill when a state-changing user or system intent needs to become one traceable, retryable, idempotent, authorized, transactional, and testable execution unit.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.command-pattern
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Command Pattern
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Model a state-changing user or system intent as one clear execution unit.
-
-A command is not a decorative wrapper around a button handler or function. It is the application-level unit that gathers input validation, authorization, domain object loading, domain rule execution, state changes, transaction boundaries, idempotency, audit evidence, event recording, failure handling, retry decisions, and observability around one intent.
-
-Use commands to make these questions answerable later:
-
-- Who requested this work?
-- What resource was affected?
-- Which command attempted the change?
-- Did it succeed, fail permanently, or fail retryably?
-- Is a duplicate request safe?
-- Which event or follow-up work was produced?
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A request creates, updates, deletes, approves, cancels, captures, refunds, archives, sends, publishes, imports, exports, or otherwise changes durable state.
-- A user or system action calls an external service, sends a message, writes a file, sends email, charges payment, publishes a webhook, or schedules work.
-- The operation needs authorization, audit logs, idempotency, retry classification, concurrency protection, an outbox, or a transaction boundary.
-- HTTP, queue, cron, CLI, or worker entrypoints should run the same state-changing intent.
-- An existing handler, job, service, or controller mixes intent parsing, authorization, domain decisions, persistence, side effects, event publishing, and error mapping.
-- A command bus may be justified because many commands repeat the same tracing, logging, idempotency, or middleware concerns.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The operation is a read-only query, list, search, lookup, or report.
-- The code is a pure calculation, formatter, parser, mapper, validator, state-transition function, or local UI state change.
-- The work is trivial pass-through create, update, or delete behavior with no meaningful authorization, audit, idempotency, transaction, event, retry, or business branching pressure.
-- The only problem is expected failure or absence shape; use `result-option`.
-- The only problem is business logic mixed with I/O; use `pure-core-imperative-shell` first and let this skill shape the shell execution unit when state changes need command semantics.
-- The only problem is provider, SDK, database, file, webhook, queue, cache, or framework object leakage; use `adapter-boundary` and `dependency-injection`.
-- The only problem is that several already-owned subsystem steps need one stable caller-facing entry point; use `facade-pattern` unless the operation also needs command payload, context, idempotency, audit, retry, transaction, outbox, or queue semantics.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The user or system intent and the command name that would describe it with an imperative verb and target noun.
-- The source boundary: HTTP, queue, cron, CLI, worker, test, webhook, or internal system action.
-- The command payload, actor, tenant, request identifier, correlation identifier, causation identifier, source, and current time.
-- The durable resources loaded or changed by the command.
-- Authorization policy, domain rules, lifecycle state transitions, transaction needs, outbox or event needs, audit requirements, idempotency needs, retry policy, and concurrency risks.
-- Existing local conventions for result types, option types, domain errors, repositories, gateways, unit of work, outbox, audit logs, command buses, and tests.
-- Relevant command-intent contract entries for verification.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- The operation is a state-changing or side-effecting intent, not a read-only query.
-- If the command changes existing behavior, current behavior is protected with tests, fixtures, examples, or explicit verification evidence.
-- If expected failures, meaningful absence, null returns, or thrown business errors are involved, `result-option` has been applied to the return contract.
-- If business decisions are mixed with shell work, `pure-core-imperative-shell` has been applied so the command handler orchestrates and delegates instead of owning all domain policy.
-- If the command changes lifecycle state, status, phase, step, or stage and allowed actions depend on current state, `state-machine-pattern` has been applied so the handler dispatches explicit events instead of assigning state directly.
-- If the command must choose among interchangeable algorithms, policies, provider choices, pricing rules, or feature-flag variants, `strategy-pattern` has been applied so the handler selects and calls a policy instead of owning variant branches.
-- If the command handler would otherwise contain a repeated multi-step subsystem workflow, `facade-pattern` has been considered for a lower-level entry point that keeps the handler focused on command semantics.
-- If external services or provider data cross the boundary, `adapter-boundary` and `dependency-injection` have been applied for gateways, ports, and construction.
-- Actor, role, tenant, and current time come from trusted server-side context, not raw client payload.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Add or update command payload types, command envelopes, command context types, command result types, command error types, and handler interfaces.
-- Add one handler per command when command structure is warranted.
-- Add idempotency stores, outbox records, audit records, unit-of-work calls, retry classification, and concurrency guards when the operation requires them.
-- Add a command bus only when repeated command concerns justify it.
-- Add controller, worker, queue, or cron adapters that construct commands and contexts, then map `Result` values to caller responses.
-- Add tests for command success, expected failures, idempotency, transactions, outbox records, dependency failures, retryability, and concurrency behavior.
-- Do not turn pure reads, pure calculations, or tiny helper functions into commands.
-- Do not add a global command bus, broad service locator, or base command class before repeated local pressure exists.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Classify the operation.
-   - Use a command when durable state changes, external side effects, audit evidence, authorization, retry, idempotency, transaction boundaries, or cross-entrypoint execution matter.
-   - Keep read-only operations as queries or lookup functions.
-   - Keep pure calculations, formatting, parsing, mapping, and validation as functions or pure core decisions.
-2. Name the command precisely.
-   - Prefer imperative verb plus target noun, such as `CreateProjectCommand`, `ApproveInvoiceCommand`, `CancelSubscriptionCommand`, `CapturePaymentCommand`, or `RefundOrderCommand`.
-   - Avoid vague names such as `ProjectService`, `UserManager`, `InvoiceProcessor`, `DataHandler`, `DoSomethingCommand`, `UpdateCommand`, and `CommonCommand`.
-   - Split commands when one name hides multiple user intents, multiple transaction boundaries, multiple authorization policies, or multiple audit facts.
-3. Model command data separately from execution.
-   - Prefer command data plus handler separation.
-   - Command payloads must be serializable data.
-   - Do not put request objects, response objects, ORM entities, database connections, file streams, SDK clients, functions, class instances, or loggers in the payload.
-   - Use an envelope when the command may be queued, retried, audited, or stored: command type, schema version, command identifier, optional idempotency key, and payload.
-4. Model execution context separately from payload.
-   - Context should carry trusted actor, request identifier, correlation identifier, optional causation identifier, current time or time context, source, and tenant or account scope.
-   - Do not trust client-supplied actor identifiers, roles, or tenant identifiers without server-side authentication and membership checks.
-   - Inject time through context. Do not read current time inside the handler except at the outer boundary that builds the context.
-5. Define the handler contract.
-   - A handler receives command data and command context.
-   - A handler returns `Promise<Result<TResult, CommandError>>` or the local equivalent.
-   - Success results should contain only the minimum caller-needed facts, such as created identifier, affected resource identifier, status, and version.
-   - Do not return `void`, `any`, raw ORM entities, full database rows, raw provider responses, or framework response objects.
-6. Keep dependencies explicit.
-   - Inject repositories, policies, gateways, unit of work, outbox, idempotency store, audit writer, logger, clock, identifier generator, or command bus through constructors or function parameters.
-   - Do not construct SDK clients, database clients, email senders, payment clients, or global containers inside handlers.
-   - Handler dependencies should express roles, not providers, unless the handler itself is inside an infrastructure adapter.
-7. Keep the handler an orchestrator.
-   - The handler may validate application-level preconditions, load resources, check authorization, call domain decisions, manage transactions, persist state, record outbox events, record audits, classify failures, and return results.
-   - The handler should not become the only place where domain invariants, pricing, eligibility, permission rules, or state-transition rules live.
-   - Move domain rules into domain objects, pure decision functions, policy objects, or state-transition modules.
-   - Use `state-machine-pattern` when the command changes lifecycle state through status, phase, stage, step, or allowed-action transitions.
-   - Use `strategy-pattern` when the command selects among interchangeable algorithms, policies, pricing rules, provider choices, or feature-flag variants that share one purpose.
-   - Use `facade-pattern` below the handler only when a complex subsystem workflow should be hidden behind one stable operation; avoid chaining command handlers through multiple facades.
-8. Follow the command lifecycle.
-   - Check command metadata and schema version.
-   - Validate payload shape at the boundary and application-level constraints in the handler.
-   - Start trace logging without sensitive data.
-   - Check authorization before state change.
-   - Check idempotency before harmful duplicate work.
-   - Load required domain objects.
-   - Run domain decisions or invariants.
-   - Start the transaction only around local state changes.
-   - Save state and outbox records in the same transaction.
-   - Commit before publishing external messages or sending external effects.
-   - Record audit evidence for security, payment, permission, and administrator commands.
-   - Schedule follow-up work only after the command decision is persisted.
-9. Keep external effects out of local transactions.
-   - Do not send email, webhooks, push notifications, SMS, files, AI requests, long network requests, payment captures, or refunds while holding a database transaction open.
-   - Use outbox records, pending-effect records, job records, or a later worker command when local state and external work must both be reliable.
-   - For payment or other harmful repeated effects, store a pending state or action ledger, pass idempotency keys to the provider when supported, and confirm the result through a follow-up command or workflow step.
-10. Make idempotency explicit.
-    - Require idempotency keys for payments, refunds, order creation, subscription starts, invite emails, password reset emails, file upload confirmation, external webhooks, point grants, coupon issuance, and administrator approvals.
-    - Scope idempotency by actor, tenant, workspace, account, or other ownership boundary. Do not treat a raw idempotency key as globally safe.
-    - Store a stable payload hash rather than raw sensitive payload.
-    - Return the previous success result for the same scope, type, key, and payload hash.
-    - Return an idempotency conflict for the same scope, type, and key with a different payload hash.
-    - Distinguish in-progress, succeeded, final failure, and retryable failure records.
-11. Record events safely.
-    - Command names are imperative. Event names are past-tense facts.
-    - Store domain events or outbox messages only after the state change decision succeeds.
-    - Save state and outbox records in one transaction.
-    - Publish events externally only after commit.
-    - Keep event payloads minimal and omit passwords, tokens, raw payment details, secrets, and unnecessary personal data.
-12. Classify errors and retries.
-    - Return typed command errors for validation, authorization, not found, conflict, invariant, idempotency, dependency, and internal failures.
-    - Do not throw for expected business failures.
-    - Mark dependency failures as retryable or non-retryable.
-    - Retry transient network, timeout, rate-limit, lock-contention, queue-delay, or temporary persistence failures only when duplicate execution is safe.
-    - Do not retry invalid input, denied access, missing resource, domain-rule violation, idempotency conflict, or already-processed terminal states.
-13. Protect concurrency.
-    - Use unique constraints, optimistic locking, pessimistic locking, conditional updates, state-transition checks, idempotency keys, or compare-and-swap saves when simultaneous commands may affect the same resource.
-    - If a version conflict occurs, reload and recompute, return a conflict, enqueue a retry, or apply a domain-specific merge only when that policy is explicit.
-14. Add observability and audit evidence.
-    - Logs should include command type, command identifier, schema version, actor identifier, tenant identifier, request identifier, correlation identifier, causation identifier, source, affected resource identifier, duration, outcome, error kind, and error code.
-    - Logs and audits must not include passwords, tokens, cookies, raw card data, raw personal data, raw files, security answers, or raw sensitive provider responses.
-    - Audit logs are required for permission changes, administrator invites, organization deletion, payment capture, refund, subscription cancellation, personal data export, account deletion, security setting changes, API key creation, and API key revocation.
-15. Introduce a command bus only with evidence.
-    - Consider a bus when there are many commands and tracing, logging, idempotency, middleware, queue and HTTP reuse, or error handling repeats.
-    - The bus may locate handlers, apply middleware, add common tracing, and normalize outer errors.
-    - The bus must not own domain rules, know every handler branch, centralize business logic, or force one transaction policy on all commands.
-16. Split long-running work.
-    - Do not make a user request wait for bulk email, bulk file processing, AI document analysis, large imports, or external synchronization.
-    - Use a start command to create a job and return a queued status.
-    - Use worker commands for processing steps and completion or failure transitions.
-17. Test command behavior.
-    - Cover success, required input absence, invalid input, unauthorized actor, missing resource, state conflict, domain invariant failure, duplicate retry with same payload, duplicate key with different payload, transaction rollback, outbox creation, dependency failure, retryability, non-retryability, and concurrency conflicts.
-    - Use fake repositories and gateways for handler unit tests.
-    - Use integration tests for real transaction behavior and adapter or contract tests for external APIs.
-    - Fix time through command context and inject identifiers or make them predictable in tests.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The command represents one clear user or system intent.
-- The payload is serializable and free of framework, ORM, SDK, connection, stream, and function objects.
-- The handler has injected dependencies and handles one command.
-- Authorization, idempotency, transaction boundaries, outbox behavior, retry classification, concurrency protection, observability, and audit requirements are explicit where relevant.
-- Expected command failures are returned as typed values.
-- External effects do not run inside local database transactions.
-- The final response reports any command bus, outbox, idempotency, audit, or retry behavior that was intentionally skipped because the operation did not need it.
-
-<!-- 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`
-
-Choose the narrowest configured verification that proves the changed command path. Use release or documentation checks when command structure is installed by templates, changes public docs, changes schemas, changes CLI behavior, or changes package metadata.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the operation is actually a query or pure function, stop using this skill and keep the simpler structure.
-- If one command hides multiple intents, split it before adding idempotency, audit, or transaction machinery.
-- If payload or context would need raw framework, ORM, SDK, stream, connection, or function objects, move that data conversion to a boundary adapter first.
-- If idempotency cannot be defined for a harmful repeated side effect, do not call the command safely retryable.
-- If an external effect must happen with a state change but no outbox, pending action, provider idempotency, or compensation path exists, report the reliability gap.
-- If tests cannot cover transaction or concurrency behavior at the handler level, add focused integration coverage or report the remaining risk.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Command intent and name
-- Payload and context shape
-- Handler dependencies and responsibilities
-- Domain decisions delegated out of the handler
-- State-machine transitions used or intentionally avoided
-- Strategy family used or intentionally avoided
-- Facade workflow used or intentionally avoided
-- Transaction, outbox, idempotency, retry, concurrency, audit, and observability choices
-- Command bus used or intentionally avoided
-- Tests or verification evidence
-- Skipped checks and remaining command safety risk

package/templates/default/locales/fr/.mustflow/skills/composition-over-inheritance/SKILL.md

@@ -1,176 +0,0 @@
----
-mustflow_doc: skill.composition-over-inheritance
-locale: fr
-canonical: false
-revision: 4
-lifecycle: mustflow-owned
-authority: procedure
-name: composition-over-inheritance
-description: Apply this skill when code introduces, extends, reviews, or refactors class inheritance, base classes, abstract classes, template methods, protected state, mixins, framework subclasses, or subtype hierarchies, especially when behavior reuse, feature variants, provider implementations, policies, strategies, adapters, or test seams could be expressed with composition instead.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.composition-over-inheritance
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Composition Over Inheritance
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Treat inheritance as an exception, not the default way to reuse implementation. Prefer explicit collaborators: small role objects, functions, policies, strategies, adapters, state machines, decorators, and injected dependencies.
-
-The goal is to keep change dimensions separate, avoid fragile parent-child coupling, make tests easy to assemble, and prevent subclass counts from growing with every feature combination.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- New code introduces `extends`, `abstract class`, `Base*`, `Abstract*`, `Common*`, `Core*`, mixins, template methods, `protected` fields, or deep class hierarchies.
-- Existing code is being refactored from inheritance, template methods, no-op overrides, or shared base classes.
-- A feature has multiple change dimensions such as format, storage, notification, provider, environment, permission policy, pricing policy, state transition, or retry behavior.
-- Framework code requires subclassing, but business logic should stay outside the framework subclass.
-- Tests are hard to write because parent setup, `super()` order, protected state, or subclass-specific behavior is entangled.
-- The design could use strategy objects, policy objects, adapters, decorators, state machines, discriminated unions, functions, or dependency injection instead of inheritance.
-- State-specific subclasses are proposed or already exist to represent lifecycle behavior that could be expressed as an explicit transition table.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The code has no inheritance, base-class, subtype, or behavior-combination decision.
-- The inheritance is a shallow and conventional language or ecosystem type, such as `Error`, `Exception`, a required test framework base class, or a required framework lifecycle class.
-- The task is only about external provider boundaries; use `adapter-boundary`.
-- The task is only about hidden dependency construction or global lookup; use `dependency-injection`.
-- The task is a pure data or function refactor where no type hierarchy or collaborator split is being considered.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The class or module under change and any existing inheritance chain, base class, template method, mixin, or protected state.
-- The behavior that needs reuse and the change dimensions that may vary independently.
-- Local patterns for functions, policies, strategies, adapters, state machines, decorators, dependency injection, and tests.
-- Compatibility constraints: public API, framework inheritance requirements, migration wrappers, and existing tests.
-- Relevant command-intent contract entries for tests, builds, docs, templates, release metadata, and mustflow validation.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- The intended behavior is understood well enough to avoid changing semantics while changing structure.
-- If the existing area is unfamiliar, use `pattern-scout` or `codebase-orientation` before changing type boundaries.
-- If the refactor must preserve behavior, use `behavior-preserving-refactor` together with this skill.
-- If multiple algorithms, policies, scoring methods, pricing rules, provider choices, or feature variants share one purpose, use `strategy-pattern` before inventing subclasses.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Replace implementation inheritance with functions, role interfaces, policies, strategies, adapters, decorators, state machines, discriminated unions, or small orchestrating objects.
-- Keep required framework subclasses thin and delegate business behavior to injected use cases or collaborators.
-- Add temporary compatibility wrappers when needed for a safe migration away from existing subclasses.
-- Add focused tests or fixtures that lock current behavior before changing inheritance structure.
-- Do not create broad `Base`, `Abstract`, `Common`, `Core`, or `Manager` classes to share miscellaneous methods.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Identify why inheritance is present or being proposed.
-   - Allowed reasons: required framework base class, conventional error or exception type, required test framework base class, sealed or closed type hierarchy, or a true substitutable subtype relationship.
-   - Suspicious reasons: sharing common methods, toggling optional behavior, swapping providers, reducing conditionals, hiding setup, reusing validation, or grouping unrelated helpers.
-2. Apply the substitution check before keeping inheritance.
-   - A child must be safe everywhere the parent is expected.
-   - The child must not require stricter inputs, return weaker outputs, no-op parent behavior, throw for normal parent methods, or require callers to check `instanceof`, class name, kind, mode, or type before use.
-3. Count independent change dimensions.
-   - If format, storage, notification, provider, policy, environment, permission, state, retry, logging, caching, or transport can change independently, do not encode the combination as subclasses.
-   - Split each meaningful dimension into a role object, function, strategy, policy, adapter, decorator, state machine, or data field.
-4. Inspect the inheritance depth and coupling.
-   - Application code should have inheritance depth 0 or 1.
-   - Reject chains where behavior depends on `super()` order, parent constructor side effects, protected mutable state, or parent methods calling overridable child methods.
-5. Replace shared implementation with simpler composition first.
-   - Use pure functions for stateless calculations and formatting.
-   - Use role objects for replaceable collaborators.
-   - Use policy objects for business decisions.
-   - Use strategy objects for algorithms, policies, scoring methods, provider choices, and feature variants. Use `strategy-pattern` before adding or refactoring a strategy family.
-   - Use facade objects for stable high-level subsystem entry points that coordinate several collaborators. Use `facade-pattern` before adding or refactoring a facade.
-   - Use adapters for external services and provider-specific data.
-   - Use decorators for cross-cutting behavior such as logging, caching, retry, rate limiting, timing, and authorization.
-   - Use state machines or transition tables when state controls allowed actions. Use `state-machine-pattern` before editing lifecycle state transitions, status fields, guards, terminal states, or transition effects.
-   - Use discriminated unions or sealed types for closed data variants when the language supports them.
-6. Keep orchestration explicit. A composed object may own the workflow, but it should delegate each variable behavior to a collaborator rather than reaching into subclass hooks.
-7. Keep construction outside the core object when collaborators are replaceable or external. If the change introduces injected collaborators, apply `dependency-injection`; if those collaborators cross provider or protocol boundaries, also apply `adapter-boundary`.
-8. Keep framework subclasses thin when inheritance is unavoidable.
-   - They may parse requests, extract framework context, call use cases, and map responses.
-   - They should not contain domain policy, external API calls, database queries, complex state transitions, or provider-specific translation.
-9. Use temporary wrappers only for migration.
-   - A legacy subclass may delegate to a new composed implementation to preserve public API.
-   - New code should use the composed implementation directly.
-   - Remove wrappers after callers have migrated.
-10. Guard against over-composition.
-    - Do not create interfaces for one-line pure functions, stable internal helpers, or single implementations with no external boundary and no test replacement need.
-    - If every class only delegates once, constructor setup becomes harder than the business logic, or a dependency object becomes broad, simplify.
-11. Protect behavior with tests.
-    - Before refactoring an inheritance tree, add or reuse tests around the observable behavior.
-    - Prefer fake collaborators over parent-state setup.
-    - Add tests for each extracted policy, strategy, adapter, decorator, or state transition when the behavior is meaningful.
-12. Verify with the narrowest configured command intents that cover changed source, tests, templates, docs, release metadata, and mustflow checks.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- New application code does not add inheritance for implementation reuse.
-- Any remaining inheritance is shallow, justified, and isolated to framework, error, test, or closed-type cases.
-- Shared behavior lives in functions, role objects, policies, strategies, adapters, decorators, state machines, or explicit data structures.
-- Variable behavior is selected by composition rather than subclass explosion.
-- There is no protected mutable state, no-op override, parent-child type check, or `super()` call-order dependency in core logic.
-- Tests can replace collaborators without constructing a fragile parent hierarchy.
-
-<!-- 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 behavior. Use documentation and release checks when skill routes, templates, public docs, package metadata, or installed-file surfaces change.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If inheritance is required by a framework, keep the subclass as an adapter and move business behavior to composed collaborators.
-- If an inheritance refactor would break public API, add a temporary wrapper and report the migration path.
-- If extracted collaborators are too many or too vague, collapse them into fewer functions or role objects with clearer ownership.
-- If tests require protected state or parent internals, add higher-level behavior tests before changing structure.
-- If a class still needs many collaborators after composition, look for mixed responsibilities and split the use case rather than adding a broad dependency bag.
-- If local language features make a sealed hierarchy or discriminated union clearer than strategy objects, use the simpler closed-data representation and report why.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Inheritance or base-class surface reviewed
-- Reason for keeping or replacing inheritance
-- Change dimensions identified
-- Composition pattern selected
-- Framework or error inheritance exceptions, if any
-- Collaborators, functions, policies, strategies, facades, adapters, decorators, or state machines added or reused
-- Temporary compatibility wrappers, if any
-- Tests added or reused
-- Command intents run
-- Skipped checks and reasons
-- Remaining inheritance or composition risk

package/templates/default/locales/fr/.mustflow/skills/contract-sync-check/SKILL.md

@@ -1,116 +0,0 @@
----
-mustflow_doc: skill.contract-sync-check
-locale: fr
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: contract-sync-check
-description: Apply this skill when a change affects a declared contract that must stay aligned across code, schemas, templates, tests, and documentation.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.contract-sync-check
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Contract Sync Check
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Keep declared behavior, machine-readable contracts, installed templates, tests, and public documentation from drifting apart after a change.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A command, option, JSON output, schema, template file, manifest, lock entry, preference, or public document changes.
-- A change adds, removes, renames, or reclassifies a mustflow-owned file.
-- Tests encode expected package, template, schema, command, dashboard, or documentation behavior.
-- A user asks whether documentation, configuration, or installed template behavior should be updated together.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task is a private implementation refactor with no declared contract or public surface.
-- The changed files are already covered by a narrower skill whose procedure explicitly checks every affected contract.
-- The user explicitly asks for a local experiment that should not update published or installed surfaces.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- Changed-file list and intended behavior change.
-- The primary contract source, such as code, schema, config, template metadata, or documentation.
-- Known derived surfaces: tests, README, docs site, localized templates, manifests, lock files, and JSON Schemas.
-- Relevant command-intent contract entries.
-
-<!-- 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
-
-- Update only the surfaces required to keep the contract consistent.
-- Add or adjust tests only when they encode the changed contract or packaging surface.
-- Mark translations or prose-heavy docs for review when exact wording cannot be confidently localized.
-- Do not broaden command permissions, invent new contract files, or convert exploratory notes into binding policy.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Name the contract being changed and identify its source of truth.
-2. List the expected synchronized surfaces for that contract: source code, schemas, command metadata, templates, manifests, lock files, tests, README, docs site, and localized copies.
-3. Compare the changed files with that list and add any missing required surface.
-4. Keep derived files mechanically aligned with the source of truth. If a surface is intentionally not updated, record the reason.
-5. Check that command intent names, schema ids, frontmatter revisions, template entries, version strings, and documented examples match exactly where they are meant to match.
-6. Use the narrowest configured verification that covers the contract and any packaging or documentation surface touched.
-7. In the final report, separate synchronized surfaces from skipped or deferred surfaces.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The contract source and every required derived surface agree.
-- Any intentionally stale, deferred, or review-needed surface is explicitly named.
-- The final report includes the command intents used to verify contract alignment.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Also run a narrower configured test or build intent if the contract affects executable behavior.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If validation finds drift, fix the first contract mismatch before adding new behavior.
-- If the source of truth is unclear, stop and report the competing sources instead of picking one silently.
-- If a required surface is too broad to verify in the current task, report the skipped surface and its risk.
-- If localized surfaces cannot be confidently updated, keep source metadata accurate and mark those translations for review.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Contract changed
-- Source of truth used
-- Synchronized surfaces
-- Deferred or review-needed surfaces
-- Command intents run
-- Skipped checks and reasons
-- Remaining drift risk