mustflow 2.112.10 → 2.112.14

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/.mustflow/skills/vector-search-integrity-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.vector-search-integrity-review
 locale: en
 canonical: true
-revision: 2
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: vector-search-integrity-review
-description: Apply this skill when vector search, semantic search, RAG retrieval mechanics, embeddings, vector databases, ANN indexes, exact versus approximate search, filters, metadata payloads, namespaces, tenants, named vectors, hybrid search, reranking, recall, latency, quantization, HNSW, IVF, pgvector, Qdrant, Milvus, Weaviate, OpenSearch kNN, or retrieval golden-set behavior is created, changed, reviewed, or failing. Use rag-pipeline-triage first when a RAG failure is not yet localized to retrieval versus parsing, context assembly, prompt, generation, citation, or answerability.
+description: Apply this skill when vector search, semantic search, RAG retrieval mechanics, embeddings, vector databases, ANN indexes, exact versus approximate search, filters, metadata payloads, chunk text variants, namespaces, tenants, named vectors, hybrid search, reranking, recall, latency, quantization, HNSW, IVF, pgvector, Qdrant, Milvus, Weaviate, OpenSearch kNN, or retrieval golden-set behavior is created, changed, reviewed, or failing. Use rag-pipeline-triage first when a RAG failure is not yet localized to retrieval versus parsing, context assembly, prompt, generation, citation, or answerability.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -68,13 +68,16 @@ filters, reranking, and latency evidence all agree for the same query contract.
 - Retrieval symptom classification: ingestion missing, write not visible, wrong results, empty
   results, low recall, tenant leak, duplicate chunks, stale deletes, slow search, reranker drift, or
   generated answer drift.
-- Query contract ledger: query text or safe fixture id, embedding model and revision, preprocessing
-  version, vector dimension, vector norm, metric, collection, namespace, tenant, named vector,
-  filters, `top_k`, candidate count, consistency level, ANN parameters, hybrid weights, and reranker
-  settings.
-- Ingestion ledger: source id, chunk id, deterministic vector id, embedding version, payload shape,
-  write count, unique id count, direct lookup count, indexed count, deleted or tombstoned count, and
-  visibility lag.
+- Query contract ledger: query text or safe fixture id, query family, embedding model and revision,
+  preprocessing version, chunker version, contextual header policy, synthetic question policy,
+  vector dimension, vector norm, metric, collection, namespace, tenant, named vector, metadata
+  payload fields and types, ACL prefilter, filters, `top_k`, candidate count, consistency level,
+  ANN parameters, hybrid weights, MMR or fusion settings, and reranker settings.
+- Ingestion ledger: source id, stable doc id, chunk id, parent document genealogy, deterministic
+  vector id, original text hash, index text, prompt text, embedding text, contextual header, title,
+  heading path, document type, status, authority, aliases, exact keywords, synthetic questions,
+  embedding version, content hash, embedding hash, payload shape, write count, unique id count,
+  direct lookup count, indexed count, deleted or tombstoned count, and visibility lag.
 - Quality ledger: golden queries, expected ids, acceptable alternatives, exact-search result,
   ANN result, recall at k, MRR, empty rate, duplicate rate, filtered result count, and before/after
   comparison.
@@ -95,10 +98,12 @@ filters, reranking, and latency evidence all agree for the same query contract.
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
 
-- Add or tighten embedding versioning, preprocessing versioning, vector validation, deterministic
-  IDs, namespace or tenant selection, metadata indexes, filter construction, exact-search checks,
-  ANN parameters, reranker candidate counts, golden-set tests, metrics, docs, fixtures, and
-  retrieval contract tests.
+- Add or tighten embedding versioning, preprocessing and chunker versioning, vector validation,
+  deterministic IDs, contextual retrieval headers, synthetic question fields,
+  original/index/prompt/embedding text separation, namespace or tenant selection, metadata payload
+  field typing, metadata indexes, ACL prefilter construction, exact-search checks, ANN parameters,
+  hybrid score ledgers, RRF or MMR settings, reranker candidate counts, golden-set tests, metrics,
+  docs, fixtures, and retrieval contract tests.
 - Add focused synthetic fixtures that encode expected retrieval behavior, filtered retrieval,
   tenant separation, duplicate handling, and exact-versus-ANN comparison.
 - Do not change embedding models, rebuild large indexes, tune ANN parameters, disable filters, widen
