mustflow 2.112.10 → 2.112.13

package/templates/default/locales/en/.mustflow/skills/repro-first-debug/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.repro-first-debug
 locale: en
 canonical: true
-revision: 3
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: repro-first-debug
-description: Apply this skill when fixing a reported bug or confusing failure before the failure has a clear reproduction.
+description: Apply this skill when fixing, investigating, or instrumenting a reported bug, confusing failure, flaky symptom, production-only defect, unreproducible incident, or legacy-code failure before the failure has a clear reproduction.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -31,8 +31,9 @@ This skill keeps debugging anchored to symptom evidence, deterministic reproduct
 ## Use When
 
 - A user reports a bug, broken behavior, confusing runtime result, or failed workflow.
-- A failure is visible, but the smallest reproduction path is not yet clear.
+- A failure is visible, intermittent, production-only, data-dependent, or reported from another environment, but the smallest reproduction path is not yet clear.
 - A fix could otherwise be based on speculation, stale assumptions, or a broad unrelated test run.
+- A safe temporary patch is needed to stop harm, but the change must also capture evidence for the next occurrence instead of only hiding the symptom.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -49,6 +50,8 @@ This skill keeps debugging anchored to symptom evidence, deterministic reproduct
 - Any pasted error text, screenshot detail, failing command intent, route, or UI action.
 - Recently changed files or likely affected files.
 - Existing tests, command intents, or manual reproduction notes related to the failure.
+- Available diagnostic evidence such as trace id, span id, request id, job id, attempt, feature flag, deployment version, log query, normal-versus-failing trace comparison, profiler window, breakpoint or watchpoint condition, and safe DB/cache/external dependency facts.
+- Runtime state snapshot evidence when available: cache keys, DB row state, queue state, locks, in-flight work, timezone, environment/config values, server instance, feature flags, app version, browser/app version, region, release, and concurrent request count.
 - Any known flakiness, environment dependency, timing dependency, or unavailable reproduction requirement.
 
 <!-- mustflow-section: preconditions -->
@@ -81,13 +84,37 @@ This skill keeps debugging anchored to symptom evidence, deterministic reproduct
    - specific input, fixture, locale, path, or data shape;
    - external source, generated output, or stale build artifact.
    For each hypothesis, write the observation that would confirm or reject it before changing production code.
-6. If the symptom appears flaky, separate the reproducible behavior from the unstable trigger. Do not treat one passing broad rerun as proof that the issue is fixed.
-7. Inspect the source that controls the reproduced behavior and gather the smallest observation needed to choose between hypotheses.
-8. If temporary instrumentation is needed, give every probe a unique marker, keep it local to the suspect boundary, and remove it before final verification.
-9. Apply the smallest fix that addresses the reproduced cause.
-10. Re-run the original reproduction path after the fix. If that path is unavailable or too broad, run the closest configured intent and report the limitation.
-11. Add or keep a regression guard only when it is tied to the reproduced symptom or a directly observed boundary condition.
-12. Report the symptom, reproduction, hypotheses considered, observations, fix, original reproduction rerun, checks, and remaining risk.
+6. Reject symptom-cover patches before editing.
+   - A null check, timeout increase, expected-value tweak, broad retry, catch-and-ignore, or local-line-only patch is not acceptable until the broken invariant and first divergence are named.
+   - Before applying a patch, state which invariant failed, where the invariant first became false, and what no-patch observation proves that claim.
+   - List counterexamples that could still fail after the obvious patch, especially concurrency, cache, time zone, retry/idempotency, schema/wire compatibility, security, and performance cases.
+7. Build a diagnostic evidence packet when logs, traces, profiling, or breakpoints are involved.
+   - Prefer normal-versus-failing trace comparison before reading only the final error log.
+   - Tie evidence together with stable identifiers such as trace id, span id, request id, tenant id, job id, attempt, feature flag, and deployment version.
+   - If timing or ordering may matter, prefer profiler, trace duration, lock wait, allocation, queue age, or dependency latency evidence before stopping the process with a broad breakpoint.
+   - Use conditional instrumentation or breakpoints scoped to the failing id when configured or manually approved; do not leave those probes in committed code.
+8. If the symptom appears flaky, separate the reproducible behavior from the unstable trigger. Do not treat one passing broad rerun as proof that the issue is fixed.
+9. For unreproducible failures, switch from "make it fail locally" to "make the next failure leave evidence."
+   - Capture a state snapshot, not just the input payload: relevant memory/cache state, DB rows, locks, queue messages, time zone, deployment version, feature flags, environment/config values, server instance, dependency versions, and concurrency shape when safe and available.
+   - Prefer pre-failure ring buffers, bounded internal event trails, impossible-state assertions, invariant checks, DB constraints, background auditors, or sanity checkers that fire where the bad state is first created.
+   - Temporary mitigation should also add forensic evidence such as caller, retry header, idempotency key, first and second handling time, state before and after, or safe resource identifiers.
+10. Narrow production-only and legacy symptoms by evidence elimination.
+   - Split last-known-good and first-failed windows across code, config, data, migration, infra, dependency, external-provider, and traffic-pattern changes.
+   - Split mixed symptoms by error code, user cohort, browser, app version, region, server instance, time window, release, feature flag, and data shape before assuming one root cause.
+   - Search stable constants, error strings, DB column names, event names, queue topics, config keys, and external endpoint fragments before trusting function names.
+   - Start from exits and writers: DB writes, serialized responses, emitted events, emails, balance changes, files, queues, cron jobs, admin tools, and external side effects. Treat DB triggers, queues, cron, imports, and admin panels as code.
+   - Use blame, linked commits, PRs, and same-commit file changes for historical context, not for assigning fault.
+11. Stress hidden conditions deliberately when the repository has a configured or approved way to do so.
+   - Suspect time, randomness, and concurrency first for "sometimes" failures.
+   - Prefer fixed seeds, fake clocks, forced interleavings, latency injection, duplicate or reordered messages, worker kills, cache clears, slight time shifts, and concurrent requests over waiting for chance.
+   - Minimize production data into a safe fixture by removing unrelated rows or events until the trigger disappears, then restore the last removed condition.
+12. Inspect the source that controls the reproduced behavior and gather the smallest observation needed to choose between hypotheses.
+13. If temporary instrumentation is needed, give every probe a unique marker, keep it local to the suspect boundary, and remove it before final verification unless the user explicitly wants durable diagnostics.
+14. Apply the smallest fix that addresses the reproduced or instrumented cause. Keep behavior-preserving cleanup, characterization tests, bug fixes, and long-term refactors separate when the codebase is legacy or high-risk.
+15. Re-run the original reproduction path after the fix. If that path is unavailable or too broad, run the closest configured intent and report the limitation.
+16. For unreproducible fixes, define the "fixed" metric before claiming success: failure rate, invariant violation count, duplicate handling count, retry exhaustion count, DLQ growth, timeout rate, latency tail, or another symptom-specific measure.
+17. Add or keep a regression guard only when it is tied to the reproduced symptom, the instrumented invariant, or a directly observed boundary condition.
+18. Report the symptom, reproduction, hypotheses considered, observations, evidence packet, fix, original reproduction rerun, checks, and remaining risk.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -95,6 +122,10 @@ This skill keeps debugging anchored to symptom evidence, deterministic reproduct
 - The final report distinguishes reproduced evidence from assumptions.
 - Any added test or reproduction note is tied to the reported failure, not to general coverage growth.
 - Cause hypotheses are confirmed, rejected, or left explicitly unresolved instead of being implied by a passing broad check.
