Findings from a Microsoft / React / SonarQube best-practices review of the codebase, carried out after the Initial Build project completed.
Each item was verified against the code rather than asserted from a checklist, and cites the files it concerns. None is a live outage; several are latent failures that would present as silence rather than as errors, which is the failure mode this project has already been bitten by in production once.
Ordered roughly by severity. #59 is the one worth doing first: it is the same defect class as the 2026-08-17 incident, and the fix written at the time reached fewer than half the routes it needed to.
Passwordless sign-in for customers using WebAuthn passkeys, alongside the existing email and password login.
Split out of #31 because it is the only item there that introduces a second authentication path next to the current bcrypt + rd_session cookie. Tracking issue: #36.
Issues
| # | Scope | Depends on |
|---|---|---|
| #37 | Schema, @simplewebauthn dependency, per-environment RP config |
— |
| #38 | Registration ceremony — a signed-in customer enrolls a passkey | #37 |
| #40 | Manage and revoke passkeys from the account page | #38 |
| #39 | Authentication ceremony — signing in with a passkey | #38 |
| #41 | Login page integration, feature detection, fallback | #39 |
| #42 | Account recovery and password-reset interaction | #32, #39 |
Suggested order: #37 → #38 → #40 → #39 → #41 → #42
#40 comes before #39 on purpose. Once a customer can enroll a passkey they can also strand one, and shipping enrollment with no way to see or remove a credential is worse than not offering passkeys at all.
Standing constraints
- The Relying Party ID is domain-bound. A passkey registered against QA will never work in production. QA proves the flow, the fallbacks, and the copy — never the credentials. Production needs its own smoke test after deploy.
- Password login remains the fallback throughout. Nothing here should make it possible to end up with an account that cannot be recovered.
- A disabled account (#33) must not authenticate via passkey. Enforcing that only on the password path would leave passkeys as a way around it.
Depends on
- #32 — password reset. Passkey login cannot ship without account recovery; a customer who loses their authenticator needs a way back in.
- #33 — disable account, so the "cannot authenticate" rule exists before there is a second path that has to honor it.
Done when
A customer can enroll a passkey, sign in with it, see and revoke it, fall back to a password on any device that does not support it, and recover the account if the authenticator is lost.