walden

Walden

意図的に作成し、レビューします。ワークフローの仕組みは CLI に委ねます。ユーザーの希望する言語で返信します。このスキルが提供するのは判断であり、ユーザーに代わっての承認ではありません。

エントリー判断

機能を作成する前、またはフェーズを選択する前に、リクエスト、適用可能なプロジェクトルール、既存の契約を確認します。.walden/constitution.md と、存在する場合は関連する .walden/lessons.md を読みます。承認済みの .walden/contracts.md が存在する場合は、そこからディスカバリーを開始します。関連すると識別された機能のみを完全に読み、必要に応じてそれらの引用をたどります。ユーザーが Walden に言及したというだけの理由で仕様を作成してはいけません。

契約への影響	ルート
意図された動作を維持または復元する	明示的なユーザーのスコープまたはプロジェクトルールが仕様を要求しない限り、新しい仕様作成サイクルの外で作業を続けます。既存のテストを実行し、該当する Walden エビデンスを更新します。
意図された動作を導入または変更する	作成に入ります。新機能の要件、または既存仕様の最も早い影響フェーズから始めます。
不明確	レーンを選択したり推測的なドキュメントを作成したりする前に、意図された動作について焦点を絞った質問をします。

バグ修正は、承認済みの契約を変更せずに復元できます。リファクタリングはそれを維持できます。どちらのルートも、テスト、エビデンスチェック、実行承認を回避しません。メンテナンス修正の実装を明示的に要求することは、その作業を承認することになります。計画ドキュメントのみの承認は、それに該当しません。

メンテナンスを完了する前に、該当する現在の契約を特定し、既存のテストを実行し、宣言されたチェックポイントで walden verify <feature> を用いて選択された影響エビデンスを更新します。--all は、正当化された強制チェックにのみ使用します。CLI の結果を確認します。生のテスト出力だけではエビデンスは更新されません。変更をカバーする仕様がない場合は、チェックボックスを得るためだけに仕様を作成することなく、その制限を述べます。

既存のポートフォリオについては、採用またはリプレイを提案する前に、ユーザーが要求したスコープ内で適用可能性を確立します。

提案する適用可能性	レビューアクション
現行	選択された検証スコープ内で必要な動作を維持します。
置き換え済み	置き換え／削除の決定と後継を引用します。廃止を提案しますが、自動的に実行してはいけません。
混在	廃止された設計／タスクを破棄する前に、存続する要件とその合意された行き先を特定します。
未解決	具体的なビジネス／スコープの質問をします。適合性をでっち上げてはいけません。

提案は意思決定の情報源に基づかせます。経過時間、欠落したフィンガープリント、完了したチェックボックスは、陳腐化を確立しません。要件は、時代遅れの実装計画を超えて存続できます。現在の要件であるからといって、その歴史的なブートストラップ／デプロイのタスクが現在の回帰チェックになるわけではありません。リプレイを提案する前に、実際の証拠を確認します。それが一度限りのデリバリー作業を記録している場合は、CLI が再証明のカウントを報告したというだけの理由で自動的なバックフィルと実行を行うのではなく、必要とされる現在のベースライン／回帰契約をレビューのために提案します。コードは観察された動作を記述するものであり、意図を書き換える権限ではありません。新しいドラフトが、承認済みの契約を自動的に置き換えるわけではありません。情報源が矛盾する場合は、契約を廃止または変更する前に質問します。ケーススタディのリクエストは、改善対象の製品に関する一般的な知見をもたらすものであり、例のリポジトリにおける一方的な操作ではありません。

既存の仕様については、推測で鮮度を判断するのではなく、CLI のステータスと検証を使用します。新しい仕様については、CLI が生成するスキャフォールドを正規のドキュメントテンプレートとして使用します。完全なテンプレートを記憶から再構築してはいけません。

CLI の前提条件

Walden CLI v0.10.4 以降の互換リリースが必要です。最初の CLI 操作の前に、command -v walden と、その実行ファイルの version --json を確認してください。PATH に使用可能な互換 CLI がない場合は、$HOME/.local/bin/walden も確認してください（Windows の場合: Get-Command walden と %USERPROFILE%\go\bin\walden.exe）。互換性のあるバイナリは、検証済みのパスまたはセッション限りの PATH 修正によって再利用してください。ダウングレードしたり、永続的なシェル設定を編集したりしないでください。不明なバージョンは互換性があると見なしません。

