mustflow 2.22.16 → 2.22.46

package/templates/default/locales/en/.mustflow/skills/auth-permission-change/SKILL.md

@@ -0,0 +1,194 @@
+---
+mustflow_doc: skill.auth-permission-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: auth-permission-change
+description: Apply this skill when authentication, authorization, permissions, roles, tenants, sessions, JWTs, OAuth or OIDC, API keys, route guards, admin access, database policies, or object-level access control are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.auth-permission-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Auth Permission Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep authentication and authorization separate, enforce permissions on the server or database for every protected request, and prevent client-only guards from being treated as a security boundary.
+
+Authentication answers who the requester is. Authorization answers what that principal can do to this resource in this tenant right now. Login state, verified email, a valid JWT, a visible admin button, or a client redirect is not permission.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Authentication, authorization, role, permission, capability, policy, tenant, workspace, organization, session, JWT, OAuth, OIDC, API key, invite, reset token, route guard, admin, impersonation, audit, or database policy behavior changes.
+- A route, resolver, controller, service, command handler, job, webhook, API client, generated SDK, UI guard, or database query starts relying on user, tenant, role, ownership, membership, or resource identity.
+- A change affects object-level access control, multi-tenant isolation, shared resources, signed URLs, exports, search, autocomplete, background jobs, webhooks, or admin/support tooling.
+- A change modifies status code behavior for auth failures, especially 401, 403, or policy-driven 404.
+- A permission model, role matrix, API docs, admin docs, migration, or tests need to stay aligned with authorization behavior.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only password hashing, cryptography, secure transport, secret handling, or generic privacy review with no auth or permission boundary; use `security-privacy-review`.
+- The task only adds abuse-case tests after a boundary is already understood; use `security-regression-tests` for that part.
+- The task only changes UI text for a public page and does not affect route guards, server checks, roles, sessions, or access decisions.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Changed files, user goal, affected actors, protected resources, actions, tenants, roles, and status-code expectations.
+- Auth middleware, framework hooks, gateway checks, session config, cookie config, JWT verifier, OAuth/OIDC callback, API key verifier, and logout or revocation code when relevant.
+- Route guards, client guards, server controllers, resolvers, command handlers, services, policy functions, role or permission tables, database queries, RLS, views, stored procedures, and ORM scopes.
+- Tenant, organization, workspace, project, membership, invite, suspension, ownership, sharing, and admin-support data models.
+- Background jobs, queue payloads, webhooks, import/export flows, search or autocomplete indexes, signed URL generation, storage keys, CDN cache, and permission caches when they can expose protected data.
+- Audit logs, admin action logs, impersonation records, denied-access logs, API docs, role matrix docs, migrations, and tests.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Classify the change as authentication, authorization, or both before editing.
+- Identify principal, tenant, resource, action, and context for each protected operation.
+- Treat client-provided `userId`, `tenantId`, `workspaceId`, `role`, `isAdmin`, object id, API key label, token claim, and local storage value as untrusted.
+- Find the current policy source of truth. If authorization is scattered across routes, do not add another scattered condition without first considering a central policy function.
+- Know whether the product intentionally hides resource existence with 404 or exposes permission denial with 403.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten server-side authorization checks, policy functions, database scopes, RLS, query constraints, audit logs, docs, and tests.
+- Adjust client guards only as UX, and only while keeping or adding server/database enforcement.
+- Add role or permission migration logic only with deny-by-default behavior and explicit backfill rationale.
+- Keep docs, generated clients, role matrices, status-code behavior, and tests synchronized with changed auth behavior.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the boundary:
+   - authentication: verifies a principal from a session, JWT, OAuth/OIDC account, API key, service account, or anonymous state;
+   - authorization: decides whether that principal can perform an action on a resource within a tenant and context.
+2. Read the mandatory surfaces that apply:
+   - auth middleware, hooks, gateway, session store, cookies, JWT, OAuth/OIDC, API key verification, logout, revocation, and token rotation;
+   - route guards, client redirects, server controllers, resolvers, services, command handlers, policy calls, and admin tools;
+   - tenant resolver, membership schema, role assignment, invite flow, suspension, ownership, sharing, and impersonation model;
+   - database queries, tenant scopes, ownership joins, soft-delete filters, RLS, views, stored procedures, and ORM helpers;
+   - background jobs, queues, webhooks, import/export, file storage, signed URLs, search, autocomplete, caches, audit logs, docs, migrations, and tests.
+3. Write the permission decision inputs for each protected action: principal, tenant, resource, action, and context.
+4. Separate identity from permission:
+   - `req.user`, a valid session, verified email, valid JWT, OAuth scope, or API key proves identity only;
+   - owner, active member, org admin, global admin, support user, service account, API client, and shared-link viewer need separate authorization rules.
+5. Prefer one central policy shape, such as a `can(principal, action, resource, context)` function, over route-local `isAdmin`, `isOwner`, or `isMember` fragments.
+6. Enforce deny by default. New roles, actions, resource types, tenant types, sharing modes, and admin paths must deny until explicitly allowed.
+7. Validate every request. Do not rely on login-time checks, client guards, disabled buttons, hidden menus, generated types, OpenAPI docs, or mobile local checks.
+8. Load resources safely before final authorization:
+   - include tenant, membership, owner, sharing, and soft-delete constraints in the resource lookup when possible;
+   - when existence must be hidden, keep wrong-tenant and missing-resource behavior consistent with the project's 404 policy.
+9. Check multi-tenant risks:
+   - body, query, header, path, JWT claim, or local storage tenant ids must not become trusted tenant context;
+   - tenant-scoped queries must include tenant or membership constraints;
+   - pending, suspended, removed, revoked, deleted, disabled, and invited states must not be treated as active access;
+   - shared links, exports, signed URLs, previews, search, cache, and CDN entries must stay inside the permission model.
+10. Check session, JWT, OAuth/OIDC, and API key contracts when touched:
+   - sessions need expiry, refresh, rotation, logout, revocation, cookie flags, and CSRF posture;
+   - JWTs need signature verification, algorithm allowlist, issuer, audience, subject, expiry, not-before, key rotation, and stale-claim handling;
+   - OAuth/OIDC needs exact redirect binding, state, nonce, PKCE when relevant, provider account binding, and safe account linking;
+   - API keys need hashing, prefix-only display, owner type, scope, tenant/resource constraints, expiry, rotation, revocation, last-used, rate limit, and audit.
+11. Check dependent surfaces: API routes, controllers, services, DB schema, DB queries, RLS, UI navigation, UI actions, API clients, audit logs, notifications, jobs, webhooks, search, file storage, docs, migrations, monitoring, and tests.
+12. Require denial-first tests for changed protected actions when the project has a usable test surface. Cover anonymous, expired, revoked, no role, wrong tenant, wrong owner, suspended or removed member, stale cache, shared-link, read-only API key, org admin, global admin, and impersonating admin cases as applicable.
+13. Update docs and role matrices when external behavior, status codes, role names, permission names, admin scope, or API errors change.
+14. Report the policy source of truth, server/database enforcement, client UX-only guards, test coverage, skipped checks, and remaining permission risk.
+
+## Boundary Rules
+
+- Client guards are UX only. They may hide buttons, menus, and pages, but they do not authorize API calls.
+- Route middleware may perform coarse authentication and tenant resolution, but final resource/action authorization belongs in server policy, service authorization, gateway policy, or database policy.
+- Database RLS, tenant-scoped queries, views, and stored procedures are defense-in-depth and may be the strongest final boundary, but they do not excuse unclear application policy.
+- Background jobs, webhooks, imports, exports, and cron paths need actor or service-principal context. User-request paths are not the only permission paths.
+- Admin is scoped. Global admin, org admin, project admin, billing admin, support, and impersonating admin are different roles and need different audit and action rules.
+- Owner is not a wildcard permission. Owners may still lack delete, export, invite, transfer, billing, or admin powers.
+- API keys are principals with scopes and owners, not user sessions with unlimited power.
+
+## Strongly Forbidden Patterns
+
+- Treating authentication as authorization.
+- Trusting client-provided `userId`, `tenantId`, `role`, `isAdmin`, `ownerId`, `scope`, price, entitlement, or plan.
+- Relying on hidden buttons, disabled controls, client redirects, mobile checks, TypeScript types, docs, or Storybook examples as permission boundaries.
+- Reading tenant-scoped resources with an object id alone.
+- Treating membership row existence as active membership without checking status.
+- Treating OAuth provider scopes as internal app permissions.
+- Treating JWT role claims as fresh authorization after role changes.
+- Treating API keys as normal user sessions.
+- Mixing org admin, global admin, support admin, and impersonation into one `admin` check.
+- Changing 403 to 404, or 404 to 403, without naming the information-disclosure policy.
+- Relaxing permissions without denial-case tests or a written migration and audit plan.
+- Letting role changes ship without permission-cache or token-staleness handling.
+- Creating shared links, signed URLs, exports, search results, or CDN responses outside tenant and resource policy.
+- Logging impersonation without separate actor and subject.
+- Backfilling broad permissions to every existing user because migration is easier.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Authentication and authorization are separated in code and report language.
+- Every changed protected action has a server-side or database-side permission boundary.
+- Tenant isolation, resource ownership, sharing, admin scope, and status-code behavior are explicit.
+- Client guards are described as UX only.
+- Session, token, OAuth/OIDC, API key, cache, audit, docs, migration, and tests are synchronized when touched.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured test intent that covers the changed protected actions and denial cases. Report missing auth-specific policy tests, tenant-isolation tests, token/session tests, API-key tests, cache-staleness tests, audit-log checks, docs validation, or database-policy verification when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the current policy source of truth is unclear, stop and report the competing policy locations before adding more checks.
+- If a server check is missing and only the UI hides the action, treat it as incomplete work, not as authorization.
+- If a tenant-scoped query lacks tenant, membership, ownership, sharing, or RLS coverage, fix the data access path before broadening features.
+- If denial tests cannot be written in the current task, report the exact untested actor, tenant, resource, action, and context combinations.
+- If the change relaxes permissions, changes status-code policy, or broadens admin/API-key behavior, call out the security risk and required verification.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Authentication versus authorization classification
+- Principal, tenant, resource, action, and context affected
+- Policy source of truth
+- Server/database enforcement notes
+- Client guard UX-only notes
+- Tenant, ownership, sharing, admin, token/session/API-key, cache, and audit notes
+- Tests or denial cases covered
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining auth or permission risk

