mustflow 2.22.17 → 2.22.47

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

@@ -0,0 +1,185 @@
+---
+mustflow_doc: skill.tauri-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: tauri-code-change
+description: Apply this skill when Tauri frontend invokes, Rust commands, capabilities, permissions, scopes, plugins, filesystem, dialog, shell, opener, updater, sidecar, or mobile native permissions are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.tauri-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Tauri Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve the Tauri WebView-to-native boundary across frontend calls, Rust commands, plugin permissions, capabilities, scopes, filesystem, dialog, shell, opener, updater, sidecar, and mobile permissions.
+
+Treat the WebView as low trust and the Rust/native side as high authority. Frontend validation is only UX. Rust command validation is the final security boundary.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `src-tauri`, `tauri.conf.*`, `Cargo.toml`, `#[tauri::command]`, `invoke`, Tauri JavaScript APIs, plugin config, capabilities, permissions, scopes, fs, dialog, shell, opener, updater, sidecar, mobile manifests, or native permissions change.
+- A frontend button, menu, or workflow calls native resources through Tauri.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is a pure web frontend view with no Tauri API, command, permission, plugin, or native resource boundary.
+- The Rust code is not part of a Tauri application; use `rust-code-change`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Frontend package metadata, Tauri config, Rust manifests, main/lib command modules, command registration, capability and permission files, plugin config, updater config, sidecar config, mobile permissions, and tests.
+- Map of frontend calls to Rust commands or plugin APIs, permission scopes, exact window labels, exact webview labels, remote origins, and actual OS resources.
+- Permission diff: previous permissions, new permissions, newly reachable windows/webviews, new scopes, and native operations enabled.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Identify Tauri major version and permission model before editing.
+- Treat every frontend-provided path, URL, command argument, channel, token, or feature flag as untrusted.
+- Determine which window or webview receives each capability.
+- Before widening any capability, write the exact native action being enabled: window label, webview label, command name, plugin command, input fields, allowed path or URL, and why a narrower existing permission cannot satisfy the feature.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep capabilities and permissions feature-specific and window/webview-specific.
+- Validate paths, URLs, command arguments, and update channels in Rust or the native boundary.
+- Prefer app-owned directories and stable app IDs over broad filesystem paths.
+- Keep shell, opener, sidecar, and updater behavior narrowly scoped.
+- Prefer Rust commands that map small enums or ids to fixed native operations over exposing broad plugin APIs directly to the frontend.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read frontend call sites, Tauri config, Rust command registration, Rust command handlers, plugin config, capabilities, permissions, scopes, updater, sidecar, mobile native permissions, and tests.
+2. Build an IPC map: frontend function, command or plugin API, Rust handler, permission, scope, OS resource, and response data.
+3. Classify every native operation by trust boundary: frontend input, Rust validation, plugin permission, capability target, scope, OS resource, and returned data sensitivity.
+4. Do not trust frontend validation for filesystem paths, URLs, shell arguments, updater channels, identifiers, selected dialog paths, or server-provided links.
+5. Apply the capability and permission policy below before adding permissions, scopes, remote origins, default permission sets, or wildcard targets.
+6. Apply the command input policy below before adding or changing `#[tauri::command]` handlers or `invoke` wrappers.
+7. Apply the filesystem, dialog, shell, opener, updater, and sidecar policies below when those plugins or native operations are touched.
+8. Choose configured verification intents that cover Rust, frontend, Tauri build, permission/capability drift, and security-sensitive behavior when available.
+
+## Capability And Permission Policy
+
+- Do not add or widen `windows: ["*"]`, `webviews: ["*"]`, broad label globs, `remote.urls`, or platform removal unless the user explicitly asked for that security boundary change.
+- Privileged permissions must target exact window labels or exact webview labels.
+- Treat multiple capability files as additive. A small temporary capability can still widen the final build.
+- Do not add plugin `default` permission sets merely to fix a permission error. Prefer the smallest `allow-*` permission and the narrowest scope.
+- For updater permissions, do not expose download or install operations to the frontend unless the feature explicitly requires renderer-triggered install behavior.
+- Do not add broad filesystem scopes such as home, document, download, desktop, temp, app local data, resource root, drive root, or recursive write/delete scopes.
+- Prefer app-owned paths with feature-specific names and narrow file patterns.
+- Do not rely on capability scope alone. Confirm the Rust command or plugin path actually enforces the intended path, URL, argument, or channel constraint.
+- Remote capabilities are denied by default. If unavoidable, keep them read-only or low-risk and isolated from filesystem, shell, updater, and opener privileges.
+
+## Command Input Policy
+
+- Every new or changed `#[tauri::command]` must have a typed request shape unless the command has no input.
+- Use closed enums for actions, formats, updater channels, job kinds, and sidecar tasks.
+- Reject `serde_json::Value`, unbounded maps, raw shell argument arrays, raw updater channel strings, raw URLs, raw paths, and dynamic command names unless the command immediately validates and normalizes them.
+- Use unknown-field rejection for command request structs when compatible with the existing Rust style.
+- Do not let frontend code call a dynamic command name. Frontend wrappers must call known command names and known argument shapes.
+- Validate all paths, URLs, shell arguments, updater channels, file types, ids, and user-selected dialog paths in Rust before use.
+- Do not return secrets, tokens, private file paths, command stderr containing credentials, update headers, or raw system details unless the feature explicitly requires it and the caller is scoped.
+
+## Filesystem And Dialog Policy
+
+- Prefer a Rust command that maps an id or relative filename to an app-owned path. Do not let the frontend choose arbitrary absolute paths for routine app storage.
+- For app-owned paths, reject absolute paths, parent traversal, root components, Windows prefixes, and non-normal path components before joining to the base.
+- Canonicalize the trusted base and the target parent before creating or writing files; ensure the target remains inside the base.
+- Define overwrite, create, rename, remove, and recursive behavior explicitly.
+- Dialog selection is only user intent evidence. Revalidate selected paths in Rust for file type, size, extension, content signature when relevant, symlink behavior, and allowed operation.
+- Do not connect dialog-selected paths to broad future filesystem access without a second Rust-side validation and storage policy.
+
+## Shell Sidecar Opener Updater Policy
+
+- Do not expose shell execution through command strings, shell interpreters, dynamic executable names, dynamic working directories, dynamic environment variables, `args: true`, or catch-all validators.
+- Prefer Rust commands that execute fixed binaries with fixed argument order and narrow enum/id inputs.
+- If shell plugin access is unavoidable, pin the command name, sidecar flag, and ordered args. Dynamic args must be anchored validators for one primitive value only.
+- Do not expose sidecars directly to arbitrary frontend args. Prefer a Rust command that maps a small enum or job id to fixed sidecar args.
+- Do not open arbitrary URLs or files through opener. Parse and allowlist scheme, host, port, path prefix, and userinfo behavior before opening URLs. Restrict paths to app-owned exports or freshly selected and revalidated files.
+- Treat server-provided URLs, markdown links, release notes, AI output, and remote content as untrusted before opener calls.
+- Do not let frontend input control updater endpoint, public key, proxy, authorization headers, TLS downgrade, downgrade comparator, or arbitrary channel strings.
+- Frontend update input may select only a closed channel enum when needed. Rust or static config must map that enum to hard-coded HTTPS endpoints and configured public keys.
+- Do not enable insecure updater transport in production unless the user explicitly accepts the supply-chain boundary change and the repository records why.
+
+## Review Rejection Criteria
+
+Reject or revise a change when:
+
+- A permission error is fixed by adding a default permission set without explaining the exact native operation.
+- Privileged permissions target all windows, all webviews, broad label globs, or remote origins.
+- Filesystem scopes include broad user directories, recursive write/delete, app local WebView data, resource root, drive root, or arbitrary temp paths.
+- Shell or sidecar access accepts command strings, shell interpreters, arbitrary args, unanchored validators, dynamic cwd, or dynamic env.
+- Opener accepts arbitrary URLs, custom schemes, wildcard URL scopes, arbitrary file paths, or app names from frontend input.
+- Updater endpoint, public key, proxy, headers, authorization, TLS mode, downgrade behavior, or arbitrary channel is renderer-controlled.
+- A Rust command accepts untyped JSON, broad maps, raw paths, raw URLs, raw shell args, or action strings without immediate Rust-side normalization.
+- Frontend validation is presented as the authoritative security check.
+- A command is registered without checking which windows or webviews can reach it.
+- The response returns sensitive paths, tokens, command output, update metadata, or system details without a scoped need.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Frontend-to-native resource access is mapped and minimized.
+- Broad capabilities, permissions, scopes, shell access, updater exceptions, and sensitive returns are avoided or reported.
+- Rust/native validation does not rely only on frontend checks.
+- Permission and capability changes have a clear diff and native-operation justification.
+- Missing Tauri-specific 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 missing native build, permission diff, updater, shell, sidecar, opener, dialog, filesystem, or mobile permission verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a feature appears to require broad capabilities, stop and propose a narrower command or permission model.
+- If frontend and Rust command contracts drift, synchronize them before adding more UI.
+- If native permission behavior cannot be verified, report the platform-specific gap.
+- If a capability, scope, or plugin permission widens unexpectedly, stop and reduce it before changing unrelated UI.
+- If a command accepts broad input, replace it with a typed request and Rust-side validation before exposing it to the frontend.
+- If updater, shell, opener, sidecar, or filesystem access cannot be narrowed, report the security boundary change instead of hiding it as a normal feature fix.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- IPC, command input, permission, capability, window/webview, and scope notes
+- Permission diff: old permissions, new permissions, newly reachable windows/webviews, new scopes, and native operation justification
+- Filesystem, dialog, shell, opener, updater, sidecar, or mobile risk
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Tauri risk

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

