mustflow 1.15.97

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

@@ -0,0 +1,159 @@
+---
+mustflow_doc: skill.structure-discovery-gate
+locale: en
+canonical: true
+revision: 12
+lifecycle: mustflow-owned
+authority: procedure
+name: structure-discovery-gate
+description: Apply this skill before introducing new feature structure, folders, file boundaries, routing, data models, or integration boundaries.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.structure-discovery-gate
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Structure Discovery Gate
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Find hidden structure decisions before coding so new files, folders, names, routing, data models, and integration boundaries reduce future change cost instead of producing a neat but brittle tree.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The task asks for a new feature, module, folder layout, architecture, scaffold, refactor, API integration, website, app flow, routing structure, data model, state model, or file split.
+- A named technology or service may be only an implementation choice rather than the product domain, such as AdSense, Stripe, Supabase, Firebase, Resend, SendGrid, Google Analytics, Plausible, or a CMS.
+- The request may hide costly structural decisions around localization, SEO, authentication, authorization, payments, ads, analytics, admin workflows, deployment, content management, storage, retention, or external service replacement.
+- The agent is about to create new top-level folders, shared modules, providers, adapters, services, constants, or public names.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a tiny mechanical edit with an obvious target file and no new boundary.
+- The user explicitly asks for a disposable prototype, spike, or one-off example where future structure is out of scope.
+- A structure decision has already been made in current project instructions, accepted design docs, or the immediately preceding user answer.
+- The task is only to match an existing local pattern; use `pattern-scout` unless hidden product assumptions may still change the shape.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User request and intended product or code change.
+- Current project instructions, relevant context, and nearby implementation patterns when available.
+- Known target platform, language, framework, package, or deployment constraints.
+- Any named external services, content sources, user roles, locales, data stores, algorithms, policies, feature flags, or revenue surfaces in the request.
+- Risk surfaces that could require a plan/apply gate, capability object, Result or Option return shape, command execution unit, facade entry point, invariant policy, state machine, pure core with an imperative shell, dependency injection boundary, adapter boundary, composition over inheritance, injected clock, state transition table, or idempotency ledger.
+- Optional collaborators whose absence might require a null object, disabled implementation, identity implementation, deny-all policy, or explicit failure.
+- Relevant command-intent contract entries for later verification.
+
+<!-- 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 from current context or can be stated as unknown without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Use this skill to shape the plan, questions, assumptions, file boundaries, and the smallest resulting implementation.
+- Edit only files needed for the accepted or reasonably assumed structure.
+- Do not create broad design documents, policy files, shared folders, provider systems, or abstractions just because they sound tidy.
+- Do not treat this skill as permission to delay every task for a long interview; ask only questions that can change the structure.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Restate the requested change as the product capability or code responsibility, not just the named technology.
+2. Identify hidden decisions that could change routing, folder names, file boundaries, data model, state ownership, environment variables, tests, deployment, SEO, localization, external integrations, or legal and policy requirements.
+3. Classify each decision:
+   - Blocking: the answer can change the basic structure and cannot be safely assumed.
+   - Structure-impacting: the answer changes boundaries, but a conservative default can be stated if the user does not answer.
+   - Preference: the answer affects styling, wording, or minor details and should not block structure.
+4. Ask at most five high-value questions before coding. Prioritize localization, authentication, authorization, payments, ads, personal data, destructive data actions, admin workflows, SEO, content storage, and external service replacement.
+5. For any question not asked, state the default assumption briefly. Defaults should keep future changes possible without adding speculative layers.
+6. Select structure patterns only when the task's risk shape requires them:
+   - Use a plan/apply gate for destructive, bulk, migration, billing, permission, publishing, or external-send operations that need review before execution.
+   - Use a capability object when a function should require a specific granted action instead of reading broad user or role state.
+   - Use Result and Option values for expected business failures, meaningful absence, not found, invalid input, denied access, stale state, or blocked policy. Use `result-option` before editing that return-shape contract.
+   - Use a Null Object only when an optional collaborator can safely implement the same interface with honest neutral behavior and the caller should not branch on presence. Use `null-object-pattern` before editing that optional dependency boundary.
+   - Use a command pattern when a state-changing user or system intent needs explicit payload, context, authorization, transaction, idempotency, outbox, audit, retry, concurrency, or queue and worker reuse. Use `command-pattern` before editing that execution unit.
+   - Use a facade pattern when controllers, handlers, workers, command handlers, services, or UI events need one stable high-level entry point over a repeated multi-step subsystem workflow. Use `facade-pattern` before editing that entry point.
+   - Use invariant policy modules when a state change must preserve non-negotiable rules, such as last-owner, paid-order, refund, or entitlement constraints.
+   - Use a state machine when status, state, phase, step, or stage controls allowed events, terminal states, guards, effects, transition history, duplicate-event handling, or concurrency. Use `state-machine-pattern` before editing that lifecycle.
+   - Use a strategy pattern when several algorithms, policies, calculations, provider choices, feature-flag variants, or scoring methods share one purpose and should not keep branching inside the stable workflow. Use `strategy-pattern` before editing that strategy family.
+   - Use pure core with an imperative shell when business decisions, validation, authorization, pricing, eligibility, state transitions, domain events, or effect descriptions would otherwise be mixed with I/O, clocks, generated identifiers, randomness, environment reads, or framework objects.
+   - Use composition over inheritance when behavior varies by multiple dimensions, class inheritance is proposed for implementation reuse, or framework subclasses could stay thin by delegating to explicit collaborators.
+   - Use dependency injection when core logic would otherwise construct, import, resolve, or hide databases, SDKs, clocks, random generators, configuration, loggers, framework objects, filesystems, queues, AI clients, payment gateways, or email senders.
+   - Use an adapter boundary when external APIs, databases, model responses, webhooks, files, queues, caches, framework objects, or command output cross into internal logic or leave it.
+   - Inject time or a time context when expiration, scheduling, retries, leases, or rate windows affect behavior.
+   - Use explicit state transitions when three or more states have meaningful allowed moves.
+   - Use an action ledger or idempotency key when repeating a side effect would be harmful.
+7. Prefer the smallest local version of the selected pattern. Do not add a framework, base class, service locator, global event bus, broad repository layer, or abstract factory when a plain function, table, adapter, or narrow policy object is enough.
+8. Separate product domains from vendor implementations. Use broad names at the product boundary and specific names inside provider or adapter internals.
+   - Prefer `monetization/ads/providers/adsense` over top-level `adsense`.
+   - Prefer `payments/providers/stripe` over top-level `stripe`.
+   - Prefer `notifications/email/providers/resend` over top-level `resend`.
+   - Prefer `analytics/providers/google-analytics` over top-level `googleAnalytics`.
+9. Propose the smallest folder and file structure that follows the answers and assumptions. For each new file or folder, state its responsibility and what it must not contain.
+10. Check the structure against local precedent with `pattern-scout` when the repository already has a nearby pattern.
+11. If the selected structure changes expected failure, meaningful absence, thrown business errors, null returns, or public error mapping, use `result-option` before editing that scope.
+12. If the selected structure creates or repairs a state-changing execution unit, use `command-pattern` before editing that scope.
+13. If the selected structure introduces or repairs lifecycle state transitions, use `state-machine-pattern` before editing that scope.
+14. If the selected structure introduces interchangeable algorithms, policies, calculations, provider choices, or feature-flag variants, use `strategy-pattern` before editing that scope.
+15. If the selected structure introduces one high-level entry point over several subsystem collaborators, use `facade-pattern` before editing that scope.
+16. If the selected structure separates business decisions from execution, use `pure-core-imperative-shell` before editing that scope.
+17. If the selected structure introduces inheritance, base classes, protected state, or subclass variants, use `composition-over-inheritance` before editing that scope.
+18. If the selected structure introduces or repairs an external dependency boundary, use `dependency-injection` for construction and collaborator flow, and `adapter-boundary` for external data, protocol, error, timeout, retry, idempotency, security, and observability handling.
+19. Implement only after the questions, assumptions, structure, dependency direction, and verification surface are clear enough for the task size.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The final structure follows an explicit set of answers or assumptions.
+- Top-level names reflect product responsibilities rather than replaceable vendor names unless the vendor is the product itself.
+- New folders and files have clear responsibilities, non-responsibilities, and dependency direction.
+- Any skipped question, deferred decision, or intentionally narrow assumption is reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Also run narrower configured tests or builds required by the changed source, template, documentation, or public contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If too many structural unknowns remain, ask only the highest-impact blocking questions and report the assumptions that are unsafe to make.
+- If the user does not answer non-blocking questions, proceed with conservative defaults and keep the first implementation small.
+- If a vendor name has already leaked into broad public structure, either localize it inside a provider or report why renaming is out of scope.
+- If a proposed abstraction has only one known use and no likely replacement pressure, keep it close to the feature instead of moving it to shared code.
+- If this skill overlaps with `codebase-orientation`, use orientation to map the existing area first, then return to this skill for the structure decision.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Capability or responsibility being built
+- Blocking questions asked, or none
+- Structure-impacting assumptions
+- Proposed files and responsibilities
+- Dependency direction
+- Structural patterns selected or intentionally skipped
+- Local pattern used or reason no pattern applies
+- Command intents run
+- Skipped checks and remaining structure risk

