Browser-validate the account-claim flow end-to-end
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- playwright, typescript
- Domain
- authentication, testing-qa
Research direction
Start by running the dev server from this branch or post-merge main, then follow the two GitHub sign-in scenarios described in the issue. Use the existing account-claim screens from PR #46 and seed two people/*.toml records if needed for the multi-candidate case. Done means the single-candidate details and matchedVia value are correct, and selecting one multi-candidate card claims only that person.
Written by the indexing model from the issue text.
Description
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.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/*.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.
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 1
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 25
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeForPhilly/codeforphilly-ng
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
MarkdownEditor toolbar: use Radix Toolbar from radix-ui instead of the hand-rolled roving tabindex Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
All issues in CodeForPhilly/codeforphilly-ng
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
mksglu/context-mode#1200 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
jaegertracing/jaeger-ui#4506 ·
-
area:desktop area:ui bug platform:macos
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
anthropics/claude-code#96687 ·
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
AOSSIE-Org/DebateAI#582 · 2 comments ·