+- Symptom-cover patches are rejected unless they repair the named invariant and survive relevant counterexamples.
+- Trace, log, profiler, breakpoint, DB, cache, and dependency evidence is correlated by stable identifiers when that evidence exists.
+- Unreproducible defects are handled with next-failure evidence capture, state snapshots, bounded event trails, impossible-state monitors, and pre-declared fix metrics rather than a speculative local patch.
+- Legacy-code investigations start from symptom exits, writers, stable strings, data flow, history, and code-outside-code surfaces before broad call-graph reading or cleanup.
 - Temporary instrumentation and debug output are removed before final verification unless intentionally retained.
 - Missing command intents, unavailable tools, or unsafe reproduction requirements are reported instead of hidden.
 
@@ -125,6 +156,8 @@ Prefer the original failing intent when it is narrower than the defaults above.
 - Symptom and expected behavior
 - Reproduction path or reproduction gap
 - Hypotheses considered and observations
+- Diagnostic evidence packet and counterexamples considered
+- State snapshot, next-failure capture, last-good or first-failed window, symptom split, and legacy narrowing evidence where relevant
 - Probable cause, confidence, and evidence
 - Fix applied
 - Original reproduction rerun result

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

@@ -790,7 +790,7 @@ applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_
 category = "data_external"
 route_type = "primary"
 priority = 75
-applies_to_reasons = ["code_change", "docs_change", "security_change", "package_metadata_change", "release_risk"]
+applies_to_reasons = ["code_change", "docs_change", "security_change", "package_metadata_change", "release_risk", "unknown_change"]
 
 [routes."dependency-reality-check"]
 category = "data_external"
@@ -814,7 +814,7 @@ applies_to_reasons = ["code_change", "public_api_change", "test_change", "docs_c
 category = "data_external"
 route_type = "adjunct"
 priority = 65
-applies_to_reasons = ["code_change", "security_change", "migration_change"]
+applies_to_reasons = ["code_change", "security_change", "migration_change", "package_metadata_change", "release_risk"]
 
 [routes."adapter-boundary"]
 category = "data_external"
@@ -886,7 +886,7 @@ applies_to_reasons = ["test_change"]
 category = "security_privacy"
 route_type = "primary"
 priority = 30
-applies_to_reasons = ["security_change", "privacy_change"]
+applies_to_reasons = ["security_change", "privacy_change", "package_metadata_change", "release_risk", "unknown_change"]
 
 [routes."secret-exposure-response"]
 category = "security_privacy"
@@ -934,7 +934,7 @@ applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "publi
 category = "security_privacy"
 route_type = "adjunct"
 priority = 76
-applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "security_change", "privacy_change", "data_change", "test_change", "package_metadata_change", "release_risk"]
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "security_change", "privacy_change", "data_change", "test_change", "docs_change", "package_metadata_change", "release_risk", "unknown_change"]
 
 [routes."security-regression-tests"]
 category = "security_privacy"

