mustflow 1.15.97

package/templates/default/locales/zh/.mustflow/skills/null-object-pattern/SKILL.md

@@ -0,0 +1,196 @@
+---
+mustflow_doc: skill.null-object-pattern
+locale: zh
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: null-object-pattern
+description: Apply this skill when repeated null, undefined, None, or nil checks, optional dependencies, disabled integrations, no-op collaborators, identity processors, null loggers, null analytics, null caches, or optional notifications could be replaced by a safe neutral implementation of the same interface without hiding required failures, security checks, payments, persistence, file uploads, audit trails, or not-found results.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.null-object-pattern
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Null Object Pattern
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Replace repeated absence checks for optional collaborators with a same-interface object that performs an honest neutral behavior.
+
+Use this skill when "no collaborator" is a normal configured state and the caller should keep the same workflow whether the real implementation is present or not. A null object is not a way to hide failure. It is only valid when doing nothing, returning a cache miss, returning a skipped outcome, or returning the input unchanged is domain-correct.
+
+Null Object means "this optional thing is intentionally absent." It must never mean "a required thing failed, so pretend everything is fine."
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code repeatedly checks `null`, `undefined`, `None`, or `nil` before calling the same optional collaborator.
+- A logger, product analytics client, optional notification sender, optional webhook publisher, optional scheduler, optional metrics sink, or optional post-processor may be disabled without breaking the main operation.
+- A cache can be disabled while the source-of-truth lookup still works; the neutral cache behavior is always miss.
+- A post-processor, transformer, or policy can safely return the input unchanged or a true zero value.
+- A feature is explicitly disabled by configuration and the disabled behavior is a stable part of the system contract.
+- A strategy family needs a no-op, disabled, identity, empty, or zero policy implementation that is honest about what happened.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The missing collaborator is required for correctness, durability, security, money movement, legal traceability, or data integrity.
+- The area is payment, authentication, authorization, permission enforcement, persistence, file storage, audit logging, security event recording, or required external delivery.
+- The caller must know whether a value exists, a resource was found, or an operation actually happened; use `result-option` instead.
+- A dependency is missing because configuration is wrong or initialization failed; fail at startup or return a required-configuration error instead.
+- A repository lookup returns no user, order, file, subscription, entitlement, or domain entity; use `Option`, `Result`, or a local lookup result.
+- The null object would return a fake success, fake identifier, fake URL, fake saved row, fake paid transaction, fake permission grant, or fake sent message.
+- The implementation needs request-specific mutable state; use a fake, mock, spy, or real collaborator instead.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The collaborator or object whose absence is being modeled.
+- The repeated null checks, optional type, or disabled integration path being changed.
+- Whether absence is a normal configured state or a missing required dependency.
+- Whether the caller needs to know if the operation was performed, skipped, absent, denied, or failed.
+- The side effects involved, especially writes, payments, file storage, external sends, audit logs, and security checks.
+- Existing local interfaces, dependency injection, strategy, `Result`, `Option`, configuration, fake, mock, and test patterns.
+- Relevant command-intent contract entries for verification.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- The target absence satisfies all of these conditions:
+  - Absence is a normal state.
+  - Doing nothing or returning a neutral value is correct.
+  - The caller does not need to branch on presence.
+  - The neutral return value does not claim work was performed.
+  - No security, payment, storage, file-upload, audit, or required-delivery responsibility is hidden.
+  - The null object can satisfy the same interface contract as the real implementation.
+- If the caller must branch on absence, use `result-option`.
+- If concrete selection should happen at an assembly boundary, use `dependency-injection`.
+- If the neutral implementation is one variant in a family of interchangeable behavior, use `strategy-pattern`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add same-interface implementations named `Null*`, `Noop*`, `Disabled*`, `Identity*`, `Empty*`, `DenyAll*`, or `Failing*` when the name matches the behavior.
+- Replace nullable collaborator types with non-null interface types at call sites.
+- Move real-versus-neutral implementation selection to an assembly root, dependency-injection registration, factory, or module initialization boundary.
+- Return honest neutral outcomes such as skipped, disabled, cache miss, empty result, zero amount, or unchanged input.
+- Add tests for callability, neutral return values, no external side effects, caller behavior without presence checks, and no fake success.
+- Do not use null objects to swallow runtime exceptions, hide initialization failures, skip required persistence, bypass authorization, or forge successful side effects.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the absence.
+   - Normal optional collaborator: null object may be valid.
+   - Meaningful missing value: use `Option` or a local lookup result.
+   - Expected failure: use `Result`.
+   - Required dependency missing: fail at startup or return a required-configuration failure.
+   - Security default: use an explicit deny-all policy, not a permissive null object.
+2. Check the risk boundary.
+   - Reject null objects for payments, authentication, authorization, required persistence, file uploads, audit trails, legal logs, required notifications, and required provider calls.
+   - If the absence can lose data, lose money, grant access, skip accountability, or corrupt state, do not use this pattern.
+3. Define or reuse the interface first.
+   - The real object and the null object must implement the same consumer-facing contract.
+   - Do not add a special `doNothing` API that forces callers to branch again.
+4. Choose the honest neutral behavior.
+   - Optional notification disabled: return `skipped` or a local disabled outcome, not `sent`.
+   - Cache disabled: return miss, not a hit with `undefined`.
+   - Analytics disabled: no-op without per-call noise.
+   - Post-processor absent: return the input unchanged.
+   - Discount absent: return a true zero discount.
+   - Permission system unavailable: deny, fail closed, or fail startup; never allow by default.
+5. Name the implementation by what it does.
+   - Use `Null*` for object absence.
+   - Use `Noop*` when calls intentionally do nothing.
+   - Use `Disabled*` when configuration turns the feature off.
+   - Use `Identity*` when input is returned unchanged.
+   - Use `Empty*` for a true empty collection or empty domain result.
+   - Use `DenyAll*` for fail-closed security policy.
+   - Use `Failing*` when a required dependency is missing and should fail loudly.
+6. Remove nullable types from callers.
+   - Constructor or function dependencies should become the interface type, not `Interface | null` or an optional parameter.
+   - Callers should invoke the collaborator directly and should not contain presence checks for that collaborator.
+7. Select implementations at the assembly boundary.
+   - Choose the real implementation or the null object in bootstrap, dependency-injection registration, module setup, factory setup, or test setup.
+   - Do not make business services read configuration and construct their own null objects.
+8. Keep null objects stateless.
+   - Store no current user, request, file, transaction state, intermediate result, or call history.
+   - A stateless null object can usually be reused as a singleton.
+   - If call recording is needed, that object is a fake, mock, spy, or metrics tool, not the production null object.
+9. Do not swallow construction or runtime failures.
+   - Use a null object only when a feature is explicitly disabled.
+   - Do not catch a failed real implementation constructor and silently replace it with a null object.
+10. Keep persistence and serialization honest.
+    - Do not persist a null object instance.
+    - Persist configuration or domain facts such as `notificationsEnabled = false`.
+11. Add observability at the right level.
+    - It is acceptable to log once at startup or expose health/status that an optional feature is disabled.
+    - Do not make the null object emit a warning for every skipped call unless the local system explicitly requires it.
+12. Test the contract.
+    - Test that the null object can be called through the shared interface.
+    - Test the neutral return value.
+    - Test that no external collaborator is called.
+    - Test that the main caller works without a null check.
+    - Test that fake success is not returned.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Optional collaborator absence is represented by a same-interface neutral implementation.
+- Callers no longer carry nullable dependency types or repeated presence checks for the optional collaborator.
+- The neutral implementation does not fake success, forge identifiers, grant permission, skip required persistence, or hide required side effects.
+- Real versus neutral implementation selection is visible at an assembly or configuration boundary.
+- Tests cover callability, neutral return values, no side effects, caller behavior, and no fake success.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `test_related`
+- `test`
+- `lint`
+- `build`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer focused tests for the caller whose nullable dependency was removed and for the neutral implementation. Use release or documentation checks when templates, public docs, package metadata, skill routes, or installed-file surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the neutral object would hide a required failure, stop and use startup validation, `Result`, `Option`, `DenyAll*`, or `Failing*` instead.
+- If the caller still needs to know whether work happened, return an explicit skipped or disabled outcome rather than pretending success.
+- If the local interface cannot support an honest neutral implementation, redesign the interface or keep explicit `Result`/`Option` handling.
+- If a null object was introduced to recover from an exception, remove the fallback and expose the initialization or configuration failure.
+- If a null object grows mutable state or call history, split that behavior into a test fake, mock, spy, or metrics decorator.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Absence classified as optional, meaningful absence, expected failure, required dependency, or security default
+- Null Object used or deliberately rejected
+- Interface and neutral implementation added or reused
+- Assembly or configuration boundary used for selection
+- Nullable caller types or checks removed
+- Result, Option, Strategy, Dependency Injection, or Adapter boundaries used with this skill
+- Tests or verification evidence
+- Skipped checks and remaining hidden-failure risk

