kimal3 0.7.0 → 0.8.0

package/claude-plugins/kimal3-plan/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kimal3-plan",
-  "version": "0.1.0",
-  "description": "Hält das Board der Projektseite in der App aktuell: Punkt solange die Sitzung arbeitet, Spec-Texte, Erinnerung an Claude · Keeps the board on the app's project page current: dot while the session works, spec texts, reminder to Claude",
+  "version": "0.1.1",
+  "description": "Hält das Board der Projektseite in der App aktuell: Punkt solange die Sitzung arbeitet, Spec-Texte, hält Claude vor dem ersten Bau-Schritt an · Keeps the board on the app's project page current: dot while the session works, spec texts, stops Claude before the first build step",
   "author": { "name": "KImal3", "url": "https://kimal3.de" },
   "types": "./types/index.d.ts"
 }

package/claude-plugins/kimal3-plan/hooks/erinnerung.ts

@@ -6,11 +6,16 @@ import { relativImOrdner } from './ordner'
  * Die drei Saetze, die NUR Claude bekommt (Spec 1.3 Aufgabe 3, 1.5, 1.7, S-25, S-26, US-6, US-8; Bauplan R-4).
  * Der Mensch sieht keinen davon (gemessen M-3, Claude-App). Zwei Wege, je nachdem, ob der Satz eine Runde starten soll:
  *
- * - **Erinnerung ans Melden** haengt am Aendern einer Datei (`tool.call` mit `context`): keine eigene Runde, Claude liest
- *   ihn direkt nach dem Werkzeug. Nur die Hauptsitzung bekommt ihn: Ein Subagent (`e.agentId`) baut im Auftrag und
- *   meldet nicht; er wuerde die 30-Minuten-Sperre verbrauchen, ohne dass die Hauptsitzung je erinnert wird (Ruling). Hoechstens einmal je 30 Minuten je Sitzung, nur in einem Projektordner mit
+ * - **Sperre vor dem ersten Bau-Schritt** (US-6, Dennis 25.10.: „Ich will das Problem gleich gefixt haben“): Will Claude
+ *   eine Datei aendern, ohne dass diese Sitzung eine Story „in Arbeit“ hat, lehnt der Mod die Aenderung VORHER ab
+ *   (`deny`), und Claude liest den Satz als Grund. Bis zum 25.10. kam der Satz erst NACH der Aenderung als `context` --
+ *   gemessen in einer echten Sitzung: Claude schrieb zuerst die Pruefung und meldete danach. Der zweite Versuch geht
+ *   durch (30-Minuten-Sperre): Eine Aenderung ohne Story (Statuszettel, neue Spec) haengt so nie fest. Nur die
+ *   Hauptsitzung: Ein Subagent (`e.agentId`) baut im Auftrag und meldet nicht. Nur in einem Projektordner mit
  *   Ordnerzettel (S-30), und nur, wenn die App zuletzt „nichts in Arbeit“ gesagt hat -- weiss der Mod es nicht (noch
- *   keine Antwort, App weg), schweigt er.
+ *   keine Antwort, App weg), haelt er nichts an. 🔴 Scheitert der Hook selbst, ueberspringt ihn die Maschine und die
+ *   Aenderung laeuft (`tool.call`, Typen: „A guard that fails is skipped and the tool runs“) -- so gewollt: Ein Fehler
+ *   im Mod darf die Arbeit nie aufhalten.
  * - **Anstoss „Projekt anlegen“** (US-8) und **„gemerkte Meldungen senden“** (R-4) sind eine Zeile im Gespraech
  *   (`$.session.append`): Claude liest sie sofort und handelt.
  */