package/templates/default/locales/en/.mustflow/skills/security-flow-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.security-flow-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: security-flow-review
-description: Apply this skill when code is created, changed, reviewed, or reported and security review needs source-to-sink tracing across authorization, object ownership, tenant scoping, IDOR or BOLA risk, mass assignment, admin-only surfaces, cache keys, exports, injection-like inputs, ORM raw paths, SSRF, file upload and extraction, path traversal, XSS, CSRF, OAuth, reset tokens, JWTs, cookies, cryptography, logs, fail-open error handling, async jobs, race conditions, or supply-chain and CI/CD paths.
+description: Apply this skill when code is created, changed, reviewed, or reported and security review needs source-to-sink tracing across authorization, object ownership, tenant scoping, IDOR or BOLA risk, mass assignment, admin-only surfaces, cache keys, exports, injection-like inputs, ORM raw paths, SSRF, file upload and extraction, path traversal, development server file serving, privileged test or browser UI APIs, XSS, CSRF, OAuth, reset tokens, JWTs, cookies, cryptography, logs, fail-open error handling, async jobs, race conditions, or supply-chain and CI/CD paths.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -42,7 +42,8 @@ changes, and where can data or authority leak?"
 
 - Code review, implementation, or report work touches routes, handlers, services, repositories,
   resolvers, jobs, workers, admin tools, exports, imports, caches, files, external fetchers,
-  OAuth callbacks, tokens, cookies, logs, CI workflows, package metadata, or dependency execution.
+  OAuth callbacks, tokens, cookies, logs, CI workflows, package metadata, development servers,
+  test UI servers, browser-mode tooling, preview servers, or dependency execution.
 - A feature accepts an identifier, URL, filename, path, HTML, Markdown, sort key, filter, field list,
   status, role, price, entitlement, tenant id, organization id, user id, or client-provided state.
 - The suspected issue may be BOLA, IDOR, missing authorization, tenant leak, mass assignment,
@@ -76,7 +77,8 @@ changes, and where can data or authority leak?"
 - Read and write surfaces: list, detail, count, export, download, search, stats, update, delete,
   approve, invite, upload, webhook, callback, job, and admin paths.
 - Framework or platform escape hatches: raw query APIs, shell wrappers, HTML escape bypasses, file
-  APIs, URL fetchers, parser options, cache behavior, token libraries, and CI/package lifecycle hooks.
+  APIs, URL fetchers, parser options, cache behavior, token libraries, development-server host and
+  filesystem policies, privileged test UI APIs, and CI/package lifecycle hooks.
 - Existing tests, denial cases, scanner findings, security docs, command intent entries, and any
   missing context that blocks a confident conclusion.
 
@@ -172,6 +174,11 @@ changes, and where can data or authority leak?"
     - Locale files, templates, themes, attachments, logs, static proxies, backup restore, plugin
       loaders, model loaders, and generated state all need real-path containment after symlinks and
       normalization.
+    - For framework file-serving and dev-server APIs, trace URL path, query string, raw path,
+      decoded path, normalized path, denied path, and final opened file as separate values. Windows
+      alternate data streams, device namespace prefixes, 8.3 short names, mixed separators, and
+      trailing dot or space aliases can make a lexical allow/deny check protect a different name
+      than the operating system opens.
 16. Trace browser-code execution contexts.
     - XSS can enter through Markdown, rich text, translations, email templates, chart labels, admin
       dashboards, CSV exports, hydration data, JSON-in-script blocks, and framework escape hatches.
@@ -213,6 +220,11 @@ changes, and where can data or authority leak?"
     - Dependency manifests, lockfiles, postinstall scripts, codegen, Docker base images, GitHub
       Actions permissions, workflow triggers, artifact upload, CI secrets, package publish identity,
       Terraform modules, Helm charts, and deployment scripts can execute or leak authority.
+    - Treat exposed dev servers and test UIs as execution surfaces when they can rerun tests, write
+      snapshots or source files, save attachments, read arbitrary files, or execute browser-mode
+      commands. Binding such a server to `0.0.0.0`, a LAN host, a tunnel, a container-published
+      port, or a remote workspace turns local convenience APIs into remote authority unless explicit
+      read-only, no-write, and no-exec gates are enforced.
 25. Convert the finding into the smallest defensive action.
     - Fix the owner closest to the sink when the boundary is clear.
     - If evidence is incomplete, report the exact unverified source, sink, actor, resource, tenant,
@@ -229,6 +241,8 @@ changes, and where can data or authority leak?"
   wording.
 - Security-sensitive caches, workers, queues, logs, tokens, files, browser renderers, and CI/CD paths
   are either checked or explicitly reported as outside the current evidence.
+- Development-server and test-UI file read, write, rerun, attachment, snapshot, and execute surfaces
+  are checked when the dependency, config, or scanner finding points at them.
 - Any concrete security bug fix has denial-case or invariant evidence, or the missing test surface is
   reported.
 
@@ -272,6 +286,7 @@ Prefer the narrowest configured test intent that proves the reviewed defensive b
 - Authorization and ownership notes
 - Input, file, network, browser, token, cookie, crypto, log, fail-open, async, race, cache, and
   supply-chain findings when relevant
