mustflow 2.84.0 → 2.99.0

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.astro-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: astro-code-change
-description: Apply this skill when Astro config, pages, layouts, components, islands, hydration directives, content collections, dynamic routes, adapters, MDX, RSS, sitemap, canonical URL, draft, pagination, or build behavior are created or changed.
+description: Apply this skill when Astro config, package metadata, pages, layouts, components, islands, hydration directives, content collections, dynamic routes, adapters, request pipeline, advanced routing, route cache, MDX, Markdown processing, RSS, sitemap, canonical URL, draft, pagination, migration, or build behavior are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -28,15 +28,15 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Preserve Astro's static-first model, island hydration boundary, routing contract, content collection schema, canonical URL, RSS, sitemap, adapter, and client bundle boundaries.
+Preserve Astro's static-first model, island hydration boundary, routing contract, request pipeline, content collection schema, canonical URL, RSS, sitemap, adapter, cache, and client bundle boundaries.
 
 The default is no-hydration. Add browser JavaScript only after proving that native HTML, CSS, standard links, forms, details/summary, or a small `.astro` script cannot provide the required behavior.
 
 <!-- mustflow-section: use-when -->
 ## Use When
 
-- `astro.config.*`, `src/pages`, `.astro`, content config, live config, collections, layouts, components, MDX, routes, endpoints, adapters, integrations, islands, or hydration directives change.
-- The task adds or changes a page, blog/docs content, interactive UI, SSR/on-demand rendering, framework component, search/filter UI, route behavior, RSS feed, sitemap, canonical URL, draft handling, or pagination.
+- `astro.config.*`, package metadata, `src/pages`, `src/fetch.*`, `.astro`, content config, live config, collections, layouts, components, MDX, Markdown processor config, routes, endpoints, adapters, integrations, islands, route cache, or hydration directives change.
+- The task adds or changes a page, blog/docs content, interactive UI, SSR/on-demand rendering, framework component, search/filter UI, request pipeline behavior, route behavior, RSS feed, sitemap, canonical URL, draft handling, migration, or pagination.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -47,20 +47,23 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
 
-- Package metadata, Astro version, framework integrations, TypeScript config, pages, layouts, components, content config, content files, integrations, adapter config, env declarations, public assets, and tests.
-- Astro config values that affect routing and URLs: `site`, `base`, `trailingSlash`, `output`, `adapter`, sitemap integration, MDX integration, and framework integrations.
+- Package metadata, current Astro version, target Astro version when migration is intended, framework integrations, TypeScript config, pages, layouts, components, content config, content files, integrations, adapter config, env declarations, public assets, and tests.
+- Astro config values that affect routing, URLs, rendering, request handling, Markdown, and cache: `site`, `base`, `trailingSlash`, `output`, `adapter`, `fetchFile`, `markdown`, `compressHTML`, `cache`, `routeRules`, sitemap integration, MDX integration, and framework integrations.
 - Content collection names, loader bases, schemas, slug/id policy, draft fields, date fields, canonical fields, and route files that turn collection entries into pages.
-- Current output mode, prerender/SSR policy, hydration conventions, route priority, endpoint layout, RSS generation, sitemap generation, and content schema.
+- Current output mode, prerender/SSR policy, hydration conventions, route priority, endpoint layout, request pipeline or middleware layout, RSS generation, sitemap generation, and content schema.
+- Markdown processor decision, remark/rehype/recma plugins, custom Markdown imports, heading id policy, syntax-highlighting expectations, and Markdown or MDX snapshots when content rendering changes.
+- Cache provider, route cache rules, cache-key inputs, invalidation path, deployment topology, and authenticated or personalized routes when `cache` or `routeRules` change.
 - Configured verification intents.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
 
 - Read Astro config, content config, and the affected route tree before changing routing, content, canonical, RSS, sitemap, or hydration behavior.
-- Identify the Astro major version before applying migration rules. Astro v6 changes must be checked against the v6 upgrade guide instead of inferred from older routing or adapter habits.
+- Identify current and target Astro major versions before applying migration rules. Apply only the official major upgrade guide deltas crossed by the change, and keep ordinary Astro edits on the version-neutral policies below.
 - Identify build-time versus request-time data before adding data access.
 - Identify which UI truly needs browser JavaScript and which UI truly needs framework state before adding a framework island.
 - Treat file movement under `src/pages`, route parameter changes, and content slug changes as URL contract changes.