CLI が存在しないか互換性がない場合は、依存する Walden 操作を停止してください。このガイドは CLI を決してインストールしません。インストーラーを実行したり、スクリプトやバイナリを取得したり、エージェントが実行するインストールコマンドを書いたりしないでください。インストールはユーザーが自身のターミナルで行う操作です。プラットフォームを判定し（POSIX シェルでは uname -s、PowerShell では $env:OS、MSYS/MINGW は Windows を意味します）、かつ command -v go（PowerShell: Get-Command go）を実行して、以下の分岐がユーザーへの質問ではなく調べるだけで済むようにしてください。そのうえで、次のいずれかのパスを提示してください:

• go が解決できる場合（すべてのプラットフォーム）: go install github.com/andrearaponi/walden/cmd/[email protected] を単一のコマンドブロックとして示し、次に $(go env GOPATH)/bin（Windows: %USERPROFILE%\go\bin）が PATH に含まれていることを確認してください。
• go が解決できず、macOS/Linux の場合: https://github.com/andrearaponi/walden を開いてください — README にワンラインインストーラーがあり、リリースページにバイナリがあります。コマンドブロックは示さないでください。あなたはそのインストーラーの行を持っていません。
• go が解決できず、Windows の場合: https://github.com/andrearaponi/walden/releases から walden-v0.10.4-windows-<arch>.exe をダウンロードし、walden.exe に名前を変更して PATH に配置してください。

そのうえでユーザーがそれでもインストールを求めた場合は、インストールは行わないことを一度だけ言い直し、同じ単一の案内またはブロックを繰り返してください — 1 回の返信につき正確に 1 つのブロックのみで、もう一方の分岐は決して示さず、取得したスクリプトも決して示さないでください。3 回目に拒否を繰り返さないでください。何も取得しないでください。欠落している CLI の代わりに手動のワークフローメタデータで代用しないでください。

このガイドは Skills CLI を通じて配布され、CLI バイナリは別途配布されます。どちらも互いをインストール、検査、更新しません。ガイドは npx skills update walden で更新し、バイナリは walden update または README のインストーラーで更新してください。ガイドをインストール、削除、報告する Walden コマンドを探さないでください。そのようなコマンドは存在しません。

所有権と承認

• あらゆる Walden 操作の前に、上記の CLI の前提条件を解決してください。ブートストラップの同意は、仕様を承認したり、タスクの実行を許可したり、公開を許可したりするものではありません。代わりの状態機械を決してでっち上げないでください。
• ワークフローのフロントマター、タイムスタンプ、フィンガープリント、チェックボックス、エビデンスの内容を決して手で編集しないでください。編集するのはドキュメントの本文であり、状態の変更には CLI を使用してください。スキャフォールドに既に存在するスキーマおよび拡張フィールドを保持してください。
• 沈黙を承認として決して扱わないでください。review approve の前に、該当するドキュメントを提示し、明示的な承認を待ってください。
• 計画は承認されたタスクで停止します。計画の実装には明示的な実行リクエストが必要であり、タスクの承認の自動的な結果ではありません。
• 免除には、現在の会話における保留中のスコープと理由についてのユーザーの明示的な承認が必要です。便宜上 --allow-pending を決して指定しないでください。
• 廃止にはユーザーの明示的な確認が必要です。後片付けとして、置き換えられた仕様やエビデンスを削除しないでください。
• 自明でないリクエストには、短い計画とその検証手順を述べてください。制約が矛盾する場合、証明が失敗する場合、または仕様が不十分な場合は、停止して、影響を受ける最も早いフェーズから再計画してください。
• 作成の前に、既存のコンスティテューションがプレースホルダーしか含んでいない場合は、安定したプロジェクトコンテキストを尋ねてください。プロジェクトのスタックやルールをでっち上げないでください。
• フィンガープリントが拘束するのは承認された内容であり、意味的な正しさではありません。優れた要件、意味のある証明、そして人間によるレビューは依然として必要です。

コマンド一覧

仕組みについてはコマンドを使用し、構文の詳細については walden --help と各コマンドのヘルプを参照してください。緑に見える要約だけでなく、JSON の結果と警告を確認してください。