@@ -116,38 +121,56 @@ filters, reranking, and latency evidence all agree for the same query contract.
    all-zero vectors, extreme norms, and model or preprocessing version mismatches.
 4. Keep embedding model identity exact. Model name alone is not enough; include revision, tokenizer,
    pooling, prefix policy, max length, HTML cleanup, chunking, and normalization.
-5. Compare exact search with approximate search on the same query and filter. If exact search is
+5. Separate original, index, prompt, and embedding text. Original text is the citation source,
+   index text may include titles, aliases, contextual retrieval summaries, and generated questions,
+   prompt text is the compact model payload, and embedding text is the vector input. Do not collapse
+   these fields unless the product intentionally accepts that tradeoff.
+6. Check chunk graph and recursive retrieval shape. Source ids, parent document ids, parent chunk
+   ids, previous and next chunk ids, section paths, summary layers, and contextual retrieval
+   headers should be available when small chunks need larger context for answer generation. Stable
+   ids must survive renames, storage moves, and reindex jobs so citations, deletes, feedback logs,
+   and eval sets keep the same lineage.
+7. Check chunk size and overlap as quality levers, not defaults. Tiny chunks that lose the subject,
+   huge chunks that average unrelated meanings, and large overlap that fills top-k with duplicates
+   each need separate recall and diversity evidence.
+8. Validate contextual headers and synthetic questions. Headers should disambiguate product,
+   version, document status, authority, section, and entity; synthetic questions should reflect real
+   user phrasing without being cited as original source. Keep original, enriched retrieval text, and
+   LLM-visible metadata distinct so search bait does not become generated evidence.
+9. Compare exact search with approximate search on the same query and filter. If exact search is
    wrong, stop tuning ANN and inspect embeddings, preprocessing, metric, payload, and expectations.
-6. Compare filter-free search, filter-only count, filtered exact search, and filtered ANN search.
+10. Compare filter-free search, filter-only count, filtered exact search, and filtered ANN search.
    Empty filtered results often mean filter construction, metadata typing, payload indexing, or
    post-filter candidate loss rather than bad embeddings.
-7. Confirm collection, namespace, tenant, alias, and named vector. Directly inspect the problem id
+11. Confirm collection, namespace, tenant, alias, and named vector. Directly inspect the problem id
    or safe synthetic id in the same search surface the app uses.
-8. Check deterministic upsert ids. Source id, chunk index, tenant, and embedding version should not
+12. Check deterministic upsert ids. Source id, chunk index, tenant, and embedding version should not
    accidentally duplicate chunks or overwrite all chunks with one id.
-9. Separate write success from search visibility. Check direct lookup, exact search, ANN search,
+13. Separate write success from search visibility. Check direct lookup, exact search, ANN search,
    indexed count, consistency, segment state, and visibility lag.
-10. Check deletes and updates. Deletion marks, tombstones, compaction, vacuum, stale segments, and
+14. Check deletes and updates. Deletion marks, tombstones, compaction, vacuum, stale segments, and
     old chunks can keep appearing after API success.
-11. Review metric and normalization. Cosine, dot product, and L2 are different contracts unless
+15. Review metric and normalization. Cosine, dot product, and L2 are different contracts unless
     the vectors are intentionally normalized and the index operator matches.