+- Treat `src/fetch.ts` and `src/fetch.js` as reserved advanced-routing entrypoint candidates unless `fetchFile` disables or moves that entrypoint.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -73,18 +76,23 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Read package metadata and Astro config first. Record Astro version, framework integrations, `site`, `base`, `trailingSlash`, `output`, adapter, sitemap integration, MDX integration, and any framework integration.
-   - For Astro v6 migrations, check removed or changed surfaces before editing call sites: `Astro.glob()` replacement with `import.meta.glob()` or content collections, `.cjs` and `.cts` config removal, `astro:ssr-manifest`, `RouteData.generate()`, old adapter hooks, old `NodeApp` paths, Zod 4 schema effects, and numeric dynamic route params.
-2. Read `src/content.config.*` when content, docs, blog, RSS, sitemap, canonical, or route generation is involved. Record each collection name, loader base, schema fields, slug/id policy, draft field, and date fields.
-3. Build a route ledger from `src/pages`: static pages, dynamic pages, rest routes, endpoints, prerendered routes, on-demand routes, and possible route-priority collisions.
-4. Classify the change: static route, dynamic route, endpoint, content collection, integration, adapter, SSR/on-demand, island, script, asset, RSS, sitemap, canonical, or docs/content.
-5. Apply the hydration policy below before adding or changing any `client:*` directive.
-6. Apply the routing and rendering policy below before adding dynamic routes, catch-all routes, endpoints, adapter changes, or `prerender` changes.
-7. Apply the content, SEO, and feed policy below before changing frontmatter, schemas, slugs, drafts, canonical URLs, pagination, RSS, or sitemap behavior.
-8. Do not put runtime-only data such as logged-in user state, request-local data, private API responses, or live inventory into build-time collections.
-9. Do not enable request-time rendering without the adapter and deployment contract that support it.
-10. Keep `set:html` or raw HTML injection behind a trusted and sanitized content boundary.
-11. Choose configured verification intents that cover content schema, build, routes, hydration, adapter/runtime, and bundle risk when available.
+1. Read package metadata and Astro config first. Record current and target Astro versions, framework integrations, `site`, `base`, `trailingSlash`, `output`, adapter, `fetchFile`, `markdown`, `compressHTML`, `cache`, `routeRules`, sitemap integration, MDX integration, and any framework integration.
+2. Apply the Version Gate before using migration guidance:
+   - If the task is not changing the Astro major version, do not run stale major-specific deltas as routine review noise.
+   - If the task crosses one or more Astro majors, check the official Astro upgrade guide for each crossed major and record which deltas apply.
+   - If a version-specific claim cannot be refreshed from official Astro docs, omit it or report it as unchecked instead of writing it as current.
+3. Read `src/content.config.*` when content, docs, blog, RSS, sitemap, canonical, or route generation is involved. Record each collection name, loader base, schema fields, slug/id policy, draft field, and date fields.
+4. Build a route ledger from `src/pages`: static pages, dynamic pages, rest routes, endpoints, prerendered routes, on-demand routes, and possible route-priority collisions.
+5. Classify the change: static route, dynamic route, endpoint, content collection, integration, adapter, SSR/on-demand, request pipeline, island, script, asset, RSS, sitemap, canonical, cache, Markdown, migration, or docs/content.
+6. Apply the hydration policy below before adding or changing any `client:*` directive.
+7. Apply the routing, request pipeline, and rendering policies below before adding dynamic routes, catch-all routes, endpoints, adapter changes, `src/fetch.*`, or `prerender` changes.
+8. Apply the content, SEO, and feed policy below before changing frontmatter, schemas, slugs, drafts, canonical URLs, pagination, RSS, or sitemap behavior.
+9. Apply the cache policy below before changing `cache`, `routeRules`, route-level cache behavior, or cache provider configuration.
+10. Apply the Markdown and compiler policy below before changing Markdown processing, MDX, generated markup, `compressHTML`, HTML snapshots, or whitespace-sensitive content.
+11. Do not put runtime-only data such as logged-in user state, request-local data, private API responses, or live inventory into build-time collections.
+12. Do not enable request-time rendering without the adapter and deployment contract that support it.
+13. Keep `set:html` or raw HTML injection behind a trusted and sanitized content boundary.
+14. Choose configured verification intents that cover content schema, build, routes, hydration, adapter/runtime, cache, Markdown, request pipeline, and bundle risk when available.
 
 ## Hydration Policy
 
@@ -102,7 +110,7 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 
 - In static output, every dynamic route must have `getStaticPaths`.
 - In on-demand or SSR dynamic routes, do not use `getStaticPaths`; read `Astro.params`, perform the request-time lookup, and handle missing entries with an explicit 404 or redirect path.
-- `getStaticPaths` params must match bracket parameter names exactly. Param values must be strings, except rest parameters may use `undefined`; numeric params are invalid in Astro 6.
+- `getStaticPaths` params must match bracket parameter names exactly. Route param values are a string contract; rest parameters may use `undefined`.
 - Custom slugs containing `/` require a rest route such as a catch-all route. Do not force slash-containing slugs into a single named parameter route.
 - Treat changes under `src/pages` as public URL changes, including endpoint names and extension-bearing endpoint paths.
 - Check route priority when adding static routes, named parameters, rest parameters, catch-all routes, and endpoints that could claim the same URL.
@@ -111,6 +119,35 @@ The default is no-hydration. Add browser JavaScript only after proving that nati
 - Do not switch the whole project to server output for one page unless the deployment and route contract require it.
 - Do not assume SSR dynamic routes appear in sitemap output automatically.
 