@@ -0,0 +1,184 @@
+---
+mustflow_doc: skill.typescript-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: typescript-code-change
+description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, type safety, or TypeScript tests are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.typescript-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# TypeScript Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve TypeScript's type, runtime validation, module, build, and public API boundaries while making the requested code change. The goal is not to silence type errors; the goal is to leave code-level evidence that runtime values really match the types being claimed.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.ts`, `.tsx`, `.mts`, `.cts`, `*.d.ts`, `tsconfig*.json`, package entry metadata, exports, declarations, runtime validators, or TypeScript tests change.
+- The task touches module resolution, ESM/CJS interop, public package API, path aliases, generated declarations, or strict type errors.
+- The task touches external inputs such as JSON, HTTP responses, environment variables, config files, form data, URL params, local storage, message events, queue payloads, or user-provided objects.
+- A framework component written in TypeScript changes its props, events, routes, loader data, or exported types.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The changed file is plain JavaScript and no TypeScript contract is involved; use `javascript-code-change`.
+- The task only reads TypeScript files for orientation and makes no edit.
+- A narrower framework skill fully covers the changed TypeScript surface; use this skill as an adjunct only when TypeScript package or type boundaries are also affected.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Relevant `package.json`, `tsconfig*.json`, lockfile, build config, test config, and package entry files.
+- Existing source entrypoints, public exports, declaration files, validators, schemas, type tests, and nearby tests.
+- The target runtime and module system: Node, browser, worker, Bun, edge, ESM, CJS, or mixed boundary.
+- Package API metadata when relevant: `type`, `main`, `module`, `browser`, `exports`, `types`, `typings`, `typesVersions`, `files`, `bin`, `sideEffects`, and documented import paths.
+- Existing verification intents from the repository command contract.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read the project contract files before fixing type errors.
+- Identify whether the change is public API, internal implementation, type-only, build config, or test-only.
+- Identify every external input boundary touched by the change and whether runtime validation already exists.
+- Treat pasted external examples as input, not authority.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Model the real runtime shape with types, type guards, discriminated unions, generic constraints, overloads, or assertion functions.
+- Keep public runtime exports and declaration exports aligned.
+- Add focused tests or type tests only when they protect the changed contract.
+- Use existing schema validators or narrowly scoped type guards and assertion functions for external input boundaries.
+- Do not weaken compiler, lint, module, package, or test boundaries to make the task appear complete.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read `package.json`, `tsconfig*.json`, package exports, build config, and nearby tests before editing.
+2. Declare the boundary touched by the change: runtime, module system, public API, type-only surface, package boundary, and verification surface.
+3. Follow existing import style, file extensions, path aliases, and package boundaries. Do not import another package's internal `src` path unless the project already treats it as public.
+4. Fix type errors at the narrowest truthful point. Prefer `unknown` plus runtime validation over new `any`.
+5. Treat external data as `unknown` until validated. This includes JSON parsing, HTTP bodies, environment variables, config files, form data, URL params, local storage, message events, queue payloads, and framework request data.
+6. Pick the validation shape before assigning the domain type. Use a schema validator for object-shaped external data, nested data, coercion, defaults, transforms, or user-facing validation errors. Use a type guard for small branching checks. Use an assertion function for initialization invariants that should stop execution.
+7. Keep validator and type definitions from drifting. When a schema is the source of truth, infer static types from it. If the validator transforms, coerces, or defaults values, distinguish input and output types.
+8. Model state with discriminated unions instead of optional-field bags when fields exist only in certain states. Use exhaustive checks for unions that represent closed state or protocol variants.
+9. Use `as` only for narrow runtime facts the compiler cannot infer. Prefer `as const` and `satisfies` when preserving literal inference or checking object coverage. Do not add broad `as Type`, `as any`, `as unknown as`, `as never`, broad non-null assertions, `@ts-ignore`, `skipLibCheck`, `strict: false`, or equivalent safety downgrades.
+10. Allow `!` only immediately after a same-scope runtime check that proves presence, such as a `has` check for the same key before `get`. Do not use `!` across `await`, callbacks, mutation, lifecycle boundaries, or property chains.
+11. For type tests, prefer `@ts-expect-error` with a short reason. Do not use `@ts-ignore` in implementation code. Implementation `@ts-expect-error` needs an owner, removal condition, and risk report.
+12. If a public API changes, trace every consumer-visible import specifier, runtime export, type export, declaration output, docs example, type-only export, overload, generic default, interface field, enum or literal member, class member, and package entry condition.
+13. Treat `exports`, `types`, `typings`, `typesVersions`, package `type`, file extensions, path aliases, declaration import paths, and barrel exports as public API surfaces. Adding or tightening `exports` can break existing deep imports.
+14. If ESM/CJS behavior changes, verify package `type`, `main`, `module`, `browser`, `exports`, condition order, extension rules, generated JS, and generated declaration files together.
+15. Inspect generated declarations when package surfaces change. Declaration files must not leak source-only aliases, private paths, workspace-only package names, unpublished internal paths, or accidental public re-exports.
+16. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
+
+<!-- mustflow-section: assertion-policy -->
+## Assertion Policy
+
+Allowed:
+
+- `as const` for preserving literal types.
+- `satisfies` for checking object coverage while preserving the expression's inferred shape.
+- Narrow assertions immediately after a nearby runtime check when TypeScript cannot express the relationship.
+- Assertion functions that actually inspect the value and throw on failure.
+- `@ts-expect-error` in type tests when the comment states why the error is expected.
+- One contained wrapper around an incorrect third-party type, backed by runtime validation or a smoke test.
+
+Rejected by default:
+
+- `JSON.parse(...) as T`, `response.json() as T`, `process.env as Env`, `Object.fromEntries(formData) as T`, or any external input cast directly to a domain type.
+- `as any`, `as unknown as T`, `as never`, or a broad object-wide `as T` used to bypass incompatible shapes.
+- `user!.profile!.field!`-style property chains or non-null assertions after async, callbacks, mutation, or lifecycle transitions.
+- Implementation `@ts-ignore`.
+- Compiler setting downgrades such as disabling strictness, null checking, indexed access safety, or declaration checking to make the patch pass.
+
+<!-- mustflow-section: public-api-policy -->
+## Public API Policy
+
+Public API includes every import path a consumer can resolve, runtime JS entry, declaration entry, package export condition, type export, generated `.d.ts` signature, class member, overload, generic parameter, interface field, enum or literal member, public barrel export, CLI `bin`, and documented example.
+
+When package or declaration surfaces change:
+
+- Compare runtime exports and type exports.
+- Check root imports, subpath imports, type-only imports, ESM imports, CJS requires, and documented deep imports when those targets are supported.
+- Treat removed exports, renamed exports, narrowed parameters, changed defaults, changed overload order, widened or narrowed return contracts, required field additions, optional field meaning changes, generic bound changes, and declaration path changes as compatibility-sensitive.
+- Treat path aliases in emitted JS or declarations as release risks unless the consumer environment is guaranteed to resolve them.
+- If a previously importable deep path becomes blocked by `exports`, report it as a breaking-change risk unless a compatibility export remains.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise the patch when any of these appear without explicit evidence and risk reporting:
+
+- A type error is fixed by adding `any`, broad `as`, double assertion, non-null assertion, `@ts-ignore`, or compiler setting downgrades.
+- External data is trusted as a domain type without schema validation, a type guard, or an assertion function.
+- A state object uses optional fields where a discriminated union would encode the lifecycle correctly.
+- Validator schemas and exported types are duplicated without a single source of truth.
+- Generated declarations expose source-only aliases, internal module paths, workspace-only packages, or accidental barrel exports.
+- Package entry metadata changes without checking runtime entry, type entry, declaration output, and supported resolver modes.
+- `skipLibCheck` or weakened strictness is used as release validation for a library/package.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Type safety is preserved or improved.
+- Runtime input boundaries are validated before values receive domain types.
+- Runtime exports, type exports, and declaration output agree.
+- Assertions are narrow, justified, and contained.
+- Any public API or module-system risk is reported.
+- No type-checking or test guard was weakened without an explicit user request and risk report.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+If a package API changes, include the configured release or package-surface verification when available.
+
+Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, latest supported TypeScript version, ESM, CJS, and bundler-style resolution when those surfaces change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a type error appears to require weakening compiler settings, stop and report the real boundary conflict.
+- If external input has no validation pattern, add a narrow validator/guard/assertion or report the missing boundary instead of casting.
+- If module resolution is unclear, inspect the package and compiler configuration before changing imports.
+- If generated declaration output cannot be inspected, report the package API risk and the missing verification intent.
+- If verification commands are missing, report the missing intents instead of inventing package-manager commands.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Files changed
+- Type and module safety notes
+- Public API or declaration impact
+- Command intents run
+- Skipped checks and reasons
+- Remaining TypeScript risk

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

