Skip to content

Selenium → browse-tests Migration: Coordination Protocol

This is the operating procedure for running multiple LLM agents (Claude, Codex, Cursor) in parallel against the migration. It pairs with:

How agents coordinate

The coordination PR description is the live status board. Day-1 batch assignments are pre-baked so every agent knows their lane immediately. The status board carries one of four states per batch:

Marker Meaning
assigned to <agent> Pre-assigned, not started yet
in progress by <agent> at <UTC> Agent claimed it and is actively working
done — PR #<n> Batch PR is open (and linked)
merged Batch PR is merged to master

Claude's role: review-only. Claude does not write tests for this migration. Claude reviews each batch PR before it merges to master, surfaces issues in PR comments, and triages prompt ambiguity feedback into doc updates.

Day-1 assignments:

Wave Batch Agent Status on day 1
1 RO-1 — Contacts read-only Cursor (prompt-validation pass) assigned
1 RO-2 — Login + redirects + reports + app store Cursor assigned
1 RO-3 — Settings read-only Codex CLI assigned
1 RO-4 — Social + Events read-only Codex CLI assigned
2 AM-1 — Contacts mutation Codex CLI assigned
2 AM-2 — ApplicationForm admin mutation Cursor assigned
2 AM-3 — Settings mutation Codex CLI assigned
2 AM-4 — Social mutation Codex CLI assigned
2 AM-5 — Events admin mutation Cursor assigned
2 AM-6 — Jobs + Messages + Directory mutation Cursor assigned
3 PM-1 — ApplicationForm payment Cursor blocked on sandbox-fixture PR
3 PM-2 — Billing + Contact payment Cursor blocked on sandbox-fixture PR
3 PM-3 — Fundraising Codex CLI blocked on sandbox-fixture PR
3 PM-4 — Events payment Codex CLI blocked on sandbox-fixture PR
3 PM-5 — Membership payment reserve blocked on sandbox-fixture PR
4 EM-1 — Email regression reserve blocked on mailbox-fixture PR

Workload by agent: - Cursor: 7 batches (RO-1, RO-2, AM-2, AM-5, AM-6, PM-1, PM-2). RO-1 is the prompt-validation pass — Cursor flags ambiguity in PR comments before grinding through the rest. - Codex CLI: 7 batches (RO-3, RO-4, AM-1, AM-3, AM-4, PM-3, PM-4) - Reserve: 2 batches (PM-5, EM-1) — pick up after sandbox + mailbox fixtures land

What each agent does at the start of a batch

  1. Read the coordination PR description (gh pr view <coord-pr> --json body).
  2. Find your row (pre-assigned). If status is assigned to <you>: proceed. If somehow in progress by someone else: stop and message the user.
  3. Update your row from assigned to in progress by <you> at <UTC> via gh pr edit <coord-pr> --body @new-body.md. This is the soft lock.
  4. Create worktree, write tests, run suite, upload screenshots, open batch PR (full procedure in browser-test-migration-prompt.md).
  5. Update your row to done — PR #<n> <link>.
  6. When your batch PR merges, change status to merged.

Race conditions

gh pr edit --body is read-modify-write with no locking. Two agents updating the description in the exact same second = last-write-wins, one update lost. Mitigations:

  • Day-1 assignments mean there's nothing to race for in waves 1 and 2.
  • Agents must re-fetch the description with gh pr view --json body immediately before each edit and only change their own row.
  • Each row carries a stable sentinel comment (<!-- batch:RO-1 -->) so even if a race happens, post-hoc reconciliation is trivial.
  • If two agents end up working the same batch (low probability), the second to open a batch PR closes it and picks the next unassigned batch.

What blocks Wave 3 and Wave 4

Wave 3 (payment) is blocked until a separate, single-purpose PR lands that adds Stripe + Iyzico sandbox env-var wiring to browse-tests/local.settings.json.template and the runner. This PR should be ~1 hour of work; it sets: - BROWSE_TEST_STRIPE_TEST_CARD - BROWSE_TEST_STRIPE_ACCOUNT - BROWSE_TEST_IYZICO_TEST_CARD - BROWSE_TEST_IYZICO_ACCOUNT

Owner: TBD. Track in the coordination PR description.

Wave 4 (email) is blocked until a mailbox fixture is documented (e.g., a Mailosaur or owned inbox we can poll). Owner: TBD.

When migration is complete

When all 16 batches are merged:

  1. Run the full browse-tests suite end-to-end against .raklet.net to confirm parity.
  2. Open a PR that removes the Selenium "Automated Tests" stages from Azure DevOps release pipeline 31.
  3. Open a PR that deletes the Raklet.UI.Test.{1..5} projects.
  4. Close this coordination PR.