Keysat
78e0de2e52
Single-user Matrix -> Claude Code bridge bot, scaffolded from a prior scoping package (SPEC/DECISIONS/CLAUDE/KICKOFF) folded into the current new-project scheme: - AGENTS.md (canonical) with core flow, stack, placement table, condensed D1-D10 decisions, sovereignty constraint, and Phase 0 as the first milestone - CLAUDE.md -> AGENTS.md relative symlink; ROADMAP.md (Phases 1-4+, falsifiable exits) - scripts/launch-claude.sh first-draft Mac wrapper (D4); config.example.toml - canonical deny-by-default .gitignore + Python ignores No bot code yet, by design: Phase 0 is manual-chain validation (N=3).
2.3 KiB
2.3 KiB
ROADMAP — matrix-bridge
Phased build plan. Near-term status lives in AGENTS.md → ## Current state; this file is
the longer arc. Substance threshold is N = 3 real uses per phase — exits are falsifiable
(it worked 3 real times), never checkboxes.
Phase 0 (the current first milestone) lives in AGENTS.md ## Current state; it writes no
bot code — foundation + proving the manual chain by hand. The phases below are what comes
after it.
Phase 1 — Single-room bot
- matrix-nio bot in a container on the Spark, logged in as a bot Matrix user.
- One hardcoded room → one repo. Any message in it spawns a session via the Mac wrapper.
- Exit (falsifiable): 3 consecutive real messages each correctly launch a drivable session on the phone.
Phase 2 — Multi-room routing
- Room → repo mapping table; the bot routes by
room_id(config over code). - Exit (falsifiable): 3 real uses across ≥2 rooms, correct repo every time, zero wrong-directory launches.
Phase 3 — Spark Control integration
- Bot container status surfaced on the Spark Control dashboard.
- One-click update (pull + restart) wired the same way Spark Control drives the Sparks today (SSH/commands behind a button).
- Exit (falsifiable): bot status is visible and the bot can be updated/restarted from the panel.
Phase 4+ — Future direction (documented, not yet scoped to build)
- Intent-routing brain (D8). Qwen3 via Spark Control as a smart dispatcher: given knowledge of all repos/contexts, parse a freeform message and decide which repo/context applies and what context to inject — not a task-vs-session classifier. MUST run on a local model. Depends on the deterministic core (Phases 1–2) working first; the architecture must not foreclose it.
- Thread-based session continuity. A Matrix thread = a distinct session/sub-context within a repo. The first natural extension after multi-room routing.
- Nextcloud / CalDAV output integration. Routing Claude/bot outputs into Nextcloud (Matrix ↔ Claude ↔ Nextcloud). Real interest, unscoped — not until Nextcloud Tasks/CalDAV is actually in use.
- E2EE (D9). Add matrix-nio end-to-end encryption (libolm) if the bot ever handles sensitive content over untrusted transport. Low priority while everything is WireGuard-local.