mustflow 1.18.16 → 1.31.0

package/templates/default/locales/hi/.mustflow/skills/facade-pattern/SKILL.md

@@ -1,210 +0,0 @@
----
-mustflow_doc: skill.facade-pattern
-locale: hi
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: facade-pattern
-description: Apply this skill when a controller, handler, command, service, or UI event needs a stable high-level entry point over a complex subsystem, repeated multi-step workflow, multiple dependencies, external services, repositories, queues, caches, file storage, transactions, idempotency, retries, logging, or normalized results, without turning that entry point into a god service or hiding domain rules.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.facade-pattern
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Facade Pattern
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Provide one simple, stable public entry point in front of a complex subsystem or repeated workflow.
-
-A facade is not a convenient name for a large service class. It is a thin application-level coordinator that hides internal ordering, external provider details, retries, transactions, logging, idempotency, and result normalization from callers while keeping domain decisions visible in domain objects, pure functions, policies, strategies, commands, or state machines.
-
-Use this skill to make callers say what they want done while the facade controls where the subsystem complexity lives.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- One user or system action requires three or more internal steps.
-- One operation coordinates two or more dependencies such as repositories, gateways, storage, queues, caches, validators, scanners, compressors, event publishers, or external services.
-- The same internal sequence is repeated across controllers, handlers, workers, UI event handlers, or services.
-- Callers know too much about implementation order, provider SDKs, database records, file storage, cache keys, queues, or external response shapes.
-- Failure handling, retry, timeout, logging, transactions, idempotency, cache invalidation, or event publishing differs between call sites for the same operation.
-- A controller, route, job, command handler, or UI event handler directly performs subsystem orchestration instead of delegating to a stable entry point.
-- The internal implementation is likely to change while the caller-facing operation should remain stable.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The facade would only call one method with a different name.
-- The caller is already simple and does not know internal subsystem details.
-- The intent is to hide messy code without clarifying ownership, tests, or boundaries.
-- Domain rules, pricing, permissions, eligibility, validation policy, or state transitions are the main problem; use `pure-core-imperative-shell`, `strategy-pattern`, or `state-machine-pattern` as appropriate.
-- Several interchangeable algorithms or policies are the main problem; use `strategy-pattern`.
-- A single external API or protocol needs translation into an internal shape; use `adapter-boundary`.
-- One state-changing intent needs payload, context, transaction, idempotency, audit, retry, outbox, and traceability semantics; use `command-pattern`, and place a facade below it only when there is a real subsystem workflow to simplify.
-- The proposed facade would become `AppFacade`, `SystemFacade`, `CommonService`, `Manager`, `Helper`, or another catch-all container.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The caller surface that should become simpler: controller, router, UI handler, command handler, worker, job, or service.
-- The high-level operation name and the user or system purpose it represents.
-- The current internal sequence, repeated call sites, or leaked subsystem details.
-- Dependencies involved and whether each is a domain service, pure policy, repository port, gateway port, adapter, queue, cache, transaction manager, idempotency store, logger, or event publisher.
-- Expected success response and expected failure cases.
-- Authorization, idempotency, retry, transaction, observability, security, and performance requirements.
-- Local conventions for request objects, context objects, `Result` values, ports, adapters, dependency injection, commands, events, 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 has enough real subsystem complexity to justify a facade.
-- The facade boundary is a feature area or workflow boundary, not a whole application boundary.
-- If preserving existing behavior, `behavior-preserving-refactor` has been applied before moving orchestration.
-- If external systems cross the boundary, `adapter-boundary` and `dependency-injection` have been applied so the facade depends on internal ports rather than SDK clients.
-- If expected failure or absence is part of the contract, `result-option` has been applied to the return shape.
-- If the operation is a traceable state-changing intent, `command-pattern` has been considered so the facade does not replace command semantics.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Add or update a narrow facade in an application or feature boundary.
-- Add request, response, context, and facade error types.
-- Add or update ports, injected collaborators, mapper functions, error normalizers, idempotency handling, transaction orchestration, retry policy calls, event publishing, cache invalidation, and logging directly needed by the facade.
-- Move repeated subsystem ordering out of controllers, handlers, workers, command handlers, or UI event handlers into the facade.
-- Add tests with fake dependencies for success, validation, permission, dependency failure, error normalization, idempotency, event publishing, transaction behavior, and sensitive-log protection.
-- Do not move domain rules into the facade just because the facade coordinates the operation.
-- Do not expose private subsystem steps as public facade methods.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Classify the need.
-   - Use a facade when the caller needs one stable high-level operation but currently knows internal ordering or multiple subsystem details.
-   - Do not use a facade for a one-line wrapper, a pure policy, a provider translation, a lifecycle transition table, or a command execution unit by itself.
-2. Name the facade by feature area or workflow.
-   - Prefer names such as `FileUploadFacade`, `CheckoutFacade`, `BillingFacade`, `ReportExportFacade`, or `SignupFacade`.
-   - Avoid broad names such as `AppFacade`, `SystemFacade`, `CommonService`, `Manager`, `Helper`, and `Util`.
-3. Name public methods by caller intent.
-   - Use names such as `uploadImage`, `checkout`, `createInvoice`, `refundPayment`, `exportReport`, or `sendWelcomeNotification`.
-   - Avoid public methods named after internal steps such as `compress`, `scan`, `saveMetadata`, `publishEvent`, or `invalidateCache`.
-   - Keep public methods few. A facade with many public methods probably owns more than one workflow.
-4. Define request and context shapes.
-   - Accept one request object for operation data.
-   - Accept a separate context object for actor, request identifier, correlation identifier, tenant or account scope, idempotency key, source, and trusted server-side execution facts.
-   - Do not pass long primitive parameter lists, framework request objects, response objects, ORM entities, SDK clients, database connections, file streams, or loggers as request payload.
-5. Define normalized response and failure shapes.
-   - Return the minimum caller-needed success facts.
-   - Return expected failures as `Result` values or the local equivalent.
-   - Do not return provider SDK responses, ORM models, full database rows, internal domain entities, raw exception objects, secrets, internal file paths, or unnecessary metadata.
-6. Keep dependencies explicit and replaceable.
-   - Inject collaborators through constructors or function parameters.
-   - Depend on role interfaces or ports, not concrete SDK clients or framework objects.
-   - Wrap external SDKs in adapters before they reach the facade.
-   - Avoid facade-to-facade dependency chains. If two facades need the same lower-level behavior, extract a shared lower-level service, port, or pure function.
-7. Keep the facade stateless per request.
-   - Store injected dependencies, immutable configuration, and read-only policy objects only.
-   - Do not store current user, current request, current file, current transaction, intermediate result, last response, or mutable request-specific collections in facade fields.
-8. Delegate domain decisions.
-   - The facade may perform basic input checks, call validators, pass context, check permissions through a policy, coordinate dependencies, normalize errors, and return results.
-   - It must not become the home for pricing formulas, eligibility rules, permission policy, lifecycle transitions, state mutation rules, or complex calculations.
-   - Use pure core functions, policies, strategies, commands, or state machines for domain decisions and have the facade call them.
-9. Control transactions carefully.
-   - Use transactions for fast local persistence that must commit together.
-   - Do not hold a database transaction open while calling slow external APIs, email, webhooks, file uploads, payment providers, AI calls, or other long network work.
-   - When local state and external work must coordinate, use idempotency keys, pending states, action ledgers, outbox records, sagas, compensation commands, or worker jobs.
-10. Make harmful duplicate execution safe.
-    - Require idempotency for payments, refunds, order creation, account creation, file uploads, email sends, coupon use, point grants, external sync, and webhook handling.
-    - Scope idempotency by actor, tenant, workspace, account, owner, or other trust boundary.
-    - Store stable payload hashes rather than raw sensitive payloads.
-    - Return existing results for the same key and same payload hash, and return conflicts for the same key with different payload.
-11. Apply retry only when safe.
-    - Retry transient network, timeout, rate-limit, provider outage, and read operations when the operation is safe or idempotent.
-    - Do not retry invalid input, denied access, unsupported formats, domain-rule failures, terminal state transitions, or unsafe writes without idempotency.
-    - Return retryability in failure results when callers or workers need it.
-12. Add safe observability.
-    - Log high-level operation start, success, failure, duration, request identifier, actor identifier, resource identifier, error code, retry count, and idempotency-key presence when useful.
-    - Do not log passwords, tokens, cookies, API keys, raw card data, raw personal data, raw file content, full provider responses, full request bodies, or raw external exceptions.
-    - Use consistent event names such as `<domain>.<operation>.started`, `<domain>.<operation>.succeeded`, and `<domain>.<operation>.failed`.
-13. Keep performance visible.
-    - If the operation is expensive or long-running, name it with words such as `request`, `schedule`, `enqueue`, or `start`, then return a job identifier or queued status.
-    - Add timeouts to external calls.
-    - Avoid hidden N+1 behavior behind a simple facade method.
-    - Limit response data to what the caller needs.
-14. Document the public facade contract when the method is new or changed.
-    - Include purpose, input, output, failure codes, side effects, idempotency, transaction behavior, external dependencies, synchronous or asynchronous behavior, and security requirements.
-    - Keep comments concise and attached to public API surfaces rather than private implementation details.
-15. Test at the facade boundary.
-    - Use fake repositories, gateways, storage, scanners, event publishers, idempotency stores, transaction runners, and loggers.
-    - Cover success, validation failure, permission denial, missing resource, dependency failure, error normalization, event or outbox creation, idempotency hit, idempotency conflict, dangerous missing key, transaction rollback when relevant, and no sensitive logging.
-    - Do not call real external APIs, real payments, real email, real large uploads, or private methods directly in facade unit tests.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Callers invoke a high-level operation and no longer know internal subsystem order.
-- Public facade methods express caller intent, not internal steps.
-- Request data and execution context are separated.
-- Success responses and expected failures are normalized.
-- External SDK types, provider errors, ORM models, framework objects, and internal paths do not cross the facade boundary.
-- Dependencies are injected and test-replaceable.
-- Domain decisions remain outside the facade.
-- Transactions, idempotency, retry, logging, security, and performance behavior are explicit where the operation needs them.
-- Tests cover the facade's observable result and side effects through fake dependencies.
-
-<!-- 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 covers changed facade code, dependencies, tests, templates, docs, release metadata, and mustflow routing.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the facade is a one-method pass-through wrapper, remove it or merge it back into the caller.
-- If the facade grows into a god service, split it by workflow or feature area.
-- If the facade hides domain rules, extract those rules into pure functions, policy objects, strategies, state machines, or domain services.
-- If public methods expose internal steps, make them private or move them to lower-level collaborators.
-- If provider objects or errors leak through the facade result, add adapters and error mappers.
-- If the facade must call another facade, check for a lower-level shared dependency before accepting the coupling.
-- If idempotency or retry cannot be made safe for a harmful side effect, fail closed and report the manual or workflow gap.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Facade need and selected workflow boundary
-- Caller surface simplified
-- Request, context, response, and failure shapes
-- Dependencies injected and lower-level collaborators used
-- Domain decisions delegated out of the facade
-- Adapter, command, strategy, state-machine, or pure-core boundaries used with this skill
-- Transaction, idempotency, retry, logging, security, and performance choices
-- Tests or verification evidence
-- Skipped checks and remaining facade risk

