From 0a0d7e8551297107cdbf3a62373792cec11dd68d Mon Sep 17 00:00:00 2001 From: mika kuns Date: Thu, 4 Jun 2026 11:45:52 +0200 Subject: [PATCH] docs: park mailbox proposal; skip architecture.md and ADRs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The generic Claude-Mailbox plugin already covers cross-session messaging, so the ClaudeDo-internal integration is parked. architecture.md and ADRs are deliberately skipped — per-project CLAUDE.md files are the living architecture doc, and ADRs add little for a solo project. Co-Authored-By: Claude Opus 4.7 --- docs/mailbox-proposal.md | 6 +++++- docs/open.md | 13 ++++++------- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/docs/mailbox-proposal.md b/docs/mailbox-proposal.md index 8c62c02..5656692 100644 --- a/docs/mailbox-proposal.md +++ b/docs/mailbox-proposal.md @@ -1,6 +1,10 @@ # Task Mailbox — Push Messages Into Running Sessions -**Status:** proposal +**Status:** PARKED (2026-06-04) — not building this. +**Why parked:** The generic Claude-Mailbox plugin (the `mcp__mailbox__*` tools used in normal sessions) already covers the core need — cross-session messaging, inbox checks, a sender — at the harness level for any project. Integrating it directly into ClaudeDo (task/worktree-scoped inboxes, per-worktree CLAUDE.md + hook seeding, UI badges, `send_to_peer`) is a sizable build (migration + MCP tools + SignalR + UI + hooks) for marginal gain over the plugin. Revisit only if the generic plugin proves insufficient for the parallel-session workflow. The original proposal is kept below for reference. + +--- + **Context:** the user runs parallel Claude sessions (e.g. backend + frontend) and wants to push messages into a session while it's busy inside a subagent. A shared folder works for one-offs; this turns it into a first-class ClaudeDo feature so every future parallel-session project gets it for free. ## Problem diff --git a/docs/open.md b/docs/open.md index 9166009..828a45d 100644 --- a/docs/open.md +++ b/docs/open.md @@ -162,15 +162,14 @@ Voraussetzung: Gitea-Release unter `git.kuns.dev/releases/ClaudeDo` mit `ClaudeD ### 6.1 README.md ✅ - Existiert mit Inhalt (Projektbeschreibung, Architektur, Zwei-Prozess-SignalR-Modell). -### 6.2 docs/architecture.md ⬜ -- Existiert nicht. Architektur lebt verstreut in `plan.md`, README und den Projekt-CLAUDE.md-Dateien. Entweder konsolidieren oder bewusst nicht ausgliedern. +### 6.2 docs/architecture.md ⛔ (bewusst nicht ausgegliedert) +- Entscheidung 2026-06-04: Die per-Projekt `CLAUDE.md`-Dateien sind bereits die lebende Architektur-Doku (detailliert + aktuell). Ein separates `architecture.md` würde duplizieren und veralten. Kein Mehrwert für ein Solo-Projekt. -### 6.3 ADRs ⬜ -- Kein `docs/adr/` o.ä. Vorschläge: „SignalR vs. SQLite-Polling für IPC", „Worktree pro Task", „TaskStateService als alleiniger State-Owner", „BlockedByTaskId statt Status='Waiting'", „External MCP als zweite WebApplication". -- **Aufwand:** klein, hilfreich für später. +### 6.3 ADRs ⛔ (bewusst nicht angelegt) +- Entscheidung 2026-06-04: ADRs lohnen sich primär für Teams, die das „Warum" früherer Entscheidungen rekonstruieren müssen. Solo-Projekt, Entscheidungen sind dem Autor präsent — nicht den Churn wert. -### 6.4 Mailbox-Proposal ⬜ (Entscheidung offen) -- `docs/mailbox-proposal.md` existiert weiter; **keine** Implementierung in `src/` (Grep nach „mailbox" → 0 Treffer). Entscheiden: bauen, droppen oder parken. Wenn droppen → Datei entfernen. +### 6.4 Mailbox-Proposal ✅ GEPARKT (2026-06-04) +- Entscheidung getroffen: **parken, nicht bauen.** Das generische Claude-Mailbox-Plugin (`mcp__mailbox__*`) deckt den Cross-Session-Bedarf bereits ab; die ClaudeDo-interne Integration wäre ein großer Build für marginalen Mehrwert. `docs/mailbox-proposal.md` trägt jetzt einen `Status: PARKED`-Header mit Begründung; Proposal bleibt als Referenz erhalten. ---