Summary
Three interconnected architectural improvements, planned and documented in docs/mcp-server-plan.md.
Layer 1 — MCP Server (do first)
Expose all 41 SPARK tools to the Claude Code dev session on the Pi via the Model Context Protocol. From the dev terminal, Claude Code can control the robot directly — no voice loop needed.
bin/mcp-server — stdio JSON-RPC 2.0 serversrc/pxh/mcp_server.py — server implementationsrc/pxh/schemas.py — declarative tool parameter schemas (generated from validate_action).mcp.json — Claude Code auto-discovers and spawns the server- MCP resources:
spark://session, spark://thoughts, spark://notes
Layer 2 — Stateful Conversation Buffer
Replace fully stateless --no-session-persistence with a rolling conversation window. SPARK remembers what it said 2 turns ago without relying entirely on file injection.
state/conversation-{persona}.jsonl — last 10 turns (user + SPARK) per persona- Injected into
build_model_prompt() as "Recent conversation" section
- Also fixes statefulness gap in the web UI chat
Layer 3 — SPARK as Autonomous Agent
SPARK can suggest features, implement them, commit to a feature branch, and create GH issues — prompted by Obi mid-conversation.
claude-voice-bridge: remove --allowedTools "", allow Read,Write,Edit,Bash,WebSearch- Remove
--no-session-persistence (requires Layer 2 first)
- SPARK operates on
spark/auto branch — Adrian reviews via PR
- Safety rules in spark-voice-system.md and Bash restrictions
Web UI (already implemented)
GET / serves a self-contained dark-theme dashboard at port 8420. Sidebar buttons for every tool + chat input → POST /api/v1/chat. Gaps: no conversation history, no live session updates — both fixed by Layer 2.
Design doc
See full plan with implementation order, file list, trade-offs, and open questions:
docs/mcp-server-plan.md
Open questions (for Adrian + Obi to decide)
- How much autonomy should SPARK have when modifying code? Always ask? Commit silently?
- Review flow: per-change PR notification or batched?
- Should SPARK narrate what it's doing in kid-friendly terms as it codes?
- Session window length: per wake-word session / all day / reset at midnight?
- Feature branch name:
spark/auto? Let Obi name it?
Summary
Three interconnected architectural improvements, planned and documented in
docs/mcp-server-plan.md.Layer 1 — MCP Server (do first)
Expose all 41 SPARK tools to the Claude Code dev session on the Pi via the Model Context Protocol. From the dev terminal, Claude Code can control the robot directly — no voice loop needed.
bin/mcp-server— stdio JSON-RPC 2.0 serversrc/pxh/mcp_server.py— server implementationsrc/pxh/schemas.py— declarative tool parameter schemas (generated from validate_action).mcp.json— Claude Code auto-discovers and spawns the serverspark://session,spark://thoughts,spark://notesLayer 2 — Stateful Conversation Buffer
Replace fully stateless
--no-session-persistencewith a rolling conversation window. SPARK remembers what it said 2 turns ago without relying entirely on file injection.state/conversation-{persona}.jsonl— last 10 turns (user + SPARK) per personabuild_model_prompt()as "Recent conversation" sectionLayer 3 — SPARK as Autonomous Agent
SPARK can suggest features, implement them, commit to a feature branch, and create GH issues — prompted by Obi mid-conversation.
claude-voice-bridge: remove--allowedTools "", allowRead,Write,Edit,Bash,WebSearch--no-session-persistence(requires Layer 2 first)spark/autobranch — Adrian reviews via PRWeb UI (already implemented)
GET /serves a self-contained dark-theme dashboard at port 8420. Sidebar buttons for every tool + chat input →POST /api/v1/chat. Gaps: no conversation history, no live session updates — both fixed by Layer 2.Design doc
See full plan with implementation order, file list, trade-offs, and open questions:
docs/mcp-server-plan.mdOpen questions (for Adrian + Obi to decide)
spark/auto? Let Obi name it?