mustflow 2.24.2 → 2.25.1

package/package.json

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

package/templates/default/i18n.toml

@@ -56,7 +56,7 @@ translations = {}
 [documents."skills.index"]
 source = "locales/en/.mustflow/skills/INDEX.md"
 source_locale = "en"
-revision = 82
+revision = 85
 translations = {}
 
 [documents."skill.adapter-boundary"]
@@ -146,13 +146,13 @@ translations = {}
 [documents."skill.line-ending-hygiene"]
 source = "locales/en/.mustflow/skills/line-ending-hygiene/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.file-path-cross-platform-change"]
 source = "locales/en/.mustflow/skills/file-path-cross-platform-change/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 4
 translations = {}
 
 [documents."skill.diff-risk-review"]
@@ -302,7 +302,7 @@ translations = {}
 [documents."skill.cross-platform-filesystem-safety"]
 source = "locales/en/.mustflow/skills/cross-platform-filesystem-safety/SKILL.md"
 source_locale = "en"
-revision = 3
+revision = 6
 translations = {}
 
 [documents."skill.pure-core-imperative-shell"]
@@ -391,7 +391,7 @@ translations = {}
 [documents."skill.process-execution-safety"]
 source = "locales/en/.mustflow/skills/process-execution-safety/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 4
 translations = {}
 
 [documents."skill.repo-improvement-loop"]
@@ -409,7 +409,7 @@ translations = {}
 [documents."skill.structure-discovery-gate"]
 source = "locales/en/.mustflow/skills/structure-discovery-gate/SKILL.md"
 source_locale = "en"
-revision = 27
+revision = 28
 translations = {}
 
 [documents."skill.state-machine-pattern"]

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

@@ -2,7 +2,7 @@
 mustflow_doc: skills.index
 locale: en
 canonical: true
-revision: 82
+revision: 85
 authority: router
 lifecycle: mustflow-owned
 ---
@@ -98,6 +98,7 @@ routes. Event routes stay inactive until their event occurs.
 | --- | --- | --- | --- | --- | --- | --- |
 | Code changes need review before report | `.mustflow/skills/code-review/SKILL.md` | Diff and task goal | Changed files | behavior and regression | `test`, `test_related`, `test_audit`, `lint` | Findings or no-issue note |
 | An unfamiliar codebase area needs an evidence-based map before planning, implementation, or reporting | `.mustflow/skills/codebase-orientation/SKILL.md` | User request, target area, relevant instructions, and current source, test, schema, template, configuration, or documentation files | Read-only orientation notes and any smallest follow-up edit chosen from inspected evidence | stale documentation, wrong ownership boundary, or invented architecture claim | `changes_status`, `changes_diff_summary`, `mustflow_check` | Scope inspected, entrypoints, flow map, ownership boundaries, verification options, risks, unknowns, and smallest safe next step |
+| A coding task has missing intent, scope, domain, data, security, UX, dependency, architecture, or verification decisions that cannot be safely inferred from repository evidence | `.mustflow/skills/clarifying-question-gate/SKILL.md` | User request, inspected repository evidence, unresolved decisions, reversibility classification, recommended option, and tradeoffs | Blocking questions, safe assumptions, and the smallest safe implementation boundary | over-questioning, lazy questions, expensive wrong assumptions, user-owned decision drift, data loss, auth bypass, public-contract drift, dependency bloat, or unverifiable completion | `changes_status`, `changes_diff_summary`, `mustflow_check` | Repository evidence inspected, blocking questions with recommendations, safe assumptions, selected scope, verification, and remaining ambiguity |
 | HTTP, REST, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, request/response schema, status code, header, error envelope, pagination, filtering, sorting, search, generated client, SDK, mock, fixture, or API docs contract is created or changed | `.mustflow/skills/api-contract-change/SKILL.md` | API style, contract source of truth, changed operations, request and response schemas, status and headers, error envelope, auth and permission behavior, pagination/filter/sort/search semantics, generated clients, SDKs, mocks, fixtures, callers, docs, and command contract entries | Routes, handlers, resolvers, validators, schemas, generated clients, SDKs, mocks, fixtures, docs, tests, and directly synchronized examples | route-only change, schema drift, generated-client breakage, hidden breaking change, status or error drift, pagination/search semantic drift, auth/permission drift, or stale docs examples | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | API contract source, changed operations, compatibility classification, synchronized client/schema/docs/tests surfaces, verification, and remaining API contract risk |
 | TypeScript source, declarations, tsconfig, package exports, module resolution, public API, or TypeScript tests are created or changed | `.mustflow/skills/typescript-code-change/SKILL.md` | TypeScript config, package entry metadata, target runtime, changed files, and command contract entries | TypeScript source, declarations, compiler config, exports, tests, and directly synchronized docs | weakened type safety, module drift, public API drift, or unverified declaration output | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime, module, type, and public API boundary checked, changes made, verification, and remaining TypeScript risk |
 | JavaScript source, module format, package entry, browser or Node runtime, dependency usage, Promise handling, bundler config, or JavaScript tests are created or changed | `.mustflow/skills/javascript-code-change/SKILL.md` | Package metadata, module system, runtime target, entrypoints, changed files, and command contract entries | JavaScript source, package exports, bundler config, dependencies, tests, and docs examples | runtime API leakage, ESM/CJS drift, discarded Promise, dependency bloat, or broken package entry | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Runtime and module boundary checked, async and dependency notes, verification, and remaining JavaScript risk |
@@ -110,7 +111,7 @@ routes. Event routes stay inactive until their event occurs.
 | Source anchors are added, revised, reviewed, or used to mark a module boundary | `.mustflow/skills/source-anchor-authoring/SKILL.md` | Target files, anchor reason, nearby anchors, source-anchor policy, and validation surface | Source anchors and directly related workflow docs or comments | comment bloat, authority drift, false verification claims, or hidden module pressure | `mustflow_check`, `docs_validate_fast` | Anchor placement decision, field choices, module-boundary handoff, and verification |
 | Changed files need risk classification and verification selection | `.mustflow/skills/diff-risk-review/SKILL.md` | Changed-file list, diff summary, and task goal | Changed surfaces and verification report | under- or over-verification | `changes_status`, `changes_diff_summary`, `test`, `test_related`, `test_audit`, `lint`, `build`, `docs_validate`, `mustflow_check` | Risk level, verification choice, rollback notes |
 | CLI execution duration, build time, bundle size, test scheduling logic, process spawning, or CLI performance claims are planned, edited, or reported | `.mustflow/skills/performance-budget-check/SKILL.md` | Performance surface, budget source, measurement method, and baseline metrics | Budget checks, CLI duration, bundle weight, scheduling optimization notes, measurements, and tests | invented budgets, stale measurements, child-process bottlenecks, or unverified speed claims | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Performance surface, budget source, measurements, execution duration, bundle size, and remaining risks |
-| New feature, module, folder layout, architecture, scaffold, refactor, routing, data model, frontend/backend/database/infrastructure choice, database engine choice, managed database extension choice, auth identity ownership, public URL contract, data residency policy, runtime patchability, runtime portability, global-ready locale/country/currency/timezone/money model, server-side authorization boundary, file upload or storage strategy, API response contract, content-heavy product, semantic content blocks, filter URL policy, admin operation model, cache strategy, content lifecycle, asset strategy, claim or fact registry, content graph, source collection flow, user-state layer, core/application/delivery/infra boundary, framework-magic boundary, core versus auxiliary path boundary, operational versus analytics boundary, HTTP-to-worker boundary, job or outbox model, backup/restore assumption, vendor or platform exit path, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, observability identifier flow, deployment-state portability, CI/CD dashboard dependency, ecosystem or maintainer-risk placement, multi-server state boundary, vertical-to-horizontal scaling boundary, AI usage cost boundary, AI gateway hard-limit boundary, pricing-growth boundary, failure-isolation boundary, or external service integration may require hidden structure decisions before coding | `.mustflow/skills/structure-discovery-gate/SKILL.md` | User request, intended capability, hidden assumptions, named technologies or services, future content/API/rendering/data assumptions, database operating-shape assumptions, managed database feature assumptions, identity and provider-id assumptions, public URL assumptions, data location assumptions, runtime patch and portability assumptions, delivery/application/core/infra assumptions, global data assumptions, authorization assumptions, file-storage assumptions, source/provenance assumptions, lifecycle/asset/claim assumptions, user-state assumptions, admin/cache assumptions, core path and auxiliary path assumptions, async work assumptions, restore assumptions, vendor exit and replacement assumptions, external-service source-of-truth assumptions, search/queue/log/analytics reconstruction assumptions, operating-state reproduction assumptions, observability identifier assumptions, CI/CD reproducibility assumptions, dependency ecosystem and maintainer assumptions, pricing value/cost unit assumptions, failure-policy assumptions, AI gateway or cost assumptions, and relevant local patterns | Questions, assumptions, proposed file boundaries, and the smallest resulting implementation | brittle structure, vendor-name leakage, migration debt, lock-in debt, provider-id leakage, raw storage URL leakage, weak data location proof, unpatchable runtime, runtime-specific core logic, framework business-rule coupling, SaaS-only core state, weak search or queue reconstruction, weak global data model, weak server authorization, process-memory state leak, untracked AI cost, provider-budget-only AI protection, value/cost pricing mismatch, hidden dashboard deployment state, fragile single-maintainer core dependency, hidden operating state, broken traceability, file/storage drift, screen-shaped API coupling, core-path coupling, retry or worker coupling, unbounded failure radius, over-questioning, or speculative abstraction | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Blocking questions, assumptions, proposed files and responsibilities, upfront versus deferred structure decisions, borrowed service versus owned contract boundary, dependency direction, database, identity, public URL, data residency, runtime patchability and portability, global data, authorization, file-storage, API, vendor exit, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, CI/CD reproducibility, dependency risk, observability identity flow, pricing value/cost boundary, AI gateway boundary, core/application/delivery/infra boundaries, core and auxiliary boundaries, async work boundary, local pattern, verification, and remaining structure risk |
+| New feature, ambiguous or complex design request, pre-implementation design gate, module, folder layout, architecture, scaffold, refactor, routing, data model, frontend/backend/database/infrastructure choice, database engine choice, managed database extension choice, auth identity ownership, public URL contract, data residency policy, runtime patchability, runtime portability, global-ready locale/country/currency/timezone/money model, server-side authorization boundary, file upload or storage strategy, API response contract, content-heavy product, semantic content blocks, filter URL policy, admin operation model, cache strategy, content lifecycle, asset strategy, claim or fact registry, content graph, source collection flow, user-state layer, core/application/delivery/infra boundary, framework-magic boundary, core versus auxiliary path boundary, operational versus analytics boundary, HTTP-to-worker boundary, job or outbox model, backup/restore assumption, vendor or platform exit path, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, observability identifier flow, deployment-state portability, CI/CD dashboard dependency, ecosystem or maintainer-risk placement, multi-server state boundary, vertical-to-horizontal scaling boundary, AI usage cost boundary, AI gateway hard-limit boundary, pricing-growth boundary, failure-isolation boundary, or external service integration may require hidden structure decisions before coding | `.mustflow/skills/structure-discovery-gate/SKILL.md` | User request, intended capability, design gate classification, restated requirement, success criteria, non-goals, compatibility boundaries, hidden assumptions, named technologies or services, future content/API/rendering/data assumptions, database operating-shape assumptions, managed database feature assumptions, identity and provider-id assumptions, public URL assumptions, data location assumptions, runtime patch and portability assumptions, delivery/application/core/infra assumptions, global data assumptions, authorization assumptions, file-storage assumptions, source/provenance assumptions, lifecycle/asset/claim assumptions, user-state assumptions, admin/cache assumptions, core path and auxiliary path assumptions, async work assumptions, restore assumptions, vendor exit and replacement assumptions, external-service source-of-truth assumptions, search/queue/log/analytics reconstruction assumptions, operating-state reproduction assumptions, observability identifier assumptions, CI/CD reproducibility assumptions, dependency ecosystem and maintainer assumptions, pricing value/cost unit assumptions, failure-policy assumptions, AI gateway or cost assumptions, and relevant local patterns | Questions, assumptions, proposed file boundaries, and the smallest resulting implementation | brittle structure, vendor-name leakage, migration debt, lock-in debt, provider-id leakage, raw storage URL leakage, weak data location proof, unpatchable runtime, runtime-specific core logic, framework business-rule coupling, SaaS-only core state, weak search or queue reconstruction, weak global data model, weak server authorization, process-memory state leak, untracked AI cost, provider-budget-only AI protection, value/cost pricing mismatch, hidden dashboard deployment state, fragile single-maintainer core dependency, hidden operating state, broken traceability, file/storage drift, screen-shaped API coupling, core-path coupling, retry or worker coupling, unbounded failure radius, over-questioning, or speculative abstraction | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Design gate classification, restated requirement, success criteria, blocking questions, recommended defaults, assumptions, proposed files and responsibilities, upfront versus deferred structure decisions, borrowed service versus owned contract boundary, dependency direction, database, identity, public URL, data residency, runtime patchability and portability, global data, authorization, file-storage, API, vendor exit, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, CI/CD reproducibility, dependency risk, observability identity flow, pricing value/cost boundary, AI gateway boundary, core/application/delivery/infra boundaries, core and auxiliary boundaries, async work boundary, local pattern, verification, and remaining structure risk |
 
 ### Tests and Regression
 
