# Intent: Intent-Detail-Modal und Übergangs-Guardrails im Board

## Ziel

Zwei zusammengehörige Verbesserungen am Board-Web-UI
(`hosts/blunix/localServices/board-agent/`):

1. Der Intent-Inhalt einer Karte (`docs/intent/<slug>.md`) soll beim
   Kartenklick lesbar sein, unabhängig davon, in welcher Spalte die Karte
   gerade steht.
2. Vorwärts-Übergänge zwischen Spalten, die eine oder mehrere
   Pipeline-Stufen überspringen, sollen serverseitig abgelehnt werden statt
   unkommentiert durchzugehen.

## Umfang / Auftrag an den Builder

- In `trigger.py`: einen neuen Endpoint `GET /api/board/cards/<id>/intent`
  ergänzen, analog zum bestehenden Review-Endpoint
  (`GET /api/board/cards/<id>/review`). Er liest den Inhalt der Datei unter
  dem `intent_path` der Karte und liefert ihn als Text/Markdown zurück.
  404, wenn die Karte keinen `intent_path` hat oder die Datei fehlt.
- In `board.html`: einen Klick-Handler für **jede** Karte mit
  `source === "intent"` ergänzen (aktuell bekommen nur `has-review`-Karten
  einen Handler). Der Klick öffnet ein eigenes `<dialog>`-Modal, das den
  Inhalt von `GET .../intent` in einem `<pre>`-Block anzeigt — analog zum
  bestehenden `showReview()`-Mechanismus, aber ein eigenständiges Modal.
  Keine Vermischung mit dem Review-Dialog; der bleibt unverändert und zeigt
  weiterhin ausschließlich den Review-Inhalt.
- In `trigger.py`'s `PATCH /api/board/cards/<id>`-Handler: die erlaubte
  Vorwärtsfolge der Spalten ist
  `idea → geplant → in_umsetzung → review → {bereit_fuer_deployment | planung_mit_feedback} → deployed`.
  Ein Vorwärts-Sprung, der eine oder mehrere Stufen dieser Folge
  überspringt (z. B. `geplant → deployed` direkt), wird mit HTTP 409
  abgelehnt — gleiches Muster wie der bereits bestehende
  `geplant → in_umsetzung`-Doppel-Trigger-Guard. Rückwärts-Bewegungen (in
  dieser Folge nach hinten, in beliebigem Abstand) bleiben uneingeschränkt
  erlaubt, ohne Guard. `bereit_fuer_deployment → deployed` und
  `planung_mit_feedback → geplant` bleiben wie bisher reine Buchhaltung
  ohne Seiteneffekt (kein Auto-Deploy, kein Auto-Re-Enqueue).
- `test_board_agent.py`: Tests für den neuen Endpoint sowie für die neuen
  Guard-Fälle ergänzen (mindestens: ein erlaubter Vorwärtsschritt, ein
  abgelehnter übersprungener Vorwärtsschritt, ein erlaubter
  Rückwärtsschritt).

## Ausgeschlossen

- Kein gemeinsames Modal für Intent- und Review-Inhalt, kein Tab-Umbau des
  bestehenden Review-Dialogs.
- Kein Markdown-Rendering zu HTML — reiner `<pre>`-Text wie beim
  bestehenden Review-Dialog.
- Kein automatisches Re-Enqueue eines Builder-Jobs beim Rework-Loop;
  `planung_mit_feedback → geplant → in_umsetzung` bleibt zwei manuelle
  Schritte.
- Kein Auto-Deploy-Trigger bei `→ deployed`.
- Keine Einführung von `docs/board/<slug>.yaml` — State bleibt in
  `BOARD_STATE_FILE`/`state.json`, wie im bestehenden Phase-1-Scope
  festgelegt.

## Annahmen

- Die erlaubte Vorwärtsfolge ist eindeutig aus der bestehenden `COLUMNS`-
  Reihenfolge in `board.html` ableitbar.
- `bereit_fuer_deployment` und `planung_mit_feedback` gelten beide
  gleichermaßen als gültige Nachfolger von `review` und als gültige
  Vorgänger von `deployed` (nur `bereit_fuer_deployment` führt praktisch
  weiter zu `deployed`, `planung_mit_feedback` führt zurück).
- Rückwärts-Bewegungen brauchen keinen Guard, weil sie schon heute
  uneingeschränkt funktionieren und keine Seiteneffekte auslösen.

## Offene Risiken

- Die Guard-Logik ist eine hartcodierte Reihenfolge, kein generisches
  State-Machine-Konfigurationsobjekt. Kommen künftig weitere Spalten/Phasen
  hinzu, muss diese Logik von Hand mitgepflegt werden — bewusster
  Trade-off gegen eine generischere, aber für den aktuellen Umfang
  überdimensionierte Lösung.

## Erfolgskriterien

- Klick auf eine beliebige Intent-Karte, in jeder Spalte, öffnet ein Modal
  mit dem aktuellen Inhalt ihrer `docs/intent/<slug>.md`.
- Ein Drag, der eine Pipeline-Stufe überspringt, wird mit 409 abgelehnt,
  die Karte bleibt in ihrer bisherigen Spalte.
- Bestehende und neue Tests in `test_board_agent.py` sind grün.
- Dieser Intent dient zugleich als Pipeline-Test: Nach dem Schreiben
  dieser Datei wird die Karte manuell durch `geplant → in_umsetzung`
  gezogen, um den bestehenden, durch diese Änderung unberührten
  Builder-Übergang end-to-end zu validieren. Diese Karte wird als erste
  von drei zusammengehörigen Karten (siehe
  `docs/intent/planner-precise-package-removal-scope.md` und
  `docs/intent/reviewer-scale-depth-to-risk.md`) durch die Pipeline
  gezogen.