mustflow 2.22.17 → 2.22.47

package/templates/default/locales/en/.mustflow/skills/rust-code-change/SKILL.md

@@ -0,0 +1,154 @@
+---
+mustflow_doc: skill.rust-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: rust-code-change
+description: Apply this skill when Rust source, Cargo metadata, features, traits, errors, ownership, async runtime, unsafe code, tests, examples, or public crate APIs are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.rust-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Rust Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and public crate boundaries while making a focused change. A Rust change is successful only when it clarifies ownership and contracts, not when it merely silences the borrow checker.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.rs`, `Cargo.toml`, `Cargo.lock`, workspace config, feature flags, public exports, traits, error types, tests, examples, benches, FFI, async runtime, or unsafe code change.
+- The task touches ownership, borrowing, lifetimes, `Clone`, `Arc`, `Mutex`, `unwrap`, or public crate compatibility.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Rust files are read-only context and no Rust surface changes.
+- A generated Rust file should be regenerated by a declared command rather than edited.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `Cargo.toml`, workspace manifests, lockfile policy, toolchain config, rustfmt, clippy, feature flags, docs.rs metadata, optional dependencies, and CI hints.
+- Relevant `src/lib.rs`, `src/main.rs`, modules, public re-exports, tests, examples, and docs examples.
+- Existing error handling convention and async runtime.
+- Public crate status, minimum supported Rust version, feature support policy, and downstream compatibility expectations when available.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine whether the change affects ownership flow, public API, feature gates, optional dependencies, error contract, async runtime, or unsafe invariants.
+- Read local patterns before adding traits, lifetimes, clones, locks, boxed errors, feature bounds, or `Send + Sync + 'static` constraints.
+- Treat `clone`, `Arc<Mutex<_>>`, explicit lifetimes, `'static`, `Box<dyn Error>`, `unwrap`, feature changes, and `unsafe` as suspicious until their contract impact is justified.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Prefer truthful ownership and borrowing over broad cloning.
+- Follow the crate's existing application-versus-library error convention.
+- Keep feature-gated code and public re-exports synchronized.
+- Touch unsafe code only with explicit invariants preserved in nearby comments.
+- Add feature, async, or unsafe verification notes when configured command intents are missing.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read Cargo metadata, features, optional dependencies, docs.rs metadata, toolchain config, public exports, relevant modules, and tests.
+2. Classify the change as ownership, API, error, feature, async, unsafe, dependency, or test-only.
+3. Resolve ownership problems in this order: identify the real owner, shrink borrow scopes, fix function signatures to accept references or slices when ownership is unnecessary, distinguish transfer from sharing, then consider clone or shared ownership only when the semantics require it.
+4. Before adding `clone`, verify it is a cheap handle clone such as `Arc`, `Rc`, or `Bytes`, a small intentional value clone, or a true independent ownership split. Reject large collection clones, loop clones, clone-then-borrow code, and whole-state clones made only to satisfy `spawn`.
+5. Before adding `Arc<Mutex<_>>`, verify multiple owners truly need shared mutable state. Keep critical sections short, document lock order when relevant, and do not hold a lock guard across `.await`, I/O, callbacks, or user code.
+6. Use explicit lifetimes only to describe real borrow relationships. Do not add `'static` or `T: 'static` to public APIs merely because an internal task boundary requires it.
+7. Use concrete error enums for library APIs when callers need to classify failures. Keep `Box<dyn Error>` mostly to binaries, examples, tests, prototypes, or explicitly opaque error policies.
+8. Avoid `unwrap` and vague `expect` in production paths. They are allowed only for tests, examples, startup policy, or invariants already proven by nearby code.
+9. If feature flags change, treat default features, no-default builds, all-features builds, optional dependency implicit features, public re-exports, docs examples, and feature-gated trait impls as compatibility surfaces. Features should be additive.
+10. Treat public re-exports, public dependency types, generic bounds, trait item sets, error enum variants, `#[non_exhaustive]`, and MSRV as public API. Tightened bounds, added required trait methods, removed re-exports, or changed error variants require compatibility review.
+11. Do not mix async runtimes. A Tokio crate should not casually gain `async-std` or runtime-specific APIs in library core. Do not call blocking I/O or CPU-heavy work in async paths without an established boundary such as async-native APIs, a blocking pool, or a dedicated worker.
+12. For async spawning, avoid leaking internal `Send + Sync + 'static` requirements into public APIs. Prefer owned task state, smaller spawn boundaries, local task structures, or caller-owned runtime decisions.
+13. Touch `unsafe` only when a safe design cannot express the required behavior. Every unsafe block needs a nearby `SAFETY:` explanation; every public `unsafe fn` needs `# Safety` docs. Keep unsafe scopes small and wrap them in safe abstractions only when callers have no hidden safety obligations.
+14. For FFI, keep Rust ABI types out of C boundaries. Use explicit ownership, `#[repr(C)]` where required, raw pointer plus length pairs, `CStr`/`CString`, RAII wrappers, null handling, panic boundaries, and documented thread-safety evidence before manual `Send` or `Sync`.
+15. Choose configured verification intents that cover format, lint, build, tests, feature combinations, docs, public API, unsafe, and FFI risk when available.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise the patch when any of these appear without strong local justification:
+
+- New large `clone()` calls, clone-then-borrow code, loop clones, or state clones used only to appease ownership errors.
+- New `Arc<Mutex<AppState>>`-style shared bags, locks held across `.await`, or async I/O resources shared mainly by mutex.
+- New public `'static`, `Send`, or `Sync` bounds that exist only because an internal task was spawned.
+- New public `Box<dyn Error>` in a library where callers need typed failures.
+- New production `unwrap` or vague `expect` on I/O, parse, environment, network, FFI, lock, or user input paths.
+- Feature changes that remove APIs, change type meaning, rename features, expose internal optional dependency names, or fail default/no-default/all-features reasoning.
+- Public dependency types, re-exports, trait bounds, trait methods, or error enum variants changed without semver review.
+- Async runtime mixing, blocking I/O in async paths, or runtime ownership moved into a library core without a clear boundary.
+- Unsafe blocks without `SAFETY:` comments, unsafe functions without `# Safety`, undocumented manual `Send`/`Sync`, or FFI that exposes Rust layout types across C ABI.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Ownership changes are intentional, not compiler appeasement.
+- Public API, features, optional dependencies, and error contracts are synchronized.
+- Async runtime ownership is preserved and blocking work is isolated.
+- Unsafe and FFI invariants are preserved or no unsafe code was touched.
+- Missing feature, semver, docs, unsafe, or FFI verification is reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report whether configured feature-combination, documentation, semver, Miri, sanitizer, and downstream-style verification exists when those surfaces change.
+
+When configured intents exist for these risks, prefer coverage equivalent to:
+
+- formatting and linting
+- workspace checks and tests
+- default, no-default, all-features, and relevant feature combinations
+- doctests and docs build for public crates
+- public API or semver compatibility checks for published crates
+- Miri or sanitizer-style checks for unsafe, raw pointer, FFI, or manual concurrency primitives
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If borrow-checker fixes produce broad clones or locks, revisit ownership boundaries before proceeding.
+- If feature-gated code cannot be verified, report the specific unverified feature surface.
+- If public API compatibility cannot be verified, report the exact exported symbols, trait bounds, feature gates, or errors at risk.
+- If async runtime or blocking boundaries are unclear, stop that part and inspect the runtime ownership before editing further.
+- If unsafe invariants are unclear, stop that part and request or inspect stronger evidence.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Ownership, feature, async, or unsafe impact
+- Public API or error impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Rust risk

