wdi-method 0.6.29 → 0.6.30

package/README.fr.md

@@ -1,263 +0,0 @@
-# WDI Method
-
-> Une couche de révision au-dessus de BMad : des documents qu'un humain lit pour vérifier les décisions techniques avant l'écriture du code, dimensionnés selon ce que le changement mérite réellement.
-
-[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.com/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
-
----
-
-> **Avis de traduction :** Ce fichier est une traduction de [README.md](README.md) fournie uniquement à titre indicatif. En cas de divergence ou de conflit d'interprétation, la version officielle en langue anglaise (`README.md`) prévaut. L'ensemble de la documentation technique approfondie et des documents juridiques est maintenu en anglais.
-
-[BMad](https://github.com/bmad-code-org/BMAD-METHOD) écrit des documents pour les agents IA. WDI Method ajoute des documents que de nombreux rôles lisent déjà : cas d'utilisation, diagrammes C4, listes d'API et de base de données, et documents de conception. Il englobe BMad sans le remplacer : les compétences du brief, du PRD, de l'UX et de l'architecture (`wdi-problem`, `wdi-product`, `wdi-ux` et `wdi-blueprint` pour la colonne vertébrale) confient la rédaction à une compétence BMad, puis vérifient le résultat par rapport aux guides de la méthode.
-
-> Ce dépôt est **public et générique**. Il NE DOIT contenir aucun nom de client, aucun nom de produit commercial ni aucun lien vers un dépôt privé. L'identité du produit réside entièrement dans le dépôt qui l'installe.
-
----
-
-## Développement Piloté par l'IA (AiDD) vs. Vibe Coding
-
-Le vibe coding utilise lui aussi des spécifications, mais pas de manière cohérente : chaque session de prompts peut différer, les documents ne sont pas structurés et le processus n'est pas tenu de façon systématique. Le résultat est une efficience et une efficacité bien moindres, et un risque réel d'accumuler de la dette technique. C'est pourquoi un framework est nécessaire.
-
-Dans WDI Method, le Développement Piloté par l'IA (AiDD) suit un ordre : des promesses enregistrées comme FR et cas d'utilisation, puis les gates, puis la spécification découpée en tickets avec `to-spec` et `to-tickets`, puis chaque ticket construit en commençant par les tests, puis une PR que le propriétaire révise et fusionne.
-
-Trois couches font le travail :
-
-| Couche | Qui | Ce qu'elle fait |
-|---|---|---|
-| 1. Documents pour les agents | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | Rédige le product brief, le PRD, l'UX et la colonne vertébrale de l'architecture, chacun via une compétence BMad |
-| 2. Couche de révision | WDI Method | Englobe ces compétences, ajoute les documents que lisent les autres rôles, exécute cinq gates humains, relie Objectif → FR → UC → Ticket → Test et vérifie la dérive du corpus |
-| 3. Tickets et code | Moteurs ([mattpocock/skills](https://github.com/mattpocock/skills)) | `to-spec` et `to-tickets` découpent la spécification en tickets verticaux ; `implement` construit chacun en commençant par les tests |
-
-### Les Documents Suivent le Code (Documents Follow Code)
-
-Un document en retard sur le code est dans son état attendu, ce n'est pas un défaut. Lorsque le propriétaire a choisi le code plutôt qu'un document, c'est le document qui est corrigé. Un document en avance sur le code, comme une spécification pas encore construite, est également normal.
-
----
-
-## Installation en 3 Étapes
-
-### Prérequis
-
-- Node.js 20 ou ultérieur.
-- Git.
-- [uv](https://docs.astral.sh/uv/), qui exécute les validateurs Python 3.11+ de la méthode.
-- Une plateforme d'agents : Claude Code, Cursor, Codex et d'autres plateformes d'agents.
-
-Exécutez les trois étapes dans l'ordre. L'installateur s'arrête si l'étape 1 ou l'étape 2 n'a pas été faite. Toutes les invites proposent des valeurs par défaut ; appuyez sur <kbd>Enter</kbd> pour les accepter.
-
-### Étape 1 : Installer BMad Method
-```bash
-cd /path/to/your/product-repo
-npx bmad-method install
-```
-
-### Étape 2 : Ajouter les Six Moteurs
-Installez les moteurs dans votre dépôt (choisissez "copy" ou "symlink") :
-```bash
-npx skills@latest add mattpocock/skills
-```
-*Sélectionnez les six moteurs que pilote la méthode :* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review` et `domain-modeling`.
-
-> **Pourquoi le plugin Claude Code ne suffit pas :** Trois des six moteurs (`to-spec`, `to-tickets`, `implement`) sont livrés avec `disable-model-invocation: true`. À chaque installation et mise à jour, WDI Method retire cette ligne des copies présentes dans votre dépôt, afin que `wdi-build` et `wdi-autopilot` puissent les exécuter. Il ne peut pas modifier un plugin au niveau utilisateur, donc l'installateur s'arrête tant que les moteurs ne sont pas dans le dépôt. `--skip-engines-check` ignore cette vérification.
-
-### Étape 3 : Installer WDI Method
-Lance l'installateur interactif et place les compétences là où chacune de vos plateformes d'agents les lit :
-```bash
-npx wdi-method
-```
-*(Non interactif : `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
-
-> **Ce que l'installateur modifie dans BMad :** L'installateur désactive aussi l'invocation par le modèle pour 13 compétences BMad de build et de sprint que les moteurs remplacent, et ajoute les règles de refus correspondantes à `.claude/settings.json`. Vous pouvez toujours les exécuter en tapant la commande.
-
-### Votre Première Commande : `/wdi-help`
-Dans votre agent de codage, exécutez :
-```text
-/wdi-help
-```
-`wdi-help` lit `.control/registry/` et vous indique le gate où se trouve votre projet, les spécifications ouvertes et la compétence suivante, sans deviner à partir de la conversation.
-
----
-
-## Trois Options de Flux de Travail
-
-WDI Method dimensionne son cérémonial selon l'ampleur et le risque de la tâche.
-
-### Option A : Parcours de Livraison Guidé (G1 à G5)
-Pour les nouveaux produits, les initiatives majeures et les changements d'architecture. Vous lancez la compétence de chaque gate ; l'agent nomme la suivante et attend.
-
-**Une Décision par Gate.** Chaque gate décide une chose. De G1 à G4, vous lisez une page générée ; à G5, vous lisez les lignes RTM de la spécification. Vous répondez à une courte liste de contrôle, et un seul « non » à une question étoilée bloque le gate.
-
-| Gate | Décide | Compétence | Ce que vous lisez | Décision du propriétaire |
-|---|---|---|---|---|
-| **G1 Problem** | Quel est le problème, à qui il appartient et pourquoi il mérite du travail | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | Approuver la formulation du problème |
-| **G2 Product** | Ce qui est construit, et l'impression qu'il donne à l'usage | `/wdi-product`<br>`/wdi-ux` (optionnel) | `.what-rendered/_prd/<slug>/prd.md` | Approuver les promesses fonctionnelles (FR) |
-| **G3 Blueprint** | La vue d'ensemble du produit, une fois par produit | `/wdi-blueprint` | `.how-rendered/blueprint.md` | Approuver la colonne vertébrale de l'architecture |
-| **G4 Component** | Comment un composant est construit (ignoré avec `mode: catalog`) | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | Approuver la conception logicielle |
-| **G5 Release** | S'il est terminé et prouvé | `/wdi-build` | Les lignes RTM de la spécification dans `.control/generated/` et les preuves de test de chaque ticket | Accepter la spécification comme terminée, ou la renvoyer |
-
-**Affiner, Ne Pas Avancer.** Un seul « non » à une question étoilée (★) de la liste de contrôle bloque le gate. Affinez le document et relancez le gate ; ne l'approuvez pas avec l'idée de corriger plus tard.
-
-#### Deux Champs qui Ne Fusionnent Jamais
-- **`mode`** fixe la profondeur des documents de chaque composant. `catalog` (par défaut) : rien au-delà du blueprint, et G4 est ignoré. `outline` : flux complets pour jusqu'à 3 cas d'utilisation, règles métier locales, un résumé des décisions. `guarded` : ajoute une section `Failure Behaviour` pour chaque frontière et des documents d'intégration tierce. `deep` : ajoute une analyse de robustesse, un contrat par endpoint, un dictionnaire de données, des diagrammes de flux et des machines à états.
-- **`risk_accepted`** fixe la sévérité de la révision. `high` (vous acceptez beaucoup de risque) : les lentilles de base de structure et de rédaction. `medium` : ajoute la lentille des cas limites. `low` : ajoute la lentille des cas limites, et le code a besoin de deux relecteurs qui ne sont pas le constructeur.
-
-Si un seul champ fixait les deux, la seule façon d'obtenir un document mince serait d'inscrire dans le registre des risques plus de risque que vous n'en acceptez réellement.
-
----
-
-### Option B : Opérations Quotidiennes Autonomes (Daily Tier)
-Une fois l'architecture en place, le travail quotidien suit un rythme journalier à travers quatre compétences que vous tapez dans votre agent :
-
-1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
-   Transforme des notes de tests manuels, des observations QA ou des rapports de bugs en une spécification ou un ticket révisé sur la branche de développement, pour une exécution ultérieure de l'autopilot. Il s'arrête là : il ne fait jamais de commit ni de push et ne lance jamais l'autopilot.
-2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
-   Vérifie l'existence d'un mandat accepté et exécute le preflight s'il n'y en a pas, détermine les relecteurs à partir de la configuration locale et lance la boucle (par défaut `/loop 10m /wdi-autopilot`). La boucle travaille sur la branche `autopilot/<mandate-id>`, écrit le code en commençant par les tests, consigne chaque décision dans son registre et se termine par une PR prête pour la révision. Le propriétaire fusionne.
-3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
-   Après une fusion : synchronise la branche de développement, supprime les branches et worktrees fusionnés, prépare l'application pour les tests manuels et construit une liste de contrôle à partir des tickets fermés depuis la dernière synchronisation (`before_sync..HEAD`). Sans argument, il se contente de synchroniser, de supprimer et de construire la liste de contrôle.
-4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
-   Déplace les spécifications fermées de `.scratch/` vers `.archive/specs/`, ou les supprime avec `git rm`, via `lifecycle.py`, qui vérifie d'abord et annule en cas d'échec. La ligne de la spécification reste dans `specs.yaml`. Sans argument, il pose la question.
-
----
-
-### Option C : Voie Rapide (`/implement` Directement)
-Un correctif peut ignorer tous les gates lorsqu'il ne modifie aucun FR, UC, AD-N ni le modèle de domaine, tient en un ticket au plus et ne touche ni à l'argent, ni aux données personnelles, ni à une intégration tierce. Vous exécutez `/implement` directement, sans compétence d'encapsulation. Si le correctif s'avère toucher un FR, le travail s'arrête et devient une spécification de taille S (3 tickets au plus), qui passe par `wdi-build`.
-
----
-
-## Règles de Terrain
-
-Règles opérationnelles tirées de l'exécution de boucles de codage autonomes sur de vrais dépôts de produits :
-
-### 1. Constructeur Fixé au Coordinateur (`builder: coordinator`)
-Dans `wdi-daily-autopilot`, `roles.builder` dans `.control/custom-dispatch.yaml` est fixé à `coordinator`. Déléguer le code à des sous-agents a produit de faux rapports d'achèvement (un sous-agent affirmant que les tests passaient sans avoir modifié le moindre fichier). La session coordinatrice écrit elle-même le code, en commençant par les tests.
-
-### 2. Relecteurs en Lecture Seule
-Les relecteurs pairs s'exécutent en lecture seule. Ils remettent en question les cas limites et lisent les diffs, mais ne modifient jamais le code et ne lancent jamais de build ; seule la session coordinatrice écrit. Avec `risk_accepted: low`, le contournement de la revue par les pairs est refusé, car le code y a besoin de deux relecteurs qui ne sont pas le constructeur.
-
-### 3. Verrous de Fichiers sous Windows (Desktop Process Gate)
-Sous Windows, un binaire d'application en cours d'exécution ou un démon de build en arrière-plan garde des descripteurs de fichiers ouverts, et une recompilation ou la suppression d'un worktree échoue alors avec `Access is denied`. Avec la cible `desktop`, `wdi-daily-what-to-test` vérifie si le binaire de l'application tourne encore avant de recompiler. Il ne ferme l'application que si sa propre exécution smoke précédente l'a lancée ; sinon, il signale le PID et s'arrête, pour que vous puissiez la fermer vous-même. Il ne force jamais l'arrêt d'un processus.
-
-### 4. La Boucle Tourne sur sa Propre Branche
-La rédaction des spécifications et des tickets se fait sur la branche de développement. La boucle tourne sur sa propre branche, `autopilot/<mandate-id>`, dans un worktree isolé ou dans un checkout propre utilisé uniquement par cette exécution. Elle ne tourne jamais sur un checkout partagé ou contenant des modifications non validées.
-
-### 5. Une Exécution de Cloud CI par Exécution de l'Autopilot
-La boucle fait un commit par ticket, et la suite de tests locale constitue la preuve pendant l'exécution. Cloud CI s'exécute une fois par exécution de l'autopilot, à la fin : lorsque l'unique PR est marquée prête pour la révision, ou lorsque le workflow est déclenché une fois. Les push pendant l'exécution ne lancent aucune exécution dans le cloud.
-
-### 6. Fichiers Smoke Locaux à la Machine
-Les curseurs smoke (`.work/smoke/last-sync`) et les manifestes d'exécution appartiennent à une seule machine. L'installateur ajoute `.work/smoke/` à `.gitignore`, de sorte que les fichiers smoke locaux ne laissent jamais l'arbre de travail avec des modifications non validées.
-
----
-
-## Configuration (`custom-dispatch.yaml`)
-
-Les commandes de runner et les flags de modèle propres à chaque machine se trouvent dans `.control/custom-dispatch.yaml`. L'installateur le crée à partir de `.control/custom-dispatch.yaml.example` lorsqu'il est absent, et l'ajoute à `.gitignore` ; seul l'exemple est commité.
-
-Un runner désigné comme relecteur DOIT être en lecture seule. Le flag de lecture seule par CLI : `claude --permission-mode plan`, `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. Les runners d'exemple du modèle l'utilisent tous.
-
----
-
-## Répertoire des Compétences (22)
-
-WDI Method installe 22 compétences : 7 compétences de gate, 5 pour le daily tier (dont `wdi-autopilot`) et 10 que vous exécutez à tout moment.
-
-Comment une compétence démarre :
-- **Vous la tapez** : les quatre compétences du daily tier et `wdi-explain-to-me` (elles portent `disable-model-invocation: true`).
-- **Vous la tapez, ou `wdi-autopilot` l'exécute sous un mandat accepté** : `wdi-build`. Elle ne porte pas le flag `disable-model-invocation`, car `wdi-autopilot` doit l'invoquer ; la règle selon laquelle les agents ne la lancent pas d'eux-mêmes figure dans la Method policy que l'installateur écrit dans `CLAUDE.md` et `AGENTS.md`.
-- **Vous la tapez, ou l'agent la nomme et attend votre feu vert** : les autres compétences.
-- **L'agent peut l'exécuter de lui-même (lecture seule)** : `wdi-help`.
-- **Déclenchée par `/loop` sous un mandat accepté** : `wdi-autopilot`. Sous un mandat, `wdi-autopilot` exécute aussi les autres compétences.
-
-| Compétence | Ce qu'elle fait | Comment elle démarre |
-|---|---|---|
-| **Compétences de gate** | | |
-| `/wdi-init` | Avant G1 et à la fin de G2 : met en place les registres, les composants, `mode` et `risk_accepted`, les deux cartes de structure, la vérification des moteurs et les lecteurs d'inventaire. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-problem` | G1. Exécute la compétence de product brief de BMad, puis vérifie le brief par rapport au guide de la méthode. N'écrit jamais le brief elle-même. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-product` | G2. Exécute la compétence PRD de BMad pour un nouveau PRD ou une promesse modifiée, puis le vérifie par rapport au guide du PRD. N'écrit jamais le PRD elle-même. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-ux` | Optionnelle, avec G2. Exécute la compétence UX de BMad et range les résultats de conception là où ils doivent aller. N'écrit jamais de contenu UX elle-même. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-blueprint` | G3, une fois par produit. La vue d'ensemble du produit : cas d'utilisation, acteurs, modèle de domaine, règles métier, glossaire, la colonne vertébrale de l'architecture, C4, et les inventaires d'API, de tables et d'écrans. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-component` | G4. La profondeur d'un composant, aussi profonde que son `mode` et pas davantage. Ignorée avec `mode: catalog`. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-build` | G5. Une spécification de l'ouverture à la clôture : vous exécutez `to-spec` et `to-tickets`, chaque ticket aboutit à une PR au vert, puis la spécification est clôturée. Elle ne fusionne jamais. | Vous la tapez, ou `wdi-autopilot` l'exécute |
-| **Daily tier** | | |
-| `/wdi-daily-what-to-build` | Transforme des notes de tests manuels en une spécification ou un ticket révisé pour une exécution ultérieure de l'autopilot. S'arrête avant le code, le commit ou le push. | Vous la tapez |
-| `/wdi-daily-autopilot` | Vérifie l'existence d'un mandat accepté (exécute le preflight s'il n'y en a pas), détermine les relecteurs à partir de la configuration locale et lance la boucle, toutes les 10 minutes par défaut. | Vous la tapez |
-| `/wdi-autopilot` | La boucle elle-même : traite chaque FR sous un mandat accepté, sur une branche avec une PR, et consigne chaque décision dans un registre. | Déclenchée par `/loop` sous un mandat accepté |
-| `/wdi-daily-what-to-test` | Après une fusion : synchronise la branche de développement, supprime les branches et worktrees fusionnés, prépare l'application pour les tests manuels et construit une liste de contrôle à partir des tickets fermés. | Vous la tapez |
-| `/wdi-prune-or-archive` | Déplace les spécifications fermées vers `.archive/specs/` ou les supprime avec `git rm`, via `lifecycle.py`, qui vérifie d'abord et annule en cas d'échec. La ligne de la spécification reste dans `specs.yaml`. | Vous la tapez |
-| **À tout moment** | | |
-| `/wdi-help` | Lit le registre d'état et vous indique le gate actuel, les spécifications ouvertes et la compétence suivante. | L'agent peut l'exécuter de lui-même (lecture seule) |
-| `/wdi-explain-to-me` | Fait la lecture avant que vous ne décidiez : enquête, puis vous informe en six sections fixes. N'écrit aucun fichier. | Vous la tapez |
-| `/wdi-decision` | Ouvre, accepte et applique une décision numérotée (`DEC-`), et la reporte dans les documents qu'elle régit. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-question` | Classe ce qui ne peut pas être décidé maintenant dans l'une des quatre listes de `.control/questions/`, et le clôt lorsque la réponse arrive. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-log` | Consigne une réunion terminée ou un fait non technique qui limite ce qui peut être construit. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-report` | Des chiffres sur le projet : avancement, estimations, lignes de tâches pour un tracker, ou un brief ou un PRD autonome. N'invente jamais un chiffre. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-reconcile` | Avant un gate ou après une série de changements : signale la dérive entre `.what`, `.how`, `.control` et les règles de la méthode. Lecture seule. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-review` | Révise n'importe quel document du corpus, et doit s'exécuter avant un gate pour la colonne vertébrale, le SRS, le SDD et le SPEC. Ses lentilles suivent `risk_accepted`. Pas pour la revue de code. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-systematic-debugging` | Pour tout bug, test en échec ou build échoué, avant de proposer un correctif : trouver la cause racine et tester une hypothèse à la fois. | Vous la tapez, ou l'agent la nomme |
-| `/wdi-upgrade` | Juste après `wdi-method update` : fait passer les documents et fichiers de registre encore dans l'ancienne forme à la nouvelle, puis vérifie que la validation est au vert. | Vous la tapez, ou l'agent la nomme |
-
----
-
-## Structure du Dépôt
-
-```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
-```
-
----
-
-## Contribution
-
-Chaque contribution à WDI Method répond à une question : **cela rend-il la couche de révision plus digne de confiance, ou seulement plus épaisse ?** Voir [CONTRIBUTING.md](CONTRIBUTING.md).
-
-### Fixture Corpus et Vérification Locale
-Les modifications des validateurs et de la méthode sont démontrées sur le fixture corpus (`tests/fixture/`). Exécutez la suite avant d'ouvrir une pull request :
-```bash
-npm test
-```
-La suite exécute les quatre scripts Python PEP 723 (`validate.py`, `timeline.py`, `inventory.py`, `lifecycle.py`) sur le fixture, et vérifie le registre des plateformes, les fichiers que reçoit chaque plateforme, ainsi que l'intégrité du kit.
-
-### Règle du Paquet Générique Public
-WDI Method est publié sur le registre npm public. Il ne doit jamais contenir de noms de clients privés, d'identités de produits commerciaux, d'identifiants ni de chemins absolus du système de fichiers.
-
----
-
-## Licence et Confidentialité
-
-- **Licence du code :** [Licence MIT](LICENSE).
-- **Confidentialité :** WDI Method lui-même n'effectue aucun appel réseau ; votre agent de codage communique toujours avec son fournisseur de modèle. Voir [PRIVACY.md](PRIVACY.md) et [SECURITY.md](SECURITY.md).
-
-## The name and the icon
-
-C'est le texte anglais ci-dessous qui s'applique.
-
-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.
-
----
-
-Nous utilisons la même méthode sur les projets de nos clients. [Contacter Wira Delta Indonesia](https://wiradelta.com/studio/#contact).

package/README.id.md

@@ -1,263 +0,0 @@
-# WDI Method
-
-> Lapisan review di atas BMad: dokumen yang dibaca manusia untuk memeriksa keputusan teknis sebelum kode ditulis, disesuaikan dengan apa yang benar-benar dibutuhkan perubahan itu.
-
-[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.com/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
-
----
-
-> **Pemberitahuan terjemahan:** Berkas ini merupakan terjemahan dari [README.md](README.md) untuk kenyamanan pembaca. Jika terdapat perbedaan makna atau penafsiran, berkas resmi berbahasa Inggris (`README.md`) yang menjadi acuan otoritatif. Seluruh dokumen teknis mendalam dan dokumen hukum dikelola dalam Bahasa Inggris.
-
-[BMad](https://github.com/bmad-code-org/BMAD-METHOD) menulis dokumen untuk AI agent. WDI Method menambahkan dokumen yang sudah biasa dibaca banyak peran: use case, diagram C4, daftar API dan database, dan dokumen desain. WDI Method membungkus BMad tanpa menggantikannya: skill untuk brief, PRD, UX, dan arsitektur (`wdi-problem`, `wdi-product`, `wdi-ux`, dan `wdi-blueprint` untuk architecture spine) menyerahkan penulisan ke skill BMad, lalu memeriksa hasilnya terhadap panduan metode.
-
-> Repositori ini bersifat **publik dan generik**. Repositori ini **TIDAK BOLEH** memuat nama klien, nama produk komersial, atau tautan ke repositori privat. Identitas produk sepenuhnya berada di repositori yang memasangnya.
-
----
-
-## AI-Driven Development (AiDD) vs. Vibe Coding
-
-Vibe coding juga memakai spesifikasi, tetapi tidak konsisten: setiap sesi prompt bisa berbeda, dokumennya tidak terstruktur, dan prosesnya tidak dijaga tetap sistematis. Akibatnya efisiensi dan efektivitas jauh lebih rendah, dan ada risiko nyata menumpuk technical debt. Itulah alasan sebuah framework dibutuhkan.
-
-Di WDI Method, AI-Driven Development (AiDD) berjalan dalam satu urutan: janji dicatat sebagai FR dan use case, lalu gerbang, lalu spec dipotong menjadi tiket dengan `to-spec` dan `to-tickets`, lalu setiap tiket dibangun dengan test lebih dulu, lalu satu PR yang di-review dan di-merge pemilik.
-
-Tiga lapisan menjalankan pekerjaannya:
-
-| Lapisan | Siapa | Yang Dikerjakan |
-|---|---|---|
-| 1. Dokumen untuk agent | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | Menulis product brief, PRD, UX, dan architecture spine, masing-masing lewat skill BMad |
-| 2. Lapisan review | WDI Method | Membungkus skill tersebut, menambahkan dokumen yang dibaca peran lain, menjalankan lima gerbang manusia, menghubungkan Goal → FR → UC → Ticket → Test, dan memeriksa drift pada korpus |
-| 3. Tiket dan kode | Engine ([mattpocock/skills](https://github.com/mattpocock/skills)) | `to-spec` dan `to-tickets` memotong spec menjadi tiket vertikal; `implement` membangun setiap tiket dengan test lebih dulu |
-
-### Dokumen Mengikuti Kode
-
-Dokumen yang tertinggal dari kode adalah keadaan wajar, bukan cacat. Bila pemilik memilih kode daripada dokumen, dokumennya yang diperbaiki. Dokumen yang mendahului kode, misalnya spec yang belum dibangun, juga wajar.
-
----
-
-## Pasang dalam 3 Langkah
-
-### Prasyarat
-
-- Node.js 20 atau lebih baru.
-- Git.
-- [uv](https://docs.astral.sh/uv/), untuk menjalankan validator Python 3.11+ milik metode ini.
-- Platform agent: Claude Code, Cursor, Codex, dan platform agent lainnya.
-
-Jalankan ketiga langkah secara berurutan. Installer berhenti bila langkah 1 atau langkah 2 belum dikerjakan. Semua prompt menyediakan jawaban default; tekan <kbd>Enter</kbd> untuk menerimanya.
-
-### Langkah 1: Pasang BMad Method
-```bash
-cd /path/to/your/product-repo
-npx bmad-method install
-```
-
-### Langkah 2: Tambahkan Enam Engine
-Pasang engine ke repositori Anda (pilih "copy" atau "symlink"):
-```bash
-npx skills@latest add mattpocock/skills
-```
-*Pilih keenam engine yang dijalankan metode ini:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review`, dan `domain-modeling`.
-
-> **Mengapa Plugin Claude Code Tidak Cukup:** Tiga dari enam engine (`to-spec`, `to-tickets`, `implement`) dirilis dengan `disable-model-invocation: true`. Setiap install dan update, WDI Method menghapus baris itu dari salinan di repo Anda, supaya `wdi-build` dan `wdi-autopilot` bisa menjalankannya. Plugin tingkat pengguna tidak bisa diubah, jadi installer berhenti sampai engine ada di repo. `--skip-engines-check` melewati pemeriksaan ini.
-
-### Langkah 3: Pasang WDI Method
-Membuka installer interaktif dan menaruh skill di tempat yang dibaca setiap platform agent Anda:
-```bash
-npx wdi-method
-```
-*(Non-interaktif: `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
-
-> **Yang diubah installer di BMad:** Installer juga mematikan pemanggilan oleh model untuk 13 skill build dan sprint BMad yang digantikan engine, dan menambahkan aturan deny yang sama ke `.claude/settings.json`. Anda tetap bisa menjalankannya dengan mengetik perintahnya.
-
-### Perintah Pertama Anda: `/wdi-help`
-Di dalam coding agent Anda, jalankan:
-```text
-/wdi-help
-```
-`wdi-help` membaca `.control/registry/` dan memberi tahu gerbang tempat proyek Anda berada, spec yang terbuka, dan skill berikutnya, tanpa menebak dari percakapan.
-
----
-
-## Tiga Pilihan Alur Kerja
-
-WDI Method menyesuaikan seremoninya dengan skala dan risiko pekerjaan.
-
-### Opsi A: Jalur Delivery Terpandu (G1 sampai G5)
-Untuk produk baru, inisiatif besar, dan perubahan arsitektur. Anda memulai setiap skill gerbang; agent menyebut skill berikutnya dan menunggu.
-
-**Satu Keputusan per Gerbang.** Setiap gerbang memutuskan satu hal. Di G1 sampai G4 Anda membaca satu halaman terender; di G5 Anda membaca baris RTM spec. Anda menjawab daftar periksa singkat, dan satu jawaban "tidak" pada pertanyaan bertanda bintang menahan gerbang.
-
-| Gerbang | Yang Diputuskan | Skill | Yang Anda Baca | Keputusan Pemilik |
-|---|---|---|---|---|
-| **G1 Problem** | Apa masalahnya, milik siapa, dan mengapa layak dikerjakan | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | Setujui rumusan masalah |
-| **G2 Product** | Apa yang dibangun, dan bagaimana rasanya dipakai | `/wdi-product`<br>`/wdi-ux` (opsional) | `.what-rendered/_prd/<slug>/prd.md` | Setujui janji fungsional (FR) |
-| **G3 Blueprint** | Gambaran utuh produk, sekali per produk | `/wdi-blueprint` | `.how-rendered/blueprint.md` | Setujui architecture spine |
-| **G4 Component** | Bagaimana satu komponen dibangun (dilewati pada `mode: catalog`) | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | Setujui desain perangkat lunak |
-| **G5 Release** | Apakah sudah selesai dan terbukti | `/wdi-build` | Baris RTM spec di `.control/generated/` dan bukti test setiap tiket | Terima spec sebagai selesai, atau kembalikan |
-
-**Perbaiki, Jangan Lanjutkan.** Satu jawaban "tidak" pada pertanyaan daftar periksa bertanda bintang (★) menahan gerbang. Perbaiki dokumennya lalu jalankan gerbang lagi; jangan menyetujuinya dengan rencana memperbaikinya nanti.
-
-#### Dua Parameter yang Tidak Boleh Digabung
-- **`mode`** menentukan kedalaman dokumen setiap komponen. `catalog` (default): tidak ada dokumen di luar blueprint, dan G4 dilewati. `outline`: alur lengkap untuk paling banyak 3 use case, aturan bisnis lokal, dan ringkasan keputusan. `guarded`: menambah bagian `Failure Behaviour` untuk setiap batas dan dokumen integrasi pihak ketiga. `deep`: menambah analisis robustness, kontrak per endpoint, kamus data, diagram alur, dan state machine.
-- **`risk_accepted`** menentukan seberapa keras review. `high` (Anda menerima banyak risiko): lensa dasar structure dan prose. `medium`: menambah lensa edge case. `low`: menambah lensa edge case, dan kode butuh dua reviewer yang bukan builder.
-
-Bila satu field mengatur keduanya, satu-satunya cara mendapat dokumen tipis adalah menulis risiko yang lebih besar daripada yang sebenarnya Anda terima.
-
----
-
-### Opsi B: Operasi Harian Otonom (Daily Tier)
-Setelah arsitektur siap, pekerjaan sehari-hari berjalan sebagai ritme harian lewat empat skill yang Anda ketik di dalam agent:
-
-1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
-   Mengubah catatan uji manual, temuan QA, atau laporan bug menjadi spec atau tiket yang sudah ditinjau di development branch, untuk run autopilot berikutnya. Skill ini berhenti di situ: tidak pernah melakukan commit, push, atau memulai autopilot.
-2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
-   Memeriksa mandat yang sudah diterima dan menjalankan preflight bila belum ada, menentukan reviewer dari konfigurasi lokal, lalu memulai loop (default `/loop 10m /wdi-autopilot`). Loop bekerja di branch `autopilot/<mandate-id>`, menulis kode dengan test lebih dulu, mencatat setiap keputusan di ledger-nya, dan berakhir dengan satu PR yang siap di-review. Pemilik yang melakukan merge.
-3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
-   Sesudah merge: menyinkronkan development branch, memangkas branch dan worktree yang sudah di-merge, menyiapkan aplikasi untuk uji manual, dan menyusun checklist dari tiket yang ditutup sejak sinkronisasi terakhir (`before_sync..HEAD`). Tanpa argumen, skill ini hanya menyinkronkan, memangkas, dan menyusun checklist.
-4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
-   Memindahkan spec yang sudah ditutup dari `.scratch/` ke `.archive/specs/`, atau menghapusnya dengan `git rm`, lewat `lifecycle.py` yang memeriksa dulu dan membatalkan perubahan bila gagal. Baris spec tetap di `specs.yaml`. Tanpa argumen, skill ini bertanya.
-
----
-
-### Opsi C: Jalur Cepat (`/implement` Langsung)
-Sebuah perbaikan boleh melewati semua gerbang bila tidak mengubah FR, UC, AD-N, atau domain model, paling banyak satu tiket, dan tidak menyentuh uang, data pribadi, atau integrasi pihak ketiga. Anda menjalankan `/implement` langsung, tanpa skill pembungkus. Bila ternyata menyentuh FR, pekerjaan berhenti dan menjadi spec ukuran S (paling banyak 3 tiket) yang dijalankan lewat `wdi-build`.
-
----
-
-## Aturan Lapangan
-
-Aturan operasional dari menjalankan loop coding otonom di repositori produk nyata:
-
-### 1. Builder Tetap di Koordinator (`builder: coordinator`)
-Di `wdi-daily-autopilot`, `roles.builder` di `.control/custom-dispatch.yaml` ditetapkan ke `coordinator`. Menyerahkan penulisan kode ke subagent menghasilkan laporan selesai yang palsu (subagent mengaku test lulus tanpa mengubah satu file pun). Sesi koordinator menulis kodenya sendiri, dengan test lebih dulu.
-
-### 2. Reviewer Hanya Membaca
-Peer reviewer berjalan dalam mode hanya membaca. Mereka menguji edge case dan membaca diff, tetapi tidak pernah mengubah kode atau menjalankan build; hanya sesi koordinator yang menulis. Pada `risk_accepted: low`, permintaan melewati peer review ditolak, karena kode di sana butuh dua reviewer yang bukan builder.
-
-### 3. File Lock di Windows (Desktop Process Gate)
-Di Windows, binary aplikasi yang sedang berjalan atau daemon build di latar belakang menahan handle file tetap terbuka, sehingga build ulang atau penghapusan worktree gagal dengan `Access is denied`. Dengan target `desktop`, `wdi-daily-what-to-test` memeriksa apakah binary aplikasi masih berjalan sebelum build ulang. Aplikasi hanya ditutup bila dijalankan oleh smoke run sebelumnya; selain itu skill melaporkan PID dan berhenti, supaya Anda menutupnya sendiri. Proses tidak pernah dihentikan paksa.
-
-### 4. Loop Berjalan di Branch Sendiri
-Penulisan spec dan tiket dilakukan di development branch. Loop berjalan di branch-nya sendiri, `autopilot/<mandate-id>`, di worktree terisolasi atau checkout bersih yang hanya dipakai run itu. Loop tidak pernah berjalan di checkout bersama atau yang kotor.
-
-### 5. Satu Cloud CI Run per Run Autopilot
-Loop melakukan commit per tiket, dan rangkaian test lokal menjadi bukti selama run. Cloud CI berjalan sekali per run autopilot, di akhir: saat satu-satunya PR ditandai siap di-review, atau saat workflow dijalankan sekali secara manual. Push selama run tidak memicu cloud run.
-
-### 6. File Smoke Khusus Mesin Lokal
-Kursor smoke (`.work/smoke/last-sync`) dan manifes runtime milik satu mesin. Installer menambahkan `.work/smoke/` ke `.gitignore`, jadi file smoke khusus mesin lokal tidak pernah membuat working tree kotor.
-
----
-
-## Konfigurasi (`custom-dispatch.yaml`)
-
-Perintah runner dan flag model khusus mesin disimpan di `.control/custom-dispatch.yaml`. Installer membuatnya dari `.control/custom-dispatch.yaml.example` bila belum ada, lalu menambahkannya ke `.gitignore`; hanya contohnya yang di-commit.
-
-Runner yang ditunjuk sebagai reviewer WAJIB hanya membaca. Flag hanya membaca per CLI: `claude --permission-mode plan`, `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. Semua contoh runner di templat memakainya.
-
----
-
-## Direktori Skill (22)
-
-WDI Method memasang 22 skill: 7 skill gerbang, 5 untuk daily tier (termasuk `wdi-autopilot`), dan 10 yang bisa Anda jalankan kapan saja.
-
-Cara sebuah skill dimulai:
-- **Anda mengetiknya**: empat skill daily tier dan `wdi-explain-to-me` (membawa `disable-model-invocation: true`).
-- **Anda mengetiknya, atau `wdi-autopilot` menjalankannya di bawah mandat yang diterima**: `wdi-build`. Skill ini tidak membawa flag `disable-model-invocation`, karena `wdi-autopilot` harus bisa memanggilnya; aturan bahwa agent tidak memulainya sendiri ada di Method policy yang ditulis installer ke `CLAUDE.md` dan `AGENTS.md`.
-- **Anda mengetiknya, atau agent menyebutnya dan menunggu izin Anda**: skill lainnya.
-- **Agent boleh menjalankannya sendiri (hanya membaca)**: `wdi-help`.
-- **Dijalankan `/loop` di bawah mandat yang diterima**: `wdi-autopilot`. Di bawah mandat, `wdi-autopilot` juga menjalankan skill lain.
-
-| Skill | Yang Dikerjakan | Cara Mulai |
-|---|---|---|
-| **Skill gerbang** | | |
-| `/wdi-init` | Sebelum G1 dan di akhir G2: menyiapkan registri, komponen, `mode` dan `risk_accepted`, dua peta struktur, pemeriksaan engine, dan pembaca inventaris. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-problem` | G1. Menjalankan skill product brief BMad, lalu memeriksa brief terhadap panduan metode. Tidak pernah menulis brief sendiri. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-product` | G2. Menjalankan skill PRD BMad untuk PRD baru atau janji yang berubah, lalu memeriksanya terhadap panduan PRD. Tidak pernah menulis PRD sendiri. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-ux` | Opsional, bersama G2. Menjalankan skill UX BMad dan menaruh hasil desain di tempatnya. Tidak pernah menulis isi UX sendiri. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-blueprint` | G3, sekali per produk. Gambaran utuh produk: use case, aktor, domain model, aturan bisnis, glosarium, architecture spine, C4, serta inventaris API, tabel, dan layar. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-component` | G4. Kedalaman satu komponen, sedalam `mode`-nya dan tidak lebih. Dilewati pada `mode: catalog`. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-build` | G5. Satu spec dari dibuka sampai ditutup: Anda menjalankan `to-spec` dan `to-tickets`, setiap tiket sampai PR hijau, lalu spec ditutup. Tidak pernah melakukan merge. | Anda mengetiknya, atau `wdi-autopilot` menjalankannya |
-| **Daily tier** | | |
-| `/wdi-daily-what-to-build` | Mengubah catatan uji manual menjadi spec atau tiket yang sudah ditinjau untuk run autopilot berikutnya. Berhenti sebelum kode, commit, atau push. | Anda mengetiknya |
-| `/wdi-daily-autopilot` | Memeriksa mandat yang sudah diterima (menjalankan preflight bila belum ada), menentukan reviewer dari konfigurasi lokal, lalu memulai loop, default setiap 10 menit. | Anda mengetiknya |
-| `/wdi-autopilot` | Loop-nya sendiri: mengerjakan semua FR di bawah satu mandat yang diterima, di satu branch dengan satu PR, dan menulis setiap keputusan ke satu ledger. | Dijalankan `/loop` di bawah mandat yang diterima |
-| `/wdi-daily-what-to-test` | Sesudah merge: menyinkronkan development branch, memangkas branch dan worktree yang sudah di-merge, menyiapkan aplikasi untuk uji manual, dan menyusun checklist dari tiket yang ditutup. | Anda mengetiknya |
-| `/wdi-prune-or-archive` | Memindahkan spec yang sudah ditutup ke `.archive/specs/` atau menghapusnya dengan `git rm`, lewat `lifecycle.py` yang memeriksa dulu dan membatalkan perubahan bila gagal. Baris spec tetap di `specs.yaml`. | Anda mengetiknya |
-| **Kapan saja** | | |
-| `/wdi-help` | Membaca registri status dan memberi tahu gerbang saat ini, spec yang terbuka, dan skill berikutnya. | Agent boleh menjalankannya sendiri (hanya membaca) |
-| `/wdi-explain-to-me` | Membaca dulu sebelum Anda memutuskan: menyelidiki, lalu memberi ringkasan dalam enam bagian tetap. Tidak menulis file. | Anda mengetiknya |
-| `/wdi-decision` | Membuka, menerima, dan menerapkan keputusan bernomor (`DEC-`), lalu membawanya ke dokumen yang diaturnya. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-question` | Mencatat hal yang belum bisa diputuskan ke salah satu dari empat daftar di `.control/questions/`, dan menutupnya saat jawaban datang. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-log` | Mencatat rapat yang sudah selesai atau fakta non-teknis yang membatasi apa yang boleh dibangun. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-report` | Angka tentang proyek: progres, estimasi, baris tugas untuk tracker, atau brief atau PRD yang berdiri sendiri. Tidak pernah mengarang angka. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-reconcile` | Sebelum gerbang atau sesudah sekumpulan perubahan: melaporkan drift antara `.what`, `.how`, `.control`, dan aturan metode. Hanya membaca. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-review` | Meninjau dokumen korpus mana pun, dan wajib dijalankan sebelum gerbang untuk spine, SRS, SDD, dan SPEC. Lensanya mengikuti `risk_accepted`. Bukan untuk review kode. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-systematic-debugging` | Untuk bug, test yang gagal, atau build yang gagal, sebelum perbaikan diusulkan: cari akar masalah dan uji satu hipotesis setiap kali. | Anda mengetiknya, atau agent menyebutnya |
-| `/wdi-upgrade` | Tepat sesudah `wdi-method update`: memindahkan dokumen dan file registri yang masih berbentuk lama ke bentuk baru, lalu memastikan validasi hijau. | Anda mengetiknya, atau agent menyebutnya |
-
----
-
-## Struktur Repositori
-
-```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
-```
-
----
-
-## Kontribusi
-
-Setiap kontribusi ke WDI Method menjawab satu pertanyaan: **apakah perubahan ini membuat lapisan review lebih dapat dipercaya, atau hanya membuatnya lebih tebal?** Lihat [CONTRIBUTING.md](CONTRIBUTING.md).
-
-### Fixture Corpus dan Verifikasi Lokal
-Perubahan validator dan metode dibuktikan terhadap fixture corpus (`tests/fixture/`). Jalankan rangkaian test sebelum membuka pull request:
-```bash
-npm test
-```
-Rangkaian test menjalankan empat script Python PEP 723 (`validate.py`, `timeline.py`, `inventory.py`, `lifecycle.py`) terhadap fixture, lalu memeriksa registri platform, file yang diterima setiap platform, dan integritas kit.
-
-### Aturan Paket Publik Generik
-WDI Method dipublikasikan ke registri npm publik. Paket ini tidak boleh memuat nama klien privat, identitas produk komersial, kredensial, atau path absolut sistem file.
-
----
-
-## Lisensi dan Privasi
-
-- **Lisensi kode:** [MIT License](LICENSE).
-- **Privasi:** WDI Method sendiri tidak melakukan panggilan jaringan; coding agent Anda tetap berkomunikasi dengan penyedia modelnya. Lihat [PRIVACY.md](PRIVACY.md) dan [SECURITY.md](SECURITY.md).
-
-## The name and the icon
-
-Naskah berbahasa Inggris di bawah ini yang berlaku.
-
-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.
-
----
-
-Kami memakai metode yang sama di proyek klien. [Hubungi Wira Delta Indonesia](https://wiradelta.com/id/studio/#contact).