package/templates/default/locales/hi/.mustflow/skills/failure-triage/SKILL.md

@@ -1,97 +0,0 @@
----
-mustflow_doc: skill.failure-triage
-locale: hi
-canonical: false
-revision: 2
-lifecycle: mustflow-owned
-authority: procedure
-name: failure-triage
-description: जब कोई configured command intent या verification step विफल हो, तब इस स्किल का उपयोग करें।
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.failure-triage
-  command_intents:
-    - mustflow_check
----
-
-# विफलता विश्लेषण
-
-<!-- mustflow-section: purpose -->
-## उद्देश्य
-
-फाइलें संशोधित करने से पहले विफल कमांड या सत्यापन चरण की सबसे संभावित मूल वजह पहचानना।
-
-<!-- mustflow-section: use-when -->
-## कब उपयोग करें
-
-- कोई configured command intent non-zero exit code लौटाए।
-- validation, build, test, या documentation checks विफल हों।
-- विफलता की मूल वजह अभी स्पष्ट न हो।
-
-<!-- mustflow-section: do-not-use-when -->
-## कब उपयोग न करें
-
-- विफलता पूरी तरह समझ में आ चुकी हो और लक्षित समाधान उपलब्ध हो।
-- उपयोगकर्ता ने केवल उच्च-स्तरीय सारांश मांगा हो।
-
-<!-- mustflow-section: required-inputs -->
-## आवश्यक इनपुट
-
-- मूल command intent
-- exit code
-- stdout और stderr की truncated output
-- हाल ही में संशोधित फाइलें
-- संबंधित command contract entry
-
-<!-- mustflow-section: preconditions -->
-## पूर्व शर्तें
-
-- Task Use When conditions से match करता है और Do Not Use When exclusions से match नहीं करता।
-- Required inputs उपलब्ध हैं, या missing inputs को guess किए बिना report किया जा सकता है।
-- Higher-priority instructions और `.mustflow/config/commands.toml` current scope के लिए check किए गए हैं।
-
-<!-- mustflow-section: allowed-edits -->
-## अनुमत edits
-
-- Edits को इस skill, user request और `.mustflow/skills/INDEX.md` की matching route में बताए scope तक सीमित रखें।
-- Command permission न बढ़ाएं, project facts invent न करें और unrelated workflow files न बदलें।
-
-<!-- mustflow-section: procedure -->
-## प्रक्रिया
-
-1. मूल विफल intent नाम संरक्षित रखें।
-2. पहली actionable error का विश्लेषण करें।
-3. तय करें कि विफलता code, tests, configuration, documentation, या environment से आई है।
-4. सबसे प्रासंगिक फाइलों की जांच करें।
-5. एकल परिकल्पना बनाएं और सबसे लक्षित configured intent से सत्यापित करें।
-
-<!-- mustflow-section: postconditions -->
-## पश्च शर्तें
-
-- Expected output clear evidence, executed command intents, skipped checks और remaining risks के साथ बनाया जा सकता है।
-- Missing command intent, unknown input या authority conflict को छिपाने के बजाय report किया जाता है।
-
-<!-- mustflow-section: verification -->
-## सत्यापन
-
-जहां संभव हो, मूल विफल intent फिर से चलाएं। यदि वह बहुत व्यापक है, तो वही विफलता क्षेत्र अलग करने वाला
-सबसे लक्षित configured intent चलाएं।
-
-<!-- mustflow-section: failure-handling -->
-## विफलता प्रबंधन
-
-- असंबंधित समाधानों को एक साथ न जोड़ें।
-- यदि विफलता missing tools के कारण हो, तो missing tool और समस्या दिखाने वाली command रिपोर्ट करें।
-- यदि output में संवेदनशील डेटा दिखे, तो raw output कॉपी करना रोकें और जानकारी को सुरक्षित रूप में सारांशित करें।
-
-<!-- mustflow-section: output-format -->
-## आउटपुट प्रारूप
-
-- विफल intent
-- संभावित मूल कारण
-- साक्ष्य
-- लागू या अनुशंसित समाधान
-- चलाया गया सत्यापन
-- शेष जोखिम