package/templates/default/locales/zh/.mustflow/skills/pattern-scout/SKILL.md

@@ -0,0 +1,110 @@
+---
+mustflow_doc: skill.pattern-scout
+locale: zh
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: pattern-scout
+description: Apply this skill before implementing in an unfamiliar area where an existing local pattern may already solve the shape of the change.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.pattern-scout
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - mustflow_check
+---
+
+# Pattern Scout
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Find the closest local implementation pattern before creating new structure, naming, data flow, tests, or documentation shape.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The task touches an unfamiliar module, command, UI pane, schema, template, skill, or documentation family.
+- A similar feature already appears to exist elsewhere in the repository.
+- A new abstraction, helper, file layout, or test style might be introduced without enough local evidence.
+- The change should fit established naming, localization, validation, or packaging conventions.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a tiny mechanical edit with an obvious surrounding pattern.
+- The user explicitly asks for a one-off experiment or prototype outside established structure.
+- The existing pattern is already known from the current task context and no new area is being touched.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User request and intended changed-file area.
+- Nearby files and at least one analogous implementation when available.
+- Relevant route, schema, template, test, or documentation examples.
+- Current changed-file list if work is already in progress.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Prefer read-only exploration before editing.
+- After choosing a pattern, edit only the files needed to apply that pattern to the requested change.
+- Add a new pattern only when no local pattern fits, and record why the new shape is necessary.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the change shape: command, UI pane, schema, template document, skill, test, documentation page, or other local category.
+2. Search for the nearest existing examples in that category and inspect enough surrounding code to understand ownership, naming, data flow, and verification style.
+3. Choose the closest pattern and list the files that define it. If multiple patterns conflict, choose the one nearest to the files being changed.
+4. Identify the parts that must stay aligned: file naming, frontmatter, schema keys, localization keys, test helper style, manifest entries, lock entries, or documentation routing.
+5. Implement by extending the chosen pattern instead of inventing a parallel shape.
+6. If the change intentionally differs from the closest pattern, state the reason in the final report.
+7. Use the smallest configured verification that covers the changed pattern.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The implementation follows a named local pattern or clearly documents why it diverges.
+- New files are connected to every existing registry, manifest, schema, localization, or docs surface used by that pattern.
+- The final report names the pattern evidence and any intentional deviation.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `mustflow_check`
+
+Also run any narrower configured test, build, or documentation intent required by the chosen pattern.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If no local pattern exists, report that this is a new pattern and keep the first version small.
+- If patterns conflict, prefer the one closest to the changed files and report the tradeoff.
+- If verification reveals missing registry or metadata alignment, fix the alignment before adding unrelated logic.
+- If the closest pattern appears stale or broken, do not copy the stale behavior silently; report it and choose a safer local precedent.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Change shape
+- Local pattern inspected
+- Pattern applied or reason for deviation
+- Registries, manifests, or docs kept aligned
+- Command intents run
+- Skipped checks and reasons

