mustflow 2.32.0 → 2.37.1

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.tauri-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: tauri-code-change
@@ -35,8 +35,9 @@ Treat the WebView as low trust and the Rust/native side as high authority. Front
 <!-- 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.
+- `src-tauri`, `tauri.conf.*`, `Cargo.toml`, `#[tauri::command]`, `invoke`, Tauri JavaScript APIs, plugin config, capabilities, permissions, scopes, CSP, WebView bootstrap HTML, fs, dialog, shell, opener, updater, sidecar, mobile manifests, or native permissions change.
 - A frontend button, menu, or workflow calls native resources through Tauri.
+- A packaged Tauri app shows a blank or black WebView after release and browser console or built HTML may point to Content Security Policy blocking the frontend bootstrap.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -47,8 +48,8 @@ Treat the WebView as low trust and the Rust/native side as high authority. Front
 <!-- 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.
+- Frontend package metadata, static build output or generated entry HTML, 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, CSP directives, remote origins, WebView custom protocols or IPC origins, and actual OS resources.
 - Permission diff: previous permissions, new permissions, newly reachable windows/webviews, new scopes, and native operations enabled.
 - Configured verification intents.
 
@@ -72,14 +73,15 @@ Treat the WebView as low trust and the Rust/native side as high authority. Front
 <!-- 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.
+1. Read frontend call sites, built frontend entry HTML when relevant, 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.
+6. Apply the CSP and WebView bootstrap policy below before tightening `script-src`, `connect-src`, `style-src`, `worker-src`, `img-src`, `font-src`, or remote-origin policy.
+7. Apply the command input policy below before adding or changing `#[tauri::command]` handlers or `invoke` wrappers.
+8. Apply the filesystem, dialog, shell, opener, updater, and sidecar policies below when those plugins or native operations are touched.
+9. Choose configured verification intents that cover Rust, frontend, Tauri build, permission/capability drift, CSP behavior, and security-sensitive behavior when available.
 
 ## Capability And Permission Policy
 
@@ -93,6 +95,18 @@ Treat the WebView as low trust and the Rust/native side as high authority. Front
 - 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.
 
+## CSP And WebView Bootstrap Policy
+
+- Treat a packaged-app blank or black screen after a CSP change as a possible frontend bootstrap failure before assuming CSS, routing, or rendering logic is broken.
+- Inspect the generated entry HTML, not only source templates. Static frontend builders such as SvelteKit may inject inline bootstrap scripts or module imports after `app.html` or the equivalent source template is processed.
+- If the built entry HTML contains an inline bootstrap script, `script-src 'self'` can block the app before JavaScript starts. Prefer a supported nonce, hash, or externalized bootstrap design when practical.
+- For urgent hotfixes, `script-src 'self' 'unsafe-inline'` may be an explicit compatibility tradeoff only when the app cannot boot otherwise, the risk is recorded, and the policy does not also allow remote script origins, `unsafe-eval`, or wildcard script sources.
+- Keep development-server CSP and packaged-production CSP separate. Do not weaken production policy only to satisfy a local dev server, HMR, or debugging tool.
+- When Tauri IPC or custom protocols are used, make `connect-src` explicit for the required IPC scheme or local origin. Do not replace a specific IPC allowance with `connect-src *`, broad `http:`, broad `https:`, or arbitrary localhost ranges.
+- Do not use `default-src *`, `script-src *`, wildcard remote origins, or catch-all protocol allowances as a shortcut for boot failures.
+- Recheck other generated asset needs after CSP changes: styles, fonts, images, workers, wasm, media, and preload/module scripts may fail independently of the main bootstrap.
+- If a CSP relaxation is shipped as a hotfix, add a follow-up note for a stricter nonce, hash, or externalized-bootstrap design unless the framework or target platform makes that infeasible.
+
 ## Command Input Policy
 
 - Every new or changed `#[tauri::command]` must have a typed request shape unless the command has no input.