@@ -154,9 +155,9 @@ routes. Event routes stay inactive until their event occurs.
 | Generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, or migration-sensitive snippets introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, or scaffold commands that may be stale | `.mustflow/skills/version-freshness-check/SKILL.md` | Versioned reference, owning files, repository version policy, approved freshness source, compatibility context, migration risk, and command contract entries | Package metadata, lockfiles, CI workflows, Dockerfiles, runtime files, framework config, docs, examples, templates, tests, and version-decision reports | stale default version, false latest claim, accidental major migration, repository policy mismatch, unsupported generated example, floating-tag drift, or unverified security/support claim | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Versioned surfaces checked, repository policy and freshness source, selected version track, compatibility classification, approval need, synchronized surfaces, verification, and remaining version-freshness risk |
 | External systems, protocols, SDKs, databases, webhooks, queues, files, object storage, signed upload or download URLs, caches, API response models, framework requests or responses, server actions, route handlers, edge functions, worker handlers, AI models, browser storage, search engines, analytics tools, email platforms, no-code tools, observability backends, trace or request context, or provider data cross the core boundary or need port/adapter translation, error mapping, timeout, retry, circuit-breaker, bulkhead, idempotency, reconciliation, security, core-state ownership, vendor portability, or observability handling | `.mustflow/skills/adapter-boundary/SKILL.md` | External system or protocol, inbound/outbound direction, delivery boundary, internal use case, local port/adapter patterns, provider risk, provider failure policy, core-state ownership risk, vendor portability risk, observability identifier policy, API contract risk, changed files, and command contract entries | Ports, adapters, mappers, controllers, workers, stores, gateways, response mappers, telemetry mappers, timeout and retry policies, circuit breakers, bulkhead boundaries, tests, fixtures, assembly wiring, and directly synchronized docs or templates | provider leakage, framework business-rule leakage, telemetry backend leakage, storage-key leakage, screen-shaped API coupling, pass-through wrapper, SaaS dashboard as truth source, search or analytics policy leakage, queue contract leakage, unclassified external failure, duplicate side effect, unsafe retry, missing timeout, missing circuit breaker, missing bulkhead, unresolved unknown provider outcome, broken identifier propagation, secret or personal-data leak, or untested integration drift | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Boundary classification, delivery adapter responsibility, internal port, provider containment, core-state ownership, vendor portability, validation and mapping, API response mapping, observability identifier flow, timeout/retry/circuit-breaker/bulkhead/idempotency handling, reconciliation behavior, security notes, verification, and remaining provider risk |
 | Tauri frontend invokes, Rust commands, capabilities, permissions, scopes, plugins, filesystem, dialog, shell, opener, updater, sidecar, or mobile native permissions are created or changed | `.mustflow/skills/tauri-code-change/SKILL.md` | Frontend call sites, Tauri config, Rust commands, capability and permission files, plugin config, changed files, and command contract entries | Tauri frontend, Rust commands, capabilities, permissions, scopes, plugins, tests, and docs | broad native permission, untrusted IPC input, filesystem escape, shell or updater risk, or WebView/native boundary drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | IPC, permission, scope, filesystem, shell, updater, and native boundary checked, verification, and remaining Tauri risk |
-| File path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported | `.mustflow/skills/file-path-cross-platform-change/SKILL.md` | Path ledger, trust classes, accepted path representation, base root, path helpers, safe filesystem wrappers, temp/cache helpers, lock policy, archive policy, upload/download policy, scanner policy, CLI/API/schema/snapshot/generated/package surfaces, platform expectations, and command contract entries | Path validators, helpers, wrappers, schemas, CLI/API parsing, snapshots, fixtures, docs, tests, generated-output paths, package artifact paths, archive extraction, scanner bounds, temp/cache handling, locks, and cleanup code | path traversal, base containment bypass, drive-relative path bug, reserved-name bug, case-collision bug, symlink or junction escape, unsafe archive extraction, non-atomic write claim, stale lock, scanner loop, cleanup data loss, path contract drift, or package artifact path drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Path contract, path ledger, trust classes, root policy, Windows/macOS/Linux/archive/upload/download/scanner/lock/temp/cache/atomic/cleanup decisions, synchronized contract surfaces, verification, and remaining path risk |
-| File paths, directories, symlinks, real paths, traversal, atomic writes, file copies, generated outputs, temporary files, cleanup, or Windows/POSIX filesystem behavior are created, changed, reviewed, or reported | `.mustflow/skills/cross-platform-filesystem-safety/SKILL.md` | Path inputs, base directory, trust boundary, symlink policy, write or cleanup strategy, platform expectations, and command contract entries | Path validation, file helpers, copy/update/delete code, scan bounds, fixtures, tests, docs, and templates | path traversal, symlink escape, unsafe overwrite, platform-only behavior, stale output, or cleanup data loss | `changes_status`, `changes_diff_summary`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Path trust classes, root boundary, symlink/write/delete/scan decisions, platform assumptions, verification, and remaining filesystem risk |
-| Child processes, shell or argv execution, built-in command reruns, timeouts, process trees, output limits, streaming, environment policy, command eligibility, or execution receipts are created, changed, reviewed, or reported | `.mustflow/skills/process-execution-safety/SKILL.md` | Execution path, timeout, output limit, stdin, environment, cwd, process tree behavior, receipt and write-tracking expectations, and command contract entries | Process execution code, process-tree helpers, output buffers, environment creation, eligibility checks, receipts, tests, and docs | runaway process, unbounded output, leaked environment, inconsistent JSON/text execution, false cleanup claim, or unreliable receipt | `changes_status`, `changes_diff_summary`, `test_related`, `test_release`, `mustflow_check` | Execution surface, timeout/output/environment/process-tree boundaries, receipt consistency, tests, verification, and remaining process risk |
+| File path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, clone or checkout destinations, scaffold roots, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported | `.mustflow/skills/file-path-cross-platform-change/SKILL.md` | Path ledger, trust classes, accepted path representation, base root, path helpers, safe filesystem wrappers, clone/checkout/scaffold/install/extract outputs, staging and promotion policy, temp/cache helpers, lock policy, archive policy, upload/download policy, scanner policy, CLI/API/schema/snapshot/generated/package surfaces, platform expectations, failure taxonomy, and command contract entries | Path validators, helpers, wrappers, schemas, CLI/API parsing, snapshots, fixtures, docs, tests, generated-output paths, package artifact paths, clone or scaffold destinations, archive extraction, scanner bounds, temp/cache handling, locks, and cleanup code | path traversal, base containment bypass, drive-relative path bug, reserved-name bug, case-collision bug, Unicode-collision bug, Git checkout path-length failure misreported as network or auth, unsafe archive extraction, non-atomic write claim, stale lock, scanner loop, partial-output cleanup data loss, user-selected destination deletion, path contract drift, or package artifact path drift | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Path contract, path ledger, trust classes, root policy, preflight/staging/promotion decisions, Windows/macOS/Linux/archive/upload/download/scanner/lock/temp/cache/atomic/cleanup decisions, failure taxonomy, synchronized contract surfaces, verification, and remaining path risk |
+| File paths, directories, symlinks, real paths, traversal, atomic writes, file copies, generated outputs, temporary files, clone or checkout materialization, cleanup, or Windows/POSIX filesystem behavior are created, changed, reviewed, or reported | `.mustflow/skills/cross-platform-filesystem-safety/SKILL.md` | Path inputs, base directory, trust boundary, symlink policy, write or cleanup strategy, clone/checkout/scaffold/install/extract path budget, app-owned staging boundary, platform expectations, failure taxonomy, and command contract entries | Path validation, file helpers, copy/update/delete code, clone/scaffold/archive cleanup code, scan bounds, fixtures, tests, docs, and templates | path traversal, symlink escape, unsafe overwrite, platform-only behavior, stale output, path-length or filename-length misclassification, watcher/resource misclassification, or cleanup data loss | `changes_status`, `changes_diff_summary`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Path trust classes, root boundary, symlink/write/delete/scan decisions, preflight and staging boundaries, clone/scaffold/extract classification, platform assumptions, verification, and remaining filesystem risk |
+| Child processes, shell or argv execution, built-in command reruns, Git/package-manager/scaffolder failures, timeouts, process trees, output limits, streaming, environment policy, command eligibility, failure classification, command-line length limits, or execution receipts are created, changed, reviewed, or reported | `.mustflow/skills/process-execution-safety/SKILL.md` | Execution path, timeout, output limit, stdin, argv and shell command-length budget, environment, cwd, process tree behavior, failure taxonomy, receipt and write-tracking expectations, and command contract entries | Process execution code, process-tree helpers, output buffers, environment creation, eligibility checks, failure classifiers, receipts, tests, and docs | runaway process, unbounded output, leaked environment, argv-too-long failure, shell-command-too-long failure, inconsistent JSON/text execution, false cleanup claim, Git checkout path failure misreported as network or auth, blind retry, diagnostic loss, or unreliable receipt | `changes_status`, `changes_diff_summary`, `test_related`, `test_release`, `mustflow_check` | Execution surface, timeout/output/environment/process-tree boundaries, argv and shell length handling, failure classification, diagnostic preservation, receipt consistency, tests, verification, and remaining process risk |
 | Core or application logic creates, imports, resolves, or hides external dependencies such as databases, SDKs, clocks, random generators, configuration, loggers, framework objects, filesystems, queues, AI clients, or payment/email providers | `.mustflow/skills/dependency-injection/SKILL.md` | Target code area, hidden dependency, intended business capability, layer ownership, local port/adapter patterns, changed files, and command contract entries | Core logic signatures, ports, adapters, assembly roots, tests, and directly synchronized docs or templates | hidden global state, untestable business logic, provider leakage, lifecycle drift, or service-locator coupling | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Dependency boundary, direct dependencies found, injection style, ports/adapters, assembly boundary, tests or fakes, verification, and remaining dependency leakage |
 | Code, data, schema, configuration, file layout, template, content frontmatter, file-to-database, URL, slug, lifecycle, asset, claim or fact extraction, API projection compatibility, public identifier changes, provider id mappings, event-schema changes, observability identifier continuity, deployment-state reproduction, generated-state, backup or restore proof, semantic export, import, platform exit, or cache migrations are planned, edited, documented, or reported | `.mustflow/skills/migration-safety-check/SKILL.md` | Source state, target state, migration surface owner, identity, lifecycle, asset, claim, export/import reconstruction shape, URL continuity, API projection expectations, public id mapping, provider id mapping, event schema versioning, observability identifier continuity, deployment-state reproduction, cache key versioning, restore evidence, idempotency, rollback, dry-run, compatibility, and command contract entries | Migration plans, compatibility notes, lock metadata, docs, tests, templates, generated state, redirects, assets, exports, imports, deployment notes, observability continuity notes, caches, restore notes, and reports | irreversible migration, data loss, incomplete export, broken links, identity drift, provider-id lock-in, lost asset originals, API contract break, event-schema ambiguity, broken traceability, dashboard-only operating state, cache-key drift, untested restore, or false migration-success claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Migration surface, source and target state, identity, lifecycle, asset, claim, URL, API, event, observability, deployment-state, cache, restore, and export/import continuity, idempotency, rollback, metadata updates, verification, and remaining migration risk |
 
