stroblmeandClaude Opus 5
1039feb5d3
Docs / docs (push) Canceled after 0s
Playwright Tests / test-playwright (1, 2) (push) Canceled after 0s
Playwright Tests / test-playwright (2, 2) (push) Canceled after 0s
pre-commit / pre-commit (push) Canceled after 0s
Test Backend / test-backend (push) Canceled after 0s
Compose Smoke Test / test-compose (push) Canceled after 0s
Playwright Tests / merge-reports (push) Canceled after 0s
An enrolment outlives the database it was made in. Restore a backup, or move to a different one, and the same operator is a different row — `local_user_id` then names nobody, every portal session resolves to no local user, and the machine answers 401 to the only route into it. That is the lockout the welcome frame's owner exists to prevent, and it was prevented only for the case where the row still existed. One superuser is not a guess: it is the account enrolment would have used, so it is adopted and written back. Several is a guess, and this says so instead. Writing it back matters beyond this: a screen paired through the portal borrows the same field, so it was refused for the same reason with no way to say so. Found on the production instance after the move to SQLite, which is exactly this case — DEPLOY.md said to enrol again, and the machine should not need telling. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>