feature-tracker-mcp

Ein projektunabhängiger Feature- und Entscheidungs-Tracker, gebaut für den Fall, dass eine Person mehrere KI-Codierungssitzungen gleichzeitig steuert und zum Engpass geworden ist.

Das Problem, das er löst, ist nicht „Features verfolgen". Es ist: Du hast mehrere Stränge in Arbeit, jede Sitzung ist blind gegenüber den anderen, Entscheidungen tauchen ständig auf, und alles zu lesen ist der Job. Die meisten dieser Entscheidungen sind banal und delegierbar. Einige wenige sind wirklich deine. Heute gibt es keinen Mechanismus, der sie trennt, also liest du alles.

Das ist der Mechanismus.

Inhaltsverzeichnis

• Rollen

• Was heute existiert

• Die Form

• Verben

• Modi

• Das Rückgrat: eine Datenbank pro Projekt

• Kategorien

• Gates: die Genehmigungswarteschlange

• Zählungen und Konvergenz

• Abbruchbedingungen

• Checkpoints, Pausieren und Zusammenfassungen

• Warum das nicht in git ist

• Was es brechen wird

• Build-Reihenfolge

Rollen

Der Sinn der Aufteilung ist, dass die zweite Zeile derzeit der Job des Menschen ist und fast nichts davon es sein muss.

Die Form

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

Zwei Eigenschaften leisten die Arbeit: Die Datenbank ist der Zustand, also hängt nichts davon ab, dass ein Modell sich erinnert; und Gates blockieren, also ist „ja, mach weiter" ein Mechanismus und keine Nachricht, bei der du anwesend sein musstest, um sie zu erwischen.

Was heute existiert

Ehrliche Aufteilung, weil der Rest dieses Dokuments ein System spezifiziert, das nur teilweise gebaut ist.

Funktioniert jetzt — 8 MCP-Tools, Ende-zu-Ende gegen eine echte Datenbank verifiziert:

Spezifiziert, aber nicht gebaut: jeder Slash-Befehl im nächsten Abschnitt, kontinuierliche Erfassung, die Ausführungsschleife und der Generator, der den Markdown-Tracker aus der Datenbank zurückrendert.

Gegen ein echtes Projekt verifiziert. 75 Features aus einem bestehenden 387-zeiligen Markdown-Tracker importiert, wobei jede ID erhalten blieb — DIP-16, GLG-1, UA-11 und der Rest lösen weiterhin auf, weil sie in Commit-Nachrichten und Worktree-Namen zitiert werden und eine Neuzuweisung diese Geschichte verwaist lassen würde. Kategorie-Zähler wurden über die höchste importierte ID hinaus erhöht, sodass nichts bereits Verwendetes erneut vergeben werden kann.

Verben

Jedes ist eine Fähigkeit, also auch ein Slash-Befehl. Keines davon ist bisher gebaut — sie sind die beabsichtigte Oberfläche über den obigen Tools.

/standup, /tracker-table und /gates sind schreibgeschützt und verbrauchen nie einen Arbeitszug.

Modi

Ideation. Ein Dialog, dessen Nebenprodukt ein gefüllter Backlog ist. Während Features erfunden werden, werden sie sofort in die Datenbank vorgeschlagen, jedes wird dir zum Zustimmen oder Ändern präsentiert — nichts landet still. So wird die Warteschlange gefüllt.

Ausführung. Die Features einer Kategorie werden nacheinander in Prioritätsreihenfolge zum Abschluss getrieben. ChatGPT wählt das nächste Element aus, brieft die Codierungssitzung, prüft, was zurückkommt, und akzeptiert es entweder oder schickt es erneut durch.