@@ -138,6 +152,7 @@ Reject or revise a change when:
 - 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.
+- A packaged blank-screen fix widens CSP with wildcard script or connect sources, remote script origins, `unsafe-eval`, or broad protocol allowances instead of proving the generated bootstrap and IPC requirements.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -146,6 +161,7 @@ Reject or revise a change when:
 - 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.
+- CSP changes have been checked against the generated frontend entry HTML and required Tauri IPC or custom protocol origins.
 - Missing Tauri-specific verification is reported.
 
 <!-- mustflow-section: verification -->
@@ -160,7 +176,7 @@ Use configured oneshot command intents when available:
 - `docs_validate_fast`
 - `mustflow_check`
 
-Report missing native build, permission diff, updater, shell, sidecar, opener, dialog, filesystem, or mobile permission verification intents when relevant.
+Report missing native build, packaged WebView smoke, CSP violation, permission diff, updater, shell, sidecar, opener, dialog, filesystem, or mobile permission verification intents when relevant.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -169,6 +185,7 @@ Report missing native build, permission diff, updater, shell, sidecar, opener, d
 - 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 CSP change breaks packaged app startup, inspect generated HTML and console CSP violations before widening policy; prefer nonce, hash, or externalized bootstrap before accepting `unsafe-inline`.
 - 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.
 
@@ -176,7 +193,7 @@ Report missing native build, permission diff, updater, shell, sidecar, opener, d
 ## Output Format
 
 - Boundary checked
-- IPC, command input, permission, capability, window/webview, and scope notes
+- IPC, command input, CSP, 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

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.typescript-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 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.
+description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, compiler-version behavior, TypeScript 6-to-7 migration surfaces, native preview tooling, type safety, or TypeScript tests are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,6 +35,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 
 - `.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 TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 native preview comparison, `@typescript/native-preview`, `tsgo`, compiler API use, declaration emit comparison, or editor language-service behavior.
 - 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.
 
@@ -51,6 +52,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - 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.
+- TypeScript compiler track and tooling entrypoint when relevant: `typescript` with `tsc`, a TypeScript 6 transition release, `@typescript/native-preview` with `tsgo`, framework typecheck wrappers, editor extension settings, and any compiler API consumers.
 - 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.
 
@@ -60,6 +62,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - 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.
+- If the change depends on TypeScript 6, TypeScript 7, native compiler status, or compiler-version support, refresh official source status before writing durable claims.
 - Treat pasted external examples as input, not authority.
 
 <!-- mustflow-section: allowed-edits -->
@@ -69,6 +72,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - 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.
+- Compare TypeScript 6 `tsc` and TypeScript 7 native preview `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports both.
 - Do not weaken compiler, lint, module, package, or test boundaries to make the task appear complete.
 
 <!-- mustflow-section: procedure -->