+- Development-server and test-UI exposure findings when relevant
 - Fixes made or recommendation
 - Tests, denial cases, or invariant evidence
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/security-privacy-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.security-privacy-review
 locale: en
 canonical: true
-revision: 23
+revision: 24
 lifecycle: mustflow-owned
 authority: procedure
 name: security-privacy-review
-description: Apply this skill when code, configuration, docs, templates, logs, telemetry, traces, baggage, behavior analytics, core events, credentials, data flows, data residency policy, region or processing-location claims, AI-generated code, AI prompts outputs usage cost records budgets policies or cache keys, authentication, authorization, server-side permission checks, admin operations, audit logs, file uploads or downloads, signed URLs, API responses, cache policy, cache-as-authority decisions, claim or policy data, comparison or affiliate data, user-generated content, webhooks, job queues, search logs, analytics SaaS exports, external API call records, network calls, dependencies, runtime security patch policy, third-party terms or data-use promises, cryptography, secure transport, agent configuration, or release surfaces affect secrets, personal data, retention, access control, vendor disclosure, or external disclosure.
+description: Apply this skill when code, configuration, docs, templates, logs, telemetry, traces, baggage, behavior analytics, core events, credentials, data flows, data residency policy, region or processing-location claims, AI-generated code, AI prompts outputs usage cost records budgets policies or cache keys, authentication, authorization, server-side permission checks, admin operations, audit logs, file uploads or downloads, signed URLs, API responses, cache policy, cache-as-authority decisions, claim or policy data, comparison or affiliate data, user-generated content, webhooks, job queues, search logs, analytics SaaS exports, external API call records, network calls, dependencies, runtime security patch policy, vulnerability scanner advisories, development servers, test UI servers, third-party terms or data-use promises, cryptography, secure transport, agent configuration, or release surfaces affect secrets, personal data, retention, access control, vendor disclosure, or external disclosure.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -40,6 +40,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - A tool, platform, model provider, analytics service, observability vendor, authentication provider, file store, or automation service has data retention, data training, commercial-use, export, API-limit, account-suspension, or unilateral terms-change implications for user data or service continuity.
 - A cloud, database, file store, logging backend, analytics tool, support tool, payment system, or AI provider choice affects where customer content, personal data, backups, logs, prompts, usage metadata, billing metadata, or support-access data is stored or processed.
 - A runtime, framework, dependency, or platform choice affects supported-version policy, end-of-life exposure, security patch timing, scanner coverage, deployment smoke tests, or rollback expectations.
+- A development server, preview server, browser-mode test server, or local tool UI can serve files, expose an API, execute tests, write project files, or bind beyond localhost.
 - A change touches administrator operations such as publishing, slug or redirect changes, canonical or robots changes, SEO updates, filter definition updates, advertisement policy, cache purge, search reindexing, ranking refresh, role changes, or audit-log snapshots.
 - A change touches legal, policy, privacy, finance, health, comparison, ranking, price, eligibility, affiliate, or high-risk factual claims that need source, reviewer, jurisdiction, effective-date, or human-approval boundaries.
 - A change touches identity, consent, editorial, catalog, community, analytics, billing, messaging, or audit data ownership boundaries, including account deletion, anonymization, export, or retention behavior.
@@ -93,6 +94,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Data residency and processing-location policy, including home region, storage region, backup region, log region, analytics region, AI processing region, support-tool region, payment or tax data region, disaster-recovery replica region, deletion expectations, and whether provider system data is outside customer-content residency guarantees.
 - Data classification policy when available, including sensitive personal data, ordinary personal data, product usage data, public content, AI prompts or outputs, and which classes may enter logs, analytics, support tools, AI providers, or cross-region backups.
 - Runtime and dependency patch policy, including supported or LTS version requirement, end-of-life ban, lockfile expectation, vulnerability scan source, patch response target, smoke-test surface, canary or rollback route, and whether experimental runtime choices are kept off survival paths.
+- Development-tool exposure policy, including host binding, allowed network interfaces, file-serving roots, deny lists, privileged API flags, write or execute capabilities, token handling, and whether the tool is local-only or safe for shared networks.
 - Webhook and external-call record policy, including signature verification, processed-event deduplication, safe request hashes, redacted provider responses, unknown-result reconciliation, dead-letter retention, and whether raw payloads are needed or should be replaced by bounded metadata.
 - Public intake default policy, including whether verifiers, authenticators, authorizers, deduplication stores, idempotency stores, and normalizers are required by registration, explicit opt-in, or silently replaced by permissive defaults.
 - Attacker-controlled key and header limits for idempotency keys, webhook event ids, provider names, action names, replay ids, dedupe keys, request ids, and any in-memory map or queue keyed by public request data.
@@ -198,10 +200,12 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 35. For pinned action references, distinguish tag objects from the commit that implements the tag. Verify pinned SHAs against the action repository so scanner tooling does not report an imposter or non-member commit.
 36. For dependency scanner alerts, separate production dependency manifests from fixtures, examples, generated test repositories, and intentionally vulnerable samples. Narrow the scan scope before treating fixture-only alerts as product vulnerabilities.
     - For lockfile CVEs, inspect the manifest and lockfile together. Identify the direct parent that keeps the vulnerable transitive package in the graph, update the narrowest direct dependency or override needed to reach the fixed range, and confirm the vulnerable package version no longer appears in the resolved graph before claiming the alert is fixed.