package/templates/default/locales/en/.mustflow/skills/svelte-code-change/SKILL.md

@@ -0,0 +1,186 @@
+---
+mustflow_doc: skill.svelte-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: svelte-code-change
+description: Apply this skill when Svelte or SvelteKit components, routes, load functions, server actions, endpoints, stores, context, runes, SSR boundaries, server-only imports, accessibility warnings, or tests are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.svelte-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Svelte Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Svelte component reactivity, SvelteKit SSR/server/client boundaries, data secrecy, load/action/endpoint contracts, request-scoped state ownership, accessibility, and generated route behavior. Choose files by data boundary first, not by filename habit.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.svelte`, `+page`, `+layout`, `+page.server`, `+layout.server`, `+server`, load functions, form actions, endpoints, stores, context, runes, `$app` imports, `$lib/server`, hooks, route params, or Svelte tests change.
+- The task touches state management, SSR errors, browser APIs, forms, routing, progressive enhancement, request-local data, server-only imports, private/public environment variables, or Svelte 5 runes.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is plain CSS or HTML with no Svelte or SvelteKit behavior; use the relevant UI foundation skill.
+- The service code is framework-free and no Svelte boundary changes.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Package metadata, Svelte config, Vite config, TypeScript config, route segment files, hooks, app types, stores/runes/context, form schema, and tests.
+- Svelte version, route data source, secrecy, request scope, mutation type, serialization requirement, SSR/client boundary, browser dependency, and state owner.
+- Imports from `$lib/server`, `*.server.*`, `$env/static/private`, `$env/dynamic/private`, DB/filesystem/server SDK modules, cookies, auth headers, and `event.locals`.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- For route work, read the sibling `+layout`, `+page`, `+page.server`, and `+server` files as one boundary.
+- Classify every data access by origin, secrecy, request scope, mutation, browser dependency, and serialization before choosing a SvelteKit file.
+- Treat all route files as potentially server-executed until proven otherwise.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep secrets, private environment, database clients, and cookie-authenticated data in server-only files.
+- Use browser APIs only behind client-safe lifecycle or environment guards.
+- Keep state local unless shared ownership is justified.
+- Preserve form actions and progressive enhancement instead of replacing all forms with client-only fetch.
+- Use context for request-scoped component-tree sharing instead of module singletons.
+- Use `$derived` for computed display values and `$effect` only for browser-side effects and cleanup.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read route segment files, parent layouts, stores/runes/context, hooks, app types, and tests.
+2. Identify Svelte version and whether the code uses runes or legacy reactivity.
+3. Before choosing a file, classify every data access with: origin, secrecy, request scope, mutation, browser dependency, and serialization.
+4. If data requires DB, filesystem, private env, cookies, auth headers, `event.locals`, server SDKs, or request-local identity, keep it in server-only code: `+page.server`, `+layout.server`, `+server`, `hooks.server`, or `$lib/server`.
+5. If data is public and can be safely fetched by the browser without secrets, universal load is allowed.
+6. If the operation is a page form mutation, prefer `+page.server` actions over a custom JSON endpoint.
+7. If the operation is a public HTTP API, webhook, mobile API, stream, file response, or non-page endpoint, use `+server`.
+8. If the value is UI-only state such as modal open, selected tab, draft input, accordion state, hover state, or local editing state, keep it in component `$state` or local context.
+9. If a value is computed from reactive inputs, use `$derived`. Do not use `$effect` to copy or synchronize derived state.
+10. Use `$effect`, lifecycle hooks, event handlers, actions, or dynamic imports for browser-only APIs and browser-only libraries. Do not touch `window`, `document`, `localStorage`, `matchMedia`, canvas, or browser-only imports in SSR top-level code.
+11. Keep request-specific user/session/auth state out of module-level mutable variables, global stores, exported `$state`, and load/action side effects.
+12. Do not write to stores from load functions.
+13. Keep server load return values intentionally serializable and minimal. Do not pass secrets, raw sessions, tokens, hidden DB fields, or whole service responses to the browser.
+14. Prefer `$app/state` over legacy `$app/stores` in SvelteKit projects that use the newer SvelteKit state API.
+15. Do not hide SSR errors by disabling SSR unless the user explicitly accepts that product and architecture change.
+16. Treat accessibility compiler warnings as real findings unless a local false-positive reason is documented.
+
+<!-- mustflow-section: data-boundary-policy -->
+## Data Boundary Policy
+
+- Public route params and public query values may live in universal load until they drive private DB/API access.
+- Public external APIs and public CMS data may live in universal load only when the browser may call them directly without secrets.
+- DB, filesystem, private env, server SDKs, cookies, auth headers, sessions, and `event.locals` belong in server-only files.
+- User-specific data must be read server-side and narrowed before being serialized into `data`.
+- Page forms should use form actions by default.
+- External clients, webhooks, mobile apps, streaming responses, and custom HTTP responses belong in `+server`.
+- Browser-only values belong in component effects, event handlers, dynamic imports, or browser actions.
+
+<!-- mustflow-section: route-boundary-policy -->
+## Route Boundary Policy
+
+- `+page.ts` and `+layout.ts` are universal. They may run on the server and in the browser.
+- `+page.server.ts` and `+layout.server.ts` are for server-only page data.
+- `+page.server.ts` actions are for page-owned form mutations.
+- `+server.ts` is for HTTP endpoints, webhooks, non-page APIs, streams, files, and custom responses.
+- Do not create a JSON endpoint for a normal page form unless there is a non-page consumer.
+- Do not wrap server-only imports in browser guards. Fix the import graph.
+
+<!-- mustflow-section: runes-state-policy -->
+## Runes And State Policy
+
+- Use `$state` for local interactive UI state.
+- Use `$derived` for calculations from props, route data, page state, or local state.
+- Use `$effect` only for browser-side effects, subscriptions, DOM, canvas, analytics, third-party browser libraries, and cleanup.
+- Use stores for external streams or manual subscribe/unsubscribe interop, not ordinary component state.
+- Use context for parent-owned values shared down the component tree, especially request-scoped layout data.
+- Do not reassign reactive context objects after placing them in context; update their properties or pass getter functions when needed.
+
+<!-- mustflow-section: ssr-debug-policy -->
+## SSR Debug Policy
+
+When SSR breaks, inspect in this order:
+
+1. Private env imports.
+2. `$lib/server`, `*.server.*`, DB, filesystem, admin SDK, or server-only import chains.
+3. Request-local state stored in module singletons, stores, or exported `$state`.
+4. Browser API access at module top-level or during SSR render.
+5. Hydration mismatch from time, randomness, locale, timezone, localStorage, or browser-only initial state.
+6. Route-level SSR disabling only after the product accepts an SPA-like shell.
+
+<!-- mustflow-section: hard-bans -->
+## Hard Bans
+
+- Do not add route-level SSR disabling to fix `window is not defined`.
+- Do not move required first-render page data into lifecycle hooks or `$effect`.
+- Do not import `$lib/server`, `*.server.*`, private env modules, DB clients, filesystem, or admin SDKs from universal/client route files or shared client utilities.
+- Do not mutate module-scope variables, global stores, or exported `$state` with user/session/request data during SSR, load, or actions.
+- Do not use `$effect` to compute derived values.
+- Do not put browser-only library imports at top level when the package touches browser globals during import.
+- Do not serialize secrets, raw sessions, access tokens, hidden DB fields, or whole service responses through load data.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Server/client and SSR boundaries are explicit.
+- State owner and derived/effect behavior are clear.
+- Forms remain progressive unless intentionally changed.
+- Private data stays server-only and serialized data is intentionally minimal.
+- Request-scoped sharing uses load data, props, or context instead of module singletons.
+- Accessibility warnings are resolved or justified.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing Svelte check, SSR render, form action, or browser verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a browser API breaks SSR, move it to a client-safe boundary instead of disabling SSR by default.
+- If data source ownership is unclear, inspect route server files and hooks before editing.
+- If accessibility warnings require an ignore, include the specific reason in the code or report.
+- If server-only imports leak into universal/client files, move the boundary instead of adding runtime guards.
+- If request-local data is stored globally, move it to server load, actions, context, or persistent storage with user scoping.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- SSR/server/client and state notes
+- Form/action/accessibility impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Svelte risk

package/templates/default/locales/en/.mustflow/skills/tailwind-code-change/SKILL.md

@@ -0,0 +1,164 @@
+---
+mustflow_doc: skill.tailwind-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: tailwind-code-change
+description: Apply this skill when Tailwind classes, className composition, static class detection, theme tokens, variants, safelists, arbitrary values, Tailwind config, @theme, @apply, or Tailwind migration surfaces are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.tailwind-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Tailwind Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Tailwind static class detection, design tokens, bounded variants, responsive/state behavior, accessibility states, and production build output. Treat Tailwind utilities as build-time tokens, not runtime strings.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Tailwind `class`, `className`, `@apply`, `@theme`, config, source scanning, safelist, theme tokens, variants, arbitrary values, or component class composition change.
+- The task touches Tailwind v3/v4 migration, token addition, responsive modifiers, state modifiers, `clsx`/`cn`, CVA-style variant helpers, `@source`, or production CSS generation risk.
+- Component APIs accept status, tone, intent, size, column count, color, spacing, or class-related props that affect Tailwind utilities.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Styling is plain CSS without Tailwind utilities; use `css-code-change`.
+- Utility generation is UnoCSS, not Tailwind; use `unocss-code-change`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Tailwind version/config or CSS entry, content/source scanning rules, theme tokens, PostCSS/build config, class merge helpers, variant helpers, component patterns, and tests.
+- Existing design system vocabulary, token naming conventions, accessibility state patterns, and component prop APIs.
+- Any runtime source for visual values: props, CMS, database, tenant config, user input, API data, or external package markup.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Confirm how Tailwind detects source classes before changing class composition.
+- Identify whether the project is using Tailwind v3 config safelists or Tailwind v4 CSS source directives.
+- Identify tokens, variant helpers, and semantic visual states before adding arbitrary values or raw colors.
+- Confirm whether affected components are local one-offs, shared components, or public design-system surfaces.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Use full static class strings that the build can detect.
+- Use existing theme tokens before arbitrary values or raw colors.
+- Use static maps, component extraction, or variant helpers for finite repeated variants.
+- Use safelists only for finite class candidates that cannot appear in scanned source.
+- Use inline styles plus CSS variables for unbounded runtime values such as tenant, database, or user-provided colors.
+- Keep hover, focus-visible, disabled, aria/data, dark, and motion variants aligned with existing component behavior.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read Tailwind config or CSS entry, scanning rules, theme tokens, helpers, and nearby components.
+2. Classify the change: token, utility usage, dynamic variant, component extraction, responsive state, accessibility state, or migration.
+3. Treat every Tailwind class as a complete build-time token. Reject runtime interpolation, concatenation, array joins, or fragment assembly for utilities such as color, spacing, grid count, span, tone, or arbitrary values.
+4. For finite choices, use a static map with semantic keys and full class strings. Good keys describe UI meaning such as `danger`, `muted`, `compact`, or `featured`; bad keys store Tailwind fragments such as `red`, `600`, or `cols-3` for later assembly.
+5. Use a CVA-style variant helper only when a shared component has multiple variant axes, defaults, or compound variants. The helper must still contain full static class strings.
+6. Use safelists only as a last resort for finite candidates that cannot be present in source files. Tailwind v4 projects should express this through the project's CSS source policy; Tailwind v3 maintenance projects may use config safelists when that is the existing pattern. Do not safelist broad palettes or unbounded ranges to avoid fixing a bad component API.
+7. Use inline style plus a CSS variable bridge for unbounded runtime values from databases, APIs, tenants, CMS content, or user input. Do not try to mint Tailwind class names from unbounded values.
+8. Treat arbitrary values as escape hatches. Allow them for one-off asset alignment, complex grid templates, complex calculations, local CSS variable assignment, or values that cannot be expressed with regular utilities.
+9. Reject arbitrary raw colors in component markup, arbitrary spacing that approximates existing scale values, arbitrary container widths, arbitrary radius or shadow used as a hidden token, and repeated arbitrary values. Repeated values must be promoted to a semantic design token or component variant.
+10. Keep raw color literals in theme or token files only. Token names should describe purpose, not numeric value.
+11. Use `clsx` or `cn` only to combine complete class strings. Do not hide dynamic Tailwind string construction inside helper functions.
+12. Do not expose unrestricted class fragments through public component APIs. If a `className` passthrough exists, preserve internal layout-critical classes and prevent consumer props from becoming the source of required Tailwind generation.
+13. Do not extract a component only because a class list is long. Extract a component when structure, behavior, accessibility, and styling repeat together across files.
+14. Do not use `@apply` to hide long JSX or template class lists. Reserve `@apply` for third-party markup overrides, CSS-module boundaries, or template systems where component extraction is genuinely heavier.
+15. Use mobile-first responsive classes and include focus-visible or equivalent keyboard states for interactive elements.
+16. Check for conflicting utilities on one element, such as mutually exclusive display, spacing, text-size, or layout utilities.
+17. Choose configured verification intents that cover production build, lint, component tests, accessibility states, and visual risk when available.
+
+<!-- mustflow-section: generation-policy -->
+## Generation Policy
+
+- Tailwind classes must appear as complete static strings in scanned source, a static variant map, a CVA-style variant declaration, or an explicit finite safelist.
+- Dynamic visual state must be represented by exactly one of: static map entry, variant helper entry, explicit safelist entry, or CSS variable bridge.
+- Status, tone, intent, size, density, and column props are closed sets until proven otherwise. Model them as finite typed variants, not string fragments.
+- Production CSS is the contract. If a class only exists after runtime string construction, assume production CSS may omit it.
+
+<!-- mustflow-section: token-policy -->
+## Token Policy
+
+- Use existing tokens and approved utilities first.
+- Add a design token when a value repeats, has product meaning, appears in more than one component, supports theming, or has a designer-owned name.
+- Do not add value-named tokens such as pixel-width or random-color names. Name tokens by role, surface, status, container, spacing purpose, or component meaning.
+- Keep component markup free of raw hex, RGB, OKLCH, arbitrary color, and arbitrary shadow values unless the file is itself a token/theme definition.
+
+<!-- mustflow-section: review-rejection-criteria -->
+## Review Rejection Criteria
+
+Reject the change when:
+
+- A Tailwind utility is assembled from runtime fragments.
+- A raw color appears outside a token or theme file.
+- An arbitrary value appears without a narrow reason.
+- The same arbitrary value appears in more than one place.
+- A wrapper component exists only to hide a one-off class list.
+- `@apply` hides component-specific styling instead of handling a CSS boundary.
+- A public component exposes unconstrained Tailwind class fragments.
+- A safelist covers broad palettes, broad numeric ranges, or unknown runtime values.
+- Conflicting utilities are present on the same element.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- All generated utilities are visible to Tailwind's detector, a static map, a variant helper, or an intentional finite safelist.
+- Arbitrary values are rare, justified, and not repeated without token promotion.
+- Runtime visual values are constrained by semantic variants or bridged through CSS variables.
+- Interactive states include keyboard and disabled behavior where relevant.
+- Production-build class loss risk is checked or reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing production CSS or visual verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If production styling disappears, inspect dynamic class generation and source scanning first.
+- If arbitrary values accumulate, stop and consider whether the design token system is missing a token.
+- If helper utilities erase class visibility, rewrite to static maps or report the build risk.
+- If a component API requires arbitrary Tailwind fragments, narrow it to semantic variants or report the public API risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Class detection and token notes
+- Responsive and accessibility state notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Tailwind risk