-12. Tune ANN only after the exact and filter contracts are correct. Evaluate recall and p95 latency
+16. Tune ANN only after the exact and filter contracts are correct. Evaluate recall and p95 latency
     across parameter sweeps instead of changing one value blindly.
-13. Treat build-time index parameters as recall ceilings. If search-time parameters cannot recover
+17. Treat build-time index parameters as recall ceilings. If search-time parameters cannot recover
     recall, the index may need rebuild policy, not a larger query knob.
-14. Review quantization and rescoring. Compare full-precision exact results with compressed-index
+18. Review quantization and rescoring. Compare full-precision exact results with compressed-index
     candidates and confirm enough candidates reach full-precision reranking.
-15. For hybrid search, store dense score, sparse or keyword score, normalized score, fusion method,
-    and final score. Do not add incompatible raw scores directly without a deliberate combiner.
-16. For reranking, record pre-rerank and post-rerank ids and ranks. If the right document never
+19. For hybrid search, store dense score, sparse or keyword score, normalized score, fusion method,
+    RRF or MMR settings when used, and final score. Do not add incompatible raw scores directly
+    without a deliberate combiner. Preserve exact product codes, API names, error codes, ticket IDs,
+    and dates in lexical fields instead of smoothing them into natural-language embedding text.
+20. For reranking, record pre-rerank and post-rerank ids and ranks. If the right document never
     enters the candidate set, the reranker cannot recover it.
-17. Avoid deep ANN pagination as a product contract. Use cursor, filters, grouping, or ordinary
+21. Avoid deep ANN pagination as a product contract. Use cursor, filters, grouping, or ordinary
     sorted indexes for deep browsing instead of pretending vector search has cheap random offsets.
-18. Split cold and warm latency, server search time and client wait, vector DB time and reranker
+22. Split cold and warm latency, server search time and client wait, vector DB time and reranker
     time, and single-query latency from concurrent load.
-19. Inspect shard, replica, segment, compaction, flush, indexing, memory, disk, and cache state when
+23. Inspect shard, replica, segment, compaction, flush, indexing, memory, disk, and cache state when
     p99 or intermittent quality varies across nodes.
-20. Add a golden-set gate when the project has a test surface. Include easy, hard, filtered,
+24. Add a golden-set gate when the project has a test surface. Include easy, hard, filtered,
     tenant-scoped, rare-name, synonym, short-query, long-query, and sparse-data cases.
 
 <!-- mustflow-section: postconditions -->
@@ -155,6 +178,10 @@ filters, reranking, and latency evidence all agree for the same query contract.
 
 - The retrieval symptom, query contract, ingestion contract, quality ledger, performance ledger, and
   privacy boundary are explicit.
+- Original/index/prompt/embedding text separation, stable source/doc/chunk ids, parent document
+  genealogy, payload field typing, ACL prefiltering, contextual headers, synthetic questions,
+  chunk graph, content hashes, embedding hashes, exact lexical safeguards, and hybrid or rerank
+  ledgers are explicit where relevant.
 - Exact search, ANN, filters, metadata, namespaces, tenants, named vectors, IDs, deletes, metric,
   normalization, quantization, hybrid search, reranking, shards, consistency, and latency are fixed
   or reported where relevant.
@@ -199,8 +226,8 @@ of inventing live diagnostics.
 - Vector search integrity reviewed
 - Retrieval symptom, query contract, ingestion ledger, quality ledger, performance ledger, and
   privacy boundary
-- Exact versus ANN, filter, metadata, namespace, tenant, id, delete, metric, normalization,
-  quantization, hybrid, reranker, shard, consistency, and latency findings
+- Exact versus ANN, filter, metadata, text-variant, namespace, tenant, id, delete, metric,
+  normalization, quantization, hybrid, MMR, reranker, shard, consistency, and latency findings
 - Fix applied or recommended
 - Evidence level: golden-set evidence, configured-test evidence, static review risk, manual-only,
   missing, or not applicable

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.14"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"