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

ROADMAP.md

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