Q-01: Pi 4 Runtime Shape & Configuration

Status: ACTIVE (exploration) Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-12T01:45:00Z Session: Live audit of Pi 4 surface — what's running, what's duplicated, how to clean and restage

Live Audit (2026-05-12)

Host Level

Docker Containers

Docker Images (Duplication)

• 4 dangling <none>:<none> images: 857MB + 578MB + 578MB + 479MB = ~2.5GB prunable
• Agent images: from-pi-agent (704MB), from-pi-agent-opencode (1.13GB), from-d3tui-agent (704MB)
• Jellyfin: 507MB (media server — unrelated)
• Total Docker image footprint: ~6GB

Disk & RAM

• 11GB used / 29GB total (38%). 18GB free.
• RAM: 3.7GB total, 678MB used, 3.0GB available

Key Findings

1. Massive Docker Image Bloat

~2.5GB in dangling images can be pruned. Multiple agent build images accumulated. Jellyfin may be unused. Run docker image prune -a to recover space.

2. Python Duplication

Python 3.13.5 with 257 packages on host. Separate venv (75MB) for game surface. The d3-tui container has NO Python — it uses Bun. The game backend needs Python. The question: new Docker container with its own Python, or use host Python?

3. Bun/Node Duplication

Node v22.22.2 on host. Node v20.19.2 + Bun 1.3.3 inside d3-tui container. Different versions, duplicated runtimes. If the game backend needs Bun (for Pi agents), it either installs its own or shares the host's.

4. No Shared Arsenal

Every container or venv is an island. No shared platform layer. Every new project reinstalls dependencies from scratch.

Proposal: Shared Platform Arsenal

Rather than per-container duplication:

/opt/pearl/
  ├── venv/              ← shared Python (langgraph, fastapi, uvicorn, requests)
  │                       Installed once. Mounted or sourced by any container/process.
  ├── runtimes/          ← Bun, Node (if needed at platform level)
  └── config/            ← game-surface configs, API key mounts

Game backend runs on host (not Docker): - Sources /opt/pearl/venv/bin/activate - LangGraph + FastAPI + uvicorn already installed there - Systemd service or tmux session for persistence - No new Docker image needed — zero additional disk footprint

Why host-level instead of new Docker container: - Python + langgraph already installed in venv (75MB, no duplication) - FastAPI HTTP bridge doesn't need container isolation — it's a dev service - Avoids building another 500MB+ Docker image with its own Python, pip installs, etc. - The existing d3-tui container stays as-is (LLM wiki + pi-teams continue working) - Forgejo stays in Docker (already working)

What stays in Docker: - from-forgejo (Git forge — needed) - d3-tui-pi-teams-proto (LLM wiki depot + pi-teams coordination — needed)

What runs on host: - LangGraph game backend (venv-based, systemd or tmux) - FastAPI HTTP bridge - Pi agent harness (Bun, installed once on host)

Archiving Current State

Before reconfiguring, capture what matters:

# 1. Archive LLM wiki (critical — inside d3-tui container)
docker cp d3-tui-pi-teams-proto:/workcell/llm-wiki /home/mehdifarah/archive/llm-wiki-$(date +%Y%m%d)

# 2. Export agent configs and prompts
docker cp d3-tui-pi-teams-proto:/home/agent/.pi /home/mehdifarah/archive/pi-agent-config-$(date +%Y%m%d)

# 3. Docker image backup (optional — only if images might be needed)
docker save d3-tui-pi-teams-proto:local | gzip > /home/mehdifarah/archive/d3-tui-image-$(date +%Y%m%d).tar.gz

# 4. Prune dangling images
docker image prune -a  # recovers ~2.5GB

What must survive: - /workcell/llm-wiki/ — the entire wiki depot (inside d3-tui container) - Forgejo repos — at /home/mehdifarah/git/ (outside containers, safe) - game-surface-venv — at /home/mehdifarah/game-surface-venv/ (on host, safe) - API keys — in d3-tui container env (document, don't lose)

Open Decisions