+    - For advisories involving development tools such as Vite, Vitest UI, browser-mode test servers, Storybook, docs preview, asset servers, or framework dev servers, do not dismiss the issue merely because the package is a devDependency. Check whether scripts, docs, Docker, Codespaces, CI previews, tunnels, or config bind the server to a non-localhost host, widen file-serving roots, disable deny lists, or expose privileged read, write, rerun, snapshot, attachment, or execute APIs.
 37. For deployment settings, check debug mode, sample admin accounts, default credentials, public admin panels, open metrics endpoints, public storage, root container users, HTTPS enforcement, and exposed GraphQL or development consoles.
 38. For runtime and framework security updates, check that supported versions are documented, end-of-life versions are rejected, dependency locks exist where appropriate, security patches can be tested and deployed quickly, and rollback or redeploy can happen without manual dashboard memory. Do not treat a fashionable or high-performance runtime as safe unless the patch path is operationally credible.
+    - Treat advisory exploit preconditions as review inputs, not excuses. If the exploit requires Windows, NTFS alternate data streams, 8.3 short names, non-localhost binding, exposed QUIC or SSH clients, oversized public keys, malformed protocol frames, or misbehaving peers, search for those conditions before marking the alert irrelevant.
 39. For transport security, check HTTPS/TLS requirements, certificate validation, insecure HTTP downgrade paths, disabled verification flags, and whether sensitive traffic can bypass the secure channel.
-40. For cryptography, reject custom cryptography and tutorial-grade shortcuts. Check password hashing uses a password-hashing primitive such as bcrypt, scrypt, or Argon2id where supported by the project; random tokens use secure randomness; keys are separated from encrypted data; and weak hashes such as MD5, SHA-1, or bare SHA-256 are not used for password storage.
+40. For cryptography and security protocols, reject custom cryptography and tutorial-grade shortcuts. Check password hashing uses a password-hashing primitive such as bcrypt, scrypt, or Argon2id where supported by the project; random tokens use secure randomness; keys are separated from encrypted data; weak hashes such as MD5, SHA-1, or bare SHA-256 are not used for password storage; protocol parsers bound attacker-controlled key sizes, packet sizes, frame ordering, unsolicited responses, and panic or assertion paths.
 41. For policy engines, architecture linters, compliance validators, and generated governance gates, identify the canonical policy source and the canonical object identity before trusting a pass result.
     - Do not let repository-controlled advisory fields, nested duplicates, labels, components, owners, stages, tiers, or exemption fields override a trusted catalog, server-derived identity, or central registration.
     - When two fields can describe the same security decision, such as top-level and nested owner values, validate their consistency or choose the canonical source explicitly instead of reading the first convenient path.
@@ -276,6 +280,7 @@ Use a narrower configured test, build, or documentation intent when it better pr
 - Data residency, data classification, AI processing location, runtime patch, and hard-limit policy checked when relevant
 - Claim, comparison, affiliate, user-generated content, data-ownership, deletion, anonymization, export, and retention boundaries checked when relevant
 - Authorization, session, token, input, file, network, business-logic, dependency, cryptography, transport, deployment, scanner, and agent-tool boundaries checked
+- Development-server, test-UI, scanner-advisory, Windows filesystem, protocol parser, and dependency patchability boundaries checked when relevant
 - Permission exception and emergency-access boundaries checked when relevant
 - Redaction, omission, or wording changes made
 - Related security-regression test need

package/templates/default/locales/en/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: en
 canonical: true
-revision: 20
+revision: 21
 lifecycle: user-editable
 authority: binding
 ---
@@ -57,6 +57,11 @@ mustflow-managed details are under `.mustflow/`.
   and command specification.
 - Preferences in `.mustflow/config/preferences.toml` have lower priority than direct user
   instructions and existing project style.
+- If this repository is a child repository without its own `.mustflow/config/preferences.toml`,
+  inherit the nearest parent mustflow root's preferences as defaults. This includes `[git]`,
+  `[git.commit_message]`, `[release.versioning]`, verification, testing, language, reporting, and
+  other preference sections. Child-local preferences override parent preferences field by field.
+  Never inherit `.mustflow/config/commands.toml`; command authority remains repository-local.
 - When code, templates, schemas, CLI behavior, package metadata, user-visible docs, installation
   output, or tests change, check `[release.versioning]` in `.mustflow/config/preferences.toml`
   before the final report. Version files may be changed only according to those preferences:
@@ -115,6 +120,9 @@ mustflow-managed details are under `.mustflow/`.
   Follow the stricter rule.
 - When navigating to a nested repository, reread that repository's `AGENTS.md` and
   `.mustflow/config/*.toml` before editing.
+- If the nested repository has no local preferences file, apply the nearest parent mustflow
+  preferences as inherited defaults while still following the nested repository's `AGENTS.md` and
+  command contract.
 - In repository farms, prefer each child repository's own command contract for repository-owned
   commands. If the parent root intentionally orchestrates children, split parent-owned commands
   into repo-named fragments under `.mustflow/config/commands/`; use

package/templates/default/locales/es/AGENTS.md

