E2E Task Validator — calistenia

The app URL when running with start:test is: http://localhost:5173

Phase 1 — Start the test server

Run the development server in test mode as a background process:

pnpm run start:test

Wait ~5 seconds for Vite to finish compiling. The app will be available at http://localhost:5173.

If the port is already in use, kill the occupying process first:

npx kill-port 5173
pnpm run start:test

Phase 2 — Test in the browser via Playwright MCP

Use the Playwright MCP browser tools to navigate and interact with the app. Your goal is to verify each acceptance criterion from the task file.

Standard login flows

Login as Client:

1. Navigate to http://localhost:5173
2. Click on the login/access button if on the landing page
3. Fill in [email protected] and 123456
4. Submit and confirm redirection to /app/*

Login as Admin:

1. Navigate to http://localhost:5173
2. Login with [email protected] and 123456
3. Confirm redirection to /admin/*

Testing approach

Work through each acceptance criterion one at a time:

1. Take a browser snapshot to see the current state
2. Interact with the relevant UI element (click, fill, navigate)
3. Take another snapshot to verify the result
4. Mark the criterion as PASS or FAIL

For each criterion, document:

• What you clicked / filled / navigated to
• What you observed in the snapshot
• Whether it matches the expected behavior

Common interactions to use

browser_navigate → go to a URL
browser_click → click a button/link by ref
browser_snapshot → capture the accessibility tree (PREFER over screenshots)
browser_type → type into an input
browser_select_option → choose from a dropdown

Phase 3 — Fix and retest (if failures found)

If any acceptance criterion fails:

1. Stop the server (or leave it running — Vite hot-reloads)
2. Identify the root cause from the snapshot and the source code
3. Apply the fix to the relevant file(s)
4. Retest — go back to Phase 2 and re-verify the failing criterion
5. Repeat until all criteria pass

Keep fixes minimal and targeted. Do not refactor unrelated code.

Phase 4 — Document test results in the task file

Once all acceptance criteria pass, append a ## Resultados de Pruebas E2E section to the task .md file:

## Resultados de Pruebas E2E

**Fecha:** YYYY-MM-DD  
**Rama:** feature/YYYY-MM-DD-[task-name]  
**Resultado:** ✅ Todos los criterios pasaron

### Pruebas realizadas

| Criterio | Acción realizada | Resultado |
|----------|-----------------|-----------|
| [Criterio 1 del .md] | [Lo que hiciste en el browser] | ✅ Pasa |
| [Criterio 2 del .md] | [Lo que hiciste en el browser] | ✅ Pasa |

### Notas
[Any relevant observations, edge cases noticed, or things left for future improvement]

Also update the frontmatter updated timestamp:

sed -i 's/^updated: .*/updated: '"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'/' "taskReadme/TASK_NAME.md"

Phase 5 — Commit and push

Stage all changes (code fixes + updated task file) and push to the task branch:

# 1. Stop the dev server if still running (optional — Ctrl+C or kill-port)

# 2. Stage everything
git add -A

# 3. Commit (only if there are changes)
if git diff --cached --quiet; then
  echo "Nothing new to commit"
else
  git commit -m "test(e2e): validate task and document results

All acceptance criteria verified via Playwright MCP browser testing.
See taskReadme/TASK_NAME.md for detailed test results."

  # 4. Push to the current branch
  BRANCH=$(git branch --show-current)
  git push origin "$BRANCH"
  echo "✅ Pushed to $BRANCH"
fi

If git push fails due to credential issues:

gh auth setup-git
git push origin "$BRANCH"

Status summary checklist

Before finishing, confirm:

• Server started and app loaded in browser
• All acceptance criteria tested in the browser (one by one)
• Any failures were fixed and retested until passing
• ## Resultados de Pruebas E2E section added to the task .md
• Commit created with fix + documentation
• Pushed to the task feature branch

Tips

• Always use browser_snapshot before clicking — references (refs) change between snapshots, don't reuse stale refs.
• If the app shows a loading spinner for too long, wait and re-snapshot.
• Test both happy path AND edge cases mentioned in "Riesgos y Notas" of the task file.
• If the task requires admin-only flows, test as admin. If it requires client flows, test as client. Some tasks need both.
• The app uses Supabase as backend — changes are real, so clean up test data if needed (e.g., cancel any test bookings made during testing).