Kontinuierliche Erfassung. Der banale Teil und der Grund, warum die Liste wahr bleibt. Jeder substanzielle Zug — in jeder Sitzung — wird daraufhin untersucht, was er implizierte: eine neue Tabelle, eine Leitplanke, eine CHECK-Einschränkung, ein Risiko, das entschärft werden muss, ein Unter-Feature, das niemand benannt hat. Jedes wird zu einer vorgeschlagenen Zeile. Die Alternative ist, was heute passiert: Es wird einmal erwähnt, scrollt weg und wird später teuer wiederentdeckt.

Die Erfassung läuft bei Zügen, die Dateien geändert oder eine Schlussfolgerung erreicht haben. Die meisten Züge implizieren nichts, und sie bei allen laufen zu lassen, ist der Weg zu einem Backlog, den niemand liest.

Das Rückgrat: eine Datenbank pro Projekt

Jedes Projekt erhält seine eigene Postgres-Datenbank, die bei der ersten Nutzung erstellt und nach dem git-Remote des Projekts benannt wird (damit jeder Worktree und jeder Klon desselben Projekts sich auf denselben Tracker einigen).

kind ist eines von feature, guardrail, schema, risk, mitigation. status läuft proposed → agreed → in_progress → done oder dropped.

IDs werden atomar von der Datenbank vergeben. Das ist kein Detail — es ist die Lösung für eine echte, wiederkehrende Klasse von Bugs. Zwei Sitzungen, die unabhängig eine Datei lesen, die nächste freie Nummer sehen und beide nehmen, erzeugen doppelte Migrations-016s und kollidierende Issue-Nummern. Ein Zähler, der innerhalb einer Transaktion erhöht wird, macht das strukturell unmöglich.

Jedes Ereignis protokolliert den git-Commit, Branch und Baum. Ein Feature, das gegen einen Commit vorgeschlagen wurde, der seitdem umgeschrieben wurde, ist eine andere Behauptung als eines, das gegen HEAD vorgeschlagen wurde, und ohne den Stempel kann später niemand den Unterschied erkennen.

Kategorien

Kategorien ersetzen die informelle Vorstellung eines „Strangs" und werden generiert, während Features protokolliert werden, statt im Voraus konfiguriert zu werden. Ein Feature unter einer neuen Kategorie vorzuschlagen, erstellt sie mit eigenem ID-Präfix und Zähler — damit DIP-17 und GLG-1 koexistieren, ohne zu kollidieren oder zentral verwaltet zu werden.

Gates: die Genehmigungswarteschlange

Ein Gate ist eine Entscheidung, die die Arbeitssitzungen nicht allein treffen dürfen.

Ein Gate zu stellen, blockiert die Sitzung, die es gestellt hat. Gates warten an einem Ort, du genehmigst, änderst oder lehnst ab, und die Sitzung wird fortgesetzt. Das verwandelt „das kostet 40 $, bist du damit einverstanden?" von einer Nachricht, auf die du hättest achten müssen, in ein Warteschlangenelement, das wartet.

Zählungen und Konvergenz

Fortschritt wird als zwei Bewegungen gemeldet, nie als Verhältnis:

3/14  ->  5/16     +2 agreed, +2 surfaced

Der Zähler ist Konsens und misst Konvergenz. Dass der Nenner wächst, ist gesund — neue Elemente bedeuten, dass echte Meinungsverschiedenheiten gefunden wurden, die die ganze Zeit da waren, unausgesprochen.

Ein Prozentsatz kehrt das um. 12/16 -> 12/20 liest sich als 75% -> 60%, ein Rückgang, wenn nichts regressiert ist und zwei echte Probleme benannt wurden. Ein einzelnes Verhältnis bestraft genau das Verhalten, das das System erzeugen soll, also wird es nie gezeigt.

Abbruchbedingungen

Festgefahren wird allein am Zähler beurteilt. Elemente, die auftauchen, während nichts vereinbart wird, ist Kreisen, und das als Fortschritt zu melden, ist der einfachste Weg, einen Nachmittag zu verlieren.

Checkpoints, Pausieren und Zusammenfassungen

Alle zwei Züge stoppt die Schleife und meldet:

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