package/templates/default/locales/en/.mustflow/skills/test-maintenance/SKILL.md

@@ -0,0 +1,122 @@
+---
+mustflow_doc: skill.test-maintenance
+locale: en
+canonical: true
+revision: 3
+lifecycle: mustflow-owned
+authority: procedure
+name: test-maintenance
+description: Apply this skill when adding, updating, removing, or auditing tests in response to changes to behavior, APIs, snapshots, compatibility, or bug fixes.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.test-maintenance
+  command_intents:
+    - test
+    - test_related
+    - test_audit
+    - snapshot_update
+    - lint
+    - build
+---
+
+# Test Maintenance
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep tests aligned with the current behavior contract.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Behavior is added, changed, removed, or deprecated.
+- A bug fix needs a regression test.
+- Existing tests may be stale, duplicated, too broad, or tied to removed implementation details.
+- Snapshot output has changed.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes prose or comments.
+- The repository lacks a configured test intent and the user has requested not to add tests.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User request
+- Current behavior contract
+- Changed or removed code path
+- Existing test style
+- `.mustflow/config/commands.toml`
+- `.mustflow/config/mustflow.toml` `[testing]`
+
+<!-- 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. Define the expected current behavior.
+2. Search for existing tests before introducing new ones.
+3. Classify affected tests:
+   - `active`: still validates current behavior
+   - `update_needed`: behavior changed
+   - `obsolete_candidate`: likely validates removed or irrelevant behavior
+   - `legacy_contract`: old behavior is intentionally preserved
+   - `flaky_or_environmental`: failure may depend on environment
+4. Add, update, remove, or report tests according to the classification.
+5. Do not reintroduce removed behavior solely because old tests expect it.
+6. Treat snapshot updates as manual unless `snapshot_update` is explicitly approved and configured.
+7. Keep tests deterministic and close to the behavior contract.
+
+<!-- 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:
+
+- `test`
+- `test_related`
+- `test_audit`
+- `snapshot_update` only with explicit approval
+- `lint`
+- `build`
+
+Do not infer missing test commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If tests fail, inspect the first relevant failure.
+- Do not delete or weaken tests merely to make validation pass.
+- If it is uncertain whether a test is stale, report it instead of deleting it.
+- If the test command is unavailable, report the missing intent.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Behavior contract being tested
+- Tests added
+- Tests updated
+- Tests removed, with reason
+- Stale test candidates
+- Command intents run
+- Skipped command intents and reasons
+- Remaining test risks

