dsh-composer-plus 1.17.0 → 1.18.0

package/README.de.md

@@ -29,7 +29,7 @@ dsh plugin --profile web add dsh-composer-plus
 
 Starte dsh danach neu. (Die CLI kann nicht in das Desktop-Profil installieren; dieses Profil verwaltet die App.)
 
-> Das pnpm von dsh überspringt Versionen, die jünger als 24 Stunden sind. Gib direkt nach einem Release die Version mit an: `dsh-composer-plus@1.17.0`.
+> Das pnpm von dsh überspringt Versionen, die jünger als 24 Stunden sind. Gib direkt nach einem Release die Version mit an: `dsh-composer-plus@1.18.0`.
 
 ## Funktionen
 
@@ -68,7 +68,10 @@ Starte dsh danach neu. (Die CLI kann nicht in das Desktop-Profil installieren; d
 | **Zielprüfung** | <a id="feature-goalcheck"></a>Starte ein Ziel mit `/goal`. Wenn der Agent das Ziel in einem automatischen Durchlauf als abgeschlossen markiert, schließt sich das Ziel erst nach zwei Prüfungen. Zuerst läuft der Testbefehl des Projekts im Ordner des Chats, im Sandbox-Modus des Chats. Der Befehl ist dein eigener oder der, der in `package.json`, `Makefile`, `Cargo.toml`, `go.mod` oder pytest gefunden wird. Wenn der neueste eigene Schritt des Agenten ein erfolgreicher Lauf dieses Tests war, läuft er nicht noch einmal. Dann liest ein unabhängiger Modellaufruf ohne Werkzeuge das Ziel, diesen Chat, `git status` und das Testergebnis. Das Modell antwortet mit einer Nachweistabelle: Jeder Teil des Ziels ist bestätigt, falsch oder ungeklärt, mit dem Nachweis und der Korrektur; das Ziel schließt sich erst, wenn jeder Teil bestätigt ist. Schlägt eine Prüfung fehl, bleibt das Ziel aktiv, der Agent liest jeden offenen Teil mit seinem Nachweis und seiner Korrektur, und der nächste Durchlauf geht weiter. Eine Zeile unter der Zielleiste (**Zielprüfung**) zeigt den Test, das letzte Ergebnis und wie viele Teile bestätigt sind (fahre mit der Maus darüber, um die Tabelle zu sehen). **Bearbeiten** legt deinen eigenen Testbefehl und ein Zeit- oder Token-Limit fest; über dem Limit wird das Ziel blockiert. Das Token-Limit zählt auch die Subagents des Chats. **Jetzt ausführen** führt die Prüfung aus, ohne das Ziel zu schließen. Die Funktion hat ein eigenes Menü **Modell** in den Einstellungen (Standard: **Wie das Modell des Chats**). Wenn du das Ziel selbst abschließt, wird nichts geprüft. | <a href="assets/features/goalCheck.webp"><img src="assets/features/goalCheck.webp" width="160" alt="Screenshot: Zielprüfung"></a> |
 | **In einem neuen Chat fortsetzen** | <a id="feature-handoffchat"></a>Rechtsklick auf einen Chat in der Seitenleiste (oder sein Menü **…** öffnen) → **In einem neuen Chat fortsetzen…**. Ein Aufruf an das eigene Modell des Chats schreibt aus dem, was der Chat zeigt, eine Übergabenotiz: Aufgabe, Ergebnisse, Erledigt, Entscheidungen, Offene Punkte und Nächster Schritt (Tool-Aufrufe und ihre Ergebnisse sind die Belege; Schritte, die du zurückgenommen hast, werden weggelassen). Die Notiz öffnet sich in einem Dialog: Lies und bearbeite sie. **Neu schreiben** schreibt eine neue Notiz. **Neuen Chat starten** (oder `Cmd/Ctrl+Enter`) öffnet einen neuen Chat im selben Projekt, mit der Notiz und einem Link zum alten Chat als erster Nachricht; der alte Chat bleibt, wie er ist. Nutze die Funktion, wenn ein langer Chat voll oder langsam ist, oder um morgen weiterzumachen. Nichts wird in das Projekt geschrieben. | <a href="assets/features/handoffChat.webp"><img src="assets/features/handoffChat.webp" width="160" alt="Screenshot: In einem neuen Chat fortsetzen"></a> |
 | **Kontextaufschlüsselung** | <a id="feature-contextbreakdown"></a>Rechte Seitenleiste → `+` → **Kontext**. Die Seite zeigt, was den Modellkontext des geöffneten Chats gerade füllt und wie viel vom Kontextfenster belegt ist: System-Prompt, Projektanweisungen (AGENTS.md), Skills, deine Nachrichten, Agent-Antworten und Tool-Aufrufe, Tool-Ergebnisse (nach Tool), MCP-Ergebnisse (nach Server), Tool-Definitionen, die Komprimierungszusammenfassung und weitere Kontexthinweise, jeweils mit Tokens und Anteil. Klicke auf einen Teil, um seine Tools oder Server zu sehen. Die Seite liest nur das Chatprotokoll, nach `/compact` und Rücknahmen, und ruft kein Modell auf; sie liest nach jeder Runde und mit **Aktualisieren** neu. Nutze sie, um zu sehen, warum ein Chat langsam oder voll ist, zum Beispiel wegen eines großen MCP-Tool-Ergebnisses oder vieler Tool-Definitionen. | <a href="assets/features/contextBreakdown.webp"><img src="assets/features/contextBreakdown.webp" width="160" alt="Screenshot: Kontextaufschlüsselung"></a> |
+| **Geplante Schritte** | <a id="feature-plannedsteps"></a>Standardmäßig aus: Schalte die Funktion unter **Einstellungen → Composer Plus** ein. Der Agent bekommt das Tool `plan_next_steps`: In derselben Nachricht wie ein Befehl kann er die nächsten Befehle mit den genauen Argumenten und einer Bedingung planen, etwa „führe `npm test` aus, wenn der Build gelingt“. Erfüllt das Ergebnis die Bedingung, führt Composer Plus den nächsten Schritt selbst aus, ohne neuen Modellaufruf, sodass ein langer Chat weniger Tokens verbraucht. Der Schritt erscheint im Chat als kurze Zeile „Composer Plus · Planned steps: ran `test` … without a model call“, danach folgen sein Tool-Aufruf und sein Ergebnis. Nur Schritte mit `bash`, `read`, `grep` und `glob`; Freigaben, Sandbox und Geschützte Dateien gelten für jeden Schritt wie gewohnt. Das Modell antwortet wieder, wenn eine Bedingung nicht erfüllt ist, wenn zwei Schritte gleichzeitig bereit sind, nach dem letzten Schritt und wenn du eine Nachricht sendest. Die Idee stammt aus HarnessMM (arXiv 2610.32813). | <a href="assets/features/plannedSteps.webp"><img src="assets/features/plannedSteps.webp" width="160" alt="Screenshot: Geplante Schritte"></a> |
 | **Geschützte Dateien** | <a id="feature-protectedfiles"></a>Standardmäßig an. Die eigenen Datei-Tools des Agenten können Dateien, die zu deinen Mustern passen, weder lesen noch ändern: `read`, `read_image` und `grep` auf eine Datei werden bei Mustern mit **Lesen und Schreiben** abgelehnt, `write`, `edit` und `str_replace_editor` bei beiden Arten. Der Agent liest den Grund und wird angewiesen, dich zu fragen. Die Standardmuster sind `.env*`, `*.pem` und `*.key`. Einstellungen → Composer Plus → **Geschützte Dateien**: Füge ein Muster hinzu (zum Beispiel `published/**` oder `config/*.yml`), klicke auf seine Art, um zwischen **Lesen und Schreiben** und **nur Schreiben** zu wechseln, entferne es mit ✕ oder klicke auf **Standardwerte verwenden**. Ein Muster ohne `/` passt auf einen Dateinamen in jedem Ordner. Das ist eine Leitplanke, keine Sandbox: Ein Shell-Befehl (`cat .env`), ein Skript oder ein MCP-Tool kann die Datei trotzdem erreichen (siehe Grenzen). | <a href="assets/features/protectedFiles.webp"><img src="assets/features/protectedFiles.webp" width="160" alt="Screenshot: Geschützte Dateien"></a> |
+| **Blockierte Befehle** | <a id="feature-blockedcommands"></a>Standardmäßig an, mit einer leeren Liste. Die Shell-Befehle des Agenten (`bash`, `pwsh`) können keinen Befehl ausführen, der zu deinen Regeln passt: Eine Regel mit **blockieren** lehnt den Aufruf ab (der Agent liest den Grund und wird angewiesen, dich zu fragen), eine Regel mit **zuerst fragen** zeigt die Genehmigungskarte von dsh, und der Befehl läuft nur, wenn du ihn zulässt. Einstellungen → Composer Plus → **Blockierte Befehle**: Gib eine Regel ein (zum Beispiel `npm publish`, `git push --force` oder `ssh *192.168.2.19`), klicke auf die Art, um zwischen **blockieren** und **zuerst fragen** zu wechseln, dann auf **Hinzufügen**; klicke auf die Art einer Regel, um sie zu ändern, und entferne sie mit ✕. Eine Regel ist ein Befehlsname und Wörter, die in dieser Reihenfolge nach ihm kommen müssen; `*` passt auf beliebigen Text. Die Funktion findet den Befehl auch nach `&&`, `;`, `\|`, innerhalb von `$(…)`, `bash -c "…"` oder `eval` sowie nach `sudo` oder `env`. Das ist eine Leitplanke, keine Sandbox: Eine Variable (`$CMD`), eine Skriptdatei oder ein anderes Programm kann den Befehl trotzdem ausführen (siehe Grenzen). | <a href="assets/features/blockedCommands.webp"><img src="assets/features/blockedCommands.webp" width="160" alt="Screenshot: Blockierte Befehle"></a> |
+| **Aufgabentafel** | <a id="feature-taskboard"></a>Linke Seitenleiste → **Aufgabentafel**. Eine Kanban-Tafel deiner dsh-Projekte für dich und die Agenten: **Zu erledigen**, **In Arbeit**, **In Prüfung** und **Fertig** (und **Warteliste**, siehe unten). Wähle links ein Projekt oder **Alle Projekte**. **Neue Aufgabe** (oder `n`) öffnet eine neue Karte: Gib ihren Titel ein und drücke `Enter`. Ziehe eine Karte in eine andere Spalte oder zwischen zwei Karten. Klicke auf eine Karte, um **Status**, **Schlagwörter**, **Manuell** (Agenten überspringen sie), Beschreibung (Markdown) und Kommentare zu sehen und zu ändern. `/` sucht in allen Projekten, `h` zeigt nur manuelle Aufgaben, und die Export-Schaltfläche speichert die Tafel als Markdown oder JSON. Agenten bekommen Tafel-Tools: Bitte einen Chat, „die nächste Aufgabe von der Tafel zu nehmen“, dann schiebt er die oberste Karte aus **Zu erledigen** nach **In Arbeit**, kommentiert, was er getan hat, und schiebt sie nach **In Prüfung**; nach **Fertig** schiebst du sie. In einem Projekt mit offenen Aufgaben bekommt jeder Chat diese Regel von selbst. Einstellungen → Composer Plus → **Aufgabentafel** hat den Schalter für die Spalte **Warteliste**: Ihre Karten überlassen die Agenten dir. | <a href="assets/features/taskBoard.webp"><img src="assets/features/taskBoard.webp" width="160" alt="Screenshot: Aufgabentafel"></a> |
 | **Projektgedächtnis** | <a id="feature-projectmemory"></a>Standardmäßig aus: Schalte die Funktion unter **Einstellungen → Composer Plus** ein. Jeder Projektordner bekommt ein eigenes Gedächtnis, das spätere Chats dieses Projekts lesen, so wie DS Bot eines pro Bot führt. Nach jeder abgeschlossenen Runde liest ein Aufruf an das Modell des Chats die neuen Nachrichten (keine zurückgenommenen), speichert deine dauerhaften Vorlieben, Entscheidungen und Fakten als kurze Notizen und ändert oder entfernt alte. Der Agent kann Notizen auch selbst speichern, entfernen und suchen (`memory_remember`, `memory_forget`, `memory_recall`). Eine Notiz kann auch global sein: Jedes Projekt liest sie. Ein neuer Chat bekommt die Notizen in seinem Systemprompt; eine später gespeicherte Notiz erscheint ab dem nächsten Chat. Die Dateien sind Markdown im dsh-Basisordner (`storages/dsh-composer-plus/memory/`), nie im Projektordner. **Gedächtnis öffnen** in derselben Zeile zeigt alle gespeicherten Notizen nach Projekt gruppiert (und das globale Gedächtnis), mit einem Filter. Schreibe in eigenen Worten, was sich ändern soll (zum Beispiel „ich nutze jetzt pnpm statt yarn“), dann **Änderungen ansehen**: Das Standardmodell von dsh schlägt die Änderungen vor, und erst **Anwenden** speichert sie. In Tether: Menü des Chat-Titels → Project memory. | <a href="assets/features/projectMemory.webp"><img src="assets/features/projectMemory.webp" width="160" alt="Screenshot: Projektgedächtnis"></a> |
 | **Für diesen Chat zulassen** | <a id="feature-allowforchat"></a>Wenn die automatische Prüfung dich fragt, bekommt die Genehmigungskarte **Für diesen Chat zulassen**: Dasselbe Tool ist im selben Chat ab dann erlaubt, mit beliebigen Argumenten, bis das Zeitlimit abläuft (standardmäßig 1 Stunde; wähle es unter **Einstellungen → Composer Plus → Für diesen Chat zulassen**). Danach fragt der Agent wieder. Ein Chip in der Kopfzeile listet die Freigaben mit ihrer Endzeit auf und widerruft sie. Freigaben bleiben nach einem Neustart erhalten. | <a href="assets/features/allowForChat.webp"><img src="assets/features/allowForChat.webp" width="160" alt="Screenshot: Für diesen Chat zulassen"></a> |
 | **Projektstatus** | <a id="feature-projectstatus"></a>Eine Projektzeile in der Seitenleiste zeigt dieselbe Markierung (Spinner / wartet / fertig) wie ihre Chats. So zeigt auch ein eingeklapptes Projekt, dass ein Chat darin arbeitet oder dich braucht. Ein Chat, der auf dich wartet, kommt zuerst, dann ein fertiger Chat, den du noch nicht geöffnet hast (der grüne Punkt, auch während ein anderer Chat noch läuft), dann der Spinner. Fahre mit der Maus darüber, um Details zu sehen. In der Ansicht **Arbeitsbereichsbaum** zeigt die Zeile eines übergeordneten Ordners auch die Chats jedes Projekts darin (zum Beispiel jedes Branch-Ordners in `.worktrees/`), auch wenn der Ordner eingeklappt ist. | <a href="assets/features/projectStatus.webp"><img src="assets/features/projectStatus.webp" width="160" alt="Screenshot: Projektstatus"></a> |
@@ -166,7 +169,9 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 - **Zielprüfung:** Sie läuft nur, wenn der Agent ein `/goal` in einem automatischen Durchlauf als abgeschlossen markiert (oder wenn du auf **Jetzt ausführen** klickst). Die Host-Hälfte führt den Testbefehl im Ordner des Chats im Sandbox-Modus des Chats aus (wie das eigene `bash`-Werkzeug von dsh: dieselbe Richtlinie für den Dateizugriff; kann diese Sandbox nicht starten, läuft der Test nicht und die Prüfung schlägt fehl). Um den Befehl zu finden, liest sie nur `package.json`, `Makefile`, `Cargo.toml`, `go.mod`, `pyproject.toml` und `pytest.ini`, als reguläre Dateien im Ordner (kein Symlink aus dem Ordner hinaus, kein FIFO). Dann sendet sie das Ziel, den Chat seit dem Start des Ziels (deine Nachrichten, die Antworten des Agenten, Werkzeugaufrufe gekürzt auf 1.000 Zeichen und die letzten 2.000 Zeichen jedes Werkzeugergebnisses; kein Reasoning, keine zurückgenommenen Schritte; höchstens etwa 60.000 Zeichen, den neuesten Teil), `git status --short` und das Ende der Testausgabe als eine einzige Anfrage ohne Werkzeuge an das unter **Zielprüfung** gewählte Modell (standardmäßig das eigene Modell des Chats). Werkzeugausgaben können enthalten, was der Agent gelesen hat. Daher kann diese Anfrage Teile deiner Dateien enthalten, so wie der Chat selbst. In den Chat und ins Projekt wird nichts geschrieben. Dein Testbefehl, die Limits, das letzte Ergebnis (mit dem Ende seiner Ausgabe) und die Modellwahl liegen in `$DSH_HOME/storages/dsh-composer-plus/goal-check.json` (Datei nur für den Besitzer, die neuesten 500 Chats).
 - **In einem neuen Chat fortsetzen:** Nichts läuft, bis du darauf klickst. Dann sendet die Host-Hälfte den Chat (so, wie die Zielprüfung ihn liest: kein Reasoning, keine zurückgenommenen Schritte) an das eigene Modell des Chats und zeigt die Übergabenotiz. Nur **Neuen Chat starten** erstellt einen neuen Chat. Ins Projekt wird nichts geschrieben.
 - **Kontextaufschlüsselung:** Die Host-Hälfte liest nur das Chatprotokoll. Kein Modellaufruf, keine Projektdatei.
+- **Aufgabentafel:** Die Tafel (Titel, Beschreibungen, Schlagwörter und Kommentare deiner Aufgaben, die Pfade der Projektordner und ihre kurzen IDs) liegt in `$DSH_HOME/storages/dsh-composer-plus/board.json` (Datei nur für den Besitzer); der Schalter liegt daneben in `board-switch.json`. Nichts verlässt deinen Rechner, und nichts wird in einen Projektordner geschrieben. Die Tafel-Tools geben den Agenten, was du auf die Tafel geschrieben hast; der Text einer Aufgabe erreicht also das Modell des Chats, wenn ein Agent sie liest. Eine beschädigte Tafel-Datei wird als `board.json.broken-<time>` aufbewahrt, und die Tafel beginnt leer.
 - **Geschützte Dateien:** Die Liste und der Schalter liegen in `$DSH_HOME/storages/dsh-composer-plus/protected-files.json` (Datei nur für den Besitzer). Die Prüfung liest nur den Pfad jedes Aufrufs eines Datei-Tools (und seinen echten Pfad), nie die Datei.
+- **Blockierte Befehle:** Die Regeln und der Schalter liegen in `$DSH_HOME/storages/dsh-composer-plus/blocked-commands.json` (Datei nur für den Besitzer). Die Prüfung liest nur den Befehlstext jedes Aufrufs von `bash` und `pwsh`; sie führt nichts aus und sendet nichts.
 - **Projektgedächtnis:** aus, bis du es einschaltest. Solange es an ist, schickt der Host-Teil nach jeder abgeschlossenen Runde eines Chats der obersten Ebene die neuen Nachrichten dieses Chats seit der letzten Prüfung (deine Nachrichten und die Textantworten des Agenten; keine Werkzeugausgabe, kein Reasoning, kein verborgener Kontext, keine zurückgenommenen Nachrichten; in einem abgezweigten Chat bleibt die Kopie des Eltern-Chats weg; höchstens etwa 16.000 Zeichen) und die gespeicherten Notizen an das Modell des Chats, als eine Anfrage ohne Werkzeuge. Die Notizen sind Markdown-Dateien unter `$DSH_HOME/storages/dsh-composer-plus/memory/` (nur für den Eigentümer): `projects/<id>/` für jeden Projektordner (`<id>` ist ein Hash des echten Pfads des Ordners; `project.json` nennt den Ordner), `global/`, `journal.jsonl` (jede Änderung mit der Zeile davor und danach) und `reviewed.json` (wie weit jeder Chat gelesen wurde). In den Projektordner wird nichts geschrieben. Notizen, die wie ein Schlüssel, ein Token, ein Passwort oder eine Ausweisnummer aussehen, werden abgelehnt. Die Notizen eines Projekts kommen in den Systemprompt jedes neuen Chats in diesem Ordner und gehen so mit jeder Anfrage dieses Chats an das Modell. Der Schalter liegt in `memory.json` am selben Ort. **Gedächtnis öffnen** schickt nichts, bis du auf **Änderungen ansehen** klickst; dann schickt es die angezeigten Notizen und deinen Text als eine Anfrage ohne Werkzeuge an das Standardmodell von dsh. Die Änderungen werden erst mit **Anwenden** geschrieben, mit `editor` im Journal. Tether liest und ändert die Notizen über dieselbe Route.
 - **Sicherung:** Nichts verlässt deinen Rechner. Archive landen in `~/Desktop/dsh-backups` (Dateien nur für den Besitzer). Geheimnisse sind nicht im Archiv: Dateien mit Anmeldedaten (`.credentials.yaml`, `.env`), Schlüsseldateien (`.pem`, `.key`, `.p12`, `.pfx`) und die Werte der Einstellungen token, secret, password und API-Schlüssel in den yml-Dateien werden maskiert. Ihre echten Kopien bleiben in `composer-plus-vault/<archive>/` im selben Ordner (nur für den Besitzer), nur auf diesem Computer. **Für einen anderen Computer** kopiert keinen vault: Gib diese Geheimnisse dort neu ein. Deine Chatprotokolle, Einstellungen und der Rest des dsh-Home liegen unverändert im Archiv: Halte den Ordner privat, so wie `$DSH_HOME` selbst. Die Sicherung liest Dateien mit `O_NOFOLLOW | O_NONBLOCK`. Ein Symlink wird als Link gespeichert (nie verfolgt), ein FIFO oder Gerät wird übersprungen. Schalter und Einstellungen der automatischen Sicherung liegen in `$DSH_HOME/storages/dsh-composer-plus/auto-backup.json`, der Schalter der Rettungskonsole in `rescue-console.json`. Solange dsh läuft, nennt `running/host-<pid>.json` jeden dsh-Prozess (die Rettungskonsole liest diese Dateien, um eine Wiederherstellung abzulehnen).
 - **Rettungskonsole:** ein Menü im Terminal; sie öffnet keinen Netzwerkport. Eine Wiederherstellung schreibt nur in einen neuen Ordner neben dem dsh-Home (Dateien mit `O_EXCL | O_NOFOLLOW`, Symlinks zuletzt und nie verfolgt). Sie lehnt ein Archiv ab, das einen unsicheren Namen (`..`, einen absoluten Pfad), ein Gerät oder FIFO, mehr als einen obersten Ordner oder einen Eintrag unter einem Link enthält.
@@ -189,7 +194,7 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 - **Kein Branch-Etikett an einer Chatzeile:** Der Chat hatte seit der Installation dieser Version keine Runde, sein Ordner ist kein git-Repository, oder **Git-Branch in Chatzeilen** ist aus. Starte dsh nach einem Update neu (die Host-Hälfte zeichnet den Branch auf).
 - **Zielprüfung meldet, dass der Test mit Code 127 oder „not found“ beendet wurde:** Ein dsh, das aus dem Finder oder dem Dock gestartet wurde, kann einen kürzeren PATH als dein Terminal haben und findet daher `npm`, `pnpm` oder `cargo` nicht. Starte dsh aus einem Terminal, oder lege unter **Zielprüfung** → **Bearbeiten** deinen eigenen Testbefehl mit dem vollständigen Pfad fest. **Jetzt ausführen** zeigt das Ergebnis sofort.
 - **Das Ziel schließt sich nicht und der Agent arbeitet weiter:** **Zielprüfung** hat einen fehlschlagenden Test oder fehlende Arbeit gefunden. Die Zeile unter dem Ziel zeigt den Grund (fahre mit der Maus über das Ergebnis, um die Details zu sehen). Behebe die Ursache oder den Testbefehl, oder schließe das Ziel selbst mit `/goal` oder der Zielleiste ab (das wird nicht geprüft).
-- **Die Installation schlägt direkt nach einem Release fehl:** Gib die Version mit an (`dsh-composer-plus@1.17.0`), siehe den Hinweis zur Installation oben.
+- **Die Installation schlägt direkt nach einem Release fehl:** Gib die Version mit an (`dsh-composer-plus@1.18.0`), siehe den Hinweis zur Installation oben.
 - **Jetzt sichern meldet „Eine andere Sicherungsaktion läuft“:** Eine Aktion läuft in einem anderen dsh-Fenster oder in der Rettungskonsole (sie teilen sich eine Sperrdatei, `.composer-plus.lock`, im Sicherungsordner). Warte, bis sie fertig ist. Läuft keine Aktion, wird die Sperre eines beendeten Prozesses beim nächsten Klick übernommen.
 - **Die Rettungskonsole meldet „dsh is running“:** Beende zuerst dsh. Ist dsh wirklich geschlossen, ist die in der Meldung genannte Datei von einem Absturz übrig: Entferne sie und versuche es erneut.
 - **Nach einer Wiederherstellung startet dsh nicht oder ein Plugin fehlt:** Die Plugin-Pakete eines Profils müssen neu installiert werden. Die Rettungskonsole bietet das nach einer Wiederherstellung an; oder führe `pnpm install` in jedem Ordner unter `$DSH_HOME/profiles/` aus, den sie auflistet. Geheimnisse, die nicht im vault waren (anderer Computer), müssen neu eingegeben werden: Die Konsole listet sie auf.
@@ -239,8 +244,11 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 - **Prompt verbessern** sieht nur eine kurze Projektzusammenfassung, die geänderten Pfade und die Pfade, deren Namen zu deinen Wörtern passen: nicht den Code selbst. Daher kann die Funktion die richtige Datei übersehen, und sie nennt nur Pfade, die sie bekommen hat. Lies den neuen Text, bevor du ihn sendest. Sie läuft nicht bei einem anderen Slash-Befehl als `/goal <Ziel>`, bei einem Steuerwort von `/goal` (`clear`, `pause`, `resume`) oder bei einer Nachricht mit einem Datei- oder Symbol-Chip (der neue Text ist reiner Text, der Chip ginge also verloren), und eine Nachricht kann höchstens 8.000 Zeichen haben. Für ein `/goal`-Ziel schreibt sie Bedingungen nur aus dem Entwurf und dem Kontext. Eine zu strenge Bedingung kann Zieldurchläufe kosten, lies sie also, bevor du sie sendest. Bilder bleiben angehängt: Nur der Text ändert sich. Jeder Klick kostet einen Modellaufruf; ein starkes Modell kann eine Minute brauchen (`Esc` bricht ab).
 - **Zielprüfung** prüft nur einen Abschluss, den der Agent in einem automatischen Zieldurchlauf macht: Einen Abschluss, um den du im Chat bittest, `/goal` und die Zielleiste prüft sie nicht. Der Agent kann die Tests oder die Dateien des Testbefehls selbst ändern; der Prüfer liest den Chat und kann das sehen, kann sich aber in beide Richtungen irren (ein falsches „nicht fertig“ kostet einen Durchlauf mehr; ein falsches „fertig“ schließt das Ziel). Der Prüfer sieht den Chat und `git status`, nicht den Code selbst. Ein Testlauf wird nur wiederverwendet, wenn der neueste Schritt des Agenten, der Dateien ändern kann, sein eigener erfolgreicher `bash`-Lauf genau desselben Befehls im selben Ordner war; ein Befehl mit einer Pipe (`| tail`) oder `&&` wird nicht wiederverwendet. Das Budget wird gemessen, wenn eine Runde endet. Daher kann eine Runde darüber hinausgehen. Das Token-Budget zählt auch die Aufrufe der Subagent-Chats des Chats (gelesen aus ihren gespeicherten Protokollen am Ende jeder Runde, daher dauert die Prüfung eines Chats mit vielen Subagents etwas länger). Die Nachweistabelle kommt aus der eigenen Lektüre des Chats durch den Prüfer: Einen Teil, den er bestätigt nennt, solltest du selbst ansehen, wenn er wichtig ist. `update_goal` wartet, während die Prüfung läuft (der Test höchstens 15 Minuten, der Prüfer höchstens 3 Minuten). Eine Abzweigung bekommt eine neue Chat-ID und startet daher ohne den eigenen Testbefehl und die Limits des übergeordneten Chats. Jeder Abschluss, der den Prüfer erreicht, kostet einen Modellaufruf.
 - **Geschützte Dateien** ist eine Leitplanke, keine Sandbox. Die Funktion deckt die eigenen Datei-Tools von dsh ab (`read`, `read_image`, `grep` auf eine Datei, `write`, `edit`, `str_replace_editor`). Ein Shell-Befehl (`cat .env`), ein Skript, das der Agent schreibt, die Shell eines Subagents, ein MCP-Tool, eine `glob`-Liste und ein `grep` über einen ganzen Ordner können eine geschützte Datei trotzdem erreichen. Für eine echte Grenze nutze die Sandbox-Modi von dsh oder halte Geheimnisse aus dem Projektordner heraus. Muster kennen `*`, `**` und `?`, nicht `{a,b}` oder `[ab]`, und sie ignorieren Groß- und Kleinschreibung.
+- **Blockierte Befehle** ist eine Leitplanke, keine Sandbox. Die Funktion liest nur den Befehlstext der Tools `bash` und `pwsh` von dsh. Eine Variable oder ein Alias, die den Befehl nennen (`CMD=npm; $CMD publish`), eine Shell-Funktion, eine Skriptdatei, die der Agent schreibt, ein anderes Programm (`python -c`, `node -e`, `make`), ein MCP-Tool und dein eigenes Terminal können ihn trotzdem ausführen. Eine Regel passt auf mehr, als du vielleicht willst: Jedes Wort eines Befehls kann der Befehlsname sein (`echo npm publish` passt auf `npm publish`), und zwischen den Wörtern der Regel können andere Wörter stehen (`git push --force` passt auch auf `git push origin main --force`). Mach eine Regel länger, wenn sie auf zu viel passt. Eine Regel mit **zuerst fragen** braucht einen Chat, der fragen kann: In einem Chat mit der Genehmigungsrichtlinie „never“ (zum Beispiel einem delegierten Subagenten) kann dsh die Karte nicht zeigen, deshalb wird der Aufruf mit dem Grund abgelehnt. Die Genehmigungskarte zeigt den Grund auf Englisch. **Für diesen Chat zulassen** beantwortet keine Karte von **zuerst fragen**.
 - **In einem neuen Chat fortsetzen** sendet den Chat (Nachrichten, Werkzeugaufrufe und das Ende jedes Werkzeugergebnisses, höchstens etwa 60.000 Zeichen, den neuesten Teil) an das eigene Modell des Chats. Die Übergabenotiz kann eine Entscheidung oder eine Datei auslassen: Lies sie vor dem Start. Der neue Chat kennt nur die Notiz und den verlinkten Chat (dsh hängt den alten Chat als schreibgeschützten Kontext an). Sein Modellkontext beginnt klein, der alte Chat bleibt, wie er ist. Pro Chat läuft immer nur eine Notiz oder ein Start.
 - **Kontextaufschlüsselung** zeigt Schätzungen nach der eigenen Regel von dsh (etwa 4 Zeichen pro Token), derselben Regel wie beim Kontextring von dsh. Die eigene Zählung des Modells kann abweichen. Die Tool-Definitionen sind die der neuesten Anfrage. Die Funktion zeigt den Kontext so, wie das Chatprotokoll ihn enthält. Eine Runde, die gerade läuft, erscheint nach ihrem nächsten Schritt.
+- **Geplante Schritte** spart nur dann Tokens, wenn das Modell plant: Solange die Funktion an ist, trägt jede Anfrage das Tool `plan_next_steps` und eine kurze Anweisung (etwa 500 Tokens), auch in Chats, in denen das Modell nie plant. Eine Bedingung beweist nur, was sie sagt (zum Beispiel: der Exit-Code des Builds war 0), nicht, dass die Arbeit stimmt. `ok` liest die eigenen Ergebnismarken von dsh (`[exit code: N]`, Zeitüberschreitungen, Sandbox-Ablehnungen); ein Befehl, der ohne Exit-Code ungleich null fehlschlägt, gilt als bestanden. Schritte laufen einzeln; zwei gleichzeitig bereite Schritte gehen an das Modell zurück. Die Nachricht des Schritts wird als Assistentennachricht des Chat-Modells gespeichert (dsh hat keine Markierung für eine Nachricht, die ein Plugin schreibt), daher sagt ihr Text, dass Composer Plus ihn ausgeführt hat. Nicht in Tether.
+- **Aufgabentafel** kennt nur die Projekte von dsh: Ein Chat außerhalb eines Projekts zeigt **Alle Projekte**, und der Ordner eines Branches pro Chat (`<project>/.worktrees/<name>`) zählt zu seinem Projekt. Die Projekt-IDs (`acme#12`) kommen aus dem Ordnernamen und bleiben, wenn du das Projekt in dsh umbenennst. Die Regel „halte die Tafel aktuell“ kommt nur dann in einen Chat, wenn sein Projekt offene Aufgaben hat; ein Chat, der sie bekommen hat, behält sie. Die Agenten werden angewiesen, **Fertig**, **Warteliste** und manuelle Aufgaben dir zu überlassen, aber die Tools lehnen es nicht ab: Ein Agent kann eine solche Karte trotzdem verschieben. Die Tafel-Tools stehen in der Tool-Liste jedes Chats, solange die Funktion an ist (etwa 1.000 Token pro Anfrage); schalte sie aus, wenn du die Tafel nicht nutzt. Die Seite liest die Tafel alle 2 Sekunden, solange sie angezeigt wird; eine Änderung durch einen Agenten erscheint innerhalb dieser Zeit. Ein Text, den du bearbeitest, während ein Agent dasselbe Feld ändert, wird nicht gespeichert: Das Panel zeigt den neuen Text und den Grund. Keine Bilder, kein Git-Abgleich zwischen Rechnern und kein Teilen über das Netzwerk (Kanzo hat das). Die Idee und das Aussehen stammen von [Kanzo](https://github.com/emanuele-em/kanzo) von emanuele-em (AGPL-3.0); Composer Plus nutzt keinen Code daraus.
 - **Neue Nachricht nach Stoppen zuerst** wirkt nur, nachdem du den Chat gestoppt hast (oder nach einer fehlgeschlagenen Runde, oder wenn du einen Chat öffnest, der noch eine Warteschlange hat): Eine Nachricht, die du sendest, während eine Runde läuft, wartet weiterhin am Ende der Warteschlange. Sie überholt nur deine eigenen eingereihten Nachrichten: Wartet eine Zielrunde oder eine Antwort auf eine Frage in der Warteschlange, bleibt die Reihenfolge von dsh. Die Funktion liest einen Teil von dsh, der keine öffentliche API ist (ob die gestoppte Runde noch endet); benennt ein dsh-Update ihn um, rückt die Nachricht erst vor, wenn diese Runde beendet ist. Subagent-Chats behalten die Reihenfolge von dsh.
 - **Projektgedächtnis** gehört zum ersten Ordner des Chats (dem Projektordner von dsh): Ein Chat, der seinen Ordner mit `cd` wechselt, behält das Gedächtnis seines ersten Projekts, und derselbe Ordner, über einen anderen Pfad zu denselben Dateien geöffnet, teilt es. Ein Chat friert seinen Gedächtnisteil beim Start ein, daher erscheint eine später gespeicherte Notiz ab dem nächsten Chat (`memory_recall` findet sie sofort). Die Prüfung behält nur, was das Modell behalten will: Sie kann einen Fakt übersehen oder einen falschen behalten. Prüfe sie in **Gedächtnis öffnen** und ändere sie dort, oder bearbeite die Dateien von Hand, während dsh geschlossen ist. **Gedächtnis öffnen** schickt die Notizen des gewählten Projekts und die globalen Notizen (alle Projekte, wenn du Alle Notizen wählst; höchstens etwa 60.000 Zeichen, der Rest wird nur gezählt und kann in dieser Anfrage nicht geändert werden) und deinen Text an das Standardmodell von dsh, nicht an das Modell des Chats. Eine Vorschau bleibt 30 Minuten und bis zum Neustart von dsh auf dem Mac; ändern eine Prüfung oder der Agent die Notizen in der Zwischenzeit, lehnt **Anwenden** ab und du holst eine neue Vorschau. **Anwenden** speichert alle Änderungen einer Vorschau oder keine: Lässt sich eine Änderung nicht speichern (zum Beispiel, weil MEMORY.md voll ist), bleiben die Notizen, wie sie waren, und der Grund wird angezeigt. Jede abgeschlossene Runde mit einer Nachricht von dir kostet einen Modellaufruf; ein fehlgeschlagener Aufruf liest dieselben Nachrichten nach der nächsten Runde erneut. Chats von Subagenten werden nicht geprüft. Die Idee und das Dateiformat stammen von [DS Bot](https://github.com/Fei2411/DS-Bot) (Apache-2.0); Composer Plus nutzt keinen Code daraus und liest oder schreibt nie das eigene Gedächtnis von DS Bot.
 - **Sicherung** nutzt einen einzigen festen Ordner, `~/Desktop/dsh-backups` (der Standardordner von dsh-backup, damit dessen Archive nutzbar bleiben); eine Einstellung für einen anderen Ordner gibt es nicht. Ein Archiv ist etwa so groß wie das dsh-Home ohne `cache/` und `dsh-runtimes/` (gemessen: 1,6 GB Dateien ergaben auf Apple Silicon in etwa 30 s ein Archiv von 830 MB; dsh reagierte weiter). Eine Datei, die sich beim Lesen ändert, wird so gespeichert, wie sie war, als die Sicherung sie geöffnet hat. Daher kann das Protokoll eines offenen Chats mit einem abgeschnittenen Datensatz enden, den dsh beim nächsten Schreiben repariert. Die Maskierung findet ein Geheimnis in einer yml-Datei am Namen seines Schlüssels in einer Zeile (`token:`, `apiKey:`, …); ein Geheimnis in einer Flow-Map (`{token: x}`), in einer Liste unter einem solchen Schlüssel, in einer JSON-Datei (zum Beispiel der `apiKey` eines MCP-Servers in einer `.json`-Datei) oder unter einem anderen Namen bleibt im Archiv. Die typisierten Archive von dsh-backup (`dsh-t-…`) werden nicht aufgelistet. **Für einen anderen Computer** kopiert das Archiv (unter APFS ein Klon: kein zusätzlicher Platz); der vault kommt nicht mit. **Jetzt sichern** löscht keine Sicherung. Eine automatische Sicherung behält die neuesten Sicherungen, die Composer Plus erstellt hat (die Einstellung **Behalten** von **Automatische Sicherung**), und löscht die älteren davon; Snapshots vor einem Upgrade werden getrennt gezählt (die neuesten 2 bleiben). Archive von dsh-backup werden nie gelöscht: Entferne sie mit **Löschen**. Solange dsh-backup noch installiert ist, zählt es die Archive von Composer Plus zu seiner eigenen Anzahl behaltener Sicherungen und kann sie löschen.
@@ -277,6 +285,8 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 
 **Kann sich der Agent meine Vorlieben über Chats hinweg merken, wie das Gedächtnis von DS Bot?** Ja, mit **Projektgedächtnis** (standardmäßig aus): Schalte es unter **Einstellungen → Composer Plus** ein. Nach jeder Runde werden deine dauerhaften Vorlieben und Entscheidungen als kurze Notizen für das Projekt des Chats gespeichert, und jeder neue Chat in diesem Projekt liest sie. Bitte den Agenten, sich etwas zu merken, dann speichert er es sofort. Um die Notizen zu sehen oder zu ändern, klicke in derselben Zeile auf **Gedächtnis öffnen** und schreibe, was sich ändern soll.
 
+**Können meine Agenten und ich eine gemeinsame Aufgabentafel nutzen, wie bei Kanzo?** Ja, mit **Aufgabentafel** (standardmäßig an): Öffne sie in der linken Seitenleiste und füge Aufgaben mit **Neue Aufgabe** hinzu. Bitte den Agenten in einem Chat, „die nächste Aufgabe von der Tafel zu nehmen“: Er schiebt die Karte nach **In Arbeit**, kommentiert, was er getan hat, und schiebt sie nach **In Prüfung**. Markiere eine Aufgabe als **Manuell**, um sie für dich zu behalten.
+
 **Kann dsh meine Chats und Einstellungen sichern, so wie dsh-backup?** Ja: **Einstellungen → Composer Plus → Sicherung → Jetzt sichern**. Es schreibt dasselbe Archivformat in denselben Ordner (`~/Desktop/dsh-backups`). Daher erscheinen auch die Archive von dsh-backup und lassen sich wiederherstellen, und du kannst dsh-backup entfernen. Schalte **Automatische Sicherung** ein, um nach Zeitplan zu sichern.
 
 **dsh startet nicht mehr. Wie stelle ich eine Sicherung wieder her?** Öffne den Sicherungsordner (`~/Desktop/dsh-backups`) und doppelklicke auf `Composer Plus Rescue.command` (Linux: `composer-plus-rescue.sh`, Windows: `Composer Plus Rescue.cmd`). Wähle `3) Restore a backup`, wähle eine Sicherung aus und tippe `RESTORE`. Das funktioniert ohne dsh.
@@ -301,6 +311,8 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 
 **Wie sehe ich nur die Dateien, die ein Chat geändert hat?** Rechte Seitenleiste → **Änderungen** → **Dieser Chat**. Klicke auf **␣**, um Änderungen auszublenden, die nur Leerraum sind.
 
+**Wie verhindere ich, dass der Agent `npm publish` oder `git push --force` ausführt?** **Einstellungen → Composer Plus → Blockierte Befehle**: Gib `npm publish` ein, wähle **blockieren** oder **zuerst fragen** und klicke dann auf **Hinzufügen**. Eine Regel mit **blockieren** lehnt den Befehl ab, und der Agent fragt dich; eine Regel mit **zuerst fragen** zeigt jedes Mal die Genehmigungskarte. „Geschützte Dateien“ deckt die Datei-Tools des Agenten ab, „Blockierte Befehle“ seine Shell-Befehle.
+
 **Wie verhindere ich, dass die automatische Prüfung in einem Chat immer wieder nach demselben Tool fragt?** Klicke auf der Genehmigungskarte auf **Für diesen Chat zulassen**. Das gilt nur für genau dieses Tool in diesem Chat, standardmäßig für 1 Stunde. Widerrufe es über den Chip in der Kopfzeile. Ändere die Zeit unter **Einstellungen → Composer Plus → Für diesen Chat zulassen**.
 
 **Ich habe mein iPhone verloren. Wie verhindere ich, dass es meinen Mac erreicht?** Klicke unten links in der Seitenleiste auf **Mobile Verbindung** und dann neben diesem iPhone auf **Remove**. Sein Schlüssel funktioniert sofort nicht mehr. Es kann nur mit einer neuen Kopplung zurückkommen, die du auf dem Mac bestätigst.
@@ -329,6 +341,8 @@ Getestet mit dsh `0.2.0-rc.2` (Desktop und Web) und `0.2.1-rc.2` (Web). Die CI f
 
 **Kann ich ein Foto von meinem iPhone senden?** Ja. Tippe in einem Tether-Chat auf **+** neben dem Nachrichtenfeld → Camera, Photos (bis zu 4) oder Paste image. Die Fotos kommen als Anhänge deiner Nachricht in den Chat auf dem Mac, daher sieht das Modell sie.
 
+**Kann dsh den nächsten Befehl ausführen, ohne das Modell erneut zu fragen?** Ja, mit **Geplante Schritte** (standardmäßig aus): Schalte die Funktion unter Einstellungen → Composer Plus ein. Das Modell kann dann seine nächsten Befehle mit einer Bedingung planen, etwa „führe die Tests aus, wenn der Build gelingt“, und Composer Plus führt einen Schritt ohne neuen Modellaufruf aus, wenn das Ergebnis die Bedingung erfüllt. Freigaben und Sandbox bleiben, wie sie sind.
+
 **Funktioniert es mit der Desktop-App?** Ja: Einstellungen → Plugins → **Plugin hinzufügen** → `dsh-composer-plus`. Getestet mit dsh 0.2.0-rc.2 (Desktop und Web) und 0.2.1-rc.2 (Web).
 
 ## Entwicklung
@@ -393,6 +407,8 @@ PLAYWRIGHT=/path/to/playwright node test/browser-continue-queue.mjs /path/to/dsh
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-stop-send.mjs /path/to/dsh/lib/bin.js
 # Edit queued message in place with images and files (slow fake model) + its thumbnail
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-edit.mjs /path/to/dsh/lib/bin.js
+# Task board: the page, the agent tools (fake model), drag and drop, search, the switch
+SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-task-board.mjs /path/to/dsh/lib/bin.js
 ```
 
 ```sh

package/README.es.md

@@ -29,7 +29,7 @@ dsh plugin --profile web add dsh-composer-plus
 
 Después, reinicia dsh. (La CLI no puede instalar en el perfil de escritorio: de eso se encarga la app).
 
-> El pnpm de dsh omite las versiones publicadas hace menos de 24 horas. Justo después de una versión nueva, añade la versión: `dsh-composer-plus@1.17.0`.
+> El pnpm de dsh omite las versiones publicadas hace menos de 24 horas. Justo después de una versión nueva, añade la versión: `dsh-composer-plus@1.18.0`.
 
 ## Funciones
 
@@ -68,7 +68,10 @@ Después, reinicia dsh. (La CLI no puede instalar en el perfil de escritorio: de
 | **Comprobación del objetivo** | <a id="feature-goalcheck"></a>Empieza un objetivo con `/goal`. Cuando el agente marca el objetivo como completado en una ronda automática, el objetivo solo se cierra tras dos comprobaciones. Primero, el comando de prueba del proyecto se ejecuta en la carpeta del chat, con el modo sandbox del chat. El comando es el tuyo o el que se encuentra en `package.json`, `Makefile`, `Cargo.toml`, `go.mod` o pytest. Si el paso más reciente del propio agente fue una ejecución correcta de esa prueba, no se vuelve a ejecutar. Después, una llamada independiente al modelo, sin herramientas, lee el objetivo, este chat, `git status` y el resultado de la prueba. El modelo responde con una tabla de evidencias: cada parte del objetivo queda verificada, incorrecta o sin resolver, con la evidencia y la corrección; el objetivo solo se cierra cuando todas las partes están verificadas. Si una comprobación falla, el objetivo sigue activo y el agente lee cada parte abierta con su evidencia y su corrección; luego continúa la ronda siguiente. Una fila bajo la barra del objetivo (**Comprobación del objetivo**) muestra la prueba, el último resultado y cuántas partes se verificaron (pasa el puntero por encima para ver la tabla). **Editar** define tu propio comando de prueba y un límite de tiempo o de tokens; al superar el límite, el objetivo queda bloqueado. El límite de tokens también cuenta los subagentes del chat. **Ejecutar ahora** ejecuta la comprobación sin cerrar el objetivo. Tiene su propio menú **Modelo** en Configuración (predeterminado: **Igual que el modelo del chat**). Cuando completas el objetivo tú mismo, no se comprueba nada. | <a href="assets/features/goalCheck.webp"><img src="assets/features/goalCheck.webp" width="160" alt="Captura: Comprobación del objetivo"></a> |
 | **Continuar en un chat nuevo** | <a id="feature-handoffchat"></a>Haz clic derecho en un chat de la barra lateral (o abre su menú **…**) → **Continuar en un chat nuevo…**. Una llamada al propio modelo del chat escribe una nota de traspaso con lo que muestra el chat: Tarea, Resultados, Completado, Decisiones, Problemas abiertos y Siguiente acción (las llamadas a herramientas y sus resultados son la evidencia; los pasos que revertiste se omiten). La nota se abre en un diálogo: léela y edítala. **Volver a escribir** escribe una nota nueva. **Iniciar chat nuevo** (o `Cmd/Ctrl+Enter`) abre un chat nuevo en el mismo proyecto con la nota y un enlace al chat anterior como primer mensaje; el chat anterior queda como está. Úsalo cuando un chat largo esté lleno o lento, o para continuar mañana. No se escribe nada en el proyecto. | <a href="assets/features/handoffChat.webp"><img src="assets/features/handoffChat.webp" width="160" alt="Captura: Continuar en un chat nuevo"></a> |
 | **Desglose del contexto** | <a id="feature-contextbreakdown"></a>Barra lateral derecha → `+` → **Contexto**. La página muestra qué llena ahora el contexto del modelo del chat abierto y cuánto de la ventana de contexto usa: el prompt del sistema, las instrucciones del proyecto (AGENTS.md), las skills, tus mensajes, las respuestas del agente y las llamadas a herramientas, los resultados de herramientas (por herramienta), los resultados de MCP (por servidor), las definiciones de herramientas, el resumen de compactación y otras notas de contexto, cada uno con sus tokens y su parte. Haz clic en una parte para ver sus herramientas o servidores. Solo lee el registro del chat, después de `/compact` y de las reversiones, y no llama a ningún modelo; vuelve a leerlo después de cada turno y con **Actualizar**. Úsalo para ver por qué un chat está lento o lleno, por ejemplo por un resultado grande de una herramienta MCP o por muchas definiciones de herramientas. | <a href="assets/features/contextBreakdown.webp"><img src="assets/features/contextBreakdown.webp" width="160" alt="Captura: Desglose del contexto"></a> |
+| **Pasos planificados** | <a id="feature-plannedsteps"></a>Desactivada de forma predeterminada: actívala en **Configuración → Composer Plus**. El agente recibe la herramienta `plan_next_steps`: en el mismo mensaje que un comando, puede planificar los siguientes comandos con sus argumentos exactos y una condición, por ejemplo «ejecuta `npm test` cuando la compilación pase». Cuando el resultado cumple la condición, Composer Plus ejecuta el siguiente paso por sí mismo, sin una nueva llamada al modelo, así un chat largo usa menos tokens. El paso aparece en el chat como una línea corta, «Composer Plus · Planned steps: ran `test` … without a model call», seguida de su llamada a la herramienta y su resultado. Solo pasos de `bash`, `read`, `grep` y `glob`; las aprobaciones, el sandbox y Archivos protegidos se aplican a cada paso como siempre. El modelo vuelve a responder cuando una condición falla, cuando dos pasos están listos a la vez, después del último paso y cuando envías un mensaje. La idea viene de HarnessMM (arXiv 2610.32813). | <a href="assets/features/plannedSteps.webp"><img src="assets/features/plannedSteps.webp" width="160" alt="Captura: Pasos planificados"></a> |
 | **Archivos protegidos** | <a id="feature-protectedfiles"></a>Activado de forma predeterminada. Las herramientas de archivos propias del agente no pueden leer ni cambiar los archivos que coinciden con tus patrones: `read`, `read_image` y `grep` sobre un archivo se rechazan con los patrones de **lectura y escritura**, y `write`, `edit` y `str_replace_editor` con los dos tipos. El agente lee el motivo y se le indica que te pregunte. Los patrones predeterminados son `.env*`, `*.pem` y `*.key`. Configuración → Composer Plus → **Archivos protegidos**: añade un patrón (por ejemplo `published/**` o `config/*.yml`), haz clic en su tipo para cambiar entre **lectura y escritura** y **solo escritura**, quítalo con ✕ o haz clic en **Usar los valores predeterminados**. Un patrón sin `/` coincide con un nombre de archivo en cualquier carpeta. Es una barrera de protección, no un sandbox: un comando de shell (`cat .env`), un script o una herramienta MCP aún pueden llegar al archivo (consulta Límites). | <a href="assets/features/protectedFiles.webp"><img src="assets/features/protectedFiles.webp" width="160" alt="Captura: Archivos protegidos"></a> |
+| **Comandos bloqueados** | <a id="feature-blockedcommands"></a>Activado de forma predeterminada, con una lista vacía. Los comandos de shell del agente (`bash`, `pwsh`) no pueden ejecutar un comando que coincida con tus reglas: una regla **bloquear** rechaza la llamada (el agente lee el motivo y se le indica que te pregunte), una regla **preguntar antes** muestra la tarjeta de aprobación de dsh, y el comando solo se ejecuta cuando tú lo permites. Configuración → Composer Plus → **Comandos bloqueados**: escribe una regla (por ejemplo `npm publish`, `git push --force` o `ssh *192.168.2.19`), haz clic en el tipo para cambiar entre **bloquear** y **preguntar antes** y luego haz clic en **Añadir**; haz clic en el tipo de una regla para cambiarlo y quítala con ✕. Una regla es un nombre de comando y palabras que deben venir después de él en este orden; `*` coincide con cualquier texto. La comprobación también encuentra el comando después de `&&`, `;`, `\|`, dentro de `$(…)`, `bash -c "…"` o `eval`, y después de `sudo` o `env`. Es una barrera de protección, no un sandbox: una variable (`$CMD`), un archivo de script u otro programa aún pueden ejecutar el comando (consulta Límites). | <a href="assets/features/blockedCommands.webp"><img src="assets/features/blockedCommands.webp" width="160" alt="Captura: Comandos bloqueados"></a> |
+| **Tablero de tareas** | <a id="feature-taskboard"></a>Barra lateral izquierda → **Tablero de tareas**. Un tablero kanban de tus proyectos de dsh, para ti y para los agentes: **Por hacer**, **En curso**, **En revisión** y **Hecho** (y **En espera**, ver abajo). Elige un proyecto o **Todos los proyectos** a la izquierda. **Nueva tarea** (o `n`) abre una tarjeta nueva: escribe su título y pulsa `Enter`. Arrastra una tarjeta a otra columna o entre dos tarjetas. Haz clic en una tarjeta para ver y cambiar su **Estado**, sus **Etiquetas**, **Manual** (los agentes la omiten), la descripción (Markdown) y los comentarios. `/` busca en todos los proyectos, `h` muestra solo las tareas manuales y el botón de exportar guarda el tablero como Markdown o JSON. Los agentes reciben herramientas del tablero: pide a un chat que "tome la siguiente tarea del tablero" y moverá la primera tarjeta de **Por hacer** a **En curso**, comentará lo que hizo y la moverá a **En revisión**; tú la mueves a **Hecho**. En un proyecto con tareas abiertas, cada chat recibe esta regla por sí solo. Configuración → Composer Plus → **Tablero de tareas** tiene el interruptor de la columna **En espera**: los agentes te dejan sus tarjetas a ti. | <a href="assets/features/taskBoard.webp"><img src="assets/features/taskBoard.webp" width="160" alt="Captura: Tablero de tareas"></a> |
 | **Memoria del proyecto** | <a id="feature-projectmemory"></a>Desactivada de forma predeterminada: actívala en **Configuración → Composer Plus**. Cada carpeta de proyecto tiene su propia memoria, que los chats posteriores de ese proyecto leen, como DS Bot guarda una por Bot. Después de cada turno terminado, una llamada al modelo del chat lee los mensajes nuevos (no los revertidos), guarda tus preferencias, decisiones y datos duraderos como notas breves, y cambia o elimina las antiguas. El agente también puede guardar, eliminar y buscar notas por sí mismo (`memory_remember`, `memory_forget`, `memory_recall`). Una nota también puede ser global: todos los proyectos la leen. Un chat nuevo recibe las notas en su prompt de sistema; una nota guardada después aparece desde el chat siguiente. Los archivos son Markdown en la carpeta de inicio de dsh (`storages/dsh-composer-plus/memory/`), nunca en la carpeta del proyecto. **Abrir memoria**, en la misma fila, muestra todas las notas guardadas agrupadas por proyecto (y la memoria global), con un filtro. Escribe con tus palabras qué cambiar (por ejemplo "cambié yarn por pnpm") y pulsa **Vista previa de los cambios**: el modelo predeterminado de dsh propone los cambios y solo **Aplicar** los guarda. En Tether: menú del título del chat → Project memory. | <a href="assets/features/projectMemory.webp"><img src="assets/features/projectMemory.webp" width="160" alt="Captura: Memoria del proyecto"></a> |
 | **Permitir en este chat** | <a id="feature-allowforchat"></a>Cuando la revisión automática te pregunta, la tarjeta de aprobación muestra **Permitir en este chat**: a partir de entonces, la misma herramienta en el mismo chat queda permitida, con cualquier argumento, hasta que termina el límite de tiempo (1 hora por defecto; elígelo en **Configuración → Composer Plus → Permitir en este chat**). Después, el agente vuelve a preguntar. Un chip en la cabecera muestra los permisos concedidos con su hora de fin y permite revocarlos. Los permisos se mantienen tras un reinicio. | <a href="assets/features/allowForChat.webp"><img src="assets/features/allowForChat.webp" width="160" alt="Captura: Permitir en este chat"></a> |
 | **Estado del proyecto** | <a id="feature-projectstatus"></a>La fila de un proyecto en la barra lateral muestra el mismo indicador de en ejecución / en espera / terminado que sus chats, así que un proyecto contraído también te dice que un chat de dentro está trabajando o te necesita. Primero se muestra un chat que te espera, luego un chat terminado que aún no has abierto (el punto verde, también mientras otro chat sigue en ejecución) y luego el indicador de en ejecución. Pasa el puntero por encima para ver los detalles. En **Árbol de espacios de trabajo**, la fila de una carpeta superior también muestra los chats de cada proyecto que contiene (por ejemplo, cada carpeta de rama en `.worktrees/`), también cuando está contraída. | <a href="assets/features/projectStatus.webp"><img src="assets/features/projectStatus.webp" width="160" alt="Captura: Estado del proyecto"></a> |
@@ -166,7 +169,9 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 - **Comprobación del objetivo:** solo se ejecuta cuando el agente marca un `/goal` como completado en una ronda automática (o cuando haces clic en **Ejecutar ahora**). La parte Host ejecuta el comando de prueba en la carpeta del chat con el modo sandbox del chat (como la propia herramienta `bash` de dsh: la misma política de acceso a archivos; si ese sandbox no puede iniciarse, la prueba no se ejecuta y la comprobación falla). Para encontrar el comando solo lee `package.json`, `Makefile`, `Cargo.toml`, `go.mod`, `pyproject.toml` y `pytest.ini`, como archivos normales dentro de la carpeta (sin enlaces simbólicos que salgan de ella, sin FIFO). Después envía el objetivo, el chat desde que empezó el objetivo (tus mensajes, las respuestas del agente, las llamadas a herramientas recortadas a 1.000 caracteres y los últimos 2.000 caracteres de cada resultado de herramienta; sin razonamiento ni pasos revertidos; como máximo unos 60.000 caracteres, la parte más reciente), `git status --short` y el final de la salida de la prueba al modelo elegido en **Comprobación del objetivo** (de forma predeterminada, el modelo del propio chat), en una sola petición sin herramientas. La salida de las herramientas puede contener lo que leyó el agente, así que esta petición puede incluir partes de tus archivos, igual que el propio chat. No se escribe nada en el chat ni en el proyecto. Tu comando de prueba, los límites, el último resultado (con el final de su salida) y el modelo elegido están en `$DSH_HOME/storages/dsh-composer-plus/goal-check.json` (archivo solo para el propietario, los 500 chats más recientes).
 - **Continuar en un chat nuevo:** no se ejecuta nada hasta que haces clic. Entonces la parte Host envía el chat (tal como lo lee la Comprobación del objetivo: sin razonamiento ni pasos revertidos) al modelo del propio chat y muestra la nota de traspaso; solo **Iniciar chat nuevo** crea un chat nuevo. No se escribe nada en el proyecto.
 - **Desglose del contexto:** la parte Host solo lee el registro del chat; ninguna llamada al modelo, ningún archivo del proyecto.
+- **Tablero de tareas:** el tablero (títulos, descripciones, etiquetas y comentarios de tus tareas, las rutas de las carpetas de los proyectos y sus id cortos) está en `$DSH_HOME/storages/dsh-composer-plus/board.json` (archivo solo para el propietario); el interruptor está en `board-switch.json`, junto a él. Nada sale de tu equipo y no se escribe nada en ninguna carpeta de proyecto. Las herramientas del tablero dan a los agentes lo que escribiste en el tablero, así que el texto de una tarea llega al modelo del chat cuando un agente la lee. Un archivo del tablero dañado se guarda como `board.json.broken-<time>` y el tablero empieza vacío.
 - **Archivos protegidos:** la lista y el interruptor están en `$DSH_HOME/storages/dsh-composer-plus/protected-files.json` (archivo solo para el propietario). La comprobación solo lee la ruta de cada llamada a una herramienta de archivos (y su ruta real), nunca el archivo.
+- **Comandos bloqueados:** las reglas y el interruptor están en `$DSH_HOME/storages/dsh-composer-plus/blocked-commands.json` (archivo solo para el propietario). La comprobación solo lee el texto del comando de cada llamada a `bash` y `pwsh`; no ejecuta nada y no envía nada.
 - **Memoria del proyecto:** desactivada hasta que la actives. Mientras está activada, después de cada turno terminado de un chat de nivel superior, la parte Host envía los mensajes nuevos del propio chat desde la última revisión (tus mensajes y las respuestas de texto del agente; sin salida de herramientas, sin razonamiento, sin contexto oculto, sin mensajes revertidos; la copia del chat padre en un chat bifurcado queda fuera; como máximo unos 16.000 caracteres) y las notas guardadas al modelo del propio chat, como una sola petición sin herramientas. Las notas son archivos Markdown en `$DSH_HOME/storages/dsh-composer-plus/memory/` (archivos solo para el propietario): `projects/<id>/` para cada carpeta de proyecto (`<id>` es un hash de la ruta real de la carpeta; `project.json` nombra la carpeta), `global/`, `journal.jsonl` (cada cambio con la línea anterior y la posterior) y `reviewed.json` (hasta dónde se leyó cada chat). No se escribe nada en la carpeta del proyecto. Se rechazan las notas que parecen una clave, un token, una contraseña o un número de identificación. Las notas de un proyecto entran en el prompt de sistema de cada chat nuevo en esa carpeta, así que llegan al modelo con cada petición de ese chat. El interruptor está en `memory.json`, en la misma carpeta. **Abrir memoria** no envía nada hasta que pulsas **Vista previa de los cambios**; entonces envía las notas que muestra y tu texto al modelo predeterminado de dsh, en una sola petición sin herramientas. Sus cambios se escriben solo con **Aplicar**, con `editor` en el registro. Tether lee y cambia las notas por la misma ruta.
 - **Copia de seguridad:** nada sale de tu equipo. Los archivos comprimidos van a `~/Desktop/dsh-backups` (archivos solo para el propietario). Los secretos no están en un archivo comprimido: los archivos de credenciales (`.credentials.yaml`, `.env`), los archivos de claves (`.pem`, `.key`, `.p12`, `.pfx`) y los valores de los ajustes token, secret, password y API key de los archivos yml se ocultan; sus copias reales se quedan en `composer-plus-vault/<archive>/`, en la misma carpeta (solo para el propietario), solo en este equipo. **Para otro equipo** no copia ningún vault: vuelve a introducir esos secretos allí. Tus registros de chat, tus ajustes y el resto del directorio home de dsh están tal cual en el archivo comprimido: mantén la carpeta privada, igual que el propio `$DSH_HOME`. La copia de seguridad lee los archivos con `O_NOFOLLOW | O_NONBLOCK`; un enlace simbólico se guarda como enlace (nunca se sigue) y un FIFO o un dispositivo se omite. El interruptor y los ajustes de la copia de seguridad automática están en `$DSH_HOME/storages/dsh-composer-plus/auto-backup.json`, el interruptor de la consola de rescate en `rescue-console.json` y, mientras dsh se ejecuta, `running/host-<pid>.json` nombra cada proceso de dsh (la consola de rescate los lee para rechazar una restauración).
 - **Consola de rescate:** un menú de terminal; no abre ningún puerto de red. Una restauración solo escribe en una carpeta nueva junto al directorio home de dsh (archivos con `O_EXCL | O_NOFOLLOW`, enlaces simbólicos al final y nunca seguidos) y rechaza un archivo comprimido con un nombre inseguro (`..`, una ruta absoluta), un dispositivo o FIFO, más de una carpeta superior o una entrada bajo un enlace.
@@ -189,7 +194,7 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 - **No hay etiqueta de rama en una fila de chat:** el chat no tuvo ningún turno desde que instalaste esta versión, su carpeta no es un repositorio git o **Rama de Git en las filas de chat** está desactivada. Después de una actualización, reinicia dsh (la parte Host registra la rama).
 - **Comprobación del objetivo dice que la prueba terminó con el código 127 o «not found»:** dsh iniciado desde el Finder o el Dock puede tener un PATH más corto que tu terminal, así que no encuentra `npm`, `pnpm` ni `cargo`. Inicia dsh desde una terminal, o define tu propio comando de prueba con la ruta completa en **Comprobación del objetivo** → **Editar**. **Ejecutar ahora** muestra el resultado al momento.
 - **El objetivo no se cierra y el agente sigue trabajando:** **Comprobación del objetivo** encontró una prueba fallida o trabajo pendiente; la fila bajo el objetivo muestra el motivo (pasa el puntero por el resultado para ver los detalles). Corrige la causa o el comando de prueba, o completa el objetivo tú mismo con `/goal` o con la barra del objetivo (eso no se comprueba).
-- **La instalación falla justo después de una versión nueva:** añade la versión (`dsh-composer-plus@1.17.0`); consulta la nota de instalación de más arriba.
+- **La instalación falla justo después de una versión nueva:** añade la versión (`dsh-composer-plus@1.18.0`); consulta la nota de instalación de más arriba.
 - **Hacer copia ahora dice «Ya hay otra acción de copia de seguridad en curso»:** hay una acción en marcha en otra ventana de dsh o en la consola de rescate (comparten un archivo de bloqueo, `.composer-plus.lock`, en la carpeta de copias de seguridad). Espera a que termine. Si no hay ninguna acción en marcha, el siguiente clic toma el bloqueo de un proceso cerrado.
 - **La consola de rescate dice «dsh is running»:** primero sal de dsh. Si dsh está realmente cerrado, el archivo que nombra el mensaje quedó de un cierre inesperado: elimínalo y vuelve a intentarlo.
 - **Después de una restauración, dsh no se inicia o falta un plugin:** hay que volver a instalar los paquetes de plugins de un perfil. La consola de rescate lo ofrece después de una restauración; o ejecuta `pnpm install` en cada carpeta de `$DSH_HOME/profiles/` que indique. Los secretos que no estaban en el vault (otro equipo) hay que introducirlos de nuevo: la consola los enumera.
@@ -239,8 +244,11 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 - **Mejorar prompt** solo ve un breve resumen del proyecto, las rutas modificadas y las rutas cuyos nombres coinciden con tus palabras: no el código en sí. Por eso puede pasar por alto el archivo correcto, y solo nombra rutas que recibió. Lee el texto nuevo antes de enviarlo. No se ejecuta con un comando de barra que no sea `/goal <objetivo>`, con una palabra de control de `/goal` (`clear`, `pause`, `resume`) ni con un mensaje que tenga un chip de archivo o de símbolo (el texto nuevo es texto plano, así que perdería el chip), y un mensaje puede tener como máximo 8.000 caracteres. Para un objetivo de `/goal`, solo escribe condiciones a partir del borrador y del contexto; una condición demasiado estricta puede costar rondas del objetivo, así que léela antes de enviarla. Las imágenes siguen adjuntas: solo cambia el texto. Cada clic cuesta una llamada al modelo; un modelo potente puede tardar un minuto (`Esc` lo cancela).
 - **Comprobación del objetivo** solo comprueba una finalización que el agente hace en una ronda automática del objetivo: una finalización que pides en el chat, `/goal` y la barra del objetivo no se comprueban. El agente puede cambiar las pruebas o los archivos del comando de prueba por sí mismo; el verificador lee el chat y puede verlo, pero puede equivocarse en ambos sentidos (un «no terminado» erróneo cuesta una ronda más; un «terminado» erróneo cierra el objetivo). El verificador ve el chat y `git status`, no el código en sí. Una ejecución de prueba solo se reutiliza cuando el paso más reciente del agente que puede cambiar archivos fue su propia ejecución correcta de `bash` con exactamente el mismo comando en la misma carpeta; un comando con una tubería (`| tail`) o `&&` no se reutiliza. El presupuesto se mide cuando termina un turno, así que un turno puede superarlo. El presupuesto de tokens también cuenta las llamadas de los chats de subagentes del chat (se leen de sus registros guardados al final de cada turno, así que un chat con muchos subagentes tarda un poco más en comprobarse). La tabla de evidencias viene de la propia lectura del chat que hace el verificador: una parte que marca como verificada aún necesita que la revises tú cuando importa. `update_goal` espera mientras se ejecuta la comprobación (la prueba como máximo 15 minutos, el verificador como máximo 3 minutos). Una bifurcación recibe un nuevo id de chat, así que empieza sin el comando de prueba ni los límites propios del chat original. Cada finalización que llega al verificador cuesta una llamada al modelo.
 - **Archivos protegidos** es una barrera de protección, no un sandbox. Cubre las herramientas de archivos propias de dsh (`read`, `read_image`, `grep` en un archivo, `write`, `edit`, `str_replace_editor`). Un comando de shell (`cat .env`), un script que escribe el agente, el shell de un subagente, una herramienta MCP, un listado de `glob` y un `grep` sobre una carpeta entera aún pueden llegar a un archivo protegido. Para un límite real, usa los modos sandbox de dsh o deja los secretos fuera de la carpeta del proyecto. Los patrones conocen `*`, `**` y `?`, no `{a,b}` ni `[ab]`, y no distinguen mayúsculas de minúsculas.
+- **Comandos bloqueados** es una barrera de protección, no un sandbox. Solo lee el texto del comando de las herramientas `bash` y `pwsh` de dsh. Una variable o un alias que nombra el comando (`CMD=npm; $CMD publish`), una función de shell, un archivo de script que escribe el agente, otro programa (`python -c`, `node -e`, `make`), una herramienta MCP y tu propia terminal aún pueden ejecutarlo. Una regla puede coincidir con más de lo que quieres: cualquier palabra de un comando puede ser el nombre del comando (`echo npm publish` coincide con `npm publish`), y puede haber otras palabras entre las palabras de la regla (`git push --force` también coincide con `git push origin main --force`). Alarga una regla cuando coincida con demasiado. **preguntar antes** necesita un chat que pueda preguntar: en un chat cuya política de aprobación es never (por ejemplo, un subagente delegado), dsh no puede mostrar la tarjeta, así que la llamada se rechaza con el motivo. La tarjeta de aprobación muestra el motivo en inglés. **Permitir en este chat** no responde a una tarjeta de **preguntar antes**.
 - **Continuar en un chat nuevo** envía el chat (mensajes, llamadas a herramientas y el final de cada resultado de herramienta, como máximo unos 60.000 caracteres, la parte más reciente) al modelo del propio chat. La nota de traspaso puede omitir una decisión o un archivo: léela antes de empezar. El chat nuevo solo conoce la nota y el chat enlazado (dsh adjunta el chat anterior como contexto de solo lectura); su contexto del modelo empieza pequeño y el chat anterior se queda como está. Solo una nota o un inicio por chat a la vez.
 - **Desglose del contexto** muestra estimaciones con la regla propia de dsh (unos 4 caracteres por token), la misma regla que usa el anillo de contexto de dsh; el recuento propio del modelo puede ser distinto. Las definiciones de herramientas son las de la petición más reciente. Muestra el contexto tal como lo tiene el registro del chat; un turno que se está ejecutando aparece después de su siguiente paso.
+- **Pasos planificados** ahorra tokens solo cuando el modelo planifica: mientras está activada, cada solicitud lleva la herramienta `plan_next_steps` y una instrucción breve (unos 500 tokens), también en los chats donde el modelo nunca planifica. Una condición prueba solo lo que dice (por ejemplo: el código de salida de la compilación fue 0), no que el trabajo sea correcto. `ok` lee las marcas de resultado propias de dsh (`[exit code: N]`, tiempos de espera, rechazos del sandbox); un comando que falla sin un código de salida distinto de cero pasa. Los pasos se ejecutan de uno en uno; dos pasos listos a la vez vuelven al modelo. El mensaje del paso se guarda como un mensaje del asistente del modelo del chat (dsh no tiene una marca para un mensaje escrito por un plugin), por eso su texto dice que Composer Plus lo ejecutó. No está en Tether.
+- **Tablero de tareas** solo conoce los proyectos de dsh: un chat fuera de un proyecto muestra **Todos los proyectos**, y la carpeta de una rama por chat (`<project>/.worktrees/<name>`) cuenta como su proyecto. Los id de proyecto (`acme#12`) vienen del nombre de la carpeta y no cambian cuando cambias el nombre del proyecto en dsh. La regla "mantén el tablero al día" entra en un chat solo cuando su proyecto tiene tareas abiertas; un chat que ya la recibió la conserva. Se indica a los agentes que te dejen **Hecho**, **En espera** y las tareas manuales, pero las herramientas no lo rechazan: un agente aún puede mover una de esas tarjetas. Las herramientas del tablero están en la lista de herramientas de cada chat mientras la función está activada (unos 1.000 tokens por petición); desactívala si no usas el tablero. La página lee el tablero cada 2 segundos mientras se muestra; un cambio de un agente aparece en ese tiempo. Un texto que editas mientras un agente cambia el mismo campo no se guarda: el panel muestra el texto nuevo y el motivo. No hay imágenes, ni sincronización con git entre equipos, ni uso compartido por la red (Kanzo sí los tiene). La idea y el aspecto vienen de [Kanzo](https://github.com/emanuele-em/kanzo), de emanuele-em (AGPL-3.0); Composer Plus no usa su código.
 - **Prioridad al mensaje enviado tras Detener** solo actúa después de que detienes el chat (o tras un turno que falló, o al abrir un chat que aún tiene cola): un mensaje que envías mientras un turno se ejecuta sigue esperando al final de la cola. Solo pasa por delante de tus propios mensajes en cola: si en la cola espera una ronda de un objetivo o una respuesta a una pregunta, se mantiene el orden de dsh. Lee una parte de dsh que no es una API pública (si el turno detenido aún está terminando); si una actualización de dsh le cambia el nombre, el mensaje pasa delante solo cuando ese turno ha terminado. Los chats de subagentes mantienen el orden de dsh.
 - **Memoria del proyecto** pertenece a la primera carpeta del chat (la carpeta de proyecto de dsh): un chat que cambia de carpeta con `cd` conserva la memoria de su primer proyecto, y la misma carpeta abierta por otra ruta a los mismos archivos la comparte. Un chat congela su sección de memoria al empezar, así que una nota guardada después aparece desde el chat siguiente (`memory_recall` la encuentra al momento). La revisión solo guarda lo que el modelo decide guardar: puede pasar por alto un dato o guardar uno erróneo; revísalas en **Abrir memoria** y cámbialas allí, o edita los archivos a mano con dsh cerrado. **Abrir memoria** envía las notas del proyecto seleccionado y las notas globales (todos los proyectos si seleccionas Todas las notas; como mucho unos 60.000 caracteres, el resto solo se cuenta y no puede cambiar en esa solicitud) y tu texto al modelo predeterminado de dsh, no al modelo del chat. Una vista previa se guarda en el Mac 30 minutos y hasta que dsh se reinicia; si una revisión o el agente cambian las notas mientras tanto, **Aplicar** se niega y vuelves a pedir la vista previa. **Aplicar** guarda todos los cambios de una vista previa o ninguno: si un cambio no se puede guardar (por ejemplo, MEMORY.md está lleno), las notas quedan como estaban y se muestra el motivo. Cada turno terminado con un mensaje tuyo cuesta una llamada al modelo; una llamada fallida vuelve a leer los mismos mensajes después del turno siguiente. Los chats de subagentes no se revisan. La idea y el formato de archivo vienen de [DS Bot](https://github.com/Fei2411/DS-Bot) (Apache-2.0); Composer Plus no usa su código y nunca lee ni escribe la memoria propia de DS Bot.
 - **Copia de seguridad** usa una sola carpeta fija, `~/Desktop/dsh-backups` (la predeterminada de dsh-backup, para que sus archivos comprimidos sigan sirviendo); no hay ningún ajuste para otra carpeta. Un archivo comprimido ocupa más o menos lo mismo que el directorio home de dsh sin `cache/` ni `dsh-runtimes/` (medido: 1,6 GB de archivos dieron un archivo comprimido de 830 MB en unos 30 s en Apple Silicon; dsh siguió respondiendo). Un archivo que cambia mientras se lee se guarda tal como estaba cuando la copia de seguridad lo abrió, así que el registro de un chat abierto puede terminar en una entrada cortada, que dsh repara en su siguiente escritura. El ocultamiento encuentra un secreto en un archivo yml por el nombre de su clave en una línea (`token:`, `apiKey:`, …); un secreto en un mapa de flujo (`{token: x}`), en una lista bajo una de esas claves, en un archivo JSON (por ejemplo, la `apiKey` de un servidor MCP en un archivo `.json`) o con otro nombre se queda en el archivo comprimido. Los archivos comprimidos por tipo de dsh-backup (`dsh-t-…`) no aparecen en la lista. **Para otro equipo** copia el archivo comprimido (un clon en APFS: sin espacio adicional); el vault no va con él. **Hacer copia ahora** no elimina ninguna copia de seguridad. Una copia de seguridad automática conserva las copias más recientes que hizo Composer Plus (el ajuste **Conservar** de **Copia de seguridad automática**) y elimina sus copias más antiguas; las instantáneas anteriores a una actualización se cuentan aparte (se quedan las 2 más recientes). Los archivos comprimidos de dsh-backup nunca se eliminan: quítalos con **Eliminar**. Mientras dsh-backup siga instalado, cuenta los archivos comprimidos de Composer Plus en su propio número de copias que conserva y puede eliminarlos.
@@ -277,6 +285,8 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 
 **¿Puede el agente recordar mis preferencias entre chats, como la memoria de DS Bot?** Sí, con **Memoria del proyecto** (desactivada de forma predeterminada): actívala en **Configuración → Composer Plus**. Después de cada turno, tus preferencias y decisiones duraderas se guardan como notas breves para el proyecto del chat, y cada chat nuevo de ese proyecto las lee. Pide al agente que recuerde algo y lo guarda al momento. Para ver o cambiar las notas, pulsa **Abrir memoria** en la misma fila y escribe qué cambiar.
 
+**¿Podemos mis agentes y yo compartir un tablero de tareas, como en Kanzo?** Sí, con **Tablero de tareas** (activado de forma predeterminada): ábrelo en la barra lateral izquierda y añade tareas con **Nueva tarea**. En un chat, pide al agente que "tome la siguiente tarea del tablero": mueve la tarjeta a **En curso**, comenta lo que hizo y la mueve a **En revisión**. Marca una tarea como **Manual** para quedártela tú.
+
 **¿Puede dsh hacer copias de seguridad de mis chats y ajustes, como dsh-backup?** Sí: **Configuración → Composer Plus → Copia de seguridad → Hacer copia ahora**. Escribe el mismo formato de archivo comprimido en la misma carpeta (`~/Desktop/dsh-backups`), así que los archivos comprimidos de dsh-backup también aparecen y se pueden restaurar, y puedes desinstalar dsh-backup. Activa **Copia de seguridad automática** para hacer copias según un horario.
 
 **dsh ya no se inicia. ¿Cómo restauro una copia de seguridad?** Abre la carpeta de copias de seguridad (`~/Desktop/dsh-backups`) y haz doble clic en `Composer Plus Rescue.command` (Linux: `composer-plus-rescue.sh`, Windows: `Composer Plus Rescue.cmd`). Elige `3) Restore a backup`, selecciona una y escribe `RESTORE`. Funciona sin dsh.
@@ -301,6 +311,8 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 
 **¿Cómo veo solo los archivos que cambió un chat?** Barra lateral derecha → **Cambios** → **Este chat**. Haz clic en **␣** para ocultar los cambios que solo son espacios en blanco.
 
+**¿Cómo evito que el agente ejecute `npm publish` o `git push --force`?** **Configuración → Composer Plus → Comandos bloqueados**: escribe `npm publish`, elige **bloquear** o **preguntar antes** y luego haz clic en **Añadir**. **bloquear** rechaza el comando y el agente te pregunta; **preguntar antes** muestra la tarjeta de aprobación cada vez. Archivos protegidos cubre las herramientas de archivos del agente; Comandos bloqueados cubre sus comandos de shell.
+
 **¿Cómo evito que la revisión automática pregunte por la misma herramienta en un chat?** Haz clic en **Permitir en este chat** en la tarjeta de aprobación. Solo cubre esa herramienta exacta en ese chat, durante 1 hora por defecto; revoca el permiso desde el chip de la cabecera. Cambia el tiempo en **Configuración → Composer Plus → Permitir en este chat**.
 
 **Perdí mi iPhone. ¿Cómo evito que llegue a mi Mac?** Haz clic en **Conexión móvil**, abajo a la izquierda de la barra lateral, y haz clic en **Remove** junto a ese iPhone. Su clave deja de funcionar al instante; solo puede volver con un nuevo emparejamiento que apruebes en el Mac.
@@ -329,6 +341,8 @@ Probado en dsh `0.2.0-rc.2` (escritorio y web) y `0.2.1-rc.2` (web). La CI ejecu
 
 **¿Puedo enviar una foto desde mi iPhone?** Sí. En un chat de Tether, toca **+** junto al campo de mensaje → Camera, Photos (hasta 4) o Paste image. Las fotos llegan al chat del Mac como adjuntos de tu mensaje, así que el modelo las ve.
 
+**¿Puede dsh ejecutar el siguiente comando sin volver a preguntar al modelo?** Sí, con **Pasos planificados** (desactivada de forma predeterminada): actívala en Configuración → Composer Plus. El modelo puede entonces planificar sus próximos comandos con una condición, por ejemplo «ejecuta las pruebas cuando la compilación pase», y Composer Plus ejecuta un paso sin una nueva llamada al modelo cuando el resultado cumple la condición. Las aprobaciones y el sandbox siguen igual.
+
 **¿Funciona con la app de escritorio?** Sí: Configuración → Plugins → **Añadir plugin** → `dsh-composer-plus`. Probado en dsh 0.2.0-rc.2 (escritorio y web) y 0.2.1-rc.2 (web).
 
 ## Desarrollo
@@ -393,6 +407,8 @@ PLAYWRIGHT=/path/to/playwright node test/browser-continue-queue.mjs /path/to/dsh
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-stop-send.mjs /path/to/dsh/lib/bin.js
 # Edit queued message in place with images and files (slow fake model) + its thumbnail
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-edit.mjs /path/to/dsh/lib/bin.js
+# Task board: the page, the agent tools (fake model), drag and drop, search, the switch
+SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-task-board.mjs /path/to/dsh/lib/bin.js
 ```
 
 ```sh

package/README.fr.md

@@ -29,7 +29,7 @@ dsh plugin --profile web add dsh-composer-plus
 
 Redémarrez ensuite dsh. (La CLI ne peut pas installer dans le profil de bureau ; c’est l’app qui le gère.)
 
-> Le pnpm de dsh ignore les versions publiées depuis moins de 24 heures. Juste après une nouvelle version, ajoutez le numéro de version : `dsh-composer-plus@1.17.0`.
+> Le pnpm de dsh ignore les versions publiées depuis moins de 24 heures. Juste après une nouvelle version, ajoutez le numéro de version : `dsh-composer-plus@1.18.0`.
 
 ## Fonctionnalités
 
@@ -68,7 +68,10 @@ Redémarrez ensuite dsh. (La CLI ne peut pas installer dans le profil de bureau
 | **Vérification de l’objectif** | <a id="feature-goalcheck"></a>Lancez un objectif avec `/goal`. Quand l’agent marque l’objectif comme terminé lors d’une itération automatique, l’objectif ne se ferme qu’après deux vérifications. D’abord, la commande de test du projet s’exécute dans le dossier de la discussion, avec le mode sandbox de la discussion. La commande est la vôtre ou celle trouvée dans `package.json`, `Makefile`, `Cargo.toml`, `go.mod` ou pytest. Quand la dernière étape de l’agent lui-même était une exécution réussie de ce test, il n’est pas relancé. Ensuite, un appel indépendant au modèle, sans outils, lit l’objectif, cette discussion, `git status` et le résultat du test. Le modèle répond par un tableau de preuves : chaque partie de l’objectif est vérifiée, incorrecte ou non résolue, avec la preuve et la correction ; l’objectif ne se ferme que lorsque chaque partie est vérifiée. Si une vérification échoue, l’objectif reste actif et l’agent lit chaque partie ouverte avec sa preuve et sa correction, puis l’itération suivante continue. Une ligne sous la barre de l’objectif (**Vérification de l’objectif**) affiche le test, le dernier résultat et le nombre de parties vérifiées (survolez-la pour voir le tableau). **Modifier** définit votre propre commande de test et une limite de temps ou de tokens ; au-delà de la limite, l’objectif devient bloqué. La limite de tokens compte aussi les sous-agents de la discussion. **Lancer maintenant** lance la vérification sans fermer l’objectif. Il a son propre menu **Modèle** dans les Réglages (par défaut : **Comme le modèle de la discussion**). Quand vous terminez l’objectif vous-même, rien n’est vérifié. | <a href="assets/features/goalCheck.webp"><img src="assets/features/goalCheck.webp" width="160" alt="Capture d’écran : Vérification de l’objectif"></a> |
 | **Continuer dans une nouvelle discussion** | <a id="feature-handoffchat"></a>Clic droit sur une discussion dans la barre latérale (ou ouvrez son menu **…**) → **Continuer dans une nouvelle discussion…**. Un seul appel au modèle de la discussion rédige une note de passation à partir de ce que montre la discussion : Tâche, Résultats, Terminé, Décisions, Problèmes ouverts et Prochaine action (les appels d’outils et leurs résultats sont les preuves ; les étapes que vous avez annulées sont exclues). La note s’ouvre dans une boîte de dialogue : lisez-la et modifiez-la. **Rédiger à nouveau** rédige une nouvelle note. **Lancer une nouvelle discussion** (ou `Cmd/Ctrl+Enter`) ouvre une nouvelle discussion dans le même projet, avec la note et un lien vers l’ancienne discussion comme premier message ; l’ancienne discussion reste telle quelle. Utilisez cette fonction quand une longue discussion est pleine ou lente, ou pour continuer demain. Rien n’est écrit dans le projet. | <a href="assets/features/handoffChat.webp"><img src="assets/features/handoffChat.webp" width="160" alt="Capture d’écran : Continuer dans une nouvelle discussion"></a> |
 | **Répartition du contexte** | <a id="feature-contextbreakdown"></a>Barre latérale droite → `+` → **Contexte**. La page montre ce qui remplit maintenant le contexte du modèle de la discussion ouverte et la part de la fenêtre de contexte utilisée : le prompt système, les instructions du projet (AGENTS.md), les compétences, vos messages, les réponses de l’agent et les appels d’outils, les résultats d’outils (par outil), les résultats MCP (par serveur), les définitions des outils, le résumé de compaction et les autres notes de contexte, chacun avec ses tokens et sa part. Cliquez sur une partie pour voir ses outils ou ses serveurs. Elle lit seulement le journal de la discussion, après `/compact` et les annulations, et n’appelle aucun modèle ; elle relit le journal après chaque tour et avec **Actualiser**. Utilisez-la pour voir pourquoi une discussion est lente ou pleine, par exemple à cause d’un gros résultat d’outil MCP ou de nombreuses définitions d’outils. | <a href="assets/features/contextBreakdown.webp"><img src="assets/features/contextBreakdown.webp" width="160" alt="Capture d’écran : Répartition du contexte"></a> |
+| **Étapes planifiées** | <a id="feature-plannedsteps"></a>Désactivée par défaut : activez-la dans **Réglages → Composer Plus**. L’agent reçoit l’outil `plan_next_steps` : dans le même message qu’une commande, il peut planifier les commandes suivantes avec leurs arguments exacts et une condition, par exemple « lance `npm test` quand la compilation réussit ». Quand le résultat remplit la condition, Composer Plus exécute lui-même l’étape suivante, sans nouvel appel au modèle, et une longue discussion consomme moins de jetons. L’étape apparaît dans la discussion sous forme d’une courte ligne, « Composer Plus · Planned steps: ran `test` … without a model call », suivie de son appel d’outil et de son résultat. Uniquement des étapes `bash`, `read`, `grep` et `glob` ; les approbations, le sandbox et Fichiers protégés s’appliquent à chaque étape comme d’habitude. Le modèle répond de nouveau quand une condition échoue, quand deux étapes sont prêtes en même temps, après la dernière étape et quand vous envoyez un message. L’idée vient de HarnessMM (arXiv 2610.32813). | <a href="assets/features/plannedSteps.webp"><img src="assets/features/plannedSteps.webp" width="160" alt="Capture d’écran : Étapes planifiées"></a> |
 | **Fichiers protégés** | <a id="feature-protectedfiles"></a>Activée par défaut. Les outils de fichiers propres à l’agent ne peuvent ni lire ni modifier les fichiers qui correspondent à vos motifs : `read`, `read_image` et `grep` sur un fichier sont refusés pour les motifs **lecture et écriture**, et `write`, `edit` et `str_replace_editor` pour les deux types. L’agent lit pourquoi et on lui demande de vous consulter. Les motifs par défaut sont `.env*`, `*.pem` et `*.key`. Réglages → Composer Plus → **Fichiers protégés** : ajoutez un motif (par exemple `published/**` ou `config/*.yml`), cliquez sur son type pour basculer entre **lecture et écriture** et **écriture seule**, supprimez-le avec ✕, ou cliquez sur **Utiliser les valeurs par défaut**. Un motif sans `/` correspond à un nom de fichier dans n’importe quel dossier. C’est un garde-fou, pas un sandbox : une commande shell (`cat .env`), un script ou un outil MCP peut encore atteindre le fichier (voir Limites). | <a href="assets/features/protectedFiles.webp"><img src="assets/features/protectedFiles.webp" width="160" alt="Capture d’écran : Fichiers protégés"></a> |
+| **Commandes bloquées** | <a id="feature-blockedcommands"></a>Activée par défaut, avec une liste vide. Les commandes shell de l’agent (`bash`, `pwsh`) ne peuvent pas exécuter une commande qui correspond à vos règles : une règle **bloquer** refuse l’appel (l’agent lit pourquoi et on lui demande de vous consulter), une règle **demander d’abord** affiche la carte d’approbation de dsh, et la commande ne s’exécute que si vous l’autorisez. Réglages → Composer Plus → **Commandes bloquées** : tapez une règle (par exemple `npm publish`, `git push --force` ou `ssh *192.168.2.19`), cliquez sur son type pour basculer entre **bloquer** et **demander d’abord**, puis cliquez sur **Ajouter** ; cliquez sur le type d’une règle pour le changer, supprimez-la avec ✕. Une règle est un nom de commande et des mots qui doivent le suivre dans cet ordre ; `*` correspond à n’importe quel texte. La vérification trouve aussi la commande après `&&`, `;`, `\|`, dans `$(…)`, `bash -c "…"` ou `eval`, et après `sudo` ou `env`. C’est un garde-fou, pas un sandbox : une variable (`$CMD`), un fichier de script ou un autre programme peut encore exécuter la commande (voir Limites). | <a href="assets/features/blockedCommands.webp"><img src="assets/features/blockedCommands.webp" width="160" alt="Capture d’écran : Commandes bloquées"></a> |
+| **Tableau des tâches** | <a id="feature-taskboard"></a>Barre latérale gauche → **Tableau des tâches**. Un tableau kanban de vos projets dsh, pour vous et pour les agents : **À faire**, **En cours**, **En revue** et **Terminé** (et **En attente**, voir plus bas). Choisissez un projet ou **Tous les projets** à gauche. **Nouvelle tâche** (ou `n`) ouvre une nouvelle carte : tapez son titre et appuyez sur `Enter`. Faites glisser une carte vers une autre colonne ou entre deux cartes. Cliquez sur une carte pour voir et modifier son **Statut**, ses **Étiquettes**, **Manuelle** (les agents l’ignorent), sa description (Markdown) et ses commentaires. `/` cherche dans tous les projets, `h` affiche seulement les tâches manuelles, et le bouton d’export enregistre le tableau en Markdown ou en JSON. Les agents reçoivent des outils de tableau : dans une discussion, demandez à l’agent de « prendre la tâche suivante du tableau » ; il déplace la première carte de **À faire** vers **En cours**, commente ce qu’il a fait et la déplace vers **En revue** ; c’est vous qui la déplacez vers **Terminé**. Dans un projet qui a des tâches ouvertes, chaque discussion reçoit cette règle d’elle-même. Réglages → Composer Plus → **Tableau des tâches** contient l’interrupteur de la colonne **En attente** : les agents vous laissent ses cartes. | <a href="assets/features/taskBoard.webp"><img src="assets/features/taskBoard.webp" width="160" alt="Capture d’écran : Tableau des tâches"></a> |
 | **Mémoire du projet** | <a id="feature-projectmemory"></a>Désactivée par défaut : activez-la dans **Réglages → Composer Plus**. Chaque dossier de projet a sa propre mémoire, que les discussions suivantes de ce projet lisent, comme DS Bot en garde une par Bot. Après chaque tour terminé, un appel au modèle de la discussion lit les nouveaux messages (pas ceux annulés), garde vos préférences, décisions et faits durables sous forme de notes courtes, et modifie ou supprime les anciennes. L’agent peut aussi enregistrer, supprimer et chercher des notes lui-même (`memory_remember`, `memory_forget`, `memory_recall`). Une note peut aussi être globale : tous les projets la lisent. Une nouvelle discussion reçoit les notes dans son prompt système ; une note enregistrée plus tard apparaît à partir de la discussion suivante. Les fichiers sont en Markdown dans le dossier personnel de dsh (`storages/dsh-composer-plus/memory/`), jamais dans le dossier du projet. **Ouvrir la mémoire**, sur la même ligne, montre toutes les notes enregistrées, groupées par projet (et la mémoire globale), avec un filtre. Écrivez avec vos mots ce qu’il faut changer (par exemple « je suis passé de yarn à pnpm »), puis **Aperçu des modifications** : le modèle par défaut de dsh propose les modifications, et seul **Appliquer** les enregistre. Dans Tether : menu du titre de la discussion → Project memory. | <a href="assets/features/projectMemory.webp"><img src="assets/features/projectMemory.webp" width="160" alt="Capture d’écran : Mémoire du projet"></a> |
 | **Autoriser pour cette discussion** | <a id="feature-allowforchat"></a>Quand la revue automatique vous demande votre avis, la carte d’approbation propose **Autoriser pour cette discussion** : le même outil dans la même discussion est ensuite autorisé, quels que soient les arguments, jusqu’à la fin de la limite de temps (1 heure par défaut ; choisissez-la dans **Réglages → Composer Plus → Autoriser pour cette discussion**). Ensuite, l’agent demande à nouveau. Une pastille dans l’en-tête liste les autorisations avec leur heure de fin et permet de les révoquer. Les autorisations restent valables après un redémarrage. | <a href="assets/features/allowForChat.webp"><img src="assets/features/allowForChat.webp" width="160" alt="Capture d’écran : Autoriser pour cette discussion"></a> |
 | **Statut du projet** | <a id="feature-projectstatus"></a>La ligne d’un projet dans la barre latérale affiche le même indicateur en cours / en attente / terminé que ses discussions : même replié, un projet vous indique donc qu’une discussion travaille ou a besoin de vous. Une discussion qui vous attend s’affiche en premier, puis une discussion terminée que vous n’avez pas encore ouverte (le point vert, même pendant qu’une autre discussion est encore en cours), puis l’indicateur en cours. Survolez-le pour voir les détails. Dans **Arborescence des espaces de travail**, la ligne d’un dossier parent affiche aussi les discussions de chaque projet qu’il contient (par exemple chaque dossier de branche dans `.worktrees/`), même quand il est replié. | <a href="assets/features/projectStatus.webp"><img src="assets/features/projectStatus.webp" width="160" alt="Capture d’écran : Statut du projet"></a> |
@@ -166,7 +169,9 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 - **Vérification de l’objectif :** elle ne s’exécute que quand l’agent marque un `/goal` comme terminé lors d’une itération automatique (ou quand vous cliquez sur **Lancer maintenant**). La partie hôte exécute la commande de test dans le dossier de la discussion avec le mode sandbox de la discussion (comme l’outil `bash` de dsh lui-même : la même politique d’accès aux fichiers ; quand ce sandbox ne peut pas démarrer, le test ne s’exécute pas et la vérification échoue). Pour trouver la commande, elle ne lit que `package.json`, `Makefile`, `Cargo.toml`, `go.mod`, `pyproject.toml` et `pytest.ini`, comme fichiers ordinaires dans le dossier (aucun lien symbolique hors du dossier, aucune FIFO). Elle envoie ensuite l’objectif, la discussion depuis le début de l’objectif (vos messages, les réponses de l’agent, les appels d’outils coupés à 1 000 caractères et les 2 000 derniers caractères de chaque résultat d’outil ; sans raisonnement ni étapes retirées par une annulation ; environ 60 000 caractères au plus, la partie la plus récente), `git status --short` et la fin de la sortie du test au modèle choisi sous **Vérification de l’objectif** (par défaut, le modèle de la discussion), en une seule requête sans outils. La sortie des outils peut contenir ce que l’agent a lu : cette requête peut donc contenir des parties de vos fichiers, comme la discussion elle-même. Rien n’est écrit dans la discussion ni dans le projet. Votre commande de test, les limites, le dernier résultat (avec la fin de sa sortie) et le modèle choisi sont dans `$DSH_HOME/storages/dsh-composer-plus/goal-check.json` (fichier réservé au propriétaire, les 500 discussions les plus récentes).
 - **Continuer dans une nouvelle discussion :** rien ne s’exécute tant que vous ne cliquez pas. Ensuite, la partie hôte envoie la discussion (comme la Vérification de l’objectif la lit : sans raisonnement ni étapes retirées par une annulation) au modèle de la discussion elle-même et affiche la note de passation ; seul **Lancer une nouvelle discussion** crée une nouvelle discussion. Rien n’est écrit dans le projet.
 - **Répartition du contexte :** la partie hôte lit seulement le journal de la discussion ; aucun appel au modèle, aucun fichier du projet.
+- **Tableau des tâches :** le tableau (titres, descriptions, étiquettes et commentaires de vos tâches, chemins des dossiers de projet et leurs id courts) se trouve dans `$DSH_HOME/storages/dsh-composer-plus/board.json` (fichier réservé au propriétaire) ; l’interrupteur se trouve à côté, dans `board-switch.json`. Rien ne quitte votre machine et rien n’est écrit dans un dossier de projet. Les outils du tableau donnent aux agents ce que vous avez écrit sur le tableau : le texte d’une tâche arrive donc au modèle de la discussion quand un agent la lit. Un fichier de tableau endommagé est gardé sous le nom `board.json.broken-<time>` et le tableau repart vide.
 - **Fichiers protégés :** la liste et l’interrupteur se trouvent dans `$DSH_HOME/storages/dsh-composer-plus/protected-files.json` (fichier réservé au propriétaire). La vérification lit seulement le chemin de chaque appel d’outil de fichiers (et son chemin réel), jamais le fichier.
+- **Commandes bloquées :** les règles et l’interrupteur se trouvent dans `$DSH_HOME/storages/dsh-composer-plus/blocked-commands.json` (fichier réservé au propriétaire). La vérification lit seulement le texte de la commande de chaque appel `bash` et `pwsh` ; elle n’exécute rien et n’envoie rien.
 - **Mémoire du projet :** désactivée tant que vous ne l’activez pas. Quand elle est activée, après chaque tour terminé d’une discussion de premier niveau, la partie Host envoie les nouveaux messages de la discussion depuis la dernière revue (vos messages et les réponses texte de l’agent ; pas de sortie d’outils, pas de raisonnement, pas de contexte caché, pas de messages annulés ; la copie de la discussion parente dans une discussion dérivée est laissée de côté ; au plus environ 16 000 caractères) et les notes enregistrées au modèle de la discussion, en une seule requête sans outils. Les notes sont des fichiers Markdown dans `$DSH_HOME/storages/dsh-composer-plus/memory/` (fichiers réservés au propriétaire) : `projects/<id>/` pour chaque dossier de projet (`<id>` est un hash du chemin réel du dossier ; `project.json` indique le dossier), `global/`, `journal.jsonl` (chaque modification avec la ligne avant et après) et `reviewed.json` (jusqu’où chaque discussion a été lue). Rien n’est écrit dans le dossier du projet. Les notes qui ressemblent à une clé, un jeton, un mot de passe ou un numéro d’identité sont refusées. Les notes d’un projet entrent dans le prompt système de chaque nouvelle discussion de ce dossier : elles vont donc au modèle avec chaque requête de cette discussion. L’interrupteur est dans `memory.json`, au même endroit. **Ouvrir la mémoire** n’envoie rien tant que vous ne cliquez pas sur **Aperçu des modifications** ; ensuite, il envoie les notes affichées et votre texte au modèle par défaut de dsh, en une seule requête sans outils. Les modifications ne sont écrites qu’avec **Appliquer**, avec `editor` dans le journal. Tether lit et modifie les notes par la même route.
 - **Sauvegarde :** rien ne quitte votre machine. Les archives vont dans `~/Desktop/dsh-backups` (fichiers réservés au propriétaire). Les secrets ne sont pas dans une archive : les fichiers d’identifiants (`.credentials.yaml`, `.env`), les fichiers de clés (`.pem`, `.key`, `.p12`, `.pfx`) et les valeurs des réglages token, secret, password et clé d’API des fichiers yml sont masqués ; leurs vraies copies restent dans `composer-plus-vault/<archive>/`, dans le même dossier (réservé au propriétaire), sur cet ordinateur uniquement. **Pour un autre ordinateur** ne copie aucun vault : saisissez de nouveau ces secrets là-bas. Vos journaux de discussion, vos réglages et le reste du dossier personnel de dsh sont dans l’archive tels quels : gardez le dossier privé, comme `$DSH_HOME` lui-même. La sauvegarde lit les fichiers avec `O_NOFOLLOW | O_NONBLOCK` ; un lien symbolique est enregistré comme lien (jamais suivi) et une FIFO ou un périphérique est ignoré. L’interrupteur et les réglages de la sauvegarde automatique sont dans `$DSH_HOME/storages/dsh-composer-plus/auto-backup.json`, l’interrupteur de la console de secours dans `rescue-console.json`, et pendant que dsh tourne, `running/host-<pid>.json` désigne chaque processus dsh (la console de secours les lit pour refuser une restauration).
 - **Console de secours :** un menu dans un terminal ; elle n’ouvre aucun port réseau. Une restauration écrit uniquement dans un nouveau dossier à côté du dossier personnel de dsh (fichiers avec `O_EXCL | O_NOFOLLOW`, liens symboliques en dernier et jamais suivis) et refuse une archive qui contient un nom dangereux (`..`, un chemin absolu), un périphérique ou une FIFO, plus d’un dossier de premier niveau ou une entrée sous un lien.
@@ -189,7 +194,7 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 - **Pas de pastille de branche sur une ligne de discussion :** la discussion n’a eu aucun tour depuis que vous avez installé cette version, son dossier n’est pas un dépôt git, ou **Branche Git sur les lignes de discussion** est désactivée. Après une mise à jour, redémarrez dsh (la partie hôte enregistre la branche).
 - **Vérification de l’objectif indique que le test s’est terminé avec le code 127 ou « not found » :** dsh démarré depuis le Finder ou le Dock peut avoir un PATH plus court que votre terminal : il ne trouve donc pas `npm`, `pnpm` ou `cargo`. Démarrez dsh depuis un terminal, ou définissez votre propre commande de test avec le chemin complet sous **Vérification de l’objectif** → **Modifier**. **Lancer maintenant** affiche le résultat tout de suite.
 - **L’objectif ne se ferme pas et l’agent continue de travailler :** **Vérification de l’objectif** a trouvé un test en échec ou du travail manquant ; la ligne sous l’objectif indique pourquoi (survolez le résultat pour voir les détails). Corrigez la cause ou la commande de test, ou terminez l’objectif vous-même avec `/goal` ou la barre de l’objectif (ce n’est pas vérifié).
-- **L’installation échoue juste après une nouvelle version :** ajoutez la version (`dsh-composer-plus@1.17.0`) ; voir la note d’installation plus haut.
+- **L’installation échoue juste après une nouvelle version :** ajoutez la version (`dsh-composer-plus@1.18.0`) ; voir la note d’installation plus haut.
 - **Sauvegarder maintenant indique « Une autre action de sauvegarde est en cours » :** une action tourne dans une autre fenêtre de dsh ou dans la console de secours (elles partagent un fichier de verrou, `.composer-plus.lock`, dans le dossier de sauvegarde). Attendez qu’elle se termine. Si aucune action ne tourne, le verrou d’un processus fermé est repris au clic suivant.
 - **La console de secours indique « dsh is running » :** quittez d’abord dsh. Si dsh est vraiment fermé, le fichier nommé dans le message reste d’un plantage : supprimez-le et réessayez.
 - **Après une restauration, dsh ne démarre pas ou un plugin manque :** les paquets de plugins d’un profil doivent être réinstallés. La console de secours le propose après une restauration ; sinon, exécutez `pnpm install` dans chaque dossier sous `$DSH_HOME/profiles/` qu’elle liste. Les secrets qui n’étaient pas dans le vault (autre ordinateur) doivent être saisis de nouveau : la console les liste.
@@ -239,8 +244,11 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 - **Améliorer le prompt** ne voit qu’un court résumé du projet, les chemins modifiés et les chemins dont le nom correspond à vos mots : pas le code lui-même. Il peut donc manquer le bon fichier, et il ne cite que les chemins qu’il a reçus. Relisez le nouveau texte avant de l’envoyer. Il ne s’exécute pas pour une commande slash autre que `/goal <objectif>`, pour un mot de contrôle de `/goal` (`clear`, `pause`, `resume`) ni pour un message avec une pastille de fichier ou de symbole (le nouveau texte est du texte brut : la pastille serait perdue), et un message peut avoir au plus 8 000 caractères. Pour un objectif `/goal`, il n’écrit des conditions qu’à partir du brouillon et du contexte ; une condition trop stricte peut coûter des itérations de l’objectif : relisez-la donc avant de l’envoyer. Les images restent jointes : seul le texte change. Chaque clic coûte un appel au modèle ; un modèle puissant peut prendre une minute (`Esc` annule).
 - **Vérification de l’objectif** ne vérifie qu’un achèvement que l’agent fait lors d’une itération automatique de l’objectif : un achèvement que vous demandez dans la discussion, `/goal` et la barre de l’objectif ne sont pas vérifiés. L’agent peut modifier lui-même les tests ou les fichiers de la commande de test ; le vérificateur lit la discussion et peut le voir, mais il peut se tromper dans les deux sens (un « pas terminé » erroné coûte une itération de plus ; un « terminé » erroné ferme l’objectif). Le vérificateur voit la discussion et `git status`, pas le code lui-même. Une exécution de test n’est réutilisée que quand la dernière étape de l’agent capable de modifier des fichiers était sa propre exécution `bash` réussie d’exactement la même commande dans le même dossier ; une commande avec un pipe (`| tail`) ou `&&` n’est pas réutilisée. Le budget est mesuré à la fin d’un tour : un tour peut donc le dépasser. Le budget de tokens compte aussi les appels des discussions de sous-agents de la discussion (lus dans leurs journaux enregistrés à la fin de chaque tour : une discussion avec beaucoup de sous-agents prend donc un peu plus de temps à vérifier). Le tableau des preuves vient de la propre lecture de la discussion par le vérificateur : une partie qu’il dit vérifiée demande encore votre propre regard quand elle compte. `update_goal` attend pendant la vérification (le test 15 minutes au plus, le vérificateur 3 minutes au plus). Une duplication de session reçoit un nouvel id de discussion : elle démarre donc sans la commande de test ni les limites propres de la discussion parente. Chaque achèvement qui atteint le vérificateur coûte un appel au modèle.
 - **Fichiers protégés** est un garde-fou, pas un sandbox. Il couvre les outils de fichiers de dsh lui-même (`read`, `read_image`, `grep` sur un fichier, `write`, `edit`, `str_replace_editor`). Une commande shell (`cat .env`), un script que l’agent écrit, le shell d’un sous-agent, un outil MCP, une liste `glob` et un `grep` sur tout un dossier peuvent encore atteindre un fichier protégé. Pour une vraie limite, utilisez les modes sandbox de dsh ou gardez les secrets hors du dossier du projet. Les motifs connaissent `*`, `**` et `?`, pas `{a,b}` ni `[ab]`, et ils ignorent la casse.
+- **Commandes bloquées** est un garde-fou, pas un sandbox. Il lit seulement le texte de la commande des outils `bash` et `pwsh` de dsh. Une variable ou un alias qui nomme la commande (`CMD=npm; $CMD publish`), une fonction shell, un fichier de script que l’agent écrit, un autre programme (`python -c`, `node -e`, `make`), un outil MCP et votre propre terminal peuvent encore l’exécuter. Une règle peut correspondre à plus de choses que vous ne le voulez : n’importe quel mot d’une commande peut être le nom de la commande (`echo npm publish` correspond à `npm publish`), et d’autres mots peuvent se placer entre les mots de la règle (`git push --force` correspond aussi à `git push origin main --force`). Allongez une règle quand elle correspond à trop de choses. **demander d’abord** a besoin d’une discussion qui peut demander : dans une discussion dont la politique d’approbation est never (par exemple un sous-agent délégué), dsh ne peut pas afficher la carte, donc l’appel est refusé avec la raison. La carte d’approbation affiche la raison en anglais. **Autoriser pour cette discussion** ne répond pas à une carte **demander d’abord**.
 - **Continuer dans une nouvelle discussion** envoie la discussion (messages, appels d’outils et la fin de chaque résultat d’outil, environ 60 000 caractères au plus, la partie la plus récente) au modèle de la discussion elle-même. La note de passation peut manquer une décision ou un fichier : relisez-la avant de lancer. La nouvelle discussion ne connaît que la note et la discussion liée (dsh joint l’ancienne discussion comme contexte en lecture seule) ; son contexte du modèle commence petit, et l’ancienne discussion reste telle quelle. Une seule note ou un seul lancement par discussion à la fois.
 - **Répartition du contexte** affiche des estimations avec la règle de dsh lui-même (environ 4 caractères par token), la même règle que l’anneau de contexte de dsh ; le décompte du modèle lui-même peut être différent. Les définitions des outils sont celles de la requête la plus récente. Elle affiche le contexte tel que le journal de la discussion le contient ; un tour en cours apparaît après sa prochaine étape.
+- **Étapes planifiées** n’économise des jetons que si le modèle planifie : tant qu’elle est activée, chaque requête porte l’outil `plan_next_steps` et une courte consigne (environ 500 jetons), aussi dans les discussions où le modèle ne planifie jamais. Une condition prouve seulement ce qu’elle dit (par exemple : le code de sortie de la compilation était 0), pas que le travail est juste. `ok` lit les marques de résultat propres à dsh (`[exit code: N]`, délais dépassés, refus du sandbox) ; une commande qui échoue sans code de sortie non nul passe. Les étapes s’exécutent une à la fois ; deux étapes prêtes en même temps reviennent au modèle. Le message de l’étape est enregistré comme un message d’assistant du modèle de la discussion (dsh n’a pas de marque pour un message écrit par un plugin), donc son texte indique que Composer Plus l’a exécutée. Pas dans Tether.
+- **Tableau des tâches** ne connaît que les projets de dsh : une discussion hors d’un projet affiche **Tous les projets**, et le dossier d’une branche par discussion (`<project>/.worktrees/<name>`) compte comme son projet. Les id de projet (`acme#12`) viennent du nom du dossier et ne changent pas quand vous renommez le projet dans dsh. La règle « tenir le tableau à jour » n’entre dans une discussion que si son projet a des tâches ouvertes ; une discussion qui l’a reçue la garde. On demande aux agents de vous laisser **Terminé**, **En attente** et les tâches manuelles, mais les outils ne le refusent pas : un agent peut encore déplacer une telle carte. Les outils du tableau sont dans la liste d’outils de chaque discussion tant que la fonction est activée (environ 1 000 tokens par requête) ; désactivez-la si vous n’utilisez pas le tableau. La page lit le tableau toutes les 2 secondes tant qu’elle s’affiche ; un changement fait par un agent apparaît dans ce délai. Un texte que vous modifiez pendant qu’un agent change le même champ n’est pas enregistré : le panneau affiche le nouveau texte et la raison. Pas d’images, pas de synchronisation git entre ordinateurs et pas de partage par le réseau (Kanzo les propose). L’idée et l’apparence viennent de [Kanzo](https://github.com/emanuele-em/kanzo) par emanuele-em (AGPL-3.0) ; Composer Plus n’en utilise aucun code.
 - **Priorité au message envoyé après Arrêter** n’agit qu’après l’arrêt de la discussion (ou après un tour qui a échoué, ou à l’ouverture d’une discussion qui a encore une file) : un message envoyé pendant qu’un tour s’exécute attend toujours à la fin de la file. Il ne passe que devant vos propres messages en file : si un tour d’objectif ou une réponse à une question attend dans la file, l’ordre de dsh reste. Il lit une partie de dsh qui n’est pas une API publique (si le tour arrêté est encore en train de se terminer) ; si une mise à jour de dsh la renomme, le message ne passe devant qu’une fois ce tour terminé. Les discussions de sous-agents gardent l’ordre de dsh.
 - **Mémoire du projet** appartient au premier dossier de la discussion (le dossier de projet de dsh) : une discussion qui change de dossier avec `cd` garde la mémoire de son premier projet, et le même dossier ouvert par un autre chemin vers les mêmes fichiers la partage. Une discussion fige sa section de mémoire à son début : une note enregistrée plus tard apparaît donc à partir de la discussion suivante (`memory_recall` la trouve tout de suite). La revue garde seulement ce que le modèle décide de garder : elle peut manquer un fait ou en garder un faux ; vérifiez-les dans **Ouvrir la mémoire** et modifiez-les là, ou modifiez les fichiers à la main quand dsh est fermé. **Ouvrir la mémoire** envoie les notes du projet sélectionné et les notes globales (tous les projets quand vous sélectionnez Toutes les notes ; au plus environ 60 000 caractères, le reste est seulement compté et ne peut pas changer dans cette demande) et votre texte au modèle par défaut de dsh, pas au modèle de la discussion. Un aperçu est gardé sur le Mac 30 minutes et jusqu’au redémarrage de dsh ; si une revue ou l’agent modifie les notes entre-temps, **Appliquer** refuse et vous redemandez un aperçu. **Appliquer** enregistre toutes les modifications d’un aperçu ou aucune : si une modification ne peut pas être enregistrée (par exemple, MEMORY.md est plein), les notes restent telles quelles et la raison s’affiche. Chaque tour terminé avec un message de vous coûte un appel au modèle ; un appel en échec relit les mêmes messages après le tour suivant. Les discussions de sous-agents ne sont pas revues. L’idée et le format de fichier viennent de [DS Bot](https://github.com/Fei2411/DS-Bot) (Apache-2.0) ; Composer Plus n’utilise pas son code et ne lit ni n’écrit jamais la mémoire propre de DS Bot.
 - **Sauvegarde** utilise un seul dossier fixe, `~/Desktop/dsh-backups` (celui de dsh-backup par défaut, pour que ses archives restent utilisables) ; aucun réglage ne permet un autre dossier. Une archive est à peu près aussi grande que le dossier personnel de dsh sans `cache/` ni `dsh-runtimes/` (mesuré : 1,6 Go de fichiers ont donné une archive de 830 Mo en environ 30 s sur Apple Silicon ; dsh est resté réactif). Un fichier qui change pendant sa lecture est enregistré tel qu’il était quand la sauvegarde l’a ouvert : le journal d’une discussion ouverte peut donc se terminer par un enregistrement coupé, que dsh répare à sa prochaine écriture. Le masquage trouve un secret dans un fichier yml par le nom de sa clé sur une ligne (`token:`, `apiKey:`, …) ; un secret dans une map de flux (`{token: x}`), dans une liste sous une telle clé, dans un fichier JSON (par exemple l’`apiKey` d’un serveur MCP dans un fichier `.json`) ou sous un autre nom reste dans l’archive. Les archives par type de dsh-backup (`dsh-t-…`) ne sont pas listées. **Pour un autre ordinateur** copie l’archive (un clone sur APFS : aucun espace en plus) ; le vault ne la suit pas. **Sauvegarder maintenant** ne supprime aucune sauvegarde. Une sauvegarde automatique conserve les sauvegardes les plus récentes faites par Composer Plus (le réglage **Conserver** de **Sauvegarde automatique**) et supprime ses sauvegardes plus anciennes ; les instantanés d’avant une mise à niveau sont comptés à part (les 2 plus récents restent). Les archives de dsh-backup ne sont jamais supprimées : retirez-les avec **Supprimer**. Tant que dsh-backup est encore installé, il compte les archives de Composer Plus dans son propre nombre de copies conservées et peut les supprimer.
@@ -277,6 +285,8 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 
 **L’agent peut-il retenir mes préférences d’une discussion à l’autre, comme la mémoire de DS Bot ?** Oui, avec **Mémoire du projet** (désactivée par défaut) : activez-la dans **Réglages → Composer Plus**. Après chaque tour, vos préférences et décisions durables sont gardées sous forme de notes courtes pour le projet de la discussion, et chaque nouvelle discussion de ce projet les lit. Demandez à l’agent de retenir quelque chose : il l’enregistre tout de suite. Pour voir ou modifier les notes, cliquez sur **Ouvrir la mémoire** sur la même ligne et écrivez ce qu’il faut changer.
 
+**Mes agents et moi pouvons-nous partager un même tableau des tâches, comme avec Kanzo ?** Oui, avec **Tableau des tâches** (activé par défaut) : ouvrez-le dans la barre latérale gauche et ajoutez des tâches avec **Nouvelle tâche**. Dans une discussion, demandez à l’agent de « prendre la tâche suivante du tableau » : il déplace la carte vers **En cours**, commente ce qu’il a fait et la déplace vers **En revue**. Marquez une tâche comme **Manuelle** pour la garder pour vous.
+
 **dsh peut-il sauvegarder mes discussions et mes réglages, comme dsh-backup ?** Oui : **Réglages → Composer Plus → Sauvegarde → Sauvegarder maintenant**. Il écrit le même format d’archive dans le même dossier (`~/Desktop/dsh-backups`) : les archives de dsh-backup s’affichent donc aussi et se restaurent, et vous pouvez supprimer dsh-backup. Activez **Sauvegarde automatique** pour des sauvegardes planifiées.
 
 **dsh ne démarre plus. Comment restaurer une sauvegarde ?** Ouvrez le dossier de sauvegarde (`~/Desktop/dsh-backups`) et double-cliquez sur `Composer Plus Rescue.command` (Linux : `composer-plus-rescue.sh`, Windows : `Composer Plus Rescue.cmd`). Choisissez `3) Restore a backup`, sélectionnez-en une et tapez `RESTORE`. Cela fonctionne sans dsh.
@@ -301,6 +311,8 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 
 **Comment voir seulement les fichiers qu’une discussion a modifiés ?** Barre latérale droite → **Modifications** → **Cette discussion**. Cliquez sur **␣** pour masquer les modifications qui ne portent que sur des espaces.
 
+**Comment empêcher l’agent d’exécuter `npm publish` ou `git push --force` ?** **Réglages → Composer Plus → Commandes bloquées** : tapez `npm publish`, choisissez **bloquer** ou **demander d’abord**, puis cliquez sur **Ajouter**. **bloquer** refuse la commande et l’agent vous consulte ; **demander d’abord** affiche la carte d’approbation à chaque fois. Fichiers protégés couvre les outils de fichiers de l’agent ; Commandes bloquées couvre ses commandes shell.
+
 **Comment empêcher la revue automatique de redemander pour le même outil dans une discussion ?** Cliquez sur **Autoriser pour cette discussion** sur la carte d’approbation. Cela couvre cet outil précis dans cette discussion seulement, pendant 1 heure par défaut ; révoquez l’autorisation depuis la pastille de l’en-tête. Changez la durée dans **Réglages → Composer Plus → Autoriser pour cette discussion**.
 
 **J’ai perdu mon iPhone. Comment l’empêcher d’accéder à mon Mac ?** Cliquez sur **Connexion mobile** en bas à gauche de la barre latérale, puis sur **Remove** à côté de cet iPhone. Sa clé cesse tout de suite de fonctionner ; il ne peut revenir qu’avec un nouvel appairage que vous approuvez sur le Mac.
@@ -329,6 +341,8 @@ Testé sur dsh `0.2.0-rc.2` (bureau et web) et `0.2.1-rc.2` (web). La CI exécut
 
 **Puis-je envoyer une photo depuis mon iPhone ?** Oui. Dans une discussion Tether, touchez **+** à côté du champ de message → Camera, Photos (jusqu’à 4) ou Paste image. Les photos arrivent dans la discussion sur le Mac comme pièces jointes de votre message, donc le modèle les voit.
 
+**dsh peut-il lancer la commande suivante sans redemander au modèle ?** Oui, avec **Étapes planifiées** (désactivée par défaut) : activez-la dans Réglages → Composer Plus. Le modèle peut alors planifier ses prochaines commandes avec une condition, par exemple « lance les tests quand la compilation réussit », et Composer Plus exécute une étape sans nouvel appel au modèle quand le résultat remplit la condition. Les approbations et le sandbox ne changent pas.
+
 **Est-ce que cela fonctionne avec l’app de bureau ?** Oui : Réglages → Plugins → **Ajouter un plugin** → `dsh-composer-plus`. Testé sur dsh 0.2.0-rc.2 (bureau et web) et 0.2.1-rc.2 (web).
 
 ## Développement
@@ -393,6 +407,8 @@ PLAYWRIGHT=/path/to/playwright node test/browser-continue-queue.mjs /path/to/dsh
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-stop-send.mjs /path/to/dsh/lib/bin.js
 # Edit queued message in place with images and files (slow fake model) + its thumbnail
 SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-queue-edit.mjs /path/to/dsh/lib/bin.js
+# Task board: the page, the agent tools (fake model), drag and drop, search, the switch
+SHOT=1 PLAYWRIGHT=/path/to/playwright node test/browser-task-board.mjs /path/to/dsh/lib/bin.js
 ```
 
 ```sh