kimal3 0.7.0 → 0.9.0

package/coach/en/kimal3-coach.md

@@ -88,7 +88,12 @@ use them instead of starting off too quickly.
 
 ### 3.3 Planning, now concretely
 - What exactly is built, in which steps, how each step is checked. For bigger things in writing: a spec,
-  that is a plan with user stories ("As … I want … so that …") and a counter-check per criterion.
+  that is a plan with user stories. Every story sits in four boxes, always in this order:
+  **User story** ("As … I want … so that …"; the title names the person's goal, not the result) ·
+  **Acceptance criterion** (four lines: *X has …* · *X does …* · *Then …must …* · *Counter-check: …* — a criterion that
+  cannot fail is none) · **How you test it** (numbered steps for someone without technical knowledge: where, what to do, what
+  appears; below them the line "Doesn't work if: …"; a command only with its place, in backticks) · **Technical note**
+  (where the thing lives, what carries it — the person need not read it). Real numbers, real text, a name instead of "the user".
 - **An approved plan justifies nothing that fresh measurements refute.** Never "the plan says this is
   acceptable" as a reason — answer anew: *What is the best thing, given what I know NOW?* If it
   differs: say so out loud, update the plan.
@@ -143,20 +148,40 @@ The board in the app shows only what you report: if you don't, it shows "Open" f
   If it creates a project, you pass on the **one** sentence it prints ("I created the project '…' in the app.").
   If two projects have the same name, or it was deleted in the app, it asks: ask the person and never choose yourself; `--new`
   only after their yes. If the success profile is missing, say the sentence once, keep working and report nothing.
-- **You report at six moments**, each time with `kimal3 plan report` (input: one report as JSON or a list,
+- **You report at seven moments**, each time with `kimal3 plan report` (input: one report as JSON or a list,
   e.g. `echo '[…]' | kimal3 plan report`; the program sets time and session). You read the keys of spec and story from the app
   with `kimal3 plan` — don't invent them.
-  1. **A spec is created or its stories change:**
-     `{"art":"spec","schluessel":"2026-10-24-test-month","titel":"Test month","datei":"docs/superpowers/specs/2026-10-24-test-month-design.md","stories":[{"schluessel":"US-1","titel":"The test month starts"}]}`
-  2. **The build of a spec begins:** the stories being built now go to "in progress" — **before** you take the first build step or
+  1. **A spec comes into being or its stories change:** you report a new spec **as soon as the person says a spec should be
+     written** (or agrees to your suggestion of one) — before the first question back, before the first written sentence, even
+     without stories. The key is the file name it will get, without `.md`. When you hand it to the person to read (after your own
+     review rounds), you report it with its stories and `"wartet_auf_lesen":true` — the card then shows "Waiting for you to
+     read". If they say it works, you report it with `"wartet_auf_lesen":false`; if they say what doesn't work, the label stays
+     until you have revised it and they say it works. If you revise it after "works" so that they have to read it again, you set
+     it again. 🔑 **A spec is one card:** no side cards like "Write spec: …" or "Build plan: …", neither as a spec nor as a topic.
+     `{"art":"spec","schluessel":"2026-10-24-test-month-design","titel":"Test month","datei":"docs/superpowers/specs/2026-10-24-test-month-design.md","stories":[]}`
+     `{"art":"spec","schluessel":"2026-10-24-test-month-design","titel":"Test month","datei":"docs/superpowers/specs/2026-10-24-test-month-design.md","stories":[{"schluessel":"US-1","titel":"The test month starts"}],"wartet_auf_lesen":true}`
+  2. **The topic in the chat is a spec** (the person talks about one, or you are creating one): whenever the topic switches to
+     another spec, not with every message; when in doubt, report — sending twice does no harm. The card then shows "In
+     discussion". For a new spec, both in one list, the spec first. If the person says in the chat that they are done with it,
+     you report the end with `"spec":null` and always name the spec you were discussing in `"war"` — if the person has clicked
+     another card in the meantime, your report then doesn't end that card's discussion. Always with the session, so without
+     `--no-session`. If the app says "Another chat is discussing this card right now.": do nothing, another chat carries the
+     discussion. If it says "… needs the chat it comes from.": report again with the session, not with `--no-session`. If it
+     says "This chat has the old board mod.": tell the person to type `/reload-plugins` or restart Claude, then report again.
+     If it says "This chat is no longer open" (a stored report arrived later): do nothing — if the topic still applies,
+     report it from the chat you are talking in now.
+     `{"art":"gespraech","spec":"2026-10-24-test-month-design"}` · `{"art":"gespraech","spec":null,"war":"2026-10-24-test-month-design"}`
+  3. **The build of a spec begins:** the stories being built now go to "in progress" — **before** you take the first build step or
      send off a subagent:
-     `{"art":"story","spec":"2026-10-24-test-month","story":"US-1","stand":"in_arbeit"}`
-  3. **A story is built and its counter-checks have run:** "built" with criteria and the `testen` sentence. The sentence is a guide for someone without technical knowledge: where to find it, what to do, what must appear, how to notice it is wrong. A command only if there is no other way - then say where to type it (in Claude Code in the project folder, with `!` in front) and put it in backticks. Without a command: "In the app open 'Metrics' and click the post from 14 Oct - it says '4,210 seen'. If a cell is empty, say 'Doesn't work'." With a command: "In Claude Code in the project folder type `! node wortzaehler.js beispiel.txt` - five lines appear, at the top 'der (4)'. If an error message appears, say 'Doesn't work'."
+     `{"art":"story","spec":"2026-10-24-test-month-design","story":"US-1","stand":"in_arbeit"}`
+  4. **A story is built and its counter-checks have run:** "built" with criteria and the `testen` text. You take the text from the story's box "How you test it", word for word. It is a guide for someone without technical knowledge: **one line per step** (where to find it, what to do, what must appear), **without** the box heading, and **last** the line "Doesn't work if: …". In the JSON you separate the lines with `\n` — a real line break inside the text breaks the JSON, and `kimal3 plan report` cannot read the report. At most 1000 characters: if it is longer, shorten the steps, never cut off in the middle of a sentence. A command only if there is no other way - then say where to type it (in Claude Code in the project folder, with `!` in front) and put it in backticks.
      Example:
-     `{"art":"story","spec":"2026-10-24-test-month","story":"US-1","stand":"gebaut","kriterien":[{"text":"If Sabine starts on 1 Nov, it ends on 30 Nov.","gegenprobe":"bestanden"}],"testen":"In the app open 'Test month' and click Start - below it says 'Ends on 30 Nov'. If it shows another date, say 'Doesn't work'."}`
-  4. **Something comes up that no spec promises:** `{"art":"thema","schluessel":"T-4","text":"The calendar could show public holidays"}`
-  5. **`/k3plan`:** check the specs against the code and report every deviation individually — it says how.
-  6. **Wrap-up:** reconcile the day — it says how.
+     `{"art":"story","spec":"2026-10-24-test-month-design","story":"US-1","stand":"gebaut","kriterien":[{"text":"If Sabine starts on 1 Nov, it ends on 30 Nov.","gegenprobe":"bestanden"}],"testen":"1. In the app open 'Test month'.\n2. Click Start.\n3. Below it says 'Ends on 30 Nov'.\nDoesn't work if: it shows another date."}`
+  5. **Something comes up that no spec promises:** `{"art":"thema","schluessel":"T-4","text":"The calendar could show public holidays"}`
+  6. **`/k3plan`:** check the specs against the code and report every deviation individually — it says how. **Checking is work:** a story with pending counter-checks (column "Claude test pending") that you check against the code, you report as "in progress" beforehand, with `"pruefen":true` — so the card doesn't come into discussion meanwhile. Stories under "Your test" or "Done" you do not report again during the reconciliation.
+  7. **Wrap-up:** reconcile the day — it says how.
+
+  🔑 **If a story stays unfinished when you stop** (at the end of `/k3plan` or in the wrap-up), you report it with `--no-session` (`kimal3 plan report --no-session`): its plan state stays `in_arbeit`, but the dot at the project stops glowing although the window stays open — on the board it then sits under "Open" as started.
 
   You report "built" only after a counter-check that ran in this session, never from memory.
 - **Subagents never report.** The mod reminds only you, not them: you report "in progress" **before** the job to a subagent that
@@ -167,7 +192,8 @@ The board in the app shows only what you report: if you don't, it shows "Open" f
   and goes along with the next command, don't send it again. `2` means not signed in: tell them `kimal3 login`.
 - **Sentences only you get** (from the mod `kimal3-plan`; the person doesn't see them): the reminder to report a story as "in
   progress" or to note the change as a topic · "create the project with `kimal3 project connect`" · "saved reports are
-  waiting — `kimal3 plan send`". Act on them without telling the person.
+  waiting — `kimal3 plan send`" · the person clicked a card on the board to discuss it, or ended the discussion (then you talk
+  about that spec, or no longer; you don't report a `gespraech` for it). Act on them without telling the person.
 
 ## 4 · Permission and safety
 - **Before an action has to be confirmed**, explain in everyday language: **what** happens (the effect, not the

package/dist/meldungen-speicher.js

@@ -40,6 +40,8 @@ export function meldungFehler(m) {
         case "spec":
             if (!istText(m.schluessel) || !istText(m.titel) || !istTextOderNull(m.datei) || !Array.isArray(m.stories))
                 return "meldung";
+            if (m.wartet_auf_lesen !== undefined && typeof m.wartet_auf_lesen !== "boolean")
+                return "meldung";
             return m.stories.every((s) => istObjekt(s) && istText(s.schluessel) && istText(s.titel)) ? null : "meldung";
         case "story":
             if (!istText(m.spec) || !istText(m.story) || typeof m.stand !== "string" || !STAENDE.includes(m.stand))
@@ -50,10 +52,13 @@ export function meldungFehler(m) {
                 return "meldung";
             if (m.befunde !== undefined && !Array.isArray(m.befunde))
                 return "meldung";
+            if (m.pruefen !== undefined && typeof m.pruefen !== "boolean")
+                return "meldung";
             return (m.testen === undefined || istTextOderNull(m.testen)) && (m.grund === undefined || istTextOderNull(m.grund)) ? null : "meldung";
         case "thema": return istText(m.schluessel) && istText(m.text) ? null : "meldung";
         case "uebernommen": return Number.isInteger(m.rueckmeldung) && istText(m.antwort) ? null : "meldung";
         case "eingeordnet": return istText(m.schluessel) && istText(m.text) && istText(m.antwort) ? null : "meldung";
+        case "gespraech": return istTextOderNull(m.spec) && (m.war === undefined || (istText(m.war) && m.spec === null)) ? null : "meldung";
         default: return "art";
     }
 }

package/dist/texte/meldungen.js

@@ -29,7 +29,7 @@ const de = {
   Meldet der Projektseite eine Änderung: liest eine Meldung oder eine Liste
   von Meldungen als JSON von der Eingabe, zum Beispiel
     echo '{"art":"story","spec":"testmonat","story":"US-2","stand":"in_arbeit"}' | kimal3 plan melde
-  Arten: spec, story, thema, uebernommen, eingeordnet.
+  Arten: spec, story, thema, uebernommen, eingeordnet, gespraech.
 
   --ohne-sitzung     Meldet ohne die Nummer der Claude-Sitzung (für das
                      Prüfen von Specs): Auf dem Board leuchtet kein Punkt.
@@ -91,7 +91,7 @@ const en = {
   Reports a change to the project page: reads one report or a list of
   reports as JSON from the input, for example
     echo '{"art":"story","spec":"testmonat","story":"US-2","stand":"in_arbeit"}' | kimal3 plan report
-  Kinds (field "art"): spec, story, thema, uebernommen, eingeordnet.
+  Kinds (field "art"): spec, story, thema, uebernommen, eingeordnet, gespraech.
 
   --no-session       Reports without the Claude session number (for checking
                      specs): no dot lights up on the board.

package/dist/texte/skill.js

@@ -1,7 +1,7 @@
 const de = {
     // ── skillInstall ──
     skillMissing: "Das Skill liegt nicht im Paket. Bitte kimal3 neu installieren:",
-    skillWriteFailed: (fehler) => `Das Skill liess sich nicht schreiben: ${fehler}`,
+    skillWriteFailed: (fehler) => `Das Skill ließ sich nicht schreiben: ${fehler}`,
     skillUpdated: "✓ Skill aktualisiert.",
     skillCreated: "✓ Skill angelegt.",
     skillOnlyInstalled: "  Das Skill ist installiert, die Slash-Befehle sind es NICHT.",
@@ -11,36 +11,36 @@ const de = {
     skipped2: "  sie bleibt unangetastet. Wer die kimal3-Fassung will, benennt",
     skipped3: "  die eigene um und führt den Befehl erneut aus.",
     unreadable: (anzahl, liste) => `⚠ ${anzahl} nicht lesbar: ${liste}`,
-    unreadable1: "  Diese Dateien liessen sich nicht öffnen — vielleicht sind sie",
+    unreadable1: "  Diese Dateien ließen sich nicht öffnen — vielleicht sind sie",
     unreadable2: "  gerade in Benutzung. Sie wurden nicht angefasst; ein zweiter",
     unreadable3: "  Versuch gleich kann klappen.",
     noCommandInstalled1: "  Es wurde KEIN Slash-Befehl installiert.",
     noCommandInstalled2: "  Das Skill selbst ist installiert und funktioniert.",
     notAllWritten1: "  Nicht alle Slash-Befehle konnten geschrieben werden.",
     notAllWritten2: "  Die oben genannten stehen; ein zweiter Lauf holt den Rest.",
-    runIncomplete: "  Der Lauf ist damit unvollstaendig -- ein zweiter Versuch holt den Rest.",
-    // ── die taegliche Pruefung (Wache) in Claudes Einstellungen ──
-    watchSetUp: "  Die taegliche kimal3-Pruefung ist eingetragen. Sie meldet sich nur, wenn etwas ansteht.",
-    watchAlready: "  Die taegliche kimal3-Pruefung steht schon in deinen Einstellungen.",
-    watchFailed: "  Die taegliche kimal3-Pruefung konnte NICHT eingetragen werden.",
+    runIncomplete: "  Der Lauf ist damit unvollständig -- ein zweiter Versuch holt den Rest.",
+    // ── die tägliche Prüfung (Wache) in Claudes Einstellungen ──
+    watchSetUp: "  Die tägliche kimal3-Prüfung ist eingetragen. Sie meldet sich nur, wenn etwas ansteht.",
+    watchAlready: "  Die tägliche kimal3-Prüfung steht schon in deinen Einstellungen.",
+    watchFailed: "  Die tägliche kimal3-Prüfung konnte NICHT eingetragen werden.",
     settingsUnreadable: (datei) => `  Deine Claude-Einstellungen sind nicht lesbar: ${datei}`,
-    settingsNotJson: "  Die Datei ist kein gueltiges JSON. Sie wurde NICHT angefasst.",
+    settingsNotJson: "  Die Datei ist kein gültiges JSON. Sie wurde NICHT angefasst.",
     settingsStrangeShape: "  Die Datei hat eine Form, die wir nicht verstehen. Sie wurde NICHT angefasst.",
     settingsRetryNoHelp: "  Wiederholen hilft nicht -- erst die Datei in Ordnung bringen.",
     settingsFailedLine: (datei, ursache) => `  ${datei}: ${ursache}`,
-    settingsUnchanged: "  Deine bisherigen Einstellungen sind unveraendert.",
+    settingsUnchanged: "  Deine bisherigen Einstellungen sind unverändert.",
     // Die Ursachen der vier Schritte aus einstellungen-schreiben.ts; `detail` ist die Meldung des Systems.
     stepRead: (detail) => `nicht lesbar (${detail})`,
-    stepBackup: (detail) => `keine Sicherungskopie moeglich (${detail})`,
+    stepBackup: (detail) => `keine Sicherungskopie möglich (${detail})`,
     stepWrite: (detail) => `nicht schreibbar (${detail})`,
-    stepCheck: (detail) => "Kontrolle nach dem Schreiben fehlgeschlagen (" + (detail ?? "unser Eintrag steht nicht in der zurueckgelesenen Datei") + ")",
+    stepCheck: (detail) => "Kontrolle nach dem Schreiben fehlgeschlagen (" + (detail ?? "unser Eintrag steht nicht in der zurückgelesenen Datei") + ")",
     // ── der Schluss ──
     tipK3: "  Tipp /k3 in Claude Code. (Taucht nichts auf, einmal neu starten.)",
     tipOther: (name) => `  Tipp /${name} in Claude Code. (Taucht nichts auf, einmal neu starten.)`,
     // ── slashBefehleInstallieren ──
     commandsMissing: "Die Slash-Befehle liegen nicht im Paket. Bitte kimal3 neu installieren.",
     commandsNone: "Im Paket liegt kein einziger Slash-Befehl. Bitte kimal3 neu installieren.",
-    commandsWriteFailed: (fehler) => `Die Slash-Befehle liessen sich nicht alle schreiben: ${fehler}`,
+    commandsWriteFailed: (fehler) => `Die Slash-Befehle ließen sich nicht alle schreiben: ${fehler}`,
     // ── raeumeVeralteteAuf ──
     outdatedRemoved: (name) => `  (Befehl /${name} entfernt: veraltet oder in einer anderen Sprache)`,
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kimal3",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "description": "Trag deine KI-Projekte dort ein, wo sie entstehen: im Terminal. · Log your AI projects where they happen: in the terminal.",
   "type": "module",
   "bin": {

package/skill/commands/k3feierabend.md

@@ -21,22 +21,31 @@ und überspring ihn — kein Leerlauf.
 - **Das Board abgleichen — nur in einem Projektordner mit Projekt in der App** (sonst überspring
   es und sag nichts). `kimal3 plan` zeigt den Stand, den die App kennt; halt ihn gegen das, was
   heute wirklich passiert ist. Was fertig ist und dessen Gegenproben in dieser Sitzung gelaufen
-  sind, steht als `gebaut` mit Kriterien und `testen`-Satz; was angefangen und nicht fertig ist,
-  bleibt `in_arbeit`; was heute aufgefallen ist und keine Spec verspricht, kommt als `thema` hinein.
-  Melde nur, was vom Stand abweicht, in einer Liste mit `kimal3 plan melde` (Aufbau und Rückgabewerte:
+  sind, steht als `gebaut` mit Kriterien und `testen`-Text; was angefangen und nicht fertig ist,
+  bleibt `in_arbeit` — und geht in einen **eigenen** Aufruf `kimal3 plan melde --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, obwohl das Fenster nur offen steht); was heute aufgefallen ist und keine Spec verspricht, kommt als `thema` hinein.
+  Melde nur, was vom Stand abweicht: die fertigen in einer Liste mit `kimal3 plan melde` (Aufbau und Rückgabewerte:
   Coach, Abschnitt 3.6, und `/k3plan`, Abschnitt 6; was ein Rückgabewert heißt, steht in
   `~/.claude/skills/kimal3/SKILL.md`):
 
   ```json
-  [ { "art": "story", "spec": "2026-10-24-testmonat", "story": "US-1", "stand": "gebaut",
+  [ { "art": "story", "spec": "2026-10-24-testmonat-design", "story": "US-1", "stand": "gebaut",
       "kriterien": [ { "text": "Startet Sabine am 1.11., endet er am 30.11.", "gegenprobe": "bestanden" } ],
-      "testen": "Öffne /testmonat und klick „Starten“ — darunter steht „Endet am 30.11.“." },
-    { "art": "story", "spec": "2026-10-24-testmonat", "story": "US-2", "stand": "in_arbeit" } ]
+      "testen": "1. Öffne /testmonat.\n2. Klick „Starten“.\n3. Darunter steht „Endet am 30.11.“.\nPasst nicht, wenn: dort ein anderes Datum steht." } ]
+  ```
+
+  Und was unfertig bleibt, getrennt davon, mit dem Schalter:
+
+  ```json
+  [ { "art": "story", "spec": "2026-10-24-testmonat-design", "story": "US-2", "stand": "in_arbeit" } ]
+  ```
+
+  ```
+  echo '[ … ]' | kimal3 plan melde --ohne-sitzung
   ```
 
   Bei Erfolg sagst du dazu nichts. Nennst du im Abschluss (Schritt 6) etwas zum Board, dann nur,
   was **nicht** geklappt hat (eine Absage, oder gemerkt, weil die App nicht erreichbar war).
-  Der Punkt am Projekt auf der Projektseite bleibt, solange das Fenster offen ist; schließt der
+  Der Punkt am Projekt auf der Projektseite bleibt für laufende Arbeit, solange das Fenster offen ist; schließt der
   Mensch es, ist er in unter einer Sekunde weg.
 
 ## 2. Status-Datei nachziehen — und aufräumen

package/skill/commands/k3plan.md

@@ -43,7 +43,7 @@ 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)
+Spec 2026-09-23-content-planer · Content-Planer als Seite (plan/2026-09-23-content-planer.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
@@ -101,7 +101,7 @@ Reihenfolge.
 **Der Stand je Story (`stand`):**
 - `offen` — noch nichts gebaut.
 - `in_arbeit` — teilweise gebaut, oder ein Befund ist offen.
-- `gebaut` — gebaut. Das Datum setzt die App; dazu ein `testen`-Satz (Abschnitt 4).
+- `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.
@@ -115,8 +115,9 @@ 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.
@@ -127,7 +128,11 @@ mehr gebaut oder geprüft wird (die Spec steht dann in „Dein Test"). Bis dahin
 bestandenen Stories in der App „Von Claude geprüft". Sag im Bericht, was fehlt, damit die
 Gegenprobe laufen kann.
 
-**Der `testen`-Satz** (bei jeder `gebaut`-Story, höchstens 1000 Zeichen) ist eine Anleitung für jemanden ohne Technik. Er sagt wo man es findet, was man tut, was dann zu sehen ist, woran man merkt, dass es nicht stimmt. 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. Ohne Befehl: „Öffne in der App ‚Kennzahlen‘ und klick auf den Beitrag vom 14.10. — dort steht ‚4.210 gesehen‘. Steht dort eine leere Zelle, sag ‚Passt nicht‘.“ Mit Befehl: „Tippe in Claude Code im Projektordner `! node wortzaehler.js beispiel.txt` — es erscheinen fünf Zeilen, oben ‚der (4)‘. Kommt eine Fehlermeldung, sag ‚Passt nicht‘.“ Fehlt der Satz, zeigt die App: „Claude hat nicht aufgeschrieben, wie man das testet".
+**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`) **und mit `"pruefen": true`**: Solange du prüfst, leuchtet der Punkt am Projekt, aber die Karte kommt dadurch nicht ins Gespräch — ohne das Feld wanderte der blaue Rahmen durch jede Spec, die du prüfst. Nach der Prüfung meldest du das Ergebnis (`gebaut`, oder `in_arbeit` mit Befund — jede `in_arbeit`-Meldung aus `/k3plan` trägt `"pruefen": true`). 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).
+
+**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. Ein
@@ -138,7 +143,7 @@ Befunde mit, nicht nur den neuen. Fehlt das Feld, bleibt die Liste, wie sie ist.
 - 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"`, `runde` + 1, 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).
@@ -148,11 +153,11 @@ Befunde mit, nicht nur den neuen. Fehlt das Feld, bleibt die Liste, wie sie ist.
 
 Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planung kurz"):
 
-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, 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 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. Was daraus wurde, steht unter „Von Claude einsortiert".
+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:** 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.
@@ -160,7 +165,7 @@ Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planun
 **Was du danach tust** (jedes Mal eine Meldung, Abschnitt 6):
 
 - **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
+  des Menschen als Befund (`quelle: "mensch"`, `seit: "<heute>"`), `stand: "in_arbeit"` und `"pruefen": true`, 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
@@ -181,10 +186,9 @@ Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planun
     `gestrichen: Feiertage stehen schon im Kalender-Werkzeug.`
 
   Für eine Notiz aus der App (`#13 · Thema`) gehört die Antwort als **ein Satz** in eine Meldung
-  `uebernommen` (die App zeigt sie unter „Zuletzt eingeordnet" als `<Notiz> → <Antwort>`); schreib
-  sie darum **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
-  und zeigt es 14 Tage lang unter „Zuletzt eingeordnet". Nenn die Einordnung auch im Bericht.
+  `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
@@ -202,45 +206,59 @@ Die App zeigt sie dem Menschen in genau diesem Wortlaut („So bleibt die Planun
 ## 6. Die Meldungen
 
 Jede Meldung ist ein JSON-Objekt, mehrere eine Liste. Sie geht über die Eingabe an
-`kimal3 plan melde --ohne-sitzung`; das Programm setzt die Zeit selbst, das Projekt kommt vom Ordnerzettel
-`plan/projekt.json`. Prüfen ist nicht Arbeiten — so leuchtet auf dem Board kein Punkt.
+`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; `"pruefen": true` an jeder `in_arbeit`-Meldung hält die Karte dabei aus dem Gespräch.
 
 ```
-echo '[ … ]' | kimal3 plan melde --ohne-sitzung
+echo '[ … ]' | kimal3 plan melde
 ```
 
-(In PowerShell: `'[ … ]' | kimal3 plan melde --ohne-sitzung`. Lange Texte lieber über eine Datei.) Die Beispiele
+(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
+```
+
 **Eine Spec** — beim Prüfen und wenn Stories dazukommen:
 
 ```json
-{ "art": "spec", "schluessel": "2026-10-24-testmonat", "titel": "Testmonat",
+{ "art": "spec", "schluessel": "2026-10-24-testmonat-design", "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" } ] }
 ```
 
+Lass dabei `wartet_auf_lesen` weg: Fehlt das Feld, bleibt das Etikett „Wartet auf dein Lesen“, wie es ist. Gesetzt und
+weggenommen wird es, wenn du eine Spec dem Menschen zum Lesen vorlegst und er sie freigibt (Coach, Abschnitt 3.6) — genauso die Meldung
+`gespraech`; `/k3plan` schickt keine.
+
 **Eine Story** — eine Abweichung, ein Eintrag. Gebaut, mit Gegenprobe:
 
 ```json
-{ "art": "story", "spec": "2026-10-24-testmonat", "story": "US-1", "stand": "gebaut",
+{ "art": "story", "spec": "2026-10-24-testmonat-design", "story": "US-1", "stand": "gebaut",
   "kriterien": [ { "text": "Startet Sabine am 1.11., endet der Testmonat am 30.11.", "gegenprobe": "bestanden" } ],
-  "testen": "Öffne in der App ‚Testmonat‘ und klick „Starten“ — darunter steht ‚Endet am 30.11.‘. Steht dort ein anderes Datum, sag ‚Passt nicht‘." }
+  "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",
+{ "art": "story", "spec": "2026-10-24-testmonat-design", "story": "US-2", "stand": "in_arbeit", "pruefen": true,
   "befunde": [ { "text": "Am 30.11. fehlt die Erinnerungsmail, die die Spec verspricht.", "quelle": "claude", "seit": "2026-10-23" } ] }
 ```
 
 Bewusst weggelassen (`grund` ist Pflicht):
 
 ```json
-{ "art": "story", "spec": "2026-10-24-testmonat", "story": "US-3", "stand": "weggelassen", "grund": "Die Spec streicht den Export." }
+{ "art": "story", "spec": "2026-10-24-testmonat-design", "story": "US-3", "stand": "weggelassen", "grund": "Die Spec streicht den Export." }
 ```
 
 **Ein Thema** (Regel 2), **ein Thema von dir einordnen** (Regel 3), **eine Rückmeldung des Menschen
@@ -270,6 +288,8 @@ angemeldet: Sag dem Menschen `kimal3 login`; die Meldung ist gemerkt.
 | `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 …` | 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 „Im Gespräch“ braucht den Chat, aus dem sie kommt.` | Mit Sitzung noch einmal melden, nicht mit `--ohne-sitzung`. |
+| `Über diese Karte spricht gerade ein anderer Chat.` | Nichts tun: Das Gespräch trägt ein anderer Chat. |
 | `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.** |
@@ -282,7 +302,7 @@ nicht, wenn die Meldung es vorschlägt.
 **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** (nur Stories aus Specs in „Dein Test") — 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: …`.