+## Request Pipeline Policy
+
+- Do not create `src/fetch.ts` or `src/fetch.js` just because a project uses Astro 7 or advanced routing. Add or modify a custom fetch entrypoint only when the request pipeline contract requires it.
+- If `src/fetch.*` already exists, check whether it is an intentional advanced-routing entrypoint, an accidental reserved-name collision, or disabled or moved through `fetchFile`.
+- Prefer preserving Astro's default request pipeline unless there is a named reason to compose handlers directly.
+- When direct handler composition is used, record a request pipeline ledger: trailing slash, redirects, sessions, actions, user middleware, rendering, i18n, cache, and any intentionally omitted stage.
+- Place session handling before any handler that reads or mutates session state.
+
+## Cache Policy
+
+- Treat `cache` and `routeRules` changes as data-exposure risks, not only performance changes.
+- Do not cache authenticated, personalized, locale-sensitive, cookie-dependent, header-dependent, or query-dependent responses unless the cache key, invalidation, and privacy boundary are explicit.
+- Check whether the deployment is single-instance or multi-instance before relying on in-memory route cache behavior.
+- When route cache behavior changes, use `cache-integrity-review` as an adjunct when available and report `HIT`, `MISS`, `STALE`, or equivalent cache evidence only when verified.
+
+## Markdown And Compiler Policy
+
+- When an Astro major migration changes Markdown processing, choose explicitly between the current processor and the new default processor. Keep the unified pipeline when remark, rehype, recma, MDX, or custom Markdown plugin compatibility is unproven.
+- Check heading ids, code blocks, syntax highlighting, link rewriting, frontmatter rendering, and Markdown or MDX snapshots when the processor changes.
+- Treat stricter compiler output, invalid HTML nesting, non-void tag closure, CSS serialization, and whitespace between inline elements as user-visible migration risks.
+- When `compressHTML` changes or defaults differ, verify important rendered text does not lose intended spaces between inline elements.
+
+## Astro Major Migration Deltas
+
+- For v5 to v6 migrations, check removed or changed surfaces before editing call sites: `Astro.glob()` replacement with `import.meta.glob()` or content collections, `.cjs` and `.cts` config removal, `astro:ssr-manifest`, `RouteData.generate()`, old adapter hooks, old `NodeApp` paths, Zod 4 schema effects, and numeric dynamic route params.
+- For v6 to v7 migrations, check `src/fetch.*` or `fetchFile`, direct request handler composition, `cache`, `routeRules`, `advancedRouting`, `logger`, `queuedRendering`, `rustCompiler`, `markdown.processor`, `compressHTML`, removed or changed `@astrojs/db` usage, transition internals, and `getContainerRenderer()` imports from integration roots.
+- For v6 to v7 migrations with custom Vite config, Rollup hooks, or Astro integrations that call Vite APIs, also use `dependency-upgrade-review` when available.
+- Keep each migration delta scoped to the crossed major version. Do not copy old delta checks into ordinary Astro UI, content, or route edits.
+
 ## Content SEO Feed Policy
 
 - Every frontmatter field used by routes, SEO, RSS, sitemap, pagination, filtering, or canonical URLs must be declared in the content collection schema.
@@ -134,8 +171,12 @@ Reject or revise a change when:
 - `client:only` is used because SSR broke, instead of isolating the browser-only dependency.
 - Static output dynamic routes lack `getStaticPaths`.
 - On-demand or SSR dynamic routes use `getStaticPaths`.
-- Route params do not match bracket names, non-rest params are not strings, rest params use values other than strings or `undefined`, or Astro 6 routes still rely on numeric params.
+- Route params do not match bracket names, non-rest params are not strings, or rest params use values other than strings or `undefined`.
 - A content slug with `/` is mapped through a non-rest route.
+- `src/fetch.*` is added without a named request pipeline requirement, or direct handler composition omits a needed pipeline stage.
+- Route cache is enabled for authenticated, personalized, locale-sensitive, cookie-dependent, header-dependent, or query-dependent responses without an explicit cache key and invalidation boundary.
+- Markdown processor changes skip plugin compatibility or rendered-output checks.
+- Compiler or `compressHTML` changes are accepted without checking invalid HTML nesting, non-void tag closure, CSS serialization, or whitespace-sensitive rendered text when those surfaces are affected.
 - Draft filtering differs between lists, detail pages, RSS, sitemap, or pagination.
 - Canonical URLs are built by ad hoc string concatenation.
 - RSS or sitemap includes drafts, stale paths, wrong trailing slash paths, or paths that the route ledger cannot produce.
@@ -147,7 +188,7 @@ Reject or revise a change when:
 
 - Build-time and runtime data are separated.
 - Client JavaScript is limited to needed islands.
-- Route, endpoint, canonical URL, RSS, sitemap, draft, and content schema impact is known.
+- Route, endpoint, request pipeline, cache, canonical URL, RSS, sitemap, draft, Markdown, and content schema impact is known.
 - SSR or adapter changes are verified or reported.
 
 <!-- mustflow-section: verification -->
