fix: orchestrator button + Pi SDK session error

- 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()

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

@@ -0,0 +1,179 @@
+# 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