コマンド	使用する場面
walden repo init	オーサリングレーンを選択した後、初期化されていないリポジトリをブートストラップします。
walden feature init <feature>	3 つの正規ドキュメントを作成します。名前は kebab-case に正規化されます。
walden status <feature>	フェーズ、鮮度、ブロッカー、次のアクションを確認します。
walden validate [<feature>] [--all]	現在のフェーズを検証します。--all は仕様全体をチェックします。名前を省略するとポートフォリオ全体を対象とします。
walden review open <feature> --phase <phase>	レビュー可能なドキュメントを提示します。requirements、design、tasks のいずれかを使用します。
walden review approve <feature> --phase <phase>	ユーザーの明示的な承認があった場合にのみ、そのフェーズを確定します。
walden reconcile <feature>	変更された承認済みチェーンを、再レビューする前に修復します。
walden task status <feature>	実行可能な作業とエビデンスの警告を確認します。
walden task start <feature> [task-id]	承認されたタスクを実装する前に、実行コンテキストを取得します。
walden task complete <feature> <task-id>	宣言された証明を実行し、成功した場合にのみ完了を記録します。
walden task complete-all <feature>	明示的に承認された実行可能なバッチを完了します。最初の失敗で停止します。
walden evidence status <feature>	導出されたエビデンスと環境の差異を確認します。診断プロファイルのプローブを実行します。
walden verify <feature>	エビデンスがもはや検証されていない完了済みタスクを再証明します。
walden verify <feature> --all	現在検証済みのタスクを含め、すべての完了済みタスクの証明を強制的に実行します。
walden verify <feature> --check	台帳を永続化せずにレポートします。--all を追加すると、すべての完了済みの証明を強制的に実行します。
walden release check [<feature>] [--strict]	既存のエビデンスとリリースのブロッカーを判定します。証明の実行や公開は決して行いません。
walden adopt [<feature>] [--apply]	証明やプローブなしで、レガシーなバインディング/鮮度/来歴を確認します。apply は選択した証明を実行し、承認が必要です。
walden consolidate	読み取り専用レポート: 前回の統合以降のコントラクトの変更、レビュー範囲、決定論的な検出事項、各変更とリンクされたステートメントとの比較、および識別子。
walden consolidate start	統合の追跡を開始します。承認済みの機能が未統合のバックログになります。
walden consolidate open	レビュー用に .walden/contracts.md を開きます。仕様と一致しない場合、または変更が保留中でコヒーレンスレビューが完了していない場合は拒否されます。
walden consolidate approve	レビュー済みのビューを確定し、チェックポイントを記録します。ユーザーの明示的な承認があった場合にのみ行います。対象の機能にレビュー中のリビジョンがある場合は拒否されます。
walden lesson log --feature <name> --phase <phase> --trigger "..." --lesson "..." --guardrail "..."	再利用可能な修正とその防止ルールを記録します。フェーズには execute と release が含まれます。
walden version	バイナリ/スキーマのバージョンを確認します。

コマンドは失敗時も含めて --json をサポートします。エンベロープには schema_version、command、ok、result が含まれます。警告とコマンド固有のフィールドを確認してください。これを再実装したり、stdout だけから成功を推測したりしないでください。

作成フェーズ

エントリーの決定後、.walden/specs/<feature>/ を特定します。最も早い、欠落している、未承認の、または古くなったフェーズを使用してください。新規機能は常に要件から開始します。既存の作業は、新鮮で承認済みの要件がある場合にのみ設計に入ることができ、新鮮で承認済みの設計がある場合にのみタスクに入ることができます。

各フェーズで同じレビューループを使用します。

1. 上流の内容と関連する教訓を読み、現在の本文を起草または改訂します。
2. 現在のフェーズを検証し、構造上の欠陥と意味のある警告を解決します。
3. CLI を通じてそのレビューを開き、ドキュメントを提示し、承認を求めます。
4. 明示的な承認後、CLI を通じてそれをシールし、ユーザーが要求した範囲内でのみ続行します。

1 つの曖昧な承認から複数のフェーズを機械的に承認しないでください。実装によって契約のギャップが明らかになった場合は、一時停止し、最も早い影響を受けるドキュメントを改訂し、整合をとり、影響を受けるレビューゲートを再度たどります。

決定チェックポイントプロトコル

実行時ではなく、要件、設計、タスクの起草中に適用します。

• 分岐テスト: 別の選択が下流の内容を破棄または大幅に書き換える場合にのみチェックポイントを設けます。結論が出ない場合は、自律的な解決をデフォルトとします。
• 尋ねる前に調査する: コードベース、コンスティテューション、および承認済みの上流ドキュメントを確認します。それらが選択を解決する場合は、`` を記録して続行します。
• チェックポイント: [decision: <question>] を挿入し、分岐を説明し、一行の根拠とともにオプションを推奨し、依存する内容の生成を停止します。どのオプションも防御可能なほど優れていない場合は、選好を捏造しないでください。
• 再開: 続行する前に、ユーザーの回答がどのように適用されるかを説明します。新たに明らかになった重要な分岐は、依存する内容が書かれる前に独自のチェックポイントを設けます。
• 自律性: ユーザーがチェックポイントの決定を委任した場合、`` を記録し、その委任された範囲内の決定についてはそれ以上チェックポイントを設けずに続行します。
• 予算: フェーズの起草セッションごとに最大 5 つのチェックポイントまでとします。未解決のチェックポイントはドラフトに保持し、未解決のものがある間はフェーズレビューを開かないでください。
• 通常の仮定: ユーザーを中断せずに `` をインラインで記録します。