@@ -89,7 +93,12 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 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.
+16. For TypeScript 6 migration work, treat deprecation warnings as future TypeScript 7 removal risk. `ignoreDeprecations` is a temporary compatibility valve, not proof that the project is ready for 7.0. Prefer removing deprecated options and updating resolver or module choices to match the project runtime.
+17. Treat TypeScript 6 `--stableTypeOrdering` as a migration comparison tool for declaration and error-order differences, not as a permanent performance-neutral default. If it changes errors or declaration output, look for inference or declaration-stability issues instead of snapshotting noise.
+18. For TypeScript 7 native preview work, keep `typescript` and `@typescript/native-preview` separate in dependency, script, editor, and verification surfaces. `tsgo` can compare compiler behavior, but it is not a drop-in promise for compiler API users, language-service plugins, custom transformers, or framework wrappers unless those surfaces are proven compatible.
+19. When comparing `tsc` and `tsgo`, classify differences before editing code: real type error, declaration emit order or printback noise, unsupported option, unsupported API, watch or incremental behavior gap, language-service gap, generated-output drift, or framework wrapper mismatch.
+20. Do not treat faster native preview results as sufficient verification. Keep existing `tsc` or framework typecheck as the compatibility baseline until repository policy explicitly adopts the native compiler path.
+21. 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
@@ -110,6 +119,8 @@ Rejected by default:
 - `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.
+- Treating TypeScript 6 deprecation suppression as a long-term fix.
+- Replacing stable `tsc` verification with `tsgo` preview verification without an explicit repository policy and compatibility evidence.
 
 <!-- mustflow-section: public-api-policy -->
 ## Public API Policy
@@ -136,6 +147,9 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - 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.
+- TypeScript 6-to-7 migration warnings are silenced instead of classified and either fixed or reported.
+- Native preview output differences are accepted as harmless without classification.
+- Compiler API, transformer, language-service, or framework typecheck surfaces are moved to TypeScript 7 native preview without compatibility proof.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -145,6 +159,7 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Runtime exports, type exports, and declaration output agree.
 - Assertions are narrow, justified, and contained.
 - Any public API or module-system risk is reported.
+- TypeScript 6/7 migration, native preview, and compiler-entrypoint risks are classified when relevant.
 - No type-checking or test guard was weakened without an explicit user request and risk report.
 
 <!-- mustflow-section: verification -->
@@ -161,7 +176,7 @@ Use configured oneshot command intents when available:
 
 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.
+Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, latest supported TypeScript version, TypeScript 6/7 comparison, native preview comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -170,6 +185,8 @@ Report whether configured verification exists for declaration output, package ar
 - 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 TypeScript 7 native preview disagrees with stable TypeScript, keep stable TypeScript as the compatibility baseline, classify the difference, and report whether it is a project bug, compiler-preview bug, unsupported feature, or expected declaration/order drift.
+- If a framework, plugin, transformer, or compiler API consumer depends on the JavaScript compiler implementation, do not migrate it to native preview unless the dependency explicitly supports that path.
 - If verification commands are missing, report the missing intents instead of inventing package-manager commands.
 
 <!-- mustflow-section: output-format -->
@@ -179,6 +196,7 @@ Report whether configured verification exists for declaration output, package ar
 - Files changed
 - Type and module safety notes
 - Public API or declaration impact
+- Compiler-version or native-preview notes
 - Command intents run
 - Skipped checks and reasons
 - Remaining TypeScript risk

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.unocss-code-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 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.
+description: Apply this skill when UnoCSS config, presets, Wind4 migration, theme extension, extraction, content pipeline, shortcuts, rules, variants, safelist, blocklist, attributify, transformers, icons, shadow DOM styling, or utility usage are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -33,7 +33,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 <!-- 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.
+- `uno.config.*`, `unocss.config.*`, presets, Wind4 preset migration, theme extension, rules, shortcuts, variants, extractors, content pipeline, safelist, blocklist, transformers, attributify, icon utilities, shadow DOM style injection, 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 -->
@@ -45,7 +45,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 <!-- 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.
+- `uno.config.*` or `unocss.config.*`, package metadata, bundler integration, CSS entry, content extraction rules, presets, Wind4 or Wind3 compatibility signals, theme extension or `extendTheme`, shortcuts, rules, variants, safelist, blocklist, transformers, attributify settings, icon loader 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.
@@ -56,6 +56,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 
 - 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 the project uses the classic preset stack, `presetWind4`, theme compatibility tokens, shortcut layers, variant groups, icons, attributify, directives, or framework-specific plugin order.
 - 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.
 
@@ -68,33 +69,39 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 - 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.
+- Add icon loaders, custom rules, and shadow DOM CSS only with explicit package, bundle-size, and injection ownership.
 
 <!-- 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.
+2. Classify the change: extraction, preset, Wind4 migration, theme extension, shortcut, rule, variant, safelist, blocklist, attributify, transformer, icon utility, shadow DOM styling, 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.
+9. For Wind4 migration, verify preset choice, theme token migration, preflight ownership, variant behavior, and compatibility with existing Tailwind-like class vocabulary before changing utilities at call sites.
+10. Use `extendTheme` or equivalent merge hooks when preserving existing theme tokens matters. Do not replace the whole theme object if the local config expects extension semantics.
+11. 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.
+12. Do not use shortcuts as one-off wrappers for long class strings in a single screen.
+13. Add custom rules only for CSS primitives or token bridges that existing presets cannot express. Do not pass arbitrary raw values directly into CSS.
+14. Returning raw CSS strings from custom rules requires explicit review because escaping, variants, and generated CSS structure become the rule author's responsibility.
+15. 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.
+16. 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.
+17. 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.
+18. If attributify transformer limitations make an attribute ambiguous, use valued prefixed attributes or plain `class` utilities.
+19. For icons, verify package ownership, icon collection size, loader source, currentColor behavior, mask/background mode, and whether `FileSystemIconLoader` or custom loaders introduce file-system or bundling risk.
+20. For Svelte, Vue, Astro, MDX, shadow DOM, web components, or framework-scoped CSS, verify plugin order and style injection order before blaming missing utilities on class names.
+21. 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.
+- Extraction can come from file-system scans, `content.pipeline.include`, inline include markers, framework transforms, markdown/MDX pipelines, backend templates, or custom extractors. Name which owner makes each utility visible.
 - 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.
@@ -109,6 +116,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 - 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.
+- Rules, shortcuts, and variants must remain layer-aware. Do not let a shortcut hide whether a style belongs in reset, preflight, tokens, utilities, components, or a local framework style block.
 
 <!-- mustflow-section: safelist-blocklist-policy -->
 ## Safelist And Blocklist Policy
@@ -120,6 +128,14 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 - 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: preset-icon-shadow-policy -->
+## Preset, Icon, And Shadow DOM Policy
+
+- Wind4 migration must preserve theme tokens, preflight expectations, variant semantics, and generated CSS size before call-site cleanup.
+- Icon utilities are production assets. Verify the chosen icon collections, loader ownership, package footprint, currentColor inheritance, accessibility label path, and whether dynamic icon names require a finite safelist.
+- Shadow DOM and web component styles need an explicit injection owner. Do not assume global utility CSS reaches closed or separately injected roots.
+- Framework plugin order is part of extraction. Svelte, Vue, Astro, MDX, transformers, variant-group handling, and attributify can change whether the token exists before UnoCSS scans it.
+
 <!-- mustflow-section: attributify-policy -->
 ## Attributify Policy
 
@@ -142,12 +158,15 @@ Reject the change when:
 - 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.
+- Wind4 migration replaces theme or preflight behavior without compatibility review.
+- Icon utilities accept unbounded runtime icon names.
+- Shadow DOM utility usage has no style injection owner.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Utilities are extractable or intentionally safelisted.
-- Shortcut, variant, and rule additions are bounded and reviewable.
+- Preset, shortcut, variant, rule, icon, and shadow DOM 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.

package/templates/default/locales/en/.mustflow/skills/version-freshness-check/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.version-freshness-check
 locale: en
 canonical: true
-revision: 1
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: version-freshness-check
-description: Apply this skill when generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, or migration-sensitive snippets introduce explicit external version references that may be stale.
+description: Apply this skill when generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, Python standard-library/API references, TypeScript compiler-track references, Go release, toolchain, standard-library, runtime, or experiment references, Rust release, toolchain, standard-library, Cargo, edition, MSRV, lint, or target references, HTTP standard or browser-support references, or migration-sensitive snippets introduce explicit external version references that may be stale.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -34,6 +34,11 @@ Prevent agents from writing stale external version references from memory, while
 
 - Generated or edited files introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, toolchain versions, setup actions, scaffold commands, install commands, or migration examples.
 - CI workflows, release workflows, Dockerfiles, package metadata, lockfiles, runtime files, framework configuration, README examples, docs, tests, fixtures, or templates mention external versions such as GitHub Actions refs, Node, Bun, Deno, Python, Rust, Tauri, Astro, Next, SvelteKit, Electron, Docker images, package managers, SDKs, plugins, or generators.
+- Python wording mentions current/stable/support status, Python 3.14+ standard-library APIs, runtime flags, changed default behavior, security defaults, or examples that depend on `requires-python`.
+- TypeScript wording mentions current/stable/beta/native preview status for TypeScript 6, TypeScript 7, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
+- Go wording mentions current/stable/support status, Go release numbers, `go.mod` language version behavior, `toolchain` behavior, standard-library APIs, `GOEXPERIMENT`, runtime defaults, container behavior, JSON experiments, or examples that depend on a specific Go version.
+- Rust wording mentions current/stable/support status, Rust release numbers, `rust-version`, edition behavior, `rust-toolchain`, Cargo resolver or workspace behavior, standard-library APIs, compiler lints, target behavior, release profiles, or examples that depend on a specific Rust version.
+- HTTP delivery wording mentions current support, baseline status, default behavior, standard status, or compatibility for zstd content coding, compression dictionary transport, SSE/EventSource, WebTransport, WebSocket fallback, HTTP/2, HTTP/3, QUIC, CDN behavior, proxy buffering, or browser transport APIs.
 - An agent proposes a versioned dependency, tool, framework, action, image, or runtime based on memory, copied snippets, older project examples, or user-provided text that may be stale.
 - The task asks whether a newer stable, recommended, LTS, or security-patched version should replace a version the agent was about to write.
 - A patch claims a version is latest, current, recommended, stable, LTS, supported, deprecated, end-of-life, or migration-safe.
@@ -89,9 +94,19 @@ Prevent agents from writing stale external version references from memory, while
 10. For patch, security-minimum, and low-risk minor differences, update only when the declaration, examples, lockfile policy, and verification surface can stay aligned. Otherwise report the proposed change and leave the pinned value unchanged.
 11. For GitHub Actions and CI tools, review the action source, major tag policy, runtime support, cache behavior, permissions, and organization pinning rule. Do not assume a newer major is safe only because it exists.
 12. For framework and runtime majors such as Astro, Tauri, Electron, Next, SvelteKit, Node, Bun, Deno, Python, Rust, or Java, check migration notes, config schema, plugin and adapter compatibility, generated files, security model, deployment target, and rollback path before recommending a major change.
-13. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
-14. Synchronize every accepted version decision across package metadata, lockfiles when intentionally updated, CI, Docker, runtime files, docs, examples, templates, tests, and release notes.
-15. Run the narrowest configured verification that covers the changed versioned surface. Use broader verification for major, migration-required, runtime, framework, generated-output, package-publish, Docker, CI, or security-sensitive changes.
+13. For Python standard-library or runtime-behavior claims, refresh official Python documentation before writing durable wording. Check `requires-python`, CI/runtime matrices, and container images before using or recommending version-gated features such as Python 3.14+ `map(strict=True)`, `functools.Placeholder`, `heapq` max-heap helpers, import-timing flag behavior, or changed security defaults.
+14. For Python examples that use newer standard-library APIs, either keep the example behind an explicit runtime floor or provide a supported fallback. Do not call a Python 3.14-only API a general Python best practice when the repository declares lower support.
+15. For TypeScript 6 and 7 claims, refresh official TypeScript sources before writing durable wording. Treat TypeScript 6 stable releases, TypeScript 7 native preview or beta packages, `@typescript/native-preview`, `tsgo`, and future stable `typescript` package behavior as distinct tracks. Do not call native preview output "latest stable TypeScript" just because it is newer.
+16. For TypeScript native-preview examples, make the selected track explicit: side-by-side comparison, beta testing, editor preview, or repository adoption. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive.
+17. For Go release, toolchain, standard-library, runtime, or experiment claims, refresh official Go release notes or package documentation before writing durable wording. Check the repository's `go` directive, `toolchain` directive, CI/runtime matrix, and container target before using or recommending version-gated features such as expression operands to `new`, `errors.AsType`, `sync.WaitGroup.Go`, `testing/synctest`, `testing.B.Loop`, `os.Root`, `os.OpenInRoot`, `omitzero`, `go.mod` `tool`, `ReverseProxy.Rewrite`, container-aware `GOMAXPROCS`, goroutine leak profiles, `encoding/json/v2`, or `GOEXPERIMENT` APIs.
+18. For Go examples that use newer standard-library APIs or runtime defaults, either keep the example behind an explicit Go version floor or provide a supported fallback. Do not call an experimental `GOEXPERIMENT` feature or a newer `go` directive behavior a general Go best practice when the repository declares lower support.
+19. For Rust release, toolchain, standard-library, Cargo, edition, lint, target, or MSRV claims, refresh official Rust release notes, standard-library docs, the Cargo Book, Rust Reference, or rustc book before writing durable wording. Check `rust-version`, edition, `rust-toolchain.toml`, CI toolchain matrix, target triples, docs.rs metadata, and crate publish policy before using or recommending version-gated features such as let chains, match `if let` guards, `cfg_select!`, `assert_matches!`, `core::range`, `Vec::push_mut`, `HashMap::get_disjoint_mut`, `Option::take_if`, `LazyLock`, `OnceLock`, `workspace.lints`, `resolver = "2"`, Rust 2024 `unsafe_op_in_unsafe_fn`, or release-profile defaults.
+20. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Do not call a Rust 1.95+ or 1.96+ API a general Rust best practice when the repository declares a lower MSRV, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
+21. For HTTP standards, browser APIs, proxy defaults, CDN defaults, and transport support claims, prefer official RFCs, standards bodies, MDN or browser vendor docs, and vendor-owned proxy/CDN documentation. Keep WebTransport, compression dictionary transport, zstd content coding, SSE/EventSource, HTTP/2, HTTP/3, QUIC, and proxy-buffering claims track-specific and dated when support is changing.
+22. For HTTP delivery examples that depend on newer or unevenly supported behavior, require feature detection, fallback behavior, or explicit deployment constraints. Do not present WebTransport, dictionary compression, or zstd negotiation as a universal default when the project still needs browsers, proxies, CDNs, or networks that may not support it.
+23. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
+24. Synchronize every accepted version decision across package metadata, lockfiles when intentionally updated, CI, Docker, runtime files, docs, examples, templates, tests, and release notes.
+25. Run the narrowest configured verification that covers the changed versioned surface. Use broader verification for major, migration-required, runtime, framework, generated-output, package-publish, Docker, CI, TypeScript compiler-track, Go toolchain or runtime support, Rust toolchain or MSRV support, HTTP delivery compatibility, or security-sensitive changes.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -100,6 +115,11 @@ Prevent agents from writing stale external version references from memory, while
 - Stale model defaults are not silently written as if they were current.
 - Repository-pinned versions are preserved unless the task, policy, and compatibility classification support changing them.
 - Major or migration-required changes are either explicitly approved, deferred with a recommendation, or left unchanged with the risk reported.
+- Python standard-library examples and runtime-default claims match the declared Python support matrix or name the required runtime floor.
+- TypeScript 6 stable, TypeScript 7 beta/native-preview, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
+- Go release, `go.mod` language version, standard-library API, runtime-default, and `GOEXPERIMENT` claims match the declared Go support matrix or name the required runtime floor.
+- Rust release, `rust-version`, edition, standard-library API, Cargo resolver, lint-default, target, and nightly/stable claims match the declared Rust support matrix or name the required runtime floor.
+- HTTP standard, browser-support, proxy-default, CDN-default, and transport-support claims are not written from stale memory and keep feature detection or fallback boundaries explicit where support varies.
 - Docs and examples do not make unverifiable current-version claims.
 
 <!-- mustflow-section: verification -->
@@ -124,6 +144,10 @@ Choose the narrowest configured intent that proves the changed versioned surface
 - If official sources conflict, prefer the source that owns the artifact being referenced and report the conflict.
 - If a freshness check requires network, credentials, or a connector that is not available, report the boundary and avoid current-version claims.
 - If a proposed major or migration-required version is better for greenfield work but risky for the existing project, present both choices and ask before changing the project.
+- If TypeScript 7 native preview freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from preview comparison.
+- If Go release or experiment freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, `go` directive adoption, CI support, and `GOEXPERIMENT` adoption separate.
+- If Rust release or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, MSRV adoption, edition adoption, CI support, target support, and nightly or unstable features separate.
+- If HTTP delivery support changes during the task, update wording to a dated or track-specific claim and keep standards, browser support, CDN behavior, proxy defaults, and repository adoption separate.
 - If verification fails after a freshness update, do not weaken tests, lower type checks, delete lockfiles, or widen ranges to make the update pass. Revert or narrow the version decision unless the behavior change is intentional.
 
 <!-- mustflow-section: output-format -->

package/templates/default/locales/en/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: en
 canonical: true
-revision: 14
+revision: 15
 lifecycle: user-editable
 authority: binding
 ---
@@ -44,7 +44,8 @@ mustflow-managed details are under `.mustflow/`.
 - Do not directly start development servers, watchers, browser interfaces, interactive prompts,
   or background processes.
 - Do not start autonomous loops, worker processes, persona systems, or long-running harness
-  processes unless this repository explicitly configures them.
+  processes unless this repository explicitly configures their lifecycle, safety, and approval
+  boundaries.
 - Follow `[budget]`, `[approval]`, and `[isolation]` in `.mustflow/config/mustflow.toml` when a
   task may run for a long time or affect sensitive state.
 - Use `mf doctor` or `mf doctor --json` for a read-only health check before broad changes.

package/templates/default/locales/ko/.mustflow/docs/agent-workflow.md

@@ -2,7 +2,7 @@
 mustflow_doc: docs.agent-workflow
 locale: ko
 canonical: false
-revision: 27
+revision: 28
 lifecycle: mustflow-owned
 authority: workflow-policy
 ---
@@ -20,7 +20,7 @@ authority: workflow-policy
 - 작업 시작 전 확인해야 할 문서 흐름
 - 상위 작업 공간과 하위 저장소 규칙 간 우선순위
 - 반복 입력의 안정성 유지 정책
-- 장기 작업에서 실행 하네스(실행 환경)가 따라야 할 작업 계약 경계
+- 기본 작업 흐름과 선택형 런타임, 조정, 작업 항목 표면의 경계
 - 계층형 압축 기억 정책과 요약 기억의 권위 한계
 - 명령 인텐트 상태별 실행 정책
 - 장기 실행 프로세스 방지 정책
@@ -217,15 +217,20 @@ mustflow 지침은 다음 지점에서 다시 확인합니다.
 
 프로젝트 내에 숨겨진 내부 추론, 비밀정보, 전체 대화 전문, 전체 터미널 출력, 원본 이벤트 로그, 원본 명령 로그를 저장하지 않습니다. 향후 호스트가 요약을 만들더라도 요약은 출처가 있어야 하며, 현재 파일과 현재 사용자 지시보다 낮은 권위를 가집니다.
 
-## 실행 하네스 계약 경계
+## 실행 하네스와 런타임 표면
 
-mustflow는 자율 에이전트 실행 환경이 아닙니다. mustflow는 여러 에이전트 실행 하네스가 저장소에 들어왔을 때 읽고 따를 수 있는 저장소 내부 작업 계약층입니다.
+mustflow는 저장소 안의 작업 흐름 파일과 명령 실행 경계에서 시작하지만, 선택형 런타임,
+조정, 작업 항목, 어댑터, 하네스 표면으로 확장될 수 있습니다. 새 표면은 문서 문구,
+생성 상태, 추측 명령에 몰래 섞는 대신 명시적이고, 경계가 있고, 검토 가능해야 합니다.
 
-- 사고 계약: `AGENTS.md`, 이 문서, 스킬 문서는 모델이 따라야 할 작업 절차를 설명합니다.
-- 실행 계약: `.mustflow/config/commands.toml`과 `mf run`은 안전한 명령 실행 경계를 정합니다.
-- 세션 계약: 실행 기록, 제한된 체크포인트, 작은 인계 문서는 복구와 검토 근거를 남깁니다.
+- 사고 표면: `AGENTS.md`, 이 문서, 스킬 문서는 모델이 따라야 할 작업 절차를 설명합니다.
+- 실행 표면: `.mustflow/config/commands.toml`과 `mf run`은 안전한 명령 실행 경계를 정합니다.
+- 세션 표면: 실행 기록, 제한된 체크포인트, 작은 인계 문서, 향후 작업 항목 기록은 복구와 검토 근거를 남깁니다.
+- 런타임 표면: 작업자 폴더, 페르소나 시스템, 다중 실행 조정, 서비스 프로세스,
+  자율 반복 실행기는 생명주기, 보존, 격리, 승인, 검증 규칙을 선언해야 합니다.
 
-저장소가 명시적으로 선택 기능을 추가하지 않았다면 `workers/`, `personas/`, 여러 에이전트 조정 폴더, 원시 이벤트 로그, 자율 반복 실행기를 만들지 않습니다.
+런타임이나 조정 표면을 암묵적 관습으로 운용하지 않습니다. 저장소가 해당 기능을 지원하기로
+선택하면 명시적 설정, 명령 계약, 테스트, 문서를 통해 추가하거나 켭니다.
 
 ## 장기 작업 단계
 

package/templates/default/locales/ko/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: ko
 canonical: false
-revision: 21
+revision: 22
 lifecycle: user-editable
 authority: binding
 ---
@@ -38,7 +38,7 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 - `mf run` 명령 인텐트는 순차적으로 실행합니다. 설정된 인텐트가 아직 실행 중이면 다른 `mf run`을 시작하지 말고, 특히 인텐트가 `dist/`처럼 비어 있지 않은 `writes`를 선언한 경우 반드시 완료될 때까지 기다립니다.  
 - 위험을 최소화하는 가장 좁은 검증 명령 인텐트를 선택합니다. 명령 계약에 관련 테스트나 빠른 검사가 있으면 넓은 전체 테스트보다 우선하며, 더 좁은 검증 인텐트가 없으면 느린 전체 테스트를 조용히 기본값으로 삼지 말고 누락 사실을 보고합니다.  
 - 개발 서버, 감시 모드, 브라우저, 대화형 명령, 백그라운드 프로세스는 직접 실행하지 않습니다.  
-- 이 저장소가 명시적으로 설정하지 않았다면 자율 반복 실행기, 다중 작업자 조정, 페르소나 시스템, 장기 실행 하네스(실행 환경)는 시작하지 않습니다.  
+- 이 저장소가 생명주기, 안전 경계, 승인 경계를 명시적으로 설정하지 않았다면 자율 반복 실행기, 다중 작업자 조정, 페르소나 시스템, 장기 실행 하네스(실행 환경)는 시작하지 않습니다.
 - 작업이 장시간 실행되거나 민감한 상태에 영향을 줄 수 있다면 `.mustflow/config/mustflow.toml`의 `[budget]`, `[approval]`, `[isolation]` 정책을 따릅니다.  
 - 수정 전 현재 mustflow 루트 상태와 다음 단계를 빠르게 확인하려면 `mf doctor` 또는 `mf doctor --json`을 사용합니다. 이 명령은 파일을 쓰지 않는 진단용 명령입니다.  
 - `mf context --json`은 읽기 전용 컨텍스트 확인 용도로 사용할 수 있으나, 실제 작업 규칙이나 명령 계약을 대체하지 않습니다.