wdi-method 0.6.26 → 0.6.28

package/CHANGELOG.md

@@ -10,6 +10,71 @@ version contains every fix below it.
 
 ---
 
+## [0.6.28] - 2026-09-24
+
+A patch, but **read the reviewer change below before you update**: it changes what the daily autopilot
+will accept.
+
+### Changed: behaviour
+
+- **The peer-review guardrail pointed the wrong way, and now follows `delivery-flow-guide.md`.** The
+  dispatch template and `wdi-daily-autopilot` allowed `reviewer: none` only when every touched component
+  was `risk_accepted: low`, and required a reviewer everywhere else. The guide says the opposite: `low` is
+  the hardest review, with a two-reviewer panel on the code (`wdi-build` Step 3). Now a peer-review bypass
+  (`roles.reviewer: none`, `review_policy.peer_review: false`, `--skip-peer-review`, `--no-review`) is
+  **refused** when any touched component is `low`: `wdi-daily-autopilot` stops and names the components.
+  At `medium` or `high` the bypass is allowed and the choice is recorded in the mandate text and the ledger.
+  A new test checks the direction of both sentences; it was seen failing against the old text.
+- **Example reviewer runners are read-only.** The `sonnet` and `opus` examples in
+  `custom-dispatch.yaml.example` used `--dangerously-skip-permissions`; they now use
+  `--permission-mode plan`. The template names the read-only flag per CLI: `claude --permission-mode plan`,
+  `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. A test fails on any example runner without it.
+  The composer example also pins `composer-2.5[fast=false]` (landed on `main` after 0.6.27).
+
+### Changed: text
+
+- **Method block (`AGENTS.md` / `CLAUDE.md` in your repo):** "the eighteen skills" is now "the twenty-two
+  skills"; `wdi-init` has seven intents (`engines` and `readers` were missing); `wdi-upgrade` joins "Any
+  time"; the four daily tier skills are listed. The same count is carried into `method/README.md`,
+  `why/README.md` (new daily tier table), `why/portability.md`, `method-glossary.md`, and `wdi-init`
+  ("Seven intents").
+- **Skill frontmatter:** `wdi-daily-autopilot` now states `[self-review] [peer] [interval]
+  [--skip-peer-review|--no-review]`, as its body already did; `wdi-daily-what-to-build` names `--no-review`.
+  OpenCode command pointers read these descriptions, so they change on update.
+- **`wdi-prune-or-archive`** runs `lifecycle.py --dry-run` through `uv run`, never bare `python`.
+- **README and its nine translations** rewritten to match what the package does: G5 is Release, G3 is once
+  per product, four `mode` values and three `risk_accepted` values as the guide defines them, a "Decides"
+  column and G5 read from RTM rows, the Fast Path limits (one ticket, no money, personal data, or third
+  party), the daily command syntax copied from the skills, six field rules plus a Configuration section,
+  a skills directory with "How It Starts", prerequisites (Node.js 20+, Git, uv), a neutral note that the
+  installer turns off model invocation for 13 BMad build and sprint skills and adds deny rules to
+  `.claude/settings.json`, and "The name and the icon" in place of the trademark line. The "Fase 4" label
+  is gone; the daily tier is "Autonomous Daily Operations (Daily Tier)".
+- **npm listing:** `package.json` `description` now matches the GitHub repo description, and `keywords`
+  are added from the repo topics.
+
+**What a repo that already has the method installed does about it.** Run
+`npx wdi-method@latest update --yes`. The method block in `AGENTS.md`, `CLAUDE.md`, and the other platform
+files changes, and so do the skills above. `.control/custom-dispatch.yaml.example` is replaced, but your
+own `.control/custom-dispatch.yaml` is **not** touched: if it copied the old `sonnet` or `opus` runner for
+a reviewer, change `--dangerously-skip-permissions` to `--permission-mode plan` yourself. If you run the
+daily autopilot with `reviewer: none` or `--skip-peer-review` on a component at `risk_accepted: low`, it
+now stops: give it a reviewer, or raise that component's `risk_accepted` with `wdi-init` intent `risk`.
+
+## [0.6.27] - 2026-09-20
+
+### Added
+
+- **Validation Rule `scratch-hygiene` in `validate.py`:** Added strict structural hygiene enforcement for the specification workspace root (`.scratch/`). Active specs live exclusively inside registered `.scratch/<spec-id>-<slug>/` directories. Loose files directly under `.scratch/` root (e.g. `prompt-*.txt`, `output-*.txt`, logs, transcripts) and unregistered child directories immediately fail validation with finding `scratch-hygiene`. Additionally, verifies that `.work/` contains no `SPEC.md` files.
+- **Defensive Scratch Dumps `.gitignore` Scaffolding in `bin/wdi-method.js`:** Expanded `ensureGitignoreScratchDumps()` during install and update to automatically add defensive ignore rules to consumer `.gitignore`: `.scratch/*.txt`, `.scratch/*.log`, `.scratch/*-review-output.md`, `.scratch/*-second-opinion.md`, and `.scratch/tmp/`, preventing accidental execution transport dumps from polluting git status.
+
+### Changed
+
+- **Spec Workspace vs Execution Scratch Boundaries in `repo-guide.md` & `AGENTS.md`:** Clarified that `.scratch/` is strictly a registered spec workspace (authoritative and git-tracked), NOT an informal scratchpad. Loose files and ad-hoc folders are forbidden. All subagent transport packets, raw CLI redirection dumps, and review transcripts MUST be written to `.work/<skill>/` and deleted upon completion.
+- **Skill Transport Discipline in `wdi-build`:** Explicitly added transport guardrails forbidding placing execution scratch, prompt handoffs, or tool logs in `.scratch/`.
+
+**What a repo that already has the method installed does about it.** Run `npx wdi-method@latest update`. It updates `validate.py`, the build skills, and automatically appends defensive ignore patterns to `.gitignore`. Any loose files in `.scratch/` should be deleted or moved to `.work/`.
+
 ## [0.6.26] - 2026-09-20
 
 ### Added

package/README.de.md

@@ -0,0 +1,262 @@
+# WDI Method
+
+> Eine Überprüfungsschicht auf BMad: Dokumente, die ein Mensch liest, um technische Entscheidungen zu prüfen, bevor Code geschrieben wird, bemessen an dem, was die Änderung tatsächlich verdient.
+
+[English](README.md) | [Bahasa Indonesia](README.id.md) | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [한국어](README.ko.md) | [Español](README.es.md) | [Deutsch](README.de.md) | [Français](README.fr.md) | [Português (Brasil)](README.pt-BR.md) | [Русский](README.ru.md)  
+[Website](https://wiradelta.id/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
+
+---
+
+> **Übersetzungshinweis:** Diese Datei ist eine Übersetzung von [README.md](README.md) und dient ausschließlich Informationszwecken. Bei Widersprüchen oder Auslegungsunterschieden ist die offizielle englische Originalfassung (`README.md`) maßgeblich. Alle tiefergehenden technischen Dokumentationen und rechtlichen Bedingungen werden auf Englisch geführt.
+
+[BMad](https://github.com/bmad-code-org/BMAD-METHOD) schreibt Dokumente für KI-Agenten. WDI Method fügt Dokumente hinzu, die viele Rollen bereits lesen: Use Cases, C4-Diagramme, API- und Datenbanklisten sowie Designdokumente. Es umschließt BMad, ohne es zu ersetzen: Jeder WDI-Skill übergibt das Schreiben an einen BMad-Skill und prüft das Ergebnis anschließend anhand der Leitfäden der Methode.
+
+> Dieses Repository ist **öffentlich und generisch**. Es DARF KEINEN Kundennamen, keinen kommerziellen Produktnamen und keinen Link zu einem privaten Repository enthalten. Die Produktidentität liegt vollständig in dem Repository, das es installiert.
+
+---
+
+## KI-gestützte Entwicklung (AiDD) vs. Vibe Coding
+
+Auch Vibe Coding nutzt Spezifikationen, aber nicht konsequent: Jede Prompt-Sitzung kann anders ausfallen, die Dokumente sind unstrukturiert, und der Prozess wird nicht systematisch gehalten. Das Ergebnis ist eine deutlich geringere Effizienz und Wirksamkeit und ein reales Risiko, technische Schulden anzuhäufen. Deshalb braucht es ein Framework.
+
+In WDI Method läuft AI-Driven Development (AiDD) in einer festen Reihenfolge: Versprechen, registriert als FR und Use Cases, dann die Gates, dann die Spezifikation, mit `to-spec` und `to-tickets` in Tickets geschnitten, dann jedes Ticket test-first gebaut, dann ein PR, den der Owner prüft und merged.
+
+Drei Schichten erledigen die Arbeit:
+
+| Schicht | Wer | Was sie tut |
+|---|---|---|
+| 1. Dokumente für Agenten | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | Schreibt den Product Brief, das PRD, die UX und das Architektur-Rückgrat, jeweils über einen BMad-Skill |
+| 2. Überprüfungsschicht | WDI Method | Umschließt diese Skills, fügt die Dokumente hinzu, die andere Rollen lesen, führt fünf menschliche Gates durch, verknüpft Ziel → FR → UC → Ticket → Test und prüft das Korpus auf Drift |
+| 3. Tickets und Code | Engines ([mattpocock/skills](https://github.com/mattpocock/skills)) | `to-spec` und `to-tickets` schneiden die Spezifikation in vertikale Tickets; `implement` baut jedes davon test-first |
+
+### Dokumente folgen dem Code (Documents Follow Code)
+
+Ein Dokument, das hinter dem Code zurückliegt, ist in seinem erwarteten Zustand und kein Fehler. Wo der Owner den Code einem Dokument vorgezogen hat, wird das Dokument korrigiert. Ein Dokument, das dem Code voraus ist, etwa eine noch nicht gebaute Spezifikation, ist ebenfalls normal.
+
+---
+
+## Installation in 3 Schritten
+
+### Voraussetzungen
+
+- Node.js 20 oder neuer.
+- Git.
+- [uv](https://docs.astral.sh/uv/), das die Python-3.11+-Validatoren der Methode ausführt.
+- Eine Agentenplattform: Claude Code, Cursor, Codex und andere Agentenplattformen.
+
+Führen Sie die drei Schritte der Reihe nach aus. Der Installer bricht ab, wenn Schritt 1 oder Schritt 2 nicht erledigt ist. Alle Abfragen bieten Standardwerte an; mit <kbd>Enter</kbd> übernehmen Sie sie.
+
+### Schritt 1: BMad Method installieren
+```bash
+cd /path/to/your/product-repo
+npx bmad-method install
+```
+
+### Schritt 2: Die sechs Engines hinzufügen
+Installieren Sie die Engines in Ihr Repository (wählen Sie "copy" oder "symlink"):
+```bash
+npx skills@latest add mattpocock/skills
+```
+*Wählen Sie alle sechs Engines, die die Methode ansteuert:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review` und `domain-modeling`.
+
+> **Warum das Claude-Code-Plugin nicht ausreicht:** Drei der sechs Engines (`to-spec`, `to-tickets`, `implement`) werden mit `disable-model-invocation: true` ausgeliefert. Bei jeder Installation und jedem Update entfernt WDI Method diese Zeile aus den Kopien in Ihrem Repository, damit `wdi-build` und `wdi-autopilot` sie ausführen können. Ein Plugin auf Benutzerebene kann es nicht bearbeiten, daher bricht der Installer ab, bis die Engines im Repository liegen. `--skip-engines-check` überspringt diese Prüfung.
+
+### Schritt 3: WDI Method installieren
+Startet den interaktiven Installer und legt die Skills dort ab, wo jede Ihrer Agentenplattformen sie liest:
+```bash
+npx wdi-method
+```
+*(Nicht interaktiv: `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
+
+> **Was der Installer an BMad ändert:** Der Installer schaltet außerdem den Modellaufruf für 13 Build- und Sprint-Skills von BMad ab, die die Engines ersetzen, und fügt passende Deny-Regeln in `.claude/settings.json` ein. Sie können sie weiterhin ausführen, indem Sie den Befehl eintippen.
+
+### Ihr erster Befehl: `/wdi-help`
+Führen Sie in Ihrem Coding-Agenten aus:
+```text
+/wdi-help
+```
+`wdi-help` liest `.control/registry/` und nennt Ihnen das Gate, an dem Ihr Projekt steht, die offenen Spezifikationen und den nächsten Skill, ohne aus dem Gesprächsverlauf zu raten.
+
+---
+
+## Drei Workflow-Optionen
+
+WDI Method bemisst seinen Aufwand an Umfang und Risiko der Aufgabe.
+
+### Option A: Geführter Lieferpfad (G1 bis G5)
+Für neue Produkte, größere Initiativen und Architekturänderungen. Sie starten den Skill jedes Gates; der Agent nennt den nächsten und wartet.
+
+**Eine Entscheidung pro Gate.** Jedes Gate entscheidet eine Sache. Bei G1 bis G4 lesen Sie eine gerenderte Seite; bei G5 lesen Sie die RTM-Zeilen der Spezifikation. Sie beantworten eine kurze Checkliste, und ein einziges "Nein" auf eine markierte Frage hält das Gate an.
+
+| Gate | Entscheidet | Skill | Was Sie lesen | Entscheidung des Owners |
+|---|---|---|---|---|
+| **G1 Problem** | Was das Problem ist, wessen Problem es ist und warum es Arbeit verdient | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | Die Problemstellung genehmigen |
+| **G2 Product** | Was gebaut wird und wie es sich in der Nutzung anfühlt | `/wdi-product`<br>`/wdi-ux` (optional) | `.what-rendered/_prd/<slug>/prd.md` | Die funktionalen Versprechen (FR) genehmigen |
+| **G3 Blueprint** | Das Gesamtbild des Produkts, einmal pro Produkt | `/wdi-blueprint` | `.how-rendered/blueprint.md` | Das Architektur-Rückgrat genehmigen |
+| **G4 Component** | Wie eine Komponente gebaut wird (übersprungen bei `mode: catalog`) | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | Das Softwaredesign genehmigen |
+| **G5 Release** | Ob es fertig und nachgewiesen ist | `/wdi-build` | Die RTM-Zeilen der Spezifikation in `.control/generated/` und der Testnachweis jedes Tickets | Die Spezifikation als fertig abnehmen oder zurückgeben |
+
+**Verfeinern, nicht weitergehen.** Ein einziges "Nein" auf eine mit Stern (★) markierte Frage der Checkliste hält das Gate an. Verfeinern Sie das Dokument und führen Sie das Gate erneut aus; genehmigen Sie es nicht mit dem Plan, es später zu korrigieren.
+
+#### Zwei Felder, die nie verschmelzen
+- **`mode`** legt fest, wie tief die Dokumente jeder Komponente gehen. `catalog` (Standard): nichts über das Blueprint hinaus, und G4 wird übersprungen. `outline`: vollständige Abläufe für bis zu 3 Use Cases, lokale Geschäftsregeln, eine Entscheidungszusammenfassung. `guarded`: fügt einen Abschnitt `Failure Behaviour` für jede Grenze sowie Dokumente zu Drittanbieter-Integrationen hinzu. `deep`: fügt Robustheitsanalyse, einen Vertrag pro Endpoint, ein Datenwörterbuch, Ablaufdiagramme und Zustandsautomaten hinzu.
+- **`risk_accepted`** legt fest, wie streng die Überprüfung ist. `high` (Sie akzeptieren viel Risiko): die grundlegenden Linsen für Struktur und Text. `medium`: fügt die Edge-Case-Linse hinzu. `low`: fügt die Edge-Case-Linse hinzu, und der Code braucht zwei Reviewer, die nicht der Builder sind.
+
+Würde ein Feld beides festlegen, wäre der einzige Weg zu einem schlanken Dokument, mehr Risiko in das Risikoprotokoll zu schreiben, als Sie tatsächlich akzeptieren.
+
+---
+
+### Option B: Autonome Tagesabläufe (Daily Tier)
+Sobald die Architektur steht, läuft die tägliche Arbeit als Tagesrhythmus über vier Skills, die Sie in Ihrem Agenten eintippen:
+
+1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
+   Wandelt Notizen aus manuellen Tests, QA-Beobachtungen oder Fehlerberichte in eine geprüfte Spezifikation oder ein geprüftes Ticket auf dem Entwicklungsbranch um, für einen späteren Autopilot-Lauf. Dort hört es auf: Es macht nie einen Commit oder Push und startet nie den Autopilot.
+2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
+   Prüft, ob ein akzeptiertes Mandat vorliegt, und führt den Preflight aus, wenn keines vorliegt, ermittelt die Reviewer aus der lokalen Konfiguration und startet die Schleife (Standard `/loop 10m /wdi-autopilot`). Die Schleife arbeitet auf dem Branch `autopilot/<mandate-id>`, schreibt den Code test-first, hält jede Entscheidung in ihrem Ledger fest und endet mit einem PR, der zur Überprüfung bereit ist. Der Owner merged.
+3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
+   Nach einem Merge: synchronisiert den Entwicklungsbranch, räumt gemergte Branches und Worktrees ab, bereitet die App für manuelle Tests vor und erstellt eine Checkliste aus den seit der letzten Synchronisation geschlossenen Tickets (`before_sync..HEAD`). Ohne Argument synchronisiert es nur, räumt ab und erstellt die Checkliste.
+4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
+   Verschiebt geschlossene Spezifikationen aus `.scratch/` nach `.archive/specs/` oder entfernt sie mit `git rm`, über `lifecycle.py`, das zuerst prüft und bei einem Fehler zurückrollt. Die Zeile der Spezifikation bleibt in `specs.yaml`. Ohne Argument fragt es nach.
+
+---
+
+### Option C: Schneller Pfad (`/implement` direkt)
+Eine Korrektur darf jedes Gate überspringen, wenn sie kein FR, keinen UC, kein AD-N und nicht das Domänenmodell ändert, höchstens ein Ticket umfasst und weder Geld noch personenbezogene Daten noch eine Drittanbieter-Integration berührt. Sie führen `/implement` direkt aus, ohne Wrapper-Skill. Stellt sich heraus, dass die Korrektur ein FR berührt, stoppt die Arbeit und wird zu einer Spezifikation der Größe S (höchstens 3 Tickets), die über `wdi-build` läuft.
+
+---
+
+## Praxisregeln
+
+Betriebsregeln aus dem Betrieb autonomer Coding-Schleifen in echten Produkt-Repositories:
+
+### 1. Builder fest beim Koordinator (`builder: coordinator`)
+In `wdi-daily-autopilot` ist `roles.builder` in `.control/custom-dispatch.yaml` fest auf `coordinator` gesetzt. Das Delegieren von Code an Subagenten führte zu falschen Abschlussmeldungen (ein Subagent behauptete, die Tests seien bestanden, ohne eine Datei bearbeitet zu haben). Die koordinierende Sitzung schreibt den Code selbst, test-first.
+
+### 2. Reviewer nur mit Lesezugriff
+Peer-Reviewer laufen nur mit Lesezugriff. Sie hinterfragen Edge Cases und lesen Diffs, ändern aber nie Code und führen nie Builds aus; nur die koordinierende Sitzung schreibt. Bei `risk_accepted: low` wird das Umgehen des Peer-Reviews abgelehnt, weil der Code dort zwei Reviewer braucht, die nicht der Builder sind.
+
+### 3. Dateisperren unter Windows (Desktop Process Gate)
+Unter Windows hält ein laufendes App-Binary oder ein Build-Daemon im Hintergrund Datei-Handles offen, und ein Rebuild oder das Löschen eines Worktrees schlägt dann mit `Access is denied` fehl. Mit dem Ziel `desktop` prüft `wdi-daily-what-to-test` vor dem Rebuild, ob das App-Binary noch läuft. Es schließt die App nur, wenn sein eigener vorheriger Smoke-Lauf sie gestartet hat; andernfalls meldet es die PID und hält an, damit Sie sie selbst schließen können. Es beendet nie einen Prozess gewaltsam.
+
+### 4. Die Schleife läuft auf ihrem eigenen Branch
+Das Verfassen von Spezifikationen und Tickets geschieht auf dem Entwicklungsbranch. Die Schleife läuft auf ihrem eigenen Branch, `autopilot/<mandate-id>`, in einem isolierten Worktree oder in einem sauberen Checkout, den nur dieser Lauf nutzt. Sie läuft nie auf einem geteilten oder unsauberen Checkout.
+
+### 5. Ein Cloud-CI-Lauf pro Autopilot-Lauf
+Die Schleife macht pro Ticket einen Commit, und die lokale Testsuite ist während des Laufs der Nachweis. Cloud CI läuft einmal pro Autopilot-Lauf, am Ende: wenn der eine PR als bereit zur Überprüfung markiert wird oder wenn der Workflow einmal ausgelöst wird. Pushes während des Laufs starten keinen Cloud-Lauf.
+
+### 6. Maschinenlokale Smoke-Dateien
+Smoke-Cursor (`.work/smoke/last-sync`) und Runtime-Manifeste gehören zu einer Maschine. Der Installer fügt `.work/smoke/` zu `.gitignore` hinzu, sodass maschinenlokale Smoke-Dateien den Arbeitsbaum nie unsauber hinterlassen.
+
+---
+
+## Konfiguration (`custom-dispatch.yaml`)
+
+Maschinenspezifische Runner-Befehle und Modell-Flags liegen in `.control/custom-dispatch.yaml`. Der Installer erstellt die Datei aus `.control/custom-dispatch.yaml.example`, wenn sie fehlt, und fügt sie zu `.gitignore` hinzu; nur das Beispiel wird committet.
+
+Ein als Reviewer benannter Runner MUSS nur Lesezugriff haben. Das Flag für Lesezugriff je CLI: `claude --permission-mode plan`, `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. Die Beispiel-Runner in der Vorlage verwenden es alle.
+
+---
+
+## Skill-Verzeichnis (22)
+
+WDI Method installiert 22 Skills: 7 Gate-Skills, 5 für das Daily Tier (einschließlich `wdi-autopilot`) und 10, die Sie jederzeit ausführen.
+
+Wie ein Skill startet:
+- **Sie tippen ihn ein**: die vier Daily-Tier-Skills, `wdi-build` und `wdi-explain-to-me` (sie tragen `disable-model-invocation: true`).
+- **Sie tippen ihn ein, oder der Agent nennt ihn und wartet auf Ihre Freigabe**: die übrigen Skills.
+- **Der Agent darf ihn selbstständig ausführen (nur Lesezugriff)**: `wdi-help`.
+- **Ausgelöst durch `/loop` unter einem akzeptierten Mandat**: `wdi-autopilot`. Unter einem Mandat führt `wdi-autopilot` auch die übrigen Skills aus.
+
+| Skill | Was er tut | Wie er startet |
+|---|---|---|
+| **Gate-Skills** | | |
+| `/wdi-init` | Vor G1 und am Ende von G2: richtet Registries, Komponenten, `mode` und `risk_accepted`, die zwei Strukturkarten, die Engine-Prüfung und Inventar-Leser ein. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-problem` | G1. Führt den Product-Brief-Skill von BMad aus und prüft den Brief anschließend anhand des Leitfadens der Methode. Schreibt den Brief nie selbst. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-product` | G2. Führt den PRD-Skill von BMad für ein neues PRD oder ein geändertes Versprechen aus und prüft es anschließend anhand des PRD-Leitfadens. Schreibt das PRD nie selbst. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-ux` | Optional, zusammen mit G2. Führt den UX-Skill von BMad aus und legt die Designergebnisse dort ab, wo sie hingehören. Schreibt nie selbst UX-Inhalte. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-blueprint` | G3, einmal pro Produkt. Das Gesamtbild des Produkts: Use Cases, Akteure, Domänenmodell, Geschäftsregeln, Glossar, das Architektur-Rückgrat, C4 sowie die API-, Tabellen- und Bildschirminventare. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-component` | G4. Die Tiefe einer Komponente, so tief wie ihr `mode` und nicht tiefer. Übersprungen bei `mode: catalog`. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-build` | G5. Eine Spezifikation von offen bis geschlossen: Sie führen `to-spec` und `to-tickets` aus, jedes Ticket geht bis zu einem grünen PR, dann wird die Spezifikation geschlossen. Es merged nie. | Sie tippen ihn ein |
+| **Daily Tier** | | |
+| `/wdi-daily-what-to-build` | Wandelt Notizen aus manuellen Tests in eine geprüfte Spezifikation oder ein geprüftes Ticket für einen späteren Autopilot-Lauf um. Hält vor Code, Commit oder Push an. | Sie tippen ihn ein |
+| `/wdi-daily-autopilot` | Prüft, ob ein akzeptiertes Mandat vorliegt (führt den Preflight aus, wenn keines vorliegt), ermittelt die Reviewer aus der lokalen Konfiguration und startet die Schleife, standardmäßig alle 10 Minuten. | Sie tippen ihn ein |
+| `/wdi-autopilot` | Die Schleife selbst: arbeitet jedes FR unter einem akzeptierten Mandat ab, auf einem Branch mit einem PR, und schreibt jede Entscheidung in ein Ledger. | Ausgelöst durch `/loop` unter einem akzeptierten Mandat |
+| `/wdi-daily-what-to-test` | Nach einem Merge: synchronisiert den Entwicklungsbranch, räumt gemergte Branches und Worktrees ab, bereitet die App für manuelle Tests vor und erstellt eine Checkliste aus den geschlossenen Tickets. | Sie tippen ihn ein |
+| `/wdi-prune-or-archive` | Verschiebt geschlossene Spezifikationen nach `.archive/specs/` oder entfernt sie mit `git rm`, über `lifecycle.py`, das zuerst prüft und bei einem Fehler zurückrollt. Die Zeile der Spezifikation bleibt in `specs.yaml`. | Sie tippen ihn ein |
+| **Jederzeit** | | |
+| `/wdi-help` | Liest die Status-Registry und nennt Ihnen das aktuelle Gate, die offenen Spezifikationen und den nächsten Skill. | Der Agent darf ihn selbstständig ausführen (nur Lesezugriff) |
+| `/wdi-explain-to-me` | Übernimmt das Lesen, bevor Sie entscheiden: recherchiert und informiert Sie dann in sechs festen Abschnitten. Schreibt keine Datei. | Sie tippen ihn ein |
+| `/wdi-decision` | Eröffnet, akzeptiert und wendet eine nummerierte Entscheidung (`DEC-`) an und überträgt sie in die Dokumente, die sie regelt. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-question` | Legt etwas, das sich jetzt nicht entscheiden lässt, in einer von vier Listen in `.control/questions/` ab und schließt es, wenn die Antwort eintrifft. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-log` | Hält ein beendetes Meeting oder eine nicht technische Tatsache fest, die einschränkt, was gebaut werden darf. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-report` | Zahlen zum Projekt: Fortschritt, Schätzungen, Aufgabenzeilen für einen Tracker oder ein eigenständiger Brief oder ein eigenständiges PRD. Erfindet nie eine Zahl. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-reconcile` | Vor einem Gate oder nach einer Reihe von Änderungen: meldet Drift zwischen `.what`, `.how`, `.control` und den Regeln der Methode. Nur Lesezugriff. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-review` | Prüft jedes Korpusdokument und muss vor einem Gate für das Rückgrat, SRS, SDD und SPEC laufen. Seine Linsen folgen `risk_accepted`. Nicht für Code-Reviews. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-systematic-debugging` | Für jeden Fehler, fehlschlagenden Test oder fehlgeschlagenen Build, bevor eine Korrektur vorgeschlagen wird: die Grundursache finden und jeweils eine Hypothese testen. | Sie tippen ihn ein, oder der Agent nennt ihn |
+| `/wdi-upgrade` | Direkt nach `wdi-method update`: überführt Dokumente und Registry-Dateien, die noch in der alten Form vorliegen, in die neue und prüft anschließend, ob die Validierung grün ist. | Sie tippen ihn ein, oder der Agent nennt ihn |
+
+---
+
+## Repository-Struktur
+
+```text
+.constitution/
+  method/                  The method itself: overwritten by every update; never edit here
+  project/                 Product-owned rules and inventory readers: kept across updates
+.control/
+  registry/                The registries: index.yaml · goals.yaml · specs.yaml · components.yaml
+  generated/               Status and RTM projections written by validate.py (never by hand)
+  decisions/               Decisions and owner mandates (DEC-*.md)
+  memlog/                  Ledgers recording autonomous loop decisions
+  test-targets/            Hand-testing templates (desktop.md, web.md, mobile.md)
+.scratch/<spec-id>-<slug>/ Active spec workspaces (SPEC.md and tickets)
+.archive/                  Archived closed specs
+.what/ & .how/             Working corpus documents (brief, PRD, SRS, blueprint, SDD)
+.what-rendered/            Rendered pages for G1 and G2 (generated)
+.how-rendered/             Rendered pages for G3 and G4 (generated)
+.work/                     Scratch that empties when a task closes
+```
+
+---
+
+## Mitwirkung
+
+Jeder Beitrag zu WDI Method beantwortet eine Frage: **Macht dies die Überprüfungsschicht vertrauenswürdiger, oder macht es sie nur dicker?** Siehe [CONTRIBUTING.md](CONTRIBUTING.md).
+
+### Fixture Corpus und lokale Verifikation
+Änderungen an Validatoren und an der Methode werden gegen das Fixture Corpus (`tests/fixture/`) nachgewiesen. Führen Sie die Suite aus, bevor Sie einen Pull Request öffnen:
+```bash
+npm test
+```
+Die Suite führt die vier Python-PEP-723-Skripte (`validate.py`, `timeline.py`, `inventory.py`, `lifecycle.py`) gegen das Fixture aus und prüft die Plattform-Registry, die Dateien, die jede Plattform erhält, sowie die Integrität des Kits.
+
+### Richtlinie für öffentliche generische Pakete
+WDI Method wird in der öffentlichen npm-Registry veröffentlicht. Es darf nie private Kundennamen, kommerzielle Produktidentitäten, Zugangsdaten oder absolute Dateisystempfade enthalten.
+
+---
+
+## Lizenz und Datenschutz
+
+- **Code-Lizenz:** [MIT-Lizenz](LICENSE).
+- **Datenschutz:** WDI Method selbst macht keine Netzwerkaufrufe; Ihr Coding-Agent kommuniziert weiterhin mit seinem Modellanbieter. Siehe [PRIVACY.md](PRIVACY.md) und [SECURITY.md](SECURITY.md).
+
+## The name and the icon
+
+Maßgeblich ist der folgende englische Text.
+
+The MIT License grants broad rights over the code. It says nothing about names or logos,
+and it does not oblige the studio to hand over either — so the licence above covers this
+repository's code, not the name **WDI Method**, not **Wira Delta Indonesia**, and not any
+associated visual marks or logos.
+
+You may use those names to refer to this project: "based on WDI Method", "a fork of WDI Method",
+or "compatible with WDI Method". You may not use them as the name of your own product or
+methodology, or in a way that suggests you are this project or endorsed by it.
+
+If you publish a modified distribution or fork, please give it your own name, so the
+engineers using it know whom to ask when something behaves unexpectedly. The code is yours
+to take; the name is not.
+
+---
+
+Wir verwenden dieselbe Methode in Kundenprojekten. [Wira Delta Indonesia kontaktieren](https://wiradelta.id/#contact).

package/README.es.md

@@ -0,0 +1,262 @@
+# WDI Method
+
+> Una capa de revisión sobre BMad: documentos que un humano lee para revisar las decisiones técnicas antes de escribir código, dimensionados según lo que el cambio realmente merece.
+
+[English](README.md) | [Bahasa Indonesia](README.id.md) | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [한국어](README.ko.md) | [Español](README.es.md) | [Deutsch](README.de.md) | [Français](README.fr.md) | [Português (Brasil)](README.pt-BR.md) | [Русский](README.ru.md)  
+[Website](https://wiradelta.id/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
+
+---
+
+> **Aviso de traducción:** Este archivo es una traducción de [README.md](README.md) sólo para fines de conveniencia. En caso de discrepancia o conflicto de interpretación, la versión oficial en inglés (`README.md`) prevalece como autorizada. Toda la documentación técnica profunda y los documentos legales se mantienen en inglés.
+
+[BMad](https://github.com/bmad-code-org/BMAD-METHOD) escribe documentos para agentes de IA. WDI Method añade documentos que muchos roles ya leen: casos de uso, diagramas C4, listas de API y de base de datos, y documentos de diseño. Envuelve a BMad sin reemplazarlo: cada skill de WDI delega la redacción a una skill de BMad y después verifica el resultado contra las guías del método.
+
+> Este repositorio es **público y genérico**. NO DEBE incluir un nombre de cliente, un nombre de producto comercial ni un enlace a un repositorio privado. La identidad del producto vive por completo en el repositorio que lo instala.
+
+---
+
+## Desarrollo Impulsado por IA (AiDD) vs. Vibe Coding
+
+El vibe coding también usa especificaciones, pero no de forma consistente: cada sesión de prompts puede ser distinta, los documentos no tienen estructura y el proceso no se mantiene sistemático. El resultado es una eficiencia y una eficacia mucho menores, y un riesgo real de acumular deuda técnica. Por eso hace falta un framework.
+
+En WDI Method, el Desarrollo Impulsado por IA (AiDD) sigue un orden: promesas registradas como FR y casos de uso, luego las compuertas, luego la especificación dividida en tickets con `to-spec` y `to-tickets`, luego cada ticket construido con pruebas primero y, por último, un PR que el propietario revisa y fusiona.
+
+Tres capas hacen el trabajo:
+
+| Capa | Quién | Qué hace |
+|---|---|---|
+| 1. Documentos para agentes | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | Escribe el product brief, el PRD, la UX y la espina dorsal de la arquitectura, cada uno mediante una skill de BMad |
+| 2. Capa de revisión | WDI Method | Envuelve esas skills, añade los documentos que leen otros roles, ejecuta cinco compuertas humanas, vincula Objetivo → FR → UC → Ticket → Prueba y verifica que el corpus no se desvíe |
+| 3. Tickets y código | Motores ([mattpocock/skills](https://github.com/mattpocock/skills)) | `to-spec` y `to-tickets` dividen la especificación en tickets verticales; `implement` construye cada uno con pruebas primero |
+
+### Los Documentos Siguen al Código (Documents Follow Code)
+
+Un documento que va detrás del código está en su estado esperado, no es un defecto. Cuando el propietario eligió el código en lugar de un documento, lo que se corrige es el documento. Un documento que va por delante del código, como una especificación aún no construida, también es normal.
+
+---
+
+## Instalación en 3 Pasos
+
+### Requisitos previos
+
+- Node.js 20 o posterior.
+- Git.
+- [uv](https://docs.astral.sh/uv/), que ejecuta los validadores del método en Python 3.11+.
+- Una plataforma de agentes: Claude Code, Cursor, Codex y otras plataformas de agentes.
+
+Ejecute los tres pasos en orden. El instalador se detiene si no se ha hecho el paso 1 o el paso 2. Todas las solicitudes ofrecen valores predeterminados; presione <kbd>Enter</kbd> para aceptarlos.
+
+### Paso 1: Instalar BMad Method
+```bash
+cd /path/to/your/product-repo
+npx bmad-method install
+```
+
+### Paso 2: Agregar los Seis Motores
+Instale los motores en su repositorio (elija "copy" o "symlink"):
+```bash
+npx skills@latest add mattpocock/skills
+```
+*Seleccione los seis motores que usa el método:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review` y `domain-modeling`.
+
+> **Por qué el plugin de Claude Code no basta:** Tres de los seis motores (`to-spec`, `to-tickets`, `implement`) se publican con `disable-model-invocation: true`. En cada instalación y actualización, WDI Method elimina esa línea de las copias de su repositorio para que `wdi-build` y `wdi-autopilot` puedan ejecutarlos. No puede editar un plugin a nivel de usuario, así que el instalador se detiene hasta que los motores estén en el repositorio. `--skip-engines-check` omite esta verificación.
+
+### Paso 3: Instalar WDI Method
+Inicia el instalador interactivo y coloca las skills donde cada una de sus plataformas de agentes las lee:
+```bash
+npx wdi-method
+```
+*(No interactivo: `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
+
+> **Qué cambia el instalador en BMad:** El instalador también desactiva la invocación por el modelo en 13 skills de construcción y de sprint de BMad que los motores reemplazan, y añade las reglas de denegación correspondientes a `.claude/settings.json`. Todavía puede ejecutarlas escribiendo el comando.
+
+### Su Primer Comando: `/wdi-help`
+Dentro de su agente de codificación, ejecute:
+```text
+/wdi-help
+```
+`wdi-help` lee `.control/registry/` y le indica la compuerta en la que está su proyecto, las especificaciones abiertas y la siguiente skill, sin conjeturar a partir de la conversación.
+
+---
+
+## Tres Opciones de Flujo de Trabajo
+
+WDI Method ajusta su ceremonia a la escala y al riesgo de la tarea.
+
+### Opción A: Vía Guiada de Entrega (G1 a G5)
+Para productos nuevos, iniciativas principales y cambios de arquitectura. Usted inicia la skill de cada compuerta; el agente nombra la siguiente y espera.
+
+**Una Decisión por Compuerta.** Cada compuerta decide una cosa. En G1 a G4 usted lee una página generada; en G5 lee las filas RTM de la especificación. Responde una lista de verificación breve, y un solo "no" en una pregunta marcada con estrella detiene la compuerta.
+
+| Compuerta | Decide | Skill | Qué lee usted | Decisión del propietario |
+|---|---|---|---|---|
+| **G1 Problem** | Cuál es el problema, de quién es y por qué merece trabajo | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | Aprobar el planteamiento del problema |
+| **G2 Product** | Qué se construye y cómo se siente al usarlo | `/wdi-product`<br>`/wdi-ux` (opcional) | `.what-rendered/_prd/<slug>/prd.md` | Aprobar las promesas funcionales (FR) |
+| **G3 Blueprint** | La imagen completa del producto, una vez por producto | `/wdi-blueprint` | `.how-rendered/blueprint.md` | Aprobar la espina dorsal de la arquitectura |
+| **G4 Component** | Cómo se construye un componente (se omite con `mode: catalog`) | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | Aprobar el diseño de software |
+| **G5 Release** | Si está terminado y demostrado | `/wdi-build` | Las filas RTM de la especificación en `.control/generated/` y la evidencia de pruebas de cada ticket | Aceptar la especificación como terminada, o devolverla |
+
+**Refinar, No Avanzar.** Un solo "no" en una pregunta marcada con estrella (★) de la lista de verificación detiene la compuerta. Refine el documento y ejecute la compuerta otra vez; no la apruebe con la idea de corregirlo después.
+
+#### Dos Campos que Nunca se Fusionan
+- **`mode`** fija la profundidad de los documentos de cada componente. `catalog` (predeterminado): nada más allá del blueprint, y G4 se omite. `outline`: flujos completos para hasta 3 casos de uso, reglas de negocio locales y un resumen de decisiones. `guarded`: añade una sección `Failure Behaviour` para cada frontera y documentos de integración con terceros. `deep`: añade análisis de robustez, un contrato por endpoint, un diccionario de datos, diagramas de flujo y máquinas de estado.
+- **`risk_accepted`** fija la dureza de la revisión. `high` (usted acepta mucho riesgo): las lentes base de estructura y de prosa. `medium`: añade la lente de casos límite. `low`: añade la lente de casos límite, y el código necesita dos revisores que no sean quien lo construyó.
+
+Si un solo campo fijara ambas cosas, la única forma de obtener un documento delgado sería registrar en el registro de riesgos más riesgo del que realmente acepta.
+
+---
+
+### Opción B: Operaciones Diarias Autónomas (Daily Tier)
+Una vez establecida la arquitectura, el trabajo diario se ejecuta como un ritmo diario mediante cuatro skills que usted escribe dentro de su agente:
+
+1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
+   Convierte notas de pruebas manuales, observaciones de QA o informes de errores en una especificación o un ticket revisado en la rama de desarrollo, para una ejecución posterior del autopilot. Se detiene ahí: nunca hace commit ni push, ni inicia el autopilot.
+2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
+   Comprueba si hay un mandato aceptado y ejecuta el preflight si no lo hay, resuelve los revisores desde la configuración local e inicia el bucle (por defecto `/loop 10m /wdi-autopilot`). El bucle trabaja en la rama `autopilot/<mandate-id>`, escribe el código con pruebas primero, registra cada decisión en su libro de registro y termina con un PR listo para revisión. El propietario lo fusiona.
+3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
+   Después de una fusión: sincroniza la rama de desarrollo, elimina las ramas y los worktrees fusionados, prepara la aplicación para pruebas manuales y construye una lista de verificación a partir de los tickets cerrados desde la última sincronización (`before_sync..HEAD`). Sin argumento, solo sincroniza, elimina y construye la lista de verificación.
+4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
+   Mueve las especificaciones cerradas de `.scratch/` a `.archive/specs/`, o las elimina con `git rm`, mediante `lifecycle.py`, que verifica primero y revierte si algo falla. La fila de la especificación permanece en `specs.yaml`. Sin argumento, pregunta.
+
+---
+
+### Opción C: Vía Rápida (`/implement` Directamente)
+Una corrección puede omitir todas las compuertas cuando no cambia ningún FR, UC, AD-N ni el modelo de dominio, ocupa como máximo un ticket y no toca dinero, datos personales ni integraciones con terceros. Usted ejecuta `/implement` directamente, sin skill envolvente. Si la corrección resulta tocar un FR, el trabajo se detiene y se convierte en una especificación de tamaño S (como máximo 3 tickets), que se ejecuta mediante `wdi-build`.
+
+---
+
+## Reglas de Campo
+
+Reglas operativas aprendidas al ejecutar bucles de codificación autónomos en repositorios de productos reales:
+
+### 1. Constructor Fijado al Coordinador (`builder: coordinator`)
+En `wdi-daily-autopilot`, `roles.builder` en `.control/custom-dispatch.yaml` está fijado a `coordinator`. Delegar el código a subagentes produjo informes de finalización falsos (un subagente que afirmaba que las pruebas pasaban sin haber editado ningún archivo). La sesión coordinadora escribe el código ella misma, con pruebas primero.
+
+### 2. Revisores de Solo Lectura
+Los revisores pares se ejecutan en modo de solo lectura. Cuestionan los casos límite y leen los diffs, pero nunca cambian el código ni ejecutan builds; solo escribe la sesión coordinadora. Con `risk_accepted: low` se rechaza omitir la revisión par, porque ahí el código necesita dos revisores que no sean quien lo construyó.
+
+### 3. Bloqueos de Archivos en Windows (Desktop Process Gate)
+En Windows, un binario de la aplicación en ejecución o un daemon de build en segundo plano mantiene abiertos identificadores de archivo, y entonces una recompilación o la eliminación de un worktree falla con `Access is denied`. Con el objetivo `desktop`, `wdi-daily-what-to-test` comprueba si el binario de la aplicación sigue en ejecución antes de recompilar. Solo cierra la aplicación si la inició su propia ejecución de smoke anterior; si no, informa el PID y se detiene, para que usted la cierre. Nunca fuerza la terminación de un proceso.
+
+### 4. El Bucle se Ejecuta en su Propia Rama
+La redacción de especificaciones y tickets ocurre en la rama de desarrollo. El bucle se ejecuta en su propia rama, `autopilot/<mandate-id>`, en un worktree aislado o en un checkout limpio que solo usa esa ejecución. Nunca se ejecuta en un checkout compartido o con cambios pendientes.
+
+### 5. Una Ejecución de Cloud CI por Ejecución del Autopilot
+El bucle hace un commit por ticket, y la suite de pruebas local es la evidencia durante la ejecución. Cloud CI se ejecuta una vez por ejecución del autopilot, al final: cuando el único PR se marca como listo para revisión, o cuando el workflow se despacha una vez. Los push durante la ejecución no inician ninguna ejecución en la nube.
+
+### 6. Archivos de Smoke Locales de la Máquina
+Los cursores de smoke (`.work/smoke/last-sync`) y los manifiestos de runtime pertenecen a una sola máquina. El instalador añade `.work/smoke/` a `.gitignore`, de modo que los archivos de smoke locales nunca dejan el árbol de trabajo con cambios pendientes.
+
+---
+
+## Configuración (`custom-dispatch.yaml`)
+
+Los comandos de runner y los flags de modelo específicos de cada máquina viven en `.control/custom-dispatch.yaml`. El instalador lo crea a partir de `.control/custom-dispatch.yaml.example` cuando falta y lo añade a `.gitignore`; solo se hace commit del ejemplo.
+
+Un runner nombrado como revisor DEBE ser de solo lectura. El flag de solo lectura por CLI: `claude --permission-mode plan`, `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. Todos los runners de ejemplo de la plantilla lo usan.
+
+---
+
+## Directorio de Skills (22)
+
+WDI Method instala 22 skills: 7 skills de compuerta, 5 del daily tier (incluida `wdi-autopilot`) y 10 que usted ejecuta en cualquier momento.
+
+Cómo se inicia una skill:
+- **Usted la escribe**: las cuatro skills del daily tier, `wdi-build` y `wdi-explain-to-me` (llevan `disable-model-invocation: true`).
+- **Usted la escribe, o el agente la nombra y espera su aprobación**: las demás skills.
+- **El agente puede ejecutarla por sí mismo (solo lectura)**: `wdi-help`.
+- **Disparada por `/loop` bajo un mandato aceptado**: `wdi-autopilot`. Bajo un mandato, `wdi-autopilot` también ejecuta las demás skills.
+
+| Skill | Qué hace | Cómo se inicia |
+|---|---|---|
+| **Skills de compuerta** | | |
+| `/wdi-init` | Antes de G1 y al final de G2: configura los registros, los componentes, `mode` y `risk_accepted`, los dos mapas de estructura, la verificación de motores y los lectores de inventario. | Usted la escribe, o el agente la nombra |
+| `/wdi-problem` | G1. Ejecuta la skill de product brief de BMad y después verifica el brief contra la guía del método. Nunca escribe el brief ella misma. | Usted la escribe, o el agente la nombra |
+| `/wdi-product` | G2. Ejecuta la skill de PRD de BMad para un PRD nuevo o una promesa modificada y después lo verifica contra la guía del PRD. Nunca escribe el PRD ella misma. | Usted la escribe, o el agente la nombra |
+| `/wdi-ux` | Opcional, junto con G2. Ejecuta la skill de UX de BMad y archiva los resultados de diseño donde corresponden. Nunca escribe contenido de UX ella misma. | Usted la escribe, o el agente la nombra |
+| `/wdi-blueprint` | G3, una vez por producto. La imagen completa del producto: casos de uso, actores, modelo de dominio, reglas de negocio, glosario, la espina dorsal de la arquitectura, C4 y los inventarios de API, tablas y pantallas. | Usted la escribe, o el agente la nombra |
+| `/wdi-component` | G4. La profundidad de un componente, tan profunda como su `mode` y no más. Se omite con `mode: catalog`. | Usted la escribe, o el agente la nombra |
+| `/wdi-build` | G5. Una especificación de abierta a cerrada: usted ejecuta `to-spec` y `to-tickets`, cada ticket llega a un PR en verde y después la especificación se cierra. Nunca fusiona. | Usted la escribe |
+| **Daily tier** | | |
+| `/wdi-daily-what-to-build` | Convierte notas de pruebas manuales en una especificación o un ticket revisado para una ejecución posterior del autopilot. Se detiene antes del código, el commit o el push. | Usted la escribe |
+| `/wdi-daily-autopilot` | Comprueba si hay un mandato aceptado (ejecuta el preflight si no lo hay), resuelve los revisores desde la configuración local e inicia el bucle, cada 10 minutos por defecto. | Usted la escribe |
+| `/wdi-autopilot` | El bucle en sí: recorre cada FR bajo un mandato aceptado, en una rama con un PR, y escribe cada decisión en un libro de registro. | Disparada por `/loop` bajo un mandato aceptado |
+| `/wdi-daily-what-to-test` | Después de una fusión: sincroniza la rama de desarrollo, elimina las ramas y los worktrees fusionados, prepara la aplicación para pruebas manuales y construye una lista de verificación a partir de los tickets cerrados. | Usted la escribe |
+| `/wdi-prune-or-archive` | Mueve las especificaciones cerradas a `.archive/specs/` o las elimina con `git rm`, mediante `lifecycle.py`, que verifica primero y revierte si algo falla. La fila de la especificación permanece en `specs.yaml`. | Usted la escribe |
+| **En cualquier momento** | | |
+| `/wdi-help` | Lee el registro de estado y le indica la compuerta actual, las especificaciones abiertas y la siguiente skill. | El agente puede ejecutarla por sí mismo (solo lectura) |
+| `/wdi-explain-to-me` | Hace la lectura antes de que usted decida: investiga y después le informa en seis secciones fijas. No escribe ningún archivo. | Usted la escribe |
+| `/wdi-decision` | Abre, acepta y aplica una decisión numerada (`DEC-`), y la lleva a los documentos que gobierna. | Usted la escribe, o el agente la nombra |
+| `/wdi-question` | Archiva algo que no se puede decidir ahora en una de cuatro listas en `.control/questions/`, y lo cierra cuando llega la respuesta. | Usted la escribe, o el agente la nombra |
+| `/wdi-log` | Registra una reunión terminada o un hecho no técnico que limita lo que se puede construir. | Usted la escribe, o el agente la nombra |
+| `/wdi-report` | Cifras sobre el proyecto: progreso, estimaciones, filas de tareas para un tracker, o un brief o PRD independiente. Nunca inventa una cifra. | Usted la escribe, o el agente la nombra |
+| `/wdi-reconcile` | Antes de una compuerta o después de un lote de cambios: informa de la desviación entre `.what`, `.how`, `.control` y las reglas del método. Solo lectura. | Usted la escribe, o el agente la nombra |
+| `/wdi-review` | Revisa cualquier documento del corpus, y debe ejecutarse antes de una compuerta para la espina dorsal, el SRS, el SDD y el SPEC. Sus lentes siguen `risk_accepted`. No sirve para revisar código. | Usted la escribe, o el agente la nombra |
+| `/wdi-systematic-debugging` | Para cualquier error, prueba fallida o build fallido, antes de proponer una corrección: encontrar la causa raíz y probar una hipótesis cada vez. | Usted la escribe, o el agente la nombra |
+| `/wdi-upgrade` | Justo después de `wdi-method update`: mueve los documentos y los archivos de registro que siguen en la forma antigua a la nueva, y después comprueba que la validación esté en verde. | Usted la escribe, o el agente la nombra |
+
+---
+
+## Estructura del Repositorio
+
+```text
+.constitution/
+  method/                  The method itself: overwritten by every update; never edit here
+  project/                 Product-owned rules and inventory readers: kept across updates
+.control/
+  registry/                The registries: index.yaml · goals.yaml · specs.yaml · components.yaml
+  generated/               Status and RTM projections written by validate.py (never by hand)
+  decisions/               Decisions and owner mandates (DEC-*.md)
+  memlog/                  Ledgers recording autonomous loop decisions
+  test-targets/            Hand-testing templates (desktop.md, web.md, mobile.md)
+.scratch/<spec-id>-<slug>/ Active spec workspaces (SPEC.md and tickets)
+.archive/                  Archived closed specs
+.what/ & .how/             Working corpus documents (brief, PRD, SRS, blueprint, SDD)
+.what-rendered/            Rendered pages for G1 and G2 (generated)
+.how-rendered/             Rendered pages for G3 and G4 (generated)
+.work/                     Scratch that empties when a task closes
+```
+
+---
+
+## Contribución
+
+Toda contribución a WDI Method responde a una pregunta: **¿hace esto que la capa de revisión sea más confiable, o solo la hace más gruesa?** Consulte [CONTRIBUTING.md](CONTRIBUTING.md).
+
+### Fixture Corpus y Verificación Local
+Los cambios en los validadores y en el método se demuestran contra el fixture corpus (`tests/fixture/`). Ejecute la suite antes de abrir un pull request:
+```bash
+npm test
+```
+La suite ejecuta los cuatro scripts Python PEP 723 (`validate.py`, `timeline.py`, `inventory.py`, `lifecycle.py`) contra el fixture, y verifica el registro de plataformas y los archivos que recibe cada plataforma, así como la integridad del kit.
+
+### Regla de Paquete Genérico Público
+WDI Method se publica en el registro público de npm. Nunca debe incluir nombres de clientes privados, identidades de productos comerciales, credenciales ni rutas absolutas del sistema de archivos.
+
+---
+
+## Licencia y Privacidad
+
+- **Licencia del código:** [Licencia MIT](LICENSE).
+- **Privacidad:** WDI Method por sí mismo no hace llamadas de red; su agente de codificación sigue comunicándose con su proveedor de modelos. Consulte [PRIVACY.md](PRIVACY.md) y [SECURITY.md](SECURITY.md).
+
+## The name and the icon
+
+El texto en inglés que sigue es el que se aplica.
+
+The MIT License grants broad rights over the code. It says nothing about names or logos,
+and it does not oblige the studio to hand over either — so the licence above covers this
+repository's code, not the name **WDI Method**, not **Wira Delta Indonesia**, and not any
+associated visual marks or logos.
+
+You may use those names to refer to this project: "based on WDI Method", "a fork of WDI Method",
+or "compatible with WDI Method". You may not use them as the name of your own product or
+methodology, or in a way that suggests you are this project or endorsed by it.
+
+If you publish a modified distribution or fork, please give it your own name, so the
+engineers using it know whom to ask when something behaves unexpectedly. The code is yours
+to take; the name is not.
+
+---
+
+Usamos el mismo método en proyectos de clientes. [Contacte con Wira Delta Indonesia](https://wiradelta.id/#contact).