package/templates/default/locales/hi/.mustflow/skills/instruction-conflict-scope-check/SKILL.md

@@ -1,118 +0,0 @@
----
-mustflow_doc: skill.instruction-conflict-scope-check
-locale: hi
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: instruction-conflict-scope-check
-description: Apply this skill when repository, host, user, nested-project, command-contract, preference, or generated instruction sources conflict or make the safe edit, command, verification, commit, push, deletion, migration, or reporting scope unclear.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.instruction-conflict-scope-check
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Instruction Conflict Scope Check
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Resolve conflicting instructions by narrowing authority, edit scope, command scope, and reporting boundaries before work proceeds.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- User instructions, host rules, `AGENTS.md`, nested repository instructions, `.mustflow/config/*.toml`, preferences, skills, generated files, or roadmap text point in different directions.
-- It is unclear whether to edit the parent repository or a nested child repository.
-- It is unclear whether a command, commit, push, delete, migration, background process, browser launch, or long-running task is allowed.
-- A lower-priority document appears to authorize behavior that a higher-priority rule blocks.
-- A final report needs to explain why part of a request was skipped, narrowed, or deferred.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The instruction order is clear and only a normal task-specific skill applies.
-- The problem is untrusted pasted text trying to override rules; use `external-prompt-injection-defense` for that part.
-- The task is only a documentation wording change and makes no authority, scope, or command claim.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The conflicting instruction sources and the exact behavior they appear to require or forbid.
-- The affected scope: repository root, nested project, file paths, command intents, verification, Git operation, migration, or report.
-- The user's direct request and any newer clarifying message.
-- Relevant command-intent contract entries and nearest `AGENTS.md` files for the affected paths.
-
-<!-- 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
-
-- Clarify workflow docs, skills, templates, tests, or reports that caused the conflict.
-- Narrow edits to the nearest applicable repository and the smallest safe surface.
-- Record skipped or deferred work when authority is missing.
-- Do not broaden command permission, override host safety rules, edit outside the selected repository, or treat preferences as higher priority than direct user instructions.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. List the conflicting sources in priority order: direct user request, host safety rules, nearest repository instructions, mustflow config, skills, preferences, generated state, and lower-priority docs.
-2. Identify the affected action: edit, read, verify, command run, commit, push, delete, migration, background process, browser launch, or final report.
-3. Select the nearest applicable repository root and path scope. If a nested repository is involved, reread that repository's instructions before editing there.
-4. Apply the stricter safe rule when safety, secrets, destructive actions, command permission, or repository boundaries conflict.
-5. Treat preferences as defaults only. Do not let preferences authorize commands, commits, pushes, migrations, or edits that higher-priority rules block.
-6. If command authority is unclear, use configured command intents only or report the missing command rather than inferring a raw command.
-7. If the conflict can be resolved by a small documentation or template clarification, update the source that caused confusion and keep the wording subordinate to the canonical contract.
-8. Report the chosen scope, skipped scope, and reason when part of the request cannot be completed safely.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The active instruction source, repository root, edit scope, command scope, and skipped scope are clear.
-- Any changed docs or templates do not create a new self-authorizing policy source.
-- The final report distinguishes completed work from blocked, deferred, or intentionally skipped work.
-
-<!-- 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 or docs intent when it better proves the clarified instruction or template surface.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If two high-priority instructions cannot be reconciled, stop and report the conflict instead of guessing.
-- If the nearest repository root is unclear, inspect read-only status and instruction files before editing.
-- If a command, Git operation, migration, or destructive action lacks authority, do not run it. Report the missing approval or command contract.
-- If validation finds command-permission or authority drift, fix that drift before adding unrelated behavior.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Conflicting instruction sources
-- Chosen priority rule and repository scope
-- Actions allowed, narrowed, skipped, or deferred
-- Documentation or template clarifications made
-- Command intents run
-- Skipped checks and reasons
-- Remaining authority or scope risk

