# Decantr vNext Progress Checkpoint

Date: 2026-04-09
Updated: 2026-04-13

This checkpoint records what was implemented on the `codex/decantr-vnext-reset`
branch so the reset program could continue from a known-good state instead of relying on
commit archaeology.

That core reset work was merged into `main` on 2026-04-13. This document now serves as
both the original branch checkpoint and a merged-state ledger of what the vNext reset
already delivered before the remaining commercialization and release-hardening work.

## Current State

- `decantr-monorepo`: `main` (merged from `codex/decantr-vnext-reset` on 2026-04-13)
- historical integration branch: `codex/decantr-vnext-reset`
- `decantr-content`: official content rollout previously synced from `codex/decantr-vnext-resetmai`

## Completed Streams

### Product boundary reset

- Removed legacy UI-runtime surfaces from the active monorepo product boundary:
  - `apps/ui-site`
  - `apps/workbench`
  - `packages/ui`
  - `packages/ui-chart`
  - `packages/ui-catalog`
- Reframed `apps/showcase/*` as a benchmark corpus instead of a product app line.
- Archived stale planning/docs that kept the old product story alive.

### Registry/content/API normalization

- Normalized live registry taxonomy around:
  - `pattern`
  - `theme`
  - `blueprint`
  - `archetype`
  - `shell`
- Removed lingering `recipe` and `theme.style` drift from active product flows.
- Tightened shared registry typing to match the real corpus.
- Hardened `decantr-content` validation around live schema contracts.
- API registry-content validation now derives per-type validators directly from the shared `REGISTRY_SCHEMAS` map instead of a second hand-wired validator list, keeping publish/admin validation aligned with the same typed schema catalog used by the public schema route.

### Schema ownership

- Canonical registry schemas live in package surfaces under `packages/registry/schema`.
- API schema serving reads from package exports instead of private copies.
- Public schema copies in `docs/schemas` are synced from package sources.
- `decantr-content` has a schema sync path back to the monorepo package source.
- `essence.v3.json` now matches the actual sectioned v3.1 contract already used by the compiler and guard stack:
  - sectioned blueprints
  - route maps
  - route-bearing blueprint pages
  - `meta.seo`
  - `meta.navigation`
- `migrateToV4()` now emits a schema-valid section description instead of producing an invalid v3.1 artifact.

### Execution packs

- Added schema-backed execution pack contracts:
  - scaffold
  - section
  - page
  - mutation
  - review
  - pack manifest
- Added a hosted execution-pack bundle contract:
  - `execution-pack-bundle.v1.json`
- Added a hosted selected execution-pack contract:
  - `selected-execution-pack.v1.json`
- CLI now emits pack artifacts into scaffolded projects.
- Shared core now compiles execution-pack bundles from essence as a reusable runtime primitive instead of only inside CLI scaffold glue.
- Shared core now also selects one scaffold, review, section, page, or mutation pack from a compiled bundle as a reusable primitive.
- MCP can read scaffold, section, page, mutation, and review pack context.
- MCP context readers now fall back to hosted pack compilation when local `.decantr/context` artifacts are missing or incomplete.
- Generated project guidance now points operators to packs first.
- Hosted API now compiles execution packs from essence documents through:
  - `POST /v1/packs/compile`
- Hosted API now also returns one selected execution pack plus manifest metadata through:
  - `POST /v1/packs/select`
- Public registry client and CLI now expose that hosted compiler surface:
  - `RegistryAPIClient.compileExecutionPacks()`
  - `decantr registry compile-packs`
  - `RegistryAPIClient.selectExecutionPack()`
  - `decantr registry get-pack`
- `decantr registry get-pack manifest` now uses the smaller hosted selected-pack path and returns just the manifest metadata without requiring a full hosted bundle compile.
- `@decantr/registry` now exposes a first-class `getExecutionPackManifest()` client helper, so CLI and MCP manifest reads do not duplicate their own scaffold-pack selection glue.
- `decantr registry compile-packs --write-context` can now materialize the hosted pack bundle into local `.decantr/context` artifacts without waiting for a full refresh cycle.
- `decantr registry get-pack --write-context` can now materialize just the hosted selected pack plus `pack-manifest.json` into local `.decantr/context`, so operators can hydrate exactly one pack without compiling the full bundle.
- `decantr_get_execution_pack` now uses the hosted selected-pack surface for targeted remote pack reads instead of recompiling the full hosted bundle when local artifacts are missing.
- `decantr_get_section_context` and `decantr_get_page_context` now also use hosted selected-pack reads for remote fallback, so MCP no longer recompiles the full hosted bundle when it only needs one page pack or one section pack.
- Plain `decantr audit` now opportunistically hydrates missing local execution-pack artifacts from the hosted compiler before running local critique or project audit, so pack-first verification still works on partially initialized projects.
- `decantr audit <file>` now hydrates just the hosted review pack plus manifest via pack select when local review context is missing, instead of recompiling and writing the full hosted bundle for single-file critique.
- Plain `decantr audit` now also prefers hydrating just the hosted review pack plus manifest before falling back to a full hosted bundle compile, so routine local project audits stay on the smaller pack-first remote path.
- MCP scaffold-context fallback now prefers hosted selected scaffold/review packs plus manifest before falling back to a full hosted bundle, reducing remote context payload size when local scaffold artifacts are missing.
- MCP manifest-only execution-pack reads now also prefer a hosted selected scaffold pack plus manifest before falling back to full hosted bundle compilation, keeping default remote manifest reads aligned with the smaller pack-first path.
- Live hosted rollout is now green for all current public pack and verification surfaces:
  - `POST /v1/packs/compile`
  - `POST /v1/packs/select`
  - `POST /v1/critique/file`
  - `POST /v1/audit/project`
  - `pnpm audit:public-api` passes against `https://api.decantr.ai/v1`
  - the root `pnpm audit:public-api` command now includes those hosted pack and verifier checks by default

### Verification foundation

- Added shared verifier package: `@decantr/verifier`
- Added schema-backed verifier report contracts.
- Verifier tests now explicitly assert every finding id currently defined in the shared verifier source, so source-defined coverage no longer silently outruns the exercised test surface when new audit or critique findings are added.
- Verifier now also validates real emitted `auditProject()` output, real `critiqueSource()` output, and the checked-in showcase shortlist artifact against the published verifier JSON schemas via AJV-backed round-trip tests, so report contracts are enforced by executable schema checks instead of only by TypeScript interfaces and downstream consumer expectations.
- API schema assertion helpers now reuse already-registered AJV schemas by `$id`, aligning the API-side validator path with the verifier test helpers instead of recompiling the same schema objects on every assertion call.
- API schema-catalog wiring now loads registry, essence, execution-pack, and verifier schemas from cached declarative spec maps instead of one hand-wired constant per file, reducing boilerplate across the public schema-serving surface without changing the exported `PUBLIC_SCHEMAS`, `REGISTRY_SCHEMAS`, or `COMMON_SCHEMA` contracts.
- CLI and MCP now share the verifier engine.
- Review packs now inform critique behavior.
- Project audit now aggregates source-tree findings from `src/`, `app/`, `pages/`, and `components/` when they are present, including inline styles, risky HTML patterns, placeholder routes, auth storage writes, accessibility issues, and unsafe form/auth input behavior.
- Project audit now also scans common root implementation surfaces such as `lib/`, `hooks/`, `providers/`, `server/`, plus root `middleware.*` and `proxy.*`, so framework-level auth guards and session exits are not missed when they live outside `src/`.
- Project audit now also warns when auth is declared but the source tree does not show obvious protected-route, middleware, session-check, or auth-redirect behavior.
- Project audit now also warns when source files reference auth/session state but do not show a loading or pending state on those same surfaces while session resolution happens.
- Project audit now also checks Decantr accessibility contract intent directly, including warning when `dna.accessibility.skip_nav=true` but the source tree does not expose a skip-link signal.
- Project audit now also warns when `dna.accessibility.skip_nav=true` but the source tree still lacks a concrete main landmark (`<main>` / `role="main"`) for skip-link targeting.
- Project audit now also warns when detected skip-link targets do not match any main landmark id, so a nominal skip-nav link cannot silently point at the wrong surface.
- Project audit now also checks Decantr accessibility style intent directly, including warning when `dna.accessibility.focus_visible=true` but the project CSS does not define a focus-visible treatment.
- Project audit now also checks Decantr motion accessibility intent directly, including warning when `dna.motion.reduce_motion=true` but the project CSS does not define a reduced-motion path.
- Runtime audit now also flags remote stylesheet links that ship without Subresource Integrity metadata, extending the built-output hardening pass beyond scripts alone.
- Source and file critique now also flag auth-like credentials written into client-managed cookies, not just localStorage/sessionStorage.
- Project audit now also warns when auth is declared but the source tree does not show an obvious sign-out or session-exit path.
- Project audit now also warns when auth gateway routes exist but the source tree never exposes a real sign-in, registration, or credential-entry surface.
- Project-audit coverage now explicitly locks down the existing auth gateway route setup that still exposes no entry surface at all, with regressions for patterns like a gateway `/login` route in `decantr.essence.json`, a source file such as `DashboardGate.tsx` that only returns `redirect('/login')` for unauthenticated users, and no sign-in, registration, or credential-entry UI anywhere in the source tree, so the verifier's already-modeled `source-auth-entry-signals-missing` detection stays pinned in place.
- Project-audit coverage now explicitly locks down the existing auth-declared source-tree path that writes `localStorage.setItem('auth_token', token)`, `document.cookie = \`auth_token=\${token}; path=/\``, and `fetch('/api/me', { headers: { Authorization: \`Bearer \${token}\` } })` without any reviewed protected-route, middleware, session-check, or auth-redirect behavior, so the already-modeled `source-auth-guard-signals-missing` regression stays pinned in place when auth-like client persistence appears without a real guard boundary anywhere in the source tree.
- Project-audit coverage now explicitly locks down the existing protected-shell path where `DashboardGate` reads `useSession()`, redirects unauthenticated users to `/login`, and returns `<Dashboard />` while the source tree still exposes no real sign-in, registration, or credential-entry UI, so the already-modeled `source-auth-entry-surface-missing` regression stays pinned in place when reviewed auth apps only show the protected side of the gateway contract.
- Source and file critique now also flag auth-like authorization headers being assembled in client-side code.
- Project audit now includes shared runtime evidence when `dist/` exists:
  - root document validation
  - document title validation
  - document `lang` and `viewport` metadata checks
  - built asset fetch checks
  - route-document coverage checks
- Runtime verification now also calls out auth route failures by role, so broken gateway login routes and broken primary app routes are surfaced explicitly instead of only as generic partial route coverage.
- Project audit now adds document-hardening and runtime-security heuristics:
  - charset declaration presence
  - inline script detection
  - external script integrity checks
  - CSP signal detection
  - built-JS dynamic code execution markers
  - built-JS HTML injection markers
- Project audit now also records built asset byte totals and warns on oversized JS/CSS/total bundle budgets.
- Project audit now warns when an auth-declared essence lacks a clear gateway section or anonymous entry route.
- File critique now flags higher-risk code patterns including:
  - `dangerouslySetInnerHTML`
  - raw DOM HTML injection
  - `eval` / `new Function`
