Projektmanagement & Ticketsystem für Silverscale

Recherche (Stand 2026-06-10): Wie wandern Backlog + Roadmap aus den Markdown-Dateien (app/ios-native/BACKLOG.md + ROADMAP.md, kuratiert über /groom) in ein echtes Projektmanagement mit visueller Roadmap und Tickets mit mehr State — ohne den wichtigsten Hebel zu verlieren: dass die KI-Agenten (MacClaude/StratoClaude) die Tickets programmatisch lesen UND schreiben können. Interface-Präferenz ist ausdrücklich etwas Besseres als MCP: bewertet wird primär nach CLI-Ergonomie und/oder per curl nutzbarer HTTP-API.

Kurz-Fazit / Empfehlung

Empfehlung: Plane (self-hosted, Docker), bedient von den Agenten ausschließlich über die REST-API per curl — plus ein dünner pm.sh-Wrapper im Stil von app/bus.sh.

Plane ist 2026 das einzige Tool im Feld, das alle vier harten Anforderungen gleichzeitig erfüllt: (1) echte visuelle Roadmap (Timeline/Cycles/Boards), (2) Tickets mit viel State (Status-Workflow, Custom Properties für Owner/Welle/ADR-Refs, Kommentare, Verlinkungen), (3) datensouverän self-hosted unter Docker/Traefik mit identischer API wie die Cloud, und (4) eine schlanke, gleichförmige REST-API (X-API-Key-Header, JSON, vorhersehbare Resource-URLs), die ein LLM-Agent ohne MCP-Server-Lifecycle direkt per curl bedient.