@@ -0,0 +1,186 @@
+---
+mustflow_doc: skill.unocss-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: unocss-code-change
+description: Apply this skill when UnoCSS config, presets, extraction, content pipeline, shortcuts, rules, variants, safelist, blocklist, attributify, transformers, or utility usage are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.unocss-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# UnoCSS Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant, attributify, and production CSS boundaries. Treat UnoCSS utilities as statically extracted tokens, not runtime-generated strings.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `uno.config.*`, `unocss.config.*`, presets, rules, shortcuts, variants, extractors, content pipeline, safelist, blocklist, transformers, attributify, icon utilities, or UnoCSS utility usage changes.
+- The task touches Vue, Svelte, Astro, MDX, TSX, backend templates, markdown-generated HTML, runtime class maps, generated CSS visibility, static class maps in `.ts` or `.js`, or utility generation in shared files.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Utility styling is Tailwind, not UnoCSS; use `tailwind-code-change`.
+- Styling is plain CSS without UnoCSS extraction risk; use `css-code-change`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `uno.config.*` or `unocss.config.*`, package metadata, bundler integration, CSS entry, content extraction rules, presets, shortcuts, rules, variants, safelist, blocklist, transformers, attributify settings, and tests.
+- The file types that actually contain utilities, including static maps or variant helpers in `.ts` or `.js` files.
+- Approved token allowlists for intent, tone, size, color, spacing, theme, state, icon, and variant values.
+- Any runtime source for visual values: CMS, database, backend templates, user input, API data, generated markdown, or external components.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Confirm extraction targets before adding utilities or moving class maps.
+- Identify whether the project uses default pipeline extraction, explicit `content.pipeline.include`, `@unocss-include`, safelist, or custom extractors.
+- Identify whether shortcuts, rules, variants, or safelist entries are design-system vocabulary or one-off hiding places.
+- If the config is unclear, do not introduce attributify, custom rules, custom variants, broad shortcuts, or broad safelists. Use plain `class` utilities with complete static strings.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Keep utilities statically extractable or narrowly safelisted.
+- Add shortcuts only for shared design-system vocabulary.
+- Add variants only for clear team conventions.
+- Use blocklist or lint policy to prevent raw pixels, raw colors, non-canonical aliases, and uncontrolled arbitrary utilities when the project supports it.
+- Extend extraction only through narrow pipeline include patterns or a single-file include marker when static class maps live outside default scanned file types.
+- Add safelist entries only for finite candidates that cannot exist statically in source.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read UnoCSS config, presets, extraction config, CSS import, framework integration, and nearby utility usage.
+2. Classify the change: extraction, preset, shortcut, rule, variant, safelist, blocklist, attributify, transformer, icon utility, or component usage.
+3. Treat every UnoCSS utility as a build-time extraction token. Reject runtime interpolation, concatenation, array joins, broad template fragments, or values built only from API, CMS, database, backend, or user-input strings.
+4. If a missing utility comes from string interpolation, replace it with a finite static map. If that map lives in `.ts` or `.js`, ensure the file is included by a narrow content pipeline pattern or a single-file include marker.
+5. Use safelist only for classes that cannot appear statically in source, such as CMS schema values, external runtime input, backend-rendered fragments, or external components. Do not use safelist to cover a bad component API or forgotten extraction include.
+6. Keep safelists small, finite, named, and bounded by approved token lists and maximum generated count. Treat feature-local safelists over 50 classes, shared safelists over 200 classes, or total safelists over 300 classes as design/extraction failures unless explicitly justified.
+7. Do not generate safelists from whole theme objects, full color palettes, all shades, all spacing values, all breakpoints, or broad property and variant multiplication.
+8. Use token allowlists before writing shortcuts, rules, variants, or safelists. Do not use every theme key as an allowed product value.
+9. Add shortcuts only for repeated product primitives. Prefer static shortcuts when all combinations are known. Dynamic shortcuts must be anchored, token allowlisted, and free of broad catch-all groups.
+10. Do not use shortcuts as one-off wrappers for long class strings in a single screen.
+11. Add custom rules only for CSS primitives or token bridges that existing presets cannot express. Do not pass arbitrary raw values directly into CSS.
+12. Returning raw CSS strings from custom rules requires explicit review because escaping, variants, and generated CSS structure become the rule author's responsibility.
+13. Add custom variants only for stable team selector conventions such as known data states, ARIA states, or approved themes. Variants must be allowlisted and selector-scoped.
+14. Use blocklist policy to catch raw pixel utilities, raw color utilities, non-token arbitrary values, and non-canonical aliases when the project supports it. Pair blocklist entries with actionable messages and lint visibility when available.
+15. If attributify is used in JSX or TSX, require prefixed-only attributes, the JSX transformer, and framework type shims. Prefer a project prefix such as `un-`; do not introduce unprefixed `text`, `color`, `size`, or `border` attributes.
+16. If attributify transformer limitations make an attribute ambiguous, use valued prefixed attributes or plain `class` utilities.
+17. Choose configured verification intents that cover production build, extraction coverage, lint, component tests, generated CSS size risk, and visual risk when available.
+
+<!-- mustflow-section: extraction-policy -->
+## Extraction Policy
+
+- Static class maps are valid only when UnoCSS actually scans the file that contains the full utility strings.
+- Default framework scanning may not include plain `.ts` or `.js` utility files. Check the project config before moving variants into helper files.
+- Prefer static maps for finite values such as intent, tone, size, density, column count, state, and theme.
+- Use narrow content pipeline includes for repeated helper-map locations.
+- Use a single-file include marker only for isolated files that intentionally hold extractable utilities.
+- Do not add broad extraction globs that pull tests, generated files, build output, dependencies, or unrelated scripts into utility extraction.
+
+<!-- mustflow-section: shortcut-rule-variant-policy -->
+## Shortcut, Rule, And Variant Policy
+
+- Shortcuts, rules, and variants create project-wide styling vocabulary. Treat them as public design-system surface, not local convenience.
+- Dynamic shortcut regexes must not contain unbounded catch-all groups. They must be anchored and restricted to approved token values.
+- Custom rules must not become raw CSS property tunnels.
+- Custom variants must not create arbitrary selector DSLs.
+- One-off names such as page-specific hero, pricing, landing, or copy wrappers do not belong in global shortcuts.
+- If all combinations are known, prefer generated static shortcut entries over runtime-like regex behavior.
+
+<!-- mustflow-section: safelist-blocklist-policy -->
+## Safelist And Blocklist Policy
+
+- Safelist is a last resort for finite utilities absent from source.
+- Safelist functions must have a named source, an approved candidate list, and a cap.
+- Broad theme iteration, palette multiplication, shade multiplication, and variant multiplication are rejected by default.
+- Blocklist should reject raw pixel, raw hex, raw color-function, and non-token arbitrary utilities when those violate the design system.
+- Blocklist failures should explain the preferred token, scale value, CSS variable, or source file to change.
+- If blocklist only removes generated CSS without a lint or test signal, report the developer-experience risk.
+
+<!-- mustflow-section: attributify-policy -->
+## Attributify Policy
+
+- Do not introduce attributify in a project whose UnoCSS config is unclear.
+- In JSX/TSX, attributify requires prefixed-only mode, JSX transformation, and framework type declarations.
+- Avoid unprefixed attributes that collide with DOM or component props.
+- Prefer plain `class` utilities when transformer, type shim, or prop conflict handling is missing.
+
+<!-- mustflow-section: review-rejection-criteria -->
+## Review Rejection Criteria
+
+Reject the change when:
+
+- Utilities are assembled from runtime fragments.
+- A static map moves into a file UnoCSS does not scan.
+- Safelist hides an extraction mistake.
+- Safelist generation is broad, uncapped, or based on whole theme objects.
+- Dynamic shortcuts use catch-all regex groups or accept arbitrary values.
+- Custom rules pass raw values directly into CSS.
+- Custom variants accept arbitrary selectors or themes.
+- Blocklist removes utilities without an actionable developer-facing signal.
+- JSX/TSX attributify lacks prefix, transformer, or type support.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Utilities are extractable or intentionally safelisted.
+- Shortcut, variant, and rule additions are bounded and reviewable.
+- Safelist and blocklist changes are finite, token-aware, and visible to maintainers.
+- Production generated CSS risk is checked or reported.
+- Attributify conflicts are considered when relevant.
+
+<!-- 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, extractor, or visual verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a utility is missing in production, inspect extraction targets and runtime-only class composition first.
+- If safelist growth is broad, stop and require a smaller token-bounded contract.
+- If a custom extractor is needed, treat it as build-system risk and use a narrower contract skill if command metadata changes.
+- If static maps are not extracted, fix the source include boundary before adding safelist.
+- If attributify breaks JSX or component props, fall back to plain `class` utilities or add the missing prefixed transformer/type contract.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Extraction, safelist, shortcut, or variant notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining UnoCSS risk