wdi-method 0.6.29 → 0.6.30

package/README.ja.md

@@ -1,263 +0,0 @@
-# WDI Method
-
-> BMad の上に載るレビュー層です。コードを書く前に、技術的な決定を人が読んで確認するための文書を、その変更に実際に見合う規模で用意します。
-
-[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)
-
----
-
-> **翻訳に関する注意事項:** 本ファイルは [README.md](README.md) の便宜的な翻訳です。矛盾や解釈の相違がある場合は、公式の英語版（README.md）が優先されます。詳細な技術文書および法的文書はすべて英語で管理されています。
-
-[BMad](https://github.com/bmad-code-org/BMAD-METHOD) は AI エージェント向けの文書を書きます。WDI Method は、多くの役割の人がすでに読んでいる文書を追加します。ユースケース、C4 図、API とデータベースの一覧、設計文書です。WDI Method は BMad を置き換えずに包み込みます。ブリーフ、PRD、UX、アーキテクチャのスキル（`wdi-problem`、`wdi-product`、`wdi-ux`、スパインについては `wdi-blueprint`）は執筆を BMad のスキルに任せ、その結果をこのメソッドのガイドに照らして確認します。
-
-> 本リポジトリは**パブリックかつ汎用**です。クライアント名、商用製品名、プライベートリポジトリへのリンクを含めてはなりません（MUST NOT）。製品のアイデンティティは、本パッケージをインストールするリポジトリ側にすべて置かれます。
-
----
-
-## AI 駆動開発 (AiDD) と Vibe Coding
-
-Vibe Coding も仕様を使いますが、一貫していません。プロンプトのセッションごとに内容が変わりうるうえ、文書は構造化されておらず、プロセスも体系的に保たれていません。その結果、効率と効果は大きく下がり、技術的負債が積み上がる現実的なリスクがあります。だからこそフレームワークが必要です。
-
-WDI Method では、AI 駆動開発 (AiDD) は一つの順序で進みます。まず約束を FR とユースケースとして登録し、次にゲートを通り、次に `to-spec` と `to-tickets` で仕様をチケットに切り分け、次に各チケットをテストファーストで作り、最後にオーナーがレビューしてマージする一つの PR にまとめます。
-
-作業は三つの層が担います。
-
-| 層 | 担い手 | 役割 |
-|---|---|---|
-| 1. エージェント向けの文書 | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | プロダクトブリーフ、PRD、UX、アーキテクチャのスパインを、それぞれ BMad のスキルを通じて書く |
-| 2. レビュー層 | WDI Method | それらのスキルを包み込み、他の役割が読む文書を追加し、五つの人間によるゲートを運用し、Goal → FR → UC → Ticket → Test をつなぎ、コーパスのドリフトを確認する |
-| 3. チケットとコード | エンジン（[mattpocock/skills](https://github.com/mattpocock/skills)） | `to-spec` と `to-tickets` が仕様を縦割りのチケットに切り分け、`implement` が各チケットをテストファーストで作る |
-
-### ドキュメントはコードに従う
-
-コードより遅れている文書は想定どおりの状態であり、欠陥ではありません。オーナーが文書よりコードを選んだ場合、修正されるのは文書のほうです。まだ作られていない仕様のように、コードより先行している文書も正常です。
-
----
-
-## 3 ステップでインストール
-
-### 前提条件
-
-- Node.js 20 以降。
-- Git。
-- [uv](https://docs.astral.sh/uv/)。このメソッドの Python 3.11+ 検証ツールを実行します。
-- エージェントプラットフォーム: Claude Code、Cursor、Codex、その他のエージェントプラットフォーム。
-
-三つのステップを順番に実行してください。ステップ 1 またはステップ 2 が済んでいない場合、インストーラーは停止します。すべてのプロンプトにはデフォルト値があり、<kbd>Enter</kbd> を押すとそれを受け入れます。
-
-### ステップ 1: BMad Method のインストール
-```bash
-cd /path/to/your/product-repo
-npx bmad-method install
-```
-
-### ステップ 2: 六つのエンジンの追加
-エンジンをリポジトリにインストールします（"copy" か "symlink" のどちらかを選びます）。
-```bash
-npx skills@latest add mattpocock/skills
-```
-*このメソッドが動かす六つのエンジンをすべて選択します:* `to-spec`、`to-tickets`、`implement`、`tdd`、`code-review`、`domain-modeling`。
-
-> **Claude Code プラグインだけでは足りない理由:** 六つのエンジンのうち三つ（`to-spec`、`to-tickets`、`implement`）は `disable-model-invocation: true` 付きで配布されています。インストールと更新のたびに、WDI Method はリポジトリ内のコピーからその行を削除し、`wdi-build` と `wdi-autopilot` がそれらを実行できるようにします。ユーザーレベルのプラグインは編集できないため、エンジンがリポジトリに入るまでインストーラーは停止します。`--skip-engines-check` でこの確認を省略できます。
-
-### ステップ 3: WDI Method のインストール
-対話型インストーラーを起動し、各エージェントプラットフォームがスキルを読む場所にスキルを配置します。
-```bash
-npx wdi-method
-```
-*（非対話型: `npx wdi-method install --yes --agents claude-code --product "Your Product"`）*
-
-> **インストーラーが BMad で変更すること:** インストーラーは、エンジンが置き換える 13 個の BMad のビルドおよびスプリント用スキルについてモデルによる呼び出しをオフにし、対応する拒否ルールを `.claude/settings.json` に追加します。コマンドを入力すれば、それらは引き続き実行できます。
-
-### 最初のコマンド: `/wdi-help`
-コーディングエージェントの中で次を実行します。
-```text
-/wdi-help
-```
-`wdi-help` は `.control/registry/` を読み、会話から推測することなく、プロジェクトがどのゲートにいるか、開いている仕様、次のスキルを伝えます。
-
----
-
-## 三つのワークフローオプション
-
-WDI Method は、タスクの規模とリスクに合わせて手続きの重さを調整します。
-
-### オプション A: ガイド付きデリバリートラック（G1 から G5）
-新製品、大きな取り組み、アーキテクチャの変更に使います。各ゲートのスキルはあなたが開始し、エージェントは次のスキルを示して待ちます。
-
-**ゲートごとに一つの決定。** 各ゲートは一つのことを決めます。G1 から G4 ではレンダリングされたページを一つ読み、G5 では仕様の RTM 行を読みます。短いチェックリストに答え、星印の付いた質問に一つでも「いいえ」があればゲートは保留になります。
-
-| ゲート | 決めること | スキル | 読むもの | オーナーの決定 |
-|---|---|---|---|---|
-| **G1 Problem** | 問題は何か、誰の問題か、なぜ作業に値するか | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | 問題の捉え方を承認する |
-| **G2 Product** | 何を作るか、使ったときにどう感じられるか | `/wdi-product`<br>`/wdi-ux`（任意） | `.what-rendered/_prd/<slug>/prd.md` | 機能上の約束（FR）を承認する |
-| **G3 Blueprint** | 製品の全体像。製品ごとに一度 | `/wdi-blueprint` | `.how-rendered/blueprint.md` | アーキテクチャのスパインを承認する |
-| **G4 Component** | 一つのコンポーネントをどう作るか（`mode: catalog` では省略） | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | ソフトウェア設計を承認する |
-| **G5 Release** | 完了し、証明されているか | `/wdi-build` | `.control/generated/` にある仕様の RTM 行と、各チケットのテストの証拠 | 仕様を完了として受け入れるか、差し戻す |
-
-**進めずに磨く。** 星印（★）の付いたチェックリストの質問に一つでも「いいえ」があれば、ゲートは保留になります。文書を磨いてからゲートを再実行してください。後で直すつもりで承認してはいけません。
-
-#### 決して統合しない二つのフィールド
-- **`mode`** は、各コンポーネントの文書をどこまで深く書くかを決めます。`catalog`（デフォルト）: ブループリント以外には何も書かず、G4 は省略されます。`outline`: 最大 3 件のユースケースの完全なフロー、ローカルなビジネスルール、決定の要約。`guarded`: すべての境界に `Failure Behaviour` セクションを加え、サードパーティ連携の文書を加えます。`deep`: ロバストネス分析、エンドポイントごとの契約、データディクショナリ、フロー図、状態機械を加えます。
-- **`risk_accepted`** は、レビューをどこまで厳しくするかを決めます。`high`（多くのリスクを受け入れる）: 基本となる構造と文章の観点。`medium`: エッジケースの観点を加えます。`low`: エッジケースの観点を加え、さらにコードにはビルダー以外のレビュアーが二人必要です。
-
-一つのフィールドで両方を決めてしまうと、薄い文書を得る唯一の方法は、実際に受け入れる以上のリスクをリスク記録に書くことになります。
-
----
-
-### オプション B: 自律的な日次運用（Daily Tier）
-アーキテクチャが整ったら、日々の作業は、エージェントの中で入力する四つのスキルによる日次のリズムで進みます。
-
-1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
-   手動テストのメモ、QA の所見、バグ報告を、後の autopilot 実行のために、開発ブランチ上のレビュー済みの仕様またはチケットに変えます。そこで止まります。コミット、プッシュ、autopilot の開始は一切しません。
-2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
-   受け入れ済みのマンデートがあるか確認し、なければプリフライトを実行し、ローカル設定からレビュアーを決定して、ループを開始します（デフォルトは `/loop 10m /wdi-autopilot`）。ループはブランチ `autopilot/<mandate-id>` 上で作業し、コードをテストファーストで書き、すべての決定を台帳に記録し、レビュー準備のできた一つの PR で終わります。マージはオーナーが行います。
-3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
-   マージ後に、開発ブランチを同期し、マージ済みのブランチとワークツリーを整理し、手動テスト用にアプリを準備し、前回の同期以降にクローズされたチケット（`before_sync..HEAD`）からチェックリストを作ります。引数なしの場合は、同期、整理、チェックリスト作成だけを行います。
-4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
-   クローズされた仕様を `.scratch/` から `.archive/specs/` へ移すか、`git rm` で削除します。これは `lifecycle.py` を通じて行われ、`lifecycle.py` は先に確認し、失敗時にはロールバックします。仕様の行は `specs.yaml` に残ります。引数なしの場合は確認を求めます。
-
----
-
-### オプション C: ファストパス（`/implement` を直接）
-FR、UC、AD-N、ドメインモデルのいずれも変えず、チケットが最大一つで、お金、個人データ、サードパーティ連携に触れない修正は、すべてのゲートを省略できます。ラッパースキルを使わず、`/implement` を直接実行します。修正が FR に触れることがわかった場合は作業を止め、サイズ S の仕様（最大 3 チケット）にして `wdi-build` で進めます。
-
----
-
-## 現場のルール
-
-実際の製品リポジトリで自律コーディングループを運用して得た運用ルールです。
-
-### 1. ビルダーはコーディネーターに固定（`builder: coordinator`）
-`wdi-daily-autopilot` では、`.control/custom-dispatch.yaml` の `roles.builder` は `coordinator` に固定されています。コードをサブエージェントに任せると、偽の完了報告が起きました（ファイルを一つも編集していないのに、サブエージェントがテストは通ったと主張する）。コーディネートするセッション自身が、テストファーストでコードを書きます。
-
-### 2. 読み取り専用のレビュアー
-ピアレビュアーは読み取り専用で動きます。エッジケースを問いただし、差分を読みますが、コードを変えたりビルドを実行したりはしません。書き込むのはコーディネートするセッションだけです。`risk_accepted: low` ではピアレビューの省略は拒否されます。そこでのコードにはビルダー以外のレビュアーが二人必要だからです。
-
-### 3. Windows のファイルロック（デスクトップのプロセスゲート）
-Windows では、実行中のアプリのバイナリやバックグラウンドのビルドデーモンがファイルハンドルを開いたままにするため、再ビルドやワークツリーの削除が `Access is denied` で失敗します。`desktop` ターゲットでは、`wdi-daily-what-to-test` は再ビルドの前にアプリのバイナリがまだ実行中かどうかを確認します。アプリを閉じるのは、自分の前回のスモーク実行がそれを起動した場合だけです。そうでなければ PID を報告して止まり、あなた自身が閉じられるようにします。プロセスを強制終了することはありません。
-
-### 4. ループは専用のブランチで動く
-仕様とチケットの執筆は開発ブランチ上で行います。ループは専用のブランチ `autopilot/<mandate-id>` 上で、隔離されたワークツリー、またはその実行だけが使うクリーンなチェックアウトの中で動きます。共有のチェックアウトや未コミットの変更があるチェックアウトの上で動くことはありません。
-
-### 5. autopilot 実行ごとにクラウド CI は一回
-ループはチケットごとにコミットし、実行中はローカルのテストスイートが証拠になります。クラウド CI は autopilot 実行ごとに一回、最後に動きます。その一つの PR がレビュー準備完了にされたとき、またはワークフローが一度ディスパッチされたときです。実行中のプッシュではクラウドの実行は始まりません。
-
-### 6. マシンローカルのスモークファイル
-スモークのカーソル（`.work/smoke/last-sync`）と実行時のマニフェストは一台のマシンに属します。インストーラーは `.work/smoke/` を `.gitignore` に追加するため、マシンローカルのスモークファイルによって作業ツリーが未コミットの状態になることはありません。
-
----
-
-## 設定（`custom-dispatch.yaml`）
-
-マシン固有のランナーコマンドとモデルのフラグは `.control/custom-dispatch.yaml` に置きます。このファイルがない場合、インストーラーは `.control/custom-dispatch.yaml.example` から作成し、`.gitignore` に追加します。コミットされるのは example だけです。
-
-レビュアーとして指定されたランナーは読み取り専用でなければなりません（MUST）。CLI ごとの読み取り専用フラグ: `claude --permission-mode plan`、`kiro-cli --trust-tools=fs_read`、`cursor-agent --mode plan`。テンプレートのランナー例はすべてこれを使っています。
-
----
-
-## スキル一覧（22）
-
-WDI Method は 22 個のスキルをインストールします。ゲートのスキルが 7 個、daily tier のスキルが 5 個（`wdi-autopilot` を含む）、いつでも実行できるスキルが 10 個です。
-
-スキルの起動方法:
-- **あなたが入力する**: daily tier の四つのスキルと `wdi-explain-to-me`（これらは `disable-model-invocation: true` を持ちます）。
-- **あなたが入力するか、受け入れ済みのマンデートのもとで `wdi-autopilot` が実行する**: `wdi-build`。`wdi-autopilot` がこれを呼び出す必要があるため、`disable-model-invocation` フラグは持ちません。エージェントが自分からこれを始めないというルールは、インストーラーが `CLAUDE.md` と `AGENTS.md` に書き込む Method policy にあります。
-- **あなたが入力するか、エージェントが示してあなたの了承を待つ**: その他のスキル。
-- **エージェントが自分で実行してよい（読み取り専用）**: `wdi-help`。
-- **受け入れ済みのマンデートのもとで `/loop` が起動する**: `wdi-autopilot`。マンデートのもとでは、`wdi-autopilot` が他のスキルも実行します。
-
-| スキル | 役割 | 起動方法 |
-|---|---|---|
-| **ゲートのスキル** | | |
-| `/wdi-init` | G1 の前と G2 の終わりに: レジストリ、コンポーネント、`mode` と `risk_accepted`、二つの構造マップ、エンジンの確認、インベントリの読み取りツールを用意します。 | あなたが入力するか、エージェントが示す |
-| `/wdi-problem` | G1。BMad のプロダクトブリーフのスキルを実行し、ブリーフをこのメソッドのガイドに照らして確認します。ブリーフを自分で書くことはありません。 | あなたが入力するか、エージェントが示す |
-| `/wdi-product` | G2。新しい PRD や変更された約束について BMad の PRD スキルを実行し、PRD ガイドに照らして確認します。PRD を自分で書くことはありません。 | あなたが入力するか、エージェントが示す |
-| `/wdi-ux` | 任意、G2 とともに。BMad の UX スキルを実行し、設計の結果をあるべき場所に収めます。UX の内容を自分で書くことはありません。 | あなたが入力するか、エージェントが示す |
-| `/wdi-blueprint` | G3、製品ごとに一度。製品全体の姿: ユースケース、アクター、ドメインモデル、ビジネスルール、用語集、アーキテクチャのスパイン、C4、そして API、テーブル、画面のインベントリ。 | あなたが入力するか、エージェントが示す |
-| `/wdi-component` | G4。一つのコンポーネントの深さで、その `mode` が求める深さまで、それ以上は書きません。`mode: catalog` では省略されます。 | あなたが入力するか、エージェントが示す |
-| `/wdi-build` | G5。一つの仕様をオープンからクローズまで: あなたが `to-spec` と `to-tickets` を実行し、各チケットがグリーンの PR になり、その後仕様がクローズされます。マージはしません。 | あなたが入力するか、`wdi-autopilot` が実行する |
-| **Daily tier** | | |
-| `/wdi-daily-what-to-build` | 手動テストのメモを、後の autopilot 実行のためのレビュー済みの仕様またはチケットに変えます。コード、コミット、プッシュの前で止まります。 | あなたが入力する |
-| `/wdi-daily-autopilot` | 受け入れ済みのマンデートがあるか確認し（なければプリフライトを実行）、ローカル設定からレビュアーを決定して、デフォルトでは 10 分ごとのループを開始します。 | あなたが入力する |
-| `/wdi-autopilot` | ループそのもの: 一つの受け入れ済みマンデートのもとで、一つのブランチと一つの PR で、すべての FR を順に処理し、すべての決定を一つの台帳に書きます。 | 受け入れ済みのマンデートのもとで `/loop` が起動する |
-| `/wdi-daily-what-to-test` | マージ後に: 開発ブランチを同期し、マージ済みのブランチとワークツリーを整理し、手動テスト用にアプリを準備し、クローズされたチケットからチェックリストを作ります。 | あなたが入力する |
-| `/wdi-prune-or-archive` | クローズされた仕様を `.archive/specs/` へ移すか `git rm` で削除します。これは `lifecycle.py` を通じて行われ、先に確認し、失敗時にはロールバックします。仕様の行は `specs.yaml` に残ります。 | あなたが入力する |
-| **いつでも** | | |
-| `/wdi-help` | ステータスのレジストリを読み、現在のゲート、開いている仕様、次のスキルを伝えます。 | エージェントが自分で実行してよい（読み取り専用） |
-| `/wdi-explain-to-me` | あなたが決める前に読み込みを済ませます: 調査し、六つの決まったセクションで要点を伝えます。ファイルは書きません。 | あなたが入力する |
-| `/wdi-decision` | 番号付きの決定（`DEC-`）をオープン、受け入れ、適用し、それが規定する文書に反映します。 | あなたが入力するか、エージェントが示す |
-| `/wdi-question` | 今は決められないことを `.control/questions/` の四つのリストのいずれかに収め、答えが出たらクローズします。 | あなたが入力するか、エージェントが示す |
-| `/wdi-log` | 終わった会議、または作れるものを制限する非技術的な事実を記録します。 | あなたが入力するか、エージェントが示す |
-| `/wdi-report` | プロジェクトに関する数字: 進捗、見積もり、トラッカー用のタスク行、または単独のブリーフや PRD。数字をでっち上げることはありません。 | あなたが入力するか、エージェントが示す |
-| `/wdi-reconcile` | ゲートの前、または一連の変更の後に: `.what`、`.how`、`.control` とこのメソッドのルールとの間のドリフトを報告します。読み取り専用です。 | あなたが入力するか、エージェントが示す |
-| `/wdi-review` | 任意のコーパス文書をレビューします。スパイン、SRS、SDD、SPEC については、ゲートの前に必ず実行します。観点は `risk_accepted` に従います。コードレビュー用ではありません。 | あなたが入力するか、エージェントが示す |
-| `/wdi-systematic-debugging` | あらゆるバグ、失敗したテスト、失敗したビルドについて、修正を提案する前に: 根本原因を見つけ、仮説を一つずつ検証します。 | あなたが入力するか、エージェントが示す |
-| `/wdi-upgrade` | `wdi-method update` の直後に: 古い形のままの文書とレジストリファイルを新しい形に移し、検証がグリーンであることを確認します。 | あなたが入力するか、エージェントが示す |
-
----
-
-## リポジトリ構成
-
-```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
-```
-
----
-
-## コントリビューション
-
-WDI Method へのすべてのコントリビューションは、一つの問いに答えます。**これはレビュー層をより信頼できるものにするのか、それとも厚くするだけなのか？** [CONTRIBUTING.md](CONTRIBUTING.md) を参照してください。
-
-### フィクスチャコーパスとローカル検証
-検証ツールとメソッドの変更は、フィクスチャコーパス（`tests/fixture/`）に対して証明します。プルリクエストを開く前にテストスイートを実行してください。
-```bash
-npm test
-```
-テストスイートは、四つの Python PEP 723 スクリプト（`validate.py`、`timeline.py`、`inventory.py`、`lifecycle.py`）をフィクスチャに対して実行し、プラットフォームのレジストリ、各プラットフォームが受け取るファイル、キットの完全性を確認します。
-
-### パブリック汎用パッケージの規則
-WDI Method は公開の npm レジストリで公開されています。プライベートなクライアント名、商用製品のアイデンティティ、認証情報、絶対ファイルシステムパスを決して含めてはなりません。
-
----
-
-## ライセンスとプライバシー
-
-- **コードのライセンス:** [MIT License](LICENSE)。
-- **プライバシー:** WDI Method 自体はネットワーク通信を行いません。ただし、コーディングエージェントはそのモデル提供元と通信します。[PRIVACY.md](PRIVACY.md) と [SECURITY.md](SECURITY.md) を参照してください。
-
-## The name and the icon
-
-以下の英語の原文が適用されるテキストです。
-
-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.
-
----
-
-私たちはクライアントのプロジェクトでも同じメソッドを使っています。[Wira Delta Indonesia に問い合わせる](https://wiradelta.com/studio/#contact)。

package/README.ko.md

@@ -1,263 +0,0 @@
-# WDI Method
-
-> BMad 위에 얹는 검토 계층입니다. 코드를 작성하기 전에 사람이 읽고 기술적 결정을 확인하는 문서를, 변경이 실제로 필요로 하는 규모에 맞춰 제공합니다.
-
-[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)
-
----
-
-> **번역 안내:** 본 문서는 편의를 위해 [README.md](README.md)를 번역한 참고용 문서입니다. 내용상 상충이나 해석의 차이가 있을 경우 영문 공식 문서(`README.md`)가 우선합니다. 세부 기술 문서 및 법적 문서는 영어로 관리됩니다.
-
-[BMad](https://github.com/bmad-code-org/BMAD-METHOD)는 AI 에이전트를 위한 문서를 작성합니다. WDI Method는 여러 역할의 사람들이 이미 읽고 있는 문서를 추가합니다. 유스케이스, C4 다이어그램, API 및 데이터베이스 목록, 설계 문서입니다. WDI Method는 BMad를 대체하지 않고 감쌉니다. 브리프, PRD, UX, 아키텍처 스킬(`wdi-problem`, `wdi-product`, `wdi-ux`, 스파인의 경우 `wdi-blueprint`)은 작성을 BMad 스킬에 맡긴 뒤, 그 결과를 이 방법론의 가이드에 비추어 확인합니다.
-
-> 본 저장소는 **공개 및 범용**입니다. 고객명, 상용 제품명 또는 비공개 저장소로 연결되는 링크를 포함해서는 안 됩니다(MUST NOT). 제품의 정체성은 전적으로 이 패키지를 설치하는 저장소에 있습니다.
-
----
-
-## AI 주도 개발 (AiDD) vs. 바이브 코딩 (Vibe Coding)
-
-바이브 코딩도 사양을 사용하지만 일관되지 않습니다. 프롬프트 세션마다 내용이 달라질 수 있고, 문서는 구조화되어 있지 않으며, 프로세스도 체계적으로 유지되지 않습니다. 그 결과 효율과 효과가 크게 떨어지고, 기술 부채가 쌓일 실제 위험이 생깁니다. 그래서 프레임워크가 필요합니다.
-
-WDI Method에서 AI 주도 개발(AiDD)은 하나의 순서로 진행됩니다. 먼저 약속을 FR과 유스케이스로 등록하고, 다음으로 게이트를 거치고, 다음으로 `to-spec`과 `to-tickets`로 사양을 티켓으로 나누고, 다음으로 각 티켓을 테스트 우선으로 구축하고, 마지막으로 오너가 검토하고 병합하는 하나의 PR로 마무리합니다.
-
-세 계층이 일을 나누어 맡습니다.
-
-| 계층 | 담당 | 하는 일 |
-|---|---|---|
-| 1. 에이전트를 위한 문서 | [BMad](https://github.com/bmad-code-org/BMAD-METHOD) | 제품 브리프, PRD, UX, 아키텍처 스파인을 각각 BMad 스킬을 통해 작성 |
-| 2. 검토 계층 | WDI Method | 그 스킬들을 감싸고, 다른 역할이 읽는 문서를 추가하고, 다섯 개의 사람 게이트를 운영하고, Goal → FR → UC → Ticket → Test를 연결하고, 코퍼스의 드리프트를 확인 |
-| 3. 티켓과 코드 | 엔진([mattpocock/skills](https://github.com/mattpocock/skills)) | `to-spec`과 `to-tickets`가 사양을 수직 티켓으로 나누고, `implement`가 각 티켓을 테스트 우선으로 구축 |
-
-### 문서는 코드를 따른다
-
-코드보다 뒤처진 문서는 예상된 상태이며 결함이 아닙니다. 오너가 문서보다 코드를 선택한 경우, 수정되는 쪽은 문서입니다. 아직 구축되지 않은 사양처럼 코드보다 앞선 문서도 정상입니다.
-
----
-
-## 3단계 설치
-
-### 사전 요구 사항
-
-- Node.js 20 이상.
-- Git.
-- [uv](https://docs.astral.sh/uv/). 이 방법론의 Python 3.11+ 검증기를 실행합니다.
-- 에이전트 플랫폼: Claude Code, Cursor, Codex 및 기타 에이전트 플랫폼.
-
-세 단계를 순서대로 실행하세요. 1단계 또는 2단계가 완료되지 않았으면 설치 프로그램이 멈춥니다. 모든 프롬프트에는 기본값이 있으며, <kbd>Enter</kbd>를 누르면 기본값을 받아들입니다.
-
-### 1단계: BMad Method 설치
-```bash
-cd /path/to/your/product-repo
-npx bmad-method install
-```
-
-### 2단계: 여섯 개의 엔진 추가
-엔진을 저장소에 설치합니다("copy" 또는 "symlink" 중 하나를 선택).
-```bash
-npx skills@latest add mattpocock/skills
-```
-*이 방법론이 구동하는 여섯 개의 엔진을 모두 선택합니다:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review`, `domain-modeling`.
-
-> **Claude Code 플러그인만으로는 부족한 이유:** 여섯 개의 엔진 중 세 개(`to-spec`, `to-tickets`, `implement`)는 `disable-model-invocation: true`가 설정된 채로 배포됩니다. 설치와 업데이트 때마다 WDI Method는 저장소 안의 사본에서 그 줄을 제거하여 `wdi-build`와 `wdi-autopilot`가 이를 실행할 수 있게 합니다. 사용자 수준의 플러그인은 편집할 수 없으므로, 엔진이 저장소에 들어올 때까지 설치 프로그램이 멈춥니다. `--skip-engines-check`로 이 확인을 건너뛸 수 있습니다.
-
-### 3단계: WDI Method 설치
-대화형 설치 프로그램을 실행하고, 각 에이전트 플랫폼이 스킬을 읽는 위치에 스킬을 배치합니다.
-```bash
-npx wdi-method
-```
-*(비대화형: `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
-
-> **설치 프로그램이 BMad에서 바꾸는 것:** 설치 프로그램은 엔진이 대체하는 13개의 BMad 빌드 및 스프린트 스킬에 대해 모델 호출을 끄고, 이에 맞는 거부 규칙을 `.claude/settings.json`에 추가합니다. 명령을 입력하면 여전히 실행할 수 있습니다.
-
-### 첫 번째 명령어: `/wdi-help`
-코딩 에이전트 안에서 다음을 실행합니다.
-```text
-/wdi-help
-```
-`wdi-help`는 `.control/registry/`를 읽고, 대화에서 추측하지 않고 프로젝트가 있는 게이트, 열려 있는 사양, 다음 스킬을 알려 줍니다.
-
----
-
-## 세 가지 워크플로 옵션
-
-WDI Method는 작업의 규모와 위험에 맞춰 절차의 무게를 조정합니다.
-
-### 옵션 A: 가이드 딜리버리 트랙 (G1부터 G5까지)
-새 제품, 주요 이니셔티브, 아키텍처 변경에 사용합니다. 각 게이트 스킬은 사용자가 시작하고, 에이전트는 다음 스킬을 알려 주고 기다립니다.
-
-**게이트마다 하나의 결정.** 각 게이트는 한 가지를 결정합니다. G1부터 G4까지는 렌더링된 페이지 하나를 읽고, G5에서는 사양의 RTM 행을 읽습니다. 짧은 체크리스트에 답하며, 별표가 붙은 질문 하나에서라도 "아니요"가 나오면 게이트는 보류됩니다.
-
-| 게이트 | 결정하는 것 | 스킬 | 읽는 것 | 오너의 결정 |
-|---|---|---|---|---|
-| **G1 Problem** | 문제가 무엇인지, 누구의 문제인지, 왜 작업할 가치가 있는지 | `/wdi-problem` | `.what-rendered/_product-brief/brief.md` | 문제 정의를 승인 |
-| **G2 Product** | 무엇을 만드는지, 사용할 때 어떻게 느껴지는지 | `/wdi-product`<br>`/wdi-ux` (선택) | `.what-rendered/_prd/<slug>/prd.md` | 기능 약속(FR)을 승인 |
-| **G3 Blueprint** | 제품의 전체 그림, 제품당 한 번 | `/wdi-blueprint` | `.how-rendered/blueprint.md` | 아키텍처 스파인을 승인 |
-| **G4 Component** | 하나의 컴포넌트를 어떻게 만드는지 (`mode: catalog`에서는 건너뜀) | `/wdi-component` | `.how-rendered/<pc>/SDD-<pc>.md` | 소프트웨어 설계를 승인 |
-| **G5 Release** | 완료되었고 입증되었는지 | `/wdi-build` | `.control/generated/`에 있는 사양의 RTM 행과 각 티켓의 테스트 증거 | 사양을 완료로 받아들이거나 되돌려 보냄 |
-
-**진행하지 말고 다듬기.** 별표(★)가 붙은 체크리스트 질문 하나에서라도 "아니요"가 나오면 게이트는 보류됩니다. 문서를 다듬고 게이트를 다시 실행하세요. 나중에 고칠 계획으로 승인해서는 안 됩니다.
-
-#### 결코 합쳐지지 않는 두 필드
-- **`mode`**는 각 컴포넌트의 문서를 얼마나 깊게 쓸지 정합니다. `catalog`(기본값): 블루프린트 외에는 아무것도 쓰지 않으며 G4는 건너뜁니다. `outline`: 최대 3개 유스케이스의 전체 흐름, 로컬 비즈니스 규칙, 결정 요약. `guarded`: 모든 경계에 대한 `Failure Behaviour` 섹션과 서드파티 연동 문서를 추가합니다. `deep`: 견고성 분석, 엔드포인트별 계약, 데이터 사전, 흐름도, 상태 머신을 추가합니다.
-- **`risk_accepted`**는 검토를 얼마나 엄격하게 할지 정합니다. `high`(많은 위험을 받아들임): 기본 구조 및 문장 관점. `medium`: 엣지 케이스 관점을 추가합니다. `low`: 엣지 케이스 관점을 추가하고, 코드에는 빌더가 아닌 검토자 두 명이 필요합니다.
-
-하나의 필드가 둘 다 정한다면, 얇은 문서를 얻는 유일한 방법은 실제로 받아들이는 것보다 더 많은 위험을 위험 기록에 적는 것이 됩니다.
-
----
-
-### 옵션 B: 자율 일일 운영 (Daily Tier)
-아키텍처가 자리 잡으면, 일상 작업은 에이전트 안에서 입력하는 네 개의 스킬을 통해 매일의 리듬으로 진행됩니다.
-
-1. **`/wdi-daily-what-to-build [reviewer] <notes>`**  
-   수동 테스트 메모, QA 관찰 내용 또는 버그 보고를, 이후의 autopilot 실행을 위해 개발 브랜치 위의 검토된 사양이나 티켓으로 바꿉니다. 거기서 멈춥니다. 커밋, 푸시, autopilot 시작은 절대 하지 않습니다.
-2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**  
-   수락된 위임(mandate)이 있는지 확인하고 없으면 사전 점검(preflight)을 실행하며, 로컬 설정에서 검토자를 정하고, 루프를 시작합니다(기본값 `/loop 10m /wdi-autopilot`). 루프는 브랜치 `autopilot/<mandate-id>`에서 작업하고, 코드를 테스트 우선으로 작성하며, 모든 결정을 원장에 기록하고, 검토 준비가 된 하나의 PR로 끝납니다. 병합은 오너가 합니다.
-3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**  
-   병합 후에: 개발 브랜치를 동기화하고, 병합된 브랜치와 워크트리를 정리하고, 수동 테스트를 위해 앱을 준비하고, 마지막 동기화 이후 닫힌 티켓(`before_sync..HEAD`)으로 체크리스트를 만듭니다. 인수가 없으면 동기화, 정리, 체크리스트 작성만 합니다.
-4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**  
-   닫힌 사양을 `.scratch/`에서 `.archive/specs/`로 옮기거나 `git rm`으로 제거합니다. 이 작업은 `lifecycle.py`를 통해 이루어지며, `lifecycle.py`는 먼저 확인하고 실패하면 롤백합니다. 사양 행은 `specs.yaml`에 남습니다. 인수가 없으면 물어봅니다.
-
----
-
-### 옵션 C: 패스트 패스 (`/implement` 직접 실행)
-FR, UC, AD-N 또는 도메인 모델을 바꾸지 않고, 티켓이 최대 하나이며, 돈, 개인 데이터 또는 서드파티 연동에 닿지 않는 수정은 모든 게이트를 건너뛸 수 있습니다. 래퍼 스킬 없이 `/implement`를 직접 실행합니다. 수정이 FR에 닿는 것으로 드러나면 작업을 멈추고 크기 S의 사양(최대 3개 티켓)으로 바꾸어 `wdi-build`로 진행합니다.
-
----
-
-## 현장 규칙
-
-실제 제품 저장소에서 자율 코딩 루프를 운영하며 얻은 운영 규칙입니다.
-
-### 1. 빌더는 코디네이터로 고정 (`builder: coordinator`)
-`wdi-daily-autopilot`에서 `.control/custom-dispatch.yaml`의 `roles.builder`는 `coordinator`로 고정됩니다. 코드를 서브에이전트에 위임하자 거짓 완료 보고가 발생했습니다(서브에이전트가 파일을 하나도 편집하지 않고 테스트가 통과했다고 주장). 코디네이팅 세션이 직접 테스트 우선으로 코드를 작성합니다.
-
-### 2. 읽기 전용 검토자
-동료 검토자는 읽기 전용으로 실행됩니다. 엣지 케이스를 따져 묻고 diff를 읽지만, 코드를 바꾸거나 빌드를 실행하지는 않습니다. 쓰는 것은 코디네이팅 세션뿐입니다. `risk_accepted: low`에서는 동료 검토 생략이 거부됩니다. 그곳의 코드에는 빌더가 아닌 검토자 두 명이 필요하기 때문입니다.
-
-### 3. Windows 파일 잠금 (데스크톱 프로세스 게이트)
-Windows에서는 실행 중인 앱 바이너리나 백그라운드 빌드 데몬이 파일 핸들을 연 채로 두기 때문에, 다시 빌드하거나 워크트리를 삭제할 때 `Access is denied`로 실패합니다. `desktop` 대상에서 `wdi-daily-what-to-test`는 다시 빌드하기 전에 앱 바이너리가 아직 실행 중인지 확인합니다. 앱을 닫는 것은 자신의 이전 스모크 실행이 그 앱을 시작한 경우뿐입니다. 그렇지 않으면 PID를 보고하고 멈추어, 사용자가 직접 닫을 수 있게 합니다. 프로세스를 강제 종료하는 일은 없습니다.
-
-### 4. 루프는 자기 브랜치에서 실행
-사양과 티켓 작성은 개발 브랜치에서 이루어집니다. 루프는 자기 브랜치 `autopilot/<mandate-id>`에서, 격리된 워크트리 안이나 그 실행만 사용하는 깨끗한 체크아웃 안에서 실행됩니다. 공유된 체크아웃이나 커밋되지 않은 변경이 있는 체크아웃에서는 절대 실행되지 않습니다.
-
-### 5. autopilot 실행당 클라우드 CI 실행은 한 번
-루프는 티켓마다 커밋하며, 실행 중에는 로컬 테스트 스위트가 증거가 됩니다. 클라우드 CI는 autopilot 실행당 한 번, 마지막에 실행됩니다. 그 하나의 PR이 검토 준비 상태로 표시될 때, 또는 워크플로가 한 번 디스패치될 때입니다. 실행 중의 푸시는 클라우드 실행을 시작하지 않습니다.
-
-### 6. 머신 로컬 스모크 파일
-스모크 커서(`.work/smoke/last-sync`)와 런타임 매니페스트는 한 대의 머신에 속합니다. 설치 프로그램이 `.work/smoke/`를 `.gitignore`에 추가하므로, 머신 로컬 스모크 파일 때문에 작업 트리가 커밋되지 않은 변경 상태로 남는 일은 없습니다.
-
----
-
-## 설정 (`custom-dispatch.yaml`)
-
-머신별 러너 명령과 모델 플래그는 `.control/custom-dispatch.yaml`에 둡니다. 이 파일이 없으면 설치 프로그램이 `.control/custom-dispatch.yaml.example`에서 만들고 `.gitignore`에 추가합니다. 커밋되는 것은 example뿐입니다.
-
-검토자로 지정된 러너는 읽기 전용이어야 합니다(MUST). CLI별 읽기 전용 플래그: `claude --permission-mode plan`, `kiro-cli --trust-tools=fs_read`, `cursor-agent --mode plan`. 템플릿의 예시 러너는 모두 이를 사용합니다.
-
----
-
-## 스킬 목록 (22)
-
-WDI Method는 22개의 스킬을 설치합니다. 게이트 스킬 7개, daily tier 스킬 5개(`wdi-autopilot` 포함), 언제든 실행할 수 있는 스킬 10개입니다.
-
-스킬이 시작되는 방식:
-- **사용자가 입력**: 네 개의 daily tier 스킬과 `wdi-explain-to-me`(이들은 `disable-model-invocation: true`를 가집니다).
-- **사용자가 입력하거나, 수락된 위임 아래에서 `wdi-autopilot`가 실행**: `wdi-build`. `wdi-autopilot`가 이를 호출해야 하므로 `disable-model-invocation` 플래그를 가지지 않습니다. 에이전트가 스스로 이를 시작하지 않는다는 규칙은 설치 프로그램이 `CLAUDE.md`와 `AGENTS.md`에 쓰는 Method policy에 있습니다.
-- **사용자가 입력하거나, 에이전트가 알려 주고 사용자의 승인을 기다림**: 나머지 스킬.
-- **에이전트가 스스로 실행할 수 있음(읽기 전용)**: `wdi-help`.
-- **수락된 위임 아래에서 `/loop`가 실행**: `wdi-autopilot`. 위임 아래에서는 `wdi-autopilot`가 다른 스킬도 실행합니다.
-
-| 스킬 | 하는 일 | 시작 방식 |
-|---|---|---|
-| **게이트 스킬** | | |
-| `/wdi-init` | G1 전과 G2 끝에: 레지스트리, 컴포넌트, `mode`와 `risk_accepted`, 두 개의 구조 맵, 엔진 확인, 인벤토리 리더를 준비합니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-problem` | G1. BMad의 제품 브리프 스킬을 실행한 뒤, 브리프를 이 방법론의 가이드에 비추어 확인합니다. 브리프를 직접 쓰지 않습니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-product` | G2. 새 PRD나 바뀐 약속에 대해 BMad의 PRD 스킬을 실행한 뒤, PRD 가이드에 비추어 확인합니다. PRD를 직접 쓰지 않습니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-ux` | 선택, G2와 함께. BMad의 UX 스킬을 실행하고 설계 결과를 제자리에 정리합니다. UX 내용을 직접 쓰지 않습니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-blueprint` | G3, 제품당 한 번. 제품 전체 그림: 유스케이스, 액터, 도메인 모델, 비즈니스 규칙, 용어집, 아키텍처 스파인, C4, 그리고 API, 테이블, 화면 인벤토리. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-component` | G4. 하나의 컴포넌트의 깊이로, 그 `mode`가 요구하는 만큼만 깊게 쓰고 그 이상은 쓰지 않습니다. `mode: catalog`에서는 건너뜁니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-build` | G5. 하나의 사양을 열림부터 닫힘까지: 사용자가 `to-spec`과 `to-tickets`를 실행하고, 각 티켓이 녹색 PR에 도달한 뒤 사양이 닫힙니다. 병합은 하지 않습니다. | 사용자가 입력하거나, `wdi-autopilot`가 실행 |
-| **Daily tier** | | |
-| `/wdi-daily-what-to-build` | 수동 테스트 메모를 이후의 autopilot 실행을 위한 검토된 사양이나 티켓으로 바꿉니다. 코드, 커밋, 푸시 전에 멈춥니다. | 사용자가 입력 |
-| `/wdi-daily-autopilot` | 수락된 위임이 있는지 확인하고(없으면 사전 점검 실행), 로컬 설정에서 검토자를 정하고, 기본적으로 10분마다 도는 루프를 시작합니다. | 사용자가 입력 |
-| `/wdi-autopilot` | 루프 자체: 하나의 수락된 위임 아래에서, 하나의 브랜치와 하나의 PR로 모든 FR을 처리하고, 모든 결정을 하나의 원장에 기록합니다. | 수락된 위임 아래에서 `/loop`가 실행 |
-| `/wdi-daily-what-to-test` | 병합 후에: 개발 브랜치를 동기화하고, 병합된 브랜치와 워크트리를 정리하고, 수동 테스트를 위해 앱을 준비하고, 닫힌 티켓으로 체크리스트를 만듭니다. | 사용자가 입력 |
-| `/wdi-prune-or-archive` | 닫힌 사양을 `.archive/specs/`로 옮기거나 `git rm`으로 제거합니다. 이 작업은 `lifecycle.py`를 통해 이루어지며, 먼저 확인하고 실패하면 롤백합니다. 사양 행은 `specs.yaml`에 남습니다. | 사용자가 입력 |
-| **언제든** | | |
-| `/wdi-help` | 상태 레지스트리를 읽고 현재 게이트, 열려 있는 사양, 다음 스킬을 알려 줍니다. | 에이전트가 스스로 실행할 수 있음(읽기 전용) |
-| `/wdi-explain-to-me` | 사용자가 결정하기 전에 읽는 일을 해 둡니다: 조사한 뒤 여섯 개의 고정된 섹션으로 브리핑합니다. 파일을 쓰지 않습니다. | 사용자가 입력 |
-| `/wdi-decision` | 번호가 붙은 결정(`DEC-`)을 열고, 수락하고, 적용하며, 그 결정이 규율하는 문서에 반영합니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-question` | 지금 결정할 수 없는 사항을 `.control/questions/`의 네 목록 중 하나에 넣고, 답이 나오면 닫습니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-log` | 끝난 회의, 또는 만들 수 있는 것을 제한하는 비기술적 사실을 기록합니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-report` | 프로젝트에 관한 숫자: 진행 상황, 추정치, 트래커용 작업 행, 또는 독립된 브리프나 PRD. 숫자를 지어내지 않습니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-reconcile` | 게이트 전이나 일련의 변경 후에: `.what`, `.how`, `.control`과 이 방법론의 규칙 사이의 드리프트를 보고합니다. 읽기 전용입니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-review` | 어떤 코퍼스 문서든 검토하며, 스파인, SRS, SDD, SPEC에 대해서는 게이트 전에 반드시 실행해야 합니다. 관점은 `risk_accepted`를 따릅니다. 코드 리뷰용이 아닙니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-systematic-debugging` | 모든 버그, 실패한 테스트, 실패한 빌드에 대해 수정을 제안하기 전에: 근본 원인을 찾고 한 번에 하나의 가설을 검증합니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-| `/wdi-upgrade` | `wdi-method update` 직후에: 아직 예전 형태인 문서와 레지스트리 파일을 새 형태로 옮긴 뒤, 검증이 녹색인지 확인합니다. | 사용자가 입력하거나, 에이전트가 알려 줌 |
-
----
-
-## 저장소 구조
-
-```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
-```
-
----
-
-## 기여
-
-WDI Method에 대한 모든 기여는 한 가지 질문에 답합니다. **이것이 검토 계층을 더 신뢰할 수 있게 만드는가, 아니면 더 두껍게만 만드는가?** [CONTRIBUTING.md](CONTRIBUTING.md)를 참고하세요.
-
-### 픽스처 코퍼스와 로컬 검증
-검증기와 방법론의 변경은 픽스처 코퍼스(`tests/fixture/`)에 대해 입증합니다. 풀 리퀘스트를 열기 전에 테스트 스위트를 실행하세요.
-```bash
-npm test
-```
-테스트 스위트는 네 개의 Python PEP 723 스크립트(`validate.py`, `timeline.py`, `inventory.py`, `lifecycle.py`)를 픽스처에 대해 실행하고, 플랫폼 레지스트리, 각 플랫폼이 받는 파일, 키트의 무결성을 확인합니다.
-
-### 공개 범용 패키지 규칙
-WDI Method는 공개 npm 레지스트리에 게시됩니다. 비공개 고객명, 상용 제품 정체성, 자격 증명, 절대 파일 시스템 경로를 절대 포함해서는 안 됩니다.
-
----
-
-## 라이선스와 개인정보
-
-- **코드 라이선스:** [MIT License](LICENSE).
-- **개인정보:** WDI Method 자체는 네트워크 호출을 하지 않습니다. 다만 코딩 에이전트는 여전히 모델 제공자와 통신합니다. [PRIVACY.md](PRIVACY.md)와 [SECURITY.md](SECURITY.md)를 참고하세요.
-
-## The name and the icon
-
-아래의 영어 원문이 적용되는 텍스트입니다.
-
-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.
-
----
-
-저희는 고객 프로젝트에도 같은 방법론을 사용합니다. [Wira Delta Indonesia에 문의하기](https://wiradelta.com/studio/#contact).