@@ -162,15 +203,18 @@ Use configured oneshot command intents when available:
 - `docs_validate_fast`
 - `mustflow_check`
 
-Report missing framework validation, route preview, content schema, RSS, sitemap, canonical, or client bundle verification intents when relevant.
+Report missing framework validation, route preview, request pipeline, cache, Markdown, content schema, RSS, sitemap, canonical, or client bundle verification intents when relevant.
 
-When verifiable, report counts for added hydration directives, added island risk, generated public content pages, excluded drafts, RSS items, sitemap URLs, and duplicate canonical URLs.
+When verifiable, report counts for added hydration directives, added island risk, generated public content pages, excluded drafts, RSS items, sitemap URLs, duplicate canonical URLs, route cache rules, and affected Markdown or MDX outputs.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
 
 - If an island is added only to work around static markup, revisit the markup and content boundary first.
 - If SSR is requested without adapter evidence, stop and report the deployment contract gap.
+- If custom request pipeline work lacks a pipeline ledger, create the ledger before changing unrelated routing or middleware.
+- If cache rules can expose private or personalized data, stop and route through cache integrity review before optimizing performance.
+- If Markdown processor compatibility is unknown, keep the existing processor path or report the migration blocker.
 - If content schema drift appears, fix schema and sample content before adding more pages.
 - If draft, canonical, RSS, sitemap, or pagination drift appears, fix the shared content and route contract before adding new entries.
 - If a route collision appears, resolve the route ledger before changing unrelated rendering code.
@@ -179,7 +223,7 @@ When verifiable, report counts for added hydration directives, added island risk
 ## Output Format
 
 - Boundary checked
-- Build/runtime, route, endpoint, content, hydration, canonical, RSS, sitemap, and draft notes
+- Build/runtime, route, endpoint, request pipeline, cache, Markdown, content, hydration, canonical, RSS, sitemap, and draft notes
 - Files changed
 - Command intents run
 - Skipped checks and reasons

package/templates/default/locales/en/.mustflow/skills/auth-flow-triage/SKILL.md