@@ -41,6 +41,7 @@ Los detalles gestionados por mustflow se encuentran en `.mustflow/`.
 - Usa `mf doctor` o `mf doctor --json` para una revisión de salud de solo lectura antes de cambios amplios.  
 - `mf context --json` puede ayudar con orientación legible por máquina, pero no reemplaza las reglas ni la especificación de comandos.  
 - Las preferencias en `.mustflow/config/preferences.toml` tienen menor prioridad que las instrucciones directas del usuario y el estilo existente del proyecto.  
+- Si este repositorio es un repositorio hijo sin su propio `.mustflow/config/preferences.toml`, hereda como valores predeterminados las preferencias del mustflow root padre más cercano. Esto incluye `[git]`, `[git.commit_message]`, `[release.versioning]`, verification, testing, language, reporting y otras secciones de preferencias. Las preferencias locales del repositorio hijo sobrescriben las del padre campo por campo. No heredes nunca `.mustflow/config/commands.toml`; la autoridad de comandos sigue siendo local del repositorio.
 - Cuando cambies código, plantillas, esquemas, comportamiento de CLI, metadatos de paquete, documentación visible para usuarios, salida de instalación o pruebas, revisa `[release.versioning]` en `.mustflow/config/preferences.toml` antes del informe final. Los archivos de versión solo pueden modificarse según esas preferencias: aplica el aumento automático cuando `auto_bump = true` y `require_user_confirmation = false`; en caso contrario, sugiere el aumento o pide confirmación antes de editar según la configuración. No asumas que la fuente de versión es `package.json`; localiza la fuente propia del repositorio antes de sugerir o editar versiones.  
 - Los archivos de contexto en `.mustflow/context/` explican la dirección del proyecto y las convenciones del dominio. Trátalos como contexto específico de la tarea, no como sustituto de código, pruebas, comandos o instrucciones del usuario.  
 - Si existe `DESIGN.md`, léelo solo para tareas de interfaz, diseño visual, maquetación, tokens de diseño o accesibilidad. No crees un `DESIGN.md` si no existe.  
@@ -57,6 +58,7 @@ Los detalles gestionados por mustflow se encuentran en `.mustflow/`.
 - Si hay conflicto entre reglas de flujo, estilo, pruebas o comandos, sigue el `AGENTS.md` del repositorio hijo y `.mustflow/config/commands.toml`.  
 - Las reglas de seguridad sobre secretos, privacidad, comandos destructivos y rutas permitidas de edición son acumulativas. Aplica la regla más estricta.  
 - Al entrar en un repositorio anidado, vuelve a leer su `AGENTS.md` y `.mustflow/config/*.toml` antes de editar.  
+- Si el repositorio anidado no tiene un archivo local de preferences, aplica las preferences del mustflow padre más cercano como valores heredados mientras sigues obedeciendo el `AGENTS.md` y el command contract del repositorio anidado.
 - No edites fuera del repositorio hijo seleccionado salvo solicitud explícita.  
 
 ## Compatibilidad con Instrucciones del Host

package/templates/default/locales/fr/AGENTS.md

@@ -41,6 +41,7 @@ Les détails gérés par mustflow se trouvent dans `.mustflow/`.
 - Utiliser `mf doctor` ou `mf doctor --json` pour un contrôle de santé en lecture seule avant des changements importants.  
 - `mf context --json` peut aider pour une orientation lisible par machine, mais ne remplace pas les règles ni la spécification des commandes.  
 - Les préférences dans `.mustflow/config/preferences.toml` ont une priorité plus faible que les instructions utilisateur directes et que le style existant du projet.  
+- Si ce dépôt est un dépôt enfant sans son propre `.mustflow/config/preferences.toml`, hériter comme valeurs par défaut des préférences du mustflow root parent le plus proche. Cela inclut `[git]`, `[git.commit_message]`, `[release.versioning]`, verification, testing, language, reporting et les autres sections de préférences. Les préférences locales du dépôt enfant remplacent celles du parent champ par champ. Ne jamais hériter de `.mustflow/config/commands.toml` ; l’autorité de commande reste locale au dépôt.
 - Quand le code, les modèles, les schémas, le comportement CLI, les métadonnées du paquet, la documentation visible par l’utilisateur, la sortie d’installation ou les tests changent, vérifier `[release.versioning]` dans `.mustflow/config/preferences.toml` avant le rapport final.  
   Les fichiers de version ne peuvent être modifiés que selon ces préférences : appliquer un changement automatique quand `auto_bump = true` et `require_user_confirmation = false` ; sinon, suggérer le changement ou demander confirmation avant modification selon la configuration. Ne pas supposer que la source de version est `package.json` ; localiser la source de version propre au dépôt avant de suggérer ou d’éditer des versions.  
 - Les fichiers de contexte dans `.mustflow/context/` expliquent la direction du projet et les conventions du domaine. Les considérer comme un contexte spécifique à la tâche, pas comme un remplacement du code, des tests, des commandes ou des instructions utilisateur.  
@@ -58,6 +59,7 @@ Les détails gérés par mustflow se trouvent dans `.mustflow/`.
 - En cas de conflit entre les règles de flux, de style, de tests ou de commandes, suivre le `AGENTS.md` du dépôt enfant et `.mustflow/config/commands.toml`.  
 - Les règles de sécurité sur les secrets, la vie privée, les commandes destructrices et les chemins d’édition autorisés sont cumulatives. Appliquer la règle la plus stricte.  
 - Lors de la navigation vers un dépôt imbriqué, relire le `AGENTS.md` de ce dépôt et `.mustflow/config/*.toml` avant d’éditer.  