要件

意図がオーサリングを選択するのに十分明確になったら、まず草案を作成し、その後イテレーションを行います。ユーザーストーリーはコンテキストを説明し、受け入れ基準が契約となります。

• 要件には安定した ID (R1)、基準には安定した ID (R1.AC1)、品質属性には NFR1、制約には C1 を付与します。他ですでに参照されている ID を振り直さないでください。
• 各 AC は、観察可能な応答を 1 つ含む EARS で記述します。CLI はキーワード構造を検証するのであり、振る舞いの品質や完全性を検証するのではありません。
• スコープリスクが高い場合は、明示的なスコープ外項目を含めてください。AC の数がしきい値を超えたという理由だけで機能を自動的に分割しないでください。代わりに、凝集性とスコープを再検討してください。
• 各 AC の下に、短い Acceptance check: の継続行を 1 つ付けます。選択したフレームワークや実装コマンドではなく、成功と失敗を分ける観察を記述してください。その観察を述べることができない場合は、承認を求める前に基準を明確化するか書き直してください。

元の AC の文言を復元する場合を含め、改訂のたびに、提示されたすべての基準を検査し、それらの受け入れチェックを保持または再添付してください。要求された EARS 文は、適切な場合は変更せずに保ちます。その別個のチェック継続行は説明的な内容であり、新しい振る舞い要件ではありません。

EARS 形式	形
遍在型	The system SHALL <response>
イベント駆動型	WHEN <event>, the system SHALL <response>
状態駆動型	WHILE <state>, the system SHALL <response>
オプション機能	WHERE <feature>, the system SHALL <response>
望ましくない振る舞い	IF <undesired condition>, THEN the system SHALL <response>
複合型	WHILE <state>, WHEN <event>, the system SHALL <response>

草案作成中の品質チェック:

• 形式: 不変条件には、でっち上げのユーザートリガーは不要です。常時有効な一意性ルールには、「WHEN the user starts, ...」ではなく「The system SHALL assign distinct identifiers」を優先してください。
• 原子性: 「レコードを生成し、通知を配信する」を、独立して観察可能な基準に分割してください。次の基準を起草する前に各応答を確認してください。「and」という語だけでは、2 つの振る舞いが存在することの証明にはなりません。
• 具体的なイベント: 「WHEN processing happens」ではなく、「WHEN an OrderCreated message arrives」または「WHEN a lease expires」を優先してください。API イベントやバックグラウンドイベントは、クリックや送信と同じくらい有効です。
• 失敗の網羅: 現実的な各制約失敗について、必要な応答を特定してください。ストレージ要件には、ハッピーパスでの保存だけでなく、読み取り、書き込み、および関連する失敗時の振る舞いが必要です。
• NFR の昇格: 「IF the connection fails, THEN ... reconnect」は振る舞いであり、AC に属します。回復性属性は NFR として保持してください。
• NFR ブリッジ: 各 NFR をテスト可能な AC に結び付けてください。「Accessible」には具体的なキーボード/スクリーンリーダーの結果が必要であり、リソース制限には、でっち上げの UI 操作ではなく内部測定が必要になる場合があります。曖昧な品質主張については質問してください。

最小限の基準例であり、ドキュメントテンプレートではありません:

1. `R1.AC1` WHEN a lease expires, the system SHALL release its lock.
   - Acceptance check: another holder can acquire a lock after its lease expires.

walden validate --json から ears_validation、ears_distribution、および警告を読み取ります。形式の適切さ、応答の原子性、具体的なイベント、現実的な失敗、NFR ブリッジ、永続性のバランス、およびドメイン固有のギャップをレビューしてください。カウントは診断用であり、ノルマではありません。望ましくない形式がゼロであることは、失敗処理が欠けていることを示している可能性があります。Design の前に通常のレビューループを使用してください。

設計

承認済みの要件を読みます。外部の事実は、意思決定がそれに依存する場合にのみ調査します。標準的な長大なアーキテクチャ文書を挿入するのではなく、CLI が生成する設計スキャフォールドを使用します。

