Use this section as the current release-facing snapshot for the workspace. If older notes elsewhere in this file conflict with this section, use this snapshot first.
### Re-verified Commands
-`cd frontend/admin && npm.cmd run test:run -- src/pages/admin/DevicesPage/DevicesPage.test.tsx`
-`cd frontend/admin && npm.cmd run test:run -- src/services/webhooks.test.ts`
-`cd frontend/admin && npm.cmd run test:run -- src/pages/admin/WebhooksPage/WebhooksPage.test.tsx`
-`cd frontend/admin && npm.cmd run test:run -- src/services/social-accounts.test.ts`
-`cd frontend/admin && npm.cmd run test:run -- src/services/settings.test.ts src/pages/admin/SettingsPage/SettingsPage.test.tsx src/pages/admin/ImportExportPage/ImportExportPage.test.tsx`
-`cd frontend/admin && npm.cmd run lint`
-`cd frontend/admin && npm.cmd run build`
-`cd frontend/admin && npm.cmd run e2e:full:win`
### Current Honest Release Conclusion
- The supported browser-level acceptance path `cd frontend/admin && npm.cmd run e2e:full:win` is green again in the current workspace.
- The latest green browser run included `admin-bootstrap`, `public-registration`, `email-activation`, `login-surface`, `auth-workflow`, `responsive-login`, `desktop-mobile-navigation`, `user-management-crud`, `user-management-batch`, `role-management-crud`, `device-management`, `login-logs`, `operation-logs`, `webhook-management`, `import-export`, `profile-and-security`, `settings`, and `dashboard-stats`.
- This evidence is sufficient for the supported browser-level gate, but it does not by itself replace the backend full matrix (`go test ./... -count=1`, `go vet ./...`, `go build ./cmd/server`).
- This snapshot also does not prove OS-level automation, live third-party OAuth validation, or external secrets/KMS delivery evidence.
## 2026-04-23 Additional Browser Gate Checks
- [ ] Cursor or list-page changes include a regression proving initial load does not self-trigger `next_cursor` pagination or burst extra requests.
- [ ] Frontend service changes against admin APIs verify exact response-envelope fields in service tests, not only page rendering.
- [ ] Frontend services using the shared HTTP client do not unwrap `data` twice; service tests reflect the real `request()` contract.
- [ ] Playwright selector changes prefer route, heading, role, or labeled-control locators over broad text searches.
- [ ] If suite retry reuses the same backend state, bootstrap or similar one-time preconditions are re-evaluated before rerunning browser scenarios.
- [ ] If a late-suite E2E failure blocks release, the release note records whether the root cause was product behavior, contract drift, selector drift, or browser-runtime instability.
-`cd frontend/admin && $env:E2E_SCENARIOS='permissions-management-crud'; npm.cmd run e2e:full:win`
-`cd frontend/admin && npm.cmd run e2e:full:win`
### Current Honest Release Conclusion
- The current supported browser-level gate is green with `20` scenarios and now includes `permissions-management-crud`.
- The same branch state also re-proved the backend full matrix and the frontend unit, lint, and build matrix.
- This evidence proves the supported browser-level acceptance path in the current workspace. It still does not prove OS-level automation, live third-party OAuth validation, or external secrets or KMS delivery evidence.
### Additional Checklist Items
- [ ] If a frontend service normalizes backend enum values for UI consumption, tests cover the raw backend payload shape, the normalized frontend shape, and outbound write serialization.
- [ ] If a browser scenario succeeds in the page but CDP request or response observers miss the proxied call, runner-level proof records the real in-page fetch result before classifying the product as broken.
- [ ] If a modal-driven CRUD flow depends on an overlay leaving animation, the next user action waits for the modal to stop blocking interaction instead of relying on a broad hidden assertion alone.
- [ ] If `npm.cmd run build` depends on Vite native config loading on Windows, the supported config keeps HTML inputs under an explicit project root instead of relying on wrapper scripts to mask absolute-path errors.
- The supported browser-level gate remains green with `20` scenarios after the real `profile-and-security` password-update contract fix.
- This round re-proved the directly affected frontend regression set, lint, build, and the supported browser gate on the same workspace state.
- This round did not re-run the backend full matrix, so backend-wide claims still rely on the latest earlier verified snapshot.
### Additional Checklist Items
- [ ] If a UI form shape differs from the backend write contract, the service adapter must serialize the backend field names explicitly and service tests must pin the exact outbound payload.
- [ ] If a browser runner waits on in-page fetch diagnostics, that wait must be created in the same control flow as the submit action and must not be allowed to outlive a failed click or fill step.
-`cd frontend/admin && npm.cmd run test:run -- src/lib/playwright-e2e-scenarios.test.ts`
-`cd frontend/admin && npm.cmd run test:run`
-`cd frontend/admin && npm.cmd run lint`
-`cd frontend/admin && npm.cmd run build`
-`cd frontend/admin && $env:E2E_SCENARIOS='email-activation'; npm.cmd run e2e:full:win`
-`cd frontend/admin && npm.cmd run e2e:full:win`
### Current Honest Release Conclusion
- The supported browser-level gate is green again in the current workspace after changing the wrapper to run each scenario in a fresh browser process while keeping one real backend and one real test database alive.
- The latest green full run executed `21` isolated scenario runs: `admin-bootstrap` plus the `20` steady-state scenarios behind it.
- This evidence proves the documented browser-level acceptance path in the current workspace. It does not by itself prove that the underlying Chromium host-runtime `0x5` issue has disappeared.
### Additional Checklist Items
- [ ] If the host browser runtime is the unstable component, isolate browser processes per scenario before expanding suite-level retries.
- [ ] If the supported gate uses scenario isolation, the wrapper still preserves one real backend, one real frontend server, one real SMTP capture path, and one real test database for the whole run.
- [ ] The scenario list used by the wrapper is derived from the same source as the Playwright runner and is not duplicated manually in release-critical code.
- [ ] For any owner-scoped resource endpoint addressed by path ID, verify that a non-owner cannot read, update, delete, or privilege-toggle another user's resource through the supported API surface.
- [ ] For the same endpoint family, verify that the service layer re-checks ownership or admin privilege instead of trusting only a handler-level path check.
- [ ] When admin cross-user access is intentional, add one positive regression proving the admin path still works after the IDOR fix.
