d335e5bf71
- Move leftSidebarMode from URL state to local useState in unified-shell,
avoiding force-dynamic router round-trip that made the button appear broken - Replace fileURLToPath(new URL(..., import.meta.url)) with process.cwd()
in bb-pi-bootstrap.ts — import.meta.url is a webpack:// URL in Next.js,
causing cross-realm TypeError when passed to Node.js fileURLToPath()
179 lines
4.8 KiB
Markdown
179 lines
4.8 KiB
Markdown
# 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
|