Read-only GET of a live Gitea /user/login showed the sign-in button is
<button class="ui primary button"> with NO type=submit attribute, so the seed
".ui.primary.button[type=submit]" would miss. Corrected to ".ui.primary.button"
(the mobile navbar toggle lacks "primary", so it stays unambiguous). Confirmed
during M-B4 rung-1 pre-live-fire prep; change-form selectors remain auth-gated
and self-heal-covered until the live run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Real account-settings pages (Gitea /user/settings/account, most dashboards) are
reachable only inside an authenticated session, but the engine went straight to
the change URL. Add Site.LoginBeforeChange: when set, Rotate authenticates through
the Login flow with the OLD secret first, so the session cookie carries into the
change-page fetch. Extract the login sequence into a shared r.login() helper reused
by both the pre-change auth (old secret) and Verify (new secret). A login wall we
cannot clear — including where MFA would appear — fails SAFE (old secret kept).
GiteaSite() seeds a curated change-password recipe (LoginBeforeChange on, standard
Gitea selectors, ProofUnproven until run against a real instance — self-heal repairs
any selector drift on first run; SuccessText mismatch only fails safe).
Proven LIVE-VM: TestIntegration_loginBeforeChangeRotation drives real Chromium
through a Gitea-style cookie gate (change page 302s to /login unless authenticated):
login(old)→settings→rotate→verify(new)→old-rejected. Non-browser
TestRotate_loginBeforeChangeOrder asserts login precedes change navigation and the
pre-change login uses the OLD secret. Full suite green.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
leetcrypt