releases/ClaudeDo
2
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 12 Wiki Activity

docs: park mailbox proposal; skip architecture.md and ADRs

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
mika kuns
2026-06-04 11:45:52 +02:00
parent 2dfa9956c5
commit 0a0d7e8551
2 changed files with 11 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/mailbox-proposal.md
View File

@@ -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

13
docs/open.md
View File

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