@@ -204,7 +205,7 @@ routes. Event routes stay inactive until their event occurs.
 | `.mustflow/config/commands.toml` command intents, resources, effects, timeouts, output limits, environment policies, lifecycle values, run policies, command-selection metadata, CI/CD reproducibility rules, build/test/migration/deploy verification handoffs, or health-check command surfaces are created, changed, reviewed, or removed | `.mustflow/skills/command-contract-authoring/SKILL.md` | Command goal, current command contract, expected reads and writes, side effects, locks, timeout, output, environment, stdin, dashboard or platform setting dependency, and verification entries | Command contract, template command contracts, workflow docs, skills, tests, and directly synchronized public docs | accidental command authority, inferred command, dashboard-only source of truth, unreproducible deployment, unbounded side effect, missing lock, secret exposure, or long-running command approval | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Intent authority decision, side-effect model, environment and timeout boundary, CI/CD reproducibility boundary, synchronized surfaces, verification, and remaining command-contract risk |
 | CLI text output, JSON output, exit codes, error messages, warnings, deprecations, help text, command aliases, schema-backed reports, or automation-facing command behavior are created, changed, reviewed, or reported | `.mustflow/skills/cli-output-contract-review/SKILL.md` | Affected command, output modes, exit-code expectations, docs examples, schemas, fixtures, consumers, and command contract entries | CLI output code, schemas, fixtures, docs, README examples, package tests, templates, and reports | broken automation, misleading success, schema drift, undocumented deprecation, stale example, or incompatible output change | `changes_status`, `changes_diff_summary`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Output surfaces reviewed, status and exit-code semantics, synchronized schemas/docs/tests/templates, verification, and remaining CLI-output risk |
 | Dates, versions, counts, durations, limits, metrics, benchmarks, prices, percentages, or other numeric facts are created, edited, or reported | `.mustflow/skills/date-number-audit/SKILL.md` | Date or numeric fact, source of truth, dependent surfaces, precision expectation, and command contract entries | Numeric statements, metadata, tests, docs, templates, and reports | invented, stale, or mismatched numeric claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Audited values, source of truth, synchronized surfaces, skipped checks, and remaining numeric risk |
-| Git reports CRLF/LF warnings or tracked text files may need line-ending normalization | `.mustflow/skills/line-ending-hygiene/SKILL.md` | Warning text or changed-file evidence, line-ending policy, changed-file status, and command contract entries | Line-ending policy files, tracked text files, command metadata, tests, and reports | silent working-tree rewrite or policy drift | `line_endings_check`, `changes_status`, `mustflow_check` | Policy found, drift files, normalization status, verification, and remaining line-ending risk |
+| Git reports CRLF/LF warnings, Docker or shell scripts fail with CRLF interpreter errors, `.gitattributes` policy is proposed, or tracked text files may need line-ending normalization | `.mustflow/skills/line-ending-hygiene/SKILL.md` | Warning or runtime error text, changed-file evidence, line-ending policy, requested scope, changed-file status, and command contract entries | Line-ending policy files when explicitly requested, tracked text files when explicitly normalized, command metadata, tests, and reports | silent working-tree rewrite, hidden repository-wide policy change, unrelated renormalization, or policy drift | `line_endings_check`, `changes_status`, `mustflow_check` | Policy found or deferred, drift files, normalization status, verification, and remaining line-ending risk |
 | External `SKILL.md` files, skill packs, awesome lists, GitHub skill repositories, installer recommendations, or third-party skill procedures are reviewed for possible mustflow adoption | `.mustflow/skills/external-skill-intake/SKILL.md` | Source path or URL, license or provenance evidence, external skill files, intended adoption outcome, existing skill overlap, and command contract entries | Skill procedures, skill routes, template metadata, tests, docs, and review notes that adapt the external idea | third-party command bypass, license or provenance gap, unsafe helper script, duplicated skill, stale source claim, or default-profile bloat | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Source review, overlap decision, safety findings, command-intent mapping, adoption decision, synchronized surfaces, verification, and remaining intake risk |
 | Repository, host, user, nested-project, command-contract, preference, or generated instruction sources conflict or make safe scope unclear | `.mustflow/skills/instruction-conflict-scope-check/SKILL.md` | Conflicting instruction sources, affected scope, direct user request, command contract entries, and nearest instruction files | Workflow docs, skills, templates, tests, reports, and selected repository scope | authority drift, unsafe scope expansion, wrong repository edit, or unauthorized command | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Conflicts reviewed, chosen priority rule, narrowed or skipped actions, clarification changes, and remaining authority risk |
 | `.mustflow/context/PROJECT.md` needs cautious project context | `.mustflow/skills/project-context-authoring/SKILL.md` | Supported project facts | `.mustflow/context/PROJECT.md` | authority drift | `mustflow_check` | Updated cautious context |

package/templates/default/locales/en/.mustflow/skills/clarifying-question-gate/SKILL.md

@@ -0,0 +1,183 @@
+---
+mustflow_doc: skill.clarifying-question-gate
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: clarifying-question-gate
+description: Apply this skill when a coding task has missing intent, scope, domain, data, security, UX, dependency, architecture, or verification decisions that cannot be safely inferred from current repository evidence.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.clarifying-question-gate
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - mustflow_check
+---
+
+# Clarifying Question Gate
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Ask only the questions that protect the work from expensive wrong assumptions.
+
+Good agent work is not maximally autonomous and not maximally interrogative. It moves forward on
+cheap, reversible, repository-evident decisions, and stops before choices that are costly to undo or
+whose correct answer belongs to the user, product owner, security owner, or operations owner.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The user asks for implementation, debugging, refactoring, UI, data, API, release, or workflow work
+  but the success criteria are not observable from the request or repository evidence.
+- The task may affect existing users, existing data, migrations, deletion, retention, auth,
+  authorization, billing, entitlements, files, secrets, external APIs, public CLI/API output,
+  user-visible UX policy, package dependencies, architecture, performance tradeoffs, or verification
+  expectations.
+- The task uses ambiguous domain words such as user, account, team, workspace, project, active,
+  complete, canceled, subscription, admin, owner, archived, deleted, invite, or verified.
+- Several implementation scopes are plausible and differ in cost, compatibility, risk, or future
+  maintenance burden.
+- You are about to add a new dependency, service, folder boundary, storage model, framework pattern,
+  persistent state, or broad refactor that the current files do not already require.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The answer is available by reading current files, tests, docs, config, or local patterns.
+- The change is small, local, reversible, and covered by an existing pattern or focused test.
+- The task is analysis-only and does not need an implementation decision.
+- A more specific skill already requires a blocking question for the same risk and covers the whole
+  decision, such as `structure-discovery-gate`, `auth-permission-change`, `database-migration-change`,
+  `dependency-upgrade-review`, or `release-publish-change`.
+- Asking would only delegate ordinary engineering responsibility, such as "should I add tests?",
+  "should I handle errors?", "what stack is this?", or "what style should I use?" when the repository
+  already answers it.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User request and any stated success criteria, constraints, examples, deadlines, or non-goals.
+- Relevant repository evidence: current files, tests, schemas, command contracts, docs, context,
+  nearby code patterns, and existing verification options.
+- Candidate decisions that are still ambiguous after reading local evidence.
+- Reversibility classification for each decision: cheap/reversible, moderate, or expensive/hard to
+  roll back.
+- A recommended option for each blocking question, with the tradeoff of at least one alternative.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Repository evidence has been inspected before asking. Do not ask the user to answer facts that the
+  codebase can answer.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current
+  scope.
+- Questions are limited to decisions that block safe implementation, not curiosity, preference
+  collection, or broad product discovery.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- No edits are required when the skill only gates a blocking decision.
+- When proceeding under a safe assumption, keep the implementation small enough that a wrong
+  assumption can be corrected locally.
+- Do not add dependencies, migrations, persistent data changes, permission policy, deletion behavior,
+  public contract changes, or broad refactors while a blocking question remains unanswered.
+- Do not create speculative specs, roadmaps, or documentation unless the user requested that artifact
+  or another selected skill authorizes that scope.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read enough local evidence to avoid lazy questions:
+   - current feature code, nearby tests, schemas, docs, command contracts, and context files when
+     relevant;
+   - existing UI, API, data, auth, dependency, and verification patterns before proposing a new one.
+2. Identify the decisions still unresolved after that evidence.
+3. Classify each unresolved decision:
+   - `repository_answerable`: inspect more local evidence instead of asking;
+   - `safe_assumption`: choose the smallest reversible option and state the assumption before or while
+     working;
+   - `blocking_question`: stop before implementation because the wrong choice would be expensive,
+     user-visible, security-sensitive, data-affecting, dependency-affecting, or hard to roll back.
+4. Ask about observable completion before feature shape when success is unclear:
+   - what behavior proves the task is done;
+   - which user path, command, test, screenshot, migration state, or registry/release state closes it.
+5. Ask about scope only when plausible scopes have different cost or risk:
+   - minimal symptom fix, root-cause fix, or broader cleanup;
+   - prototype, maintainable production path, or release-ready path.
+6. Ask about existing users and data before changing persistence, lifecycle, deletion, migration,
+   retention, cache, API compatibility, or old-client behavior.
+7. Ask about failure UX before implementing user-visible success flows where failure handling is a
+   product decision: retry, queue, message, audit/log-only, rollback, partial success, or manual
+   recovery.
+8. Ask about security and authorization before relying on UI hiding, client-side checks, roles,
+   invites, team boundaries, file access, billing state, or admin features.
+9. Ask before adding or swapping dependencies, services, queues, databases, auth providers, design
+   systems, state managers, or major folder boundaries.
+10. Ask about verification when there is no declared command intent or when the user expects a
+    specific proof beyond the repository's configured checks.
+11. Keep the question set short:
+    - ask at most three questions at once;
+    - each question must name the decision, the recommended choice, the consequence of that choice,
+      and one meaningful alternative;
+    - avoid open-ended prompts like "how should I implement this?" unless no responsible options can
+      be framed from repository evidence.
+12. If no blocking question remains, proceed without ceremony. State only the assumptions that matter
+    to review or rollback.
+13. If a blocking question remains unanswered, do not implement around it. Offer the smallest safe
+    non-blocked action, such as read-only analysis, a plan, a reproduction, or a narrow preparatory
+    refactor when another selected skill supports it.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Questions are grounded in inspected repository evidence.
+- The agent has not asked for facts it could read locally.
+- Expensive, user-owned, security-sensitive, data-affecting, dependency-affecting, and public-contract
+  decisions are resolved before implementation.
+- Safe assumptions are narrow, reversible, and reported.
+- The final work can be judged against observable success criteria or a reported verification gap.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `mustflow_check`
+
+This skill often runs before edits and may need no command execution by itself. After implementation,
+run the specific configured verification intents required by the selected implementation skills.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the user rejects a question as unnecessary, reclassify the decision as a safe assumption only
+  when current evidence supports a narrow reversible path; otherwise report the unresolved risk.
+- If new evidence shows the question was answered by current files, continue without asking and note
+  the evidence if it affects the final report.
+- If a blocking question reveals a larger feature, switch to the relevant skill before editing that
+  new scope.
+- If the task becomes over-scoped, reduce the next action to the smallest safe slice with explicit
+  acceptance evidence.
+- If verification intent is missing, report the missing command contract instead of inventing a raw
+  command.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Repository evidence inspected
+- Blocking questions asked, with recommendation and tradeoff
+- Safe assumptions made
+- Decisions intentionally deferred
+- Implementation scope selected
+- Command intents run
+- Skipped checks and reasons
+- Remaining ambiguity or rollback risk

