kimal3 0.6.5 → 0.8.0

package/skill/commands/k3plan.md

@@ -1,122 +1,107 @@
 ---
-description: Die Specs gegen den Code prüfen und die Planung in die App hochladen
+description: Die Specs gegen den Code prüfen und jede Abweichung dem Board in der App melden
 ---
 
 <!-- kimal3:erzeugt — diese Datei wird von `kimal3 skill install` gepflegt und bei
      jedem Update ueberschrieben. Eigene Aenderungen gehen dabei verloren; wer sie
      behalten will, kopiert die Datei unter einem anderen Namen. -->
-# Planung prüfen und hochladen
+# Planung prüfen und melden
 
 ## 1. Wozu
 
-Du prüfst die User Stories in den Specs dieses Projekts gegen den Code und lädst **nur das
-Ergebnis** in die App hoch — nie den Code. Dort sieht der Mensch auf der Projektseite (Reiter
-„Planung"), was offen ist, was auf seinen Test wartet und was fertig ist, und urteilt mit
-„Passt" oder „Passt nicht".
+Du prüfst die User Stories in den Specs dieses Projekts gegen den Code und **meldest jede
+Abweichung einzeln** an die App — nie den Code, und seit Fassung 0.7.0 keine ganze Datei mehr. Dort
+sieht der Mensch auf der Projektseite (Reiter „Planung", das Board), was offen ist, was auf seinen
+Test wartet und was fertig ist, und urteilt mit „Passt" oder „Passt nicht".
 
-Arbeite die Abschnitte der Reihe nach ab. Die Regeln (Abschnitt 5) und das Dateiformat
-(Abschnitt 6) brauchst du schon ab Abschnitt 2 — lies sie zuerst. Was ein Rückgabewert von
-`kimal3` heißt, steht in **`~/.claude/skills/kimal3/SKILL.md`, Abschnitt „Rückgabewerte"**;
-diese Datei wiederholt es nicht.
+Arbeite die Abschnitte der Reihe nach ab. Die Regeln (Abschnitt 5) und die Meldungen (Abschnitt 6)
+brauchst du schon ab Abschnitt 2 — lies sie zuerst. Was ein Rückgabewert von `kimal3` heißt, steht
+in **`~/.claude/skills/kimal3/SKILL.md`, Abschnitt „Rückgabewerte"**; diese Datei wiederholt es
+nicht.
 
-🔑 **`/k3plan` prüft, ordnet ein und lädt hoch — es baut nichts.** Was nachzubessern ist, steht
+🔑 **`/k3plan` prüft, ordnet ein und meldet — es baut nichts.** Was nachzubessern ist, steht
 danach als Befund an der Story; gebaut wird, wenn der Mensch es sagt.
 
-## 2. Rückmeldungen holen
+## 2. Den Stand holen
 
-Arbeite im **Projektordner** (dort, wo Specs und Code liegen). Die Datei heißt immer
-`plan/stand.json`, relativ zu diesem Ordner.
+Arbeite im **Projektordner** (ein Ordner direkt in `werkbank-…/projekte/`). Der Stand liegt in der
+App, nicht in einer Datei:
 
 ```
 kimal3 plan
 ```
 
-**Kommt `Im Ordner liegt keine plan/stand.json.`**, ist es das erste Mal (oder du stehst im
-falschen Ordner — prüf das zuerst):
-
-1. `kimal3 projekt liste` — such das Projekt, um das es hier geht. Gibt es **kein** passendes,
-   frag den Menschen, welches gemeint ist, und schlag `/k3projekt <was du gebaut hast>` vor:
-   Ohne Eintrag im Erfolgsprofil gibt es keine Projektseite. Hier aufhören, nichts erfinden.
-2. Leg `plan/stand.json` an, mit dem Namen **genau so, wie die Liste ihn schreibt**:
-
-   ```json
-   {
-     "format": 1,
-     "projekt": "LinkedIn Content-App",
-     "projekt_id": null,
-     "basis": null,
-     "geprueft_am": "2026-10-21T22:10:00+02:00",
-     "specs": [],
-     "themen": [],
-     "uebernommen": []
-   }
-   ```
-
-   (Name und Zeitpunkt sind ein Beispiel.) `projekt_id` und `basis` trägt `kimal3 plan hoch`
-   nach dem ersten Hochladen selbst ein — **lass sie bei `null`**.
-3. `kimal3 plan` noch einmal.
+**Kommt `Dieser Ordner ist noch mit keinem Projekt in der App verbunden.`**, leg das Projekt an:
+`kimal3 projekt verbinden` (der Coach, Abschnitt 3.6, sagt, was dabei zu tun ist), dann `kimal3 plan`
+noch einmal. Kommt `Hier ist kein Projektordner …`, stehst du im falschen Ordner — prüf das zuerst
+und melde nichts.
+
+**Liegt im Ordner eine `plan/stand.json`**, sag dem Menschen **einmal**: „Die Datei
+plan/stand.json wird nicht mehr gebraucht — der Stand liegt in der App. Du kannst sie löschen."
+Du löschst sie nicht selbst.
 
 **Was die Ausgabe heißt** (Beispiel, erfundene Werte):
 
 ```
+Spec 2026-09-23-content-planer · Content-Planer als Seite (plan/2026-09-23-content-planer-seite-spec.md)
+  US-1 · gebaut · Runde 1 · Beiträge anlegen
+  US-2 · in Arbeit · Runde 1 · Beiträge im Kalender verschieben
+Notiertes Thema T-3: Export als PDF
 #12 · passt nicht · 2026-09-23-content-planer / US-2 (Runde 1): Beim Ziehen springt er auf Dienstag
 #13 · Thema: Kalender soll Feiertage zeigen
 Bestätigt: 2026-09-23-content-planer / US-1 (Runde 1)
 Ansehen: https://app.kimal3.de/projekt/…
 ```
 
+- `Spec <Schlüssel> · <Titel> (<Datei>)` und darunter je Story `<Schlüssel> · <Stand> · Runde n ·
+  <Titel>` — der Stand, den die App kennt. **Die Schlüssel von hier sind bindend** (Abschnitt 3).
+- `Notiertes Thema <Schlüssel>: …` — ein Thema, das **Claude** früher notiert hat. → Regel 3.
 - `#12 · passt nicht · <Spec> / <Story> (Runde n): <Satz>` — der Mensch hat die Story getestet,
   sie hält nicht. → Regel 1 in Abschnitt 5. Die Nummer brauchst du später für `uebernommen`.
 - `#13 · Thema: <Satz>` — etwas Neues, das er in der App notiert hat. → Regel 3.
 - `Bestätigt: …` — für diese Stories hat er in **dieser** Runde „Passt" gesagt; sie sind fertig.
   Ein „Passt" musst du nicht übernehmen.
 - `Ansehen: …` — der Link zur Planung. Merk ihn dir für den Bericht.
+- `Noch keine Planung in der App.` — es ist das erste Mal; weiter mit Abschnitt 3, alle Specs sind neu.
 - `Keine offenen Rückmeldungen.` — nichts zu übernehmen; weiter mit Abschnitt 3.
 
-**Absagen:**
-- `Kein Projekt heißt „…“. Deine Projekte: … Trag den Namen in plan/stand.json genau so ein.` —
-  übernimm den passenden Namen **wörtlich** aus der Liste in `"projekt"`. Passen zwei, frag.
-- `Mehrere deiner Projekte heißen „…“ (Nummern: …).` — frag den Menschen, welches gemeint ist, und
-  trag dessen Nummer als `"projekt_id"` ein.
-- `Die Projektnummer in plan/stand.json gehört zu keinem deiner Projekte.` — die Nummer stammt aus
-  einem kopierten Ordner oder einem gelöschten Projekt. Setz `"projekt_id"` auf `null` (die Zeile
-  bleibt stehen, das Feld ist Pflicht); dann sucht kimal3 nach dem Namen. Das ist der **einzige**
-  Fall, in dem du `projekt_id` selbst änderst.
-- `Der Plan ist nicht lesbar: plan/stand.json enthält kein gültiges JSON-Objekt.` — Klammern oder
-  Kommas in der Datei reparieren.
+**Absagen** stehen als ganzer Satz auf der Fehlerausgabe (Rückgabewert `1`): Lies sie, sag dem
+Menschen, was dort steht, und wiederhole nicht blind. Meldet `kimal3 plan` `3` (App nicht
+erreichbar), versuch es einmal später noch einmal.
 
 ## 3. Specs finden
 
 Such im Projektordner in **`docs/superpowers/specs/`**, **`plan/`** und **`docs/specs/`** nach
 Markdown-Dateien mit User Stories („Als … will ich … damit …", oft `US-1`, `US-2`, mit
-Akzeptanzkriterien und Gegenprobe). `plan/stand.json` selbst, Statuszettel und Aufgabenlisten
-sind keine Specs.
+Akzeptanzkriterien und Gegenprobe). `plan/stand.json`, `plan/projekt.json`, Statuszettel und
+Aufgabenlisten sind keine Specs.
 
-Je Spec ein Eintrag in `specs`, je User Story ein Eintrag in `stories`, je Akzeptanzkriterium
-ein Eintrag in `kriterien` (kurz gefasst, höchstens 500 Zeichen: Ausgangslage → Handlung →
-Ergebnis).
+Je Spec eine Meldung `spec` mit ihren Stories, je Akzeptanzkriterium ein Eintrag in `kriterien`
+(kurz gefasst, höchstens 500 Zeichen: Ausgangslage → Handlung → Ergebnis).
 
 🔴 **Die Schlüssel sind bindend.** Die App hängt jedes „Passt" und „Passt nicht" an
-Spec-Schlüssel + Story-Schlüssel + Runde. Steht eine Spec oder Story schon in `plan/stand.json`,
-**übernimm ihren Schlüssel unverändert** — ein umbenannter Schlüssel lässt das Urteil des
-Menschen verschwinden. Neu: Spec-Schlüssel = Dateiname ohne `.md`; Story-Schlüssel = die Nummer
-aus der Spec (`US-3`); nummeriert die Spec nicht, zähl selbst `US-1`, `US-2` … in ihrer
+Spec-Schlüssel + Story-Schlüssel + Runde. Steht eine Spec oder Story schon in der Ausgabe von
+`kimal3 plan`, **übernimm ihren Schlüssel unverändert** — ein umbenannter Schlüssel lässt das
+Urteil des Menschen verschwinden. Neu: Spec-Schlüssel = Dateiname ohne `.md`; Story-Schlüssel = die
+Nummer aus der Spec (`US-3`); nummeriert die Spec nicht, zähl selbst `US-1`, `US-2` … in ihrer
 Reihenfolge.
 
-- `titel`: die Überschrift der Spec bzw. der Story. `datei`: der Pfad der Spec im Projektordner (relativ, endet auf `.md`; sonst `null`). Den **Text** der Spec
-  liest `kimal3 plan hoch` aus dieser Datei und schickt ihn mit — Pfade außerhalb des Projektordners
-  liest es nicht.
+- `titel`: die Überschrift der Spec bzw. der Story. `datei`: der Pfad der Spec im Projektordner
+  (relativ, endet auf `.md`; sonst `null`). Den **Text** der Spec lädt der Mod `kimal3-plan` beim
+  Schreiben der Datei hoch, `kimal3 plan melde` holt ihn nach, wenn die Datei vor der Meldung
+  geschrieben wurde — Pfade außerhalb des Projektordners liest es nicht.
 - Der Story-Schlüssel ist **derselbe wie in der Überschrift der Spec**, wo die Spec ihre Stories
   nummeriert (`### US-3 · …` → `US-3`): Die App findet die Story im Spec-Text über diesen Schlüssel.
 - Eine Spec ohne Stories kommt mit `"stories": []` hinein; sag es im Bericht.
 - Grenzen: höchstens 50 Specs, 60 Stories je Spec, 400 zusammen. Sind es mehr, frag den
   Menschen, welche Specs hineingehören.
+- Eine Story, die du nicht mehr in der Spec findest, **entfernst du nicht** — eine Meldung kann
+  keine Story löschen. Meld sie als `weggelassen` mit Grund, wenn die Spec das so entschieden hat.
 
-**Der Stand je Story:**
+**Der Stand je Story (`stand`):**
 - `offen` — noch nichts gebaut.
-- `in_arbeit` — teilweise gebaut, oder ein Befund ist offen. `gebaut_am` ist dann `null`.
-- `gebaut` — gebaut. `gebaut_am`: das Datum, an dem **diese Runde** fertig wurde (`JJJJ-MM-TT`);
-  dazu ein `testen`-Satz (Abschnitt 4).
+- `in_arbeit` — teilweise gebaut, oder ein Befund ist offen.
+- `gebaut` — gebaut. Das Datum setzt die App; dazu ein `testen`-Text (Abschnitt 4).
 - `weggelassen` — bewusst nicht gebaut, `grund` ist Pflicht (Regel 8). Nur, wenn die Spec oder
   der Mensch das so entschieden hat — nie von dir allein, um aufzuräumen. Im Zweifel: `offen`
   lassen und im Bericht fragen.
@@ -130,29 +115,35 @@ lesen.
 - `bestanden` — **nur**, wenn die Gegenprobe in dieser Sitzung gelaufen ist und das erwartete
   Ergebnis gezeigt hat. Nie aus dem Gedächtnis, nie vom letzten Mal, nie weil der Code „richtig
   aussieht".
-- `gescheitert` — sie ist gelaufen und hat etwas anderes gezeigt. Das ist ein Befund (Regel 1);
-  die App stellt die Story und ihre Spec damit nach „In Arbeit".
+- `gescheitert` — sie ist gelaufen und hat etwas anderes gezeigt. Das ist ein Befund (Regel 1):
+  Die Story trägt damit ⚠ und steht in „In Arbeit“, solange eine Sitzung daran arbeitet, sonst in
+  „Offen“ — ihre Spec kommt nicht nach „Dein Test“.
 - `offen` — alles, was nicht gelaufen ist: braucht einen Browser, eine Anmeldung, echte Daten
   oder einen Menschen. Lesen zählt nur, wenn das Kriterium etwas über die Datei selbst sagt (eine
   Datei gibt es, ein Text steht so da) — ein Verhalten beweist Lesen nicht.
 
-⚠️ Eine Story mit einem `offen`-Kriterium steht in „Claude-Test offen", und der Mensch kann sie
-noch nicht testen. Sag im Bericht, was fehlt, damit die Gegenprobe laufen kann.
+⚠️ Eine Story mit einem `offen`-Kriterium steht in „Claude-Test offen" — und mit ihr die ganze Spec.
+Der Mensch testet eine Spec erst als Ganzes: Knöpfe bekommt er nur, wenn an keiner Story der Spec
+mehr gebaut oder geprüft wird (die Spec steht dann in „Dein Test"). Bis dahin heißen die schon
+bestandenen Stories in der App „Von Claude geprüft". Sag im Bericht, was fehlt, damit die
+Gegenprobe laufen kann.
+
+**Der `testen`-Text** (bei jeder `gebaut`-Story, höchstens 1000 Zeichen) ist eine Anleitung für jemanden ohne Technik. Steht die Story in einer Spec mit der Kiste „So testest du es“, nimmst du ihn von dort, wörtlich; fehlt die Kiste, schreibst du ihn selbst. **Eine Zeile je Schritt** — wo man es findet, was man tut, was dann zu sehen ist —, **ohne** Kistenüberschrift, und **zuletzt** die Zeile „Passt nicht, wenn: …“. Im JSON trennst du die Zeilen mit `\n`: Ein echter Zeilenumbruch im Text bricht das JSON, und `kimal3 plan melde` liest die Meldung nicht. Ist der Text länger als 1000 Zeichen, kürze die Schritte — nie mitten im Satz abschneiden, die Zeile „Passt nicht, wenn: …“ muss am Ende stehen bleiben. Ein Befehl nur, wenn es keinen anderen Weg gibt — dann sagst du, wo man ihn eingibt (in Claude Code im Projektordner, mit `!` davor), und setzt ihn in Backticks. Fehlt der Text, zeigt die App: „Claude hat nicht aufgeschrieben, wie man das testet".
+
+**Prüfen ist Arbeit.** Bevor du eine Story mit offenen Gegenproben (Spalte „Claude-Test offen“) gegen den Code prüfst, meldest du sie als `in_arbeit` **mit** der Sitzung (also ohne `--ohne-sitzung`): Solange du prüfst, leuchtet der Punkt am Projekt. Nach der Prüfung meldest du das Ergebnis (`gebaut`, oder `in_arbeit` mit Befund). Stories in „Dein Test“ oder „Fertig“ meldest du beim Abgleich **nicht** neu, auch wenn du sie durchsiehst: `in_arbeit` und danach `gebaut` setzt ihr Baudatum auf heute, und jede Meldung zeigt das Etikett „geändert“ und bei zwei Sitzungen das ⚠ „gleichzeitig geändert“. Was am Ende von `/k3plan` unfertig bleibt, meldest du mit `--ohne-sitzung` (Abschnitt 6).
 
-**Der `testen`-Satz** (bei jeder `gebaut`-Story, höchstens 1000 Zeichen) nennt die **Adresse oder
-den Befehl** und **was dort zu sehen sein muss**, zum Beispiel: „Starte `npm run dev`, öffne
-http://localhost:3000/kalender und zieh den Beitrag vom Montag auf den Mittwoch — er steht danach
-am Mittwoch." Ohne ihn zeigt die App: „Claude hat nicht aufgeschrieben, wie man das testet".
+**Wie eine Spec aufgebaut ist.** Findest du beim Prüfen eine Spec, die nicht so gebaut ist, sag es im Bericht — du schreibst sie nicht um. Eine Story steht darin in vier Kisten: **User Story** (der Titel nennt das Ziel des Menschen) · **Akzeptanzkriterium** (mit Gegenprobe) · **So testest du es** (nummerierte Schritte, darunter „Passt nicht, wenn: …“) · **Technische Notiz**.
 
 **Befunde** (`befunde`): nur **offene**. `quelle: "claude"` für etwas, das die Story verspricht und
-nicht tut, und das kein Kriterium abdeckt. `seit`: das Datum, an dem der Befund entstand — steht
-er schon in der Datei, bleibt sein altes Datum.
+nicht tut, und das kein Kriterium abdeckt. `seit`: das Datum, an dem der Befund entstand. Ein
+`befunde`-Feld in einer Meldung **ersetzt** die Liste der Story — schick also alle noch offenen
+Befunde mit, nicht nur den neuen. Fehlt das Feld, bleibt die Liste, wie sie ist.
 
 **Die Runde** bindet ein Urteil an einen Bau-Stand — wie ein Stempel auf einer Fassung:
-- Sie beginnt bei `1` und wird **nie** kleiner.
+- Sie beginnt bei `1` und wird **nie** kleiner; fehlt `runde` in der Meldung, bleibt sie.
 - **Um genau 1 erhöhen**, wenn eine Story mit einem Befund des Menschen (`quelle: "mensch"`)
   seitdem nachgebessert wurde (Git-Verlauf, und die Gegenproben bestehen jetzt): dann
-  `befunde: []`, `stand: "gebaut"`, neues `gebaut_am`, neuer `testen`-Satz. Der Mensch testet neu.
+  `befunde: []`, `stand: "gebaut"`, `runde` + 1, neuer `testen`-Text. Der Mensch testet neu.
   Ist unklar, ob nachgebessert wurde: Befund stehen lassen und im Bericht fragen.
 - **Auch erhöhen**, wenn du eine **bestätigte** Story so geändert hast, dass der Mensch es merken
   würde — sein altes „Passt" gilt dann nicht mehr (Regel 7).
@@ -162,187 +153,150 @@ er schon in der Datei, bleibt sein altes Datum.
 
 Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planung kurz"):
 
-1. **Ein Befund ist keine neue Karte.** Hält eine Story nicht, was sie verspricht — Claudes Gegenprobe scheitert oder du sagst „Passt nicht" —, hängt der Befund an **dieser** Story, und ihre Spec geht zurück nach „In Arbeit“.
+1. **Ein Problem wird keine neue Karte.** Hält eine Story nicht, was sie verspricht — Claudes Prüfung fällt durch oder du sagst „Passt nicht" —, hängt das Problem (Befund) an **dieser** Story. Sie steht in „Offen“, bis jemand daran arbeitet.
 2. **Neu ist nur, was niemand versprochen hat. Das kommt in den Eingang, und der hat fünf Plätze.**
-3. **Claude ordnet jedes Thema beim nächsten `/k3plan` ein:** als neue Story in eine Spec, als Befund an eine Story, oder gestrichen mit Begründung. „Für später" gibt es nicht. Was daraus wurde, steht unter „Zuletzt eingeordnet".
+3. **Claude sortiert jedes Thema beim nächsten Abgleich (`/k3plan`) ein:** als neue Story in eine Spec, als Befund an eine Story, oder gestrichen mit Begründung. „Für später" gibt es nicht.
 4. **Nichts liegt länger als 14 Tage im Eingang.**
-5. **Höchstens eine Spec gleichzeitig in Arbeit** („In Arbeit“ und „Claude-Test offen“ zusammen). Erst fertig machen, dann die nächste beginnen.
+5. **Höchstens eine Spec gleichzeitig in Arbeit** („In Arbeit“ und „Claude-Test offen“ zusammen). „In Arbeit“ heißt: Eine Claude-Sitzung arbeitet gerade daran. Erst fertig machen, dann die nächste beginnen.
 6. **Höchstens fünf Stories warten auf deinen Test.** Sind es mehr, fängt Claude nichts Neues an, bis du getestet hast.
-7. **Fertig heißt zweimal geprüft:** Claudes Gegenproben bestanden, und du hast „Passt" gesagt — für genau diesen Stand.
+7. **Fertig heißt zweimal geprüft:** Claude hat alles selbst ausprobiert, und du hast „Passt" gesagt — für genau diesen Stand.
 8. **Eine Spec ist erst abgeschlossen, wenn jede Story fertig oder bewusst weggelassen ist** — mit Grund. Einen stillen Rest gibt es nicht.
 
-**Was du danach tust:**
+**Was du danach tust** (jedes Mal eine Meldung, Abschnitt 6):
 
-- **Regel 1 — jedes `passt nicht` aus `kimal3 plan`:** Gibt es die Story noch, häng den Satz des
-  Menschen als Befund an sie (`{ "text": "<sein Satz>", "quelle": "mensch", "seit": "<heute>" }`),
-  `stand: "in_arbeit"`, `gebaut_am: null`. Ist sie seitdem schon nachgebessert, stattdessen
-  Runde + 1 und `befunde: []` (Abschnitt 4). Dazu in `uebernommen`:
-  `{ "rueckmeldung": 12, "antwort": "Befund an US-2" }`. Gibt es die Story nicht mehr, sagt die
-  `antwort`, warum. ⚠️ Ohne Befund von `mensch` und ohne höhere Runde lehnt der Server das
-  Hochladen ab.
+- **Regel 1 — jedes `passt nicht` aus `kimal3 plan`:** Gibt es die Story noch, melde sie mit dem Satz
+  des Menschen als Befund (`quelle: "mensch"`, `seit: "<heute>"`) und `stand: "in_arbeit"`, und
+  gleich dahinter in derselben Liste `uebernommen` mit der Nummer: `{ "art": "uebernommen",
+  "rueckmeldung": 12, "antwort": "Befund an US-2" }`. Ist sie seitdem schon nachgebessert,
+  stattdessen `runde` + 1, `befunde: []` und `stand: "gebaut"` (Abschnitt 4). Gibt es die Story
+  nicht mehr, sagt die `antwort`, warum. ⚠️ Ohne Befund von `mensch` und ohne höhere Runde lehnt
+  die App die Übernahme ab.
 - **Regel 2 — Neues:** Was dir beim Prüfen auffällt oder der Mensch im Gespräch sagt und was
-  **keine** Spec verspricht, kommt nach `themen`:
-  `{ "schluessel": "T-1", "text": "…", "quelle": "claude" | "mensch", "seit": "<heute>" }`.
-  Nimm die nächste freie Nummer, auch über `eingeordnet` hinweg (dort bleibt ein Schlüssel
-  14 Tage belegt). Die fünf Plätze teilen sich `themen` und die offenen Notizen aus der App.
-- **Regel 3 — einordnen:** Jedes `Thema` aus `kimal3 plan` **und** jedes Thema, das schon von
-  früher in `themen` steht, ordnest du **jetzt** ein — eins von dreien:
+  **keine** Spec verspricht, meldest du als `thema`. Nimm die nächste freie Nummer (`T-4` nach
+  `T-3`) — und denk daran, dass ein eingeordnetes Thema seinen Schlüssel 14 Tage lang behält:
+  Sagt die App, ein Schlüssel komme doppelt vor, nimm die nächste Nummer. Die fünf Plätze teilen
+  sich deine Themen und die offenen Notizen aus der App.
+- **Regel 3 — einordnen:** Jedes `Thema` aus `kimal3 plan` **und** jedes `Notiertes Thema` ordnest
+  du **jetzt** ein — eins von dreien:
   - **neue Story:** schreib sie in die Spec, zu der sie gehört (User Story, Akzeptanzkriterium mit
-    Gegenprobe), und in `plan/stand.json` mit `stand: "offen"`. Passt keine Spec, frag, wohin.
-    Antwort: `neue Story US-7 in „Content-Planer“`.
+    Gegenprobe), und melde die Spec mit der neuen Story (`stand` bleibt `offen`; es genügt die
+    neue, die alten bleiben). Passt keine Spec, frag, wohin. Antwort: `neue Story US-7 in „Content-Planer“`.
   - **Befund an eine Story:** wie bei Regel 1. Antwort: `Befund an US-2 in „Content-Planer“`.
   - **gestrichen:** Antwort `gestrichen: <Grund in einem Satz>`, zum Beispiel
     `gestrichen: Feiertage stehen schon im Kalender-Werkzeug.`
 
-  Für eine Notiz aus der App gehört die Antwort als **ein Satz** in `uebernommen` (die App zeigt
-  sie unter „Zuletzt eingeordnet" als `<Notiz> → <Antwort>`); schreib sie darum **ohne** Pfeil
-  am Anfang. Ein Thema aus der Datei nimmst du aus `themen` heraus und schreibst es mit seiner
-  Antwort nach `eingeordnet`: `{ "schluessel": "T-4", "text": "<Text wie in themen>", "antwort":
-  "<ein Satz>", "am": "<heute>" }` — die App zeigt es 14 Tage lang unter „Zuletzt eingeordnet".
-  Einträge, deren `am` mehr als 14 Tage zurückliegt, nimmst du dabei heraus. Nenn die Einordnung
-  auch im Bericht.
-- **Regel 4:** Weil du bei jedem `/k3plan` alles einordnest, liegt nichts lange. Ein Thema mit
-  `seit` vor mehr als 14 Tagen ordnest du **auf jeden Fall** jetzt ein.
+  Für eine Notiz aus der App (`#13 · Thema`) gehört die Antwort als **ein Satz** in eine Meldung
+  `uebernommen`, **ohne** Pfeil am Anfang. Ein `Notiertes Thema` von dir ordnest du mit einer Meldung
+  `eingeordnet` ein (Schlüssel, Text wie oben, Antwort) — die App nimmt es aus den Themen heraus.
+  Die Seite zeigt die Antwort nicht; nenn die Einordnung deshalb im Bericht.
+- **Regel 4:** Weil du bei jedem `/k3plan` alles einordnest, liegt nichts lange. Ein Thema, das
+  schon mehr als 14 Tage liegt, ordnest du **auf jeden Fall** jetzt ein.
 - **Regel 5 und 6 — keine neue Spec beginnen**, solange eine andere Spec in Arbeit ist (eine ihrer
   Stories ist `in_arbeit`, hat einen Befund oder eine gescheiterte Gegenprobe, oder ist `gebaut`
   mit einem `offen`-Kriterium oder ganz ohne Kriterien), oder solange mehr als fünf Stories auf den Test des Menschen
-  warten (`gebaut`, alles bestanden, kein Befund, noch nicht bestätigt). **Sag dem Menschen
+  warten (`gebaut`, alles bestanden, kein Befund, noch nicht bestätigt — **und** keine Story ihrer Spec hält die Spec
+  noch in Arbeit: Nur dann steht sie in „Dein Test", und nur dann zählt die App die Story). **Sag dem Menschen
   stattdessen, was er testen soll** — mit den `testen`-Sätzen. Ordnest du ein Thema als neue Story
   in eine Spec ein, beginnst du sie damit nicht: Sie steht `offen`, und die Spec gilt nicht als in
   Arbeit.
-- **Regel 7:** „Fertig" setzt nur der Mensch mit „Passt" in der App; in der Datei gibt es dafür kein
+- **Regel 7:** „Fertig" setzt nur der Mensch mit „Passt" in der App; eine Meldung hat dafür kein
   Feld. Du hältst nur die Runde stabil (Abschnitt 4).
 - **Regel 8:** `weggelassen` nur mit `grund` (Abschnitt 3).
 
-## 6. Die Datei
+## 6. Die Meldungen
 
-`plan/stand.json` steht unter Git. Beispiel, gekürzt:
+Jede Meldung ist ein JSON-Objekt, mehrere eine Liste. Sie geht über die Eingabe an
+`kimal3 plan melde`; das Programm setzt die Zeit selbst, das Projekt kommt vom Ordnerzettel
+`plan/projekt.json`. Prüfen ist Arbeit — mit der Sitzung gemeldet leuchtet auf dem Board der Punkt, solange du prüfst.
 
-```json
-{
-  "format": 1,
-  "projekt": "LinkedIn Content-App",
-  "projekt_id": null,
-  "basis": null,
-  "geprueft_am": "2026-10-21T22:10:00+02:00",
-  "specs": [
-    {
-      "schluessel": "2026-09-23-content-planer",
-      "titel": "Content-Planer als Seite",
-      "datei": "plan/2026-09-23-content-planer-seite-spec.md",
-      "stories": [
-        {
-          "schluessel": "US-2",
-          "titel": "Beiträge im Kalender verschieben",
-          "stand": "gebaut",
-          "runde": 1,
-          "gebaut_am": "2026-10-21",
-          "kriterien": [
-            { "text": "Beitrag vom Montag auf Mittwoch ziehen → steht am Mittwoch", "gegenprobe": "bestanden" }
-          ],
-          "befunde": [],
-          "testen": "Öffne /kalender, zieh den Beitrag vom Montag auf den Mittwoch.",
-          "grund": null
-        }
-      ]
-    }
-  ],
-  "themen": [
-    { "schluessel": "T-1", "text": "Kalender soll Feiertage zeigen", "quelle": "mensch", "seit": "2026-10-21" }
-  ],
-  "uebernommen": [
-    { "rueckmeldung": 12, "antwort": "Befund an US-2" }
-  ],
-  "eingeordnet": [
-    { "schluessel": "T-2", "text": "Export als PDF", "antwort": "gestrichen: Der Drucken-Knopf kann das schon.", "am": "2026-10-21" }
-  ]
-}
+```
+echo '[ … ]' | kimal3 plan melde
 ```
 
-**Die Felder** — jedes muss da sein, auch wenn es `null` oder leer ist (nur `eingeordnet` darf
-fehlen); ein unbekanntes Feld (ein Tippfehler wie `"befund"`) lehnt der Server ab:
-
-- `format`: genau `1`.
-- `projekt`: der Name wie in der App, 1–200 Zeichen.
-- `projekt_id`, `basis`: am Anfang `null`; danach schreibt sie `kimal3 plan hoch` — **nie von Hand
-  ändern**. Einzige Ausnahme: die Absage „Die Projektnummer in plan/stand.json gehört zu keinem
-  deiner Projekte." — dann `projekt_id` auf `null` setzen (Abschnitt 2).
-- `geprueft_am`: jetzt, mit Zeitzone (`date +%Y-%m-%dT%H:%M:%S%:z` in der Bash, `Get-Date -Format
-  "yyyy-MM-ddTHH:mm:sszzz"` in PowerShell).
-- `specs[]`: `schluessel` (eindeutig, 1–80 Zeichen), `titel` (1–200), `datei` (Pfad oder `null`),
-  `stories[]`.
-- `stories[]`: `schluessel` (eindeutig in ihrer Spec), `titel`, `stand` (`offen` · `in_arbeit` ·
-  `gebaut` · `weggelassen`), `runde` (1–999), `gebaut_am` (`JJJJ-MM-TT` bei `gebaut`, sonst
-  `null`), `kriterien[]`, `befunde[]`, `testen` (Satz oder `null`), `grund` (Pflicht bei
-  `weggelassen`, sonst `null`).
-- `kriterien[]`: `{ "text", "gegenprobe": "bestanden" | "gescheitert" | "offen" }`, höchstens 30
-  je Story.
-- `befunde[]`: `{ "text", "quelle": "claude" | "mensch", "seit": "JJJJ-MM-TT" }` — nur offene,
-  höchstens 20.
-- `themen[]`: `{ "schluessel", "text", "quelle", "seit" }`, höchstens 50 (der Eingang hat fünf
-  Plätze, Regel 2).
-- `uebernommen[]`: `{ "rueckmeldung": <Nummer aus kimal3 plan>, "antwort": "<ein Satz>" }`. Leert
-  `kimal3 plan hoch` nach dem Hochladen selbst.
-- `eingeordnet[]`: `{ "schluessel", "text", "antwort": "<ein Satz>", "am": "JJJJ-MM-TT" }`, höchstens
-  50 — Themen aus `themen`, die du eingeordnet hast (Regel 3). Ein Schlüssel steht nie zugleich in
-  `themen` und `eingeordnet`.
-- Die ganze Datei: höchstens 300 KB.
-
-## 7. Hochladen
-
-Erst der Probelauf — er prüft alles und speichert nichts:
+(In PowerShell: `'[ … ]' | kimal3 plan melde`. Lange Texte lieber über eine Datei.) Die Beispiele
+sind erfunden.
 
+**Ganz am Ende** meldest du die Stories, die unfertig bleiben (in Arbeit, Befund offen), noch einmal —
+in einem **eigenen** Aufruf mit `--ohne-sitzung`, getrennt von der Liste der fertigen: Eine gemischte
+Liste ohne den Schalter bindet auch die unfertige Story an die Sitzung, und der Punkt leuchtet weiter.
+Mit dem Schalter bleibt der Plan-Stand `in_arbeit`, aber der Punkt leuchtet nicht weiter, während das
+Fenster offen bleibt — auf dem Board steht die Story dann in „Offen“ als angefangen.
+
+```
+echo '[ … ]' | kimal3 plan melde --ohne-sitzung
 ```
-kimal3 plan hoch --probe
+
+**Eine Spec** — beim Prüfen und wenn Stories dazukommen:
+
+```json
+{ "art": "spec", "schluessel": "2026-10-24-testmonat", "titel": "Testmonat",
+  "datei": "docs/superpowers/specs/2026-10-24-testmonat-design.md",
+  "stories": [ { "schluessel": "US-1", "titel": "Der Testmonat startet" },
+               { "schluessel": "US-2", "titel": "Der Testmonat endet" },
+               { "schluessel": "US-3", "titel": "Export des Testmonats" } ] }
 ```
 
-`Probelauf: würde 9 Stories hochladen, 2 Rückmeldungen als übernommen melden. Gespeichert wurde
-nichts.` (Zahlen als Beispiel.) **Vergleich die zweite Zahl** mit den offenen Rückmeldungen aus
-`kimal3 plan`: Ist sie kleiner, hast du eine vergessen — sie bliebe in der App unter „Wartet auf
-Claude".
+**Eine Story** — eine Abweichung, ein Eintrag. Gebaut, mit Gegenprobe:
 
-Dann:
+```json
+{ "art": "story", "spec": "2026-10-24-testmonat", "story": "US-1", "stand": "gebaut",
+  "kriterien": [ { "text": "Startet Sabine am 1.11., endet der Testmonat am 30.11.", "gegenprobe": "bestanden" } ],
+  "testen": "1. Öffne in der App ‚Testmonat‘.\n2. Klick „Starten“.\n3. Darunter steht ‚Endet am 30.11.‘.\nPasst nicht, wenn: dort ein anderes Datum steht." }
+```
+
+Mit einem offenen Befund (hier von dir; `quelle: "mensch"` nur für den Satz des Menschen):
 
+```json
+{ "art": "story", "spec": "2026-10-24-testmonat", "story": "US-2", "stand": "in_arbeit",
+  "befunde": [ { "text": "Am 30.11. fehlt die Erinnerungsmail, die die Spec verspricht.", "quelle": "claude", "seit": "2026-10-23" } ] }
 ```
-kimal3 plan hoch
+
+Bewusst weggelassen (`grund` ist Pflicht):
+
+```json
+{ "art": "story", "spec": "2026-10-24-testmonat", "story": "US-3", "stand": "weggelassen", "grund": "Die Spec streicht den Export." }
 ```
 
-Geklappt hat es bei `✓ Planung für „…“ hochgeladen: … Stories, … warten auf deinen Test.` und
-`Ansehen: …`; beim ersten Mal zusätzlich `projekt_id und basis stehen jetzt in plan/stand.json.`
-Die CLI hat `projekt_id` und `basis` eingetragen und `uebernommen` geleert — lass die Datei so.
-Sag dem Menschen, dass `plan/stand.json` geändert ist und in den nächsten Commit gehört.
+**Ein Thema** (Regel 2), **ein Thema von dir einordnen** (Regel 3), **eine Rückmeldung des Menschen
+übernehmen** (Regel 1 und 3):
+
+```json
+{ "art": "thema", "schluessel": "T-4", "text": "Der Kalender könnte Feiertage zeigen" }
+{ "art": "eingeordnet", "schluessel": "T-3", "text": "Export als PDF", "antwort": "gestrichen: Der Drucken-Knopf kann das schon." }
+{ "art": "uebernommen", "rueckmeldung": 12, "antwort": "Befund an US-2" }
+```
 
-Danach steht eine Zeile `Spec-Texte hochgeladen: 1 von 3. Ohne Text: …` — der Text der Specs geht mit hoch.
-Eine Spec ohne Text ist ein **Hinweis, kein Fehlschlag** (Rückgabewert `0`): Nenn dem Menschen die
-Specs, die in der Klammer stehen, und was zu tun ist (Pfad in `datei` berichtigen; über 300 KB
-lässt sich nicht hochladen; bei „alle Spec-Texte zusammen größer als 4 MB" ist keine Datei allein
-zu groß — die größten bleiben draußen, bis der Rest passt).
+**Was das Programm zurückgibt:** Bei Erfolg schweigt es (`0`) — und **du auch**: Sag dem Menschen
+nicht, dass du gemeldet hast. `1` — die App hat abgesagt oder die Eingabe war unlesbar; der Satz
+auf der Fehlerausgabe sagt warum. Meldungen, die er nicht nennt, sind angekommen. `3` — die App
+ist nicht erreichbar; die Meldung ist **gemerkt** und geht beim nächsten Befehl mit
+(`kimal3 plan senden` schickt sie sofort) — nicht noch einmal schicken. `2` — nicht mehr
+angemeldet: Sag dem Menschen `kimal3 login`; die Meldung ist gemerkt.
 
-**Absagen — die Meldung lesen, beheben, Probelauf, noch einmal:**
+**Absagen — die Meldung lesen, beheben, noch einmal:**
 
 | Meldung beginnt mit | Was du tust |
 |---|---|
-| `Der Plan ist nicht lesbar: <Ort> …` | Die Stelle (`specs[0].stories[2].stand`) in der Datei reparieren. |
-| `Kein Projekt heißt …` · `Mehrere deiner Projekte heißen …` · `Die Projektnummer in plan/stand.json gehört zu keinem deiner Projekte.` | Wie in Abschnitt 2. Bei der Projektnummer darfst du `projekt_id` auf `null` setzen — nur hier. |
-| `<Spec> / <Story> hat Runde 1, gespeichert ist schon Runde 2.` | Die Datei ist älter als der gespeicherte Stand. Runde auf den gespeicherten Wert setzen — nie kleiner. |
+| `Die Meldung zu <Story> von <Uhrzeit> kam zu spät an …` | Eine andere Sitzung oder der Mensch hat die Story danach geändert. **Nicht erneut senden.** `kimal3 plan` zeigt den heutigen Stand; melde nur, was dann noch fehlt. |
+| `Die Spec … gibt es in diesem Projekt noch nicht.` · `… hat keine Story …` | Melde zuerst die Spec mit ihren Stories (Abschnitt 6, „Eine Spec"), dann die Story. |
+| `Meldung Nr. 2 ist nicht lesbar (meldung).` | Die Meldung hat ein falsches Feld oder fehlt eines — gegen die Beispiele oben halten. Geschickt wurde nichts. |
+| `<Spec> / <Story> hat Runde 1, gespeichert ist schon Runde 2.` | Deine Runde ist älter als die gespeicherte. Mit der gespeicherten oder höher noch einmal — nie kleiner. |
 | `Rückmeldung 12 gibt es in diesem Projekt nicht oder steht zweimal …` | Nur Nummern aus `kimal3 plan`, jede einmal. |
-| `Rückmeldung 12 („…“) ist als übernommen gemeldet, aber US-2 hat keinen Befund von dir …` | Den Befund mit `quelle: "mensch"` an die Story hängen (Regel 1) — oder Runde + 1, wenn nachgebessert ist. |
-| `In der App liegt ein neuerer Plan (hochgeladen …).` | Eine andere Arbeitskopie hat hochgeladen. **Nicht überschreiben.** Sag es dem Menschen und frag, ob ihr deren Stand erst holt (Git) und neu prüft. `kimal3 plan hoch --ueberschreiben` **nur nach seinem ausdrücklichen Ja.** |
-| `Die gespeicherte Planung in der App ist beschädigt …` | Auch hier `--ueberschreiben` **nur nach seinem Ja.** |
-| `Die Planung ist gespeichert, aber die Rückmeldungen sind noch nicht als übernommen markiert.` | `kimal3 plan hoch` **unverändert** noch einmal — das ist harmlos, die CLI hat `basis` schon nachgetragen und `uebernommen` stehen lassen. |
-| ``Die Planung ist gespeichert, aber die Spec-Texte nicht. Führ `kimal3 plan hoch` noch einmal aus.`` | `kimal3 plan hoch` **unverändert** noch einmal — der Plan steht schon in der App, die CLI hat `basis` nachgetragen. |
-| `⚠ Die Planung ist gespeichert, aber plan/stand.json ließ sich nicht nachtragen. Trag selbst ein: …` | Genau diese Werte in die Datei schreiben. |
-| `… ließ sich gerade nicht laden` / `… nicht speichern` | Einmal wiederholen; klappt es dann nicht, dem Menschen sagen. |
+| `Rückmeldung 12 („…“) ist als übernommen gemeldet, aber US-2 hat keinen Befund von dir …` | Erst die Story mit dem Befund `quelle: "mensch"` melden (Regel 1) — oder `runde` + 1, wenn nachgebessert ist — dann `uebernommen`. |
+| `Der Plan ist nicht lesbar: <Ort> …` | Die genannte Stelle der Meldung berichtigen (Länge, `grund` bei `weggelassen`, doppelter Schlüssel). |
+| `Die Meldung ist angekommen, der Text von <Datei> aber nicht …` | Die Meldung noch einmal schicken — doppelt schadet nicht. Passt der Text nicht mehr (über 300 KB), sag es dem Menschen. |
+| `Die Meldungen sind gespeichert, aber noch nicht ganz vermerkt.` | Noch einmal schicken — doppelt schadet nicht. |
+| `Die gespeicherte Planung in der App ist beschädigt …` | Sag es dem Menschen. `kimal3 plan hoch --ueberschreiben` ersetzt die Planung durch eine ganze Datei `plan/stand.json` — **nur nach seinem ausdrücklichen Ja.** |
 
-🔴 **`--ueberschreiben` ersetzt, was ein anderer hochgeladen hat.** Nie aus eigenem Entschluss,
-auch nicht, wenn die Meldung es vorschlägt.
+🔴 **`--ueberschreiben` ersetzt, was andere gemeldet haben.** Nie aus eigenem Entschluss, auch
+nicht, wenn die Meldung es vorschlägt.
 
-## 8. Dem Menschen berichten
+## 7. Dem Menschen berichten
 
-**Höchstens fünf Zeilen**, ohne Fachjargon:
+**Höchstens fünf Zeilen**, ohne Fachjargon — und nichts über die Meldungen selbst:
 
 - was **fertig** wurde (seit dem letzten Mal bestätigt),
-- was **auf seinen Test wartet** — mit dem `testen`-Satz, damit er gleich loslegen kann,
+- was **auf seinen Test wartet** (nur Stories aus Specs in „Dein Test") — mit dem `testen`-Text, damit er gleich loslegen kann,
 - was im **Eingang** entschieden wurde (jedes Thema mit seiner Antwort),
 - eine **Warnung**, wenn Regel 5 oder 6 verletzt ist: „Teste zuerst …" statt einer neuen Story,
 - der **Link** aus `Ansehen: …`.