+- Si le dépôt imbriqué n’a pas de fichier preferences local, appliquer les preferences du mustflow parent le plus proche comme valeurs héritées tout en continuant de suivre le `AGENTS.md` et le command contract du dépôt imbriqué.
 - Ne pas éditer en dehors du dépôt enfant sélectionné, sauf demande explicite.  
 
 ## Compatibilité avec les instructions du host

package/templates/default/locales/hi/AGENTS.md

@@ -41,6 +41,7 @@ mustflow द्वारा प्रबंधित विवरण `.mustflow/
 - बड़े बदलावों से पहले read-only स्वास्थ्य जांच के लिए `mf doctor` या `mf doctor --json` चलाएं।  
 - `mf context --json` मशीन-पठनीय आउटपुट दे सकता है, लेकिन यह नियम और कमांड विनिर्देशन का विकल्प नहीं है।  
 - `.mustflow/config/preferences.toml` की प्राथमिकता सीधे उपयोगकर्ता निर्देशों और मौजूदा परियोजना शैली से कम है।  
+- यदि यह repository ऐसी child repository है जिसके पास अपना `.mustflow/config/preferences.toml` नहीं है, तो निकटतम parent mustflow root की preferences को defaults के रूप में inherit करें। इसमें `[git]`, `[git.commit_message]`, `[release.versioning]`, verification, testing, language, reporting, और अन्य preference sections शामिल हैं। child-local preferences parent preferences को field-by-field override करती हैं। `.mustflow/config/commands.toml` को कभी inherit न करें; command authority repository-local command contract में ही रहती है।
 - code, templates, schemas, CLI व्यवहार, package metadata, user-visible docs, installation output, या tests बदलने पर अंतिम रिपोर्ट से पहले `.mustflow/config/preferences.toml` में `[release.versioning]` देखें। version files केवल उन्हीं preferences के अनुसार बदली जा सकती हैं: यदि `auto_bump = true` और `require_user_confirmation = false` हो तो automatic bump लागू करें; अन्यथा configuration के अनुसार bump सुझाएं या संपादन से पहले confirmation मांगें। version source को `package.json` मानकर न चलें; version suggest या edit करने से पहले repository-specific version source खोजें।  
 - `.mustflow/context/` की संदर्भ फाइलें परियोजना दिशा और डोमेन परंपराएं बताती हैं। इन्हें कार्य-विशिष्ट संदर्भ के रूप में लें, न कि कोड, परीक्षण, कमांड या उपयोगकर्ता निर्देशों के स्थान पर।  
 - यदि `DESIGN.md` मौजूद हो, तो उसे केवल UI, दृश्य डिज़ाइन, लेआउट, design token, या अभिगम्यता कार्य के लिए पढ़ें। यदि `DESIGN.md` नहीं है, तो नई फाइल न बनाएं।  
@@ -57,6 +58,7 @@ mustflow द्वारा प्रबंधित विवरण `.mustflow/
 - यदि कार्यप्रवाह, शैली, परीक्षण, या कमांड नियमों में टकराव हो, तो child रिपॉजिटरी के `AGENTS.md` और `.mustflow/config/commands.toml` का पालन करें।  
 - secrets, गोपनीयता, destructive commands, और अनुमत संपादन मार्गों के सुरक्षा नियम संचयी होते हैं। अधिक सख्त नियम अपनाएं।  
 - nested रिपॉजिटरी में जाने पर संपादन से पहले उसका `AGENTS.md` और `.mustflow/config/*.toml` फिर से पढ़ें।  
+- यदि nested repository में local preferences file नहीं है, तो nested repository के `AGENTS.md` और command contract का पालन करते हुए निकटतम parent mustflow preferences को inherited defaults के रूप में लागू करें।
 - स्पष्ट अनुरोध के बिना चुनी हुई child रिपॉजिटरी के बाहर संपादन न करें।  
 
 ## होस्ट-विशिष्ट निर्देश अनुकूलता

package/templates/default/locales/ko/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: ko
 canonical: false
-revision: 27
+revision: 28
 lifecycle: user-editable
 authority: binding
 ---
@@ -45,6 +45,7 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 - 수정 전 현재 mustflow 루트 상태와 다음 단계를 빠르게 확인하려면 `mf doctor` 또는 `mf doctor --json`을 사용합니다. 이 명령은 파일을 쓰지 않는 진단용 명령입니다.  
 - `mf context --json`은 읽기 전용 컨텍스트 확인 용도로 사용할 수 있으나, 실제 작업 규칙이나 명령 계약을 대체하지 않습니다.  
 - `.mustflow/config/preferences.toml`의 선호 설정은 사용자 직접 지시와 기존 파일 스타일보다 낮은 기본값으로 취급합니다.  