@@ -30,17 +35,16 @@ export function dateiAus(e: unknown): string | null {
 
 export function erinnerung(on: On, lauf: Lauf): void {
   on('tool.call', { tool: ['Write', 'Edit', 'NotebookEdit'] }, async ($, e, next) => {
-    const ergebnis = await next(e)
-    // Abgelehnt oder gescheitert: Es hat sich nichts geaendert. Ein Subagent: nur die Hauptsitzung wird erinnert.
-    if (ergebnis.deny !== undefined || ergebnis.isError === true || e.agentId !== undefined) return ergebnis
-    const satz = await satzFuer($, lauf, dateiAus(e))
-    return satz === null ? ergebnis : { ...ergebnis, context: [...(ergebnis.context ?? []), satz] }
+    const satz = e.agentId === undefined ? await satzFuer($, lauf, dateiAus(e)) : null
+    return satz === null ? next(e) : { deny: satz }
   })
 }
 
 async function satzFuer($: EngineInterface, lauf: Lauf, datei: string | null): Promise<string | null> {
   const lage = lauf.lage
   if (lauf.inArbeit !== false || lage.art !== 'projekt' || lage.zettel === null || datei === null) return null
+  // Markdown ist Planung (Spec, Bauplan, Statuszettel), kein Bau-Schritt: Eine neue Spec entsteht, bevor es eine Story gibt.
+  if (datei.toLowerCase().endsWith('.md')) return null
   if (relativImOrdner(datei, lage.ordner, await $.session.cwd()) === null) return null
   const jetzt = await $.clock.now()
   const zuletzt = await read($, letzteErinnerung)

package/claude-plugins/kimal3-plan/hooks/lauf.ts

@@ -56,7 +56,7 @@ const APP = 'https://app.kimal3.de'
 // Englische Befehlswoerter wie in `cli/src/befehlswoerter.ts` (`project connect`, `plan send`).
 export const TEXTE = {
   de: {
-    erinnerung: (titel: string) => `Du arbeitest im Projekt ${titel}, aber diese Sitzung hat keine Story ‚in Arbeit‘ gemeldet. Welche ist dran? Gehört die Änderung zu keiner Spec, notiere sie als Thema oder arbeite weiter.`,
+    erinnerung: (titel: string) => `Halt, die Datei ist noch nicht geändert: Du arbeitest im Projekt ${titel}, aber diese Sitzung hat keine Story ‚in Arbeit‘ gemeldet. Melde zuerst die Story, an der du arbeitest, und ändere die Datei danach. Gehört die Änderung zu keiner Story, notiere sie als Thema oder versuch es einfach noch einmal.`,
     anstoss: 'Für diesen Projektordner gibt es noch kein Projekt in der App — leg es mit `kimal3 projekt verbinden` an.',
     gemerkt: 'Gemerkte Meldungen warten — führe `kimal3 plan senden` aus.',
     fehler: {
@@ -66,7 +66,7 @@ export const TEXTE = {
     },
   },
   en: {
-    erinnerung: (titel: string) => `You are working in the project ${titel}, but this session hasn't reported a story as ‘in progress’. Which one is it? If the change belongs to no spec, note it as a topic or keep working.`,
+    erinnerung: (titel: string) => `Stop, the file has not been changed: You are working in the project ${titel}, but this session hasn't reported a story as ‘in progress’. Report the story you're working on first, then change the file. If the change belongs to no story, note it as a topic or simply try again.`,
     anstoss: 'There is no project in the app for this project folder yet — create it with `kimal3 project connect`.',
     gemerkt: 'Saved reports are waiting — run `kimal3 plan send`.',
     fehler: {

package/coach/de/kimal3-coach.md

@@ -88,7 +88,12 @@ nutze sie, statt vorschnell loszulegen.
 
 ### 3.3 Planen, jetzt konkret
 - Was genau gebaut wird, in welchen Schritten, woran jeder Schritt geprüft wird. Bei Größerem schriftlich: eine Spec,
-  also ein Plan mit Nutzergeschichten („Als … will ich … damit …“) und einer Gegenprobe je Kriterium.
+  also ein Plan mit Nutzergeschichten. Jede Story steht in vier Kisten, immer in dieser Reihenfolge:
+  **User Story** („Als … will ich … damit …“; der Titel nennt das Ziel des Menschen, nicht das Ergebnis) ·
+  **Akzeptanzkriterium** (vier Zeilen: *X hat …* · *X tut …* · *Dann muss …* · *Gegenprobe: …* — ein Kriterium, das nicht
+  scheitern kann, ist keins) · **So testest du es** (nummerierte Schritte für jemanden ohne Technik: wo, was tun, was dann
+  zu sehen ist; darunter die Zeile „Passt nicht, wenn: …“; ein Befehl nur mit Ort, in Backticks) · **Technische Notiz**
+  (wo die Sache wohnt, was sie trägt — der Mensch muss sie nicht lesen). Echte Zahlen, echter Text, ein Name statt „der Nutzer“.
 - **Ein abgesegneter Plan rechtfertigt nichts, was frische Messungen widerlegen.** Nie „der Plan sagt, das ist
   hinnehmbar" als Begründung — sondern neu beantworten: *Was ist mit dem, was ich JETZT weiß, das Beste?* Weicht es
   ab: laut sagen, Plan nachziehen.
@@ -151,13 +156,15 @@ Das Board in der App zeigt nur, was du meldest: Wer nicht meldet, lässt es stun
   2. **Der Bau einer Spec beginnt:** die Stories, die jetzt gebaut werden, auf „in Arbeit“ — **bevor** du den ersten Bau-Schritt oder
      einen Subagenten losschickst:
      `{"art":"story","spec":"2026-10-24-testmonat","story":"US-1","stand":"in_arbeit"}`
-  3. **Eine Story ist gebaut und ihre Gegenproben sind gelaufen:** „gebaut“ mit Kriterien und dem `testen`-Satz. Der Satz ist eine Anleitung für jemanden ohne Technik: 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‘.“
+  3. **Eine Story ist gebaut und ihre Gegenproben sind gelaufen:** „gebaut“ mit Kriterien und dem `testen`-Text. Den Text nimmst du aus der Kiste „So testest du es“ der Story, wörtlich. Er ist eine Anleitung für jemanden ohne Technik: **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: …“. Die Zeilen trennst du im JSON mit `\n` — ein echter Zeilenumbruch im Text bricht das JSON, und `kimal3 plan melde` liest die Meldung nicht. Höchstens 1000 Zeichen: ist er länger, kürze die Schritte, nie mitten im Satz abschneiden. 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.
      Beispiel:
-     `{"art":"story","spec":"2026-10-24-testmonat","story":"US-1","stand":"gebaut","kriterien":[{"text":"Startet Sabine am 1.11., endet er 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‘."}`
+     `{"art":"story","spec":"2026-10-24-testmonat","story":"US-1","stand":"gebaut","kriterien":[{"text":"Startet Sabine am 1.11., endet er 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."}`
   4. **Etwas fällt auf, das keine Spec verspricht:** `{"art":"thema","schluessel":"T-4","text":"Der Kalender könnte Feiertage zeigen"}`
-  5. **`/k3plan`:** Specs gegen den Code prüfen und jede Abweichung einzeln melden — dort steht, wie.
+  5. **`/k3plan`:** Specs gegen den Code prüfen und jede Abweichung einzeln melden — dort steht, wie. **Prüfen ist Arbeit:** Eine Story mit offenen Gegenproben (Spalte „Claude-Test offen“), die du gegen den Code prüfst, meldest du vorher als „in Arbeit“. Stories in „Dein Test“ oder „Fertig“ meldest du beim Abgleich nicht neu.
   6. **Feierabend:** den Tag abgleichen — dort steht, wie.
 
+  🔑 **Bleibt eine Story unfertig, wenn du aufhörst** (am Ende von `/k3plan` oder im Feierabend), meldest du sie mit `--ohne-sitzung` (`kimal3 plan melde --ohne-sitzung`): Ihr Plan-Stand bleibt `in_arbeit`, aber der Punkt am Projekt leuchtet nicht weiter, obwohl das Fenster offen bleibt — auf dem Board steht sie dann in „Offen“ als angefangen.
+
   „Gebaut“ meldest du erst nach einer Gegenprobe, die in dieser Sitzung gelaufen ist, nie aus dem Gedächtnis.
 - **Subagenten melden nie.** Der Mod erinnert nur dich, nicht sie: Du meldest „in Arbeit“ **vor** dem Auftrag an einen Subagenten, der
   baut, und „gebaut“ **nachdem** du sein Ergebnis geprüft hast.

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.
@@ -151,13 +156,15 @@ The board in the app shows only what you report: if you don't, it shows "Open" f
   2. **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'."
+  3. **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'."}`
+     `{"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":"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."}`
   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.
+  5. **`/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. Stories under "Your test" or "Done" you do not report again during the reconciliation.
   6. **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
   builds, and "built" **after** you have checked its result.

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.8.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",
       "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", "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

@@ -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`): 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).
+
+**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.
@@ -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,16 +206,26 @@ 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.
 
 ```
-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
@@ -227,7 +241,7 @@ sind erfunden.
 ```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": "Ö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):
@@ -282,7 +296,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: …`.

package/skill/en/commands/k3plan.md

@@ -98,7 +98,7 @@ count `US-1`, `US-2` … yourself in their order.
 **The state of each story (`stand`):**
 - `offen` — nothing built yet.
 - `in_arbeit` — partly built, or a finding is open.
-- `gebaut` — built. The app sets the date; plus a `testen` sentence (section 4).
+- `gebaut` — built. The app sets the date; plus a `testen` text (section 4).
 - `weggelassen` — deliberately not built, `grund` is required (rule 8). Only if the spec or the
   person decided so — never on your own to tidy up. If in doubt: leave it `offen` and ask in the
   report.
@@ -110,8 +110,9 @@ Run the counter-check of each criterion **wherever you can**: the project's guar
 
 - `bestanden` (passed) — **only** if the counter-check ran in this session and showed the
   expected result. Never from memory, never from last time, never because the code "looks right".
-- `gescheitert` (failed) — it ran and showed something else. That is a finding (rule 1); the app
-  then puts the story and its spec under "In progress".
+- `gescheitert` (failed) — it ran and showed something else. That is a finding (rule 1): the story
+  then carries ⚠ and sits under "In progress" while a session is working on it, otherwise under
+  "Open" — its spec does not move to "Your test".
 - `offen` (not run) — everything that did not run: needs a browser, a sign-in, real data or a
   person. Reading only counts if the criterion says something about the file itself (a file
   exists, a text is there as written) — reading does not prove a behaviour.
@@ -122,7 +123,11 @@ built or checked (the spec is then under "Your test"). Until then the app calls
 already passed "Checked by Claude". Say in the report what is missing so the counter-check can
 run.
 
-**The `testen` sentence** (on every `gebaut` story, at most 1000 characters) is a guide for someone without technical knowledge. It says 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'." If the sentence is missing, the app shows: "Claude didn't write down how to test this".
+**The `testen` text** (on every `gebaut` story, at most 1000 characters) is a guide for someone without technical knowledge. If the story sits in a spec with the box "How you test it", you take it from there, word for word; if the box is missing, you write it yourself. **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. If the text is longer than 1000 characters, shorten the steps — never cut off in the middle of a sentence; the line "Doesn't work if: …" must stay at the end. 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. If the text is missing, the app shows: "Claude didn't write down how to test this".
+
+**Checking is work.** Before you check a story with pending counter-checks (column "Claude test pending") against the code, you report it as `in_arbeit` **with** the session (so without `--no-session`): while you check, the dot at the project glows. After the check you report the result (`gebaut`, or `in_arbeit` with a finding). Stories under "Your test" or "Done" you do **not** report again during the reconciliation, even if you look through them: `in_arbeit` followed by `gebaut` sets their build date to today, and every report shows the label "changed" and, with two sessions, the ⚠ "changed at the same time". What stays unfinished at the end of `/k3plan`, you report with `--no-session` (section 6).
+
+**How a spec is built.** If you find a spec while checking that is not built like this, say so in the report — you do not rewrite it. A story in it sits in four boxes: **User story** (the title names the person's goal) · **Acceptance criterion** (with counter-check) · **How you test it** (numbered steps, below them "Doesn't work if: …") · **Technical note**.
 
 **Findings** (`befunde`): only **open** ones. `quelle: "claude"` for something the story promises
 and doesn't do, and that no criterion covers. `seit`: the date the finding came up. A `befunde`
@@ -133,7 +138,7 @@ just the new one. If the field is missing, the list stays as it is.
 - It starts at `1` and **never** goes down; if a report has no `runde`, it stays.
 - **Raise it by exactly 1** when a story with a finding from the person (`quelle: "mensch"`) has
   been fixed since (Git history, and the counter-checks pass now): then `befunde: []`,
-  `stand: "gebaut"`, `runde` + 1, a new `testen` sentence. The person tests again. If it is
+  `stand: "gebaut"`, `runde` + 1, a new `testen` text. The person tests again. If it is
   unclear whether it was fixed: leave the finding and ask in the report.
 - **Also raise it** if you changed a **confirmed** story in a way the person would notice — their
   old "Works" no longer applies (rule 7).
@@ -143,11 +148,11 @@ just the new one. If the field is missing, the list stays as it is.
 
 The app shows them to the person in exactly this wording ("How planning stays short"):
 
-1. **A problem does not become a new card.** If a story doesn't hold what it promises — Claude's check fails or you say "Doesn't work" — the problem (finding) is attached to that story and its spec goes back to "In progress".
+1. **A problem does not become a new card.** If a story doesn't hold what it promises — Claude's check fails or you say "Doesn't work" — the problem (finding) is attached to that story. It stays in "Open" until someone works on it.
 2. **Only what nobody promised is new. It goes into the inbox, which has five places.**
-3. **Claude sorts every topic at the next check (`/k3plan`):** as a new story in a spec, as a finding on a story, or dropped with a reason. There is no "later". What happened to it is shown under "Sorted in by Claude".
+3. **Claude sorts every topic at the next check (`/k3plan`):** as a new story in a spec, as a finding on a story, or dropped with a reason. There is no "later".
 4. **Nothing stays in the inbox longer than 14 days.**
-5. **At most one spec in progress at once** ("In progress" and "Claude test pending" together). Finish it before starting the next.
+5. **At most one spec in progress at once** ("In progress" and "Claude test pending" together). "In progress" means: a Claude session is working on it right now. Finish it before starting the next.
 6. **At most five stories wait for your test.** If there are more, Claude starts nothing new until you have tested.
 7. **Done means checked twice:** Claude tried everything itself, and you said "Works" — for exactly this version.
 8. **A spec is only closed when every story is done or deliberately left out** — with a reason. There is no silent remainder.
@@ -177,10 +182,9 @@ The app shows them to the person in exactly this wording ("How planning stays sh
     `dropped: public holidays are already in the calendar tool.`
 
   For a note from the app (`#13 · Topic`), the answer goes into an `uebernommen` report as **one
-  sentence** (the app shows it under "Recently sorted" as `<note> → <answer>`); so write it
-  **without** an arrow at the start. A `Noted topic` of yours you sort with an `eingeordnet`
-  report (key, text as above, answer) — the app takes it out of the topics and shows it under
-  "Recently sorted" for 14 days. Name how it was sorted in the report too.
+  sentence**, **without** an arrow at the start. A `Noted topic` of yours you sort with an `eingeordnet`
+  report (key, text as above, answer) — the app takes it out of the topics.
+  The page doesn't show the answer; so name how it was sorted in the report.
 - **Rule 4:** because you sort everything at every `/k3plan`, nothing stays long. A topic that has
   been waiting more than 14 days is sorted now **in any case**.
 - **Rules 5 and 6 — don't start a new spec** while another spec is in progress (one of its
@@ -188,7 +192,7 @@ The app shows them to the person in exactly this wording ("How planning stays sh
   criterion or with no criteria at all), or while more than five stories are waiting for the person's test (`gebaut`, all
   passed, no finding, not yet confirmed — **and** no story of their spec keeps the spec in progress: only then
   is it under "Your test", and only then does the app count the story). **Tell the person what to test instead** — with the
-  `testen` sentences. If you sort a topic in as a new story in a spec, you do not start that spec
+  `testen` texts. If you sort a topic in as a new story in a spec, you do not start that spec
   with it: it stays `offen`, and the spec does not count as in progress.
 - **Rule 7:** only the person sets "Done", with "Works" in the app; a report has no field for it.
   You only keep the round stable (section 4).
@@ -196,17 +200,27 @@ The app shows them to the person in exactly this wording ("How planning stays sh
 
 ## 6. The reports
 
-A report is a JSON object, several are a list. It goes through the input to `kimal3 plan report --no-session`;
+A report is a JSON object, several are a list. It goes through the input to `kimal3 plan report`;
 the program sets the time itself, and the project comes from the folder note
-`plan/projekt.json`. Checking is not working — this way no dot lights up on the board.
+`plan/projekt.json`. Checking is work — reported with the session, the dot on the board glows while you check.
 
 ```
-echo '[ … ]' | kimal3 plan report --no-session
+echo '[ … ]' | kimal3 plan report
 ```
 
-(In PowerShell: `'[ … ]' | kimal3 plan report --no-session`. For long texts, use a file.) The examples are
+(In PowerShell: `'[ … ]' | kimal3 plan report`. For long texts, use a file.) The examples are
 made up.
 
+**At the very end** you report the stories that stay unfinished (in progress, a finding open) once more —
+in their **own** call with `--no-session`, separate from the list of the finished ones: a mixed list
+without the flag ties the unfinished story to the session too, and the dot keeps glowing. With the flag
+the plan state stays `in_arbeit`, but the dot stops glowing while the window stays open — on the board the
+story then sits under "Open" as started.
+
+```
+echo '[ … ]' | kimal3 plan report --no-session
+```
+
 **A spec** — when checking, and when stories are added:
 
 ```json
@@ -222,7 +236,7 @@ made up.
 ```json
 { "art": "story", "spec": "2026-10-24-test-month", "story": "US-1", "stand": "gebaut",
   "kriterien": [ { "text": "If Sabine starts on 1 Nov, the test month 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'." }
+  "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." }
 ```
 
 With an open finding (here from you; `quelle: "mensch"` only for the person's sentence):
@@ -276,7 +290,7 @@ message suggests it.
 **At most five lines**, without jargon — and nothing about the reports themselves:
 
 - what became **done** (confirmed since last time),
-- what is **waiting for their test** (only stories from specs under "Your test") — with the `testen` sentence so they can start right away,
+- what is **waiting for their test** (only stories from specs under "Your test") — with the `testen` text so they can start right away,
 - what was decided in the **inbox** (each topic with its answer),
 - a **warning** if rule 5 or 6 is broken: "Test first …" instead of a new story,
 - the **link** from `View: …`.

package/skill/en/commands/k3show.md

@@ -60,7 +60,9 @@ workbench) · “The project folder is nested too deeply for the recorder …”
 
 If the session is in the workbench, say **that first**, in one sentence: the recording belongs in
 a project, and you'll suggest one in a moment. Then explain in at most five short sentences what
-happens, and ask **one** question:
+happens, and ask **one** question. **Word for word: the first sentence of that explanation is
+exactly this one: “You show me the task once and talk while you do it.”** Don't open with anything
+else and don't reword it (only the workbench sentence above may come before it); the rest follows as written:
 
 > “You show me the task once and talk while you do it. I record the screen, sound, clicks and
 > keys. It stays on your computer. Before I read any of it, I'll ask you. Which task do you want

package/skill/en/commands/k3wrapup.md

@@ -21,21 +21,30 @@ and skip it — no filler.
 - **Reconcile the board — only in a project folder that has a project in the app** (otherwise skip
   it and say nothing). `kimal3 plan` shows the state the app knows; hold it against what really
   happened today. What is done and whose counter-checks ran in this session is `gebaut` with
-  criteria and a `testen` sentence; what was started and isn't done stays `in_arbeit`; what came
-  up today and no spec promises goes in as a `thema`. Report only what differs from that state, in
+  criteria and a `testen` text; what was started and isn't done stays `in_arbeit` — and goes into its **own** call `kimal3 plan report --no-session`, separate from the list of the finished ones (a mixed list without the flag ties the unfinished story to the session too, and the dot keeps glowing although the window is merely open); what came
+  up today and no spec promises goes in as a `thema`. Report only what differs from that state: the finished ones in
   one list with `kimal3 plan report` (format and exit codes: the coach, section 3.6, and
   `/k3plan`, section 6; what an exit code means is in `~/.claude/skills/kimal3/SKILL.md`):
 
   ```json
   [ { "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": "Open /test-month and click Start - below it says Ends on 30 Nov." },
-    { "art": "story", "spec": "2026-10-24-test-month", "story": "US-2", "stand": "in_arbeit" } ]
+      "testen": "1. Open /test-month.\n2. Click Start.\n3. Below it says Ends on 30 Nov.\nDoesn't work if: it shows another date." } ]
+  ```
+
+  And what stays unfinished, separately, with the flag:
+
+  ```json
+  [ { "art": "story", "spec": "2026-10-24-test-month", "story": "US-2", "stand": "in_arbeit" } ]
+  ```
+
+  ```
+  echo '[ … ]' | kimal3 plan report --no-session
   ```
 
   On success you say nothing about it. If you mention the board in the wrap-up (step 6), then only
   what did **not** work (a refusal, or kept because the app was not reachable). The dot at the
-  project on the project page stays as long as the window is open; when the person closes it, it
+  project on the project page stays for work in progress, as long as the window is open; when the person closes it, it
   is gone in under a second.
 
 ## 2. Update the status file — and tidy it up