@@ -0,0 +1,192 @@
+---
+mustflow_doc: skill.auth-flow-triage
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: auth-flow-triage
+description: Apply this skill when login, signup, logout, session refresh, OAuth or OIDC redirect, PKCE, nonce, state, passkey, MFA, password reset, magic link, cookie, JWT, token exchange, JWKS, IdP callback, account linking, or authorization-after-login behavior is failing, intermittent, browser-only, client-specific, or not yet localized to identity, cookie, token, proxy, session store, provider, clock, rate limit, or permission policy.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.auth-flow-triage
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Auth Flow Triage
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Localize authentication-flow failures without collapsing identity proof, session issuance, token
+validation, browser cookie behavior, external provider callbacks, MFA, and authorization into one
+"login is broken" bucket.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Login, signup, logout, refresh, password reset, magic link, MFA, passkey, OAuth, OIDC, SAML-like
+  handoff, API-key login, or account-linking behavior fails or behaves differently across clients.
+- A user appears authenticated on one boundary but logged out, forbidden, redirected, or assigned to
+  the wrong account on another boundary.
+- The failure may involve cookies, SameSite, CORS credentials, CSRF, proxy headers, redirect URI,
+  state, nonce, PKCE, authorization code exchange, JWT claims, JWKS rotation, refresh token
+  rotation, session storage, account lockout, rate limit, IdP metadata, passkeys, OTP, clocks, or
+  authorization after login.
+- The task is to diagnose or review an auth failure before the exact code owner is known.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is already localized to implementing or changing the permission model; use
+  `auth-permission-change`.
+- The task is specifically API object, property, or function authorization review; use
+  `api-access-control-review`.
+- The task is only generic API failure triage before any auth-specific signal exists; use
+  `api-failure-triage`.
+- The task asks for live credential testing, brute force, phishing simulation, or production token
+  collection. Stay within defensive code review, sanitized traces, and configured tests.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Auth attempt packet: observed time, timezone, trace or request id, client type, route, sanitized
+  request and response shape, redirect chain, status codes, user-facing message class, and result.
+- Stage ledger: user lookup, credential verification, external provider round trip, callback,
+  token exchange, session issue, cookie write, redirect, authorization decision, and logout or
+  revocation when relevant.
+- Token and session ledger: session id hash, token type, issuer, audience, subject, `jti`, `iat`,
+  `nbf`, `exp`, key id, refresh-token family state, cookie attributes, session-store key, and
+  revocation or rotation state.
+- Browser and proxy ledger: origin, host, forwarded proto and host, redirect URI, cookie domain and
+  path, SameSite, Secure, HttpOnly, CORS credentials, CSRF token, and proxy trust boundary.
+- Provider ledger: IdP issuer, discovery metadata, JWKS URI, registered redirect URIs, client id,
+  PKCE method, state, nonce, passkey RP ID, WebAuthn origin, MFA method, and provider error class.
+- Denial and privacy ledger: enumeration policy, lockout or rate-limit decision, internal result
+  code, public error message, redaction boundary, and denial-case tests.
+
+<!-- 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 `.mustflow/config/commands.toml` have been checked.
+- Secrets, tokens, OTPs, passwords, cookies, raw provider payloads, personal identifiers, and private
+  callback URLs are redacted before being written into docs, tests, commits, or reports.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten stage-specific result codes, safe trace ids, token validation, cookie settings,
+  proxy trust handling, redirect URI checks, PKCE, state, nonce, JWKS refresh behavior, session
+  rotation, refresh-token serialization, account-linking checks, passkey origin checks, MFA tests,
+  redaction, docs, fixtures, and denial-case tests.
+- Add focused tests that reproduce the sanitized failure stage, token claim mismatch, cookie
+  behavior, callback binding, refresh-token race, session fixation boundary, or account-linking
+  policy.
+- Do not add auth bypasses, broad CORS wildcards, loose redirect matching, disabled TLS checks,
+  widened clock skew, token logging, provider-console assumptions, or live credential probes.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split the symptom by stage before editing: user lookup, credential or passkey verification,
+   provider redirect, callback validation, token exchange, session issue, cookie persistence,
+   refresh, logout, and authorization-after-login.
+2. Preserve one sanitized failing attempt plus one success comparator. Compare the actual redirect
+   chain, cookies sent and set, status codes, provider error class, token type, and client version.
+3. Keep public and internal errors separate. Public messages should avoid account enumeration;
+   internal evidence should keep stable reason codes such as missing user, credential mismatch,
+   disabled account, MFA required, token expired, nonce mismatch, PKCE mismatch, and policy denied.
+4. Verify clocks before treating tokens as bad. Compare server epoch, token `iat`, `nbf`, `exp`,
+   OTP window, signed request timestamp, certificate validity, and applied clock skew.
+5. For browser-only failures, check actual cookie attributes, CORS credential behavior, CSRF,
+   redirect handling, preflight, duplicate cookie names, and whether the callback writes the cookie
+   on the host and path the app later uses.
+6. For proxy-backed apps, verify trusted forwarded headers, external URL calculation, secure cookie
+   detection, host allowlists, and callback URL generation. Do not trust arbitrary forwarded headers.
+7. For OAuth or OIDC, compare the exact registered and transmitted redirect URI, issuer, discovery
+   metadata, client id, state, nonce, PKCE method, code-verifier binding, token endpoint, and JWKS.
+8. For token validation, check signature, algorithm allowlist, key id refresh, issuer, audience,
+   authorized party when needed, subject, expiry, not-before, nonce, token type, and stale role or
+   permission claims.
+9. For refresh and logout failures, separate local cookie deletion, server session revocation,
+   refresh-token family state, access-token lifetime, IdP SSO session, and provider logout.
+10. For passkeys and MFA, check challenge one-time use, origin, RP ID, credential id, user handle,
+    user-verification flags, OTP reuse, recovery path, reauthentication, and registration or removal
+    policy.
+11. For account linking, use provider `issuer + subject` as the external identity key. Treat email
+    equality as weak evidence that requires an authenticated linking flow.
+12. If authentication succeeds but the user is still blocked, switch to `auth-permission-change` or
+    `api-access-control-review` and inspect tenant, resource, role, scope, stale cache, and token
+    claim freshness.
+13. Apply the smallest localized fix and rerun the narrowest configured intent that covers the
+    affected auth stage, denial case, docs, template, or package surface.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The failing auth stage is localized or named as an evidence gap.
+- Public error wording, internal reason codes, trace ids, session or token identifiers, and redaction
+  boundaries are explicit.
+- Cookie, proxy, redirect, token, JWKS, provider metadata, passkey, MFA, refresh, logout, rate limit,
+  and authorization-after-login checks are fixed or reported where relevant.
+- Any permission follow-up is routed to the narrower access-control skill instead of hidden inside
+  login debugging.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `test_audit`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured tests that cover the failing auth stage and denial behavior. Report
+missing browser cookie, provider callback, JWKS rotation, MFA, passkey, refresh-token race, and
+session-store integration evidence instead of inventing live auth probes.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the failing auth attempt cannot be captured safely, report the missing stage evidence instead
+  of changing auth code from guesses.
+- If sensitive values appear in evidence, stop repeating them and summarize the shape only.
+- If fixing the failure requires external IdP console changes, provider credentials, production
+  tokens, live email or SMS delivery, or browser automation outside the command contract, report the
+  manual boundary.
+- If configured verification fails, preserve the failing intent and output tail, then fix only the
+  localized auth stage or test contract.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Auth flow triaged
+- Failing stage, sanitized attempt packet, and success comparator
+- Cookie, proxy, redirect, provider, token, JWKS, session, refresh, logout, passkey, MFA, rate limit,
+  enumeration, and authorization-after-login findings
+- Fix applied or recommended
+- Evidence level: configured-test evidence, static review risk, manual-only, missing, or not
+  applicable
+- Command intents run
+- Skipped auth diagnostics and reasons
+- Remaining auth-flow risk

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.auth-permission-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 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, object-level access control, signed delivery URLs, credentialed event streams, or private cache behavior are created or changed.
+description: Apply this skill when authentication, authorization, permissions, roles, effective permissions, policy decisions, tenants, sessions, JWTs, OAuth or OIDC, API keys, route guards, admin access, database policies, object-level access control, signed delivery URLs, credentialed event streams, or private cache behavior are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -54,11 +54,20 @@ Authentication answers who the requester is. Authorization answers what that pri
 ## Required Inputs
 
 - Changed files, user goal, affected actors, protected resources, actions, tenants, roles, and status-code expectations.