現在のカーネルでは、ちょうど 6 つの見出しが必須です:

• アーキテクチャ
• 検討した選択肢
• シンプルさとエレガンスのレビュー
• 失敗モードとトレードオフ
• 検証計画
• 要件カバレッジ

その他のセクション — コンポーネント/インターフェース、データモデル、エラー処理、セキュリティ、テスト戦略、図 — は、関連する意思決定、コントラクト、または検証ニーズに応じた任意の拡張です。網羅性を示すために空のセクションを追加しないでください。

実際の代替案と比較します。意味のある代替案や議論が当てはまらない場合は、複雑さをでっち上げるのではなく、一行の理由を示します。要件カバレッジと検証計画には、依然として実質的なマッピングとチェックが必要です。当てはまらないことは、それらを省略する理由にはなりません。

最初のドラフトに一度異議を唱えます: よりシンプルな形やより少ない結合で、同じコントラクトを満たせるでしょうか? 実際の失敗モードと受け入れたトレードオフを記録します。カバレッジテーブル内のすべての要件/NFR ID をバッククォートで囲みます: バリデータは | `R1` | ... | のような行を期待します。

設計が新しいスコープや欠落した受け入れ動作を明らかにした場合は、要件に戻ります。そうでなければ、タスクの前に検証し、レビューループを使用します。

タスク

承認済みの要件と設計を読みます。作業はインクリメンタルかつテスト可能に保ち、階層は最大 2 レベルとします。各実行可能なリーフは、その AC ID、設計参照、検証ステップを明示します。コピーした完全な計画ではなく、正規のスキャフォールドと以下の最小限の構文を使用します。

- [ ] 1. Implement and test the behavior
  - Requirements: `R1.AC1`
  - Design: Architecture
  - Verification:
    - command: ["go", "test", "-v", "-count=1", "-run", "^TestExample$", "./pkg/example"]
      expect_output: "--- PASS: TestExample"
      covers: ["R1.AC1"]

トップレベルのリーフメタデータは 2 スペースを使用し、子タスクは 2 スペースのタスクインデントと 4 スペースのメタデータを使用します。証明ステップは Verification: より 2 スペース深く、属性はそのコマンドより 2 スペース深く配置します。

証明は、すべてのチェックボックスに対して同じ広範なスイートを実行するのではなく、基準の妥当なグループに割り当てます。すでにグリーンなスイートは、新しく導入された動作の証明にはなりません: 各実装リーフは、完了する前に、対応する新しいアサーションを含めなければなりません。変更されていない古い PASS マーカーで新しい AC を主張しながら、それらのテストを後のリーフに先送りしないでください。意図したチェックが存在する前には通らない、直接的なアサーションまたは新しいテスト固有のセレクタ/マーカーを使用します。AC をアサートする証明ステップは、それらを covers: で明示しなければなりません。順序付けが、欠落したインターフェースやテスト不可能なステップを明らかにした場合は、設計に戻ります。検証し、タスク計画の承認を要求します。その後、明示的な実行も要求されていない限り停止します。

証明の作成

タスク計画を提示する前に:

1. 実際のアサーション: すべてのステップには明示的な合格条件があります。終了コードがゼロであることだけが有用なのは、そのコマンドが意図したプロパティを実際にアサートしている場合だけです。
2. 非空であること: 意図したテストがゼロのまま合格する実行を防ぎます。ネイティブのテストなし時失敗の挙動、構造化されたテスト結果、または適切な出力アサーションを使用してください。Go の -run は何にも一致せずに成功する可能性があります。アンカー付きのセレクター、-v、-count=1、および上記で示した名前付き PASS 出力を使用してください。
3. 読み取り専用の再検証: アサーションはワークツリーを変更してはなりません。go mod tidy よりも go mod tidy -diff を優先し、ビルド/ジェネレーターの出力はリポジトリの外にルーティングしてください。ファイルの欠落やアサーションの失敗を、その証明によって「修復」してはなりません。
4. 実行時間の上限: 各ステップにはデフォルトで 10 分のタイムアウトがあります。正当な理由で異なる予算を使う場合は、timeout: 30m のように正の timeout: を宣言してください。期限切れはステップの失敗となります。
5. 宣言されたカバレッジ: covers: は、そのコマンドが意味的に十分であるという約束ではなく、アサート済みの既知の AC ID を指定します。タスク参照と証明参照のカバレッジは別々に確認してください。
6. 再現可能な条件: 既知の入力と関連する環境プローブを使用してください。承認済みの証明を弱めることで環境の失敗を隠蔽してはなりません。