- File critique now includes a first AST-backed static pass for supported TS/JSX input so inline-style and high-risk HTML/code-execution findings do not rely only on regex matching.
- File critique and source audit now also catch unlabeled icon-only links, not just icon-only buttons, so generated nav/icon surfaces are held to the same accessibility contract.
- File critique and source audit now also flag iframes without descriptive `title` attributes, so embedded dashboards/docs do not slip past the accessibility baseline.
- File critique and source audit now also flag external iframes without `sandbox`, so embeds are held to a safer default trust boundary.
- File critique and source audit now also flag forms posting to plain `http://` endpoints, so insecure transport regressions show up before runtime review.
- File critique and source audit now also flag plain `http://` / `ws://` client transport endpoints across fetch, axios, WebSocket, and EventSource usage, so insecure outbound requests are caught before hosted/runtime verification.
- File critique and source audit now also flag auth-like forms that default to GET semantics, so credential flows are forced onto explicit POST/server-action boundaries instead of URL-leaking defaults.
- Source audit now also flags auth-enabled apps that still expose no obvious entry surface at all, even when the blueprint forgot to declare gateway routes.
- File critique and source audit now also flag auth-like forms without any submit control, so credential surfaces are not accidentally left non-functional.
- File critique now also treats `autocomplete=\"off\"` on auth inputs as a credential-flow issue, not just missing autocomplete hints.
- File critique now also treats auth-like inputs with the wrong semantic type (`text` instead of `email`/`password`) as a credential-flow issue.
- Source audit and file critique now also flag localhost-style endpoints such as `localhost`, `127.0.0.1`, and `0.0.0.0`, so generated client code does not quietly ship development-only URLs into production.
- Runtime verification now also treats localhost-style development endpoints in built JavaScript as transport-risk signals, so development-only bundle markers are caught even when they survive minification or only appear post-build.
- Runtime verification now also flags plain `http://` / `ws://` transport markers that survive into built JavaScript bundles.
- Runtime verification now also flags root-document remote scripts and stylesheets loaded over plain `http://`, so insecure external asset transport is caught separately from missing integrity metadata.
- Runtime verification now also flags external iframes in built HTML that omit sandboxing or still load over plain `http://`, so embed trust boundaries and embed transport are carried through shortlist benchmarks, intelligence scoring, CLI summaries, registry UI copy, and public schemas alongside the existing source-level iframe review.
- Source audit now flags protected app-surface files that reference routes like `/dashboard` or `/settings` without co-located session or guard behavior, even when an auth helper exists elsewhere in the repo.
- Source audit now also flags auth/session flows that never expose an obvious failure state, so generated credential handling is pushed toward explicit rejected-sign-in and session-refresh error affordances.
- Source audit now also flags auth entry surfaces that never show an obvious post-auth transition into the protected app, so login or registration flows do not silently stop before a primary route like `/dashboard` or `/app`.
- File critique now also flags auth entry flows that never show an obvious transition into a protected route declared by the compiled review contract, so login-page reviews can catch missing post-auth navigation directly instead of only at project-audit time.
- File critique now also flags auth/session files that omit explicit loading and failure states, so reviewed login/session components surface missing pending/error handling directly instead of relying only on project-audit aggregation.
- Project-audit coverage now explicitly locks down the existing auth/session path where `DashboardGate` reads `useSession()`, branches straight from `if (!session) { return redirect('/login'); }` into `<Dashboard />`, and never shows any pending state on that same surface, so the already-modeled `source-auth-loading-signals-missing` regression stays pinned in place when reviewed source auth flows skip an explicit loading boundary.
- Project-audit coverage now explicitly locks down the existing auth source-tree path where `LoginPage` renders a bare sign-in form, `DashboardGate` handles `status === 'loading'` and `!session`, and the reviewed flow still never surfaces a rejected-sign-in or session-error state, so the already-modeled `source-auth-error-signals-missing` regression stays pinned in place when source auth flows handle pending and redirect branches but never expose failure UX.
- Package graduation audits now report npm authentication health explicitly, so release readiness can distinguish repo-side blockers from "npm credentials are not currently usable" operational blockers.
- The standalone graduation plan now also reports npm authentication health, so package graduation can be reviewed from one operator-facing report instead of requiring a second release-surface audit to expose auth failures.
- The plain release-wave plan now also reports npm authentication health, so all three package-governance views (`release:plan`, `release:graduation-plan`, and `audit:release-surface`) expose the same operational blocker without requiring cross-checking separate reports.
- Auth exit assurance is stricter now too: if reviewed source files persist auth state in browser storage, client-managed cookies, or client-managed authorization headers, both project audit and file critique now expect those persistence surfaces to be explicitly cleared during sign-out instead of assuming redirects or generic sign-out helpers are sufficient.
- Auth redirect assurance is stricter now too: reviewed sign-in, recovery, registration, and logout flows are now flagged when they hard-redirect users to external URLs, so Decantr distinguishes internal reviewed route transitions from off-site auth handoffs that should instead go through explicit allowlists or provider configuration.
- External provider auth handoffs are stricter too: hardcoded OAuth/authorize URLs without a `state` parameter are now flagged in both project audit and file critique, so off-site auth entry can’t quietly bypass basic return-flow protection.
- Provider code flows are stricter too: hardcoded external `response_type=code` authorize URLs now get flagged when they omit PKCE, so client-initiated OAuth handoffs can’t quietly ship as bare authorization-code redirects.
- OIDC implicit and hybrid handoffs are stricter too: hardcoded external `id_token` authorize URLs now get flagged when they omit `nonce`, so provider-return integrity can’t quietly depend on a bare implicit-flow redirect.
- Callback cleanup is stricter too: auth callback code that reads codes or tokens from URL query/hash without scrubbing them back out of browser history is now flagged in both project audit and file critique.
- Callback failure handling is stricter now too: auth callback code that reads provider return data without an obvious failure state for `error` returns is now flagged in both project audit and file critique, so provider-denied callbacks do not silently assume the happy path.
- Callback state validation is stricter too: if reviewed callback code reads a returned provider `state`, Decantr now expects an obvious validation step against a stored or expected reviewed value before the auth exchange continues.
- Callback state teardown is stricter now too: if reviewed callback code validates stored `oauth_state` or similar CSRF state, Decantr now expects that reviewed state key to be cleared afterwards instead of lingering in browser storage or cookies.
- Callback failure routes are stricter now too: if reviewed callback handling exposes an error state and the contract declares a sign-in route, Decantr now expects an obvious way back into that sign-in surface instead of trapping users on an isolated callback error screen.
- Callback success paths are stricter too: code/state callback handlers now need to either enter a reviewed protected route or expose an explicit success/verification state instead of ending in an indeterminate “processing” surface.
- Callback completion is stricter too: if reviewed code exchanges provider callback codes into a session, Decantr now expects explicit rejection handling for that exchange instead of assuming provider-return success means callback completion cannot fail.
- Callback URL hygiene is broader too: Decantr now treats provider-return error params the same way it treats callback codes/tokens, so failure callbacks are expected to scrub stale query params out of browser history instead of leaving them behind.
- Callback recovery is stricter too: once callback code/session exchange failures are handled explicitly, Decantr now expects those failure paths to lead users back to the reviewed sign-in surface instead of leaving them stuck on a dead-end callback screen.
- Auth loading detection is a little smarter now too: callback-style pending copy such as “Signing you in…” is treated as a real loading state, which reduces false positives when reviewed auth flows are already surfacing legitimate pending UX.
- Recovery-flow assurance is deeper now too: project audit and file critique both flag password-reset/recovery surfaces that never show a visible success confirmation such as "check your email" or another reviewed completion state after the request succeeds.
- Project-audit coverage now explicitly locks down the existing recovery flow path that submits `requestPasswordReset()` and then only returns users to `/login`, so the already-modeled `source-auth-recovery-success-missing` regression stays pinned in place when reviewed source trees omit a visible reset-request confirmation state.
- Critique-side coverage now explicitly locks down the existing forgot-password flow path that submits a reset request but never surfaces "check your email" or another reviewed confirmation state, so the already-modeled `state-auth-recovery-success-missing` regression stays pinned in place when reviewed recovery surfaces omit a visible completion affordance.
- Registration-flow assurance now follows the same standard: registration surfaces are flagged when they neither transition into a reviewed protected destination nor show an explicit success/verification state, and the source-audit recovery-success check is now scoped to the recovery files themselves instead of any unrelated auth success signal elsewhere in the tree.
- Project-audit coverage now explicitly locks down the existing registration flow path that submits account creation but neither enters a reviewed protected route like `/dashboard` nor exposes a visible verification state such as "account created" or "check your email", so the already-modeled `source-auth-registration-success-missing` regression stays pinned in place when reviewed source trees omit both post-auth transition and success confirmation.
- Critique-side coverage now explicitly locks down the existing registration flow path that submits account creation but neither redirects into a reviewed protected route like `/dashboard` nor surfaces a reviewed completion state such as "account created" or "check your email", so the already-modeled `state-auth-registration-success-missing` regression stays pinned without falling back to the sign-in-only `route-auth-success-redirect-missing` rule.
- Project-audit coverage now explicitly locks down the existing sign-in flow path that submits `auth.signIn()` but never enters a reviewed primary route like `/dashboard`, so the already-modeled `source-auth-success-redirect-missing` regression stays pinned in place when reviewed source trees leave the post-auth transition implicit.
- Critique-side coverage now explicitly locks down the existing sign-in flow path that submits into the app but never enters a reviewed protected route like `/dashboard`, so the already-modeled `route-auth-success-redirect-missing` regression stays pinned in place when reviewed entry surfaces leave the post-auth transition implicit.
- Critique coverage now explicitly locks down the existing auth/session file path where `DashboardGuard` reads `useSession()`, jumps straight from `if (!session) { return redirect('/login'); }` into `<Dashboard />`, and never renders a pending branch on that same reviewed surface, so the already-modeled `state-auth-loading-missing` regression stays pinned in place when critique-side auth/session files skip explicit loading UX.
- The generic "missing post-auth redirect" rule is narrower now as well: it focuses on direct sign-in flows, so registration and recovery surfaces are judged by their own reviewed success-state contract instead of being over-flagged by a sign-in-specific redirect expectation.
- Source critique now also flags insecure remote image URLs in JSX/TSX (`http://...` image sources), closing a mixed-content blind spot that previously existed outside the built-runtime script/stylesheet checks.
- Mixed-content source hardening is broader now too: external iframe embeds over plain HTTP are flagged separately from sandbox issues, so embed trust and embed transport are both visible during critique instead of being conflated into one finding.
- Image semantics are wider now as well: the verifier treats framework-level `Image` components like real image surfaces for missing-`alt` and insecure-transport checks, so Next-style generated code no longer sidesteps those accessibility and mixed-content rules.
- File critique now also flags sign-in flows that omit an obvious path to a declared recovery route, so compiled auth contracts can enforce recovery completeness instead of leaving it implicit.
- File critique now also flags recovery flows that omit an obvious path back to a declared anonymous entry route, so compiled auth contracts can enforce recovery completeness in both directions.
- File critique now also flags sign-in and sign-up surfaces that omit obvious cross-links when the compiled auth contract declares both routes, so gateway entry flows no longer drift into isolated dead ends.
- Critique coverage now explicitly locks down the existing sign-in file path where `handleSubmit` does `await auth.signIn(); return redirect('/dashboard');` and the reviewed form still never renders an error message, alert, or failed-auth state, so the already-modeled `state-auth-error-missing` regression stays pinned in place when critique-side auth entry flows only show the happy path.
- Critique coverage now explicitly locks down the existing sign-in file path where the compiled contract declares `/forgot-password` but `LoginPage` still only renders credential inputs plus a submit button, so the already-modeled `route-auth-recovery-link-missing` regression stays pinned in place when reviewed entry surfaces omit their recovery branch.
- Critique-side coverage now explicitly locks down the existing sign-in flow path that submits into the app but never links into a declared registration route like `/register` or `/sign-up`, so the already-modeled `route-auth-registration-link-missing` regression stays pinned in place when reviewed gateway entry surfaces omit their create-account branch.
- Critique-side coverage now explicitly locks down the existing registration flow path that creates an account but never links back to a declared sign-in route like `/login` or `/sign-in`, so the already-modeled `route-auth-signin-link-missing` regression stays pinned in place when reviewed gateway entry surfaces omit their return-to-entry branch.
- Critique-side coverage now explicitly locks down the existing recovery flow path that submits a reset request but never links back to a declared anonymous entry route like `/login`, `/register`, or `/`, so the already-modeled `route-auth-entry-return-missing` regression stays pinned in place when reviewed forgot-password surfaces omit their return-to-entry branch.
- Project audit now also flags declared auth-route gaps across the source tree, such as sign-in surfaces that never link into declared recovery/registration routes or gateway flows that never route back into declared sign-in.
- Project-audit coverage now explicitly locks down the existing sign-in surface path that declares a recovery route like `/forgot-password` or `/reset-password` but never links into it anywhere in the source tree, so the already-modeled `source-auth-recovery-route-missing` regression stays pinned in place when reviewed auth entry surfaces omit their recovery branch.
- Project-audit coverage now explicitly locks down the existing sign-in surface path that declares a registration route like `/register` or `/sign-up` but never links into it anywhere in the source tree, so the already-modeled `source-auth-registration-route-missing` regression stays pinned in place when reviewed auth entry surfaces omit their create-account branch.
- Project-audit coverage now explicitly locks down the existing registration and recovery surface path that declares a sign-in route like `/login` or `/sign-in` but never links back into it anywhere in the source tree, so the already-modeled `source-auth-signin-route-missing` regression stays pinned in place when reviewed gateway surfaces omit their return-to-entry branch.
- File critique now catches dialog accessibility gaps too, including missing dialog labels and missing modal hints on dialog-like surfaces.
- Auth verification now flags guard/session files that redirect unauthenticated users toward protected destinations like `/dashboard` instead of anonymous entry routes.
- Critique-side coverage now explicitly locks down the existing guard/session path where a reviewed auth surface checks session state and then redirects unauthenticated users toward `/dashboard`, so the already-modeled `route-auth-guard-protected-redirect` regression stays pinned in place when reviewed auth/session logic points anonymous traffic at protected destinations instead of gateway routes.
- Project-audit coverage now explicitly locks down the existing guard/session path where a `DashboardGuard`-style surface checks for session state and then redirects unauthenticated users back to `/dashboard`, so the already-modeled `source-auth-guard-protected-redirect` regression stays pinned in place when reviewed auth guards point anonymous traffic at protected destinations instead of gateway routes.
- File critique now also flags auth-like form inputs that omit `name` attributes, so visually correct login forms do not silently fail browser submission or FormData handling.
- Critique-side coverage now explicitly locks down the existing sign-in form path that renders credential inputs without stable `name` attributes, so the already-modeled `interaction-auth-input-name-missing` regression stays pinned in place when reviewed auth forms look complete visually but still drop values during browser submission or FormData handling.
- Security critique now also flags credential inputs whose `autocomplete` values are semantically wrong for the field, closing another silent auth-form correctness gap beyond missing hints.
- Critique-side coverage now explicitly locks down the existing sign-in form path whose credential inputs use `autocomplete` values that do not match the field purpose, so the already-modeled `security-auth-autocomplete-missing` regression stays pinned in place when reviewed auth forms look complete visually but still break browser autofill and credential semantics.
- Security critique now also treats string-based `setTimeout` / `setInterval` execution like other dynamic-eval patterns, so timer strings do not slip past the AST-backed runtime-trust checks.
- Critique-side coverage now explicitly locks down the existing utility/action path that still passes string payloads into `setTimeout(...)`, so the already-modeled `security-dynamic-code-eval` regression stays pinned in place when reviewed files smuggle code execution through timer strings instead of explicit functions.
- Security critique now also treats insecure client-side redirects like other transport hygiene failures, catching `location.href` / `location.assign` / `location.replace` paths that still point at plain `http://` destinations.
- Project-audit coverage now explicitly locks down the existing legacy-auth helper path that still calls `fetch('http://...')` and opens `new WebSocket('ws://...')` from reviewed source files, so the already-modeled `source-security-risk-patterns-present` regression stays pinned in place when project audits surface insecure transport endpoints before runtime review.
- Critique-side coverage now explicitly locks down the existing legacy-auth helper path that mixes `fetch('http://...')`, `window.location.assign('http://...')`, and `new WebSocket('ws://...')`, so the already-modeled `security-transport-endpoint-insecure` regression stays pinned in place when reviewed client code still calls or navigates to insecure transport endpoints.
- Project-audit coverage now explicitly locks down the existing login-redirect route path that reads raw `next` query params from `URLSearchParams` and feeds them straight into `redirect(...)` or `window.open(..., '_self')`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when reviewed source flows skip a reviewed internal allowlist for post-auth transitions.
- Critique-side coverage now explicitly locks down the existing login-redirect path that reads raw `next` query params from `URLSearchParams` and feeds them straight into browser navigation, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when reviewed auth flows skip a reviewed internal allowlist for post-auth transitions.
- Project-audit coverage now explicitly locks down the existing sign-in submit path that completes `auth.signIn()` and then redirects users straight to an external URL like `https://accounts.example.com/continue`, so the already-modeled `source-auth-external-redirect-risk` regression stays pinned in place when reviewed source flows hardcode off-site post-auth destinations instead of keeping transitions on reviewed internal routes or explicit allowlists.
- Critique-side coverage now explicitly locks down the existing sign-in submit path that completes `auth.signIn()` and then redirects users straight to an external URL like `https://accounts.example.com/continue`, so the already-modeled `security-auth-external-redirect-risk` regression stays pinned in place when reviewed auth flows hardcode off-site post-auth destinations instead of keeping transitions on reviewed internal routes or explicit allowlists.
- Project-audit coverage now explicitly locks down the existing login form path that renders credential inputs inside `<form>` without `method="post"`, so the already-modeled `source-security-risk-patterns-present` regression stays pinned in place when reviewed auth flows silently fall back to GET semantics before runtime review.
- Critique coverage now explicitly locks down the existing auth form path that renders credential inputs inside `<form>` without `method="post"`, so the already-modeled `security-auth-form-method-insecure` regression stays pinned in place when reviewed sign-in forms silently fall back to GET semantics.
- Project-audit coverage now explicitly locks down the existing login form path that renders credential inputs without explicit `autocomplete` values like `email` or `current-password`, so the already-modeled `source-auth-input-hints-missing` regression stays pinned in place when reviewed source auth flows skip browser credential hints before runtime review.
- Project-audit coverage now explicitly locks down the existing client auth helper path that writes `auth_token` into browser storage via `localStorage.setItem('auth_token', token)`, so the already-modeled `source-auth-storage-writes-present` regression stays pinned in place when reviewed source files persist bearer-like credentials in browser storage.
- Project-audit coverage now explicitly locks down the existing client auth helper path that writes `auth_token` through `document.cookie = \`auth_token=\${token}; path=/\``, so the already-modeled `source-auth-cookie-writes-present` regression stays pinned in place when reviewed source files persist auth-like credentials in client-managed cookies.
- Project-audit coverage now explicitly locks down the existing client auth helper path that writes `Authorization` headers via `fetch('/api/me', { headers: { Authorization: \`Bearer \${token}\` } })`, so the already-modeled `source-auth-header-writes-present` regression stays pinned in place when reviewed source files attach bearer-like credentials through client-managed authorization headers.
- Critique coverage now explicitly locks down the existing auth-like credential persistence path where reviewed code writes `localStorage.setItem('auth_token', token)`, `sessionStorage.jwt = token`, `document.cookie = \`auth_token=\${token}; path=/\``, and `fetch('/api/me', { headers: { Authorization: \`Bearer \${token}\` } })`, so the already-modeled `security-auth-storage-write`, `security-auth-cookie-write`, and `security-auth-header-write` regressions stay pinned in place when critique-side auth helpers assemble client-managed credential persistence directly in browser code.
- Security critique now also flags imperative `window.open(..., "_blank")` usage that omits `noopener,noreferrer`, so generated action handlers do not silently preserve opener access across trust boundaries.
- Critique-side coverage now explicitly locks down the existing action/button path that opens a new tab with `window.open(..., "_blank")` but omits `noopener,noreferrer`, so the already-modeled `security-window-open-noopener-missing` regression stays pinned in place when reviewed outbound actions preserve opener access across trust boundaries.
- Accessibility critique now catches table markup without headers or captions, so data-heavy generated UIs fail earlier when their structure is visually plausible but semantically incomplete.
- Accessibility critique now also catches multiple navigation landmarks without distinct labels, which is especially important for generated app shells with both sidebar and utility nav regions.
- Accessibility critique now also flags files that render multiple main landmarks, helping generated page and shell structures keep a single clear primary content region for assistive technologies.
- Verification checkpoint coverage now also explicitly names the remaining source/bootstrap and auth-topology regressions that still live in the verifier contract, including `review-pack-file-missing`, `runtime-dist-missing`, `auth-gateway-section-missing`, `auth-primary-section-missing`, `auth-entry-route-missing`, `auth-primary-routes-missing`, `auth-gateway-routes-not-auth-like`, `auth-gateway-routes-look-protected`, `auth-primary-routes-not-app-like`, `auth-primary-routes-look-auth-only`, `auth-gateway-primary-route-overlap`, `source-protected-surface-auth-checks-missing`, and `interaction-auth-submit-missing`, so the checkpoint doc keeps the same topology/baseline failure language as the current verifier suite instead of leaving those contract gaps implicit.
- Verification checkpoint coverage now also explicitly names the remaining source-level accessibility/style/anti-pattern regressions, including `source-accessibility-issues-present`, `source-main-landmark-signals-missing`, `source-skip-nav-signals-missing`, `source-skip-nav-target-mismatch`, `style-focus-visible-signals-missing`, `style-reduced-motion-signals-missing`, `source-inline-styles-present`, `anti-pattern-inline-styles`, `anti-pattern-hardcoded-colors`, `source-localhost-endpoints-present`, `source-placeholder-route-targets-present`, and `source-interaction-safety-issues-present`, so the checkpoint doc now mirrors the verifier’s current source-audit expectations around landmark structure, motion/focus styling, styling discipline, placeholder routing, and unsafe local-only endpoints.
- Verification checkpoint coverage now also explicitly names the remaining file-critique accessibility semantics regressions, including `accessibility-clickable-non-semantic`, `accessibility-form-control-label-missing`, `accessibility-icon-button-label-missing`, `accessibility-icon-link-label-missing`, `accessibility-image-alt-missing`, `accessibility-iframe-title-missing`, `accessibility-dialog-label-missing`, `accessibility-dialog-modal-hint-missing`, `accessibility-table-caption-missing`, `accessibility-table-headers-missing`, `accessibility-navigation-landmark-label-missing`, and `accessibility-multiple-main-landmarks`, so the checkpoint doc now stays aligned with the verifier’s element-level accessibility contract instead of only mentioning a subset of those AST-backed checks.
- Verification checkpoint coverage now also explicitly names the remaining file-critique interaction and trust-boundary regressions, including `interaction-button-type-missing`, `route-placeholder-navigation-target`, `security-dangerously-set-html`, `security-raw-html-injection`, `security-hardcoded-secret-literal`, `security-client-secret-env-reference`, `security-form-action-insecure`, `security-target-blank-rel-missing`, `security-postmessage-wildcard-origin`, `security-message-listener-origin-check-missing`, `security-iframe-sandbox-missing`, `security-iframe-transport-insecure`, `security-image-transport-insecure`, and `security-localhost-endpoint-present`, so the checkpoint doc now explicitly carries the same source-level DOM, secret, messaging, and external-navigation risks that the verifier already enforces.
- Verification checkpoint coverage now also explicitly names the remaining built-document and remote-asset hardening regressions, including `runtime-title-missing`, `runtime-lang-missing`, `runtime-viewport-missing`, `runtime-charset-missing`, `runtime-csp-signal-missing`, `runtime-inline-scripts-present`, `runtime-inline-event-handlers-present`, `runtime-external-scripts-without-integrity`, `runtime-external-scripts-crossorigin-missing`, `runtime-external-scripts-insecure-transport`, `runtime-external-stylesheets-without-integrity`, `runtime-external-stylesheets-crossorigin-missing`, `runtime-external-stylesheets-insecure-transport`, `runtime-external-links-noopener-missing`, `runtime-external-iframes-sandbox-missing`, `runtime-external-iframes-insecure-transport`, and `runtime-external-media-insecure-transport`, so the checkpoint doc now names the same root-document and remote-asset runtime contract that shortlist verification and hosted audits already consume.
- Verification checkpoint coverage now also explicitly names the remaining built-bundle and route-survival regressions, including `runtime-js-bundle-large`, `runtime-js-dynamic-code-signals`, `runtime-js-html-injection-signals`, `runtime-js-insecure-transport-signals`, `runtime-js-secret-signals`, `runtime-route-hints-partial`, `runtime-route-documents-partial`, `runtime-auth-gateway-routes-failed`, and `runtime-auth-primary-routes-failed`, so the checkpoint doc now carries the same bundle-trust and route-survival vocabulary as the built-dist verifier and shortlist pipeline.
- Verification checkpoint coverage now also explicitly names the remaining responsive/theme drift regressions, including `responsive-signals-missing` and `theme-consistency-weak`, so the checkpoint doc now reflects the verifier’s current design-quality floor for responsive behavior and overall visual-system coherence instead of leaving those checks only in test expectations.
- Verification checkpoint coverage now also explicitly names the remaining project-contract and execution-pack baseline regressions, including `essence-missing`, `essence-parse-error`, `essence-validation`, `pack-manifest-missing`, `scaffold-pack-missing`, `review-pack-missing`, `mutation-packs-missing`, and `review-pack-missing-for-critique`, so the checkpoint doc now mirrors the verifier’s current expectation that every audited project carries a valid essence plus a materially complete compiled context bundle before critique and project audit try to reason about routes, sections, or review contracts.
- Verification checkpoint coverage now also explicitly names the remaining auth-topology route-definition regression `auth-gateway-routes-missing`, so the checkpoint doc now reflects the verifier’s current distinction between “a gateway section exists” and “that gateway actually exposes explicit routable login, registration, or recovery pages” instead of only talking about gateway presence in the abstract.
- Verification checkpoint coverage now also explicitly names the remaining built-output baseline and performance regressions, including `runtime-index-missing`, `runtime-root-document-invalid`, `runtime-assets-missing`, `runtime-assets-fetch-failed`, `runtime-route-hints-missing`, `runtime-route-documents-missing`, `runtime-route-document-hardening-missing`, `runtime-route-document-hardening-partial`, `runtime-css-bundle-large`, and `runtime-total-assets-large`, so the checkpoint doc now carries the same mount-point, asset-fetch, route-document, and CSS/total-budget vocabulary as the current built-dist verifier instead of stopping at the earlier JS-only and partial-route coverage language.
- Verification checkpoint coverage now also explicitly names the remaining source-critique accessibility and treatment-discipline regressions, including `accessibility-aria-missing`, `accessibility-keyboard-missing`, `treatment-usage-missing`, and `anti-pattern-utility-framework-leakage`, so the checkpoint doc now reflects the verifier’s current requirement that reviewed files expose explicit accessibility metadata, preserve keyboard affordances, actually use Decantr treatments, and avoid letting raw utility-framework classes become the primary visual system.
- Package graduation now also audits publish metadata quality directly, including `license`, `homepage`, `repository.directory`, `files`, `publishConfig.access`, and normalized `bin` paths, so stable-readiness is enforced in code instead of left to npm auto-correction.
- Package release auditing now also runs real `npm publish --dry-run` style preflights for the `foundation` and `delivery` waves, so graduation review captures actual packaging/publish rehearsal output instead of stopping at metadata and dist-tag checks.

### Showcase / golden corpus

- Added showcase manifest validation and repeatable shortlist verification.
- Added shortlist verification reports and schema contracts.
- Moved shortlist verification onto the shared `@decantr/verifier` built-dist runtime audit path instead of keeping a showcase-only smoke helper.
- Deepened shortlist verification beyond root/asset smoke with:
  - HTML title checks
  - HTML `lang` and viewport checks
  - charset checks
  - inline script counts
  - external script integrity checks
  - CSP signal checks
  - route-document coverage checks
  - total / JS / CSS asset payload reporting
  - richer shortlist summary/report fields surfaced through shared contracts
- Registry homepage and blueprint detail surfaces expose showcase benchmark metadata.
- API, CLI, and MCP all expose showcase benchmark surfaces.
- Registry app now dogfoods public showcase metadata from the hosted API path.
- Current tracked shortlist baseline on 2026-04-09:
  - 8/8 builds passing
  - 8/8 smoke checks passing
  - 8/8 title / `lang` / viewport / charset checks passing
  - 8/8 with no inline script tags
  - 8/8 with no external scripts missing integrity
  - 8/8 with no insecure remote asset transport
  - 8/8 with sandboxed external iframes
  - 8/8 with no insecure external iframes
  - 0/8 with CSP signals present
  - average build duration `1908ms`
  - average smoke duration `12ms`
  - average assets `335362 B total`, `325759 B JS`, `9602 B CSS`

### Registry intelligence

- Added authored intelligence scoring on top of benchmark-backed blueprint intelligence.
- Added public ranking for recommended content.
- Added shared sort handling across API, registry, CLI, and MCP.
- Added recommended filtering across public registry surfaces.
- Added explicit intelligence provenance:
  - `authored`
  - `benchmark`
  - `hybrid`
- Added explicit intelligence confidence tiers so recommendation quality is visible and rankable:
  - `low`
  - `medium`
  - `high`
  - `verified`
- Added explainable intelligence metadata so API, CLI, and registry detail views can surface recommendation reasons and blockers instead of only raw scores.
- Intelligence scoring now rewards shortlist runtime hardening evidence:
  - document `lang` / viewport metadata
  - charset presence
  - script hygiene without inline scripts or missing integrity
  - optional CSP signal presence
  - healthy built asset budgets
  - not just build/smoke pass state
- Added a hosted schema-backed registry intelligence rollup endpoint:
  - `/v1/intelligence/summary`
- Added intelligence-source filtering across:
  - public API routes
  - registry portal browse surfaces
  - CLI search/list
  - MCP registry search
- Registry cards now label intelligence provenance directly.

### Content repo operational audits

- Added live registry drift audit in `decantr-content`.
- Added content-intelligence audit in `decantr-content`.
- Added provenance/source-filter audit coverage so live API rollout gaps are measurable.
- Added a hosted intelligence summary surface so rollout state can be checked without crawling the entire public corpus.
- Added dry-run reporting for official-content sync/prune behavior.

### Hosted rollout visibility

- Added a lightweight public API smoke audit script: `pnpm audit:public-api`
- Added a GitHub Actions workflow for scheduled/manual public API audit reporting.
- Added a human-readable public API reference page under `docs/reference/`.
- API schema-route coverage now walks the exported `PUBLIC_SCHEMAS` catalog directly and the unknown-schema branch asserts exact catalog parity, so adding a new public schema requires touching the shared catalog once instead of extending a second hand-maintained route-test list.
- Added a manual Fly deploy workflow for the hosted API:
  - `.github/workflows/deploy-api-fly.yml`
- Added an explicit Vercel deploy workflow for the registry portal:
  - `.github/workflows/deploy-registry-vercel.yml`
- Added a hosted registry portal audit surface:
  - `pnpm audit:registry-portal`
  - `.github/workflows/registry-portal-audit.yml`
- Standardized the hosted API deploy contract around:
  - `apps/api/fly.toml`
  - the workspace-aware root `Dockerfile`
- Standardized the registry portal deploy contract around:
  - `apps/registry`
  - `apps/registry/.env.example`
  - `docs/runbooks/2026-04-09-registry-portal-deploy.md`
- Removed stale deploy-path drift:
  - retired the old root `fly.toml`
  - removed the obsolete `apps/api/Dockerfile`
  - removed the stray `apps/api/package-lock.json`
- Completed the hosted API rollout on 2026-04-09:
  - Fly now serves the reset-branch API successfully
  - `/v1/schema/*`, `/v1/showcase/*`, and `/v1/intelligence/summary` are publicly reachable
  - `pnpm audit:public-api` now passes against `https://api.decantr.ai/v1`
- Extended the hosted public API contract again after rollout with:
  - `POST /v1/packs/compile`
  - audit coverage for hosted execution-pack compilation
  - public docs/reference coverage for the hosted compiler surface
  - direct Fly redeploy from `codex/decantr-vnext-reset` completed successfully
  - `POST /v1/packs/compile` now returns `200` in live public audits
- Added a hosted file-critique surface on the reset branch:
  - `POST /v1/critique/file`
  - shared verifier-backed critique for inline source plus posted essence
  - CLI entrypoint via `decantr registry critique-file`
  - MCP hosted fallback when local review packs are missing
  - the root `pnpm audit:public-api` path now covers the hosted critique surface by default
- Added a hosted project-audit surface on the reset branch:
  - `POST /v1/audit/project`
  - remote project audit from posted essence plus optional dist and source snapshots
  - CLI entrypoint via `decantr registry audit-project`
  - MCP hosted fallback when local pack artifacts are missing, with optional `sources_path` support for richer hosted source verification
  - the root `pnpm audit:public-api` path now covers the hosted project-audit surface by default
- Completed the hosted verification rollout on 2026-04-09:
  - Fly redeploy from `codex/decantr-vnext-reset` completed successfully after syncing the workspace lockfile
  - `pnpm audit:public-api` now reports both hosted verification endpoints as `200`
  - live hosted verification now covers:
    - `POST /v1/critique/file`
    - `POST /v1/audit/project`
- Completed the official content rollout on 2026-04-09:
  - content workflow run `24192386163` synced `codex/decantr-vnext-resetmai` into the live registry
  - live `@official` content count is now `480`
  - stale live extras were pruned
  - live registry drift now reports zero missing, extra, or changed items

### Registry portal dogfooding

- The registry portal now validates as a schema-correct Decantr v3.1 project instead of carrying a stale essence shape.
- `apps/registry` now has compiled pack artifacts checked into `.decantr/context`, including:
  - scaffold pack
  - section packs
  - page packs
  - mutation packs
  - review pack
  - pack manifest
- Added a CI-visible dogfood audit command:
  - `pnpm audit:registry-dogfood`
- Wired that audit into the main CI workflow.
- Reduced verifier findings on the public homepage and detail page by:
  - removing inline style literals
  - removing hardcoded color literals
  - adding real landmark ARIA metadata
  - adding explicit focus-visible signals
  - adding responsive CSS-module breakpoints
- Made the registry portal `build` path clean-checkout safe by rebuilding `@decantr/registry` before Next.js typechecking, matching the existing lint discipline.

### Package surface governance