package/templates/default/locales/zh/.mustflow/skills/performance-budget-check/SKILL.md

@@ -0,0 +1,121 @@
+---
+mustflow_doc: skill.performance-budget-check
+locale: zh
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: performance-budget-check
+description: Apply this skill when performance budgets, bundle size, page weight, startup time, command duration, memory use, asset size, throughput, latency, benchmark output, or performance claims are planned, edited, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.performance-budget-check
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - build
+    - test_related
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Performance Budget Check
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep performance claims and budgets tied to declared thresholds, reproducible measurements, and explicit tradeoffs instead of guessing from local impressions.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task changes or reports performance budgets, bundle size, page weight, startup time, command duration, memory use, asset size, throughput, latency, search index size, build time, or benchmark output.
+- A change adds heavier dependencies, generated assets, static pages, search indexes, startup work, file scanning, command fan-out, or repeated process spawning.
+- A report claims that a path is faster, slower, lightweight, optimized, cached, parallelized, cheap, expensive, within budget, or over budget.
+- A failure or slowdown suggests that measurement scope, command selection, concurrency, caching, or generated output size needs review.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes wording and does not make a performance or size claim.
+- The number is only a local fixture or example with no budget or public reporting meaning.
+- The change is only image asset conversion; use `web-asset-optimization` for that asset pipeline and this skill only for budget reporting.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The performance surface, such as command, page, asset, bundle, startup path, query, build, or generated output.
+- The budget source, if one exists: repository config, documented threshold, user-provided limit, benchmark baseline, package metadata, or current command result.
+- Measurement method, environment boundary, warm or cold run expectation, and whether the result is deterministic, sampled, local-only, or approximate.
+- Relevant command-intent contract entries for status, diff, build, tests, docs, release, or mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten budget checks, measurement notes, thresholds, cache boundaries, dependency tradeoff notes, tests, docs, and reports tied to the changed performance surface.
+- Replace vague claims such as "fast" or "lightweight" with measured, bounded, or explicitly unverified wording.
+- Prefer existing configured command intents and repository-local measurement paths before adding new tools.
+- Do not invent thresholds, benchmark numbers, hardware assumptions, network conditions, or release-blocking budgets without a source of truth.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Identify the performance surface and whether the task affects runtime, build time, test time, docs generation, asset weight, package size, or user-facing load behavior.
+2. Find the budget source before changing thresholds or claims. If no budget exists, report that the work is budget-discovery or measurement-only.
+3. Check nearby code, docs, templates, tests, and command metadata for duplicated performance statements or stale thresholds.
+4. Classify the measurement as deterministic, sampled, local-only, externally dependent, or unmeasured.
+5. If the change adds dependencies, generated output, or repeated work, identify the likely cost path and whether an existing alternative is available.
+6. Keep claims conservative: state the command, input scope, and whether caching, warm runs, parallelism, or generated files influenced the result.
+7. If a budget is exceeded, report the affected surface, budget source, measured value or unavailable measurement, likely cause, and smallest follow-up.
+8. Run the narrowest configured verification that proves the changed performance, package, docs, or mustflow surface.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Performance claims have a budget source, measurement method, or explicit unverified status.
+- Thresholds and benchmark-facing docs, tests, package metadata, generated output notes, and command contracts are synchronized where they overlap.
+- Final reports separate measured evidence from estimates, local observations, and suggested follow-up work.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `build`
+- `test_related`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use a narrower configured benchmark, asset, build, docs, or test intent when it better proves the changed performance surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If no budget source exists, do not invent one. Report the missing source and keep the claim qualitative or measurement-only.
+- If a measurement depends on local hardware, cache state, network, registry state, or generated output from a previous run, state that boundary.
+- If verification is too slow or no configured command exists, report the missing or skipped intent instead of running an inferred command.
+- If a performance fix conflicts with correctness, security, accessibility, or data safety, preserve the stricter correctness boundary and report the tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Performance surface reviewed
+- Budget source or missing budget
+- Measurement method and boundary
+- Thresholds, claims, or metadata synchronized
+- Command intents run
+- Skipped measurements and reasons
+- Remaining performance risk