package/templates/default/locales/en/.mustflow/skills/cross-platform-filesystem-safety/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.cross-platform-filesystem-safety
 locale: en
 canonical: true
-revision: 3
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: cross-platform-filesystem-safety
-description: Apply this skill when file paths, directories, symlinks, reparse points, real paths, path traversal, reserved names, null bytes, atomic file writes, temporary files, file copies, generated outputs, Windows/POSIX path behavior, line endings, file permissions, durable writes, or filesystem cleanup are created, changed, reviewed, or reported.
+description: Apply this skill when file paths, directories, symlinks, reparse points, real paths, path traversal, reserved names, null bytes, atomic file writes, temporary files, file copies, generated outputs, clone or checkout materialization, Windows/POSIX path behavior, line endings, file permissions, durable writes, failure classification, or filesystem cleanup are created, changed, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -33,6 +33,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 
 - Code creates, reads, writes, deletes, copies, moves, normalizes, scans, watches, or reports files or directories.
 - A change handles user-provided paths, repository-relative paths, real paths, symlinks, Windows reparse points or junctions, temporary files, generated output, backups, manifests, locks, caches, or latest pointers.
+- Code materializes large or externally sourced trees such as Git checkouts, cloned repositories, project scaffolds, dependency trees, archive extractions, template installs, generated snapshots, or package artifacts.
 - Behavior must work on Windows and POSIX path separators, drive roots, case differences, reserved names, maximum path lengths, executable extensions, line endings, permissions, or rename semantics.
 - A test or final report claims a path is inside the project, symlink-safe, traversal-safe, race-safe, atomic, idempotent, cleanup-safe, or cross-platform.
 
@@ -49,6 +50,8 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 - Affected path inputs, output paths, base directory, trust boundary, and whether each path is user-controlled, template-controlled, generated, or repository-owned.
 - Current filesystem helpers, path validation rules, symlink policy, case-sensitivity policy, write strategy, cleanup strategy, temporary-file strategy, permission strategy, and platform expectations.
 - Expected behavior for missing paths, existing files, directories, symlinks, dangling symlinks, reparse points or junctions, path traversal, null bytes, Windows namespace prefixes, Windows reserved names, alternate data streams, trailing spaces or dots, collisions, long paths, large files, and permissions errors.
+- Path-length, filename-length, collision, staging, promotion, and cleanup expectations for clone, checkout, scaffold, install, archive, and generated-tree flows, including the deepest known entry path when available.
+- Failure classification expectations for filesystem and platform errors such as Windows path length, POSIX `ENAMETOOLONG`, reserved names, case collisions, Unicode aliases, file locks, permissions, quota, cross-device moves, missing executable bits, line endings, watcher limits, and descriptor limits.
 - Whether atomicity requires best-effort rename, same-directory temporary files on the same volume, file fsync, parent directory fsync, Windows replacement behavior, or reader-safe latest pointers.
 - Relevant command-intent entries for tests, docs, release, and mustflow validation.
 
@@ -69,6 +72,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 - Do not accept null bytes, Windows device names, namespace bypass prefixes, alternate data streams, or platform-invalid path segments as ordinary filenames.
 - Do not recursively delete, overwrite, or copy broad directories unless the target is resolved, bounded, and intentionally owned by the task.
 - Do not claim operating-system mitigations such as Windows RedirectionGuard unless the application actually enables and verifies the mitigation in the relevant process boundary.
