Files
matrix-bridge/ROADMAP.md
T
Keysat 78e0de2e52 Scaffold matrix-bridge (standards-compliant; pre-Phase 0)
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).
2026-06-14 20:20:17 -05:00

48 lines
2.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 12) 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.