beadboard/docs/manual-test-phase-1-worker-spawning.md

Phase 1: Worker Spawning - Manual E2E Test

Date: 2026-03-06 Status: Ready for manual testing

---

Prerequisites

1. ✅ Dev server is running (user has it running)
2. ✅ Pi SDK is available (bb daemon bootstrap-pi should have been run)
3. ✅ All code changes are committed and applied

---

Test Scenarios

Scenario 1: Basic Worker Spawn

Steps:

1. Open BeadBoard in browser (http://localhost:3000)
2. Open left panel (orchestrator mode)
3. Send this prompt to orchestrator:

   Spawn a worker to read the README.md file and tell me what it says.
   

4. Observe the response and check:
   • Orchestrator calls bb_spawn_worker tool
   • Worker spawns with task context
   • worker.spawned event appears in runtime console (with "Worker" badge)
   • Worker event shows task ID: "read-the-readme.md-file-and-tell-me-what-it-says"
   • Worker status tool response is shown

Expected Result: Worker appears in console with "Worker" badge, shows "WORKING" status.

---

Scenario 2: Worker Status Check

Steps:

1. From left panel, send:

   Check the status of the worker you just spawned.
   

2. Observe:
   • Orchestrator calls bb_worker_status tool
   • Worker status is displayed with correct emoji
   • Shows "WORKING", "COMPLETED", or "FAILED" as appropriate
   • Task ID matches the spawned task

Expected Result: Current worker status shown with helpful message.

---

Scenario 3: Worker Completion

Steps:

1. Wait for the worker to complete (should happen within ~30 seconds for README read)
2. Observe:
   • worker.updated or worker.completed event appears
   • If completed: shows "COMPLETED" with ✅ emoji
   • Result summary is shown (first 200 chars)
   • Worker no longer shows as "WORKING"

Expected Result: Worker successfully completes and result is displayed.

---

Scenario 4: Multiple Workers

Steps:

1. Send prompt to orchestrator:

   Spawn 3 workers in parallel:
   - Worker 1: Read package.json
   - Worker 2: List all files in src/
   - Worker 3: Read .env.example file
   

2. Observe:
   • Three separate worker.spawned events appear
   • All three workers show "WORKING" status
   • Each worker has a unique ID
   • Task contexts are correct for each

Expected Result: Multiple workers run in parallel, each with unique identity and task.

---

Scenario 5: Worker with Archetype

Steps:

1. Send prompt to orchestrator:

   Spawn a worker with archetype "coder" to add a new test file.
   

2. Observe:
   • Worker spawns with "Archetype: coder" in the detail
   • Worker system prompt includes the archetype context

Expected Result: Worker behavior is guided by archetype (though actual behavior is same - this is v1).

---

Scenario 6: Worker Error Handling

Steps:

1. Send prompt to orchestrator with invalid task:

   Spawn a worker to read a file that does not exist: /nonexistent/path/to/file.txt
   

2. Observe:
   • Worker attempts the task
   • Worker fails and reports error
   • worker.failed event appears with ❌ emoji
   • Error message explains what went wrong

Expected Result: Worker failures are captured and reported clearly.

---

Scenario 7: Runtime Console Worker Badge

Steps:

1. Spawn a worker
2. Look at runtime console (bottom panel)
3. Observe:
   • Worker events have a purple "Worker" badge
   • Orchestrator events do NOT have the badge
   • Badge says "Worker Agent Event" on hover

Expected Result: Visual distinction between orchestrator and worker events is clear.

---

Scenario 8: Left Panel Chat Integration

Steps:

1. Observe the orchestrator conversation in left panel
2. During worker spawn, check:
   • Tool calls appear inline (like they do for bb_dolt_read)
   • Worker spawn response includes worker ID
   • Chat remains readable and not cluttered

Expected Result: Orchestrator chat surface handles worker interactions natively.

---

Success Criteria

A scenario passes when:

• Worker events appear in runtime console
• Worker events have "Worker" badge
• Status changes (spawning → working → completed) are visible
• Tool calls are logged and returned to orchestrator
• Multiple workers can run in parallel
• Worker completion/failure is captured

---

Bug Report Form

If any test fails, capture:

Test Scenario: [number]
Steps Taken: [what you did]
Expected Result: [what should happen]
Actual Result: [what actually happened]
Error Messages: [any errors in console]
Screenshot/Notes: [any additional details]

---

After Testing

Once all scenarios pass:

1. Review success criteria in docs/plans/2026-03-06-phase-1-worker-spawning.md
2. Update roadmap to mark Phase 1 as complete
3. Move to Phase 2: Archetype-backed execution configs