package/templates/default/locales/hi/.mustflow/skills/line-ending-hygiene/SKILL.md

@@ -1,111 +0,0 @@
----
-mustflow_doc: skill.line-ending-hygiene
-locale: hi
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: line-ending-hygiene
-description: Apply this skill when Git reports CRLF/LF warnings or when tracked text files may need repository line-ending normalization.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.line-ending-hygiene
-  command_intents:
-    - line_endings_check
-    - changes_status
-    - mustflow_check
----
-
-# Line Ending Hygiene
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Detect line-ending drift without silently rewriting a repository, and normalize only when a repository policy and explicit user request make it safe.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- Git reports CRLF, LF, or line-ending replacement warnings.
-- A diff or formatter appears to rewrite files only because of line endings.
-- A user asks why line-ending warnings appear.
-- A user asks to normalize tracked files to the repository line-ending policy.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task is unrelated to Git, text files, formatting, or command-output warnings.
-- The repository has no line-ending policy and the user has not asked to create one.
-- The only affected files are generated artifacts, package archives, images, databases, or other binary files.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The warning text or changed-file evidence.
-- Current `.gitattributes` or equivalent repository line-ending policy.
-- Current changed-file status.
-- The configured command intents for line-ending checks and manual normalization.
-
-<!-- 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 line-ending policy files only when the user asks for a repository policy change.
-- Normalize tracked text files only when the user explicitly requests normalization and the repository declares an LF policy.
-- Do not rewrite binary files, generated archives, dependency folders, or unrelated source files.
-- Do not change formatting, indentation, or content while handling line endings.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Inspect the changed-file status before deciding whether line endings are the actual issue.
-2. Use the `line_endings_check` intent when it is configured and agent-runnable.
-3. If no LF policy is declared, report the missing policy instead of normalizing files.
-4. If drift is found, report the affected tracked files and whether normalization was only previewed.
-5. Use normalization only after an explicit user request, and treat `line_endings_normalize` as manual-only unless the repository declares otherwise.
-6. After any normalization, re-run the line-ending check and a relevant validation intent for the touched scope.
-7. Keep the final report focused on policy, files changed, checks run, and remaining risk.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The agent has not silently rewritten the working tree.
-- Any normalization is tied to a declared repository policy.
-- Remaining CRLF, mixed line endings, missing policy, or manual-only command gaps are reported.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `line_endings_check`
-- `changes_status`
-- `mustflow_check`
-
-If normalization touched code, documentation, templates, or release surfaces, also run the narrowest configured verification that covers those changed files.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If Git is unavailable or the repository is not a Git working tree, report that tracked-file inspection is unavailable.
-- If a line-ending check fails because drift exists, do not treat it as a tool failure; report the affected files and next safe action.
-- If normalization fails, stop after the first relevant error and do not attempt broader formatting.
-- If the repository policy conflicts with user intent, ask for an explicit policy decision before editing.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Line-ending policy found
-- Files with CRLF or mixed line endings
-- Files normalized
-- Command intents run
-- Command intents skipped with reasons
-- Remaining line-ending risk