- Added `config/package-surface.json` as the package support and dist-tag source of truth.
- Added `config/package-retirements.json` plus a retirement/deprecation script for removed npm lines such as `@decantr/ui`.
- Added `pnpm audit:package-surface` and wired it into CI.
- Added executable release-readiness metadata and `pnpm audit:release-readiness` so beta-to-stable graduation stops living only in docs.
- Added `pnpm release:plan` plus `scripts/release-plan.mjs` so package publish intent, beta blockers, and retired replacements can be generated as Markdown or JSON from the manifest source of truth.
- Added `pnpm audit:release-surface` plus `scripts/audit-release-surface.mjs` so package support config, release readiness, release plan, and live npm drift can be reported together in one JSON/Markdown artifact.
- Improved npm surface tooling so dist-tag audits and normalization now distinguish between packages that merely need missing `beta` tags and packages whose `latest` retag is blocked because no stable published version exists yet.
- Added a dedicated npm surface normalization workflow so safe dist-tag repairs can run through GitHub Actions without relying on local npm auth state.
- Added a real package artifact preflight path via `--publish-dry-run` and `pnpm release:preflight`, so selected packages now run through `npm publish --dry-run` when unpublished and `npm pack --dry-run` when the version is already on npm instead of relying only on manifest selection rehearsal.
- Replaced the hardcoded publish loop with a manifest-backed publish script.
- Added explicit release-wave and publish-order metadata so package planning, dry-runs, and publishes can execute in a stable foundation-to-delivery order instead of hand-curated lists.
- Added wave-aware release-plan and publish filtering so npm rehearsals can target a specific package wave instead of hand-picked package name lists.
- Updated the GitHub npm publish workflow so manual runs can select a release wave, emit the computed release plan into the Actions summary, and rehearse with `dry_run_only=true`.
- Added a dedicated package release audit workflow so GitHub Actions now publishes report-only package-governance artifacts without requiring npm publish credentials.
- Added package-level README coverage for all active public packages.
- Added a generated package support matrix and release-strategy runbook for the npm surface, with `pnpm audit:package-surface` now enforcing that the matrix stays in sync with the manifest source of truth.
- The generated package support matrix now also includes an operator-facing graduation snapshot with stable-now, ready-next, beta-blocked, and experimental-hold lanes, so release planning is visible directly from manifest-backed docs instead of only from audit artifacts.
- Package-surface validation now also enforces semver intent directly, so stable packages cannot silently keep prerelease versions and beta packages must keep prerelease semver until they intentionally graduate.
- Graduation and release-plan output now also surface each package's current version and stable target version, making beta-to-latest planning more operational than a pure status label.
- Cleared the remaining workspace dependency advisories by upgrading `hono`, `@hono/node-server`, and `@modelcontextprotocol/sdk`, then pinning patched `vite` and `path-to-regexp` resolutions through root `pnpm` overrides so `pnpm audit` now returns zero vulnerabilities.

## Remaining Major Work

The core reset tracks are no longer the primary risk. The remaining initiative now centers on depth, graduation, and commercialization:

- Hosted commercialization depth:
  - private registries
  - richer org/team governance
  - stronger entitlement and approval workflows
  - deeper billing lifecycle and metering confidence
- Package graduation and release execution:
  - move selected `beta-blocked` packages toward intentional publish readiness
  - run real release waves instead of only readiness audits
- Final documentation completeness:
  - sweep remaining package/app READMEs
  - keep operator docs aligned with the merged `main` workflow
- Optional but recommended hardening:
  - expand the new representative blueprint certification matrix beyond its current `6/6` representative baseline
  - route inventory/meta coverage so test drift is caught automatically
  - deeper billing/admin/publish branch coverage where business logic is now present but not exhaustively exercised

## Verification Baseline

The reset branch has repeatedly been verified with:

- `pnpm test`
- `pnpm build`
- `pnpm lint`
- `pnpm audit`
- `pnpm audit:registry-dogfood`
- `pnpm showcase:validate`
- `pnpm showcase:verify:shortlist`
- `node validate.js` in `decantr-content`
- `node scripts/audit-content-intelligence.js` in `decantr-content`
- `node scripts/audit-registry-drift.js` in `decantr-content`

## Current Live State

Observed from live audits against `https://api.decantr.ai/v1` on 2026-04-09:

- hosted public API smoke audit is green
- hosted intelligence summary is green
- live `@official` content count matches repo count
- live registry drift is clean after the official-content sync
- showcase shortlist verification is publicly reachable
- hosted execution-pack compilation is publicly reachable
- `POST /v1/packs/compile` returns `200`
- `POST /v1/critique/file` returns `200`
- `POST /v1/audit/project` returns `200`

The hosted API path is explicit and exercised in production. The registry portal deploy path is
now explicit in-repo as well through the Vercel workflow, portal audit, and runbook surfaces.

The local dependency graph is also green again on 2026-04-09:

- `pnpm audit` reports `0` vulnerabilities
- `hono` is resolved at `4.12.12`
- `@hono/node-server` is resolved at `1.19.13`
- `@modelcontextprotocol/sdk` is resolved at `1.29.0`
- `vite` is resolved at `6.4.2`
- `path-to-regexp` is resolved at `8.4.0`

The verifier layer has also moved beyond heuristic-only critique in this branch:

- AST-backed security checks now detect `dangerouslySetInnerHTML`, raw DOM HTML injection, and dynamic eval patterns.
- AST-backed accessibility checks now detect unlabeled icon-only buttons, clickable non-semantic controls, images without `alt`, and unlabeled form controls.
- AST-backed route/security checks now catch external `_blank` links missing `rel="noopener noreferrer"`, placeholder navigation targets such as `href="#"` or `javascript:void(0)`, and auth-related inputs missing explicit `autocomplete` hints.
- Auth-input hardening now also treats OTP and verification-code fields as first-class auth surfaces, so generated one-time-code flows are reviewed for `autocomplete="one-time-code"` instead of slipping past the password/email-focused checks.
- Framework navigation wrappers now inherit the same safety/accessibility scrutiny as raw anchors, so `Link` and `NavLink` surfaces are reviewed for unlabeled icon links and `_blank` external targets missing `rel="noopener noreferrer"`.
- Remote image-transport checks now cover responsive media sources too, so insecure `srcSet` and `<source>` entries inside `picture` flows are caught alongside plain `img src` and framework `Image` props.
- Open-redirect review is tighter too: Decantr now flags `href`/`to`/location assignments and route-transition helpers that pull destinations directly from `searchParams.get("next")`-style values, not just obvious inline `redirect(...)` calls.
- Runtime smoke verification now catches insecure remote image and media sources in built HTML too, and that signal flows through shortlist verification, content-intelligence scoring, CLI summaries, registry detail pages, and the public verifier schemas.
- Project audit now also flags suspicious auth topology, including gateway sections that expose protected-looking routes, gateway sections that are not auth-like, primary sections that only expose auth-like destinations, and primary sections that do not include a clear post-auth application route.
- Project audit now also warns when gateway and primary sections overlap on the same route, making the anonymous-to-authenticated boundary ambiguous.
- Runtime verification now reports partial route drift when only some compiled route hints or route documents survive the built output, instead of only surfacing catastrophic misses.
- Runtime verification and shortlist reports now also track strict full-route-coverage booleans for both compiled route hints and audited route documents, so the golden corpus can distinguish “some route coverage” from “the entire declared route contract survived.”
- Runtime verification and shortlist reports now also track route-document hardening coverage separately from route existence, so Decantr can distinguish “the route rendered” from “the route preserved a hardened document shell.”
- Runtime verification now also flags secret-like client-bundle leakage, including service-role key markers, live secret key patterns, and private-key material that survive into built JavaScript.
- Runtime verification now also flags inline DOM event-handler attributes that survive into built HTML, so golden verification and hosted audits catch `onclick`/`onload`-style leakage alongside inline scripts and remote asset hardening issues.
- File critique and source audit now also flag hardcoded secret literals plus client-exposed secret env references, so privileged keys can be caught before they ever reach a compiled bundle.
- File critique and source audit now also flag `postMessage(..., "*")` wildcard target origins, so cross-window messaging contracts have to name an explicit reviewed origin instead of broadcasting blindly.
- File critique and source audit now also flag inbound `message` handlers that never validate `event.origin`, so Decantr reviews both sides of the browser cross-window trust boundary instead of only outbound `postMessage` calls.
- Critique now also flags buttons inside forms that omit `type`, helping catch accidental-submit behavior before generated UI reaches review.
- Critique now flags auth-like writes into `localStorage` and `sessionStorage`, helping catch insecure client-side token/session persistence earlier in review.
- Critique now also flags auth cookie issuance that omits explicit `httpOnly`, `secure`, or `sameSite` options across both `cookies.set(...)` and `Set-Cookie` header issuance, so server-managed session flows are held to a hardened baseline instead of relying on ambient framework defaults.
- Critique coverage now explicitly locks down the existing auth cookie issuance path where reviewed server code does `cookies.set('session_token', token, { secure: true })` or `res.setHeader('Set-Cookie', 'session_token=' + token + '; Path=/; Secure')` without an explicit full hardening set such as `httpOnly`, `secure`, and `sameSite`, so the already-modeled `security-auth-cookie-hardening-missing` regression stays pinned in place when critique-side auth session issuance relies on partial cookie options.
- Project-audit coverage now explicitly locks down the existing auth-declared source-tree path that never exposes any obvious sign-out or logout flow, so the already-modeled `source-auth-exit-signals-missing` regression stays pinned in place when reviewed protected shells never surface an intentional session-exit boundary.
- Project audit and file critique now also flag auth exit flows that never return users to an anonymous route after logout, so protected shells do not quietly linger after session teardown.
- Project-audit coverage now explicitly locks down the existing auth/session exit path where source audit sees sign-out logic but no matching redirect back to `/`, `/login`, or `/register`, so the already-modeled `source-auth-exit-redirect-missing` regression stays pinned in place when reviewed logout flows tear down session state without a return-to-entry branch.
- Critique-side coverage now explicitly locks down the existing auth/session exit path where a reviewed `useSession()`-style surface calls `auth.signOut()` but never routes users back to `/`, `/login`, or `/register`, so the already-modeled `route-auth-exit-redirect-missing` regression stays pinned in place when reviewed logout flows tear down session state without an anonymous return branch.
- Project audit and file critique now also distinguish redirect-only logout from a real sign-out boundary, so auth exit flows have to actually invalidate session state instead of merely bouncing users back to `/login`.
- Project-audit coverage now explicitly locks down the existing redirect-only logout path with regressions for patterns like `async function handleLogout() { return redirect('/login'); }`, so the verifier’s already-modeled auth exit teardown enforcement stays pinned in place alongside the earlier auth assurance work.
- Critique coverage now explicitly locks down the existing redirect-only logout path with regressions for patterns like `async function handleLogout() { return redirect('/login'); }`, so the verifier’s already-modeled auth exit teardown enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit and critique coverage now explicitly lock down the existing redirect-only logout path where `handleLogout` or `logout()` only does `return redirect('/login')` instead of `await auth.signOut(); return redirect('/login');`, so the already-modeled `source-auth-exit-teardown-missing` and `state-auth-exit-teardown-missing` regressions stay pinned in place when reviewed auth exits redirect away without actually invalidating session state.
- Hosted showcase summaries, CLI output, registry portal messaging, and benchmark-backed intelligence scoring now all surface that stricter full-route-coverage signal instead of treating partial route survival as fully verified.
- Showcase manifest, shortlist, and shortlist-report surfaces are now kept in sync with the runtime security contract, so new smoke fields cannot silently land in verifier output while API and registry serializers keep emitting stale payloads.
- Registry app lint now rebuilds `@decantr/registry` before typechecking so clean-checkout verification does not depend on stale generated package artifacts.
- Package graduation now has its own executable planning surface via `pnpm release:graduation-plan`, which classifies each public package as stable, ready, contract-blocked, npm-blocked, experimental, or retired.
- The package governance GitHub Actions audit now publishes the graduation plan alongside the broader release-surface audit, so stable-vs-beta decisions are visible in CI artifacts instead of only from local scripts.
- The package governance workflow now also captures the raw live npm-surface audit log, so stray dist-tags, missing `beta` tags, and unpublished packages stay visible in CI even while graduation remains report-first.
- The package governance workflow now also captures the npm dist-tag normalization dry-run preview, so CI artifacts show both the live npm drift and the safe executable repair plan in one place.
- The verifier now flags auth and route-transition flows that trust raw `next`/`returnTo`-style redirect params, so open-redirect risk shows up in both project audit and file critique before shipping.
- That open-redirect coverage now also catches raw `new URLSearchParams(window.location.search).get('next')`-style flows in both direct redirects and JSX route props, so auth handoff code cannot evade review by parsing the query string inline before navigating.
- The auth open-redirect detector now also follows simple local aliases of those raw query-param reads, so `const next = new URLSearchParams(window.location.search).get('next')` still gets flagged when later consumed by redirects or JSX route props.
- The auth open-redirect detector now also covers browser-native handoffs like `window.location.assign(...)` and `window.location.href = next`, including aliased `next` values sourced from raw query-param reads, so app code cannot bypass review just by swapping router redirects for direct location navigation.
- That auth open-redirect tracing now also follows aliased query containers like `const params = new URLSearchParams(window.location.search)` and `const url = new URL(window.location.href)`, so later `params.get('next')` or `url.searchParams.get('next')` handoffs still get caught when they feed redirects or direct location navigation.
- Runtime verification now also distinguishes remote assets that declare integrity but omit `crossorigin`, and that signal flows through shortlist benchmarks, intelligence scoring, CLI summaries, registry UI copy, and public schemas.
- Runtime verification now also flags external new-tab links in built HTML that omit `rel="noopener noreferrer"`, and that signal now flows through shortlist benchmarks, intelligence scoring, CLI summaries, registry UI copy, and public schemas alongside the existing source-level link review.
- MCP scaffold/section/page context tools now reuse hosted selected packs as readable fallback context, so missing local `.decantr/context` markdown no longer forces consumers to reconstruct human-readable context from JSON alone.
- Release operations now have a command-level handoff too: `pnpm release:commands` prints exact preflight and publish commands for the selected package wave, so npm publishing can move from “audit says it’s ready” to “run these commands” without manual translation.
- `pnpm release:commands` now also prints exact npm dist-tag repair commands for the selected package wave, so the same handoff covers both publish execution and the live npm cleanup still blocking package graduation.
- The release planning and publish scripts now also accept both `--wave foundation` and `--wave=foundation` style flags, so the operator commands in the runbooks work exactly as documented.
- Project-audit coverage now explicitly locks down the existing client-managed auth persistence teardown path with regressions for patterns like `localStorage.setItem('auth_token', token)`, `document.cookie = 'auth_token=...; path=/'`, and `fetch('/api/me', { headers: { Authorization: 'Bearer ...' } })`, so the verifier's already-modeled auth storage, cookie, and header teardown enforcement stays pinned in place alongside the earlier auth exit work.
- Project-audit coverage now explicitly locks down the existing client-managed auth storage teardown path with regressions for patterns like `localStorage.setItem('auth_token', token)` followed by `await auth.signOut(); return redirect('/login');` without a matching `localStorage.removeItem('auth_token')`, so the verifier's already-modeled `source-auth-storage-teardown-missing` enforcement stays pinned in place alongside the earlier auth persistence work.
- Project-audit coverage now explicitly locks down the existing client-managed auth cookie teardown path with regressions for patterns like `document.cookie = \`auth_token=\${token}; path=/\`` followed by `await auth.signOut(); return redirect('/login');` without a matching cookie expiry or delete step, so the verifier's already-modeled `source-auth-cookie-teardown-missing` enforcement stays pinned in place alongside the earlier auth persistence work.
- Project-audit coverage now explicitly locks down the existing client-managed auth header teardown path with regressions for patterns like `fetch('/api/me', { headers: { Authorization: \`Bearer \${token}\` } })` followed by `await auth.signOut(); return redirect('/login');`, so the verifier's already-modeled `source-auth-header-teardown-missing` enforcement stays pinned in place alongside the earlier auth persistence work.
- Critique coverage now explicitly locks down the existing client-managed auth persistence teardown path with regressions for patterns like `localStorage.setItem('auth_token', token)`, `document.cookie = 'auth_token=...; path=/'`, and `fetch('/api/me', { headers: { Authorization: 'Bearer ...' } })`, so the verifier's already-modeled auth storage, cookie, and header teardown enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing client-managed auth persistence teardown path where a reviewed `UserMenu` writes `localStorage.setItem('auth_token', token)`, `document.cookie = \`auth_token=\${token}; path=/\``, and `fetch('/api/me', { headers: { Authorization: \`Bearer \${token}\` } })`, then calls `await auth.signOut(); return redirect('/login');` without clearing any of those persistence surfaces, so the already-modeled `state-auth-storage-teardown-missing`, `state-auth-cookie-teardown-missing`, and `state-auth-header-teardown-missing` regressions stay pinned in place when critique-side logout flows tear down the session but leave client-managed auth residue behind.
- Project-audit coverage now explicitly locks down the existing client data cache teardown path during sign-out with regressions for patterns like `useQueryClient()`-backed logout handlers that call `auth.signOut()` and immediately `redirect('/login')`, so the verifier's already-modeled `source-auth-cache-teardown-missing` enforcement stays pinned in place alongside the earlier auth persistence work.
- Critique coverage now explicitly locks down the existing client data cache teardown path during sign-out with regressions for patterns like `useQueryClient()`-backed logout handlers that call `auth.signOut()` and immediately `redirect('/login')`, so the verifier's already-modeled `state-auth-cache-teardown-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth refresh teardown path during sign-out with regressions for patterns like `setInterval(() => auth.refreshSession(), 60_000)` that survive `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `source-auth-refresh-teardown-missing` enforcement stays pinned in place alongside the earlier auth cache work.
- Critique coverage now explicitly locks down the existing auth refresh teardown path during sign-out with regressions for patterns like `setInterval(() => auth.refreshSession(), 60_000)` that survive `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `state-auth-refresh-teardown-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing realtime teardown path during sign-out with regressions for patterns like `new WebSocket('wss://example.com/live')` surviving `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `source-auth-realtime-teardown-missing` enforcement stays pinned in place alongside the earlier auth refresh work.
- Critique coverage now explicitly locks down the existing realtime teardown path during sign-out with regressions for patterns like `new WebSocket('wss://example.com/live')` surviving `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `state-auth-realtime-teardown-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing cross-tab auth coordination teardown path during sign-out with regressions for patterns like `new BroadcastChannel('auth')` and `window.addEventListener('storage', syncSession)` surviving `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `source-auth-coordination-teardown-missing` enforcement stays pinned in place alongside the earlier realtime work.
- Critique coverage now explicitly locks down the existing cross-tab auth coordination teardown path during sign-out with regressions for patterns like `new BroadcastChannel('auth')` and `window.addEventListener('storage', syncSession)` surviving `auth.signOut()` and immediate redirects to `/login`, so the verifier's already-modeled `state-auth-coordination-teardown-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project audit and file critique now also flag logout flows that leave client-side query or data caches alive, so reviewed auth exits are expected to reset React Query/Apollo/SWR-style caches before returning users to an anonymous route.
- Project audit and file critique now also flag logout flows that leave background auth refresh timers or subscriptions alive, so session refresh work is expected to stop alongside sign-out instead of continuing after users return to anonymous routes.
- Project audit and file critique now also flag logout flows that leave realtime sockets or channels alive, so protected live data streams are expected to close during sign-out instead of continuing after users return to anonymous routes.
- Project audit and file critique now also flag logout flows that leave cross-tab auth coordination channels or storage listeners alive, so BroadcastChannel and storage-based session sync work is expected to stop alongside sign-out instead of lingering after users return to anonymous routes.
- Project-audit coverage now explicitly locks down the existing protected session-aware surface path that never branches on unauthenticated state, with regressions for patterns like `const { status, data: session } = useSession();`, a loading-only `if (status === 'loading') { return <Spinner />; }`, and a direct protected return such as `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-handling-missing` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected session-aware surface path that never branches on unauthenticated state, with regressions for patterns like `const { status, data: session } = useSession();`, a loading-only `if (status === 'loading') { return <Spinner />; }`, and a direct protected return such as `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-handling-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected session-aware auth-loss path that returns nothing instead of routing users back to an anonymous route, with regressions for patterns like `const { status, data: session } = useSession();`, a loading-only `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return null; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-redirect-missing` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected session-aware auth-loss path that returns nothing instead of routing users back to an anonymous route, with regressions for patterns like `const { status, data: session } = useSession();`, a loading-only `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return null; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-redirect-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected session-aware loading branch that still renders a protected shell, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <DashboardShell path="/dashboard" pendingSession={session} />; }`, an unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected session-aware loading branch that still renders a protected shell, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <DashboardShell path="/dashboard" pendingSession={session} />; }`, an unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth/session loading branch that returns nothing instead of an explicit pending boundary, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return null; }`, an unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-blank-render` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth/session loading branch that returns nothing instead of an explicit pending boundary, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return null; }`, an unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-blank-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth/session loading branch that redirects users to an anonymous route before session resolution finishes, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return redirect('/login'); }`, a trailing unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-anonymous-redirect` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth/session loading branch that redirects users to an anonymous route before session resolution finishes, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return redirect('/login'); }`, a trailing unauthenticated redirect like `if (!session) { return redirect('/login'); }`, and a protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-anonymous-redirect` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected surface that branches on auth loss but still renders a protected destination in the unauthenticated branch, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardShell path="/dashboard" />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected surface that branches on auth loss but still renders a protected destination in the unauthenticated branch, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardShell path="/dashboard" />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected surface that reads auth/session state but never shows an explicit unauthenticated branch, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />` with no `if (!session)` guard at all, so the verifier's already-modeled `source-auth-session-loss-handling-missing` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected surface that reads auth/session state but never shows an explicit unauthenticated branch, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />` with no `if (!session)` guard at all, so the verifier's already-modeled `state-auth-session-loss-handling-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected surface that branches on auth loss but never returns users to a reviewed anonymous route, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return null; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-redirect-missing` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected surface that branches on auth loss but never returns users to a reviewed anonymous route, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return null; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-redirect-missing` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected surface whose auth/session loading branch still renders a protected destination, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <DashboardShell path="/dashboard" pendingSession={session} />; }`, an unauthenticated branch like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected surface whose auth/session loading branch still renders a protected destination, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <DashboardShell path="/dashboard" pendingSession={session} />; }`, an unauthenticated branch like `if (!session) { return redirect('/login'); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project audit and file critique now also flag protected session-aware surfaces that never branch on unauthenticated state, so reviewed dashboard shells cannot quietly keep rendering after session loss just because they only handled the loading path.
- Project audit and file critique now also flag protected session-aware surfaces that handle auth loss by returning nothing instead of routing users back to an anonymous entry point, so reviewed dashboard shells cannot quietly go blank after session loss without re-establishing the gateway boundary.
- Project audit and file critique now also flag protected session-aware surfaces that use the loading branch to render the protected shell itself, so reviewed dashboard shells cannot flash or hydrate privileged UI before session resolution completes.
- Project audit and file critique now also flag auth/session loading branches that return `null` or an empty fragment instead of an explicit pending boundary, so reviewed auth-aware shells cannot hide loading races behind a blank frame.
- Project audit and file critique now also flag auth/session loading branches that redirect straight to anonymous routes before session resolution finishes, so reviewed gateway logic cannot bounce real users to `/login` while a valid session is still loading.
- Project audit and file critique now also flag unauthenticated branches that still render dashboard/app shells, so reviewed protected surfaces cannot acknowledge auth loss and then keep rendering privileged structure anyway.
- Protected-shell detection for auth-loss branches now also catches protected-looking shell component names even when they omit explicit `path="/dashboard"`-style route props, so dashboard/workspace/admin shells do not evade review just by relying on component identity alone.
- Project-audit coverage now explicitly locks down the existing protected-looking unauthenticated shell render even when it omits explicit `path="/dashboard"`-style route props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardShell />; }`, and a trailing protected return like `<DashboardShell session={session} />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the expanded protected-shell detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected-looking unauthenticated shell render even when it omits explicit `path="/dashboard"`-style route props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardShell />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing protected-looking unauthenticated child render even when it is not literally a `*Shell` surface, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardSummary />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the expanded child-component-name detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing protected-looking unauthenticated child render even when it is not literally a `*Shell` surface, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <DashboardSummary />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss render detection now also catches protected-looking child component names such as dashboard/workspace/admin summaries or panels even when they are not literally `*Shell` surfaces, so privileged child renders cannot slip through the unauthenticated branch under softer component naming.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still returns outlet-like protected content, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <Outlet />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer outlet-pass-through detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still returns outlet-like protected content, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <Outlet />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also treats `children`, `props.children`, `Outlet`, `Routes`, and `RouterProvider` pass-through branches as protected renders, so reviewed gates cannot leak nested protected content just by returning the outlet tree directly.
- Protected auth-loss and auth-loading detection now also catches generic component renders that still receive auth-scoped props like `session`, `currentUser`, or `authUser`, so stale privileged state cannot hide behind neutral component names like `SummaryPanel`.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still passes auth-scoped props into a generic component, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <SummaryPanel currentUser={session?.user} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer auth-prop leakage detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still passes auth-scoped props into a generic component, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <SummaryPanel currentUser={session?.user} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches direct JSX interpolation of auth-scoped values like `session?.user?.email`, so stale privileged identity data cannot linger inside otherwise generic markup after reviewed gateway logic has supposedly left the protected state.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still interpolates auth-scoped identity data into generic JSX, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <section>{session?.user?.email}</section>; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer auth-data interpolation detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still interpolates auth-scoped identity data into generic JSX, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return <section>{session?.user?.email}</section>; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches protected route links nested inside otherwise generic markup, so reviewed gateway branches cannot keep advertising `/dashboard` or other privileged destinations from a neutral `<section>` container.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still advertises a protected route from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return (<section><a href="/dashboard">Continue to dashboard</a></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer protected-route link detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still advertises a protected route from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch like `if (!session) { return (<section><a href="/dashboard">Continue to dashboard</a></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches protected route actions hidden behind nested buttons or callback handlers, so reviewed gateway branches cannot keep a stale “continue to dashboard” button alive just by replacing a link with `navigate('/dashboard')`.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes a protected route action from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><button onClick={() => navigate('/dashboard')}>Continue to dashboard</button></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer protected-route callback detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes a protected route action from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><button onClick={() => navigate('/dashboard')}>Continue to dashboard</button></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches nested form submissions into protected routes like `action="/dashboard"`, so reviewed gateway branches cannot preserve privileged navigation by swapping a link or button callback for a form post.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes a protected form submission from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><form action="/dashboard"><button type="submit">Continue to dashboard</button></form></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer protected-route form-action detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes a protected form submission from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><form action="/dashboard"><button type="submit">Continue to dashboard</button></form></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches browser redirects like `window.location.assign('/dashboard')` inside nested callbacks, so reviewed gateway branches cannot preserve privileged navigation by bypassing router helpers entirely.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes a protected browser redirect from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><button onClick={() => window.location.assign('/dashboard')}>Continue to dashboard</button></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer browser-redirect detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes a protected browser redirect from otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><button onClick={() => window.location.assign('/dashboard')}>Continue to dashboard</button></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches hidden redirect payloads like `<input type="hidden" value="/dashboard" />` inside nested markup, so reviewed gateway branches cannot stash privileged destinations in invisible form state after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still stashes a protected hidden redirect inside otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><input type="hidden" name="redirectTo" value="/dashboard" /></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer hidden-redirect-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still stashes a protected hidden redirect inside otherwise generic markup, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section><input type="hidden" name="redirectTo" value="/dashboard" /></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches `data-redirect` / `data-next` style metadata carrying reviewed protected routes, so reviewed gateway branches cannot preserve privileged destinations by hiding them in seemingly neutral markup attributes.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still stashes a protected route inside otherwise generic redirect metadata, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section data-redirect="/dashboard"><p>Loading account context...</p></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer metadata-carrier detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still stashes a protected route inside otherwise generic redirect metadata, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return (<section data-redirect="/dashboard"><p>Loading account context...</p></section>); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches neutral component props like `redirectTo="/dashboard"` or `returnTo="/dashboard"`, so reviewed gateway branches cannot smuggle privileged destinations through helper components after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still passes a protected redirect helper prop, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard redirectTo="/dashboard" />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer neutral-component-prop detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still passes a protected redirect helper prop, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard redirectTo="/dashboard" />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches nested object props like `state={{ redirectTo: '/dashboard' }}` or `options={{ returnTo: '/dashboard' }}`, so reviewed gateway branches cannot preserve privileged destinations inside seemingly generic helper payloads.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still passes a protected redirect object prop, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard state={{ redirectTo: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer nested-object-prop detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still passes a protected redirect object prop, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard state={{ redirectTo: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches generic config payloads like `config={{ to: '/dashboard' }}` or `config={{ path: '/dashboard' }}`, so reviewed gateway branches cannot hide privileged route intent inside neutral helper objects after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still passes a protected generic route object, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard config={{ to: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer generic-config-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still passes a protected generic route object, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard config={{ to: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches serialized route payloads like `payload={JSON.stringify({ redirectTo: '/dashboard' })}`, so reviewed gateway branches cannot preserve privileged destinations by wrapping them in stringified helper configs after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still serializes a protected route payload, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={JSON.stringify({ redirectTo: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer serialized-route-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still serializes a protected route payload, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={JSON.stringify({ redirectTo: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches querystring-encoded helper payloads like `payload={new URLSearchParams({ next: '/dashboard' }).toString()}`, so reviewed gateway branches cannot preserve privileged destinations by hiding them inside encoded helper state after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still hides a protected route inside encoded helper state, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={new URLSearchParams({ next: '/dashboard' }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer querystring-encoded-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still hides a protected route inside encoded helper state, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={new URLSearchParams({ next: '/dashboard' }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches router-helper payloads like `payload={createSearchParams({ next: '/dashboard' }).toString()}`, so reviewed gateway branches cannot preserve privileged destinations by relying on framework query helpers instead of native `URLSearchParams`.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still hides a protected route inside router-helper payloads, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={createSearchParams({ next: '/dashboard' }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer router-helper-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still hides a protected route inside router-helper payloads, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={createSearchParams({ next: '/dashboard' }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches JSX expression-wrapped route props like `to={'/dashboard'}` or ``redirectTo={`/dashboard`}``, so reviewed gateway branches cannot evade route leakage checks just by wrapping privileged destinations in JSX expressions instead of plain string props.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes protected route props through JSX expressions, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={'/dashboard'} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer JSX-expression route-prop detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes protected route props through JSX expressions, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={'/dashboard'} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes protected helper props through JSX expressions, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirectTo={\`/dashboard\`} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer JSX-expression route-prop detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes protected helper props through JSX expressions, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirectTo={\`/dashboard\`} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches route-object props like `to={{ pathname: '/dashboard' }}` or `redirect={{ pathname: '/dashboard' }}`, so reviewed gateway branches cannot preserve privileged destinations by hiding them inside router descriptor objects after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes protected route objects through pathname props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={{ pathname: '/dashboard' }} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer pathname-prop route-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes protected route objects through pathname props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={{ pathname: '/dashboard' }} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route objects through pathname props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirect={{ pathname: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer pathname-prop route-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route objects through pathname props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirect={{ pathname: '/dashboard' }} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches callback navigation objects like `navigate({ pathname: '/dashboard' })` inside returned UI, so reviewed gateway branches cannot preserve privileged navigation by swapping string route callbacks for router descriptor objects after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes protected route objects through callback navigation, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return ( <section><button onClick={() => navigate({ pathname: '/dashboard' })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer callback-navigation route-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes protected route objects through callback navigation, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return ( <section><button onClick={() => navigate({ pathname: '/dashboard' })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route objects through callback navigation, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate({ pathname: '/dashboard' })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer callback-navigation route-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route objects through callback navigation, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate({ pathname: '/dashboard' })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches helper-generated destinations like `generatePath('/dashboard')` and `createPath({ pathname: '/dashboard' })`, so reviewed gateway branches cannot preserve privileged navigation by synthesizing protected routes through router helper APIs after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route props, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={generatePath('/dashboard')} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer helper-generated-route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route props, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={generatePath('/dashboard')} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected callback destinations, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return ( <section><button onClick={() => navigate(createPath({ pathname: '/dashboard' }))}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer helper-generated-route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected callback destinations, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return ( <section><button onClick={() => navigate(createPath({ pathname: '/dashboard' }))}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected callback destinations, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate(createPath({ pathname: '/dashboard' }))}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer helper-generated-route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected callback destinations, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate(createPath({ pathname: '/dashboard' }))}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route props, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirectTo={generatePath('/dashboard')} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer helper-generated-route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route props, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard redirectTo={generatePath('/dashboard')} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches helper-generated `pathname` route objects like `to={{ pathname: generatePath('/dashboard') }}` and `navigate({ pathname: createPath({ pathname: '/dashboard' }) })`, so guarded branches cannot smuggle protected destinations through route-object wrappers after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route objects, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={{ pathname: generatePath('/dashboard') }} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer helper-generated-pathname-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route objects, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Navigate to={{ pathname: generatePath('/dashboard') }} replace />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route objects through callback navigation, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate({ pathname: createPath({ pathname: '/dashboard' }) })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer helper-generated-pathname-object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route objects through callback navigation, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return ( <section><button onClick={() => navigate({ pathname: createPath({ pathname: '/dashboard' }) })}>Continue</button></section> ); }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches array-carried route payloads like `items={[{ to: '/dashboard' }]}` and `links={[{ href: '/dashboard' }]}`, so reviewed gateway branches cannot preserve privileged destinations by tucking them into nav/config collections after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes protected route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ to: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer array-carried route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes protected route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ to: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ href: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer array-carried route detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes protected route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ href: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches helper-generated destinations inside nav/config arrays like `items={[{ to: generatePath('/dashboard') }]}` and `links={[{ pathname: createPath({ pathname: '/dashboard' }) }]}`, so reviewed gateway branches cannot preserve privileged destinations by combining array-carried configs with router helper APIs after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route arrays, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ to: generatePath('/dashboard'), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer helper-generated-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes helper-generated protected route arrays, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ to: generatePath('/dashboard'), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route arrays, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ pathname: createPath({ pathname: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer helper-generated-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated protected route arrays, with regressions for patterns like `import { createPath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ pathname: createPath({ pathname: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches helper-style redirect props inside nav/config arrays like `items={[{ redirectTo: '/dashboard' }]}` and `links={[{ returnTo: generatePath('/dashboard') }]}`, so reviewed gateway branches cannot preserve privileged destinations by swapping route keys for helper-prop keys inside array-carried configs after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes helper-prop route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ redirectTo: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer helper-prop-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes helper-prop route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ redirectTo: '/dashboard', label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated helper-prop route arrays, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ returnTo: generatePath('/dashboard'), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer helper-generated helper-prop-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes helper-generated helper-prop route arrays, with regressions for patterns like `import { generatePath } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ returnTo: generatePath('/dashboard'), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches nested state/options payloads inside nav/config arrays like `items={[{ state: { redirectTo: '/dashboard' } }]}` and `links={[{ options: { returnTo: '/dashboard' } }]}`, so reviewed gateway branches cannot preserve privileged destinations by nesting redirect payloads one object deeper inside array-carried configs after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes nested redirect state arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ state: { redirectTo: '/dashboard' }, label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer nested-array redirect detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes nested redirect state arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ state: { redirectTo: '/dashboard' }, label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes nested redirect state arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ options: { returnTo: '/dashboard' }, label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer nested-array redirect detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes nested redirect state arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ options: { returnTo: '/dashboard' }, label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches serialized or query-encoded payloads inside nav/config arrays like `items={[{ payload: JSON.stringify({ redirectTo: '/dashboard' }) }]}` and `links={[{ payload: createSearchParams({ path: '/dashboard' }).toString() }]}`, so reviewed gateway branches cannot preserve privileged destinations by hiding them inside encoded array item payloads after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes serialized redirect payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: JSON.stringify({ redirectTo: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer encoded-array redirect detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes serialized redirect payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: JSON.stringify({ redirectTo: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes encoded redirect payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ path: '/dashboard' }).toString(), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer encoded-array redirect detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes encoded redirect payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ path: '/dashboard' }).toString(), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches stale auth-scoped data hidden inside nav/config arrays like `items={[{ label: session?.user?.email, href: '/login' }]}` and `links={[{ label: currentUser?.email, href: '/login' }]}`, so reviewed gateway branches cannot leak privileged identity data through config-driven UI after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ label: session?.user?.email, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer auth-scoped-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ label: session?.user?.email, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ label: currentUser?.email, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer auth-scoped-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ label: currentUser?.email, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches stale auth-scoped data buried inside nested array metadata like `items={[{ meta: { label: session?.user?.email }, href: '/login' }]}` and `links={[{ details: { subtitle: currentUser?.email }, href: '/login' }]}`, so config-driven gateway surfaces cannot leak privileged identity data by nesting it inside secondary array objects after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes nested auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ meta: { label: session?.user?.email }, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer nested auth-scoped-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes nested auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ meta: { label: session?.user?.email }, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes nested auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ details: { subtitle: currentUser?.email }, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer nested auth-scoped-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes nested auth-scoped data arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ details: { subtitle: currentUser?.email }, href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches stale auth-scoped data encoded into array payloads like `items={[{ payload: JSON.stringify({ label: session?.user?.email }), href: '/login' }]}` and `links={[{ payload: createSearchParams({ email: currentUser?.email }).toString(), href: '/login' }]}`, so config-driven gateway surfaces cannot leak privileged identity data by serializing it into payload helpers after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes encoded auth-scoped payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: JSON.stringify({ label: session?.user?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer encoded auth-scoped-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes encoded auth-scoped payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: JSON.stringify({ label: session?.user?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes encoded auth-scoped payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ email: currentUser?.email }).toString(), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer encoded auth-scoped-payload-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes encoded auth-scoped payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ email: currentUser?.email }).toString(), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also catches stale auth-scoped data encoded into direct helper props like `payload={JSON.stringify({ label: session?.user?.email })}` and `payload={createSearchParams({ email: currentUser?.email }).toString()}`, so neutral status surfaces cannot leak privileged identity data by serializing it into non-array payload helpers after auth loss.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes encoded auth-scoped direct helper props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={JSON.stringify({ label: session?.user?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer direct-helper auth-scoped-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes encoded auth-scoped direct helper props, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={JSON.stringify({ label: session?.user?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still encodes auth-scoped payloads with `createSearchParams(...)`, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ email: currentUser?.email }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer direct-helper auth-scoped-payload detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still encodes auth-scoped payloads with `createSearchParams(...)`, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ email: currentUser?.email }).toString()} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Protected auth-loss and auth-loading detection now also treats raw `new URLSearchParams(...)` and `createSearchParams(...)` helper objects as risky too, so reviewed surfaces cannot preserve `/dashboard` routes or stale identity data by passing `payload={new URLSearchParams({ next: '/dashboard' })}`, `payload={new URLSearchParams({ path: '/dashboard' })}`, `payload={new URLSearchParams({ email: session?.user?.email })}`, `links={[{ payload: new URLSearchParams({ next: '/dashboard' }) }]}`, `links={[{ payload: new URLSearchParams({ path: '/dashboard' }) }]}`, `links={[{ payload: new URLSearchParams({ email: currentUser?.email }) }]}`, `payload={createSearchParams({ next: '/dashboard' })}`, `payload={createSearchParams({ path: '/dashboard' })}`, `links={[{ payload: createSearchParams({ next: '/dashboard' }) }]}`, `links={[{ payload: createSearchParams({ path: '/dashboard' }) }]}`, or `links={[{ payload: createSearchParams({ email: currentUser?.email }) }]}` without an immediate `.toString()`.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes raw `createSearchParams(...)` route payload objects, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={createSearchParams({ next: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer raw `createSearchParams(...)` direct-helper detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes raw `createSearchParams(...)` route payload objects, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={createSearchParams({ next: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` path payload objects, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ path: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw `createSearchParams(...)` direct-helper detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` path payload objects, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ path: '/dashboard' })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ email: currentUser?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw-helper object detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={createSearchParams({ email: currentUser?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` auth payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ email: currentUser?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw-helper array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` auth payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ email: currentUser?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes `URLSearchParams` payload objects in route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: new URLSearchParams({ next: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` route-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes `URLSearchParams` payload objects in route arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: new URLSearchParams({ next: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes raw `createSearchParams(...)` next payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: createSearchParams({ next: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer raw `createSearchParams(...)` route-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes raw `createSearchParams(...)` next payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: createSearchParams({ next: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` route payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ path: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw `createSearchParams(...)` route-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `createSearchParams(...)` route payload arrays, with regressions for patterns like `import { createSearchParams } from 'react-router-dom';`, `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: createSearchParams({ path: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `URLSearchParams` route payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: new URLSearchParams({ path: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` route-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `URLSearchParams` route payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: new URLSearchParams({ path: '/dashboard' }), label: 'Dashboard' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes direct `URLSearchParams` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={new URLSearchParams({ email: currentUser?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` direct-helper detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes direct `URLSearchParams` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <StatusCard payload={new URLSearchParams({ email: currentUser?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `URLSearchParams` auth payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: new URLSearchParams({ email: currentUser?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-session-loss-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` auth-payload-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing unauthenticated branch that still exposes raw `URLSearchParams` auth payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, `const currentUser = session?.user;`, a loading branch such as `if (status === 'loading') { return <Spinner />; }`, an unauthenticated branch such as `if (!session) { return <Sidebar links={[{ payload: new URLSearchParams({ email: currentUser?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-session-loss-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes raw `URLSearchParams` auth payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: new URLSearchParams({ email: session?.user?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` auth-payload-array detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes raw `URLSearchParams` auth payload arrays, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <QuickNav items={[{ payload: new URLSearchParams({ email: session?.user?.email }), href: '/login' }]} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth-loading branch that still exposes direct `URLSearchParams` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={new URLSearchParams({ email: session?.user?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `source-auth-loading-protected-render` enforcement stays pinned in place alongside the newer raw `URLSearchParams` direct-helper detection before the critique-side companion.
- Critique coverage now explicitly locks down the existing auth-loading branch that still exposes direct `URLSearchParams` auth payload objects, with regressions for patterns like `const { status, data: session } = useSession();`, a loading branch such as `if (status === 'loading') { return <StatusCard payload={new URLSearchParams({ email: session?.user?.email })} />; }`, and a trailing protected return like `<DashboardShell session={session} path="/dashboard" />`, so the verifier's already-modeled `state-auth-loading-protected-render` enforcement stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows destructured and aliased query carriers like `const { searchParams: params } = new URL(window.location.href)`, aliased query keys like `const queryKey = 'next'`, and destructured query payloads like `const { next: redirectTo } = router.query`, so later `params.get(queryKey)` or `redirect(redirectTo ?? '/dashboard')` handoffs still get caught in both project audit and file critique.
- Auth open-redirect tracing now also follows destructured `query` carriers like `const { query: params } = router` and bracket-access reads like `query[queryKey]`, so auth flows cannot evade redirect-param detection just by swapping dot access for destructuring or indexed query lookups before calling `redirect(...)` or similar route transitions.
- Auth open-redirect tracing now also recurses into object-shaped route descriptors like `navigate({ pathname: next ?? '/dashboard' })` and `<Link to={{ pathname: next ?? '/dashboard' }}>`, so aliased redirect params cannot slip past the verifier just by being wrapped inside router object payloads before the transition call or JSX route prop.
- Auth open-redirect tracing now also follows server handler URL parsing like `new URL(request.url).searchParams.get('next')` and `new URL(req.url).searchParams.get('next')`, so route handlers and server auth callbacks cannot bypass redirect-param detection by pulling the same untrusted destination out of the incoming request URL instead of browser location state.
- Auth open-redirect tracing now also treats plain `searchParams` object props as redirect carriers, so server-rendered login routes like `redirect(searchParams.next ?? '/dashboard')` and aliased/indexed variants like `const { searchParams: params } = props; params[queryKey]` get caught too instead of only the `searchParams.get('next')` family.
- Auth open-redirect tracing now also follows parameter-destructured and nested `searchParams` props like `function LoginRedirect({ searchParams: params }) { ... }` and `function LoginRedirect({ searchParams: { next } }) { ... }`, so auth entry routes cannot hide unreviewed `next` handoffs behind destructured function signatures instead of local aliases.
- Auth open-redirect tracing now also recurses into template-wrapped route handoffs like ``redirect(`${next ?? '/dashboard'}`)`` and `<Link to={`${next ?? '/dashboard'}`}>`, so aliased redirect params cannot bypass the verifier just by being interpolated into template strings before the transition sink.
- Auth open-redirect tracing now also treats common snake/kebab redirect keys like `return_to`, `redirect_to`, and `callback_url` as first-class redirect carriers, so auth flows cannot evade review simply by switching from camel-case query names like `returnTo` to more backend-shaped parameter names before redirecting into `/dashboard`.
- Auth open-redirect tracing now also follows `req.nextUrl.searchParams.get(...)` in addition to `request.nextUrl.searchParams.get(...)` and `new URL(req.url).searchParams.get(...)`, so server auth handlers cannot bypass redirect-param detection just by renaming the request object while still trusting the same incoming Next.js query state.
- Auth open-redirect tracing now also follows aliased `req.nextUrl.searchParams` containers like `const params = req.nextUrl.searchParams; params.get(queryKey)`, so server auth handlers cannot evade review by lifting Next.js query state into a local alias before consuming `next` in a redirect sink.
- Auth open-redirect tracing now also follows aliased and destructured `req.nextUrl` bases like `const nextUrl = req.nextUrl` and `const { nextUrl } = req`, so server auth handlers cannot bypass redirect-param detection by hoisting the Next.js URL object first and only reading `nextUrl.searchParams` later.
- Auth open-redirect tracing now also recurses through URL-constructor wrappers like `NextResponse.redirect(new URL(next ?? '/dashboard', req.url))`, so server handlers cannot hide the same raw `next` redirect source just by normalizing it through `new URL(...)` before returning the response.
- Auth open-redirect tracing now also follows aliased URL-constructor bases like `const requestUrl = req.url; new URL(next ?? '/dashboard', requestUrl)`, so server handlers cannot bypass redirect-param detection by hoisting the request URL into a local variable before wrapping the destination.
- Auth open-redirect tracing now also follows destructured browser location carriers like `const { search } = window.location; new URLSearchParams(search).get('next')` and `const { href } = window.location; new URL(href).searchParams.get('next')`, so client auth routes cannot bypass redirect-param detection by pulling `search` or `href` off `window.location` before reading and forwarding the same untrusted destination.
- Auth open-redirect tracing now also treats `globalThis.location` and destructured global location bases like `const { location } = globalThis` as first-class carriers, so browser auth flows cannot bypass redirect-param detection by swapping from `window.location` to the generic global location surface before reading `next` and redirecting into `/dashboard`.
- Auth open-redirect tracing now also follows aliased location objects like `const browserLocation = window.location` or `const browserLocation = globalThis.location`, so browser auth flows cannot evade detection by hoisting the location object first and only then reading `browserLocation.search`, `browserLocation.href`, `browserLocation.assign(...)`, or `browserLocation.href = next ?? '/dashboard'`.
- Auth open-redirect tracing now also treats `document.location` and aliased document location objects as first-class carriers, so browser auth flows cannot bypass redirect-param detection by switching to the older DOM location surface before reading `next` and handing it to `document.location.assign(...)` or `browserLocation.href = next ?? '/dashboard'`.
- Auth open-redirect tracing now also treats frame/window variants like `self.location`, `parent.location`, and `top.location` as first-class carriers, so embedded auth flows cannot bypass redirect-param detection by reading `next` from a frame-level location object and handing it to `self.location.assign(...)` or `frameLocation.href = next ?? '/dashboard'`.
- Auth open-redirect tracing now also follows bracketed location access like `self['location']['search']`, `self['location']['assign'](...)`, `parent['location']`, and `frameLocation['href'] = next ?? '/dashboard'`, so auth flows cannot bypass redirect-param detection just by swapping dot access for element-access syntax on browser location carriers and sinks.
- Auth open-redirect tracing now also follows bracketed query getter calls like `req['nextUrl']['searchParams']['get']('next')` and `searchParams['get']('next')`, so auth flows cannot bypass redirect-param detection by swapping `params.get(...)` for element-access calls on the same reviewed query carrier.
- Auth open-redirect tracing now also follows bracketed location access through aliased browser/frame bases like `const browser = window; browser['location']['assign'](...)`, so auth flows cannot bypass redirect-param detection by hoisting `window`, `self`, or `parent` into a local alias before reading `['location']` and forwarding the same untrusted destination.
- Auth open-redirect tracing now also treats bracketed route-transition sinks like `router['push'](...)` and `router['replace'](...)` the same as dot-access router calls, so auth flows cannot bypass redirect-param detection just by swapping `router.push(next)` for element-access syntax before navigating into a privileged destination.
- Auth open-redirect tracing now also treats History API transitions like `history.pushState(...)`, `history.replaceState(...)`, and aliased `window.history` calls as reviewed route-transition sinks, so auth flows cannot bypass redirect-param detection just by mutating the browser URL through the History API instead of router helpers or redirect functions.
- Auth open-redirect tracing now also treats `useSearchParams()` hook results, including tuple-destructured forms like `const [params] = useSearchParams()`, as reviewed query carriers, so auth flows cannot bypass redirect-param detection by pulling `next` from framework hook state instead of props, router query objects, or raw request/browser URL helpers.
- Auth open-redirect tracing now also treats `useRouter()` hook results as reviewed query-container bases, including renamed forms like `const appRouter = useRouter()` and destructured aliases like `const { query: params } = useRouter()`, so auth flows cannot bypass redirect-param detection just by hiding `query.next` behind framework hook output instead of a prop literally named `router`.
- Auth open-redirect tracing now also follows redirect params through common transformations like `decodeURIComponent(searchParams.get('next'))`, chained helper access, and repeated-query reads like `searchParams.getAll('next')[0]`, so auth flows cannot bypass redirect-param detection just by wrapping or indexing the same unreviewed destination before handing it to a redirect sink.
- Auth open-redirect tracing now also treats `useLocation()` hook results as reviewed location carriers, including aliased forms like `const routeLocation = useLocation()` and destructured forms like `const { search } = useLocation()`, so router-driven auth entry routes cannot bypass redirect-param detection by reading `next` from hook-managed route state instead of raw `window.location`.
- Auth open-redirect tracing now also follows cloned Next.js request URLs like `req.nextUrl.clone()`, including aliased `searchParams` reads off the cloned object, so middleware and route handlers cannot bypass redirect-param detection just by copying the incoming request URL before consuming `next`.
- Auth open-redirect tracing now also treats Next.js `nextUrl.search` and `nextUrl.href` as reviewed URL carriers, so middleware and route handlers cannot bypass redirect-param detection by reparsing the same incoming request URL through `new URLSearchParams(req.nextUrl.search)` or `new URL(nextUrl.href)` before redirecting.
- Auth open-redirect tracing now also treats stringified reviewed URL carriers like `req.nextUrl.toString()` and `String(nextUrl)` as equivalent URL inputs, so middleware and route handlers cannot bypass redirect-param detection by stringifying a trusted request URL object and then reparsing it through `new URL(...)` before consuming `next`.
- Project-audit coverage now explicitly locks down the existing stringified reviewed URL-carrier path with regressions for patterns like `const next = new URL(String(nextUrl)).searchParams.get('next')`, so the verifier’s already-modeled stringified URL-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing stringified reviewed URL-carrier path with regressions for patterns like `const next = new URL(String(nextUrl)).searchParams.get('next')`, so the verifier’s already-modeled stringified URL-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also treats `Object.fromEntries(searchParams)` as a reviewed query carrier, including destructured forms like `const { next } = Object.fromEntries(...)`, so auth flows cannot bypass redirect-param detection by converting reviewed search params into a plain object and then reading `query.next` before redirecting.
- Project-audit coverage now explicitly locks down the existing `Object.fromEntries(...)` query-carrier path with regressions for patterns like `const query = Object.fromEntries(req.nextUrl.searchParams); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled plain-object query-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `Object.fromEntries(...)` query-carrier path with regressions for patterns like `const query = Object.fromEntries(req.nextUrl.searchParams); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled plain-object query-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing destructured `Object.fromEntries(...)` query-carrier path with regressions for patterns like `const { next } = Object.fromEntries(new URLSearchParams(window.location.search)); return redirect(next ?? '/dashboard')`, so the verifier’s already-modeled destructured plain-object query-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing destructured `Object.fromEntries(...)` query-carrier path with regressions for patterns like `const { next } = Object.fromEntries(new URLSearchParams(window.location.search)); return redirect(next ?? '/dashboard')`, so the verifier’s already-modeled destructured plain-object query-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased `searchParams.entries()` iterators passed into `Object.fromEntries(...)`, so auth flows cannot bypass redirect-param detection by lifting the reviewed entries iterator into a local `entries` variable before materializing `query.next`.
- Project-audit coverage now explicitly locks down the existing aliased `searchParams.entries()` iterator path feeding `Object.fromEntries(...)`, with regressions for patterns like `const entries = new URLSearchParams(window.location.search).entries(); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled aliased reviewed-entries behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased `searchParams.entries()` iterator path feeding `Object.fromEntries(...)`, with regressions for patterns like `const entries = new URLSearchParams(window.location.search).entries(); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled aliased reviewed-entries behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows `Array.from(...)` and spread-array wrappers around reviewed search-param iterables like `Object.fromEntries(Array.from(searchParams.entries()))` and `Object.fromEntries([...searchParams])`, so auth flows cannot bypass redirect-param detection by materializing reviewed query pairs into intermediate arrays before reading `query.next`.
- Project-audit coverage now explicitly locks down the existing `Array.from(...)`-wrapped reviewed-entries path feeding `Object.fromEntries(...)`, with regressions for patterns like `const entries = Array.from(new URLSearchParams(window.location.search).entries()); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled materialized reviewed-entries behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `Array.from(...)`-wrapped reviewed-entries path feeding `Object.fromEntries(...)`, with regressions for patterns like `const entries = Array.from(new URLSearchParams(window.location.search).entries()); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled materialized reviewed-entries behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing spread-wrapped reviewed-search-param iterable path feeding `Object.fromEntries(...)`, with regressions for patterns like `const query = Object.fromEntries([...new URLSearchParams(window.location.search)]); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled spread-materialized reviewed-entries behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing spread-wrapped reviewed-search-param iterable path feeding `Object.fromEntries(...)`, with regressions for patterns like `const query = Object.fromEntries([...new URLSearchParams(window.location.search)]); return redirect(query.next ?? '/dashboard')`, so the verifier’s already-modeled spread-materialized reviewed-entries behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows optional-chain access across both reviewed carriers and navigation sinks like `searchParams?.get('next')`, `query?.next`, `router?.push(next)`, and `window.location?.assign(next)`, so auth flows cannot bypass redirect-param detection just by inserting `?.` between the same reviewed redirect source and the eventual sink.
- Project-audit coverage now explicitly locks down the existing optional-chained reviewed carrier path with regressions for patterns like `redirect(searchParams?.get('next') ?? '/dashboard')` and `redirect(query?.next ?? '/dashboard')`, so the verifier’s already-modeled optional carrier behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing optional-chained reviewed carrier path with regressions for patterns like `redirect(searchParams?.get('next') ?? '/dashboard')` and `redirect(query?.next ?? '/dashboard')`, so the verifier’s already-modeled optional carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing optional-chained navigation sink path with regressions for patterns like `router?.push(searchParams.get('next') ?? '/dashboard')` and `window.location?.assign(searchParams.get('next') ?? '/dashboard')`, so the verifier’s already-modeled optional sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing optional-chained navigation sink path with regressions for patterns like `router?.push(searchParams.get('next') ?? '/dashboard')` and `window.location?.assign(searchParams.get('next') ?? '/dashboard')`, so the verifier’s already-modeled optional sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows bound and wrapper-based reviewed query readers like `const readRedirect = searchParams.get.bind(searchParams)` and `get.call(searchParams, 'next')`, so auth flows cannot bypass redirect-param detection just by hoisting `searchParams.get` into a helper before the eventual redirect sink.
- Project-audit coverage now explicitly locks down the existing bound and wrapper-based reviewed query-reader path with regressions for patterns like `const readRedirect = searchParams.get.bind(searchParams)` and `get.call(searchParams, 'next')`, so the verifier’s already-modeled helper-wrapped query-reader behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing bound and wrapper-based reviewed query-reader path with regressions for patterns like `const readRedirect = searchParams.get.bind(searchParams)` and `get.call(searchParams, 'next')`, so the verifier’s already-modeled helper-wrapped query-reader behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows simple local helper wrappers like `const readRedirect = (key) => searchParams.get(key)` and `function readRedirect(searchParams, key) { return searchParams.get(key); }`, so auth flows cannot bypass redirect-param detection just by hiding the same reviewed query read behind a tiny local helper before redirecting.
- Project-audit coverage now explicitly locks down the existing simple local helper-reader path with regressions for patterns like `const readRedirect = (key) => searchParams.get(key)` and `function readRedirect(searchParams, key) { return searchParams.get(key); }`, so the verifier’s already-modeled helper-wrapped query-reader behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing simple local helper-reader path with regressions for patterns like `const readRedirect = (key) => searchParams.get(key)` and `function readRedirect(searchParams, key) { return searchParams.get(key); }`, so the verifier’s already-modeled helper-wrapped query-reader behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows object-shaped local helpers like `helpers.readRedirect('next')` and destructured aliases like `const { readRedirect } = helpers`, so auth flows cannot bypass redirect-param detection by stashing the same reviewed query read behind a small object method before redirecting.
- Project-audit coverage now explicitly locks down the existing object-shaped local helper-reader path with regressions for patterns like `helpers.readRedirect('next')` and `const { readRedirect } = helpers`, so the verifier’s already-modeled object-helper query-reader behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing object-shaped local helper-reader path with regressions for patterns like `helpers.readRedirect('next')` and `const { readRedirect } = helpers`, so the verifier’s already-modeled object-helper query-reader behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows nested helper objects like `helpers.redirect.readRedirect('next')` and destructured helper-object aliases like `const { redirect: redirectHelpers } = helpers`, so auth flows cannot bypass redirect-param detection by hiding the same reviewed query read one object layer deeper before redirecting.
- Project-audit coverage now explicitly locks down the existing nested helper-object reader path with regressions for patterns like `helpers.redirect.readRedirect('next')` and `const { redirect: redirectHelpers } = helpers`, so the verifier’s already-modeled nested object-helper query-reader behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing nested helper-object reader path with regressions for patterns like `helpers.redirect.readRedirect('next')` and `const { redirect: redirectHelpers } = helpers`, so the verifier’s already-modeled nested object-helper query-reader behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows helper factories like `const helpers = createRedirectHelpers(searchParams)` and destructured factory results like `const { readRedirect } = createRedirectHelpers(searchParams)`, so auth flows cannot bypass redirect-param detection by returning the same reviewed query reader from a small local factory before redirecting.
- Project-audit coverage now explicitly locks down the existing helper-factory reader path with regressions for patterns like `const helpers = createRedirectHelpers(searchParams)` and `const { readRedirect } = createRedirectHelpers(searchParams)`, so the verifier’s already-modeled factory-produced query-reader behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing helper-factory reader path with regressions for patterns like `const helpers = createRedirectHelpers(searchParams)` and `const { readRedirect } = createRedirectHelpers(searchParams)`, so the verifier’s already-modeled factory-produced query-reader behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves helper-factory closure bindings like `function createRedirectHelpers(params) { return { readRedirect() { return params.get(...) } }; }`, so auth flows cannot bypass redirect-param detection just by renaming the reviewed `searchParams` carrier inside a small factory before returning and calling the helper object.
- Auth open-redirect tracing now also follows function-returning helper factories like `const readRedirect = createReadRedirect(searchParams)` and aliased returns like `return getRedirectFromQuery`, so auth flows cannot bypass redirect-param detection by wrapping the same reviewed query read in a returned closure before redirecting.
- Project-audit coverage now explicitly locks down the existing returned helper-factory reader path with regressions for patterns like `const readRedirect = createReadRedirect(searchParams)` and aliased returns like `return getRedirectFromQuery`, so the verifier’s already-modeled returned query-reader factory behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned helper-factory reader path with regressions for patterns like `const readRedirect = createReadRedirect(searchParams)` and aliased returns like `return getRedirectFromQuery`, so the verifier’s already-modeled returned query-reader factory behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also treats returned query-reader closures as getter helpers even through wrappers like `readRedirect.call(null, 'next')`, `readRedirect.apply(null, ['next'])`, `Reflect.apply(readRedirect, null, ['next'])`, and `createReadRedirect(searchParams).bind(null)`, so auth flows cannot bypass redirect-param detection by wrapping the returned helper closure before invoking it with the same raw redirect key.
- Project-audit coverage now explicitly locks down the existing wrapped returned-helper reader path with regressions for patterns like `readRedirect.call(null, 'next')`, `readRedirect.apply(null, ['next'])`, `Reflect.apply(readRedirect, null, ['next'])`, and `createReadRedirect(searchParams).bind(null)`, so the verifier’s already-modeled wrapped helper-closure behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped returned-helper reader path with regressions for patterns like `readRedirect.call(null, 'next')`, `readRedirect.apply(null, ['next'])`, `Reflect.apply(readRedirect, null, ['next'])`, and `createReadRedirect(searchParams).bind(null)`, so the verifier’s already-modeled wrapped helper-closure behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through fallback expressions like `const readRedirect = (key) => params.getAll(key)[0] ?? '/dashboard'` and `const readRedirect = (key) => params.getAll(key)[0] || '/dashboard'`, so auth flows cannot bypass redirect-param detection just by layering a local default route over the same raw redirect param before redirecting.
- Project-audit coverage now explicitly locks down the existing nullish-fallback returned-helper reader path with regressions for patterns like `const readRedirect = createReadRedirect(searchParams)` paired with `return (key) => params.getAll(key)[0] ?? '/dashboard'`, so the verifier’s already-modeled local-default helper-closure behavior stays pinned in place alongside the existing critique fallback coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing logical-or returned-helper reader path with regressions for patterns like `const readRedirect = createReadRedirect(searchParams)` paired with `return (key) => params.getAll(key)[0] || '/dashboard'`, so the verifier’s already-modeled local-default helper-closure behavior stays pinned in place alongside the earlier project-audit fallback coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through ternaries like `const readRedirect = (key) => key === 'next' ? params.getAll(key)[0] : '/dashboard'` and the branch-flipped equivalent, so auth flows cannot bypass redirect-param detection by hiding the same raw redirect param behind a local conditional branch before redirecting.
- Project-audit coverage now explicitly locks down the existing returned-helper ternary path with regressions for patterns like `return (key) => key === 'default' ? '/dashboard' : params.getAll(key)[0]` and `return (key) => key === 'next' ? params.getAll(key)[0] : '/dashboard'`, so the verifier’s already-modeled conditional helper-closure behavior stays pinned in place alongside the existing critique ternary coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned-helper ternary path with regressions for patterns like `return (key) => key === 'default' ? '/dashboard' : params.getAll(key)[0]` and `return (key) => key === 'next' ? params.getAll(key)[0] : '/dashboard'`, so the verifier’s already-modeled conditional helper-closure behavior stays pinned in place alongside the earlier project-audit ternary coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through template wrappers like ``const readRedirect = (key) => `${params.getAll(key)[0]}` ``, so auth flows cannot bypass redirect-param detection by stringifying the same raw redirect param inside a local template literal before redirecting.
- Project-audit coverage now explicitly locks down the existing returned-helper template-wrapper path with regressions for patterns like ``return (key) => `${params.getAll(key)[0]}` ``, so the verifier’s already-modeled stringified helper-closure behavior stays pinned in place alongside the existing critique template coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned-helper template-wrapper path with regressions for patterns like ``return (key) => `${params.getAll(key)[0]}` ``, so the verifier’s already-modeled stringified helper-closure behavior stays pinned in place alongside the earlier project-audit template coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through tagged template wrappers like ``const readRedirect = (key) => String.raw`${params.getAll(key)[0]}` ``, so auth flows cannot bypass redirect-param detection by stringifying the same raw redirect param inside a tagged template before redirecting.
- Project-audit coverage now explicitly locks down the existing returned-helper tagged-template path with regressions for patterns like ``return (key) => String.raw`${params.getAll(key)[0]}` ``, so the verifier’s already-modeled tagged-string helper-closure behavior stays pinned in place alongside the existing critique tagged-template coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned-helper tagged-template path with regressions for patterns like ``return (key) => String.raw`${params.getAll(key)[0]}` ``, so the verifier’s already-modeled tagged-string helper-closure behavior stays pinned in place alongside the earlier project-audit tagged-template coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through URI codec wrappers like `const readRedirect = (key) => decodeURIComponent(params.getAll(key)[0])` and `const readRedirect = (key) => encodeURI(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by normalizing the same raw redirect param through built-in URL encoding helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing returned-helper URI-decoding path with regressions for patterns like `return (key) => decodeURIComponent(params.getAll(key)[0])`, so the verifier’s already-modeled URI-normalized helper-closure behavior stays pinned in place alongside the existing critique URI-encoding coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned-helper URI-encoding path with regressions for patterns like `return (key) => encodeURI(params.getAll(key)[0])`, so the verifier’s already-modeled URI-normalized helper-closure behavior stays pinned in place alongside the earlier project-audit URI-decoding coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global string coercion like `const readRedirect = (key) => window.String(params.getAll(key)[0])` and `const readRedirect = (key) => globalThis.String(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through browser-global string coercion helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing returned-helper browser-global string coercion path with regressions for patterns like `return (key) => window.String(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global string helper behavior stays pinned in place alongside the existing critique browser-global coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing returned-helper browser-global string coercion path with regressions for patterns like `return (key) => globalThis.String(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global string helper behavior stays pinned in place alongside the earlier project-audit browser-global coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound and wrapper-based browser-global string coercion like `window.String.bind(window)` and `Reflect.apply(globalThis.String, globalThis, args)`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through generic binding or invocation wrappers around browser-global string coercion helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing bound browser-global string coercion path with regressions for patterns like `window.String.bind(window)`, so the verifier’s already-modeled string binding behavior stays pinned in place alongside the existing critique-bound and wrapper-based coverage plus the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing direct string coercion path with regressions for patterns like `String(params.getAll(key)[0])`, so the verifier’s already-modeled string coercion behavior stays pinned in place alongside the earlier browser-global, bound, wrapper-based, and project-audit coverage.
- Project-audit coverage now explicitly locks down the existing direct string coercion path with regressions for patterns like `String(params.getAll(key)[0])`, so the verifier’s already-modeled string coercion behavior stays pinned in place alongside the earlier browser-global, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global string coercion path with regressions for patterns like `globalThis.String.bind(globalThis)`, so the verifier’s already-modeled string binding behavior stays pinned in place alongside the earlier audit and wrapper coverage.
- Critique coverage now explicitly locks down the existing wrapper-based browser-global string coercion path with regressions for patterns like `Reflect.apply(globalThis.String, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled string wrapper behavior stays pinned in place alongside the earlier direct, bound, and project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapper-based browser-global string coercion path with regressions for patterns like `Reflect.apply(globalThis.String, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled string wrapper behavior stays pinned in place alongside the existing direct, bound, and critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through constructor-style string wrappers like `new String(params.getAll(key)[0])`, `new globalThis.String(params.getAll(key)[0])`, and destructured aliases like `const { String: StringCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by wrapping the same raw redirect param in boxed-string constructors before redirecting.
- Project-audit coverage now explicitly locks down the existing constructor-style browser-global `String` path with regressions for patterns like `new globalThis.String(params.getAll(key)[0])`, so the verifier’s already-modeled boxed-string constructor behavior stays pinned in place alongside the existing destructured alias coverage and the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing destructured constructor-style browser-global `String` path with regressions for patterns like `const { String: StringCtor } = globalThis`, so the verifier’s already-modeled boxed-string alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured constructor-style browser-global `String` path with regressions for patterns like `const { String: StringCtor } = globalThis`, so the verifier’s already-modeled boxed-string alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through object-boxing wrappers like `Object(params.getAll(key)[0])`, `new globalThis.Object(params.getAll(key)[0])`, and destructured aliases like `const { Object: ObjectCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through boxed-object coercion before redirecting.
- Critique coverage now explicitly locks down the existing direct browser-global object coercion path with regressions for patterns like `Object(params.getAll(key)[0])`, so the verifier’s already-modeled object coercion behavior stays pinned in place alongside the earlier destructured, bound, wrapper-based, and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing direct browser-global object coercion path with regressions for patterns like `Object(params.getAll(key)[0])`, so the verifier’s already-modeled object coercion behavior stays pinned in place alongside the existing destructured, bound, wrapper-based, and critique coverage.
- Project-audit coverage now explicitly locks down the existing constructor-style browser-global `Object` path with regressions for patterns like `new globalThis.Object(params.getAll(key)[0])`, so the verifier’s already-modeled boxed-object constructor behavior stays pinned in place alongside the existing direct and destructured alias coverage plus the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing destructured browser-global `Object` alias path with regressions for patterns like `const { Object: ObjectCtor } = globalThis`, so the verifier’s already-modeled boxed-object alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured browser-global `Object` alias path with regressions for patterns like `const { Object: ObjectCtor } = globalThis`, so the verifier’s already-modeled boxed-object alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound browser-global object coercion like `globalThis.Object.bind(globalThis)` and `ObjectCtor.bind(window)`, so auth flows cannot bypass redirect-param detection by hiding the same raw redirect param behind a pre-bound object coercion helper before redirecting.
- Project-audit coverage now explicitly locks down the existing bound browser-global object coercion path with regressions for patterns like `globalThis.Object.bind(globalThis)`, so the verifier’s already-modeled object binding behavior stays pinned in place alongside the existing direct, constructor-style, destructured, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global object coercion path with regressions for patterns like `globalThis.Object.bind(globalThis)`, so the verifier’s already-modeled object binding behavior stays pinned in place alongside the earlier project-audit coverage plus the other critique object-wrapper regressions.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when browser-global object coercion is routed through wrapper invocation helpers like `Object.call(globalThis, params.getAll(key)[0])`, `readRedirectValue.apply(globalThis, args)`, and `Reflect.apply(globalThis.Object, globalThis, [params.getAll(key)[0]])`, so auth flows cannot bypass redirect-param detection by hiding the same object coercion behind generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing `.call(...)` browser-global object wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the earlier bound, direct, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing `.apply(...)` browser-global object wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the earlier bound, direct, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected browser-global object coercion path with regressions for patterns like `Reflect.apply(globalThis.Object, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the existing bound, `.call(...)`, `.apply(...)`, and critique coverage.
- Critique coverage now explicitly locks down the existing `.call(...)` browser-global object wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the earlier audit and bound coverage plus the other critique wrapper regressions.
- Critique coverage now explicitly locks down the existing `.apply(...)` browser-global object wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the earlier audit, bound, `.call(...)`, and reflected critique coverage.
- Critique coverage now explicitly locks down the existing reflected browser-global object coercion path with regressions for patterns like `Reflect.apply(globalThis.Object, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled object wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global number-boxing wrappers like `Number(params.getAll(key)[0])`, `new globalThis.Number(params.getAll(key)[0])`, and destructured aliases like `const { Number: NumberCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through boxed-number coercion before redirecting.
- Critique coverage now explicitly locks down the existing direct browser-global number coercion path with regressions for patterns like `Number(params.getAll(key)[0])`, so the verifier’s already-modeled number coercion behavior stays pinned in place alongside the earlier destructured, bound, wrapper-based, and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing direct browser-global number coercion path with regressions for patterns like `Number(params.getAll(key)[0])`, so the verifier’s already-modeled number coercion behavior stays pinned in place alongside the existing destructured, bound, wrapper-based, and critique coverage.
- Project-audit coverage now explicitly locks down the existing constructor-style browser-global `Number` path with regressions for patterns like `new globalThis.Number(params.getAll(key)[0])`, so the verifier’s already-modeled boxed-number constructor behavior stays pinned in place alongside the existing direct and destructured alias coverage plus the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing destructured browser-global `Number` alias path with regressions for patterns like `const { Number: NumberCtor } = globalThis`, so the verifier’s already-modeled boxed-number alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured browser-global `Number` alias path with regressions for patterns like `const { Number: NumberCtor } = globalThis`, so the verifier’s already-modeled boxed-number alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound browser-global number coercion like `globalThis.Number.bind(globalThis)` and `NumberCtor.bind(window)`, so auth flows cannot bypass redirect-param detection by hiding the same raw redirect param behind a pre-bound number coercion helper before redirecting.
- Project-audit coverage now explicitly locks down the existing bound browser-global number coercion path with regressions for patterns like `globalThis.Number.bind(globalThis)`, so the verifier’s already-modeled number binding behavior stays pinned in place alongside the existing direct, destructured, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global number coercion path with regressions for patterns like `globalThis.Number.bind(globalThis)`, so the verifier’s already-modeled number binding behavior stays pinned in place alongside the earlier project-audit coverage plus the other critique number-wrapper regressions.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when browser-global number coercion is routed through wrapper invocation helpers like `Number.call(globalThis, params.getAll(key)[0])`, `readRedirectValue.apply(globalThis, args)`, and `Reflect.apply(globalThis.Number, globalThis, [params.getAll(key)[0]])`, so auth flows cannot bypass redirect-param detection by hiding the same number coercion behind generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing `.call(...)` browser-global number wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the earlier bound, direct, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing `.apply(...)` browser-global number wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the earlier bound, direct, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected browser-global number coercion path with regressions for patterns like `Reflect.apply(globalThis.Number, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing `.call(...)` browser-global number wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the earlier audit and bound coverage plus the other critique wrapper regressions.
- Critique coverage now explicitly locks down the existing `.apply(...)` browser-global number wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the earlier audit, bound, `.call(...)`, and reflected critique coverage.
- Critique coverage now explicitly locks down the existing reflected browser-global number coercion path with regressions for patterns like `Reflect.apply(globalThis.Number, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled number wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global boolean-boxing wrappers like `Boolean(params.getAll(key)[0])`, `new globalThis.Boolean(params.getAll(key)[0])`, and destructured aliases like `const { Boolean: BooleanCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through boxed-boolean coercion before redirecting.
- Critique coverage now explicitly locks down the existing direct browser-global boolean coercion path with regressions for patterns like `Boolean(params.getAll(key)[0])`, so the verifier’s already-modeled boolean coercion behavior stays pinned in place alongside the earlier destructured, bound, wrapper-based, and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing direct browser-global boolean coercion path with regressions for patterns like `Boolean(params.getAll(key)[0])`, so the verifier’s already-modeled boolean coercion behavior stays pinned in place alongside the existing destructured, bound, wrapper-based, and critique coverage.
- Project-audit coverage now explicitly locks down the existing constructor-style browser-global `Boolean` path with regressions for patterns like `new globalThis.Boolean(params.getAll(key)[0])`, so the verifier’s already-modeled boxed-boolean constructor behavior stays pinned in place alongside the existing direct and destructured alias coverage plus the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing destructured browser-global `Boolean` alias path with regressions for patterns like `const { Boolean: BooleanCtor } = globalThis`, so the verifier’s already-modeled boxed-boolean alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured browser-global `Boolean` alias path with regressions for patterns like `const { Boolean: BooleanCtor } = globalThis`, so the verifier’s already-modeled boxed-boolean alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound browser-global boolean coercion like `globalThis.Boolean.bind(globalThis)` and `BooleanCtor.bind(window)`, so auth flows cannot bypass redirect-param detection by hiding the same raw redirect param behind a pre-bound boolean coercion helper before redirecting.
- Project-audit coverage now explicitly locks down the existing bound browser-global boolean coercion path with regressions for patterns like `globalThis.Boolean.bind(globalThis)`, so the verifier’s already-modeled boolean binding behavior stays pinned in place alongside the existing direct, destructured, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global boolean coercion path with regressions for patterns like `globalThis.Boolean.bind(globalThis)`, so the verifier’s already-modeled boolean binding behavior stays pinned in place alongside the earlier audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when browser-global boolean coercion is routed through wrapper invocation helpers like `Boolean.call(globalThis, params.getAll(key)[0])`, `readRedirectValue.apply(globalThis, args)`, and `Reflect.apply(globalThis.Boolean, globalThis, [params.getAll(key)[0]])`, so auth flows cannot bypass redirect-param detection by hiding the same boolean coercion behind generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing `.call(...)` browser-global boolean wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing `.apply(...)` browser-global boolean wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected browser-global boolean coercion path with regressions for patterns like `Reflect.apply(globalThis.Boolean, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing `.call(...)` browser-global boolean wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the earlier audit and bound coverage plus the other critique wrapper regressions.
- Critique coverage now explicitly locks down the existing `.apply(...)` browser-global boolean wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the earlier audit, bound, `.call(...)`, and reflected critique coverage.
- Critique coverage now explicitly locks down the existing reflected browser-global boolean coercion path with regressions for patterns like `Reflect.apply(globalThis.Boolean, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled boolean wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global bigint coercion helpers like `BigInt(params.getAll(key)[0])`, `globalThis.BigInt.bind(globalThis)`, and destructured aliases like `const { BigInt: BigIntCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through bigint coercion before redirecting.
- Critique coverage now explicitly locks down the existing direct browser-global bigint coercion path with regressions for patterns like `BigInt(params.getAll(key)[0])`, so the verifier’s already-modeled bigint coercion behavior stays pinned in place alongside the earlier destructured, bound, wrapper-based, and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing direct browser-global bigint coercion path with regressions for patterns like `BigInt(params.getAll(key)[0])`, so the verifier’s already-modeled bigint coercion behavior stays pinned in place alongside the existing destructured, bound, wrapper-based, and critique coverage.
- Project-audit coverage now explicitly locks down the existing destructured browser-global `BigInt` alias path with regressions for patterns like `const { BigInt: BigIntCtor } = globalThis`, so the verifier’s already-modeled bigint alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured browser-global `BigInt` alias path with regressions for patterns like `const { BigInt: BigIntCtor } = globalThis`, so the verifier’s already-modeled bigint alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing bound browser-global bigint coercion path with regressions for patterns like `globalThis.BigInt.bind(globalThis)`, so the verifier’s already-modeled bigint binding behavior stays pinned in place alongside the existing direct, destructured, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global bigint coercion path with regressions for patterns like `globalThis.BigInt.bind(globalThis)`, so the verifier’s already-modeled bigint binding behavior stays pinned in place alongside the earlier audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when browser-global bigint coercion is routed through wrapper invocation helpers like `BigInt.call(globalThis, params.getAll(key)[0])`, `readRedirectValue.apply(globalThis, args)`, and `Reflect.apply(globalThis.BigInt, globalThis, [params.getAll(key)[0]])`, so auth flows cannot bypass redirect-param detection by hiding the same bigint coercion behind generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing `.call(...)` browser-global bigint wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing `.apply(...)` browser-global bigint wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, `.call(...)`, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected browser-global bigint coercion path with regressions for patterns like `Reflect.apply(globalThis.BigInt, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing `.call(...)` browser-global bigint wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the earlier audit and bound coverage plus the other critique wrapper regressions.
- Critique coverage now explicitly locks down the existing `.apply(...)` browser-global bigint wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the earlier audit, bound, `.call(...)`, and reflected critique coverage.
- Critique coverage now explicitly locks down the existing reflected browser-global bigint coercion path with regressions for patterns like `Reflect.apply(globalThis.BigInt, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled bigint wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global symbol coercion helpers like `Symbol(params.getAll(key)[0])`, `globalThis.Symbol.bind(globalThis)`, and destructured aliases like `const { Symbol: SymbolCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through symbol coercion before redirecting.
- Critique coverage now explicitly locks down the existing direct browser-global symbol coercion path with regressions for patterns like `Symbol(params.getAll(key)[0])`, so the verifier’s already-modeled symbol coercion behavior stays pinned in place alongside the earlier destructured, bound, wrapper-based, and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing direct browser-global symbol coercion path with regressions for patterns like `Symbol(params.getAll(key)[0])`, so the verifier’s already-modeled symbol coercion behavior stays pinned in place alongside the existing destructured, bound, wrapper-based, and critique coverage.
- Project-audit coverage now explicitly locks down the existing destructured browser-global `Symbol` alias path with regressions for patterns like `const { Symbol: SymbolCtor } = globalThis`, so the verifier’s already-modeled symbol alias behavior stays pinned in place alongside the existing direct, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured browser-global `Symbol` alias path with regressions for patterns like `const { Symbol: SymbolCtor } = globalThis`, so the verifier’s already-modeled symbol alias behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing bound browser-global symbol coercion path with regressions for patterns like `globalThis.Symbol.bind(globalThis)`, so the verifier’s already-modeled symbol binding behavior stays pinned in place alongside the existing direct, destructured, wrapper-based, reflected, and critique coverage.
- Critique coverage now explicitly locks down the existing bound browser-global symbol coercion path with regressions for patterns like `globalThis.Symbol.bind(globalThis)`, so the verifier’s already-modeled symbol binding behavior stays pinned in place alongside the earlier audit coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when browser-global symbol coercion is routed through wrapper invocation helpers like `Symbol.call(globalThis, params.getAll(key)[0])`, `readRedirectValue.apply(globalThis, args)`, and `Reflect.apply(globalThis.Symbol, globalThis, [params.getAll(key)[0]])`, so auth flows cannot bypass redirect-param detection by hiding the same symbol coercion behind generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based browser-global symbol coercion path with regressions for patterns like `Symbol.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing `.apply(...)` browser-global symbol wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected browser-global symbol coercion path with regressions for patterns like `Reflect.apply(globalThis.Symbol, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the existing direct, destructured, bound, wrapper-based, and critique coverage.
- Critique coverage now explicitly locks down the existing `.call(...)` browser-global symbol wrapper path with regressions for patterns like `readRedirectValue.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the earlier audit and bound coverage plus the other critique wrapper regressions.
- Critique coverage now explicitly locks down the existing `.apply(...)` browser-global symbol wrapper path with regressions for patterns like `readRedirectValue.apply(globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the earlier audit, bound, `.call(...)`, and reflected critique coverage.
- Critique coverage now explicitly locks down the existing reflected browser-global symbol coercion path with regressions for patterns like `Reflect.apply(globalThis.Symbol, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled symbol wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through direct, destructured, and bound `JSON.parse` helpers like `JSON.parse(params.getAll(key)[0])`, `const { parse } = JSON`, and `JSON.parse.bind(JSON)`, so auth flows cannot bypass redirect-param detection by reparsing the same raw redirect param through JSON helper wrappers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based `JSON.parse` helpers like `JSON.parse.call(JSON, params.getAll(key)[0])`, `parseRedirect.apply(JSON, args)`, and `Reflect.apply(parseRedirect, JSON, args)`, so auth flows cannot bypass redirect-param detection by routing the same reparsing helper through generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based `JSON.parse` helper path with regressions for patterns like `JSON.parse.call(JSON, params.getAll(key)[0])`, so the verifier’s already-modeled JSON reparse wrapper behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected `JSON.parse` wrapper path with regressions for patterns like `Reflect.apply(parseRedirect, JSON, parseArgs)`, so the verifier’s already-modeled JSON reparse wrapper behavior stays pinned in place alongside the existing bound, `.call(...)`, and critique coverage.
- Project-audit coverage now explicitly locks down the existing bound `JSON.parse` helper path with regressions for patterns like `JSON.parse.bind(JSON)`, so the verifier’s already-modeled JSON reparse binding behavior stays pinned in place alongside the existing reflected and destructured audit coverage plus the earlier critique helper regressions.
- Critique coverage now explicitly locks down the existing reflected `JSON.parse` wrapper path with regressions for patterns like `Reflect.apply(parseRedirect, JSON, parseArgs)`, so the verifier’s already-modeled JSON reparse wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Critique coverage now explicitly locks down the existing bound `JSON.parse` helper path with regressions for patterns like `JSON.parse.bind(JSON)`, so the verifier’s already-modeled JSON reparse binding behavior stays pinned in place alongside the existing audit and the earlier destructured and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing destructured `JSON.parse` helper path with regressions for patterns like `const { parse } = JSON`, so the verifier’s already-modeled JSON reparse alias behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured `JSON.parse` helper path with regressions for patterns like `const { parse } = JSON`, so the verifier’s already-modeled JSON reparse alias behavior stays pinned in place alongside the earlier audit, reflected, and bound critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through direct, destructured, and bound `JSON.stringify` helpers like `JSON.stringify(params.getAll(key)[0])`, `const { stringify } = JSON`, and `JSON.stringify.bind(JSON)`, so auth flows cannot bypass redirect-param detection by serializing the same raw redirect param through JSON helper wrappers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based `JSON.stringify` helpers like `JSON.stringify.call(JSON, params.getAll(key)[0])`, `stringifyRedirect.apply(JSON, args)`, and `Reflect.apply(stringifyRedirect, JSON, args)`, so auth flows cannot bypass redirect-param detection by routing the same serialization helper through generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based `JSON.stringify` helper path with regressions for patterns like `JSON.stringify.call(JSON, params.getAll(key)[0])`, so the verifier’s already-modeled JSON stringify wrapper behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected `JSON.stringify` wrapper path with regressions for patterns like `Reflect.apply(stringifyRedirect, JSON, stringifyArgs)`, so the verifier’s already-modeled JSON stringify wrapper behavior stays pinned in place alongside the existing bound, `.call(...)`, and critique coverage.
- Project-audit coverage now explicitly locks down the existing bound `JSON.stringify` helper path with regressions for patterns like `JSON.stringify.bind(JSON)`, so the verifier’s already-modeled JSON stringify binding behavior stays pinned in place alongside the existing reflected and destructured audit coverage plus the earlier critique helper regressions.
- Critique coverage now explicitly locks down the existing reflected `JSON.stringify` wrapper path with regressions for patterns like `Reflect.apply(stringifyRedirect, JSON, stringifyArgs)`, so the verifier’s already-modeled JSON stringify wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Critique coverage now explicitly locks down the existing bound `JSON.stringify` helper path with regressions for patterns like `JSON.stringify.bind(JSON)`, so the verifier’s already-modeled JSON stringify binding behavior stays pinned in place alongside the existing audit and the earlier destructured and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing destructured `JSON.stringify` helper path with regressions for patterns like `const { stringify } = JSON`, so the verifier’s already-modeled JSON stringify alias behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured `JSON.stringify` helper path with regressions for patterns like `const { stringify } = JSON`, so the verifier’s already-modeled JSON stringify alias behavior stays pinned in place alongside the earlier audit, reflected, and bound critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through direct, destructured, and bound `structuredClone` helpers like `structuredClone(params.getAll(key)[0])`, `const { structuredClone } = globalThis`, and `globalThis.structuredClone.bind(globalThis)`, so auth flows cannot bypass redirect-param detection by cloning the same raw redirect param before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based `structuredClone` helpers like `globalThis.structuredClone.call(globalThis, params.getAll(key)[0])`, `cloneRedirect.apply(globalThis, args)`, and `Reflect.apply(cloneRedirect, globalThis, args)`, so auth flows cannot bypass redirect-param detection by routing the same clone helper through generic invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based `structuredClone` helper path with regressions for patterns like `globalThis.structuredClone.call(globalThis, params.getAll(key)[0])`, so the verifier’s already-modeled clone wrapper behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Project-audit coverage now explicitly locks down the existing reflected `structuredClone` wrapper path with regressions for patterns like `Reflect.apply(cloneRedirect, globalThis, cloneArgs)`, so the verifier’s already-modeled clone wrapper behavior stays pinned in place alongside the existing bound, `.call(...)`, and critique coverage.
- Project-audit coverage now explicitly locks down the existing bound `structuredClone` helper path with regressions for patterns like `globalThis.structuredClone.bind(globalThis)`, so the verifier’s already-modeled clone binding behavior stays pinned in place alongside the existing reflected and destructured audit coverage plus the earlier critique helper regressions.
- Critique coverage now explicitly locks down the existing reflected `structuredClone` wrapper path with regressions for patterns like `Reflect.apply(cloneRedirect, globalThis, cloneArgs)`, so the verifier’s already-modeled clone wrapper behavior stays pinned in place alongside the earlier audit, bound, and `.call(...)` critique coverage.
- Critique coverage now explicitly locks down the existing bound `structuredClone` helper path with regressions for patterns like `globalThis.structuredClone.bind(globalThis)`, so the verifier’s already-modeled clone binding behavior stays pinned in place alongside the existing audit and the earlier destructured and reflected critique coverage.
- Project-audit coverage now explicitly locks down the existing destructured `structuredClone` helper path with regressions for patterns like `const { structuredClone: cloneRedirect } = globalThis`, so the verifier’s already-modeled clone alias behavior stays pinned in place alongside the existing bound, reflected, and critique coverage.
- Critique coverage now explicitly locks down the existing destructured `structuredClone` helper path with regressions for patterns like `const { structuredClone: cloneRedirect } = globalThis`, so the verifier’s already-modeled clone alias behavior stays pinned in place alongside the earlier audit, reflected, and bound critique coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through base64 helpers like `const readRedirect = (key) => atob(params.getAll(key)[0])` and `const readRedirect = (key) => btoa(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by normalizing the same raw redirect param through base64 helper wrappers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through `Buffer.from(...).toString(...)` wrappers like `const readRedirect = (key) => Buffer.from(params.getAll(key)[0], 'base64').toString('utf8')` and `const readRedirect = (key) => Buffer.from(params.getAll(key)[0], 'utf8').toString('base64')`, so auth flows cannot bypass redirect-param detection by normalizing the same raw redirect param through common Node-side base64 wrappers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint when `Buffer.from` is hoisted or destructured first, like `const decodeRedirect = Buffer.from` and `const { from } = Buffer`, so auth flows cannot bypass redirect-param detection by renaming the same Node-side base64 wrapper before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through global-object Buffer access like `const readRedirect = (key) => globalThis.Buffer.from(params.getAll(key)[0], 'base64').toString('utf8')` and `const { Buffer: BufferCtor } = globalThis`, so auth flows cannot bypass redirect-param detection by routing the same Node-side base64 wrapper through global-object member access before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based Buffer invocations like `Buffer.from.call(Buffer, params.getAll(key)[0], 'base64')`, `decodeRedirect.apply(Buffer, args)`, and `Reflect.apply(decodeRedirect, Buffer, args)`, so auth flows cannot bypass redirect-param detection by wrapping the same Node-side base64 helper in generic invocation helpers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound Buffer helpers like `const decodeRedirect = Buffer.from.bind(Buffer)` and `const decodeRedirect = globalThis.Buffer.from.bind(globalThis.Buffer)`, so auth flows cannot bypass redirect-param detection by pre-binding the same Node-side base64 helper before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based `Buffer.from` helper path with regressions for patterns like `Buffer.from.call(Buffer, params.getAll(key)[0], 'base64')`, so the verifier’s already-modeled Node-side base64 wrapper behavior stays pinned in place alongside the existing bound and critique helper coverage.
- Project-audit coverage now explicitly locks down the existing bound `Buffer.from` helper path with regressions for patterns like `Buffer.from.bind(Buffer)`, so the verifier’s already-modeled Node-side base64 binding behavior stays pinned in place alongside the existing critique-side global-object binding coverage and the earlier Buffer helper regressions.
- Critique coverage now explicitly locks down the existing bound global-object `Buffer.from` helper path with regressions for patterns like `globalThis.Buffer.from.bind(globalThis.Buffer)`, so the verifier’s already-modeled Buffer binding behavior stays pinned in place alongside the earlier project-audit Buffer helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global base64 helpers like `const readRedirect = (key) => window.atob(params.getAll(key)[0])` and `const readRedirect = (key) => globalThis.btoa(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through browser-global base64 helper wrappers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound browser-global base64 helpers like `const decodeRedirect = window.atob.bind(window)` and `const encodeRedirect = globalThis.btoa.bind(globalThis)`, so auth flows cannot bypass redirect-param detection by pre-binding the same browser-global base64 helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing bound browser-global base64 helper path with regressions for patterns like `window.atob.bind(window)`, so the verifier’s already-modeled browser-global base64 binding behavior stays pinned in place alongside the existing critique helper coverage and the earlier direct and wrapper-path regressions.
- Project-audit coverage now explicitly locks down the existing direct browser-global base64 helper path with regressions for patterns like `window.atob(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global base64 helper behavior stays pinned in place alongside the existing bound and wrapper-path coverage.
- Critique coverage now explicitly locks down the existing direct browser-global base64 helper path with regressions for patterns like `globalThis.btoa(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global base64 helper behavior stays pinned in place alongside the earlier project-audit, bound, and wrapper-path coverage.
- Critique coverage now explicitly locks down the existing bound browser-global base64 helper path with regressions for patterns like `window.atob.bind(window)` and `globalThis.btoa.bind(globalThis)`, so the verifier’s already-modeled browser-global base64 binding behavior stays pinned in place alongside the earlier project-audit helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based browser-global base64 invocations like `window.atob.call(window, params.getAll(key)[0])`, `encodeRedirect.apply(globalThis, args)`, and `Reflect.apply(globalThis.btoa, globalThis, args)`, so auth flows cannot bypass redirect-param detection by wrapping the same browser-global base64 helpers in generic invocation helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based browser-global base64 helper path with regressions for patterns like `window.atob.call(window, params.getAll(key)[0])`, so the verifier’s already-modeled browser-global base64 wrapper behavior stays pinned in place alongside the existing bound helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapper-based browser-global base64 helper path with regressions for patterns like `Reflect.apply(globalThis.btoa, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled browser-global base64 wrapper behavior stays pinned in place alongside the earlier project-audit and bound helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through browser-global URI codec member access like `const readRedirect = (key) => window.decodeURIComponent(params.getAll(key)[0])` and `const readRedirect = (key) => globalThis.encodeURI(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by routing the same raw redirect param through member-access forms of the same built-in URL encoding helpers before redirecting.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound browser-global URI codec helpers like `const decodeRedirect = window.decodeURIComponent.bind(window)` and `const encodeRedirect = globalThis.encodeURI.bind(globalThis)`, so auth flows cannot bypass redirect-param detection by pre-binding the same browser-global URL encoding helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing direct browser-global URI codec helper path with regressions for patterns like `window.decodeURIComponent(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global URI helper behavior stays pinned in place alongside the existing bound and wrapper-path coverage.
- Project-audit coverage now explicitly locks down the existing bound browser-global URI codec helper path with regressions for patterns like `window.decodeURIComponent.bind(window)`, so the verifier’s already-modeled browser-global URI binding behavior stays pinned in place alongside the existing critique helper coverage and the earlier direct and wrapper-path regressions.
- Critique coverage now explicitly locks down the existing direct browser-global URI codec helper path with regressions for patterns like `globalThis.encodeURI(params.getAll(key)[0])`, so the verifier’s already-modeled browser-global URI helper behavior stays pinned in place alongside the earlier project-audit helper coverage.
- Critique coverage now explicitly locks down the existing bound browser-global URI codec helper path with regressions for patterns like `window.decodeURIComponent.bind(window)` and `globalThis.encodeURI.bind(globalThis)`, so the verifier’s already-modeled browser-global URI binding behavior stays pinned in place alongside the earlier project-audit helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through wrapper-based browser-global URI codec invocations like `window.decodeURIComponent.call(window, params.getAll(key)[0])`, `encodeRedirect.apply(globalThis, args)`, and `Reflect.apply(globalThis.encodeURI, globalThis, args)`, so auth flows cannot bypass redirect-param detection by wrapping the same browser-global URL encoding helpers in generic invocation helpers before redirecting.
- Project-audit coverage now explicitly locks down the existing wrapper-based browser-global URI codec helper path with regressions for patterns like `window.decodeURIComponent.call(window, params.getAll(key)[0])`, so the verifier’s already-modeled browser-global URI wrapper behavior stays pinned in place alongside the existing bound helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapper-based browser-global URI codec helper path with regressions for patterns like `Reflect.apply(globalThis.encodeURI, globalThis, [params.getAll(key)[0]])`, so the verifier’s already-modeled browser-global URI wrapper behavior stays pinned in place alongside the earlier project-audit and bound helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through legacy URI helpers like `const readRedirect = (key) => unescape(params.getAll(key)[0])` and `const readRedirect = (key) => window.escape(params.getAll(key)[0])`, so auth flows cannot bypass redirect-param detection by normalizing the same raw redirect param through legacy browser URI helper variants before redirecting.
- Project-audit coverage now explicitly locks down the existing direct legacy URI helper path with regressions for patterns like `unescape(params.getAll(key)[0])`, so the verifier’s already-modeled legacy browser URI normalization behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing direct legacy URI helper path with regressions for patterns like `unescape(params.getAll(key)[0])` and `window.escape(params.getAll(key)[0])`, so the verifier’s already-modeled legacy browser URI normalization behavior stays pinned in place alongside the earlier project-audit helper coverage.
- Auth open-redirect tracing now also preserves returned query-reader closure taint through bound and wrapper-based legacy URI helper variants like `window.unescape.bind(window)` and `Reflect.apply(globalThis.escape, globalThis, args)`, so auth flows cannot bypass redirect-param detection by routing the same legacy browser URI helpers through generic binding or invocation wrappers before redirecting.
- Project-audit coverage now explicitly locks down the existing bound legacy URI helper path with regressions for patterns like `window.unescape.bind(window)`, so the verifier’s already-modeled legacy browser URI helper binding behavior stays pinned in place alongside the existing critique helper coverage and the earlier direct-helper regressions.
- Critique coverage now explicitly locks down the existing bound and wrapper-based legacy URI helper path with regressions for patterns like `window.unescape.bind(window)` and `Reflect.apply(globalThis.escape, globalThis, args)`, so the verifier’s already-modeled legacy browser URI helper-wrapper behavior stays pinned in place alongside the earlier project-audit helper coverage.
- Auth open-redirect tracing now also preserves repeated-param helper normalization inside returned closures, including shapes like `const readRedirect = (key) => params.getAll(key)[0]`, `const readRedirect = (key) => params.getAll(key)[0].trim()`, `const readRedirect = (key) => params.getAll(key)[0].trimStart()`, `const readRedirect = (key) => params.getAll(key)[0].trimLeft()`, `const readRedirect = (key) => params.getAll(key)[0].trimEnd()`, `const readRedirect = (key) => params.getAll(key)[0].trimRight()`, `const readRedirect = (key) => params.getAll(key)[0].padStart(12, '/')`, `const readRedirect = (key) => params.getAll(key)[0].padEnd(12, '/')`, `const readRedirect = (key) => params.getAll(key)[0].repeat(1)`, `const readRedirect = (key) => params.getAll(key)[0].replace(/^\\/+/, '/')`, `const readRedirect = (key) => params.getAll(key)[0].replaceAll('//', '/')`, `const readRedirect = (key) => params.getAll(key)[0].slice(0)`, `const readRedirect = (key) => params.getAll(key)[0].split('?').join('?')`, `const readRedirect = (key) => params.getAll(key)[0].split('?')[0]`, `const readRedirect = (key) => params.getAll(key)[0].match(/^[^?]+/)?.[0]`, `const readRedirect = (key) => params.getAll(key)[0].matchAll(/^[^?]+/g).next().value?.[0]`, `const readRedirect = (key) => /^[^?]+/.exec(params.getAll(key)[0])?.[0]`, `const readRedirect = (key) => params.getAll(key)[0].substr(0)`, `const readRedirect = (key) => params.getAll(key)[0].substring(0)`, `const readRedirect = (key) => params.getAll(key)[0].toLowerCase()`, `const readRedirect = (key) => params.getAll(key)[0].toUpperCase()`, `const readRedirect = (key) => params.getAll(key)[0].toLocaleLowerCase()`, `const readRedirect = (key) => params.getAll(key)[0].toLocaleUpperCase()`, `const readRedirect = (key) => params.getAll(key)[0].toLocaleString()`, `const readRedirect = (key) => params.getAll(key)[0].toString()`, `const readRedirect = (key) => params.getAll(key)[0].toWellFormed()`, `const readRedirect = (key) => String(params.getAll(key)[0])`, `const readRedirect = (key) => params.getAll(key)[0].valueOf()`, `const readRedirect = (key) => params.getAll(key)[0].normalize()`, `const readRedirect = (key) => params.getAll(key).at(0)`, `const readRedirect = (key) => params.getAll(key).shift()`, `const readRedirect = (key) => params.getAll(key).pop()`, `const readRedirect = (key) => params.getAll(key).find(Boolean)`, `const readRedirect = (key) => params.getAll(key).findLast(Boolean)`, `const readRedirect = (key) => params.getAll(key).slice(-1)[0]`, `const readRedirect = (key) => params.getAll(key).reverse()[0]`, `const readRedirect = (key) => params.getAll(key).toReversed()[0]`, `const readRedirect = (key) => params.getAll(key).sort()[0]`, `const readRedirect = (key) => params.getAll(key).toSorted()[0]`, `const readRedirect = (key) => Array.from(params.getAll(key))[0]`, `const readRedirect = (key) => [...params.getAll(key)][0]`, `const readRedirect = (key) => params.getAll(key).concat()[0]`, `const readRedirect = (key) => params.getAll(key).flat()[0]`, `const readRedirect = (key) => params.getAll(key).map((value) => value)[0]`, `const readRedirect = (key) => params.getAll(key).flatMap((value) => [value])[0]`, `const readRedirect = (key) => params.getAll(key).splice(0, 1)[0]`, `const readRedirect = (key) => params.getAll(key).toSpliced(0, 1)[0]`, `const readRedirect = (key) => params.getAll(key).values().next().value`, `const readRedirect = (key) => params.getAll(key).entries().next().value[1]`, `const readRedirect = (key) => params.getAll(key).reduce((_, value) => value)`, `const readRedirect = (key) => params.getAll(key).reduceRight((_, value) => value)`, `const readRedirect = (key) => params.getAll(key).filter(Boolean)[0]`, and wrapped invocations like `readRedirect.call(null, 'next')`, so auth flows cannot sidestep redirect-param detection by normalizing repeated `next` values before redirecting.
- Project-audit coverage now explicitly locks down the existing iterator-based repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key).values().next().value; }`, so the verifier’s already-modeled repeated-param iterator behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing iterator-based repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key).values().next().value; }`, so the verifier’s already-modeled repeated-param iterator behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing entry-iterated repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key).entries().next().value[1]; }`, so the verifier’s already-modeled repeated-param entry-iterator behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing entry-iterated repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key).entries().next().value[1]; }`, so the verifier’s already-modeled repeated-param entry-iterator behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing trimmed repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].trim(); }`, so the verifier’s already-modeled repeated-param trimming behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing trimmed repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].trim(); }`, so the verifier’s already-modeled repeated-param trimming behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped trimmed repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].trim(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param trim-wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped trimmed repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].trim(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param trim-wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing replaced repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replace(/^\\/+/, '/'); }`, so the verifier’s already-modeled repeated-param slash-normalization behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing replaced repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replace(/^\\/+/, '/'); }`, so the verifier’s already-modeled repeated-param slash-normalization behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped replaced repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replace(/^\\/+/, '/'); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param slash-normalization wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped replaced repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replace(/^\\/+/, '/'); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param slash-normalization wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing replace-all repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replaceAll('//', '/'); }`, so the verifier’s already-modeled repeated-param slash-collapse behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing replace-all repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replaceAll('//', '/'); }`, so the verifier’s already-modeled repeated-param slash-collapse behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped replace-all repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replaceAll('//', '/'); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param slash-collapse wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped replace-all repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].replaceAll('//', '/'); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param slash-collapse wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing substring repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substring(0); }`, so the verifier’s already-modeled repeated-param substring pass-through behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing substring repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substring(0); }`, so the verifier’s already-modeled repeated-param substring pass-through behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped substring repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substring(0); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param substring wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped substring repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substring(0); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param substring wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing `substr(0)` repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substr(0); }`, so the verifier’s already-modeled repeated-param legacy-substring pass-through behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `substr(0)` repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substr(0); }`, so the verifier’s already-modeled repeated-param legacy-substring pass-through behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped `substr(0)` repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substr(0); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param legacy-substring wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped `substr(0)` repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].substr(0); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param legacy-substring wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLowerCase(); }`, so the verifier’s already-modeled repeated-param lowercase normalization behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLowerCase(); }`, so the verifier’s already-modeled repeated-param lowercase normalization behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLowerCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param lowercase wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLowerCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param lowercase wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toUpperCase(); }`, so the verifier’s already-modeled repeated-param uppercase normalization behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toUpperCase(); }`, so the verifier’s already-modeled repeated-param uppercase normalization behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toUpperCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param uppercase wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toUpperCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param uppercase wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing locale-lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleLowerCase(); }`, so the verifier’s already-modeled repeated-param locale-aware lowercase normalization behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing locale-lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleLowerCase(); }`, so the verifier’s already-modeled repeated-param locale-aware lowercase normalization behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped locale-lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleLowerCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param locale-aware lowercase wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped locale-lowercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleLowerCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param locale-aware lowercase wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing locale-uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleUpperCase(); }`, so the verifier’s already-modeled repeated-param locale-aware uppercase normalization behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing locale-uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleUpperCase(); }`, so the verifier’s already-modeled repeated-param locale-aware uppercase normalization behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing wrapped locale-uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleUpperCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param locale-aware uppercase wrapper behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing wrapped locale-uppercased repeated-query returned-helper path with regressions for patterns like `function createReadRedirect(params) { return (key) => params.getAll(key)[0].toLocaleUpperCase(); }` plus `readRedirect.call(null, 'next')`, so the verifier’s already-modeled repeated-param locale-aware uppercase wrapper behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows normalized query carriers like `new URLSearchParams(window.location.search.slice(1))` and `new URLSearchParams(req.nextUrl.search.slice(1))`, so auth flows cannot bypass redirect-param detection just by stripping the leading `?` off a reviewed location/request query string before reading `next`.
- Project-audit coverage now explicitly locks down the existing normalized query-carrier path with regressions for patterns like `new URLSearchParams(window.location.search.slice(1))` and `new URLSearchParams(req.nextUrl.search.slice(1))`, so the verifier’s already-modeled stripped-query carrier behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing normalized query-carrier path with regressions for patterns like `new URLSearchParams(window.location.search.slice(1))` and `new URLSearchParams(req.nextUrl.search.slice(1))`, so the verifier’s already-modeled stripped-query carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also treats `open(...)` and `window.open(...)` as imperative navigation sinks, so auth flows cannot bypass redirect-param detection by forwarding raw `next` or `returnTo` values through browser popup or tab navigation instead of `redirect(...)`, router transitions, or direct location assignment.
- Project-audit coverage now explicitly locks down the existing direct browser-open sink path with regressions for patterns like `window.open(searchParams.get('next') ?? '/dashboard', '_self')`, so the verifier’s already-modeled imperative popup/tab navigation sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing direct browser-open sink path with regressions for patterns like `window.open(searchParams.get('next') ?? '/dashboard', '_self')`, so the verifier’s already-modeled imperative popup/tab navigation sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased and destructured `window.open` sinks like `const popup = window.open` and `const { open: popup } = window`, so auth flows cannot bypass redirect-param detection just by hoisting browser-open navigation into a local helper before forwarding the same untrusted destination.
- Project-audit coverage now explicitly locks down the existing aliased and destructured browser-open sink path with regressions for patterns like `const popup = window.open` and `const { open: popup } = window`, so the verifier’s already-modeled hoisted browser-open sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased and destructured browser-open sink path with regressions for patterns like `const popup = window.open` and `const { open: popup } = window`, so the verifier’s already-modeled hoisted browser-open sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased and destructured location-mutation sinks like `const navigate = window.location.assign` and `const { replace: navigate } = window.location`, so auth flows cannot bypass redirect-param detection just by hoisting browser location navigation methods into local helpers before forwarding the same raw `next` value.
- Project-audit coverage now explicitly locks down the existing aliased and destructured location-mutation sink path with regressions for patterns like `const navigate = window.location.assign` and `const { replace: navigate } = window.location`, so the verifier’s already-modeled hoisted browser-location sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased and destructured location-mutation sink path with regressions for patterns like `const navigate = window.location.assign` and `const { replace: navigate } = window.location`, so the verifier’s already-modeled hoisted browser-location sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows bound location-mutation sinks like `window.location.assign.bind(window.location)` and `replace.bind(window.location)`, so auth flows cannot bypass redirect-param detection just by binding browser location navigation methods before forwarding the same raw `next` value.
- Project-audit coverage now explicitly locks down the existing bound location-mutation sink path with regressions for patterns like `window.location.assign.bind(window.location)` and `replace.bind(window.location)`, so the verifier’s already-modeled bound browser-location sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing bound location-mutation sink path with regressions for patterns like `window.location.assign.bind(window.location)` and `replace.bind(window.location)`, so the verifier’s already-modeled bound browser-location sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased and bound router transition sinks like `const { push } = useRouter()` and `router.replace.bind(router)`, so auth flows cannot bypass redirect-param detection just by hoisting or binding client router navigation methods before forwarding the same raw `next` value.
- Project-audit coverage now explicitly locks down the existing aliased and bound router transition sink path with regressions for patterns like `const { push } = useRouter()` and `router.replace.bind(router)`, so the verifier’s already-modeled hoisted and bound client-router sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased and bound router transition sink path with regressions for patterns like `const { push } = useRouter()` and `router.replace.bind(router)`, so the verifier’s already-modeled hoisted and bound client-router sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows router transition method wrappers like `router.push.call(router, next)` and `navigate.apply(router, [next])`, so auth flows cannot bypass redirect-param detection just by forwarding the same raw destination through `call(...)` or `apply(...)` around client router navigation.
- Project-audit coverage now explicitly locks down the existing router method-wrapper path with regressions for patterns like `router.push.call(router, searchParams.get('next') ?? '/dashboard')` and `navigate.apply(router, [searchParams.get('next') ?? '/dashboard'])`, so the verifier’s already-modeled wrapped client-router sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing router method-wrapper path with regressions for patterns like `router.push.call(router, searchParams.get('next') ?? '/dashboard')` and `navigate.apply(router, [searchParams.get('next') ?? '/dashboard'])`, so the verifier’s already-modeled wrapped client-router sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows `call(...)` and `apply(...)` wrappers around browser/history sinks like `history.replaceState.call(history, {}, '', next)`, `window.location.assign.call(window.location, next)`, and `window.open.apply(window, [next, '_self'])`, so auth flows cannot bypass redirect-param detection just by forwarding the same raw destination through method wrappers on non-router navigation APIs.
- Project-audit coverage now explicitly locks down the existing browser/history wrapper-call path with regressions for patterns like `history.replaceState.call(history, {}, '', searchParams.get('next') ?? '/dashboard')`, `window.location.assign.call(window.location, searchParams.get('next') ?? '/dashboard')`, and `window.open.apply(window, [searchParams.get('next') ?? '/dashboard', '_self'])`, so the verifier’s already-modeled non-router wrapper sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing browser/history wrapper-call path with regressions for patterns like `history.replaceState.call(history, {}, '', searchParams.get('next') ?? '/dashboard')`, `window.location.assign.call(window.location, searchParams.get('next') ?? '/dashboard')`, and `window.open.apply(window, [searchParams.get('next') ?? '/dashboard', '_self'])`, so the verifier’s already-modeled non-router wrapper sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased `.apply(...)` argument arrays like `const args = [next]; navigate.apply(router, args)` and `const args = [{}, '', next]; history.replaceState.apply(history, args)`, so auth flows cannot bypass redirect-param detection just by hoisting the wrapped argument list into a local helper before calling the same router, history, location, or `window.open` sink.
- Project-audit coverage now explicitly locks down the existing aliased `.apply(...)` argument-array path with regressions for patterns like `const args = [searchParams.get('next') ?? '/dashboard']; navigate.apply(router, args)`, `const args = [{}, '', searchParams.get('next') ?? '/dashboard']; updateHistory.apply(history, args)`, and `const args = [searchParams.get('next') ?? '/dashboard', '_self']; popup.apply(window, args)`, so the verifier’s already-modeled hoisted wrapper-argument sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased `.apply(...)` argument-array path with regressions for patterns like `const args = [searchParams.get('next') ?? '/dashboard']; navigate.apply(router, args)`, `const args = [{}, '', searchParams.get('next') ?? '/dashboard']; updateHistory.apply(history, args)`, and `const args = [searchParams.get('next') ?? '/dashboard', '_self']; popup.apply(window, args)`, so the verifier’s already-modeled hoisted wrapper-argument sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows reflected wrapper calls like `Reflect.apply(router.replace, router, [next])`, `Reflect.apply(history.replaceState, history, [{}, '', next])`, `Reflect.apply(window.location.assign, window.location, [next])`, and `Reflect.apply(window.open, window, [next, '_self'])`, including aliased argument arrays like `const args = [next]; Reflect.apply(router.replace, router, args)`, so auth flows cannot bypass redirect-param detection just by routing the same raw destination through `Reflect.apply(...)` instead of method-style `.apply(...)`.
- Project-audit coverage now explicitly locks down the existing reflected wrapper-call path with regressions for patterns like `const args = [searchParams.get('next') ?? '/dashboard']; Reflect.apply(router.replace, router, args)`, `Reflect.apply(window.location.assign, window.location, [searchParams.get('next') ?? '/dashboard'])`, and `Reflect.apply(window.open, window, [searchParams.get('next') ?? '/dashboard', '_self'])`, so the verifier’s already-modeled reflected navigation-sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing reflected wrapper-call path with regressions for patterns like `const args = [searchParams.get('next') ?? '/dashboard']; Reflect.apply(router.replace, router, args)`, `Reflect.apply(window.location.assign, window.location, [searchParams.get('next') ?? '/dashboard'])`, and `Reflect.apply(window.open, window, [searchParams.get('next') ?? '/dashboard', '_self'])`, so the verifier’s already-modeled reflected navigation-sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing aliased `window.history` object sink path with regressions for patterns like `const browserHistory = window.history; browserHistory.replaceState({}, '', searchParams.get('next') ?? '/dashboard')`, so the verifier’s already-modeled hoisted history-object sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased `window.history` object sink path with regressions for patterns like `const browserHistory = window.history; browserHistory.replaceState({}, '', searchParams.get('next') ?? '/dashboard')`, so the verifier’s already-modeled hoisted history-object sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows aliased and destructured History API sinks like `const updateHistory = history.replaceState` and `const { pushState: updateHistory } = window.history`, so auth flows cannot bypass redirect-param detection just by hoisting history mutation methods into local helpers before forwarding the same raw destination into the browser URL bar.
- Project-audit coverage now explicitly locks down the existing aliased and destructured History API sink path with regressions for patterns like `const updateHistory = history.replaceState` and `const { pushState: updateHistory } = window.history`, so the verifier’s already-modeled hoisted browser-history sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing aliased and destructured History API sink path with regressions for patterns like `const updateHistory = history.replaceState` and `const { pushState: updateHistory } = window.history`, so the verifier’s already-modeled hoisted browser-history sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Auth open-redirect tracing now also follows bound History API sinks like `history.replaceState.bind(history)` and `pushState.bind(window.history)`, so auth flows cannot bypass redirect-param detection just by binding a browser history mutation method before forwarding the same untrusted destination into the URL bar.
- Project-audit coverage now explicitly locks down the existing bound History API sink path with regressions for patterns like `history.replaceState.bind(history)` and `pushState.bind(window.history)`, so the verifier’s already-modeled bound browser-history sink behavior stays pinned in place alongside the existing critique helper coverage and the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing bound History API sink path with regressions for patterns like `history.replaceState.bind(history)` and `pushState.bind(window.history)`, so the verifier’s already-modeled bound browser-history sink behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing `useSearchParams()` hook carrier path with regressions for patterns like `const params = useSearchParams()` and `const [params] = useSearchParams()`, so the verifier’s already-modeled hook-backed query-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `useSearchParams()` hook carrier path with regressions for patterns like `const params = useSearchParams()` and `const [params] = useSearchParams()`, so the verifier’s already-modeled hook-backed query-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing `useLocation()` hook carrier path with regressions for patterns like `const routeLocation = useLocation()` and `const { search } = useLocation()`, so the verifier’s already-modeled hook-backed location-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `useLocation()` hook carrier path with regressions for patterns like `const routeLocation = useLocation()` and `const { search } = useLocation()`, so the verifier’s already-modeled hook-backed location-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing `useRouter()` hook query-container path with regressions for patterns like `const appRouter = useRouter()` and `const { query: params } = useRouter()`, so the verifier’s already-modeled hook-backed router-query behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing `useRouter()` hook query-container path with regressions for patterns like `const appRouter = useRouter()` and `const { query: params } = useRouter()`, so the verifier’s already-modeled hook-backed router-query behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing template-wrapped query-alias path with regressions for patterns like `const next = router.query.next; return redirect(\`${next ?? '/dashboard'}\`)`, so the verifier’s already-modeled template-coerced redirect-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing template-wrapped query-alias path with regressions for patterns like `const next = router.query.next; return redirect(\`${next ?? '/dashboard'}\`)`, so the verifier’s already-modeled template-coerced redirect-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing template-wrapped `searchParams` prop path in JSX with regressions for patterns like `export function LoginRedirect({ searchParams: { next } }) { return <Link to={\`${next ?? '/dashboard'}\`}>Continue</Link>; }`, so the verifier’s already-modeled template-coerced JSX navigation-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing template-wrapped `searchParams` prop path in JSX with regressions for patterns like `export function LoginRedirect({ searchParams: { next } }) { return <Link to={\`${next ?? '/dashboard'}\`}>Continue</Link>; }`, so the verifier’s already-modeled template-coerced JSX navigation-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing snake-case search-param-key path with regressions for patterns like `return redirect(searchParams.get('return_to') ?? '/dashboard')`, so the verifier’s already-modeled alias-style auth redirect-key handling stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing snake-case search-param-key path with regressions for patterns like `return redirect(searchParams.get('return_to') ?? '/dashboard')`, so the verifier’s already-modeled alias-style auth redirect-key handling stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing snake-case query-alias path with regressions for patterns like `const queryKey = 'redirect_to'; return <Link to={{ pathname: router.query[queryKey] ?? '/dashboard' }}>Continue</Link>;`, so the verifier’s already-modeled alias-style router-query redirect handling stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing snake-case query-alias path with regressions for patterns like `const queryKey = 'redirect_to'; return <Link to={{ pathname: router.query[queryKey] ?? '/dashboard' }}>Continue</Link>;`, so the verifier’s already-modeled alias-style router-query redirect handling stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing snake-case callback URL param path with regressions for patterns like `const queryKey = 'callback_url'; const next = new URLSearchParams(window.location.search).get(queryKey); return redirect(next ?? '/dashboard');`, so the verifier’s already-modeled alias-style browser-query redirect handling stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing snake-case callback URL param path with regressions for patterns like `const queryKey = 'callback_url'; const next = new URLSearchParams(window.location.search).get(queryKey); return redirect(next ?? '/dashboard');`, so the verifier’s already-modeled alias-style browser-query redirect handling stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing direct external auth-redirect path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/continue');`, so the verifier’s already-modeled post-auth external redirect handling stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing direct external auth-redirect path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/continue');`, so the verifier’s already-modeled post-auth external redirect handling stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing provider authorize URL without `state` path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code');`, so the verifier’s already-modeled OAuth state enforcement stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing provider authorize URL without `state` path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code');`, so the verifier’s already-modeled OAuth state enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing provider code-flow URL without PKCE path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code&state=opaque123');`, so the verifier’s already-modeled OAuth PKCE enforcement stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing provider code-flow URL without PKCE path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code&state=opaque123');`, so the verifier’s already-modeled OAuth PKCE enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing provider `id_token` URL without `nonce` path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=id_token&state=opaque123');`, so the verifier’s already-modeled OpenID nonce enforcement stays pinned in place alongside the earlier auth tracing work.
- Critique coverage now explicitly locks down the existing provider `id_token` URL without `nonce` path with regressions for patterns like `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=id_token&state=opaque123');`, so the verifier’s already-modeled OpenID nonce enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth callback flows that never scrub URL codes path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback URL scrubbing enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback URL scrub gap where `AuthCallback` reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in…</p>;` without scrubbing callback params out of browser history, so the already-modeled `source-auth-callback-url-scrub-missing` regression stays pinned in place when reviewed callback flows leave provider-return data sitting in the URL bar.
- Project-audit coverage now explicitly locks down the existing callback URL scrub gap where `AuthCallback` branches on `searchParams.get('error')`, returns `<a href="/login">Back to sign in</a>;`, and still leaves the provider error params sitting in browser history without any `history.replaceState` or equivalent scrub step, so the already-modeled `source-auth-callback-url-scrub-missing` regression stays pinned in place when reviewed callback failure paths leave provider-return data sitting in the URL bar.
- Critique coverage now explicitly locks down the existing auth callback flows that never scrub URL codes path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback URL scrubbing enforcement stays pinned in place alongside the earlier project-audit coverage.
- Project-audit coverage now explicitly locks down the existing auth callback flows that never handle provider error returns path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback error-handling enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback error-handling gap where `AuthCallback` reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still never branches on provider `error` returns, so the already-modeled `source-auth-callback-error-missing` regression stays pinned in place when reviewed callback flows assume the happy path even when providers can deny or fail the exchange.
- Critique coverage now explicitly locks down the existing auth callback flows that never handle provider error returns path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback error-handling enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback error-handling gap where reviewed `AuthCallback` code reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in...</p>;` without ever branching on provider `error` params, so the already-modeled `state-auth-callback-error-missing` regression stays pinned in place when critique-side callback flows assume the happy path even when providers can deny or fail the exchange.
- Project-audit coverage now explicitly locks down the existing auth callback flows that read provider `state` without validating it path with regressions for patterns like `const state = searchParams.get('state'); const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback state-validation enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback state-validation gap where `AuthCallback` reads both `searchParams.get('state')` and `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p data-state={state}>Signing you in…</p>;` without comparing that returned `state` against any reviewed expected value, so the already-modeled `source-auth-callback-state-validation-missing` regression stays pinned in place when reviewed callback flows trust provider state without validation.
- Critique coverage now explicitly locks down the existing auth callback flows that read provider `state` without validating it path with regressions for patterns like `const state = searchParams.get('state'); const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); }`, so the verifier’s already-modeled callback state-validation enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback state-validation gap where reviewed `AuthCallback` code reads both `searchParams.get('state')` and `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p data-state={state}>Signing you in...</p>;` without comparing that returned `state` against any reviewed expected value, so the already-modeled `security-auth-callback-state-validation-missing` regression stays pinned in place when critique-side callback flows trust provider state without validation.
- Project-audit coverage now explicitly locks down the existing auth callback flows that validate provider `state` but never clear stored state path with regressions for patterns like `const returnedState = searchParams.get('state'); const expectedState = sessionStorage.getItem('oauth_state'); if (!returnedState || returnedState !== expectedState) { return <p>Authentication failed. Please try again.</p>; }`, so the verifier’s already-modeled callback state-teardown enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback state-teardown gap where `AuthCallback` validates `returnedState` against `sessionStorage.getItem('oauth_state')`, continues into `void auth.exchangeCodeForSession(code)`, and redirects to `/dashboard` without ever clearing the stored `oauth_state` key, so the already-modeled `source-auth-callback-state-teardown-missing` regression stays pinned in place when reviewed callback flows validate CSRF state but leave it lingering in browser storage.
- Critique coverage now explicitly locks down the existing auth callback flows that validate provider `state` but never clear stored state path with regressions for patterns like `const returnedState = searchParams.get('state'); const expectedState = sessionStorage.getItem('oauth_state'); if (!returnedState || returnedState !== expectedState) { return <p>Authentication failed. Please try again.</p>; }`, so the verifier’s already-modeled callback state-teardown enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback state-teardown gap where reviewed `AuthCallback` code validates `returnedState` against `sessionStorage.getItem('oauth_state')`, continues into `void auth.exchangeCodeForSession(code)`, and still redirects to `/dashboard` without ever clearing the stored `oauth_state` key, so the already-modeled `security-auth-callback-state-teardown-missing` regression stays pinned in place when critique-side callback flows validate CSRF state but leave it lingering in browser storage.
- Project-audit coverage now explicitly locks down the existing auth callback failure handling that never routes back to sign-in path with regressions for patterns like `const providerError = searchParams.get('error'); if (providerError) { return <p>Authentication failed. Please try again.</p>; }`, so the verifier’s already-modeled callback entry-return enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback entry-return gap where `AuthCallback` branches on `searchParams.get('error')`, returns `<p>Authentication failed. Please try again.</p>;`, and still never exposes a path back to `/login` or another declared sign-in route before the successful branch redirects to `/dashboard`, so the already-modeled `source-auth-callback-entry-return-missing` regression stays pinned in place when reviewed callback failure states strand users away from the anonymous entry surface.
- Critique coverage now explicitly locks down the existing auth callback failure handling that never routes back to sign-in path with regressions for patterns like `const providerError = searchParams.get('error'); if (providerError) { return <p>Authentication failed. Please try again.</p>; }`, so the verifier’s already-modeled callback entry-return enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback entry-return gap where reviewed `AuthCallback` code branches on `searchParams.get('error')`, returns `<p>Authentication failed. Please try again.</p>;`, and still never exposes a path back to `/login` or another declared sign-in route before the successful branch redirects to `/dashboard`, so the already-modeled `route-auth-callback-entry-return-missing` regression stays pinned in place when critique-side callback failure states strand users away from the anonymous entry surface.
- Project-audit coverage now explicitly locks down the existing auth callback flows that never surface success state or protected transition path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); } return <p>Signing you in...</p>;`, so the verifier’s already-modeled callback success-transition enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback-success gap where `AuthCallback` reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in...</p>;`, so the already-modeled `source-auth-callback-success-missing` regression stays pinned in place when reviewed callback flows never resolve into either a protected route transition or an explicit success state.
- Critique coverage now explicitly locks down the existing auth callback flows that never surface success state or protected transition path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); } return <p>Signing you in...</p>;`, so the verifier’s already-modeled callback success-transition enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback-success gap where reviewed `AuthCallback` code reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in...</p>;`, so the already-modeled `state-auth-callback-success-missing` regression stays pinned in place when critique-side callback flows never resolve into either a protected route transition or an explicit success state.
- Project-audit coverage now explicitly locks down the existing auth callback exchanges without explicit rejection handling path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); } history.replaceState({}, '', '/dashboard'); return redirect('/dashboard');`, so the verifier’s already-modeled callback exchange-error handling enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback exchange-error gap where `AuthCallback` reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still immediately runs `history.replaceState({}, '', '/dashboard'); return redirect('/dashboard');` without any rejection branch, so the already-modeled `source-auth-callback-exchange-error-missing` regression stays pinned in place when reviewed callback flows assume exchange success and strand failures on an unhandled path.
- Critique coverage now explicitly locks down the existing auth callback exchanges without explicit rejection handling path with regressions for patterns like `const code = searchParams.get('code'); if (code) { void auth.exchangeCodeForSession(code); } history.replaceState({}, '', '/dashboard'); return redirect('/dashboard');`, so the verifier’s already-modeled callback exchange-error handling enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback exchange-error gap where reviewed `AuthCallback` code reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still immediately runs `history.replaceState({}, '', '/dashboard'); return redirect('/dashboard');` without any rejection branch, so the already-modeled `state-auth-callback-exchange-error-missing` regression stays pinned in place when critique-side callback flows assume exchange success and strand failures on an unhandled path.
- Project-audit coverage now explicitly locks down the existing auth callback error returns that never scrub provider params path with regressions for patterns like `const providerError = searchParams.get('error'); if (providerError) { return <a href="/login">Back to sign in</a>; }`, so the verifier’s already-modeled callback URL hygiene enforcement stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing callback URL scrub gap where `AuthCallback` branches on `searchParams.get('error')`, returns `<a href="/login">Back to sign in</a>;`, and still leaves the provider error params sitting in browser history without any `history.replaceState` or equivalent scrub step, so the already-modeled `source-auth-callback-url-scrub-missing` regression stays pinned in place when reviewed callback failure paths leave provider-return data sitting in the URL bar.
- Project-audit coverage now explicitly locks down the existing callback URL scrub gap where `AuthCallback` reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in...</p>;` without any `history.replaceState`, router replacement, or equivalent callback URL scrub step, so the already-modeled `source-auth-callback-url-scrub-missing` regression stays pinned in place when project-audit callback success paths leave provider-return codes sitting in browser history.
- Critique coverage now explicitly locks down the existing auth callback error returns that never scrub provider params path with regressions for patterns like `const providerError = searchParams.get('error'); if (providerError) { return <a href="/login">Back to sign in</a>; }`, so the verifier’s already-modeled callback URL hygiene enforcement stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing callback URL-scrub gap where reviewed `AuthCallback` code branches on `searchParams.get('error')`, returns `<a href="/login">Back to sign in</a>;`, and still leaves the provider error params sitting in browser history without any `history.replaceState` or equivalent scrub step, so the already-modeled `security-auth-callback-url-scrub-missing` regression stays pinned in place when critique-side callback failure paths leave provider-return data sitting in the URL bar.
- Critique coverage now explicitly locks down the existing callback URL-scrub gap where reviewed `AuthCallback` code reads `searchParams.get('code')`, calls `void auth.exchangeCodeForSession(code)`, and still only returns `<p>Signing you in...</p>;` without any `history.replaceState`, router replacement, or equivalent callback URL scrub step, so the already-modeled `security-auth-callback-url-scrub-missing` regression stays pinned in place when critique-side callback success paths leave provider-return codes sitting in browser history.
- Project-audit coverage now explicitly locks down the existing cloned `req.nextUrl` carrier path with regressions for patterns like `const nextUrl = req.nextUrl.clone()` and `const params = req.nextUrl.clone().searchParams`, so the verifier’s already-modeled cloned request-URL behavior stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing cloned-`req.nextUrl` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); return redirect(nextUrl.searchParams.get('next') ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects trust cloned request-carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing cloned `req.nextUrl` carrier path with regressions for patterns like `const nextUrl = req.nextUrl.clone()` and `const params = req.nextUrl.clone().searchParams`, so the verifier’s already-modeled cloned request-URL behavior stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing cloned-`req.nextUrl` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); return redirect(nextUrl.searchParams.get('next') ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects trust cloned request-carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `nextUrl.search` / `nextUrl.href` reviewed URL-carrier path with regressions for patterns like `new URLSearchParams(req.nextUrl.search)` and `new URL(nextUrl.href)`, so the verifier’s already-modeled reviewed request-URL string-carrier behavior stays pinned in place alongside the earlier auth tracing work.
- Project-audit coverage now explicitly locks down the existing `req.nextUrl.search` redirect gap where reviewed middleware code does `const next = new URLSearchParams(req.nextUrl.search).get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects reparse reviewed request search strings and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `nextUrl.href` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); const next = new URL(nextUrl.href).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects reparse cloned reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `req.nextUrl.toString()` redirect gap where reviewed middleware code does `const next = new URL(req.nextUrl.toString()).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects stringify reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `String(nextUrl)` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); const next = new URL(String(nextUrl)).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects stringify cloned reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `Object.fromEntries(req.nextUrl.searchParams)` redirect gap where reviewed middleware code does `const query = Object.fromEntries(req.nextUrl.searchParams); return redirect(query.next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects coerce reviewed request params into plain objects and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing destructured `Object.fromEntries(new URLSearchParams(window.location.search))` redirect gap where reviewed route code does `const { next } = Object.fromEntries(new URLSearchParams(window.location.search)); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects destructure plain-object query carriers and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing aliased `searchParams.entries()`-into-`Object.fromEntries(...)` redirect gap where reviewed route code does `const entries = new URLSearchParams(window.location.search).entries(); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects route reviewed query iterators through aliased entry carriers and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing `Array.from(new URLSearchParams(window.location.search).entries())` redirect gap where reviewed route code does `const entries = Array.from(new URLSearchParams(window.location.search).entries()); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects materialize reviewed query iterators into arrays and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing spread-wrapped `Object.fromEntries([...new URLSearchParams(window.location.search)])` redirect gap where reviewed route code does `const query = Object.fromEntries([...new URLSearchParams(window.location.search)]); return redirect(query.next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects spread reviewed query iterables into arrays and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing normalized `window.location.search.slice(1)` redirect gap where reviewed route code does `const params = new URLSearchParams(window.location.search.slice(1)); return redirect(params.get('next') ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects normalize reviewed location-search carriers and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing normalized `req.nextUrl.search.slice(1)` redirect gap where reviewed middleware code does `const params = new URLSearchParams(req.nextUrl.search.slice(1)); return redirect(params.get('next') ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects normalize reviewed request-search carriers and still trust carried destinations without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing aliased destructured `useRouter().query` redirect gap where reviewed route code does `const { query: params } = useRouter(); return redirect(params.next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects trust aliased router-query carriers without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing template-wrapped router-query redirect gap where reviewed route code does `const next = router.query.next; return redirect(\`\${next ?? '/dashboard'}\`);`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects wrap carried router-query destinations in template strings and still trust them without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing template-wrapped `searchParams` prop redirect gap where reviewed route code does `return <Link to={\`\${next ?? '/dashboard'}\`}>Continue</Link>;`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects wrap carried `searchParams` destinations in template strings and still trust them without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing snake-case `searchParams.get('return_to')` redirect gap where reviewed route code does `return redirect(searchParams.get('return_to') ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects trust backend-shaped redirect keys without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing snake-case `router.query[queryKey]` redirect gap where reviewed route code does `const queryKey = 'redirect_to'; return <Link to={{ pathname: router.query[queryKey] ?? '/dashboard' }}>Continue</Link>;`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects trust backend-shaped query aliases without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing snake-case `URLSearchParams(window.location.search).get(queryKey)` redirect gap where reviewed route code does `const queryKey = 'callback_url'; const next = new URLSearchParams(window.location.search).get(queryKey); return redirect(next ?? '/dashboard');`, so the already-modeled `source-auth-open-redirect-risk` regression stays pinned in place when project-audit auth redirects trust backend-shaped callback-url carriers without validating them against reviewed internal routes.
- Project-audit coverage now explicitly locks down the existing post-sign-in external redirect gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/continue');`, so the already-modeled `source-auth-external-redirect-risk` regression stays pinned in place when project-audit auth flows hardcode off-site destinations instead of keeping post-auth transitions on reviewed internal routes or explicit allowlists.
- Project-audit coverage now explicitly locks down the existing provider authorize URL without `state` gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code');`, so the already-modeled `source-auth-provider-state-missing` regression stays pinned in place when project-audit auth flows hardcode provider authorize URLs without explicit return-flow state protection.
- Project-audit coverage now explicitly locks down the existing provider code-flow URL without PKCE gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code&state=opaque123');`, so the already-modeled `source-auth-provider-pkce-missing` regression stays pinned in place when project-audit auth flows hardcode provider code-flow authorize URLs without explicit PKCE protection.
- Project-audit coverage now explicitly locks down the existing provider `id_token` URL without `nonce` gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=id_token&state=opaque123');`, so the already-modeled `source-auth-provider-nonce-missing` regression stays pinned in place when project-audit auth flows hardcode provider `id_token` authorize URLs without explicit nonce protection.
- Critique coverage now explicitly locks down the existing post-sign-in external redirect gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/continue');`, so the already-modeled `security-auth-external-redirect-risk` regression stays pinned in place when critique-side auth flows hardcode off-site destinations instead of keeping post-auth transitions on reviewed internal routes or explicit allowlists.
- Critique-side coverage now explicitly locks down the existing provider authorize URL without `state` gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code');`, so the already-modeled `security-auth-provider-state-missing` regression stays pinned in place when critique-side auth flows hardcode provider authorize URLs without explicit return-flow state protection.
- Critique-side coverage now explicitly locks down the existing provider code-flow URL without PKCE gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code&state=opaque123');`, so the already-modeled `security-auth-provider-pkce-missing` regression stays pinned in place when critique-side auth flows hardcode provider code-flow authorize URLs without explicit PKCE protection.
- Critique-side coverage now explicitly locks down the existing provider `id_token` URL without `nonce` gap where reviewed route code does `await auth.signIn(); return redirect('https://accounts.example.com/oauth2/authorize?client_id=web&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=id_token&state=opaque123');`, so the already-modeled `security-auth-provider-nonce-missing` regression stays pinned in place when critique-side auth flows hardcode provider `id_token` authorize URLs without explicit nonce protection.
- Critique coverage now explicitly locks down the existing snake-case `URLSearchParams(window.location.search).get(queryKey)` redirect gap where reviewed route code does `const queryKey = 'callback_url'; const next = new URLSearchParams(window.location.search).get(queryKey); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects trust backend-shaped callback-url carriers without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing template-wrapped `searchParams` prop redirect gap where reviewed route code does `return <Link to={\`\${next ?? '/dashboard'}\`}>Continue</Link>;`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects wrap carried `searchParams` destinations in template strings and still trust them without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `nextUrl.search` / `nextUrl.href` reviewed URL-carrier path with regressions for patterns like `new URLSearchParams(req.nextUrl.search)` and `new URL(nextUrl.href)`, so the verifier’s already-modeled reviewed request-URL string-carrier behavior stays pinned in place alongside the earlier project-audit coverage.
- Critique coverage now explicitly locks down the existing `req.nextUrl.search` redirect gap where reviewed middleware code does `const next = new URLSearchParams(req.nextUrl.search).get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects reparse reviewed request search strings and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `nextUrl.href` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); const next = new URL(nextUrl.href).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects reparse cloned reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `req.nextUrl.toString()` redirect gap where reviewed middleware code does `const next = new URL(req.nextUrl.toString()).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects stringify reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `String(nextUrl)` redirect gap where reviewed middleware code does `const nextUrl = req.nextUrl.clone(); const next = new URL(String(nextUrl)).searchParams.get('next'); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects stringify cloned reviewed request URLs and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `Object.fromEntries(req.nextUrl.searchParams)` redirect gap where reviewed middleware code does `const query = Object.fromEntries(req.nextUrl.searchParams); return redirect(query.next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects coerce reviewed request params into plain objects and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing destructured `Object.fromEntries(new URLSearchParams(window.location.search))` redirect gap where reviewed route code does `const { next } = Object.fromEntries(new URLSearchParams(window.location.search)); return redirect(next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects destructure plain-object query carriers and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing aliased `searchParams.entries()`-into-`Object.fromEntries(...)` redirect gap where reviewed route code does `const entries = new URLSearchParams(window.location.search).entries(); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects route reviewed query iterators through aliased entry carriers and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing `Array.from(new URLSearchParams(window.location.search).entries())` redirect gap where reviewed route code does `const entries = Array.from(new URLSearchParams(window.location.search).entries()); const query = Object.fromEntries(entries); return redirect(query.next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects materialize reviewed query iterators into arrays and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing spread-wrapped `Object.fromEntries([...new URLSearchParams(window.location.search)])` redirect gap where reviewed route code does `const query = Object.fromEntries([...new URLSearchParams(window.location.search)]); return redirect(query.next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects spread reviewed query iterables into arrays and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing normalized `window.location.search.slice(1)` redirect gap where reviewed route code does `const params = new URLSearchParams(window.location.search.slice(1)); return redirect(params.get('next') ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects normalize reviewed location-search carriers and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing normalized `req.nextUrl.search.slice(1)` redirect gap where reviewed middleware code does `const params = new URLSearchParams(req.nextUrl.search.slice(1)); return redirect(params.get('next') ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects normalize reviewed request-search carriers and still trust carried destinations without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing aliased destructured `useRouter().query` redirect gap where reviewed route code does `const { query: params } = useRouter(); return redirect(params.next ?? '/dashboard');`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects trust aliased router-query carriers without validating them against reviewed internal routes.
- Critique coverage now explicitly locks down the existing template-wrapped router-query redirect gap where reviewed route code does `const next = router.query.next; return redirect(\`\${next ?? '/dashboard'}\`);`, so the already-modeled `security-auth-open-redirect-risk` regression stays pinned in place when critique-side auth redirects wrap carried router-query destinations in template strings and still trust them without validating them against reviewed internal routes.

## Highest-Value Next Streams

1. Add richer golden verification beyond build/smoke into route/runtime behavior.
2. Move execution packs deeper into hosted/API workflows instead of local scaffold-only artifacts.
3. Deepen verifier coverage further into auth, navigation, performance, and security checks beyond the current AST/runtime baseline.
4. Continue narrowing legacy `any`/implicit contracts in older CLI and MCP paths.
5. Keep improving content intelligence quality and confidence scoring on top of the now-live hosted summary contract.