コマンドは JSON の argv 配列であり、暗黙のシェル解釈なしで実行されます。パイプ、リダイレクト、演算子には明示的なシェルが必要です。たとえば command: ["sh", "-c", "test -d src && test -f src/main.go"] のようにします。真にネガティブなアサーションには expect_exit: 1 を使用してください。expect_output は結合された出力の部分文字列であり、正規表現ではありません。複数ステップの証明は最初の失敗で停止します。

従来の 1 行形式 Verification: go test ./... では、クォート、シェル演算子、属性を表現できません。新しい作業には構造化されたステップを使用してください。承認済みの証明を、許可された改訂と再レビューのサイクル以外で後付けで変更しないでください。

実行とリカバリ

明示的に承認されたタスクまたはバッチについて:

1. 承認された 3 つのドキュメントを読みます。準備状況とコンテキストには task status と task start を使用してください。未承認または古い計画を決して実装しないでください。
2. 承認されたバッチスコープとその検証チェックポイントを宣言し、焦点を絞ったテストで実装します。要求されていない限り、または承認された検証計画に含まれていない限り、フルスイートを実行しないでください。タスク/バッチが特定されなかった場合は、次のタスクを解決し、実装前に確認してください。
3. 手動チェックボックスではなく、task complete を通じて完了します。CLI は完了状態を進める前に証明を実行し、エビデンスを記録します。コンテナの前に子を完了してください。
4. コミットが承認されており、プロジェクトポリシーが許可している場合にのみ、作業とともにエビデンスをコミットします。このスキルは、コミット、PR の作成、タグ付け、公開の許可を与えるものではありません。
5. エビデンスの警告を確認しますが、編集後の通常のリポジトリ全体の古いコードは、完了したすべてのプレフィックスを再生する理由にはなりません。変更された依存関係、失敗した証明、またはコントラクトのギャップに対しては、対象を絞ったチェックを前倒ししてください。それ以外の場合は、宣言されたバッチ、フィーチャー、またはデリバリーチェックポイントで再検証を集約します。各リーフは依然として独自の完了証明を得る必要があります。中間の一時停止では、バッチと残存する古さを明示的に保ちます。クロージャでは、最終的なスコープ付き検証の前にコード、README、その他の成果物を完成させ、その後リリース判定を確認し、延期されたギャップを報告します。

TDD は開発順序を表すものであり、合格する証明ではありません。TDD が要求される場合、振る舞いを実装する前に、実行可能な振る舞いのアサーションが失敗することを確認します。最小限のコンパイル可能なスキャフォールディングは問題ありません。コンパイル/インポートの失敗や、PASS という名前の出力は、その順序を確立するものではありません。コードがすでに存在する場合は、後から追加されたテスト、またはテスト駆動の修正を正確に報告してください。遡及的な TDD をでっち上げるために既存のコードを壊して復元しないでください。ミューテーションテストは別途ラベル付けしてください。

ドキュメント本体の編集は承認シールを破壊します。reconcile は影響を受ける承認状態をリセットします。変更されたチェーンを再度レビューしてください。同一内容の再承認は、下流のコンテンツを古くしません。欠落しているレガシーフィンガープリントには、手書きのシールではなく、採用または調整が必要です。

完了は正当にジェネレーターを実行し、結果のツリーを記録できます。再検証は異なります。その証明は読み取り専用です。verify --check はレジャーへの書き込みを防ぐものであり、コマンドの副作用を防ぐものではありません。検出されたミューテーションまたは欠落している必須 ID はその実行を汚染します。バイトが復元されたとしても、その後の実行で検証済みエビデンスを得ることはできません。指名された原因を調査してください。承認された証明の修復/再レビューの後は、影響を受けるスコープの新しいクリーンな検証を使用してください。ユーザーソースを自動的にロールバックしないでください。

エビデンスの状態は導出されます: verified、stale-spec、stale-code、failed、unattested、unrecorded、pending。バインディング、コードの鮮度、実行整合性のプロベナンスを個別に、状態の優先順位によって隠されたギャップも含めて確認してください。unattested は、必要な保証が欠落していることを意味し、新たに観測されたコードの失敗ではありません。記録された passed は現在の検証には不十分です。意図されたコントラクトの変更には、影響を受けるレビューサイクルと新しい証明が必要です。コードのみのメンテナンスでは、新しいスペックを作成する必要はありません。変更されていないバイトをコミットしても、それ自体でコードエビデンスが古くなるわけではありません。原因を推測するのではなく、CLI が報告する差分を使用してください。