+- Permission decision tuple for each changed protected action: subject, action, object, tenant or
+  organization, relationship path, request environment, policy version, data revision, token issue
+  time, and final allow or deny reason.
+- Effective-permission evidence, not only role names: computed capabilities, inherited
+  relationships, explicit denies, wildcard policies, policy-combination rules, and default-deny
+  behavior.
 - 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, SSE or streaming channels, WebTransport sessions, WebSocket fallback, CDN cache, proxy 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.
+- Revocation and cache evidence: token claim freshness, session lifetime, permission-cache key and
+  TTL, policy replication delay, search-index or export lag, stale queue payloads, and rollback or
+  shadow-evaluation behavior when policy changes.
 - Configured verification intents.
 
 <!-- mustflow-section: preconditions -->
@@ -92,31 +101,58 @@ Authentication answers who the requester is. Authorization answers what that pri
    - 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, SSE or streaming channels, WebTransport sessions, WebSocket fallback, search, autocomplete, caches, CDN or proxy cache rules, 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:
+4. Freeze the authorization decision tuple.
+   - Record subject, action, object, tenant, environment, policy version, data revision, token issue
+     time, matched policy, inheritance path, and final allow or deny reason.
+   - A role label is not the decision. Use effective permissions and relationship paths.
+5. 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:
+6. Prefer one central policy shape, such as a `can(principal, action, resource, context)` function, over route-local `isAdmin`, `isOwner`, or `isMember` fragments.
+7. Require explainable policy decisions.
+   - A production-supportable permission engine should expose which policy matched, which condition
+     failed, which inherited relationship granted access, and whether an explicit deny won.
+   - If the implementation cannot explain allow or deny decisions, report observability risk before
+     claiming the policy is maintainable.
+8. Enforce deny by default. New roles, actions, resource types, tenant types, sharing modes, and admin paths must deny until explicitly allowed.
+9. Define policy-combination semantics. Check whether multiple policies combine by union,
+   intersection, priority, explicit deny, boundary policy, or tenant override; write tests for
+   allow-plus-deny and no-match cases.
+10. Validate every request. Do not rely on login-time checks, client guards, disabled buttons, hidden menus, generated types, OpenAPI docs, or mobile local checks.
+11. 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:
+12. 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.
    - event streams, WebTransport sessions, WebSocket fallback channels, private downloads, and reconnect URLs must not bypass tenant, resource, role, token expiry, or revocation policy.
-10. Check session, JWT, OAuth/OIDC, and API key contracts when touched:
+13. 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.
+14. Check permission creators more strictly than ordinary permissions.
+    - Role creation, role assignment, invitation, service-account issuance, API-key creation,
+      impersonation, support access, and token minting are privilege factories.
+    - A low-privilege actor that can attach a high privilege to itself collapses the whole model.
+15. Check revocation time.
+    - Demotion, removal, suspension, role deletion, membership expiry, subscription cancellation,
+      and ownership transfer should say how long old sessions, JWT claims, caches, search indexes,
+      queued jobs, and replicas can keep authorizing the old state.
+    - Sensitive actions need server-side recheck, short-lived tokens, revocation lists, or policy
+      version gates when stale tokens would be harmful.
+16. 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.
     - For credentialed delivery surfaces, check whether EventSource can supply the intended credentials, whether CORS and cookies match the policy, whether signed URLs expire and scope correctly, and whether caches vary on auth, tenant, and private response dimensions.
-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.
+17. 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 token, stale cache, unknown role, unknown action, wildcard policy, explicit deny, shared-link, read-only API key, org admin, global admin, and impersonating admin cases as applicable.
+18. When changing policies, consider shadow evaluation.
+    - Compute old and new decisions side by side for representative requests before flipping broad
+      policy changes when the product has the infrastructure to do so.
+    - Log policy version and data revision for both decisions without exposing secrets or sensitive
+      object contents.
+19. Update docs and role matrices when external behavior, status codes, role names, permission names, admin scope, or API errors change.
+20. Report the policy source of truth, effective-permission evidence, decision explanation, server/database enforcement, client UX-only guards, revocation window, test coverage, skipped checks, and remaining permission risk.
 
 ## Boundary Rules
 
@@ -127,6 +163,10 @@ Authentication answers who the requester is. Authorization answers what that pri
 - 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.
+- Wildcard permissions are future permissions. Adding a new action under an old wildcard should be
+  treated as a permission expansion and reviewed accordingly.
+- Unknown roles, unknown actions, malformed identifiers, and missing relationship data deny by
+  default; they are not normalized into a normal user path.
 
 ## Strongly Forbidden Patterns
 
