Context
The account-claim plan (PR #46) covers all paths via unit + integration tests against the in-process Fastify instance. Two validation criteria depend on the running browser experience and were not flipped at merge:
- OAuth callback with candidates → claim screen renders the candidate(s) with the right info
- Multi-candidate picker works; selecting one claims it; others remain unclaimed
The implementation is complete; this is purely a manual / playwright verification gap. The parent-repo dev server was busy during the implementation window so I couldn't drive a real GitHub OAuth flow through the new screens without disrupting other agents.
Verification
Run dev in this branch (or a checked-out post-merge main) and:
- Sign in via GitHub against a laddr-era email that matches a single legacy Person. Confirm the claim screen renders one card with
matchedVia: email, fullName, slug, and member count.
- Repeat against a GH identity whose
gh.login and email both match different legacy Persons (multi-candidate). Confirm the picker shows both cards; select one; confirm only that Person gets the GH identity and the other stays unclaimed.
Notes: a quick way to seed the multi-candidate path locally is to add two people/*.toml records with distinct slugs and email-match one to your real primary GH email, and have the GH login field equal the other slug.
Context
The account-claim plan (PR #46) covers all paths via unit + integration tests against the in-process Fastify instance. Two validation criteria depend on the running browser experience and were not flipped at merge:
The implementation is complete; this is purely a manual / playwright verification gap. The parent-repo dev server was busy during the implementation window so I couldn't drive a real GitHub OAuth flow through the new screens without disrupting other agents.
Verification
Run
devin this branch (or a checked-out post-mergemain) and:matchedVia: email, fullName, slug, and member count.gh.loginand email both match different legacy Persons (multi-candidate). Confirm the picker shows both cards; select one; confirm only that Person gets the GH identity and the other stays unclaimed.Notes: a quick way to seed the multi-candidate path locally is to add two
people/*.tomlrecords with distinct slugs and email-match one to your realprimaryGH email, and have the GHloginfield equal the other slug.