+- Do not change system-wide or user-wide settings such as Windows registry long-path flags, global Git config, Developer Mode, WSL mount metadata, Linux sysctl limits, Docker Desktop storage backends, antivirus exclusions, or shell profile files from this skill. Report the missing prerequisite or require an explicit configured setup command.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
@@ -77,26 +81,37 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 2. Reject impossible or dangerous path text early. Check null bytes, empty segments, absolute paths where relative paths are required, Windows device names such as `CON` or `NUL`, namespace prefixes such as `\\?\`, alternate data streams using colon segments, trailing dots or spaces when Windows compatibility matters, and platform-invalid characters before writing.
 3. Establish the base boundary. Use normalized repository-relative paths for storage and real-path checks for filesystem safety when symlinks may be present.
 4. Use Unicode normalization for validation only when detecting platform aliases such as superscript Windows device-name variants. Do not rewrite or persist normalized filenames unless the repository policy explicitly says so.
-5. Check containment with path-aware logic. Prefer relative-path or resolved-path containment helpers over raw string prefixes, and include a path-separator boundary so partial path traversal cannot let sibling names masquerade as children.
-6. Check case behavior explicitly. Windows and many macOS volumes preserve case but compare case-insensitively by default; POSIX commonly compares case-sensitively. State whether the code preserves spelling, rejects conflicting names, or relies on the host filesystem.
-7. Check symlink, reparse point, and junction behavior explicitly. Decide whether they are rejected, followed only within the root, or treated as ordinary path entries. Test dangling, outside-target, loop, and junction-like cases when relevant.
-8. Close time-of-check to time-of-use gaps where practical. Prefer opening or writing through safe helpers that reject symlinks at the final operation, then verify the opened target when the platform and helper support it.
-9. Treat high-level path APIs as incomplete defenses when the runtime cannot expose descriptor-relative open, no-follow, or opened-file verification. Do not claim race-free behavior from resolve-then-open code alone.
-10. Check traversal and root handling across platforms. Account for absolute paths, drive letters, UNC-like paths, mixed separators, empty paths, dot segments, reserved names, long paths, and case sensitivity where relevant.
-11. For writes, prefer same-directory temporary-file then rename or replace behavior when readers may observe the file. Keep the temporary file on the same volume, use unpredictable names, least-privilege creation permissions, and safe no-follow writes when the project already has that helper.
-12. Treat atomic writes as platform-specific. POSIX rename semantics, Windows replacement behavior, cross-filesystem moves, network filesystems, fsync availability, and directory fsync support differ; report best-effort guarantees honestly.
-13. When durable writes matter, include the full durability sequence where the platform supports it: write the temporary file, flush the file data, close it, rename or replace it, then flush the parent directory entry. If parent directory fsync is unavailable, downgrade the durability claim.
-14. For copies and updates, close the check-then-write gap as much as the platform and existing helpers allow. Do not report symlink safety if the final write can still follow a changed symlink.
-15. For privileged Windows services, check whether reparse-point traversal mitigations belong at process startup. If the code cannot enable or verify them, report the remaining junction risk instead of claiming system-level protection.
-16. For deletes and cleanup, verify the resolved absolute target is inside the intended generated or temporary directory and narrow the deletion scope.
-17. For scans, bound recursion, generated/vendor exclusions, file size, symlink traversal, reparse-point traversal, loop detection, and maximum path length or depth where relevant.
-18. Keep path output stable for users and automation. Report repository-relative paths unless an absolute path is necessary for local diagnosis.
-19. Add focused tests for the highest-risk path shapes instead of broad platform speculation.
+5. For externally sourced trees, use a `preflight -> dangerous operation -> classifier -> safe cleanup` pipeline. Estimate the materialized path budget before writing, including destination root, project directory, generated subdirectories, deepest known repository or archive entry, Windows path-length behavior, POSIX path and component limits, byte limits, case collisions, reserved names, and safety headroom.
+6. For Git clone and checkout materialization, prefer an app-owned staging directory and no-checkout or metadata-first flow when feasible. Inspect repository entries before checkout, check them against the final destination, then promote the result only after success. Do not delete a user-selected final destination when checkout fails.
+7. For Windows Git checkout or clone materialization, prefer a per-invocation `core.longpaths=true` setting when product code invokes Git. Do not mutate global Git config from application code unless the user explicitly chose that setup action. Long-path support still depends on operating-system, Git, filesystem, and downstream tool behavior, so checkout failures must remain classifiable.
+8. For symlink-heavy repositories on Windows, detect whether checkout produced real links or plain-text symlink stubs before running build logic. Report missing Developer Mode, `core.symlinks`, or native symlink support as an environment prerequisite; do not silently replace file symlinks with junctions or copies unless the repository contract explicitly supports that compatibility mode.
+9. For POSIX, do not assume that forward slashes make paths safe. Check `ENAMETOOLONG`, byte-based per-component name limits, mount permissions, executable bits, case-sensitive import paths, symlink loops, file descriptor limits, watcher limits, quota, and cross-device rename behavior.
+10. Check containment with path-aware logic. Prefer relative-path or resolved-path containment helpers over raw string prefixes, and include a path-separator boundary so partial path traversal cannot let sibling names masquerade as children.
+11. Check case behavior explicitly. Windows and many macOS volumes preserve case but compare case-insensitively by default; POSIX commonly compares case-sensitively. State whether the code preserves spelling, rejects conflicting names, or relies on the host filesystem.
+12. Check collisions before materializing Git trees, archives, generated files, uploaded names, or dependency trees. Include case-only collisions, Unicode normalization aliases, reserved Windows names with extensions, trailing dot or space aliases, duplicate archive entries, and byte-limit collisions from multibyte names.
+13. Check symlink, reparse point, and junction behavior explicitly. Decide whether they are rejected, followed only within the root, or treated as ordinary path entries. Test dangling, outside-target, loop, text-stub, and junction-like cases when relevant.
+14. Close time-of-check to time-of-use gaps where practical. Prefer opening or writing through safe helpers that reject symlinks at the final operation, then verify the opened target when the platform and helper support it.
+15. Treat high-level path APIs as incomplete defenses when the runtime cannot expose descriptor-relative open, no-follow, or opened-file verification. Do not claim race-free behavior from resolve-then-open code alone.
+16. Check traversal and root handling across platforms. Account for absolute paths, drive letters, UNC-like paths, mixed separators, empty paths, dot segments, reserved names, long paths, and case sensitivity where relevant.
+17. Classify filesystem failures before generic network, auth, or unknown failures. Use stable categories such as `path_too_long`, `filename_too_long`, `byte_limit_exceeded`, `invalid_path`, `reserved_name`, `case_collision`, `unicode_collision`, `symlink_escape`, `permission_denied`, `file_locked`, `cross_device_move`, `disk_full_or_quota`, `executable_bit_missing`, `line_ending_mismatch`, `watcher_limit`, and `descriptor_limit`.
+18. For writes, prefer same-directory temporary-file then rename or replace behavior when readers may observe the file. Keep the temporary file on the same volume, use unpredictable names, least-privilege creation permissions, and safe no-follow writes when the project already has that helper.
+19. Treat atomic writes as platform-specific. POSIX rename semantics, Windows replacement behavior, cross-filesystem moves, network filesystems, fsync availability, and directory fsync support differ; report best-effort guarantees honestly.
+20. When durable writes matter, include the full durability sequence where the platform supports it: write the temporary file, flush the file data, close it, rename or replace it, then flush the parent directory entry. If parent directory fsync is unavailable, downgrade the durability claim.
+21. For copies and updates, close the check-then-write gap as much as the platform and existing helpers allow. Do not report symlink safety if the final write can still follow a changed symlink.
+22. For privileged Windows services, check whether reparse-point traversal mitigations belong at process startup. If the code cannot enable or verify them, report the remaining junction risk instead of claiming system-level protection.
+23. For host environment limitations such as long-path registry flags, Developer Mode, WSL metadata mounts, Linux inotify/sysctl limits, Docker Desktop volume backend, or antivirus locks, classify and report the environment prerequisite. Do not perform privileged host repair from ordinary file logic.
+24. Distinguish disk and quota errors from watch or descriptor exhaustion. In a watcher or scanner path, `ENOSPC` may mean an inotify watch limit rather than a full disk, and `EMFILE` or similar failures may indicate a per-process or per-user file-descriptor limit.
+25. For deletes and cleanup, verify the resolved absolute target is inside the intended generated or temporary directory and narrow the deletion scope. Preserve bounded diagnostic evidence before deleting partial clone, checkout, scaffold, install, extraction, or generated output. Cleanup may remove only app-owned staging or generated-state paths, never the user-selected destination that the operation was supposed to populate.
+26. For scans, bound recursion, generated/vendor exclusions, file size, symlink traversal, reparse-point traversal, loop detection, and maximum path length or depth where relevant.
+27. Keep path output stable for users and automation. Report repository-relative paths unless an absolute path is necessary for local diagnosis.
+28. Add focused tests for the highest-risk path shapes and failure categories instead of broad platform speculation.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Path boundaries, invalid-name policy, case policy, symlink and reparse-point policy, write strategy, cleanup strategy, durability expectations, and platform assumptions are explicit.
+- Clone, checkout, scaffold, install, extraction, and generated-tree flows have preflight, staging, promotion, path-length, byte-limit, symlink-stub, collision, diagnostic-preservation, cleanup, and failure-taxonomy policies.
+- Host setting prerequisites are reported without unapproved registry, global config, WSL, sysctl, Docker Desktop, antivirus, or shell-profile mutation.
 - Dangerous file operations are bounded to known repository-owned or generated locations.
 - Atomicity and race-safety claims are scoped to what the current helpers and platform can actually guarantee.
 - Any untested platform behavior is reported as remaining risk instead of claimed safe.
@@ -122,8 +137,10 @@ Use release checks when template files, package artifacts, or installed workflow
 - If the platform cannot prove symlink-safe behavior, fail closed or document the exact remaining gap.
 - If atomic replace, file fsync, parent directory fsync, no-follow open, or final-target verification is not available on the platform, downgrade the claim to best-effort and keep the write boundary narrow.
 - If Unicode normalization, Windows namespace prefixes, alternate data streams, or reparse points could change the effective target, fail closed or report the exact unhandled path class.
+- If clone, checkout, scaffold, install, extraction, or generated-tree materialization fails, classify filesystem and platform causes before reporting network, token, auth, dependency, or unknown causes.
+- If a fix requires elevated host settings or global user configuration, stop at a clear prerequisite report unless an explicit configured command intent and user request authorize the setup.
 - If a test depends on platform-specific symlink support or permissions, state the platform boundary and keep assertions narrow.
-- If cleanup might remove user data, do not proceed without a tighter generated-state boundary.
+- If cleanup might remove user data, do not proceed without a tighter app-owned staging or generated-state boundary.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
@@ -131,6 +148,8 @@ Use release checks when template files, package artifacts, or installed workflow
 - Filesystem surface reviewed
 - Path trust classes, invalid-name handling, case policy, and root boundary
 - Null byte, reserved-name, Unicode normalization, namespace prefix, alternate data stream, symlink, reparse-point, traversal, race, atomic write, durability, permission, copy, delete, scan, and cleanup decisions
+- Clone, checkout, scaffold, install, extraction, preflight, staging, promotion, path-length, collision, failure-taxonomy, and diagnostic-preservation decisions
+- Host-setting prerequisites reported or deferred
 - Windows/POSIX assumptions and skipped platform checks
 - Tests or fixtures added or reused
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/file-path-cross-platform-change/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.file-path-cross-platform-change
 locale: en
 canonical: true
-revision: 1
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: file-path-cross-platform-change
-description: Apply this skill when file path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported.
+description: Apply this skill when file path handling, cross-platform path behavior, path helpers, safe filesystem wrappers, clone or checkout destinations, scaffold roots, temp or cache paths, atomic writes, locks, archive extraction, uploads, downloads, scanners, CLI/API/schema path contracts, snapshots, generated outputs, or package artifact paths are created, changed, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,7 +35,8 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 ## Use When
 
 - Code accepts, stores, serializes, validates, normalizes, joins, resolves, compares, scans, extracts, uploads, downloads, writes, deletes, locks, packages, or reports paths.
-- Path behavior appears in CLI arguments, API request or response schemas, config files, snapshots, fixtures, generated output, package artifacts, logs, manifests, caches, temp directories, upload or download flows, archive extraction, or scanner output.
+- Path behavior appears in CLI arguments, API request or response schemas, config files, snapshots, fixtures, generated output, package artifacts, logs, manifests, caches, temp directories, upload or download flows, archive extraction, repository clone or checkout destinations, project scaffolding, installer output, or scanner output.
+- Code clones or checks out repositories, downloads and extracts templates, scaffolds projects, installs dependency trees, or cleans up partially materialized project folders after a filesystem or toolchain failure.
 - A change claims path traversal safety, base-directory containment, symlink safety, junction or reparse-point safety, archive extraction safety, atomic write behavior, durable write behavior, lock ownership, cleanup safety, deterministic scanning, or Windows/macOS/Linux compatibility.
 - A test or docs example includes paths that must behave consistently across Windows, macOS, Linux, CI, containers, archives, package artifacts, or user machines.
 
@@ -53,6 +54,7 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 - Every path input and output, including user input, CLI args, API fields, config fields, archive entries, generated files, temp files, cache paths, lock files, uploaded filenames, download filenames, scanner roots, package artifact paths, and logs.
 - The path owner and trust class: user-controlled, repository-owned, generated, temp, cache, archive-contained, package artifact, external file, or unknown.
 - The base directory or allowed root, expected relative/absolute policy, symlink and reparse-point policy, case-sensitivity policy, invalid-name policy, atomic-write policy, lock policy, archive extraction policy, scanner bounds, cleanup policy, and platform expectations.
+- For clone, checkout, scaffold, extract, and install flows: requested source, destination root, final project directory, deepest expected entry when known, path-length budget, component-length budget, byte budget, preflight coverage, partial-output owner, staging directory owner, promotion policy, cleanup policy, and failure classification contract.
 - Current path helpers, safe filesystem wrappers, temp/cache helpers, archive helpers, upload/download helpers, scanners, schema validators, snapshots, and tests.
 - Relevant command-intent entries for build, tests, docs, release, and mustflow validation.
 
@@ -75,34 +77,45 @@ Treat file paths as security boundaries and operating-system contracts, not as o
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Build a path ledger. List every path field, argument, helper, schema, snapshot, generated output, package artifact, archive entry, upload/download filename, scanner root, temp/cache path, lock file, and cleanup target touched by the change.
+1. Build a path ledger. List every path field, argument, helper, schema, snapshot, generated output, package artifact, archive entry, clone or checkout destination, scaffold output, installer output, upload/download filename, scanner root, temp/cache path, lock file, and cleanup target touched by the change.
 2. Classify each path by trust and owner: trusted repository path, user input, generated state, template path, package artifact, temporary file, cache file, archive-contained path, external path, uploaded name, downloaded name, scanner root, or unknown.
 3. Define the allowed root and representation. Decide whether the contract accepts relative paths, absolute paths, URLs, file URLs, archive entry names, package-relative paths, repository-relative paths, or display-only paths.
 4. Reject dangerous path text before filesystem access: null bytes, empty names where not allowed, absolute paths where relative paths are required, dot segments where not allowed, Windows device names, drive-relative paths, UNC roots, namespace prefixes, alternate data streams, trailing dots or spaces, reserved characters, and mixed separator bypasses.
 5. Treat Windows drive-relative paths such as `C:tmp.txt` as relative to a drive current directory, not as `C:\tmp.txt`.
 6. Treat Windows reserved names as reserved even with extensions. Names such as `CON`, `PRN`, `AUX`, `NUL`, `COM1`, and `LPT1` must not become ordinary user filenames.
-7. Treat macOS and Windows case-insensitive defaults as compatibility risks. Decide whether to reject case-only collisions, preserve spelling, normalize display only, or rely on the host filesystem.
-8. Do not solve containment with string prefixes. Establish the base real path, resolve or canonicalize the candidate parent when possible, then use path-aware relative containment with a separator boundary.
-9. For new files whose final path does not exist yet, canonicalize the existing parent directory and verify that parent remains inside the allowed root.
-10. Recheck symlink, junction, reparse-point, and final-target behavior at the operation boundary where the runtime allows it. Do not claim race-free behavior from normalize-then-open code alone.
-11. For uploads and downloads, separate displayed filename from storage key. Validate extension, size, content type, magic bytes when relevant, path separators, Unicode aliasing, reserved names, collision policy, overwrite policy, and tenant or user ownership.
-12. For archive extraction, validate every entry before extraction. Reject absolute entries, parent traversal, empty names, platform-reserved names, symlink entries unless explicitly supported, hard links unless explicitly supported, duplicate or case-colliding entries, oversized entries, zip bombs, and extraction outside the target root.
-13. Do not call extract-all behavior on untrusted archives unless the helper performs per-entry validation and bounded extraction.
-14. For atomic writes, create the temporary file in the target directory on the same filesystem, use an unpredictable temp name, write, flush, close, replace or rename, and flush the parent directory when the platform and helper support it.
-15. Scope atomicity claims. Cross-filesystem moves, network filesystems, Windows sharing violations, antivirus/indexer locks, and missing directory fsync support can downgrade a claim to best effort.
-16. For Windows replace or rename failures caused by sharing violations, use bounded retry or report the platform limitation. Do not turn every transient lock into silent data loss.
-17. For locks and mutexes, define owner token, stale lock policy, crash recovery, deletion race handling, PID reuse handling, and whether the lock works on local filesystems only. Do not treat a PID file alone as proof of ownership.
-18. For scanners, set max depth, max file count, max file size, binary-file handling, ignored directories, hidden-file policy, permission-error behavior, symlink traversal policy, loop detection, deterministic ordering, and output path format.
-19. For temp and cache paths, keep them under an owned root, avoid global temp rename into a target location, include cleanup bounds, and avoid leaking user data through predictable names.
-20. For CLI, API, schema, snapshot, docs, and package artifact path changes, update every contract surface together. Path spelling, separators, slash policy, absolute/relative policy, escaping, sorting, and error messages are part of the contract.
-21. Add focused tests for the riskiest path shapes: traversal, absolute input, drive-relative input, UNC-like input, reserved names, trailing dots or spaces, case collision, symlink escape, archive traversal, duplicate archive entries, scanner loop, large file cap, and cleanup boundary.
-22. Select verification from the command contract based on risk. Public CLI/API/schema/package artifact changes need broader checks than internal helper-only changes.
+7. For clone, checkout, scaffold, extract, and install flows, use an explicit `preflight -> dangerous operation -> classifier -> safe cleanup` pipeline. Preflight must estimate the effective path budget before materializing files, including the destination root, project directory, generated path segments, archive or repository entry names when known, operating-system path limits, component-name limits, byte limits, and safety headroom.
+8. For Git clone and checkout materialization, do not treat `clone` as one indivisible operation. When feasible, fetch repository metadata into an app-owned staging area without checkout, inspect the tree or manifest entries, check the final destination budget, Windows reserved names, byte limits, Unicode aliases, and case collisions, then perform checkout or promotion only after the destination is known to be safe.
+9. Do not clone, extract, scaffold, or install directly into a user-selected final directory when the operation may partially materialize an externally sourced tree. Materialize into an owned staging directory, preserve diagnostics on failure, and promote or move into the final directory only after success.
+10. On Windows Git checkout paths, do not assume the operating system long-path setting alone is enough. Product code that invokes Git should prefer per-invocation `core.longpaths=true` configuration when compatible, avoid mutating global Git config without explicit user intent, and still surface a path-specific error if checkout cannot create an entry.
+11. Treat POSIX `ENAMETOOLONG`, component-length failures, case-only conflicts on case-sensitive filesystems, missing executable bits, watcher limits, descriptor limits, quota, and mount permission errors as platform failures, not generic application failures.
+12. Count bytes where the platform counts bytes. A filename that looks short in characters can exceed component limits when it contains CJK, combining marks, emoji, or mixed normalization forms. Do not treat JavaScript string length, Python `len`, or UI character count as a filesystem byte-budget proof.
+13. Do not silently hash, truncate, underscore-prefix, fullwidth-convert, or otherwise rename user, repository, archive, or generated filenames to dodge platform restrictions unless the product contract explicitly defines a reversible mapping, collision handling, display name, migration behavior, and user-facing explanation.
+14. Treat macOS and Windows case-insensitive defaults as compatibility risks. Decide whether to reject case-only collisions, preserve spelling, normalize display only, or rely on the host filesystem.
+15. Detect candidate collisions before writing when entries come from Git trees, archives, generators, uploads, or package artifacts. Include case collisions, Unicode normalization aliases, reserved names, trailing dot or space aliases, and duplicate archive entries.
+16. Do not solve containment with string prefixes. Establish the base real path, resolve or canonicalize the candidate parent when possible, then use path-aware relative containment with a separator boundary.
+17. For new files whose final path does not exist yet, canonicalize the existing parent directory and verify that parent remains inside the allowed root.
+18. Recheck symlink, junction, reparse-point, and final-target behavior at the operation boundary where the runtime allows it. Do not claim race-free behavior from normalize-then-open code alone.
+19. For uploads and downloads, separate displayed filename from storage key. Validate extension, size, content type, magic bytes when relevant, path separators, Unicode aliasing, reserved names, collision policy, overwrite policy, and tenant or user ownership.
+20. For archive extraction, validate every entry before extraction. Reject absolute entries, parent traversal, empty names, platform-reserved names, symlink entries unless explicitly supported, hard links unless explicitly supported, duplicate or case-colliding entries, oversized entries, zip bombs, and extraction outside the target root.
+21. Do not call extract-all behavior on untrusted archives unless the helper performs per-entry validation and bounded extraction.
+22. Classify filesystem and platform errors before reporting a generic network, auth, dependency, or unknown failure. Use a stable taxonomy such as `path_too_long`, `filename_too_long`, `byte_limit_exceeded`, `invalid_path`, `reserved_name`, `case_collision`, `unicode_collision`, `symlink_escape`, `permission_denied`, `file_locked`, `cross_device_move`, `disk_full_or_quota`, `executable_bit_missing`, `line_ending_mismatch`, `watcher_limit`, and `descriptor_limit`.
+23. Preserve bounded diagnostic evidence before cleaning up a failed clone, scaffold, extraction, install, or generated-output write. Cleanup may remove only an app-owned staging directory or owned partial output, never an ambiguous parent directory, an existing project directory, or a user-selected final folder.
+24. For atomic writes, create the temporary file in the target directory on the same filesystem, use an unpredictable temp name, write, flush, close, replace or rename, and flush the parent directory when the platform and helper support it.
+25. Scope atomicity claims. Cross-filesystem moves, network filesystems, Windows sharing violations, antivirus/indexer locks, and missing directory fsync support can downgrade a claim to best effort.
+26. For Windows replace or rename failures caused by sharing violations, use bounded retry or report the platform limitation. Do not turn every transient lock into silent data loss.
+27. For locks and mutexes, define owner token, stale lock policy, crash recovery, deletion race handling, PID reuse handling, and whether the lock works on local filesystems only. Do not treat a PID file alone as proof of ownership.
+28. For scanners, set max depth, max file count, max file size, binary-file handling, ignored directories, hidden-file policy, permission-error behavior, symlink traversal policy, loop detection, deterministic ordering, and output path format.
+29. For temp and cache paths, keep them under an owned root, avoid global temp rename into a target location, include cleanup bounds, and avoid leaking user data through predictable names.
+30. For CLI, API, schema, snapshot, docs, and package artifact path changes, update every contract surface together. Path spelling, separators, slash policy, absolute/relative policy, escaping, sorting, and error messages are part of the contract.
+31. Add focused tests for the riskiest path shapes: traversal, absolute input, drive-relative input, UNC-like input, reserved names, trailing dots or spaces, case collision, Unicode collision, long path, overlong filename, byte-limit overflow with multibyte names, symlink escape, archive traversal, duplicate archive entries, scanner loop, large file cap, clone checkout failure classification, and cleanup boundary.
+32. Select verification from the command contract based on risk. Public CLI/API/schema/package artifact changes need broader checks than internal helper-only changes.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Path trust classes, accepted path representation, invalid-name policy, case policy, root boundary, symlink and reparse-point policy, archive policy, upload/download policy, scanner policy, atomic-write policy, lock policy, temp/cache policy, and cleanup policy are explicit.
 - Path contracts are synchronized across helpers, schemas, CLI/API docs, snapshots, fixtures, generated outputs, package artifacts, tests, and reports.
+- Clone, checkout, scaffold, extract, and install flows have explicit preflight, staging, promotion, path-length, collision, platform-failure classification, diagnostic-preservation, and cleanup policies.
 - Any race-safety, atomicity, durability, lock, or cross-platform claim is scoped to what the current runtime and helpers can actually guarantee.
 - Platform behavior that was not tested is reported as remaining risk.
 
@@ -129,6 +142,7 @@ Prefer focused tests for helper-only path changes. Use release or package checks
 - If root containment is unclear, stop before writing, deleting, extracting, scanning, or opening and report the ambiguous path owner.
 - If the platform cannot prove symlink-safe behavior, fail closed or report the exact remaining gap.
 - If archive entries cannot be validated before extraction, do not extract the archive.
+- If clone, checkout, scaffold, extraction, or install fails mid-materialization, classify filesystem and platform causes before network or auth causes, preserve bounded diagnostics, and cleanup only the owned staging directory or owned partial output.
 - If atomic replace, file fsync, parent directory fsync, no-follow open, lock ownership, or final-target verification is unavailable, downgrade the claim and keep the operation bounded.
 - If Windows, macOS, Linux, container, CI, or network-filesystem behavior differs and cannot be tested, state the untested platform boundary.
 - If cleanup might remove user data or files outside generated state, do not proceed without a tighter owned root.
@@ -139,7 +153,8 @@ Prefer focused tests for helper-only path changes. Use release or package checks
 - Path contract changed
 - Path ledger and trust classes
 - Accepted representation and base-root policy
-- Windows, macOS, Linux, archive, upload/download, scanner, lock, temp/cache, atomic-write, and cleanup decisions
+- Windows, macOS, Linux, byte-limit, Unicode, archive, upload/download, scanner, lock, temp/cache, atomic-write, and cleanup decisions
+- Clone, checkout, scaffold, extract, install, preflight, staging, promotion, failure-taxonomy, diagnostic-preservation, and safe-cleanup decisions
 - CLI/API/schema/snapshot/generated-output/package artifact surfaces synchronized
 - Tests or fixtures added or reused
 - Command intents run

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.line-ending-hygiene
 locale: en
 canonical: true
-revision: 1
+revision: 2
 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.
+description: Apply this skill when Git reports CRLF/LF warnings, Docker or shell scripts fail with CRLF interpreter errors, or tracked text files may need repository line-ending policy or normalization review.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -30,6 +30,8 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 
 - Git reports CRLF, LF, or line-ending replacement warnings.
 - A diff or formatter appears to rewrite files only because of line endings.
+- Docker, Linux, WSL, CI, or shell execution fails with `bad interpreter`, `bash\r`, `env: ...\r`, `exec format error`, or similar CRLF-related symptoms.
+- A proposal suggests creating `.gitattributes`, running renormalization, or rewriting tracked files to fix cross-platform line endings.
 - A user asks why line-ending warnings appear.
 - A user asks to normalize tracked files to the repository line-ending policy.
 
@@ -46,6 +48,7 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 - The warning text or changed-file evidence.
 - Current `.gitattributes` or equivalent repository line-ending policy.
 - Current changed-file status.
+- Whether the request is diagnosis-only, policy authoring, or explicit tracked-file normalization.
 - The configured command intents for line-ending checks and manual normalization.
 
 <!-- mustflow-section: preconditions -->
@@ -62,6 +65,7 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 - 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.
+- Do not create `.gitattributes`, run repository-wide renormalization, or commit line-ending changes as an automatic fallback from a build, Docker, clone, scaffold, or script failure.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
@@ -69,15 +73,18 @@ Detect line-ending drift without silently rewriting a repository, and normalize
 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.
+4. If a runtime error mentions CRLF symptoms, classify it as a line-ending/platform issue before treating it as a missing executable, missing dependency, Docker image problem, or shell bug.
+5. If drift is found, report the affected tracked files and whether normalization was only previewed.
+6. If a policy file needs to be created or changed, keep that as an explicit policy change with reviewable scope. Do not smuggle a new repository-wide policy into an unrelated bug fix.
+7. Use normalization only after an explicit user request, and treat `line_endings_normalize` as manual-only unless the repository declares otherwise.
+8. After any normalization, re-run the line-ending check and a relevant validation intent for the touched scope.
+9. 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.
+- The agent has not silently created or changed a repository-wide line-ending policy.
 - Any normalization is tied to a declared repository policy.
 - Remaining CRLF, mixed line endings, missing policy, or manual-only command gaps are reported.
 
@@ -99,11 +106,13 @@ If normalization touched code, documentation, templates, or release surfaces, al
 - 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.
+- If a fix would require repository-wide policy authoring or tracked-file renormalization, report the prerequisite unless the user explicitly requested that scope.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
 
 - Line-ending policy found
+- Policy changes made or deferred
 - Files with CRLF or mixed line endings
 - Files normalized
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/process-execution-safety/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.process-execution-safety
 locale: en
 canonical: true
-revision: 1
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: process-execution-safety
-description: Apply this skill when spawning, wrapping, previewing, timing out, terminating, buffering, streaming, or reporting child processes, built-in command reruns, shell commands, argv commands, environment variables, output limits, process trees, or long-running command patterns.
+description: Apply this skill when spawning, wrapping, previewing, timing out, terminating, buffering, streaming, classifying, or reporting child processes, built-in command reruns, shell commands, argv commands, environment variables, output limits, process trees, Git or package-manager failures, or long-running command patterns.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -32,6 +32,7 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 
 - Code spawns, wraps, previews, streams, buffers, times out, kills, reruns, or reports a child process or in-process built-in command.
 - A command path handles shell mode, argv mode, process groups, Windows task termination, POSIX signals, output limits, stdin, environment variables, or working directories.
+- Code invokes Git clone or checkout, package managers, project scaffolders, archive tools, build tools, test runners, Docker wrappers, or installers whose failures can be misclassified as network, token, auth, dependency, or unknown errors.
 - Long-running, background, watcher, server, browser, daemon, shell wrapper, package-manager, or project-local executable patterns are allowed, blocked, or classified.
 - Receipts, logs, verification, write tracking, or final reports depend on whether a command actually finished.
 
@@ -46,8 +47,10 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 ## Required Inputs
 
 - The execution path: shell, argv, built-in rerun, preview, dry run, JSON mode, streaming mode, or configured command intent.
-- Timeout, grace period, force-kill behavior, output limit, stdin policy, environment policy, working directory, process tree behavior, and receipt or write-tracking expectations.
+- Timeout, grace period, force-kill behavior, output limit, stdin policy, argv and shell command-length budget, environment policy, working directory, process tree behavior, and receipt or write-tracking expectations.
 - Platform boundary for Windows and POSIX process termination.
+- Failure classification rules for child-process output and exit causes, including filesystem/path, permission/lock, resource exhaustion, shell/environment, missing executable, network, token, auth, dependency, timeout, output overflow, and unknown categories.
+- For Git and scaffolding flows: clone or checkout destination, path-length policy, per-process Git config policy, partial-output owner, cleanup timing, and diagnostic-preservation expectations.
 - Existing tests for timeout, output overflow, environment redaction, local executable avoidance, command eligibility, and receipt status.
 - Relevant command-intent entries for related tests, release checks, and mustflow validation.
 
@@ -65,25 +68,40 @@ Ensure process execution obeys declared command contracts, terminates reliably,
 - Prefer one execution path for JSON and human modes when output format alone should differ.
 - Do not bypass timeouts, output limits, working-directory checks, environment policy, or receipt generation for convenience.
 - Do not run unconfigured servers, watchers, background tasks, or interactive commands.
+- Do not use child-process code to apply privileged host repairs such as registry edits, global Git config, Developer Mode changes, WSL shutdown or mount edits, sysctl writes, Docker Desktop setting changes, antivirus exclusions, shell profile edits, or automatic commits unless an explicit configured command intent and user request authorize that setup operation.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
 
 1. Map the execution path from command contract to child process, output handling, receipt writing, write tracking, and final status.
 2. Confirm that shell and argv modes enforce the same safety boundary where they represent the same command intent.
-3. Check timeout semantics. A timeout should initiate termination, wait through the declared grace behavior when possible, attempt force termination when needed, and record whether cleanup was confirmed or still uncertain.
-4. Check output limit semantics. Output overflow should be distinct from process start failure, apply consistently across output modes, preserve bounded tails, and avoid unbounded memory growth.
-5. Check process-tree cleanup. On POSIX, account for process groups and signals. On Windows, account for task termination behavior and the fact that process-group semantics differ.
-6. Check in-process shortcuts. Built-in commands should not bypass timeout, output, environment, working-directory, or receipt policy unless the command contract explicitly accepts the weaker boundary.
-7. Check environment exposure. Minimal or allowlisted environments should be the default for agent-runnable commands, with redaction only as a logging safeguard, not as execution isolation.
-8. Check command eligibility before execution. Long-running and shell-wrapper patterns should be blocked or made manual-only before relying on timeout as the only defense.
-9. Check write tracking and receipts. Do not finalize a receipt or write-drift snapshot as complete while a child process may still be writing, unless the receipt states cleanup is unconfirmed.
-10. Add focused tests for timeout, output limit, environment, built-in rerun, local executable avoidance, and platform-neutral status semantics as justified by the change.
+3. Prefer argv execution over shell-string execution for dynamic commands. Do not build `exec("long command string")` or shell wrappers from repository paths, file lists, prompts, JSON, or user input when the tool can accept a file plus args, stdin, or an owned temporary parameter file.
+4. Keep large payloads out of argv and shell strings. Pass large JSON, file lists, AI prompts, generated context, and batch parameters through stdin or an owned temporary file with bounded lifetime, ownership, redaction, and cleanup policy.
+5. Classify command-length failures separately. Windows process creation, `cmd.exe`, POSIX `ARG_MAX`, shells, package managers, and wrapper scripts can fail at different limits; map these to `argv_too_long` or `shell_command_too_long` before retrying or reporting an unknown tool failure.
+6. In Node.js path handling around process execution, use explicit `path.win32` or `path.posix` behavior when parsing a path format that may differ from the host OS. Do not assume host-default `node:path` behavior proves cross-platform command construction.
+7. Check timeout semantics. A timeout should initiate termination, wait through the declared grace behavior when possible, attempt force termination when needed, and record whether cleanup was confirmed or still uncertain.
+8. Check output limit semantics. Output overflow should be distinct from process start failure, apply consistently across output modes, preserve bounded tails, and avoid unbounded memory growth.
+9. Check process-tree cleanup. On POSIX, account for process groups and signals. On Windows, account for task termination behavior and the fact that process-group semantics differ.
+10. Check in-process shortcuts. Built-in commands should not bypass timeout, output, environment, working-directory, or receipt policy unless the command contract explicitly accepts the weaker boundary.
+11. Check environment exposure. Minimal or allowlisted environments should be the default for agent-runnable commands, with redaction only as a logging safeguard, not as execution isolation.
+12. Check command eligibility before execution. Long-running and shell-wrapper patterns should be blocked or made manual-only before relying on timeout as the only defense.
+13. For Git clone or checkout on Windows, prefer argv mode with a per-process `core.longpaths=true` configuration when compatible. Do not mutate global Git config from product code unless the user explicitly selected that setup action.
+14. For Git, package-manager, and scaffolder materialization, coordinate with filesystem safety: preflight entries when feasible, run the dangerous operation only against an app-owned staging area, classify failure before cleanup, then delete only owned partial output.
+15. Classify child-process failures before retrying or reporting them. Separate filesystem/path, permission/lock, resource exhaustion, shell/environment, missing executable, network, token, auth, dependency, timeout, output overflow, argv length, shell command length, and unknown causes.
+16. Do not classify a Git checkout path failure as network, token, or auth merely because the top-level operation was clone. Output such as filename-too-long, invalid path, reserved name, permission denied, file locked, no space left, too many open files, watcher limit, bad interpreter, missing executable bit, argv-too-long, or shell-command-too-long should map to platform, filesystem, resource, or shell categories first.
+17. Preserve bounded stdout/stderr tails, exit status, signal, timeout status, cwd, argv summary, and cleanup status before deleting partial output from clone, checkout, scaffold, install, or archive-tool failures.
+18. Keep retry policy cause-aware. Retry transient locks or recoverable process cleanup only when bounded and idempotent; do not blindly retry auth, token, path-too-long, reserved-name, or destructive cleanup failures.
+19. Treat environment repair as a separate setup workflow, not as an invisible fallback inside clone, install, build, or test execution. Report missing host prerequisites and the blocked action rather than silently running privileged or global mutation commands.
+20. Check write tracking and receipts. Do not finalize a receipt or write-drift snapshot as complete while a child process may still be writing, unless the receipt states cleanup is unconfirmed.
+21. Add focused tests for timeout, output limit, environment, built-in rerun, local executable avoidance, failure classification, diagnostic preservation, partial-output cleanup, blocked host-repair fallback, and platform-neutral status semantics as justified by the change.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Execution status, timeout status, output status, cleanup status, receipt status, and write tracking tell the same story.
+- Child-process failures have cause-aware categories that separate filesystem/path, permission/lock, resource exhaustion, shell/environment, network, token, auth, dependency, timeout, output overflow, argv length, shell command length, and unknown causes.
+- Partial clone, checkout, scaffold, install, or archive outputs are cleaned up only after bounded diagnostics and app-owned staging or generated-state ownership are known.
+- Host repair commands are either modeled as explicit configured setup intents or reported as prerequisites, not hidden inside ordinary command execution.
 - JSON and human modes differ only in presentation unless a documented contract says otherwise.
 - Any unconfirmed cleanup or platform limitation is explicit in the report.
 
@@ -104,6 +122,8 @@ Escalate to broader configured tests when execution behavior crosses many comman
 ## Failure Handling
 
 - If a timed-out or output-limited process cannot be confirmed terminated, record the uncertainty and do not claim full cleanup.
+- If a child process fails after creating files, preserve bounded diagnostics and classify path/platform causes before deleting owned partial output or reporting a network, token, auth, dependency, or unknown failure.
+- If recovery would require privileged or global host mutation, stop and report the prerequisite instead of running the mutation as a fallback.
 - If environment isolation cannot be applied to a path, fail closed or route through a spawned process that can honor the contract.
 - If a platform-specific termination test is not available, report the skipped platform check and cover the shared status contract.
 - If a process safety fix conflicts with convenience or performance, preserve safety and report the tradeoff.
@@ -115,6 +135,8 @@ Escalate to broader configured tests when execution behavior crosses many comman
 - Timeout, force-kill, output-limit, environment, stdin, cwd, and process-tree boundaries
 - Receipt, write-tracking, and cleanup-confirmation behavior
 - Shell, argv, JSON, streaming, and built-in path consistency
+- Failure classification, retry policy, argv and shell length handling, diagnostic preservation, and partial-output cleanup behavior
+- Host repair prerequisites reported or deferred
 - Tests or fixtures added or reused
 - Command intents run
 - Remaining process execution risk

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

@@ -108,6 +108,12 @@ route_type = "primary"
 priority = 20
 applies_to_reasons = ["unknown_change", "code_change"]
 
+[routes."clarifying-question-gate"]
+category = "general_code"
+route_type = "adjunct"
+priority = 42
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "public_api_change", "security_change", "privacy_change", "data_change", "migration_change", "package_metadata_change"]
+
 [routes."api-contract-change"]
 category = "general_code"
 route_type = "primary"
@@ -412,7 +418,7 @@ applies_to_reasons = ["code_change"]
 category = "general_code"
 route_type = "primary"
 priority = 35
-applies_to_reasons = ["code_change", "unknown_change"]
+applies_to_reasons = ["code_change", "unknown_change", "behavior_change", "public_api_change", "security_change", "data_change", "migration_change", "product_change"]
 
 [routes."repro-first-debug"]
 category = "bug_failure"

package/templates/default/locales/en/.mustflow/skills/structure-discovery-gate/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.structure-discovery-gate
 locale: en
 canonical: true
-revision: 27
+revision: 28
 lifecycle: mustflow-owned
 authority: procedure
 name: structure-discovery-gate
@@ -27,10 +27,18 @@ metadata:
 
 Find hidden structure decisions before coding so new files, folders, names, routing, data models, and integration boundaries reduce future change cost instead of producing a neat but brittle tree.
 
+This is the pre-implementation design gate for work where the agent might otherwise shrink the user's
+problem into an easy toy version. It should expose the agent's current understanding, classify the
+work by risk, and stop before coding only when the next design choice can change compatibility,
+data, authorization, failure behavior, scale, operations, or long-term structure.
+
 <!-- mustflow-section: use-when -->
 ## Use When
 
 - The task asks for a new feature, module, folder layout, architecture, scaffold, refactor, API integration, website, app flow, routing structure, data model, state model, or file split.
+- The user asks for a broad or ambiguous capability and coding immediately would require guessing
+  success criteria, scope boundaries, users or roles, data lifecycle, failure policy, scale target,
+  existing conventions, non-negotiable constraints, test proof, or operational recovery behavior.
 - A named technology or service may be only an implementation choice rather than the product domain, such as AdSense, Stripe, Supabase, Firebase, Resend, SendGrid, Google Analytics, Plausible, or a CMS.
 - The request may hide costly structural decisions around localization, SEO, authentication, authorization, payments, ads, analytics, admin workflows, deployment, content management, storage, retention, or external service replacement.
 - A website, content system, marketplace, comparison site, review site, knowledge base, documentation site, or data-backed product may later need filtering, search, localization, SEO, public APIs, apps, content revisions, data verification, redirects, or cache invalidation.
@@ -78,6 +86,10 @@ Find hidden structure decisions before coding so new files, folders, names, rout
 ## Required Inputs
 
 - User request and intended product or code change.
+- Design gate classification: `simple_patch`, `bounded_feature`, `structural_change`, or
+  `risk_change`, with a short reason for the classification.
+- The agent's current understanding of the requirement in four sentences or fewer.
+- Candidate success criteria, non-goals, and compatibility boundaries that could change the design.
 - Current project instructions, relevant context, and nearby implementation patterns when available.
 - Known target platform, language, framework, package, or deployment constraints.
 - Any named external services, content sources, user roles, locales, data stores, algorithms, policies, feature flags, or revenue surfaces in the request.
@@ -135,8 +147,32 @@ Find hidden structure decisions before coding so new files, folders, names, rout
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Restate the requested change as the product capability or code responsibility, not just the named technology.
-2. Identify hidden decisions that could change routing, folder names, file boundaries, data model, state ownership, environment variables, tests, deployment, SEO, localization, external integrations, or legal and policy requirements.
+1. Classify the work before designing:
+   - `simple_patch`: one obvious target, existing local pattern, low reversibility cost, no new
+     contract, data, permission, dependency, or architecture decision. Do not run a design interview;
+     inspect files and fix it.
+   - `bounded_feature`: a focused capability with a few missing product or verification decisions.
+     Produce a compact gate with at most five design-shaping questions.
+   - `structural_change`: new boundaries, data models, public contracts, workflows, services, or
+     cross-module responsibilities are likely. Do not edit until the design gate has a selected
+     implementation boundary.
+   - `risk_change`: the work touches database schema, auth, permissions, billing, personal data,
+     destructive actions, public APIs, migrations, dependencies on survival paths, external side
+     effects, or operational recovery. Treat editing as blocked until the risky decisions are
+     resolved or explicitly scoped out.
+2. Restate the requested change as the product capability or code responsibility, not just the named technology. Keep the restatement to four sentences or fewer so the user can correct an early misunderstanding quickly.
+3. Identify hidden decisions that could change routing, folder names, file boundaries, data model, state ownership, environment variables, tests, deployment, SEO, localization, external integrations, or legal and policy requirements.
+   Always check whether the design changes along these axes before asking:
+   - observable success criteria and verification proof;
+   - scope and non-scope, including public API, URL, schema, event, and stored-data compatibility;
+   - actor roles, tenant or ownership boundaries, and server-side authorization;
+   - data creation, state transition, deletion, retention, migration, and recovery lifecycle;
+   - failure mode, retry, idempotency, partial success, rollback, operator visibility, and manual recovery;
+   - expected scale, performance floor, pagination, indexing, caching, and queue or batch throughput;
+   - existing local conventions, nearby precedents, naming, error shapes, folder layout, and test style;
+   - constraints such as no new dependency, no migration, no public contract change, browser/runtime support, SEO, SSR, and privacy boundaries;
+   - tests or invariants that prove the behavior, not only happy-path examples;
+   - logging, metrics, audit, trace identifiers, alerts, and operational repair paths.
    For content-heavy products, treat these as structural decisions, not later feature polish:
    - Permanent identity: distinguish stable ids from titles, slugs, display names, routes, and provider ids.
    - Addressing: decide canonical URLs, locale routes, slug history, redirects, filter URLs, sitemap inclusion, `noindex`, and canonical behavior.
@@ -195,12 +231,15 @@ Find hidden structure decisions before coding so new files, folders, names, rout
    - Failure radius: decide timeout, retry, circuit-breaker, feature-flag, stale fallback, degraded mode, and resource-pool boundaries so one auxiliary dependency does not make unrelated core functions fail.
    - Operations: decide status workflow, ownership, created/updated actors, permissions, audit logs, preview needs, admin filters, analytics event identity, privacy, deletion, anonymization, retention, backup, and migration expectations before adding user or content data.
    - Interaction and monetization: decide whether accounts, anonymous identity linking, comments, moderation, reports, notifications, newsletter sends, paywalls, access levels, plans, and previews require data fields now even when the UI is deferred.
-3. Classify each decision:
+4. Classify each decision:
    - Blocking: the answer can change the basic structure and cannot be safely assumed.
    - Structure-impacting: the answer changes boundaries, but a conservative default can be stated if the user does not answer.
    - Preference: the answer affects styling, wording, or minor details and should not block structure.
-4. Ask at most five high-value questions before coding. Prioritize localization, authentication, authorization, payments, ads, personal data, destructive data actions, admin workflows, SEO, content storage, and external service replacement.
-5. For any question not asked, state the default assumption briefly. Defaults should keep future changes possible without adding speculative layers.
+5. Ask only questions whose answers can change the design. Each question must include the decision,
+   why it matters, the recommended default, and how at least one alternative changes the implementation.
+   Do not ask about facts that current files, docs, tests, schemas, or conventions can answer.
+6. Ask at most five high-value questions before coding. Prioritize localization, authentication, authorization, payments, ads, personal data, destructive data actions, admin workflows, SEO, content storage, external service replacement, failure policy, operational recovery, and verification proof.
+7. For any question not asked, state the default assumption briefly. Defaults should keep future changes possible without adding speculative layers.
    For a content or data-product default, prefer:
    - Stable internal ids plus mutable slugs.
    - Explicit lifecycle states and delete alternatives, such as archive, private, redirect, gone, and soft delete, before adding a destructive remove path.
@@ -254,7 +293,7 @@ Find hidden structure decisions before coding so new files, folders, names, rout
    - Operations-as-code-lite before infrastructure-as-code: even without Terraform or OpenTofu, require an environment schema, secret inventory, domain notes, cron definitions, deployment steps, observability notes, and smoke-test expectations when the platform can become a hidden source of truth.
    - Domain-shaped API responses over screen-shaped payloads; screen-specific endpoints are acceptable when labeled internal and still expose resources, states, errors, and pagination rather than card titles, button text, or storage implementation details.
    Do not add full implementations of these surfaces unless the task needs them now.
-6. Select structure patterns only when the task's risk shape requires them:
+8. Select structure patterns only when the task's risk shape requires them:
    - Use a plan/apply gate for destructive, bulk, migration, billing, permission, publishing, or external-send operations that need review before execution.
    - Use a capability object when a function should require a specific granted action instead of reading broad user or role state.
    - Use Result and Option values for expected business failures, meaningful absence, not found, invalid input, denied access, stale state, or blocked policy. Use `result-option` before editing that return-shape contract.
@@ -273,23 +312,23 @@ Find hidden structure decisions before coding so new files, folders, names, rout
    - Inject time or a time context when expiration, scheduling, retries, leases, or rate windows affect behavior.
    - Use explicit state transitions when three or more states have meaningful allowed moves.
    - Use an action ledger or idempotency key when repeating a side effect would be harmful.
-7. Prefer the smallest local version of the selected pattern. Do not add a framework, base class, service locator, global event bus, broad repository layer, or abstract factory when a plain function, table, adapter, or narrow policy object is enough.
-8. Separate product domains from vendor implementations. Use broad names at the product boundary and specific names inside provider or adapter internals.
+9. Prefer the smallest local version of the selected pattern. Do not add a framework, base class, service locator, global event bus, broad repository layer, or abstract factory when a plain function, table, adapter, or narrow policy object is enough.
+10. Separate product domains from vendor implementations. Use broad names at the product boundary and specific names inside provider or adapter internals.
    - Prefer `monetization/ads/providers/adsense` over top-level `adsense`.
    - Prefer `payments/providers/stripe` over top-level `stripe`.
    - Prefer `notifications/email/providers/resend` over top-level `resend`.
    - Prefer `analytics/providers/google-analytics` over top-level `googleAnalytics`.
-9. Propose the smallest folder and file structure that follows the answers and assumptions. For each new file or folder, state its responsibility and what it must not contain.
-10. Check the structure against local precedent with `pattern-scout` when the repository already has a nearby pattern.
-11. If the selected structure changes expected failure, meaningful absence, thrown business errors, null returns, or public error mapping, use `result-option` before editing that scope.
-12. If the selected structure creates or repairs a state-changing execution unit, use `command-pattern` before editing that scope.
-13. If the selected structure introduces or repairs lifecycle state transitions, use `state-machine-pattern` before editing that scope.
-14. If the selected structure introduces interchangeable algorithms, policies, calculations, provider choices, or feature-flag variants, use `strategy-pattern` before editing that scope.
-15. If the selected structure introduces one high-level entry point over several subsystem collaborators, use `facade-pattern` before editing that scope.
-16. If the selected structure separates business decisions from execution, use `pure-core-imperative-shell` before editing that scope.
-17. If the selected structure introduces inheritance, base classes, protected state, or subclass variants, use `composition-over-inheritance` before editing that scope.
-18. If the selected structure introduces or repairs an external dependency boundary, use `dependency-injection` for construction and collaborator flow, and `adapter-boundary` for external data, protocol, error, timeout, retry, idempotency, security, and observability handling.
-19. Implement only after the questions, assumptions, structure, dependency direction, and verification surface are clear enough for the task size.
+11. Propose the smallest folder and file structure that follows the answers and assumptions. For each new file or folder, state its responsibility and what it must not contain.
+12. Check the structure against local precedent with `pattern-scout` when the repository already has a nearby pattern.
+13. If the selected structure changes expected failure, meaningful absence, thrown business errors, null returns, or public error mapping, use `result-option` before editing that scope.
+14. If the selected structure creates or repairs a state-changing execution unit, use `command-pattern` before editing that scope.
+15. If the selected structure introduces or repairs lifecycle state transitions, use `state-machine-pattern` before editing that scope.
+16. If the selected structure introduces interchangeable algorithms, policies, calculations, provider choices, or feature-flag variants, use `strategy-pattern` before editing that scope.
+17. If the selected structure introduces one high-level entry point over several subsystem collaborators, use `facade-pattern` before editing that scope.
+18. If the selected structure separates business decisions from execution, use `pure-core-imperative-shell` before editing that scope.
+19. If the selected structure introduces inheritance, base classes, protected state, or subclass variants, use `composition-over-inheritance` before editing that scope.
+20. If the selected structure introduces or repairs an external dependency boundary, use `dependency-injection` for construction and collaborator flow, and `adapter-boundary` for external data, protocol, error, timeout, retry, idempotency, security, and observability handling.
+21. Implement only after the questions, assumptions, structure, dependency direction, and verification surface are clear enough for the task size.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -337,8 +376,12 @@ Also run narrower configured tests or builds required by the changed source, tem
 <!-- mustflow-section: output-format -->
 ## Output Format
 
+- Design gate classification and reason
+- Restated requirement in four sentences or fewer
 - Capability or responsibility being built
 - Blocking questions asked, or none
+- Recommended defaults and tradeoffs for each blocking question
+- Success criteria, non-goals, and compatibility boundaries
 - Structure-impacting assumptions
 - Proposed files and responsibilities
 - Upfront structure decisions versus deferred features

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.24.2"
+version = "2.25.1"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -19,6 +19,7 @@ creates = [
   ".mustflow/skills/behavior-preserving-refactor/SKILL.md",
   ".mustflow/skills/code-review/SKILL.md",
   ".mustflow/skills/codebase-orientation/SKILL.md",
+  ".mustflow/skills/clarifying-question-gate/SKILL.md",
   ".mustflow/skills/astro-code-change/SKILL.md",
   ".mustflow/skills/css-code-change/SKILL.md",
   ".mustflow/skills/dart-code-change/SKILL.md",
@@ -124,6 +125,7 @@ minimal = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",
@@ -175,6 +177,7 @@ patterns = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",
@@ -237,6 +240,7 @@ oss = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",
@@ -311,6 +315,7 @@ team = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",
@@ -373,6 +378,7 @@ product = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",
@@ -440,6 +446,7 @@ library = [
   "behavior-preserving-refactor",
   "code-review",
   "codebase-orientation",
+  "clarifying-question-gate",
   "astro-code-change",
   "css-code-change",
   "dart-code-change",