@@ -142,6 +182,9 @@ Authentication answers who the requester is. Authorization answers what that pri
 - 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.
+- Shipping a permission engine that cannot explain why a request was allowed or denied.
+- Treating an effective-permission bug as solved because the `role` column looks correct.
+- Treating token-embedded roles as fresh after demotion, removal, or policy version changes.
 - Creating shared links, signed URLs, exports, search results, or CDN responses outside tenant and resource policy.
 - Creating credentialed event streams, WebTransport sessions, WebSocket fallback channels, signed delivery URLs, or private caches outside tenant and resource policy.
 - Logging impersonation without separate actor and subject.
@@ -153,6 +196,8 @@ Authentication answers who the requester is. Authorization answers what that pri
 - 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.
+- Effective permissions, policy-combination rules, decision explanation, policy version, data
+  revision, and revocation window are explicit when relevant.
 - Client guards are described as UX only.
 - Session, token, OAuth/OIDC, API key, cache, audit, docs, migration, and tests are synchronized when touched.
 - Signed URL, event-stream, WebTransport, WebSocket fallback, CORS, cookie, CDN/proxy cache, and reconnect behavior remains inside the permission model when touched.
@@ -190,6 +235,7 @@ Prefer the narrowest configured test intent that covers the changed protected ac
 - Authentication versus authorization classification
 - Principal, tenant, resource, action, and context affected
 - Policy source of truth
+- Effective permission, policy version, data revision, decision explanation, and revocation window
 - Server/database enforcement notes
 - Client guard UX-only notes
 - Tenant, ownership, sharing, admin, token/session/API-key, cache, and audit notes

package/templates/default/locales/en/.mustflow/skills/backend-log-evidence-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.backend-log-evidence-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: backend-log-evidence-review
-description: Apply this skill when backend code is created, changed, reviewed, or reported and request logs, error logs, structured event names, log schema versions, trace/span/request IDs, correlation and causation IDs, outcome or reason fields, external API logs, database write logs, transaction or state-transition logs, retry or timeout logs, queue or batch logs, audit logs, auth or validation logs, cache or lock logs, release/config/feature-flag logs, log levels, duplicate logs, redaction, log-injection safety, sampling, or log searchability need review for whether an operator can reconstruct why a backend request, job, or data change reached its final state.
+description: Apply this skill when backend code is created, changed, reviewed, or reported and request logs, error logs, structured event names, log schema versions, trace/span/request IDs, correlation and causation IDs, outcome or reason fields, external API logs, database write logs, transaction or state-transition logs, retry or timeout logs, queue or batch logs, audit logs, auth or validation logs, cache or lock logs, release/config/feature-flag logs, log pipeline canaries, collector accepted/sent/stored counts, timestamp versus observed timestamp, parser or mapping failures, log levels, duplicate logs, redaction, log-injection safety, sampling, or log searchability need review for whether an operator can reconstruct why a backend request, job, or data change reached its final state and whether the evidence actually survived the logging pipeline.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -39,6 +39,7 @@ The review question is: "If this backend path fails, times out, retries, silentl
 - Backend handlers, services, repositories, adapters, workers, schedulers, webhooks, migrations, scripts, or batch jobs add, remove, review, or depend on logs.
 - A change claims that a path is logged, traceable, easy to debug, auditable, operationally safe, or diagnosable from logs.
 - Request start or finish logs, event names, schema versions, severity fields, trace or span IDs, error handling, error wrapping, external API calls, DB writes, transactions, status transitions, early returns, retries, timeouts, queues, async jobs, batches, audit events, auth, validation, cache, distributed locks, idempotency, feature flags, configuration, releases, migrations, or background promises are involved.
+- Log ingestion, parsing, buffering, shipping, storage, searchability, retention, rotation, multiline parsing, canary logs, dropped-log counters, timestamp skew, or log sink visibility affects whether backend evidence can be trusted.
 - A review needs to decide whether logs explain why the system reached a state, not only where the exception was thrown.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -60,6 +61,7 @@ The review question is: "If this backend path fails, times out, retries, silentl
 - Error evidence: thrown errors, catches, wrappers, causes, stack preservation, error categories, public versus internal messages, and log boundary ownership.
 - Decision evidence: branches, early returns, validation failures, auth decisions, feature flags, state transitions, cache paths, retry decisions, timeout classes, and fallback decisions.
 - Side-effect evidence: external API calls with dependency name, operation, timeout, latency, status class, retry count, circuit state, and provider request id; DB affected rows; transaction begin/commit/rollback evidence; queue enqueue and consume; idempotency decisions; locks; migrations; batch summaries; release/config/feature-flag events; and configuration snapshots.