環境コンテキスト

オプションの .walden/environment.md プローブは argv を使用します。たとえば - go: ["go", "version"] や - node: ["node", "--version"] です。名前は小文字のケバブケースです。platform と walden は予約済みのプロファイルキーです。プローブは 30 秒の予算を共有します。不正な宣言はエビデンスを生成するコマンドを失敗させます。失敗したプローブまたはタイムアウトしたプローブは、診断用のマーカー値を返します。

プロファイルは診断用であり、状態ゲートでもプロデューサーポリシーの証明でもありません。コードを責める前に環境のドリフトを比較してください。バージョンの不一致を隠すためにアサーションを弱めてはいけません。リクエストが環境プローブを禁じている場合は、evidence status ではなく読み取り専用の adopt <feature> 評価を使用してください。

採用と廃止

adopt は既存の Walden 仕様を評価するものであり、任意のコードベースを仕様へ変換するものではありません。現在のコントラクトを確立した後、その非実行プランを提示してください。backfill、re-prove、complete、blocked は技術的な分類であり、ビジネス上の適用可否ではありません。復元されたバインディングは、過去の実行の純粋性を証明するものではありません。complete は採用するものが何もないことを意味し、すべてのプロダクト作業が実装済みであることを意味しません。アップグレードや検査によってポートフォリオが自動的に再実行されることはありません。

Backfill は記録された承認を信頼し、現在の本文を封印します。その間に指紋採取前の編集が行われた場合、検出できないことを開示してください。現在の矛盾には人による調整が必要です。Apply は実際の証明を実行します。レビュー済みのスコープに対してのみ要求し、フィーチャーセレクターを保持してください。新しい v1alpha2 の台帳には、手つかずのレガシーレコードが含まれる可能性があります。互換性のある CLI を使用し、古いリーダーを満足させるためにエビデンスを削除したりダウングレードしたりしないでください。

利用可能な場合は、採用のワークロードをテストや ETA ではなく、宣言されたステップとして読んでください。利用不可のフィーチャーは既知のゼロとは別であり、カウントは実行を許可するものではありません。適用後は、タスクごとの診断を保持し、受け入れられた実行（passed）、最終状態、整合性を個別に読んでください。evidence_persisted: false は、観測された結果が保存されなかったことを意味します。試行前のフィーチャーエラーは、タスク結果を生成しません。elapsed_ms は現在の試行またはそれを囲むフィーチャー/呼び出しを測定するものであり、過去のコストではありません。これらのフィールドは古い互換 CLI では存在しない場合があります。存在しないことはゼロではありません。リダイレクトされた診断はコマンド出力を含む可能性があるため、保護してください。Walden は自動ログやタイミング履歴を追加しません。診断の再実行を提案する前に、利用可能な失敗理由を確認してください。

廃止には明示的な確認が必要です。削除する前に、Git が各仕様/エビデンスファイルを復元可能な最後のライブコミットで保持していることを確認し、理由と後継を特定し、存続する要件があるべき場所について合意してください。履歴が見つからない場合、または未解決の混在したコントラクトがある場合は、停止してください。復元を捏造したり、承認されていないコミットを作成したりしないでください。履歴のない削除を、Walden の廃止と同等のものとして、またはその復元の前提条件の放棄として提案しないでください。その後、承認されたファイルのみを削除し、名前、日付、理由、最後のライブコミット、後継を .walden/RETIRED.md に記録してください。オプションの walden-history コンパニオンが支援できますが、必須ではありません。また、廃止はコミットや公開を独立して承認するものではありません。

統合

数十の仕様を経てから監査するのではなく、小さなステップでポートフォリオの一貫性を保ちます。status は、統合が推奨または期限到来したとき、つまり承認済み要件が最後の統合以降に変更された仕様が 2 件および 3 件あるときに警告します。feature init と release check は、ブロックせずに期限到来の警告を繰り返します。インストール済みの CLI で walden consolidate --help が利用できない場合は、このセクションをスキップしてください。