package/templates/default/locales/en/.mustflow/skills/ui-quality-gate/SKILL.md

@@ -0,0 +1,119 @@
+---
+mustflow_doc: skill.ui-quality-gate
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: ui-quality-gate
+description: Apply this skill when user-facing UI, dashboard, settings, navigation, form, copy, responsive layout, accessibility, or visual state changes are planned, edited, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.ui-quality-gate
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# UI Quality Gate
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep user-facing interfaces usable, minimal, responsive, and verifiable instead of drifting into decorative demos or brittle screenshots.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A change touches dashboard, settings, navigation, forms, tables, lists, tabs, buttons, empty states, tooltips, status messages, or user-facing copy.
+- A task asks for UI polish, layout, responsive behavior, accessibility, visual states, language switching, labels, or interaction feedback.
+- A report claims that UI text fits, controls are understandable, language updates apply, or a page renders correctly.
+- A change could add explanatory, marketing-like, decorative, duplicate, invented, or non-actionable UI content.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task changes only backend logic, CLI output, metadata, or documentation with no user-facing UI surface.
+- The task is only image asset conversion; use `web-asset-optimization` for that part.
+- The UI change cannot be rendered or inspected in the current environment; report the inspection gap instead of claiming visual verification.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The changed UI surface, user task, and expected interaction path.
+- Existing design patterns, labels, states, accessibility conventions, and localization rules in the same area.
+- Viewports, themes, languages, and state combinations that need inspection.
+- Relevant command-intent contract entries for status, diff, docs, build, 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, remove, or refine UI controls, labels, states, layout constraints, localization hooks, and accessibility attributes when they support the user's real task.
+- Remove decorative, explanatory, invented, or marketing-like UI content that does not help the user act on real data.
+- Prefer existing component patterns and stable dimensions over new visual systems.
+- Do not claim a UI is visually verified without an actual render, screenshot, DOM inspection, or clear reason that visual verification was unavailable.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Identify the real user task and the UI surface that supports it.
+2. Check nearby UI patterns before adding new layout, component, color, copy, or state conventions.
+3. Remove or avoid non-essential welcome text, feature summaries, decorative cards, fake metrics, marketing copy, and invented controls.
+4. Verify controls are understandable: icon buttons need accessible names or tooltips, destructive or state-changing actions need clear labels, and disabled states need a visible reason when useful.
+5. Check accessibility behavior before visual polish: native elements first, keyboard access, focus order and return, visible focus state, names for icon-only controls, form error linkage, live status announcements, reduced-motion handling, and sufficient contrast.
+6. Check localization-sensitive behavior: language switching, fallback text, placeholders, plural or formatted values, long translated labels, bidirectional text, logical spacing, and date, time, number, currency, or unit display where applicable.
+7. Check layout constraints: text should not overflow, overlap, resize fixed-format controls unexpectedly, or depend on viewport-width font scaling.
+8. Check state coverage: loading, empty, error, saved, changed, disabled, selected, focused, and language-switched states should update consistently where applicable.
+9. Inspect responsive and localization-sensitive surfaces when the change affects layout or translated text.
+10. Run the narrowest configured verification that covers the changed UI, documentation, package, or mustflow contract.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The UI supports the user's task without unnecessary explanatory or decorative surface.
+- Important controls, labels, states, layout constraints, and localization updates are checked or reported as unverified.
+- Final reports distinguish code-level verification from visual or interactive verification.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use a narrower configured test, build, browser, screenshot, or accessibility intent when it better proves the changed UI surface.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If visual inspection is unavailable, report the unverified viewport, state, or interaction instead of assuming it works.
+- If UI text overlaps, clips, or fails to update after a state or language change, fix the smallest owning component before adding broader layout changes.
+- If a requested UI element conflicts with repository UI minimalism rules, implement the smallest task-focused control and report the omitted decorative content.
+- If verification requires an interactive server or browser command not declared by the command contract, stop at that boundary and report the skipped check.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- UI surface reviewed
+- User task and states checked
+- Layout, keyboard, focus, accessibility, and localization checks
+- Decorative or unnecessary UI avoided or removed
+- Command intents run
+- Skipped visual checks and reasons
+- Remaining UI risk