package/templates/default/locales/en/.mustflow/skills/config-env-change/SKILL.md

@@ -0,0 +1,189 @@
+---
+mustflow_doc: skill.config-env-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: config-env-change
+description: Apply this skill when environment variables, config keys, secrets, public env prefixes, build-time or runtime config, config schemas or parsers, feature flags, deployment variables, CI secrets, Docker or Compose env, Kubernetes ConfigMaps or Secrets, Cloudflare bindings, Vite, Next.js, Astro, SvelteKit, Tauri, Node, Bun, generated env types, .env examples, config docs, or config validation behavior are created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.config-env-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Config Env Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep configuration and environment changes from leaking secrets, freezing runtime values at build time, or drifting across local, CI, and deployment surfaces.
+
+A config or env change is not just adding a key. It is deciding who can see the value, when the value is fixed, where the value is validated, how errors are redacted, and which deployment surfaces must change together.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task adds, removes, renames, defaults, validates, documents, or reports an env var, secret, config key, feature flag, runtime setting, build define, platform binding, or deploy variable.
+- Code reads from `process.env`, `import.meta.env`, `Bun.env`, framework env helpers, worker bindings, CI variables, Docker env, Kubernetes env, platform env stores, mobile or desktop packaged config, or app updater config.
+- A change touches `.env.example`, `.env.template`, `.env.test`, `.dev.vars.example`, config schemas, config parsers, generated env types, deployment docs, CI workflow env, Docker Compose env, Kubernetes ConfigMap or Secret, Terraform or Pulumi env wiring, or hosting provider config.
+- A final report claims a config key is public, private, runtime, build-time, optional, required, secret, safe to expose, changed without rebuild, or controlled by a feature flag.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes product behavior behind an existing config value and the config contract is untouched.
+- The task only edits command-intent environment policy in `.mustflow/config/commands.toml`. Use `command-contract-authoring` for that primary scope.
+- The task only reviews a broad sensitive-data change without config or env surfaces. Use `security-privacy-review`.
+- The task only changes release publication variables for a remote registry or channel. Use `release-publish-change` for that primary scope and this skill only if env behavior itself changes.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Key name, value meaning, sensitivity, visibility, timing, required environments, owner, default, validation shape, and removal or deprecation plan if replacing another key.
+- Read-first surfaces: env examples, config schema or parser, runtime config loader, framework env conventions, CI variables or secrets, Docker or Compose config, Kubernetes or cloud config, typed env helpers, deployment docs, and tests.
+- Platform timing: build-time, startup runtime, request runtime, command runtime, tenant runtime, packaged-app time, or provider-evaluated feature flag.
+- Visibility boundary: server-only, client bundle, static asset, sourcemap, mobile app, desktop app, container image, CI log, cloud dashboard, telemetry, or user-visible docs.
+- Verification options from the command contract for config validation, build, tests, docs, package or template release, and secret redaction checks.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and the command contract have been checked for the current scope.
+- The config source of truth is identified before editing. If several files define the same key differently, resolve authority before adding another copy.
+- Real secrets are not read, printed, copied, committed, or requested unless the user explicitly authorizes a secret-handling task and the active rules allow it.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update config schemas, parser code, runtime loader wiring, generated type expectations, example env files with fake values, deployment docs, tests, CI or deployment variable names, and feature-flag defaults directly required by the config change.
+- Add redacted validation errors that name the key and expected shape without printing the value.
+- Add migration aliases, deprecation warnings, or removal notes when replacing keys.
+- Do not commit real `.env` files, private keys, tokens, service account JSON, production connection strings, or secret values.
+- Do not add unchecked raw env reads outside the central parser unless the repository already has a narrower pattern and the exception is documented.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the value before editing:
+   - Sensitivity: public config, private server secret, credential, internal topology, business rule, user-specific setting, or feature flag.
+   - Visibility: server-only, client bundle, static output, packaged mobile or desktop app, container image, CI log, telemetry, or docs.
+   - Timing: build-time, startup runtime, request runtime, command runtime, tenant runtime, packaged-app time, or feature-flag provider runtime.
+   - Mutation action after value change: no action, process restart, pod rollout, container redeploy, static rebuild, app rebuild, store release, or flag flip.
+2. Read existing env and config surfaces before adding a key.
+   - Env examples and test env files.
+   - Config schema or parser.
+   - Runtime loader and central config object.
+   - Framework env helpers and bundler defines.
+   - CI, Docker, Compose, Kubernetes, cloud platform, and hosting provider wiring.
+   - Generated env types and docs.
+   - Tests for missing, malformed, defaulted, successful, and redacted behavior.
+3. Treat public prefixes as exposure markers, not security.
+   - `VITE_`, `NEXT_PUBLIC_`, `PUBLIC_`, client env, frontend build defines, static JSON, mobile resources, and desktop app resources are public or effectively public.
+   - Do not put secrets, privileged internal URLs, signing keys, service credentials, tenant maps, entitlement gates, pricing gates, webhook secrets, or admin tokens in public or packaged surfaces.
+4. Separate build-time from runtime.
+   - Values inlined into frontend bundles, static builds, package resources, or build defines usually require rebuild and redeploy to change.
+   - Runtime values read from server process env, worker bindings, platform secrets, mounted secret volumes, or provider flags may still require restart, pod rollout, or deployment depending on platform.
+   - Do not promise that changing an env var will affect already built client JavaScript, static HTML, mobile apps, desktop apps, or container image defaults.
+5. Validate through the central parser.
+   - Parse booleans explicitly. The string `false` must not become truthy behavior.
+   - Validate numbers with ranges, URLs with protocol and host expectations, paths with safe path rules, enums with allowlists, and secrets with presence and format checks only.
+   - Keep validation errors redacted. Show key name and expected shape, not actual value.
+6. Update every dependent surface for a new key.
+   - Schema validation, runtime loader, type definitions, safe defaults, fake-value env examples, local setup docs, deploy docs, tests, CI variables or secrets, Docker or Compose, Kubernetes or cloud config, observability redaction, and rollback or restart notes.
+   - If a surface is not updated because it is outside scope, report it as deferred with risk.
+7. Handle framework-specific env boundaries conservatively.
+   - Vite and Next public prefixes are client bundle exposure.
+   - SvelteKit static env helpers are build-time; dynamic helpers are runtime.
+   - Astro env should distinguish client or server and public or secret schema.
+   - Cloudflare Worker secrets and bindings arrive through runtime `env`; plaintext vars are not secret storage.
+   - Docker `ARG` and baked `ENV` are not secret storage.
+   - Compose interpolation env is not the same as container env.
+   - Kubernetes env vars are captured at pod start; mounted config may update differently.
+   - Tauri, mobile, and desktop packaged config should be treated as public because users can inspect app artifacts.
+8. Treat feature flags as contracts.
+   - The default value is real product behavior when the provider is down, cache is empty, or local dev is offline.
+   - Kill switches should be runtime-controllable unless the runbook explicitly accepts rebuild delay.
+   - Rollouts should use stable user, tenant, org, or device keys, not per-request randomness.
+   - Sensitive authorization must use server evaluation as source of truth.
+   - New flags need owner, expiry or cleanup issue, default, provider-down behavior, and client/server divergence tests when relevant.
+9. Detect config drift.
+   - Schema key missing from examples.
+   - Deploy key missing from schema.
+   - Secret-looking key with public prefix.
+   - Runtime docs for a build-time value.
+   - Staging missing keys required in production.
+   - Tests depending on private `.env.local`.
+   - Compose `.env` used for interpolation but not passed into the container.
+   - Kubernetes env var changed with no rollout note.
+   - Worker binding only present in production.
+   - Mobile or desktop package containing privileged credentials.
+10. Keep fallbacks safe.
+   - Local and test defaults must not silently connect to production services.
+   - Optional integrations may validate lazily, but must fail clearly at first use.
+   - Core values such as database, auth, session, encryption, signing, queue, and required external APIs should fail fast at startup or command start.
+11. Select verification from configured command intents. Prefer config validation, build, typecheck, related tests, docs validation, release/package checks, and secret-redaction checks when exposed by the command contract. Do not infer raw package manager, cloud, Docker, Kubernetes, or CI commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Each changed key has sensitivity, visibility, timing, validation, default, owner, required environments, and change-action classification.
+- Schema, loader, examples, docs, generated types, tests, CI/deploy surfaces, and redaction behavior are synchronized or explicitly deferred.
+- Public prefixes and packaged app surfaces contain no secrets.
+- Build-time and runtime behavior are described accurately.
+- Feature flag defaults and provider-down behavior are classified when flags are involved.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer narrower configured config-schema, env-validation, type-generation, deployment-doc, release-template, and secret-redaction intents when the command contract exposes them.
+
+Do not infer commands from package manager files, Docker files, cloud config, framework config, or CI workflow names. Report missing command-intent coverage instead.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a value might be secret and the visibility is unclear, classify it private until proven public.
+- If build-time or runtime timing is unclear, do not promise hot config changes. Report the rebuild, restart, redeploy, rollout, or release uncertainty.
+- If schema, example, docs, tests, and deploy surfaces disagree, fix the source of truth first and report any deferred surface.
+- If validation would print a value, redact it before continuing.
+- If a feature flag default is unknown, do not claim provider-down behavior is safe.
+- If a real secret appears in tracked files, stop ordinary work and report the secret exposure according to repository security rules.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Keys or flags changed
+- Sensitivity, visibility, timing, and required action after value change
+- Source of truth and synchronized surfaces
+- Public/private boundary and redaction notes
+- Build-time versus runtime classification
+- Feature flag default and provider-down behavior when relevant
+- Command intents run
+- Skipped checks and reasons
+- Remaining config/env risk

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