So arbeitet der Agent als Konsument + Producer (Self-hosted-Basis-URL = https://pm.dennisfisch.de, Token in der .env):

# ENV einmalig: PLANE=https://pm.dennisfisch.de  WS=silverscale  PROJ=<project_id>
H=(-H "X-API-Key: $PLANE_API_KEY" -H "Content-Type: application/json")

# LESEN — offene Tickets der MacClaude-Welle als JSON ziehen
curl -s "${H[@]}" \
  "$PLANE/api/v1/workspaces/$WS/projects/$PROJ/work-items/?state__group=unstarted" | jq '.results[].name'

# ANLEGEN — neues Ticket (entspricht einem B-NN-Harvest)
curl -s "${H[@]}" -X POST \
  "$PLANE/api/v1/workspaces/$WS/projects/$PROJ/work-items/" \
  -d '{"name":"Pin-Semantik: gepinnt + low Signal → unsicher vorschlagen","priority":"none"}'

# STATUS SETZEN — Ticket auf „in Arbeit" / „erledigt"
curl -s "${H[@]}" -X PATCH \
  "$PLANE/api/v1/workspaces/$WS/projects/$PROJ/work-items/$ID/" \
  -d '{"state":"<state_id_in_arbeit>"}'

# KOMMENTIEREN — Handoff-Notiz / Befund ans Ticket hängen (statt flüchtigem Handoff-Doc)
curl -s "${H[@]}" -X POST \
  "$PLANE/api/v1/workspaces/$WS/projects/$PROJ/work-items/$ID/comments/" \
  -d '{"comment_html":"<p>Gerätetest phase-5: 8✓/5🐞, Crash gefixt 72bf08c</p>"}'

Damit lebt der State im Ticketsystem statt in flüchtigen Handoff-Docs — genau das, was die Zwei-Sessions-Übergabe heute schwer macht. Der /groom-Skill bleibt als Sync-/Harvest-Skript relevant (Quellen scannen → Tickets anlegen/abhaken), Prio-Hoheit bleibt bei Dennis.

Wenn der visuelle Roadmap-Anspruch nachgibt und maximale Agent-Ergonomie + minimaler Footprint zählen: Vikunja ist die leichtgewichtige Alternative (ein einziges Go-Binary, Board/Gantt, sauberer JWT-Bearer-REST). Vikunjas CLI taugt aber NICHT für Ticketpflege (nur Migrationen/Admin) — Agenten müssen ohnehin über die REST-API. Plane gewinnt durch die deutlich reichere Roadmap-/State-Modellierung; Vikunja durch Ein-Personen-Wartbarkeit.

Vergleichstabelle

Bewertung gegen die Briefing-Dimensionen. „CLI/curl-Agent-Eignung" ist die Leitspalte.

⭐ = Empfehlung.

Warum CLI / HTTP-API > MCP für diesen Zweck

Dennis' Präferenz „etwas Besseres als MCP" ist hier technisch gut begründet — gerade für ein Zwei-Sessions-Agenten-Setup, das ohnehin schon auf curl-Endpoints (Agent-Bus) baut:

1. Determinismus & Reproduzierbarkeit. Ein curl … -X PATCH … -d '{"state":…}' ist ein exakt protokollierbarer, wiederholbarer Aufruf — copy-paste-bar in Skripte, Cron, Skills. MCP-Tool-Calls sind serverseitig vermittelt und je nach Server-Version/Tool-Schema wechselhaft.
2. Kein MCP-Server-Lifecycle. MCP heißt: ein weiterer Prozess, den man starten, beobachten, neu starten und versionieren muss — pro Session. Beide Sessions (MacClaude über WireGuard, StratoClaude lokal) sprechen dagegen schon heute direkt HTTP gegen den VPS (/api/bus*). Ein PM-Endpoint reiht sich nahtlos ein, null neue Laufzeit.
3. Skriptbarkeit & Komposition. curl | jq lässt sich frei mit Bash, dem /groom-Skill und app/bus.sh verketten (z. B. „alle offenen MacClaude-Tickets → Bus-Nachricht"). MCP-Tools komponieren nicht über die Shell.
4. Debugbarkeit. Fehlersuche an einem HTTP-Call ist transparent (Statuscode, JSON-Body, -v). MCP fügt eine Indirektion (Tool-Layer + Transport) ein, die im Fehlerfall verschleiert.
5. Token-/Kontext-Ökonomie. Ein dünner pm.sh-Wrapper (analog linearis' discover-then-act: wenige Subcommands, JSON-Out) hält die genutzte Oberfläche klein — statt ein fettes MCP-Tool-Schema in jeden Kontext zu laden. Das passt zur Compact-Disziplin des Projekts.
6. Least-Privilege-Auth wie beim Bus. Plane-X-API-Key (bzw. Vikunja-JWT) ist ein scoped Token in der .env — dasselbe Muster wie BUS_TOKEN/INTERNAL_API_TOKEN. Kein neues Auth-Modell.

MCP ist nicht falsch — Plane/Linear/GitLab haben MCP-Server. Aber für agentische Pflege in diesem self-hosted, skript-getriebenen Setup ist die HTTP-API der robustere, billigere, determinischere Draht. Die MCP-Option bleibt als Bonus erhalten, falls je gewünscht.

Migrationsskizze: Markdown-Backlog → Tickets

Der bestehende Backlog ist bereits stark strukturiert (Tabelle mit ID·Titel·Bereich·WAF· Aufwand·Prio·Status·Ref) — das mappt fast 1:1 auf Plane-Felder.

Feld-Mapping (B-NN-Tabelle → Plane-Work-Item):

Now/Next/Later (ROADMAP.md): als Module oder Custom Property bucket abbilden — Dennis pflegt sie weiter, der visuelle Timeline-View ersetzt die handgeschriebene Erzählung. „Bewusst vertagt (+Warum)" → State vertagt + Kommentar mit Begründung.

Bulk-Import-Ansatz: Einmaliges Python-Skript (backend-Stil, requests/curl): Markdown-Tabelle parsen → je Zeile POST …/work-items/ + Custom-Property-Values setzen + backlog_id schreiben. ~60 Items → wenige Minuten. Idempotent über backlog_id (vorher GET + Abgleich), damit ein Re-Run nicht dupliziert — dasselbe Idempotenz-Prinzip wie der Bon-Import.

Was aus /groom wird: Der Skill bleibt, wandelt sich aber vom MD-Editor zum Sync-/Harvest-Skript: - Quellen-Harvest unverändert (61/62-Rekonstruktion, Handoffs, Spec-§-Tabellen, Code-TODOs). - Statt Edit auf zwei MD-Dateien: Diff gegen die Plane-Tickets (per API ziehen) → neue Items POSTen, Erledigtes per PATCH state abhaken, Refs in Description nachziehen, Dubletten per backlog_id mergen. - Eiserne Regel bleibt: Prio + Now/Next/Later = Dennis; Kurator schlägt nur vor (z. B. als Kommentar/Vorschlags-Label, nie priority setzen). - Vorteil: kein git add/pull --rebase/index.lock-Tanz mehr für Backlog-Pflege — der Commit-Lärm und das Rebase-Ping-Pong (genau der Schmerz, der schon zum Agent-Bus führte) entfallen für Backlog/Roadmap komplett. Git bleibt nur für echten Code.

Self-Host-/Deploy-Skizze (Plane)

Stack: Plane liefert ein Docker-Compose-Bundle (~13 Services: API, Web, Worker/Beat, Postgres, Redis/Valkey, MinIO, interner Proxy). Footprint: 4 GB RAM min., 8 GB empfohlen — das ist der größte Posten dieser Entscheidung und auf dem geteilten VPS einzuplanen.

Traefik-Anbindung (Muster wie der restliche Stack): - Eigene Subdomain pm.dennisfisch.de, Let's-Encrypt via vorhandenem Cloudflare-DNS-01. - Plane-internen Proxy hinter Traefik hängen; Container-Ports nur auf 127.0.0.1 + WireGuard (MacClaude erreicht die API über den bekannten WG-Fallback, analog Bus). - Postgres/MinIO nicht öffentlich; Plane-Data in die bestehende Backup-Rotation aufnehmen (Postgres-Dump + MinIO; Valkey braucht kein Backup).

SSO: Plane unterstützt OIDC — die Pocket ID (id.silverscale.dennisfisch.de) kann als OIDC-Provider andocken, dann ein Login für App + PM. Für die Agenten ist SSO irrelevant: sie nutzen den X-API-Key-Token (scoped, in der Repo-.env, niemals committen — gleiche Regel wie LIDL_REFRESH_TOKEN/Bus-Token).

Aufwand (grob): - Compose hochziehen + Traefik-Labels + Subdomain: ~0,5 Tag. - States/Labels/Custom-Properties anlegen + API-Token: ~0,5 Tag. - Bulk-Import-Skript (MD→Tickets, idempotent): ~0,5–1 Tag. - /groom zum Sync-Skript umbauen + pm.sh-Wrapper: ~1 Tag. - Summe ~2,5–3 Tage, danach läuft die Backlog-Pflege agentisch.

Risiken / Stolperfallen: - RAM-Druck auf dem geteilten VPS — Plane ist das Schwergewicht; vorher Speicher prüfen. (Vikunja als Sparvariante mit ~1 Go-Binary, falls der VPS eng wird.) - Migrations-/Upgrade-Disziplin bei einem 13-Container-Open-Core-Stack: Updates testen, Backups vor Major-Upgrades. Self-hosted Plane hinkt der Cloud bei einzelnen API-Features teils hinterher (z. B. waren Pages-Endpoints zeitweise nicht im self-hosted REST exponiert — vor Verlass auf ein Feature kurz gegen die laufende Instanz testen). - Webhooks zu Private-IPs: self-hosted Plane verlangt für Webhook-Targets erreichbare, nicht-localhost-URLs — falls man Plane→Bus-Webhooks will, über die WG-/interne IP planen. - Zwei Wahrheiten vermeiden: Während der Migration NICHT parallel MD und Tickets pflegen. Cut-over planen; MD-Dateien danach als „eingefroren, siehe Plane" markieren (oder das Import-Skript bleibt als Re-Hydration-Pfad). - backlog_id-Stabilität: Plane-Item-IDs ≠ B-NN. Alle Code-/Doc-/Bus-Referenzen auf B-NN müssen weiter über das Custom Field auflösbar bleiben.

Quellen (Abruf 2026-06-10)

• Plane — Self-Hosting-Übersicht: https://developers.plane.so/self-hosting/overview
• Plane — API-Referenz/Einführung (X-API-Key, Work-Items, States, Comments, Custom Properties): https://developers.plane.so/api-reference/introduction
• Plane — Self-Hosting 101 / Architektur: https://developers.plane.so/self-hosting/self-hosting-101
• Plane — Webhooks: https://developers.plane.so/dev-tools/intro-webhooks
• Plane — „Pages API nicht im self-hosted REST exponiert" (Issue #8986): https://github.com/makeplane/plane/issues/8986
• Plane — Self-Hosting Docker-Compose Resource-Bedarf (selfhosting.sh): https://selfhosting.sh/apps/plane/
• Plane — Top-6-Open-Source-PM 2026 (Marktüberblick): https://plane.so/blog/top-6-open-source-project-management-software-in-2026
• Vikunja — Projektseite / Self-Host: https://vikunja.io/
• Vikunja — CLI (Admin/Migration, NICHT Task-Pflege): https://vikunja.io/docs/cli/
• Vikunja — Installing (Single-Binary): https://vikunja.io/docs/installing/
• Vikunja — GitHub (REST-API, Importer): https://github.com/go-vikunja/vikunja
• Linear — Developers (GraphQL-first, MCP, Agent-Support): https://linear.app/developers
• linearis — Linear-CLI für LLM-Agenten (discover-then-act, JSON, Token-Sparsamkeit): https://github.com/czottmann/linearis · https://zottmann.org/2025/09/03/linearis-my-linear-cli-built.html
• Huly — Self-Host (CockroachDB/Elasticsearch/Redpanda/MinIO, 8–16 GB RAM): https://docs.huly.io/getting-started/self-host/ · https://github.com/hcengineering/huly-selfhost
• GitLab — Issues-API (curl, PRIVATE-TOKEN): https://docs.gitlab.com/api/issues/
• GitLab — glab-CLI: https://docs.gitlab.com/cli/
• GitLab — Epics/Roadmap (Ultimate-Tier): https://docs.gitlab.com/user/group/epics/
• Leantime — API (JSON-RPC, transaktional): https://docs.leantime.io/api/usage · https://github.com/Leantime/leantime
• Marktüberblick Self-Hosted PM 2026: https://uibakery.io/blog/self-hosted-project-management-software · https://super-productivity.com/blog/open-source-productivity-apps-comparison/

Recherche-Stand 2026-06-10. Empfehlung: Plane self-hosted, von den Agenten per curl/REST bedient (kein MCP-Lifecycle), /groom als Sync-Skript. Prio + Now/Next/Later bleiben Dennis' Hoheit. Footprint (Plane ~8 GB RAM) ist der entscheidende Trade-off gegen die leichtere Vikunja-Alternative.