+- 이 저장소가 자체 `.mustflow/config/preferences.toml`이 없는 하위 저장소라면, 가장 가까운 상위 mustflow 루트의 선호 설정을 기본값으로 상속합니다. 여기에는 `[git]`, `[git.commit_message]`, `[release.versioning]`, verification, testing, language, reporting 및 기타 preference section이 포함됩니다. 하위 저장소의 로컬 preference 값은 상위 값을 field 단위로 덮어씁니다. `.mustflow/config/commands.toml`은 절대 상속하지 않습니다. 명령 실행 권한은 저장소별 command contract에 남아 있어야 합니다.
 - 코드, 템플릿, 스키마, CLI 동작, 패키지 메타데이터, 사용자에게 보이는 문서, 설치 출력, 테스트가 변경되면 최종 보고 전에 `.mustflow/config/preferences.toml`의 `[release.versioning]`을 확인합니다. 버전 파일은 해당 선호 설정에 따라서만 변경할 수 있습니다. `auto_bump = true`이고 `require_user_confirmation = false`이면 자동으로 버전 올림(버전 범프)을 적용하며, 그렇지 않으면 설정에 따라 버전 올림을 제안하거나 수정 전에 사용자 확인을 받습니다. 버전 기준 파일이 `package.json`이라고 가정하지 말고, 제안하거나 수정하기 전에 이 저장소에서 실제 기준으로 사용하는 버전 위치를 반드시 확인합니다.  
 - `.mustflow/context/` 파일은 프로젝트 방향과 도메인 약속을 설명하는 작업별 컨텍스트입니다. 코드, 테스트, 명령 계약, 사용자 지시를 대신하는 최종 기준으로 보지 않습니다.  
 - `DESIGN.md`가 있으면 UI, 시각 디자인, 레이아웃, 디자인 토큰, 접근성 작업에서만 읽습니다. 없는 `DESIGN.md`를 임의로 생성하지 않습니다.  
@@ -72,6 +73,7 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 - 작업 방식, 코드 스타일, 테스트 방식, 명령 실행 규칙이 충돌할 경우 하위 저장소의 `AGENTS.md`와 `.mustflow/config/commands.toml`을 우선합니다.  
 - 보안, 비밀 정보, 개인정보, 파괴적 명령, 수정 가능 경로 등 안전 규칙은 누적 적용하며 더 엄격한 규칙을 따릅니다.  
 - 상위 작업 공간에서 하위 저장소로 진입한 경우, 하위 저장소의 `AGENTS.md`와 `.mustflow/config/*.toml`을 다시 읽은 뒤 작업합니다.  
+- 하위 저장소에 로컬 preferences 파일이 없다면, 하위 저장소의 `AGENTS.md`와 command contract를 계속 따르면서 가장 가까운 상위 mustflow preferences를 상속 기본값으로 적용합니다.
 - repository farm에서는 각 하위 저장소가 소유한 명령은 해당 저장소의 command contract를 우선합니다. 상위 루트가 하위 저장소를 의도적으로 orchestration해야 한다면 상위 소유 명령을 `.mustflow/config/commands/` 아래 repo 이름별 fragment로 나누고, `mf workspace command-fragments`로 읽기 전용 안내를 확인합니다.  
 - 명시적 요청 없이 선택한 하위 저장소 밖의 파일은 수정하지 않습니다.
 

package/templates/default/locales/zh/AGENTS.md

@@ -40,6 +40,7 @@ authority: binding
 - 大范围修改前，应使用 `mf doctor` 或 `mf doctor --json` 进行只读健康检查。  
 - `mf context --json` 提供机器可读的方向信息，但不能替代规则和命令规范。  
 - `.mustflow/config/preferences.toml` 中的偏好优先级低于用户直接指令及项目既有风格。  
+- 如果本仓库是没有自己的 `.mustflow/config/preferences.toml` 的子仓库，则把最近的父级 mustflow 根目录中的 preferences 作为默认值继承。继承范围包括 `[git]`、`[git.commit_message]`、`[release.versioning]`、verification、testing、language、reporting 以及其他 preference section。子仓库本地 preference 按字段覆盖父级默认值。绝不要继承 `.mustflow/config/commands.toml`；命令权限仍然是仓库本地的 command contract。
 - 当代码、模板、schema、CLI 行为、包元数据、用户可见文档、安装输出或测试发生变更时，需在最终报告前检查 `.mustflow/config/preferences.toml` 中的 `[release.versioning]`。  
   版本文件只能按偏好修改：当 `auto_bump = true` 且 `require_user_confirmation = false` 时，自动升级版本；否则应按配置建议升级或编辑前请求确认。  
   不得假设版本来源为 `package.json`，应先定位仓库自身版本来源。  
@@ -58,6 +59,7 @@ authority: binding
 - 工作流、风格、测试或命令规则冲突时，遵循子仓库的 `AGENTS.md` 和 `.mustflow/config/commands.toml`。  
 - 针对 secrets、隐私、破坏性命令和允许编辑路径的安全规则为累加，执行更严格的规则。  
 - 进入嵌套仓库时，编辑前应重新阅读该仓库的 `AGENTS.md` 和 `.mustflow/config/*.toml`。  
+- 如果嵌套仓库没有本地 preferences 文件，在继续遵循该仓库 `AGENTS.md` 和 command contract 的同时，使用最近父级 mustflow preferences 作为继承默认值。
 - 未经明确请求，不得编辑所选子仓库之外的内容。  
 
 ## 宿主专用指令兼容性

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.112.10"
+version = "2.112.13"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"