Claude (Werkstatt PC)
e1ca7f6a5e
Entscheid nach Probe (Hermes-first): Dispatcher im Gateway, Specifier (triage -> sauberer Auftrag), Profil-Routing und Artefakt-Tracking sind nativ E2E bewiesen — kein Eigenbau. Auftragsbuch bleibt das Klick-Gate. - backend services/ideen.py + routers/ideen.py: MC2-Tuer zur Queue (GET /api/ideen, POST /api/ideen -> kanban create --triage, Archiv) - AuftragsbuchView: Ideen-Queue-Sektion (Eingabefeld + Status-Liste), dist frisch gebaut - mcp_voice.py: idee_notieren (Lucys Sprech-Leitung, Prompt-Diaet: 1 Tool) - chef-gutachter-feed.sh: Morgenlage bekommt kanban stats + Bewegung - Bagatell-Pfad: bagatell-annahme.sh + mc2-bagatell.timer (04:10) — NUR .md-Anlagen/-AEnderungen, max 2/Nacht, gleicher Annahme-Runner mit Health-Gate + Auto-Revert, Chronik/Telegram-Meldung - werkstatt-SOUL.md: Leitplanken des Kanban-Worker-Profils (propose-only, nie main, nie Live-Checkout) — deploy.sh zieht sie kuenftig nach Box-live heute schon (ausserhalb Repo, mit Backups): toolsets+kanban, platform_toolsets.telegram+kanban, SOUL.md-Ideen-Regel, Profil werkstatt (model.default=coder), Gateway neu gestartet + E2E-Tuer-Test gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
75 lines
4.1 KiB
Markdown
75 lines
4.1 KiB
Markdown
# Auftragsbuch — die Vorschlags-Inbox der Box
|
|
|
|
Das Auftragsbuch ist das Mensch-Gate des propose-only-Kreislaufs als Klick statt
|
|
Git-Handarbeit: alles, was die Box von allein baut oder sich ausdenkt, landet hier
|
|
als Karte — du entscheidest mit **Annehmen** oder **Ablehnen**.
|
|
|
|
## Die Ideen-Queue davor (natives Hermes-Kanban, seit 10.07.2026)
|
|
|
|
Vor dem Auftragsbuch liegt DIE eine Ideen-Queue: das native Hermes-Kanban
|
|
(`hermes kanban`, SQLite-Board, Dispatcher läuft im Gateway). Der Weg einer Idee:
|
|
|
|
1. **Idee rein — Tür egal:** Eingabefeld im Auftragsbuch-Tab (`POST /api/ideen`),
|
|
Telegram/Desktop (natives Tool `kanban_create`, Regel in SOUL.md) oder Lucys
|
|
Sprech-Leitung (`idee_notieren` in `mcp/mcp_voice.py`). Alles landet als
|
|
`triage`-Aufgabe auf demselben Board.
|
|
2. **Die Box arbeitet sie aus:** der Kanban-Specifier macht aus der rohen Idee
|
|
einen sauberen Auftrag und wählt das Worker-Profil (Routing über die
|
|
Profil-Beschreibungen: Code → `werkstatt` [Qwen3-Coder-Next, Leitplanken in
|
|
`deploy/werkstatt-SOUL.md`], Doku/Analyse → `default`).
|
|
3. **Der Worker baut** im isolierten Workspace; Code-Ergebnisse pusht er als
|
|
Vorschlags-Branch auf Gitea — der hier als Karte erscheint. **Das Gate bleibt
|
|
dein Klick.**
|
|
|
|
Die Queue-Sicht im Tab (Status, offene Ideen) kommt aus `hermes kanban list --json`
|
|
(`backend/services/ideen.py`); die Morgenlage bekommt `kanban stats` als
|
|
Beweismaterial. Entscheid nativ-vs-Eigenbau (Hermes-first): Probe 10.07.2026 —
|
|
Dispatcher, Specifier, Profil-Modellwahl und Artefakt-Tracking sind nativ E2E
|
|
bewiesen; ein Eigenbau hätte all das nur nachgebaut.
|
|
|
|
## Woher die Karten kommen
|
|
|
|
- **Fertige Patches** — Branches auf Gitea (`wartung/*`, `orchestrator/*`, `doku/*`,
|
|
`feature/*`), wie die Werkstatt und der Orchestrator sie hinterlassen. Die Karte
|
|
zeigt Commit-Botschaft, geänderte Dateien und den vollen Diff.
|
|
- **Skill-Kandidaten** — Ideen des nächtlichen Traum-Crons aus dem Wissens-Vault
|
|
(`~/wissens-vault/skill-kandidaten/`). „Beauftragen" schickt sie als Auftrag an
|
|
die Werkstatt (Orchestrator-Skill); das Ergebnis kommt als neuer Patch zurück.
|
|
|
|
## Was „Annehmen" bei einem Patch macht (deploy/auftrag-annehmen.sh)
|
|
|
|
1. Merge des Branches in einem **isolierten Worktree** (Live-Checkout bleibt unberührt).
|
|
2. `py_compile`-Gate über die geänderten Python-Dateien.
|
|
3. Push nach `main` auf Gitea (mit Retry).
|
|
4. Deploy (als /tmp-Kopie von deploy.sh — Selbst-Reset-Falle) — die Zentrale
|
|
startet dabei kurz neu.
|
|
5. Health-Check mit Geduld. **Rot ⇒ automatischer Revert des Merges + Redeploy +
|
|
Alarm.** Grün ⇒ Branch wird aufgeräumt, Meldung an Telegram + Chronik.
|
|
|
|
Der Lauf ist eine eigene systemd-Unit (detached) — er überlebt den Neustart des
|
|
Backends, das ihn gestartet hat. Fortschritt steht live auf der Karte
|
|
(`/srv/models/mc2-auftragsbuch.json`).
|
|
|
|
## Bagatellen ohne Klick (mc2-bagatell.timer, 04:10)
|
|
|
|
Einzige Ausnahme vom Klick-Gate (User-Entscheid 10.07.2026, bewusst eng geschnitten):
|
|
`deploy/bagatell-annahme.sh` spielt nachts Vorschlags-Branches ein, deren Diff
|
|
**ausschließlich `.md`-Dateien anlegt oder ändert** — keine Code-Zeile, keine
|
|
Löschungen, keine Renames, keine Skripte. Der Weg ist derselbe Annahme-Runner wie
|
|
beim Klick (Merge → Gate → Deploy → Health → Auto-Revert), maximal 2 pro Nacht und
|
|
nur Branches ohne vorherige Fehl-Läufe. Fangnetz: Nacht-Sicherung 03:30 liegt davor,
|
|
jede Annahme steht in Chronik + Telegram, die Morgenlage 04:30 berichtet. Die Klasse
|
|
erweitert nur der Commander, nie das Skript.
|
|
|
|
## Leitplanken
|
|
|
|
- Propose-only bleibt: **keine Code-Zeile geht ohne Klick live.** Das Gate ist dieses
|
|
Buch; einzige Ausnahme sind die eng geschnittenen Doku-Bagatellen (oben).
|
|
- „Frontend ohne Build"-Warnung: die Box kann kein Frontend bauen (kein Node) —
|
|
enthält ein Branch `frontend/src` ohne frisches `frontend/dist`, bleibt die
|
|
Oberfläche nach dem Annehmen alt, bis am PC gebaut wird.
|
|
- Ablehnen löscht nur den Remote-Branch; die Historie auf Gitea bleibt.
|
|
|
|
Diese Datei kam übrigens selbst über das Auftragsbuch ins Repo — als erste echte
|
|
End-to-End-Annahme (Probe-Branch `wartung/annahme-probe`, 08.07.2026).
|