Du kannst jederzeit Pause sagen und die Zusammenfassung sofort erhalten, ohne auf den Checkpoint zu warten. Nichts läuft unbeaufsichtigt länger, als du erlaubst — Autonomie beginnt bei zwei Zügen und verlängert sich nur, sobald sie sie verdient hat.

Warum das nicht in git ist

Der Tracker war zuvor eine Markdown-Datei. In einer jüngsten Woche brauchte es 115 Commits von parallelen Worktrees, und die Geschichte enthält manuell aufgelöste Nummerierungskollisionen. Eine einzelne Datei unter Versionskontrolle ist bereits ein Konfliktpunkt bei menschlichen Schreibraten; das Hinzufügen automatisierter Schreibvorgänge pro Zug aus mehreren Sitzungen würde sie unbrauchbar machen.

Also ist die Datenbank kanonisch und das Markdown wird generierte Ausgabe, bei Bedarf neu generiert und von der Versionskontrolle ausgeschlossen.

Die bewusst zu akzeptierende Konsequenz: Die Git-Historie war das Audit-Protokoll. feature_event ersetzt sie – nur anhängbar, mit Akteur und Commit gestempelt – und dieser Ersatz ist eine Anforderung, keine Nettigkeit. Andernfalls tauscht man Merge-Konflikte gegen Amnesie.

Jede projektweite Anweisung, die die Markdown-Datei als kanonisch benennt, muss in derselben Änderung umgeschrieben werden. Sitzungen befolgen diese Anweisungen; lässt man eine davon auf die alte Datei zeigen, schreiben sie weiterhin in etwas, das niemand liest.

Was es zerstört

Vorschlags-Spam. Die Erfassung pro Runde über mehrere Tracks hinweg kann Hunderte von Zeilen mit geringem Wert erzeugen – und dann liest man einen Backlog statt Transkripte, dasselbe Problem in anderer Kleidung. Die Messlatte ist explizit: Festgehalten wird nur, was sonst verloren ginge, was umsetzbar ist und was nicht bereits abgedeckt ist. Deduplizierung ist Pflicht, denn zwei Sitzungen, die unabhängig voneinander dieselbe fehlende Einschränkung bemerken, sind der Normalfall, nicht der Ausnahmefall.

Den falschen Baum lesen. Ein Worktree ist ein separater Checkout. Weist man eine Sitzung auf den falschen, meldet sie Ihre Dateien als fehlend und Ihre Änderungen als nicht vorhanden – mit voller Überzeugung, und das liest sich wie ein Befund über den Code statt wie eine Fehlkonfiguration. Jede Operation protokolliert den Baum, den sie gelesen hat, sodass die Abweichung sichtbar wird, bevor jemand danach handelt.

Ein Manager, der berichtet statt rechnet. Zählungen werden aus der Datenbank berechnet und können nicht beredt über etwas sein, das nicht existiert. Von einem Modell geschriebene Zusammenfassungen können es sehr wohl. Wo die beiden auseinandergehen, gewinnt die Tabelle.

Autonomie, die der Aufmerksamkeit davonläuft. Sich verstärkende Fehler werden am schnellsten teuer, wenn niemand liest. Gates und Checkpoints existieren genau dafür, und das Standardintervall ist bewusst kurz.

Build-Reihenfolge

1. category, feature, feature_event, gate; projektbezogene Datenbankerstellung; atomare ID-Vergabe

2. MCP-Tools: propose, list, update, table, history, gate raise/list/decide

3. Kontinuierliche Erfassung, mit der Messlatte und Deduplizierung, plus die Agree-or-Alter-Review-Warteschlange

4. /standup über alle Tracks hinweg, einschließlich nicht committeter Arbeit – Commits allein zeigen nicht, wo die Arbeit tatsächlich steht

5. Gates, die Sitzungen blockieren

6. /ideate

7. Ausführungsschleife, die eine Kategorie in Prioritätsreihenfolge zum Abschluss bringt