@@ -0,0 +1,199 @@
+---
+mustflow_doc: skill.css-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: css-code-change
+description: Apply this skill when CSS, Sass, Less, CSS Modules, CSS-in-JS, global styles, cascade layers, selector specificity, design tokens, layout, responsive behavior, focus styles, animation, color, or component styling are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.css-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# CSS Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve cascade order, specificity discipline, resilient responsive layout, design tokens, focus visibility, contrast, reduced motion, browser compatibility, and layout stability. Treat CSS as a long-lived system, not a screenshot patch.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.css`, Sass, Less, CSS Modules, CSS-in-JS, global styles, reset, theme variables, cascade layers, selectors, design tokens, component styles, animations, or responsive rules change.
+- The task touches specificity, `!important`, inline styles, negative margins, layout shift, browser compatibility, dark mode, focus style, contrast, typography, zoom, text scaling, or motion preference.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Styling is entirely Tailwind utility usage; use `tailwind-code-change`.
+- Styling is entirely UnoCSS utility usage; use `unocss-code-change`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Global CSS entrypoints, reset/base styles, cascade layer strategy, token files, theme config, component CSS, parent layout styles, browserslist, build config, and style lint config.
+- Existing responsive, dark mode, accessibility, focus, reduced-motion, breakpoint, and design-token conventions.
+- Target surfaces for narrow viewports, 200% zoom, text scaling, delayed media, third-party markup, and browser compatibility.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Identify the cascade layer, selector scope, token source, layout constraints, and browser target before editing.
+- Prefer low-specificity selectors, parent layout fixes, and existing semantic tokens.
+- Identify whether the style belongs in global CSS, token/theme CSS, component-scoped CSS, CSS Modules, or a third-party wrapper.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add styles in the correct layer or module.
+- Use class-level selectors, custom properties, design tokens, intrinsic sizing, flex, grid, container queries, or media queries according to local patterns.
+- Preserve visible focus, contrast, text scaling, reduced motion, and reserved space for late-loaded media.
+- Use narrow exceptions for legacy/third-party markup, runtime geometry, rich text/prose wrappers, and urgent accessibility overrides when lower-specificity or token-based fixes cannot solve the issue.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read global style entrypoints, tokens, component styles, parent layout styles, and build/lint config.
+2. Map the cascade: reset, base, tokens, layout, components, utilities, overrides.
+3. Do not patch visible symptoms with stronger specificity. Resolve conflicts by checking layer order, import order, token choice, component boundary, parent layout, and selector scope first.
+4. Do not add ID selectors for styling, selectors with more than two combinators, or new `!important` unless an allowed exception is documented.
+5. Do not use negative margin to repair normal content flow. Fix parent layout, spacing, alignment, or intrinsic sizing instead.
+6. Do not add inline styles for color, spacing, typography, focus, dark mode, or responsive layout. Inline styles are for runtime geometry such as drag positions, virtualized offsets, and measured canvas/SVG values.
+7. Use existing color, spacing, font, radius, shadow, z-index, and breakpoint tokens before adding literals.
+8. Keep raw color values out of component CSS. Add or reuse semantic tokens for surfaces, text, borders, actions, danger states, focus, disabled states, and dark mode.
+9. Avoid raw pixel values for typography, spacing, layout dimensions, and radius. Allow narrow values such as one-pixel borders, intrinsic icon/media dimensions, and established breakpoint tokens.
+10. Make layout responsive through constraints, `min-width: 0`, min/max sizing, flex/grid, wrapping, gap, intrinsic media dimensions, container/media queries, and content-based rules rather than fixed viewport assumptions.
+11. Do not set fixed width on page, section, container, card, modal, or form layouts. Do not set fixed height on components that contain text.
+12. Do not use viewport-only typography. Use bounded responsive type patterns that survive small screens and large displays.
+13. Do not use `overflow: hidden` to hide layout bugs. Allow it only for intentional clipping such as avatars, media crops, masks, or animation containers.
+14. Reserve dimensions or aspect ratio for images, videos, iframes, ads, embeds, skeletons, fonts, and lazy content that could cause layout shift.
+15. Preserve visible focus, sufficient contrast, 200% text resize behavior, text-spacing stress, keyboard navigation, and reduced-motion behavior.
+16. If hover styling changes an interactive affordance, provide a matching focus-visible affordance.
+17. Prefer outline and outline-offset for focus indicators. Do not rely only on shadows when ancestors may clip overflow.
+18. Respect reduced motion for parallax, large transforms, auto-scroll, route transitions, autoplay carousels, skeleton shimmer, and looping decorative animation.
+19. Check browser compatibility before adding new CSS features. Use progressive enhancement for newly available features and avoid limited-availability features unless the project browser target allows them.
+20. Choose configured verification intents that cover style lint, build, visual states, accessibility, and browser target risk when available.
+
+<!-- mustflow-section: cascade-specificity-policy -->
+## Cascade And Specificity Policy
+
+- Keep component styling overrideable with low-specificity class selectors.
+- Do not use IDs as styling weight. IDs are for anchors, form/ARIA relationships, or JavaScript hooks.
+- Do not write DOM-path selectors that break when markup gains or loses a wrapper.
+- Use low-specificity contextual selectors for rich text or CMS areas. Prefer patterns that keep specificity easy to override.
+- Do not add global overrides for local component problems when component-scoped styling or tokens can solve the issue.
+- New `!important` requires an explicit exception for immutable third-party/legacy markup, third-party inline style override, urgent accessibility protection, or equivalent narrow reason.
+
+<!-- mustflow-section: responsive-layout-policy -->
+## Responsive Layout Policy
+
+- Layout must survive narrow screens, 200% zoom, increased text size, longer localized text, delayed media loading, and reduced motion.
+- Prefer fluid width plus max constraints over fixed width.
+- Prefer min-height, padding, and line-height over fixed height for text-containing controls.
+- Prefer content-based layout, flex/grid, `minmax`, wrapping, and `clamp` over breakpoint patching.
+- Avoid `100vw` except for deliberate full-bleed designs; otherwise prefer normal containing-block width.
+- Avoid absolute positioning for normal document flow. Use it only for overlays, decorative placement, controls anchored to known boxes, or measured geometry.
+
+<!-- mustflow-section: token-accessibility-policy -->
+## Token And Accessibility Policy
+
+- Name visual values by role, not by raw color or numeric value.
+- Search existing tokens before adding a value. If a new value has product meaning, theme impact, repeated use, or dark-mode behavior, add it at the token source.
+- Body text and normal UI text should meet the project contrast target; large text and meaningful non-text UI indicators must remain distinguishable against adjacent colors.
+- Do not communicate state by color alone. Pair color with text, icon shape, border, position, or another non-color signal when meaning matters.
+- Never remove focus indication without replacing it in the same change.
+- Verify focus, error, selected, disabled, hover, active, and dark-mode states when token or component color changes.
+
+<!-- mustflow-section: browser-compatibility-policy -->
+## Browser Compatibility Policy
+
+- New CSS features require browser-target awareness before use.
+- Widely supported features may be used normally.
+- Newly available features need a fallback or progressive enhancement path.
+- Limited-availability features are blocked unless the repository browser target explicitly allows them.
+- Feature queries are enhancements only. Keep an accessible fallback outside the query and layer the new behavior inside it.
+
+<!-- mustflow-section: exception-policy -->
+## Exception Policy
+
+Allowed exceptions include:
+
+- Legacy or third-party markup that cannot be changed.
+- Runtime geometry such as drag positions, virtualized list offsets, canvas/SVG measurements, or measured transforms.
+- Accessibility emergency overrides such as focus visibility or reduced-motion protection.
+- Rich text, CMS, or prose styling scoped to a wrapper with low specificity.
+- Essential two-dimensional layouts such as data tables, maps, diagrams, code blocks, canvas, games, and design tools.
+
+Every exception must explain why a lower-specificity, token-based, or layout-level fix is not enough and must include a removal condition when practical.
+
+<!-- mustflow-section: review-rejection-criteria -->
+## Review Rejection Criteria
+
+Reject the change when:
+
+- It adds styling ID selectors, long descendant chains, or unexplained `!important`.
+- It repairs normal document flow with negative margins or absolute positioning.
+- It uses fixed width for containers or fixed height for text-containing UI.
+- It hides layout bugs with `overflow: hidden`.
+- It adds unsized media, embeds, ads, or lazy content that can shift layout.
+- It hardcodes raw component colors, spacing, font sizes, radius, or shadows without an exception.
+- It removes focus styling, creates hover-only affordances, or clips the focus indicator.
+- It adds motion without reduced-motion behavior.
+- It uses a new CSS feature without compatibility/fallback review.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Selectors remain maintainable and low-specificity.
+- Tokens are used or new literals are justified.
+- Responsive, zoom, text-scaling, focus, contrast, motion, compatibility, and layout-shift risks are checked or reported.
+- Exceptions are narrow, explained, and not used as a normal styling path.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report missing visual, accessibility, or browser compatibility verification intents when relevant.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a style requires `!important` or high specificity, inspect the cascade conflict before adding it.
+- If a raw token is missing, report whether a token should be added or the existing system should be reused.
+- If visual verification is unavailable, report the unverified viewport, zoom, contrast, or motion states.
+- If layout only works for the current screenshot, stop and rework it around content, constraints, and parent layout.
+- If a new CSS feature fails in the target browser or WebView, add a fallback or remove the feature.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Cascade, token, and responsive notes
+- Accessibility and layout-stability notes
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining CSS risk