Front Office

Design-Ops-System der Aufzeichnungen für Projekte, die im Dialog mit KI entwickelt werden: Entscheidungsprotokolle, offene Fragen und Dokumentation als generierte Ansichten – damit jede Sitzung (menschlich oder KI, heute oder in Monaten, parallel oder sequenziell) auf demselben Wissensstand arbeitet, statt auf Chat-Verläufen.

Entstanden aus einem realen Problem: Bei der Entwicklung eines Spiels über lange KI-Sitzungen hinweg entstanden 46 protokollierte Entscheidungen, und die Frage „Wurde das eigentlich jemals genehmigt?“ erforderte ständig eine Prüfung. Front Office macht den Prüfpfad zum primären Artefakt.

Kernideen

• Das Entscheidungsprotokoll ist ein Ereignisprotokoll. Jede Entscheidung trägt wann / wer / warum, ein Herkunfts-Tag – [A] explizite menschliche Entscheidung · [A→C] menschliche Vorgabe, KI-Spezifikation · [C→A] KI-Vorschlag, menschlich ratifiziert · [C] KI-Annahme, gültig bis auf Widerspruch – sowie einen Status (✅ entschieden · 🕐 dokumentationsausstehend · 💬 vorgeschlagen). Korrekturen sind neue Einträge, die auf alte verweisen, keine Bearbeitungen.

• Offene Fragen sind Aufzeichnungen, kein Scrollback. Unbeantwortete Punkte bleiben in einer nachverfolgten Datei, bis sie geklärt sind – mit einem Protokolleintrag.

• Dokumentation ist ein Build-Artefakt. Kontextpakete und Statusansichten werden aus den Aufzeichnungen generiert; Markdown ist das Speicher- und Austauschformat, sodass keine Abhängigkeit entsteht – die Dateien sind auch ohne Werkzeuge nutzbar.

• Die Reiterklausel. Ein Vorschlag, der an eine genehmigte Entscheidung angehängt ist, erbt deren Genehmigung nicht. Von KI verfasste Entwürfe sind immer 💬.

Related MCP server: kb

Verwendung

npm ci
npm run fo -- status                 # counts, unratified [C] list, pending rulings
npm run fo -- decisions --provenance C --status decided
npm run fo -- open --section A
npm run fo -- show 12
npm run fo -- pack                   # writes projects/<p>/context-pack.md
npm run fo -- validate               # CI-able: exit 1 on invariant violations

Projektdaten liegen in projects/<name>/ mit *decision-log.md und *open-items.md (Format siehe test/fixtures/). projects/ ist in .gitignore – die Mandantendaten gehören dir und bleiben privat. Ein anderes Verzeichnis lässt sich mit --project <dir> oder FO_PROJECT_DIR angeben.

Web-UI

npm run fo -- pack   # optional: regenerate views first
npm run web          # http://localhost:4747 (FO_PORT / FO_PROJECT_DIR to override)

Live-Dashboard über dieselben Dateien: Entscheidungs-Feed mit Herkunfts- und Status-Filtern, Aufmerksamkeitsleiste (ausstehende Entscheidungen, nicht ratifizierte [C]), offene Fragen nach Bereich, Statistiken – sowie ein Entwurfsformular (Entwürfe sind immer 💬). 100% UI/Logik-Trennung: Der Client enthält keinerlei Geschäftslogik; jeder abgeleitete Wert kommt vorberechnet von /api/state, der Browser rendert nur und sendet Befehle.

MCP-Server (die Gehirn-Anbindung)

Die Aufzeichnungen für jede Claude-Code-Sitzung bereitstellen:

claude mcp add front-office --scope user -- npx tsx <repo>/src/mcp/server.ts

Werkzeuge: get_context_pack · list_decisions · list_open_items · draft_decision (immer 💬) · get_stats. Mit FO_PROJECT_DIR in der Server-Umgebung wird das Projekt ausgewählt.

Architektur

Gemäß der eigenen Doktrin des Projekts (ja, auch deren Designentscheidungen sind im Front-Office-Protokoll festgehalten):

• src/core, src/adapters, src/views – rein (strenges funktionales ESLint-Profil: kein let, keine Schleifen, keine Mutation; Uhren und Zufall müssen injiziert werden).

• src/shell, src/mcp – die Effektgrenze (moderates Profil).

• Parser übernehmen Rohzellen unverändert → Serialisierung ist verlustfrei umkehrbar (parse(serialize(parse(x))) ≡ parse(x), eigenschaftsbasiert getestet).

npm run typecheck && npm run lint && npm test

MIT.