package/templates/default/locales/en/.mustflow/skills/visual-review-artifact/SKILL.md

@@ -0,0 +1,127 @@
+---
+mustflow_doc: skill.visual-review-artifact
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: visual-review-artifact
+description: Apply this skill when a plan, suggestion, code explanation, or review result would be easier to inspect as a safe static HTML review artifact.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.visual-review-artifact
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Visual Review Artifact
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Create a safe, static HTML artifact when a dense plan, suggestion, code explanation, or review result needs visual structure for human inspection and decision-making.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- The user asks for a plan, idea comparison, implementation options, refactor proposal, code walkthrough, change review, or design comparison that would be hard to scan as plain text.
+- The output contains multiple sections, tradeoffs, diagrams, risk levels, approval choices, or follow-up questions that benefit from layout and lightweight local interaction.
+- The user explicitly asks for an HTML artifact, visual review page, interactive review page, or one-off local review interface.
+- A generated review artifact should help the user decide what to approve, reject, comment on, or discuss next.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- A short plain-text or Markdown answer is enough.
+- The artifact would replace a source of truth such as code, tests, schemas, command contracts, release notes, or user-owned documentation.
+- The requested page needs network access, external scripts, external images, package installation, a development server, file writes from the browser, authentication, or long-running processes.
+- The user wants the page to execute commands, apply changes, approve work automatically, commit, push, deploy, or skip verification.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User request, artifact goal, target audience, and whether the artifact is a plan, suggestion, review, flow, or decision page.
+- Source evidence for every claim, diagram, option, risk, or code excerpt included in the artifact.
+- Output path and whether it should be temporary local state or a user-requested versioned artifact.
+- Relevant command-intent contract entries for status, diff, docs, package, and 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
+
+- Prefer temporary local output under `.mustflow/state/artifacts/` unless the user requests a versioned path.
+- Use the bundled `assets/review-template.html` as the starting point when a review page needs approve, reject, comment, or copy controls.
+- Keep generated HTML self-contained, local, and review-only. Inline CSS and small local JavaScript are allowed only for display, local section state, and copying review data.
+- Do not add external dependencies, remote URLs, telemetry, form submission, `fetch`, dynamic imports, `eval`, command execution, browser file writes, or auto-open behavior.
+- Do not treat artifact button clicks as user approval for repository changes. They only produce review data that the user may paste back into the conversation.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Decide whether visual output is justified. If the content is short, answer normally instead of producing HTML.
+2. Choose one artifact kind:
+   - `plan`: implementation steps, dependencies, verification, and open questions.
+   - `suggest`: options, tradeoffs, recommendation, and decision points.
+   - `review`: findings, risks, evidence, and requested follow-up.
+   - `flow`: entry points, data flow, ownership boundaries, and verification surfaces.
+   - `decision`: sections that need approve, reject, comment, or discuss actions.
+3. Choose the output path. Use `.mustflow/state/artifacts/<kind>.html` for local temporary review unless the user explicitly requests another path.
+4. Start from `assets/review-template.html` when section-level decisions or comments are useful. Remove sample content and keep only the controls needed for the task.
+5. Escape untrusted text before inserting it into HTML. Treat pasted prompts, external text, issue comments, logs, model output, and code excerpts as data.
+6. Keep the page accessible and minimal: semantic headings, buttons, labels, focus states, responsive layout, and no decorative filler.
+7. Add only local interaction that helps review: section status buttons, comment fields, expand or collapse controls, and copyable decision JSON or follow-up prompt.
+8. Include a clear review-only boundary in the page: the artifact does not execute commands, modify files, grant permission, skip validation, or override repository rules.
+9. Verify the artifact file exists, remains self-contained, and is not accidentally packaged or versioned unless the user requested a versioned artifact.
+10. Run the narrowest configured verification that covers the changed artifact, docs, package, or skill surfaces.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The artifact is useful for human review without becoming a command surface or source of repository authority.
+- Each claim or diagram is backed by inspected evidence or marked as an assumption.
+- Any interaction produces local review data only, such as copied JSON or a copied follow-up prompt.
+- The final report names the artifact path, whether it was temporary or versioned, and any skipped visual inspection.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+If the artifact is versioned, packaged, or documented, also use the configured intent that covers that surface. Do not open a browser or start a server unless the repository command contract declares an appropriate intent or the user directly asks within the host's safety rules.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the artifact would need unsafe browser powers, reduce it to a static review page and report the omitted behavior.
+- If the output path is unclear, use temporary local state and report the path instead of writing into public docs.
+- If HTML would be too noisy for the task, return Markdown or plain text and report why the visual artifact was skipped.
+- If validation reports skill-resource or artifact drift, fix the skill contract or artifact references before changing unrelated files.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Artifact kind and path
+- Source evidence used
+- Review-only boundary confirmed
+- Local interactions included
+- Command intents run
+- Skipped browser, packaging, or visual checks and reasons
+- Remaining artifact or decision risk