package/templates/default/locales/zh/.mustflow/skills/project-context-authoring/SKILL.md

@@ -0,0 +1,107 @@
+---
+mustflow_doc: skill.project-context-authoring
+locale: zh
+canonical: false
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: project-context-authoring
+description: Apply this skill when filling or maintaining `.mustflow/context/PROJECT.md` from repository-supported evidence.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.project-context-authoring
+  command_intents:
+    - mustflow_check
+---
+
+# Project Context Authoring
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep `.mustflow/context/PROJECT.md` useful as a compact agent briefing while preventing invented product direction, architecture, roadmap, or implementation promises.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.mustflow/context/PROJECT.md` is created, filled, corrected, or reorganized.
+- Project goals, non-goals, domain terms, invariants, validation notes, operational constraints, source-of-truth notes, or open questions need to be recorded for agents.
+- Public docs, manifests, tests, source files, or command contracts disagree and the context file needs to record the conflict.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only updates root `README.md`, `PROJECT.md`, `ROADMAP.md`, API docs, or user-facing documentation.
+- The user asks for speculative planning, product vision, or architecture design that is not supported by repository evidence.
+- A nearer project-specific context authoring procedure exists.
+- The change belongs in `AGENTS.md`, `.mustflow/config/commands.toml`, or `.mustflow/docs/agent-workflow.md` rather than low-authority project context.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Existing `.mustflow/context/PROJECT.md`.
+- `AGENTS.md` and `.mustflow/config/*.toml`.
+- Optional root `PROJECT.md`, `README.md`, `ROADMAP.md`, and `DESIGN.md` when present and relevant.
+- `REPO_MAP.md`, package manifests, existing docs, tests, CI files, and source files only as evidence, not as permission sources.
+- The current user request and any explicit source constraints.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep edits within the scope described by this skill, the user request, and the matching route in `.mustflow/skills/INDEX.md`.
+- Do not broaden command permission, invent project facts, or change unrelated workflow files.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Preserve existing human-written context unless current repository evidence clearly contradicts it.
+2. Start from the existing context file, then gather only the evidence needed for the requested context fields.
+3. Separate confirmed facts, assumptions, unknowns, and conflicts. Do not smooth over disagreements between docs, manifests, tests, source files, and command contracts.
+4. Keep the context concise. Prefer short bullets or short paragraphs over broad essays.
+5. Cover only supported fields: project summary, goals, non-goals, domain terms, risk areas, invariants, validation, operational constraints, source-of-truth and conflict notes, and open questions.
+6. Add optional architecture, persona, release, or coding-convention notes only when the repository provides direct evidence.
+7. Reference command intent names from `.mustflow/config/commands.toml` when describing validation. Do not convert package scripts, CI jobs, or manifest hints into runnable agent permission.
+8. Leave unknown fields unset or explicitly marked as unknown instead of inventing product goals, roadmap promises, domain rules, or implementation details.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The expected output can be produced with clear evidence, executed command intents, skipped checks, and remaining risks.
+- Any missing command intent, unknown input, or authority conflict is reported instead of hidden.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `mustflow_check`
+
+If the context update also changes public docs or command contracts, activate the matching skill and use its configured verification intents.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If evidence conflicts, record the conflict or open question instead of choosing one source silently.
+- If a needed source is missing, mark the claim unknown rather than filling the gap from model memory.
+- If validation fails because context text looks like command policy or file-edit prohibition, move that rule to the proper authority file or remove the unsupported claim.
+- If the context becomes too large, reduce detail to durable facts and source-of-truth notes.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Context fields updated
+- Evidence sources used
+- Confirmed facts added
+- Assumptions, unknowns, or conflicts recorded
+- Command intents run
+- Skipped command intents and reasons
+- Remaining context risks