+- Pipeline integrity evidence when logs leave the process: generated count, collector accepted count, exporter sent count, stored count, searchable count, canary event id, sequence gaps, duplicate rate, timestamp and observed timestamp drift, queue oldest age, DLQ oldest age, parser failures, mapping conflicts, dropped or sampled counts, rotation or restart boundary, multiline grouping, and storage retention boundary.
 - Safety constraints: secrets, tokens, cookies, auth headers, passwords, raw payloads, personal data, payment data, provider response bodies, full SQL, log injection through control characters or ANSI escapes, high-cardinality indexing cost, sampling policy, and retention policy.
 - Local conventions: logger API, structured field names, severity levels, redaction helpers, error serialization, test helpers, snapshots or fixtures, and configured command intents.
 
@@ -161,7 +163,14 @@ The review question is: "If this backend path fails, times out, retries, silentl
     - Normalize or escape user-controlled strings such as filenames, user agents, nicknames, referers, and queries so newlines, tabs, control characters, and ANSI escapes cannot forge log entries.
     - Sink-side masking is not enough when sensitive data has already crossed the process boundary.
     - Tests or static guards should cover sensitive log fields when feasible.
-18. Require evidence.
+18. Review log pipeline survival when the task depends on searchable logs.
+    - Compare generated, accepted, sent, stored, and searchable counts by service, environment, version, and event family instead of trusting one total.
+    - A synthetic canary log with a unique id and increasing sequence can expose loss, duplication, reorder, and search visibility lag.
+    - Distinguish event timestamp from observed timestamp; large drift points to clock skew, buffer delay, backpressure, or collector backlog.
+    - Queue size alone is weak. Check queue utilization, oldest queued event age, enqueue failures, exporter failures, receiver refusals, DLQ size, and DLQ oldest age.
+    - Parser failures, mapping conflicts, multiline splits, log rotation, container restart, pod deletion, disk buffer exhaustion, and retention or rollover drift can silently erase the evidence operators think they have.
+    - If pipeline checks require live collectors, sinks, dashboards, or production search, report them as manual-only instead of claiming log evidence survived.
+19. Require evidence.
     - Prefer focused tests, log fixtures, snapshot assertions, redaction tests, source-level guards, or local logger contract tests for stable event names and fields.
     - Prefer tests that pin `event_name`, schema version, required fields, redaction, bounded reason codes, and message-independent query fields rather than exact prose.
     - If logs depend on runtime middleware, production log routing, sink configuration, or manual log search outside the repository, report that evidence as manual-only.
@@ -170,7 +179,7 @@ The review question is: "If this backend path fails, times out, retries, silentl
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
-- The reviewed backend path has a reconstruction question, event contract, request lifecycle evidence, correlation and causation model, decision evidence, side-effect evidence, error and cause preservation, redaction boundary, level ownership, sampling boundary, and evidence level.
+- The reviewed backend path has a reconstruction question, event contract, request lifecycle evidence, correlation and causation model, decision evidence, side-effect evidence, error and cause preservation, pipeline survival boundary, redaction boundary, level ownership, sampling boundary, and evidence level.
 - Missing start or finish logs, message-only contracts, unstable event names, missing schema version, missing trace or span id, missing correlation or causation id, string-only errors, lost causes, missing external-call before and after logs, raw provider body logs, missing affected-row counts, invisible transaction or state transitions, silent early returns, attempt-free retries, duration-free timeouts, enqueue or consume gaps, broken async correlation, empty batch summaries, missing auth or validation reasons, ordinary logs for audit events, cache or lock blind spots, idempotency ambiguity, feature flag opacity, release or config opacity, secret-bearing config logs, migration `done` logs, swallowed async errors, all-info or all-error severity, duplicate error spam, prose-only messages, high-cardinality indexed fields, log injection exposure, unsafe sampling, and missing identifiers are fixed or reported.
 - Named review smells such as broken async request id, auth or validation failures, cache hits or misses, lock acquisition, idempotency outcomes, config startup summaries, release and migration event gaps, migration dry-run and apply logs, message-based dashboards, prose-only log, and sink-side-only masking are fixed or reported when present.
 - Log changes are backed by local logger conventions, tests, fixtures, source review evidence, or labeled as manual-only or missing.
@@ -205,7 +214,7 @@ Prefer the narrowest configured checks that cover the changed logging contract a
 ## Output Format
 
 - Backend log boundary reviewed
-- Reconstruction question, event contract, request lifecycle, correlation and causation, error and cause preservation, external API, database write, transaction, state transition, early return, retry, timeout, queue or async handoff, batch or migration, audit, auth, validation, cache, lock, idempotency, feature flag, release, config, level ownership, structure, cardinality, sampling, log-injection safety, redaction, and test evidence findings
+- Reconstruction question, event contract, request lifecycle, correlation and causation, error and cause preservation, external API, database write, transaction, state transition, early return, retry, timeout, queue or async handoff, batch or migration, audit, auth, validation, cache, lock, idempotency, feature flag, release, config, pipeline survival, level ownership, structure, cardinality, sampling, log-injection safety, redaction, and test evidence findings
 - Log fixes made or recommended
 - Evidence level: configured-test evidence, log fixture evidence, source review evidence, manual-only, missing, or not applicable
 - Command intents run