package/templates/default/locales/hi/.mustflow/skills/migration-safety-check/SKILL.md

@@ -1,117 +0,0 @@
----
-mustflow_doc: skill.migration-safety-check
-locale: hi
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: migration-safety-check
-description: Apply this skill when code, data, schema, configuration, file layout, template, or generated-state migrations are planned, edited, documented, or reported.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.migration-safety-check
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Migration Safety Check
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Keep migrations reversible, scoped, and verified before they affect data, schemas, configuration, templates, generated state, or file layout.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A change moves, renames, deletes, transforms, backfills, or rewrites files, data, schemas, configuration, template state, generated state, or persisted metadata.
-- A task mentions migration, upgrade, conversion, import, export, reindexing, backfill, cleanup, lock refresh, or baseline regeneration.
-- Documentation or final reports claim that a migration is safe, complete, reversible, idempotent, or already applied.
-- A change could make older installed projects, existing lock files, generated files, caches, or user-edited documents incompatible.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The change is a small local refactor with no persisted, generated, installed, or user data surface.
-- The task only edits inert documentation and makes no claim about applying or validating a migration.
-- The migration would require live production access, destructive actions, or manual operator approval that is outside the current command contract.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The source state, target state, and the files or data that would change.
-- The owner of the migration surface: code, schema, template, lock file, generated state, cache, package, or docs.
-- Idempotency, rollback, backup, dry-run, compatibility, and failure behavior expectations.
-- Relevant command-intent contract entries for status, diff, docs, release, 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
-
-- Add or tighten migration plans, compatibility notes, dry-run behavior, validation checks, lock metadata, tests, and docs tied to the changed surface.
-- Prefer idempotent, explicit, and inspectable migration behavior over implicit one-way rewrites.
-- Mark rollback, backup, or compatibility gaps as unverified when they cannot be proven.
-- Do not run destructive migrations, delete user data, rewrite generated state broadly, or claim live migration success without configured evidence.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Identify the migration surface and classify it as code, schema, data, configuration, template, generated state, cache, package metadata, or documentation.
-2. Record the source state, target state, expected affected paths, and whether the change must support old and new states during transition.
-3. Check whether the migration is idempotent: a second run should either do nothing or report an already-applied state without extra diffs.
-4. Check rollback or recovery expectations: backup, restore path, manual fallback, or explicit "not reversible" report.
-5. Prefer dry-run or read-only inspection before apply behavior when a command or workflow exists for it.
-6. Keep compatibility claims tied to fixtures, lock metadata, tests, generated output, or documented command results.
-7. If the migration changes public docs, installed templates, package contents, or lock files, synchronize the related metadata and version surfaces.
-8. Run the narrowest configured verification that proves the migrated surface and its metadata still agree.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The migration surface, source state, target state, and compatibility boundary are named.
-- Idempotency, rollback, backup, dry-run, and verification status are either proven or explicitly left as remaining risk.
-- Final reports do not imply that a live or destructive migration ran unless configured evidence proves it.
-
-<!-- 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, migration dry-run, or documentation intent when it better proves the changed migration surface.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the migration has no rollback or dry-run path, report that risk before applying broader changes.
-- If a migration check fails, stop at the first affected surface and avoid cascading rewrites.
-- If old and new states conflict, preserve user data and lock metadata before updating generated or derived files.
-- If verification requires live data, operator approval, or destructive access, stop at that boundary and report the skipped check.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Migration surface reviewed
-- Source and target state
-- Idempotency and rollback status
-- Compatibility or lock metadata updated
-- Command intents run
-- Skipped checks and reasons
-- Remaining migration risk