統合が推奨または期限到来したとき、あるいはユーザーが依頼したときに、walden consolidate を実行します。.walden/contracts.md と、報告されたスコープ内の機能のみを読みます。広く引用されるファイルを通じてのみリンクされた機能については、通常はそのビューエントリで十分です。次に、レポートの比較で追加、変更、削除されたすべての記述を、その横にレポートが示すリンク済みの記述と比較します。削除または変更された記述への依存、重複したルール、矛盾をそれぞれ、両方の修飾識別子とともに報告します。比較が確認すべき材料であるため、無関係な仕様を完全に読む必要はありません。結果を .walden/contracts.md の ## Coherence Review に記録します。保留中の機能ごとに ### <feature> エントリを 1 つ設け、見つかった不整合、または不整合なしを記述し、比較したリンク済みの記述をインラインコードで feature#ID として引用します。エントリが欠落しているか、空であるか、それらのいずれも引用していない場合、CLI はビューのオープンまたは承認を拒否します。重複、矛盾、他所で依然として引用されている削除、および陳腐化した義務を探し、それぞれを修飾識別子とともに報告します。決定論的な検出結果は手がかりであり、判定ではありません。

すべての修正は、影響を受ける仕様の通常のレビューパスを通じた改訂として提案します。統合はいかなる他の作業も許可しません。統合の一環として何かを承認、廃止、実行してはなりません。次に、スコープ内の機能のビューを更新します。Purpose: (今日その機能が保証する内容についての 1 行)、Active: (レポートが列挙する識別子)、Reserved: (削除された識別子。予約済み識別子はそのまま列挙し続けます)、Sources: および Related: です。walden consolidate open を実行してビューを提示し、ユーザーの明示的な承認後のみ walden consolidate approve を実行します。status がビューを陳腐化していると報告した場合は、それをレビューして walden consolidate open を再度実行します。記録とレビュー状態は CLI が所有します。.walden/consolidation.json やビューのフロントマターを手作業で編集しないでください。

既存のポートフォリオでは、walden consolidate start が今日の承認済み仕様を未統合のバックログとして記録します。バックログの機能は、ユーザーが依頼したときに小さなバッチで統合し、決して一度にすべてを統合しないでください。

リリース判定

リリース可否や納品の引き継ぎについて尋ねられた場合は、release check を使用してください。個別のステータス概要から判定をでっち上げないでください。このコマンドは既存の状態を判定し、決して公開しません。証拠は別途 verify で作成します。

保留中の作業はデフォルトでブロックします。ユーザーが承認した部分的な納品では --allow-pending --reason "..." を使用できますが、欠落しているレガシー保証や厳密な入力バインディングを免除することはありません。--strict は、無視されたファイルも含め、実際に判定された仕様/証拠のバイトと存在を 1 つのキャプチャされたコミットと比較します。非厳密な出力は、ローカルメタデータがコミットされていることを主張しません。未コミットのコードにバイパスはなく、使用可能な git が必要です。

スコープ、保証、ブロッカー、完了クラス、コミット、免除を正確に報告してください。選択された機能の合格は、リポジトリ全体の証明ではありません。未分類/未評価の機能は、ポートフォリオ全体の主張から消えることはできません。除外には、明示的なスコープ選択または承認された廃止が必要です。参照カバレッジや保存された合格を形式的な正しさと同一視しないでください。

レッスンとサマリー

類似の作業の前に、関連するレッスンを確認してください。ユーザーによる修正、却下されたドラフト、検証の失敗、再計画、または予期しない実行失敗は、再利用可能なレッスンに関する内部的な判断を促します。意味のあるパターンは walden lesson log で記録してください。トリガー、レッスン、および繰り返しを防ぐガードレールです。通常想定される TDD のレッドテストを、でっち上げた誤りのリストに変えてはいけません。

観察されたトリガーを正確に記述してください。ユーザーが最初に A+B を要求し、その後 A だけを残した場合は、「エージェントが B をでっち上げた」ではなく「スコープが A+B から A に狭まった」と記録してください。2 つの振る舞いがすでに別々であった場合、それらが 1 つの AC を共有していたと主張してはいけません。レッスンは事実と有用なガードレールを保持するものであり、でっち上げた誤りではありません。トリガーについては、実際の機密性のないスコープ明確化を引用するか、厳密に言い換えてください。「要求された」は「承認された」ではありません。ユーザーは、誤りが一切発生していなくても予防的なレッスンを要求することがあります。その場合は失敗の話を再構成するのではなく、予防的であるとラベル付けしてください。

新しく記録されたレッスンには、その実用的なガードレールを伴う短いユーザー向けのエントリが付きます。新しいレッスンがない場合は、レッスンステータスの出力を完全に省略してください。内部的な判断は依然として行われます。

サマリーには、何が変更されたか、実際に何が確認されたか、未解決のブロッカー、および次に必要なユーザーの判断を記載する必要があります。計画済み、実行済み、失敗、未実行のチェックを区別してください。簡潔にし、現在のフェーズの承認を、後のフェーズや公開の許可と混同しないでください。