Urazuke、裏付けの方法 — 方法論のはしご（第4版）

著者：Pablo Kuschniroff、Claude Codeの支援による。第4版、2026年10月18日に始まり、記録（docs/DECISIONES.md）のその後の決定ごとに更新され続けている。開始日はわざと固定したままにしてある。新しい決定がこの文書に触れるたびにバージョン履歴を書き換えずに済むように。これは作業文書で、これを使う各プロジェクトとともに磨き続けるつもりだ。ここに書かれていることはまだ何一つ閉じた教義ではない。とはいえ、私の知る限り、既に三つの本番システムを背負っている方法の最初の誠実な蒸留ではある。

本題に入る前に、どう書かれているかについて一言。重要だからだ。これらのプロジェクトを私とともに経験していない人のために書いた：人工知能でソフトウェアを構築し、そのソフトウェアが長持ちしてほしい人であって、プログラミングを学びたい人でも、プロンプトのコツを集めたい人でもない。だから説明に時間をかけ、必要なら繰り返し、日常の言葉を使い、末尾に私の口からこぼれるすべての略語と口語表現を収めた用語集を置いた。どこかで見慣れない言葉に出くわしたら——「ラチェット」「錠」「フェイルクローズド」「PND」——用語集へ。すべてそこにある。そして Ref. 26 のような印を読んだら、それは参照文書で語る実際の事例への近道で、日付と証拠が付いていると知ってほしい。流れを失わずに無視することも、詳細に関心があれば辿ることもできる。

方法の公開リポジトリは github.com/pkuschnirof/urazuke。そこにこの文書、各段の契約、コースのマニュアル、参照文書が、NAC3の八言語である。

名前

Urazuke（裏付け）は、ある主張が持つ根拠、それを背後から支えるもの（文字通り「裏の当て布」）を指す日本語だ。動詞*裏付ける*は「証拠で支える」。2026年10月17日に、既存の企業やプロジェクトとの衝突でいくつかの名前を除外した後にこれを選んだ。選んだのは、方法が求めることをそのまま言っているからだ：モデルのすべての主張がその裏付けとともに来ること、そしてその裏付けがコードを読まずに検証できること。名前は翻訳しない。副題「裏付けの方法」は翻訳する：*the evidence method*、*o método da evidência*、*la méthode de la preuve*、*die Nachweis-Methode*、*il metodo del riscontro*、裏付けの方法、验证方法。この文書で「はしご」は方法の構造——その二十四の段——を指し、「Urazuke」は方法全体を指す。

何についてのものか

何を教えていて何を教えていないかについて、明確でありたい。ツールを教えているのではない。 方法を教えている：何をどの順でするか、各時点でモデルに何を頼むか、何を納めてもらうべきか、そしてコードを読まずに、納められたものが完全だとどう知るか。賭けているのは、誰でも、プログラミングに使える人工知能ツールなら何でも使って、手でコードを打つ代わりにモデルと会話してソフトウェアを構築でき、出てくるものが堅牢で、本番運用の準備ができていて、そしてここが重要だが、プロジェクトのオーナーがコードを一行もレビューする必要がないことだ。そして、これが何でないかについても同じく明確でありたい。これはシステムをより速く作るためのプロセスではない。誰もそのコードを一ビットも理解する必要なく、運用可能で保守可能なシステムを作るためのプロセスだ。コードを理解し保守するのは、それを書くエージェント的な枠組みだからだ。速度は、現れるとすれば、結果である。だからこの文書には期限がない：各システムの大きさと複雑さが期間を決め、方法は順序だけを決める。

ここで明確にしておきたいことがある。前の文が、私の意図とは違う読み方をされかねないからだ。「所有者がコードを一行も確認する必要がない」ということは、「システムの知識がない人がプログラムを組めるように設計されている」ということと同じではない。そうではない。この方法の第一の目的は、誰でもソフトウェアの作り方を何も知らずにソフトウェアを作れるように技術的なハードルを下げることではない。システムに責任を負う人に、モデルが作るものが、誰も書面で要求しなければモデルがその同じ原則を脆く適用してしまう弱点に対抗しながら、昔ながらのシステム工学の堅実さで仕上がるような、方法論的な支えを与えることだ。所有者がコードを読まないのは、ゲートをどこに置いたか、そして人間が実装を読まずに何を検証できるかの結果であって、誰であろうと、何を知っていようと、自分が指揮しているものを何も理解せずにソフトウェアプロジェクトを指揮できるという約束ではない。契約が実際に求めている人物像はその中間にある：コマンドを実行でき、認証情報を扱え、バックアップを復元でき、CIのクォータが何を言っているか理解でき、モデルが渡したものが足りないときにそれを見分けられる人だ。純粋な素人でもなければ、すでにプログラムが組める人でもない。

そしてもう一つ、コストについての明確化。この段階を踏むことは、モデルに一度ですべてを解決させるよりも多くのトークンを使う：各段が、プロンプトと、それ自体の検証と、モデルが維持しなければならない成果物を一つずつ増やすからだ。一目では見えないのは、それがどれだけ節約になるかということだ。これらのゲートなしに作られたシステムは、遅かれ早かれ、作り直しを必要とする傾向がある：やっていなかったサイジングをやり直す、段8で赤いテストが捕まえていたはずのバグを追いかける、誰も時間内に監査しなかったものを書き直す。その作り直しは、トークンでも、時間でも、お金でも、各段がかかる余分なプロンプトよりもはるかに高くつく。私は先に、頭を使って使う。後で盲目的に二倍使わないために。

野心的に聞こえるし、実際そうだ。だが私にはほとんど誰も持っていないものがある：まさにそうやって構築し、今日本物の顧客とともに動いていて、続くすべてのルールをそこから抽出した三つの実在のシステムだ。だから私が自分に問うのは「できるだろうか」ではない。もうできたからだ。問いは「何を、どの順でし、そのうち何が本当に違いを生んだのか」だ。このはしごがその答えであり、三つのものの基盤だ：方法の文書、コースの受講生が行う実践、そしてマニュアル。後には私のツールの中に実行フローとして輸出し、人の記憶ではなくツールが方法を導くようにする。

方法の出所、そして誤解されたくないこと

これらすべてには、定着する前に解体しておきたい安易な読み方がある：方法は、痛手のたびに私が当てていったパッチの寄せ集めだ、というものだ。そうではない。正確に言うことが重要だ。各段の読み方を変えるからだ。

方法は組み合わさった二つの要因から生まれ、どちらか一方だけでは足りない。第一はシステム工学についての私自身の知識だ。システム畑の人なら誰でもすぐわかることを、私は長年適用してきた：設計の前の調査、書かれた要件、数字によるサイジング、設計、構築、証拠としてのテスト、再現可能なデプロイ、運用、定期監査、プロダクトの一部としての文書。二十四の段で私が要求することの大半は、よく運営されたプロジェクトで常に要求してきたことだ。モデルのために発明したのではない。以前から持ってきた。

第二の要因は、この五か月のインシデントが次々と私に見せたもの：モデルがそれらの原則を脆く適用する場所だ。モデルはテストとは何か、根本原因とは何か、サイジングとは何かを完璧に知っている。聞けば多くのエンジニアより上手に説明する。だが実践では、テストしたと言ってテストしておらず、事業だけが持つデータを自信ありげな顔で推定し、事業ルールの穴を妥当に思えたもので埋め、役に立つよう訓練されたために過剰に報告し、気づかずに嘘をつく計器を作る。 参照文書で語るそれぞれの事例が、どこを締めるべきかを正確に教えてくれた：私にとって自明だった原則が、どこでプロンプトの明示的な条項、ゲート、私がコードを読まずに行う検証に変わる必要があったか。

だから、ある段で「これはあのインシデントの後に課した」と言うとき、原則がそこで生まれたと言っているのではない。そこでモデルが独りでは適用しないことを確かめ、書面で要求しなければならなかったと言っているのだ。方法は昔ながらのシステム工学を、疲れず、証拠なしには信じることのできない構築者に必要な硬さで適用したものだ。傷跡はどこに硬さが必要かの証明であって、原則の起源ではない。

方法の三つのユースケース

先へ進む前に、以前の版にはなかった分岐を一つ。ある読者がもっともな理由で求めてきたものだ。この文書は空のフォルダを見ながらはしごを記述している：第0段はプロジェクトに取り組むかを決め、第4段は機能のない骨組みをデプロイし、第5段が最初のブロックを開く。学ぶには最も明快な場合であり、最も頻繁な場合ではない。方法には三つのユースケースがあり、エージェントを開く前にどれにいるかを知っておくとよい。どこから入るかが変わるからだ。

1. 新規プロジェクト。 空のフォルダと依頼を持つオーナー。第0段から入り、二十四を順に登る。この文書が、その契約とコースのマニュアルとともに記述しているものだ。
2. 方法で作られたシステムへの進化・修正。 システムは既にはしごを登っている：契約、地図、証拠付きで閉じた保留項目、テスト群、デプロイ、マニュアルがある。第5段から、ブロックを開いて入り、ループを辿る。第13段は定期的に。第23段は各段階の締めに。タイムラインのフェーズ4 （パートB）だ。
3. 方法なしで作られたシステムへの進化・修正。 動いていて、ユーザーがいて、他人または証拠なしの自分自身が作った、修正するか成長させなければならないシステム。第0段からも第5段からも入らない：八つのステーション（N0からN7）の正常化の区間から入る。それは立ち上げの段が生むすべての入力を自動発見で、出所の印付きで復元し、システムを書き直さずにその周りに安全ベルトを組み、そのうえでようやく修正モードか進化モードでループを開く。その道は独自のページ、進化・修正の道にあり、二つ目のガイドプロジェクトを伴う独自のコースのパートを持つ。

名指ししておく、外に残るもの：技術の移行は方法のユースケースではない。それは別のプロジェクトであり、一般には第0段の排除基準に当たる。

AIは方法を中断しない。方法を継続する

これがすべてを開くテーゼで、最初に置くのは、最もよくある反論が現れる前に解体するためだ：「機械が書いたコードをどうやって信用するのか」。

私の答えは、業界は既に二十年前にコードの書き手を信用することをやめたということだ。執筆の大半がジュニア、外注、ローテーションのチームに移ったとき、一行ずつのレビューは維持不可能になった。その代わりに育ったのが、今日我々が当然視するすべてだ：自動テスト、継続的インテグレーション、受け入れ基準、緑なしには何も通さないパイプライン、テストの「シフトレフト」、独立した機能としての品質管理。それが「書く者は信用できない」に対するシステム工学の答えだった：コードを読まず、証拠を要求する。

だからモデルに書かせることは、虚空への跳躍ではない。もう信用していなかった書き手を、やはり信用しない別の書き手に換えることであり、その書き手のために検証の装置は既に組み上がっていた。これは安心させるべきことで、不安にさせることではない。しかも新しい書き手はより安く、より速く、そして——ジュニアと違って——赤で証明しろと頼んでも気を悪くしない。

だからこの方法は、隠すことなく古典的なシステム工学に依拠する。骨格はいつものものだ。他にありようがない。問題がいつものものだからだ：データがどれだけあるかわからない、顧客が何を望むかわからない、構築したものが頼まれたものかわからない。AIは問題を変えなかった。誰が各部分をどのコストでやるかを変えた。第0段の適格性基準X2でさえ古典工学だ：契約の条件としてのテスト可能性。

ここで何が古く、何が新しいか

古いもの、そして古いと言っておくべきもの：段階の骨格、検証者の構築者からの独立、証拠としてのテスト、プロダクトの一部としての文書、設計前の調査。

本当に変わるもの、私の貢献があるところは三つだ：

1. 人間の努力がどこへ行くか。 古典的方法では人間が仕様を書き、コードを書き、別の人間がそれをレビューする。ここでは人間は二つのことだけをする：決定し、成果物を検証する。それ以外のすべて——起草、構築、テスト、計測、文書化——はモデルがする。だから各段は「コードを読まない完全性の検証」で終わる。それが人間が依然として不可欠である正確な場所であり、それ以外にはない。

2. 書き手が証拠も作る。 これが唯一の本当に新しい点であり、三つの段まるごとを正当化するニュアンスだ。ジュニアは怪しいコードを書いたが、証拠は作らなかった：テストと計測は別の誰かが組み、少なくとも別の誰かが見た。モデルは対照的に、コード*と*テスト*と*計器*と* 報告を、同じセッションで、正しいときも間違っているときも同じ自信のある声で作る。私は見た：二度嘘をついた計器 Ref. 36、「成功」と報告された認証エラー Ref. 43、四つのうち三つが間違っていた主張。だから「コードの代わりに証拠をレビューする」は依然として正しい原則だが、証拠は自身を証明しなければならない：赤で見たテスト（第8段）、ガード付きの計器（第7段）、検証済みと信じていることを分ける報告（第12段）、構築者とは別の監査者（第13段）。新しい懸念ではない：品質管理の独立という同じ規律を、一歩内側に持ち込んだものだ。

3. 成果物のコスト。 古典的方法では文書は高価で、だから一度作られて古びた。ここでは再生成は無料で、だからルールは「同じコミットで」「AIなしで手で再現可能」になる。かつて達成不可能な理想だったものがゲートになる。

コースと公開のために、これが誠実にポジショニングを定める：「新しいプログラミングの仕方」ではない。疲れず、しかし信じることもできない構築者に適用されたシステム工学だ。システム畑の人には馴染み深く響き、不信を下げる。バイブコーディング畑の人には持っていないもの、まさに骨格を与える。そして速度を売り骨格をまるごと省くツールから私を差別化する。

パートA — 各段の読み方

各段には八つの部分があり、比較できるよう常に同じだ：

• 意図：何を目指すか、一文で。
• いつ：プロジェクトのどの時点で登るか、一度登るか繰り返すか。この部分は第4版で新しく、パートBで詳しく説明する。タイムラインのない方法は善意のリストだからだ。
• 入力：登るために何が先に存在しなければならないか。
• 成果物：登ったときに何が書かれ、または実行可能なものとして残るか。常に具体的なもの：ファイル、テスト、スクリプト。
• ゲート：次へ進むために何が真でなければならないか。満たされなければ登らない。
• 誰が決めるか：プロジェクトのオーナー、エージェント、または自動なので誰でもない。
• 防ぐ失敗：段が防ぐ種類の問題、それを確かめた実際の事例への短い参照付き。
• 契約：どう実行するかが書かれたファイル：文脈、プロンプト、成果物、検証、警告サイン。

そして六つの段にだけ現れるもう一つの部分がある。読むべきものを変える横断的な部品だからだ：附属書H（ANEXO_HEURISTICAS.md）。検証可能な四十五のルール——コード品質の十八と使いやすさの二十七——で、それぞれが安定した識別子、重大度、それを測る道具を持つ。任意の付録ではない：義務だ。そして六つの点で梯子に掛かる。第2段ではその二つの前提入力が入る（ユーザー用語集とプロフィール一覧：人々が実際に各々のものを呼ぶ言葉と、それぞれが誰で何をしに来るのか）。そして第5、8、9、10、12段にはその五つの アンカーがある——「アンカー」とは、附属書の部品がなければその段の関門が緑にならないという意味だ。その五つは公開された関門の定義における機械的な要求であり、推奨ではない：方法をコンパイルするツールはそれを求める。その六つの段はそれぞれ自分のカードでリンク付きでそう言っており、どれかが言うのをやめたら赤くなる検証が方法自身の連鎖にある。遅れて気づいたことから生まれた：附属書は義務でありながらこの文書で一度も名前を挙げられておらず、方法を別の形式に翻案した最初の読者は四十五のうち二十七のルールを飛ばした。それらがあると知らなかったからだ。

二つの重要な注意。第一：はしごはツールに対して中立だ。すべての成果物はファイル、テスト、スクリプトであり、どれも私のツールも他のツールも要求しない。Forgeはそれらを自動化する（ゲート、コマンド、保留項目の記録）が、段はForgeなしに存在する。第二：段は登る順に番号が付いている。そして四つの区間にまとまる：0から4は立ち上げで、プロジェクトごとに一度登る。5から12 は変更ごとに繰り返すループ。13から20は本番リリースで、最初のデプロイの前に一度登る。そして 21から23は運用で、システムが既に稼働しているとき。23はサイクルを閉じ、次のプロジェクトのために0へ戻る。区間の中では番号が順序を言い、区間の間では、ループが繰り返される一方で他の三つは一度登られる。だが「厳密に順次ではない」は「どんな順でもよい」ではない：パートBが各段をいつ登り、その間に何が起きるかを正確に言う。

パートB — タイムライン：各段をいつ登り、その間に何が起きるか

この部分は以前の版には存在せず、その不在は深刻な欠陥だった：方法は何をしどう検証するかを言ったが、いつを言わなかった。そして「いつ」は方法の半分だ。文字通りに受け取る読者は二十四の段を次々と登り、ではインフラ、継続的インテグレーションとデプロイの連鎖、要件の取り込み、機能の開発、すべてのフローのエンドツーエンドテスト、画面への人間の目、人間による受け入れテストはいつするのかと自問しただろう。それらすべては起こり、段の間と段の中の正確な時点で起こる。ここに書く。

B.0 プロセス全体を、一枚の図で

表の前に、絵を。プロセス記法（BPMN風：丸いイベント、長方形のタスク、ひし形のゲート、点線の戻り矢印）で描いてあり、表よりうまく三つのことを言う。第一：プロセスは方法の外から始まる。要件工学であり、それは前提条件であると同時に恒常的だ。決して終わらず、新しい要件はそのたびにまた入ってくる。第二：新しい要件はループにだけ入るのではない。評価の段へ再注入される。アーキテクチャを決めた数字を変えうるからだ（「十倍」はまだ耐えるか？）。そしてそこから先へ。第三：プロセスは人によるテストケースの手動実行で終わり（第10段）、その実行が見つけたものは要件としてループへ戻る。円環は機械ではなく、人で閉じる。第四、この修正より前の図にはこれが描かれていなかった：システムが構築するものが世界に結果をもたらす場合（課金する、送信する）、ループは第14段の後に再び開く。すでに鍵がかかった状態で、そこから生産チェーン（15）へ進む前に、その部分をリハーサルモードで構築するためだ。これは最初に戻ることではない。いつもと同じゲート（ブロックの締めくくりか？）を、安全網が整った今、もう一度通るだけだ。

flowchart TB
  subgraph RE["要件工学 · 外部の前提条件であり恒常的"]
    direction TB
    E0(("業務からの依頼")) --> RE1["調査：インタビュー、ユースケース、ドメインモデル、プロトタイプ"]
    RE1 --> RE2["新しい、または変更された要件"]
  end
  subgraph ARR["立ち上げ · 第0段から第4段、一度"]
    direction TB
    P0["0 適格性"] --> P1["1 共働の約束"] --> P2["2 定義とセマンティックツリー"] --> P3["3 サイジング"]
    P3 --> G1{"アーキテクチャは数字に耐えるか？"}
    G1 -- はい --> P4["4 ゲート付きの骨組み"]
    G1 -- いいえ --> P3
  end
  subgraph LOOP["ループ · 第5段から第12段、変更ごとに"]
    direction TB
    P5["5 仕様付きの保留項目"] --> P6["6 書かれた決定"] --> P7["7 計測"] --> P8["8 赤のテストとエンドツーエンド"] --> P9["9 コードの品質"] --> P10["10 手動テストケース"] --> P11["11 対称性"] --> P12["12 誠実な報告"]
    P12 --> G2{"ブロックの締めか？"}
    G2 -- いいえ --> P5
  end
  H1["人によるテストケースの手動実行"]
  subgraph OUT["本番リリース · 第13段から第20段、一度"]
    direction TB
    P13["13 監査"] --> P14["14 錠"] --> P15["15 本番への連鎖"] --> P16["16 可観測性"] --> P17["17 永続化"] --> P18["18 脆弱性"] --> P19["19 性能"] --> P20["20 生きた文書"]
  end
  D(("最初のデプロイ"))
  subgraph OPS["運用 · 第21段から第23段"]
    direction TB
    P21["21 資源の監視"] --> P22["22 エラーの監視"] --> P23["23 常駐と振り返り"]
  end
  RE1 --> P0
  P4 --> P5
  RE2 -. "再注入：数字は変わるか？" .-> P3
  RE2 --> P5
  G2 -- はい --> H1
  H1 -- "発見＝要件" --> RE2
  H1 --> P13
  P14 -. "結果を持つものは、鍵がかかった今、構築される" .-> P5
  P20 --> D --> P21
  P21 -. "逸脱＝保留項目" .-> P5
  P22 -. "エラー＝保留項目" .-> P5
  P23 -. "次の段階のために0へ戻る" .-> P0

図が見えない場合（markdownのビューアがmermaidを描かない場合）、上の文章がそれを丸ごと記述している。HTML版では独りで描かれる。

B.1 プロジェクトの五つのフェーズ

この方法で進められるプロジェクトは五つのフェーズを通る。真ん中の三つはループ、本番リリース、運用の区間に対応するもの。フェーズ1は立ち上げの区間。そしてフェーズ0は初期の取り込みで、それ自体は「段」ではないが方法がカバーするものだ。期間は書かない：求められるものの大きさと複雑さに依存し、書かれた期間は偽の期待に変わるからだ。大きさに依存しないもの、それが順序だ。

この表は新規プロジェクトのものだ。システムが既に存在し、方法で生まれなかったときは、フェーズ0と1が正常化の区間に置き換わる（読み取り、安全ベルト、測って順序を付ける）。それは 進化・修正の道にある。フェーズ2、3、4は同じだ。

ユーザーと帰結のあるプロジェクトで育つのはループ、つまり機能だ。立ち上げ、本番リリース、運用は、小さいシステムでも大きいシステムでも同じ形をしている。変わるのはどれだけ計測しなければならないかであって、何を計測するかではない。

B.2 段と段の間に何が起きるか

ここに欠けていたものがある。各フェーズについて、各種の作業を段に対してどの正確な時点で行うか。表を行で読んでほしい：各行は作業の種類で、各セルはそのフェーズ内でいつ行うかを言う。

強調しておきたい細部がある。バイブコーディング畑の人が最も間違える場所だからだ：すべてのフローのエンドツーエンドテストは最後に一度ではない。三回、三つの規模で行う。各保留項目とともに、その保留項目が触れたフロー。各ブロックの締めに、そこまでに存在するすべてのフロー。そして本番の前に、昇格する正確なバージョンですべてのフロー。三つ目だけをするなら、何週間も誰もエンドツーエンドでテストしなかったシステムで最後に至り、本番リリースは一週間の修正に変わる。

B.3 ループのリズム：典型的な機能ブロック

機能ブロックとは、四つから八つの関連する保留項目の集まりで、一緒になって事業が使える何かをなす：「基本の予約台帳」「リマインダー」「月次レポート」。内側はこう見える：

1. ブロックの開始。 オーナーが散文で、このブロックに何を望むかを語る。エージェントがそれを番号付きの保留項目に、「どう検証するか」付きで変換し、検証可能な保留項目を書くには足りないことを質問する（第5段）。オーナーが優先順位を付ける。
2. 各保留項目。 エージェントがどの保留項目をなぜ取るかを告げる。途中で書かれていない事業ルールが現れたら、止まって質問する（6）。保留項目が数字——いくつのクエリ、どれだけかかるか——に依存するなら、まずテスト付きの計器でそれを計測する（7）。構築する。終わったらこの順で閉じる：赤で証明されたテスト、緑、隣接項目の回帰、そして触れたフローのエンドツーエンドテスト（8）。コードの品質のゲートが緑（9）。人に向けて書かれた、そのフローの手動テストケース（10）。そして変更がシステムの二つの部分間の契約に触れたなら、同じコミットで更新された相手側（11）。報告は検証したことと信じていることを分け、盲点を宣言する（12）。オーナーは報告を読み、画面のスクリーンショットを見る。コードは読まない。
3. ブロックの締め。 テスト環境で完全なエンドツーエンドのテスト群が緑。オーナーまたは信頼できるユーザーがブロックの手動テストケースを実行し（10）、何が起き何が失敗したかを書き留める。各失敗は修正の保留項目としてループへ戻る。ブロックの品質の報告を読む（9）。新しい画面でユーザーマニュアルを更新する（20、同じコミットで）。そのとき初めて次のブロックを開く。

ループの典型的な一日で、方法がオーナーに求めることは小さく限られている：二つか三つの事業ルールの質問に答え、二つか三つの報告を読み、二つか三つのスクリーンショットを見る。それだけだ。それ以上を求めているなら、エージェントが独りで解決できることを聞いているか（第1段）、オーナーがコードを読んでいるか（なら第8段か第12段の何かが機能していない）だ。

B.4 人間の節目

人間、オーナーまたは信頼できる誰かが、システムを見るか使わなければならない瞬間をリストにまとめる。少なく、正確な時点にあり、どれもエージェントに委任できない：

• 立ち上げの終わり：テスト環境のURLを開き、空のシステムを見る。
• 画面に触れる各保留項目とともに：テスト環境の実際のスクリーンショットを見る。
• 各ブロックの締めに：ブロックの手動テストケース（10）をテスト環境で実行し、結果を書き留める。失敗したものは要件としてループへ戻る。
• 本番への最初のデプロイの前：すべての手動テストケースに従った、すべてのフローについての受け入れテスト。
• 第20段で：プログラミングをしない人がテスト環境で復旧マニュアルを追う。
• 本番への各デプロイの後：動いているバージョンが意図したものであることを確かめ、重要なフローを読み取り専用で一巡する。
• 第19段で、最初のデプロイの前：業務の許容を隣に置いて負荷テストの数字を読み、破断点を読む。
• 監視の各サイクルで（21と22）：周期報告をエージェントと読み、どの逸脱とどのエラーが保留項目になるかを決める。

それ以外のすべて——テスト、計測、監査、文書——はモデルがし、人間はコードではなく成果物で検証する。

B.5 要件はどう入るか：調査からセマンティックツリーへ、そして保留項目へ

ここで立ち止まりたい。古典的なシステム工学が最も言うべきことを持ち、バイブコーディングが最も熱心にそれを無視する場所だからだ。要件とはチャットの中の顧客の一文ではない。何十年も前から存在し、前面にモデルがいても依然として有効な方法で処理された顧客の一文だ。モデルは頼めばそれらを適用するのが非常にうまく、頼まなければ非常に下手だからだ。

私が使い、方法が各フェーズで要求する方法：

• オーナーとのインタビュー、自由に、散文で、記録して。フェーズ0だ。完全にしようとはしない：エージェントが何が足りないかを検知するようにする。
• ユースケースまたはユーザーストーリー、事業が名付けられるフローごとに一つ：「受付係が予約を登録する」「患者がリマインダーを受け取る」。それぞれにアクター、トリガー、手順、結果、例外がある。機能ブロックを開く単位だ。
• ドメインモデル：事業のエンティティ、その属性、可能な状態、状態間の遷移。セマンティックツリー（下記参照）の心臓部で、モデルが事業にない状態を発明するのを防ぐものだ。
• ストーリーごとの受け入れ基準、「ある状況を前提に、あることが起きたとき、ならばある結果が見える」の形で。各保留項目の「どう検証するか」に、そして後にエンドツーエンドテストに変わるものだ。
• 画面のプロトタイプ、絵でも。画面の人間による目視はここで、コードが存在する前に始まる。
• トレーサビリティ：各要件を、それを実装する保留項目、それを証明するテスト、それを閉じたコミットまで辿れる。方法ではトレーサビリティは別のマトリクスではない：保留項目そのものであり、その出所と証拠を引用する。

セマンティックツリー。 これらすべてを整理する成果物で、エージェントが毎セッション読む地図だ（第2段）。木であって、リストではない：根にシステム。その下にドメインまたはモジュール。各ドメインの下にそのアクター、プロセス（ユースケース）、状態を持つエンティティ、画面、外部インテグレーション。そして各ノードからぶら下がる、それに触れる保留項目とそれに影響する決定。エージェントが調査から構築し、あなたが修正し、各ブロックとともに育つ。その価値は二重だ：モデルにプロジェクト全体を読まなくても触れるノードの正確な文脈を与え、あなたにはコードを読まずに、エージェントが理解しているシステムが事業が求めたものであることを検証する方法を与える。保留項目がどのノードからもぶら下がらないとき、木が不完全か保留項目が範囲外かだ。どちらも十秒で見える。

詳細な仕様は保留項目に住む。 古典的方法には長い、古びる要件仕様書があった。ここではその文書が分解される：各保留項目が自分の完全な仕様を持ち、保留項目の総和がシステムの仕様だ。よく書かれた保留項目が持つもの：タイトル。ぶら下がるセマンティックツリーのノード。顧客の言葉による、それを生むストーリーまたはユースケース。求められるものの詳細な記述。適用される事業ルール、その決定と日付付き。入出力データ。影響を受ける画面、プロトタイプがあればそれも。境界ケースと例外。受け入れ基準。そしてどう検証するか。エージェントがあなたの散文の依頼から起草し、仕様化できないことを質問し、あなたは構築前にそれを読む。保留項目の仕様を読むことは、あなたがコードを読むことに最も近づく瞬間であり、まさに正しい距離だ。

閉じた保留項目は文書である。 これが円環を閉じるものだ。保留項目が閉じるとき、消されも空のまま保管されもしない：その仕様、それを生んだ決定、閉じたときの証拠（赤と緑の数字、画面のスクリーンショット、計測した数字）、コミット、日付とともに残る。したがって閉じた保留項目のキューはシステムの機能的な履歴だ：何を、なぜ、いつ構築し、どうテストしたか。そこから変更日誌、ユーザーマニュアルの新しい節、そして六か月後に誰かが「なぜシステムはこうするのか？」と聞いたときの答えが出てくる。コースのマニュアルは、第5段のルーチンの一部として、各保留項目の締めに同じセッションでこの文書化を要求することを教える。

パートC — 二十四の段

登る順に並んでいる。運用品質の六つの段（最初のデプロイの前に16から19、後に21と22）は、私が名付けずにやっていたものだ：システムが走っている間に見えること、サイジングした量に耐えること、既知の穴がないこと、そして本番に出た後、誰も怒った利用者から問題を知らされないこと。二つの監視は他のすべてと同じ場所に行き着く：ループへ、修正の保留項目として。初心者の方へ：その六つの契約と、第9段と第10段の契約は、それぞれの言葉を日常の言語で説明する段落から始まり、用語集にはそのすべてが載っている。

そして読み始める前の警告。後になるほど高くつくからだ：二十四のうち六つは、カードが言うことだけでは登れない。第2段は附属書Hの二つの前提入力——ユーザー用語集とプロフィール一覧——を担い、第5、8、9、10、12段はその五つのアンカーを担う。六つそれぞれが自分のカードの末尾で、附属書Hで始まる行でそう言っている。方法を適用するなら、第5段を開く前に附属書を読むこと：あなたの関門の五つはそれなしでは緑にならず、関門に止められてから気づくのは最悪の気づき方だ。

ステップ 0 — このプロジェクトはこの方法で取り組めるか？（適格性）

すべてに先立つものがあり、どのリポジトリにもない。常に既に決まった状態で届いたからだ： プロジェクトにこの方法で取り組むかどうかの決定だ。何か月も私の頭の中に住んでいた基準で、書き終えつつある。二つの排除基準は既に明確で、受け入れたプロジェクトではなく断ったプロジェクトから来ている Ref. 46：「否」は「可」よりも境界をよく定める。重み付け基準はまだ較正中で、そう印している。

• 意図：リポジトリを開く前に、プロジェクトにこの方法で、エージェントを前面に、取り組むか否かを決める。耐えられないプロジェクトに入れば、方法は「AIでプログラミングする」に退化し、そこでこそオーナーはコードを読む羽目になるからだ。
• いつ：一度だけ、他の何よりも前に。システムが既に存在するなら、この段はレガシー向けの版で登る（進化・修正の道のステーションN0）。基準が四つ多く、X2は画面ごとに測る。
• 入力：顧客の依頼、事業のドメイン、データ、技術、利用可能な環境、誰がオーナーになるか。
• 成果物：一ページの適格性シート、評価された基準と決定付き：可、不可、または条件付き可。
• ゲート：排除基準がすべて緑で、重み付け基準の得点が閾値（まだ定義していない閾値）を超える。
• 誰が決めるか：オーナー。今日は私。方法によって別の人が同じシートでそれを決められるようにするのが狙い。
• 防ぐ失敗：エージェントが自分で検証できないプロジェクト、または決定するドメインのオーナーがいないプロジェクトに入り込み、人間が一行ずつコードをレビューする羽目になること。
• 契約：peldanos/peldano-00-elegibilidad.md。

二つの排除基準。

ツール中立性にとって金に値する明確化：NAC3（画面をプログラムから操作できるよう私のツールが使うプロトコル）は条件ではない。今日私がそれを達成する手段だ。中立な基準はこうなる：インターフェースをプログラムから実行でき、画面の各要素にその各種の操作（クリック、入力、状態の読み取り）でアクセスでき、テストが画面を辿ってバックエンドへの効果を検証できる。インターフェースが「ドライバ」（例えばPlaywright）に要素を露出しない技術は、リポジトリがあっても外に残る。

そして重要だと思う読み：根本的にはX1とX2は同じ条件を二つの側から見たものだ。エージェントはエンドツーエンドで自分を検証し、証拠をリポジトリに残せなければならない。X1は「証拠はどこに残るか」の半分、X2は「証拠はどう作られるか」の半分。

仮説 重み付け基準、まだ重みなし。 方法を最初から最後まで使う最初のプロジェクトで較正するまで、仮説として印しておく。

以前の版にあった二つの基準（エージェントが単独でテストできること、プロジェクトが新規または監査可能であること）は、それぞれX2とX1に吸収した。帰結であって別個の基準ではないからだ。

ステップ 1 — 共働の約束（コードの前のルール）

一行も書く前に、あなたとエージェントがどう働くかを書面にすること。形式的に見えるが、そうではない：最初の月の苛立ちの八十パーセントを防ぐものだ。エージェントは毎朝昨日の記憶なしにやってくると考えてほしい。書かれていないことは毎回繰り返さなければならず、毎回少しずつ違う言い方になる。

• 意図：最初の一行のコードの前に、人間とエージェントがどう働くかを定める。
• いつ：一度だけ、適格性の直後。痛手がそれを求めたときに見直す。
• 入力：プロジェクトからは何もない。最初のファイルだ。あなたから：あなたの働き方の好み。
• 成果物：品質基準の文書、最低限以下を言う：人間の時間は神聖（エージェントが自分で解決できることには使わない）。技術的負債ゼロ、つまり何かが壊れたら根本から直し、同じセッションで回帰テストを加える。範囲は正確に、頼まれた以上でも以下でもなく。ユーザーの言語で話す。文書は同じコミットで更新する。そして、やっていないことを決してやったと告げない。
• ゲート：約束がリポジトリにあり、毎セッション読まれる。
• 誰が決めるか：オーナー。エージェントは変更を提案できるが、独断で約束を編集しない。
• 防ぐ失敗：良い考えに思えたからと範囲を広げて「助ける」エージェント。「後で」のために負債を残すエージェント（後では決して来ない）。そしてやったと*思う*ことをやったと報告するエージェント。私が初めてこれを書いたのは、二週間にわたって毎セッション同じことを繰り返していたときだった Ref. 1。
• 契約：peldanos/peldano-01-contrato-de-convivencia.md。

ステップ 2 — プロジェクトの定義と必読

エージェントの各セッションはゼロから始まる。短い地図を与え、何かに触れる前にそれを読むよう義務付けること。二つの半分は等しく重要だ：誰も読まない地図は作用せず、長い地図は誰も読まない。

• 意図：各セッションが、プロジェクトが何で、どんな状態で、どの決定が既になされたかを知って始まるようにする。
• いつ：一度書く、約束の後。プロジェクト全体を通じて、新しい決定ごとに最新に保つ。
• 入力：約束（第1段）と事業の調査。
• 成果物：運用可能なプロジェクトファイル、そしてここで強調：短く。綱領であって履歴ではない。加えてシステムのセマンティックツリー（B.5参照）：ドメイン、アクター、プロセス、状態を持つエンティティ、画面、インテグレーション、各ノードからぶら下がる保留項目と決定付き。加えて取り組んでいることと開いている疑問を持つ生きた状態のファイル。
• ゲート：エージェントはコードに触れる前にプロジェクトファイルとセマンティックツリーを読み、読むことが証明された。
• 誰が決めるか：オーナーが定義し、エージェントが最新に保つ。
• 防ぐ失敗：二つ、非常に具体的。地図を読まなかったための捨てる仕事 Ref. 9。そして読めなくなるまで育つプロジェクトファイル Ref. 41：運用ファイルと事例集は別のファイルでなければならない。
• 附属書H：ここに附属書Hの二つの前提入力が入る。あとに来るすべてがそれらを使うから、ここに入る。一つはユーザー用語集：人々が実際に各々のものを呼ぶ言葉で、システムが使う言葉ではない。もう一つはプロフィール一覧：それぞれが誰か——管理、運用、照会、顧客——と何をしに来るのか。この二つから第8段の行列、第10段のプロフィール別のケース、第5段のプロフィール別の受け入れ基準が出てくる。これらがなければ、附属書の五つのアンカーは出どころを持たない。
• 契約：peldanos/peldano-02-definicion-y-lectura.md。

ステップ 3 — アーキテクチャを設計する前にサイジングする

飛ばすと最も高くつく段であり、それを知っているのは私が飛ばしたからだ。構造的な決定は数字で行い、一次の数字は事業が持っていて、モデルは持っていない。

• 意図：構造的な決定（どのデータベースエンジンか、インターフェースは同期か非同期か、どれだけの並行性か）を好みではなく数字で行う。
• いつ：一度、骨組みを組む前。事業がスケールを変えればやり直す。小さいプロジェクトでは半ページと一つの決定。
• 入力：事業とともに行ったボリュームデータの調査、本質的に不完全。そして以前のシステムがあれば読み取りアクセス。事業だけが持つデータがあり、モデルは推論できない：だからプロンプトは完全か評価し足りないものを求めるよう要求する。自信ありげな顔で推定する代わりに。
• 成果物：固定の選択肢（三つか四つの具体的な選択肢）と選んだものを持つサイジングの記録。そして明示的に宣言された「非対称な」決定。例えば「永続化インターフェースは最初のエンジンが同期でも一行目から非同期」。間違えても安く、やらないと大金がかかるから。
• ゲート：骨組みを組む前にサイジングが記録されている。
• 誰が決めるか：オーナーが固定の選択肢から選ぶ。エージェントが数字付きで提示する。
• 防ぐ失敗：ボリュームに耐えないストレージで始め、インターフェースの変更が再設計の一段階まるごとを要するときにそれを発見すること Ref. 15。
• 契約：peldanos/peldano-03-dimensionar.md。

ステップ 4 — ゲート付きの骨組み

システムが何か役立つことをする前に、空のまま起動し、テストされ、デプロイされなければならない。そう、空のまま。本番への道はプロダクトの一部であり、機能すると知る唯一の方法は、まだ失うものがないときにそれを辿ることだからだ。これは初期インフラのすべてとインテグレーションとデプロイの連鎖を作る段で、だから立ち上げの中で最も長い。

• 意図：まだ機能が何もない状態で起動し、テストされ、デプロイされるシステムを持つ。
• いつ：一度、立ち上げの終わりに、サイジングの後、いかなる機能よりも前。立ち上げ区間の締めだ。
• 入力：サイジング（第3段）、環境の調査、そしてデプロイ先の認証情報。
• 成果物：継続的インテグレーションが緑の骨組み、スモークテスト付きで組まれたテスト構造、機能し二度実行されたテスト環境へのデプロイ、そして書面で宣言されたワークフローのゲート。
• ゲート：骨組みが緑、継続的インテグレーションが走り、機能ゼロでテスト環境へのデプロイが機能する。オーナーがURLを開き、空の画面を見た。
• 誰が決めるか：エージェントが実行し、オーナーが目視で承認する。
• 防ぐ失敗：立ち上げの一か月後にデプロイを発見し、機能を賭けた状態で動かすために五つの連続した保留項目を払うこと Ref. 32。
• 契約：peldanos/peldano-04-esqueleto.md。

ステップ 5 — 計画とは保留項目のこと

ここに、一度掴んだら手放さない考えがある：「計画」が一方に「タスクリスト」が他方にあるのではない。保留項目のリストが計画そのものだ。 そして各保留項目はどう検証するかを言う。それがあなたがコードを見る代わりに見るものだからだ。

• 意図：順序とゲートを持つ単一の作業キューが、プロジェクトの真実であること。
• いつ：立ち上げが終わった直後、最初の機能ブロックを開くときに作る。プロジェクト全体を通じて毎セッション使う。新しいブロックはそれぞれ、顧客の依頼を保留項目に変換することから始まる。
• 入力：ブロックに対する顧客の依頼、監査、人間によるテストの発見。
• 成果物：番号付き保留項目の記録、それぞれ詳細な仕様付き（B.5参照）：ぶら下がるセマンティックツリーのノード、顧客の言葉による起源のストーリー、記述、適用される事業ルール、データ、画面、境界ケース、受け入れ基準、どう検証するか。そして閉じるとき、完了した保留項目の文書化：証拠、コミット、日付、途中で決まったこと。閉じた保留項目はシステムの機能的な履歴だ。
• ゲート：仕様付きの保留項目なしに変更は入らない。そして保留項目は「完了」ではなく文書化された証拠で閉じる。
• 誰が決めるか：オーナーが優先順位を付け、エージェントが提案し順に実行する。
• 防ぐ失敗：「追い越され」二週間で陳腐化する仕様 Ref. 17。そして六か月後、なぜやったか誰も知らない仕事 Ref. 7。
• 附属書H：附属書Hのアンカー1。画面に触れる保留項目はすべて、上記に加えてもう三つを宣言する：属する機能的収束グループ（その人が何をしに来たか。機能はそれで束ねる）、それを持つプロフィール、そしてプロフィールごとに一つの受け入れ基準。その宣言がなければ保留項目は段を通らない。これは推奨ではない：関門が測るものだ。
• 契約：peldanos/peldano-05-pendientes.md。

ステップ 6 — 決定はコードの隣に書く

モデルは、事業ルールの穴を見つけると、それを埋める。止まって質問しない。最もありそうなもので補完し、他のすべてを書くのと同じ自然さでそうする。だからこの段は「決定を書け」ではなく「欠けていたら止まって質問するよう要求しろ」であり、あなたが決めたら、決定はあなたの言葉、あなたの名前、日付とともに残る。

• 意図：すべてのドメインルールまたは構造的決定に、オーナー、日付、場所があること。
• いつ：ループの各セッションで、エージェントが書かれていないルールに出くわすたびに。機能ブロックごとに二つか三つが普通。立ち上げ（第0段と第3段）と本番リリース（14と15）でも。
• 入力：オーナーとの対話。唯一の入力だ。
• 成果物：コミットと決定の記録に書かれた決定、発言そのままで。オーナーが答えずエージェントが選ばなければならなかったなら、見直すために「省略による決定」と印して残す。
• ゲート：事業ルールはその出所の文なしにコードに入らない。
• 誰が決めるか：オーナー。常に。例外なし。
• 防ぐ失敗：六週間後になぜそうなっているか議論すること。そしてもっと悪いのは、妥当に思えたからとドメインルールを発明するエージェント。ルールをコミットに日付とオーナー付きで書く実践は共済組合から来ており Ref. 29、構築前に決定を凍結する実践は私のツールから Ref. 5。
• 契約：peldanos/peldano-06-decisiones.md。

ステップ 7 — 構築の前に計測する、自身も検証される計器で

これは私にとってすべての中で最も大人の段であり、形式化するのに最も時間がかかったものだ。モデルが独りで適用するだろうと当然視していたからだ。適用しない。ルールは：何かを決める数字は印象からは出ない。リポジトリに住み、テストを持ち、あなたが実行できる計器から出る。そして計器も検証される。計器は嘘をつくからだ。

• 意図：決定に入力されるすべての数字がテスト付きの計器から出て、計器自体が監査されること。
• いつ：ループで、保留項目が数字または原因の仮説に依存するたびに、構築の前に。立ち上げでは、サイジングが最初の事例。小さいプロジェクトでは「計測する」とはコマンドで数えて数字を日付とともに記すことだ。
• 入力：オーナーまたはエージェントの仮説、そして計測したいものへのアクセス。
• 成果物：リポジトリ内のガード付きの計器。コマンドと日付付きの数字。双方向の監査。印された近似。そして該当するなら、計測値に締められテストで守られた経路ごとの予算。
• ゲート：五つのルール：ガード付きの計器。計器がなければ作る。双方向で監査する。近似は印す。そして実行者は計画者の数字を検証する。
• 誰が決めるか：数字。オーナーが仮説を持ち込み、エージェントが構築前に計測する。
• 防ぐ失敗：嘘をついた計器と四つのうち三つの数字が間違っていた計画 Ref. 36。84回の呼び出しを見なかったゼロのラチェット Ref. 35。ルールは教義になる前に、セッション中に私が書いた Ref. 45。
• 契約：peldanos/peldano-07-medir.md。

ステップ 8 — 錠としてのテスト、赤で証明

一度も失敗するのを見ていないテストは、何かを証明しているかわからない。だからここでのルールは「テストを書け」ではない。「テストが古いコードに対して赤になり、その後緑になり、その後回帰が緑のままであることを示せ」だ。そして画面からバックエンドまでのエンドツーエンドテストが、あなたのコード読みを置き換えるものだ。

• 意図：重要なすべての振る舞いに、壊れたら失敗するテストがあり、失敗することが確実に知られていること。
• いつ：ループの各保留項目とともに、それを閉じるとき。触れたフローのエンドツーエンドテストは同じ締めで。完全なエンドツーエンドのテスト群は各ブロックの締めと本番への各デプロイの前に。
• 入力：既に実装された変更と、「どう検証するか」付きの保留項目。
• 成果物：新しいテスト、レシートとしての赤の出力（コマンド、それが走った対象のバージョン、数字、終了コード：一つのコマンドでもう一度走らせるのに必要なもの）、数字付きの緑の出力、同じセッションでの隣接項目の回帰、そして何に対して赤で証明したかを言うコミット。
• ゲート：レシート付きで示された赤、緑、緑の回帰。そしてエージェントはまさに試したい部分をシミュレートしない。
• 誰が決めるか：エージェントが実行して報告し、オーナーはテストではなく報告を読む。
• 防ぐ失敗：何も証明しないから通るテストと、バグを隠す緑 Ref. 44。カウンタの事例は古い基準に対して赤で証明されたテストの完全な例だ Ref. 26。
• 最初のブロックの赤: 以前のバージョンにモジュールがないときは、赤をミューテーションで証明する（植えた欠陥、赤のテスト、レシートの diff）。読み込めないファイルでは証明にならない。
• 附属書H：附属書Hのアンカー2。同じ保留項目がプロフィール別機能行列のテストを担う：どのプロフィールが何をできるかを言う表で、メニュー、ルート、権限を三箇所に三回書く代わりにそこから導く。端から端までのテストは、プロフィールごとに、到達できるものを行列のその行と比べる：少なくも多くもなく。自分のものでないボタンが見えている人と、権限があるのに画面を見つけられない人を捕まえる方法だ。
• 契約：peldanos/peldano-08-tests-en-rojo.md。

ステップ 9 — 機械で検証されるコードの品質、ゲート付きで

オーナーはコードを読まない。それが要点だ。だがコードは誰かが保守することになり、今日動いて明日読めないコードは、三か月目に取り立てられる負債だ。誰も読まないなら、機械が見なければならない：各コミットで、人間のレビュアーが見るであろうものが、上限を持つ数字に変えられる。私はそれを自分のすべてのプロジェクトで、段として名付けないままやってきた。

そしてここで、この段を前の段から分ける一文を手元に置くとよい。業界で最も高くつく混同であり、九語で解ける：カバレッジはテストを数える。赤はそれが役に立つかを言う。九十パーセントというカバレッジの数字は、テストがどれだけのコードを実行するかを教えるが、振る舞いが壊れたときにそのテストのどれかが赤くなるかについては何も教えない。それを言うのは第8段で、偽装できない唯一の方法で言う：赤を見ることだ。カバレッジはこの段の数字。赤は前の段の受領証だ。（この定式化は方法を別の形式に翻案した最初のものに由来し、パートFで出典を示している。）

• 意図：コードの品質が各コミットで機械によって検証され、ビルドの赤を帰結として持ち、決して独りでに劣化しないこと。
• いつ：最初の機能ブロックを開くときに組み立て、各プッシュで走る。各保留項目は品質が緑の状態で、赤のテスト（8）の後に閉じる。報告は各ブロックの締めにオーナーと読む。レガシーでは、最初の実行が基準線だ。
• 入力：継続的インテグレーション（4）、閉じた保留項目が少なくとも一つ分のコード、そしてオーナーが決めた上限（まずはファイルと関数の大きさ）。
• 成果物：単一の設定を持つリンタとフォーマッタ。大きさと複雑度の上限。重複と死んだコードの検出。ラチェット付きのカバレッジ。言語が許すなら型。各上限とその計測値を持つ docs/CODE_QUALITY.md。docs/GATES.md のゲート。利用者のいるどんなプロジェクトでも必須で、実際の利用者がいないときだけ任意の、ミューテーションテスト（わざと植えた誤りを、テストがいくつ捕まえるかで数えるもの）。ブロックごとの得点をカバレッジの隣に。
• ゲート：品質が赤のものは何もマージされない。書かれた理由のないリンタへの例外はない。通すために引き上げられた上限はない。
• 誰が決めるか：オーナーが上限を定め、何を今直し何を日付付きで許容するかを決める。エージェントが計測し、同じコミットで直す。
• 防ぐ失敗：どの上限も止めなかったために監査が見つけた、二千行を超えるコンポーネントと一万行近いファイル Ref. 41。誰も見ないうちに悪化する品質の数字 Ref. 35。
• 附属書H：附属書Hのアンカー3。五つのうち最大のもので、ここで関門がコード品質から使いやすさへ広がる。四十五のルールのカタログはグループごとに宣言され有効になっている。有効な各ルールは道具、重大度、検査器を持つ。消された各ルールは理由、誰が承認したか、見直し日付の記録を持つ——記録なしに消すのは赤で、ルールが存在しないのとは違う——。持ち主が宣言しなかった閾値はすべて、でっち上げる代わりに未宣言として公開される。そして報告は二つの数字とルール集合の指紋とともに出る。システムはコード品質を優秀に通りながら使えないことがありうる。このアンカーがそれを防ぐ。
• 契約：peldanos/peldano-09-calidad-de-codigo.md。

ステップ 10 — 手動テストケースは機能とともに書かれ、それを実行するのは人である

自動テストはモデルが書きモデルが走らせ、モデルが理解したことを検証する。欠けているのは、人が自分の目と自分の手で、台本に従って行うテストだ。台本は、その機能を構築したのと同じ者が、同じ瞬間に、受け入れ基準から書く。それを人が実行するのは各ブロックの締め、受け入れ、そして各デプロイの後。失敗したものは要件としてループへ戻る。プロセスの図が示す円環の閉じだ。

• 意図：すべての機能が、システムがどう作られているかを知らない人に向けて書かれた手動テストケースとともに生まれること。そして人による各実行が、失敗したものを保留項目として再注入すること。
• いつ：各保留項目とともに、それを閉じるとき、赤のテスト（8）と品質（9）の後に。人による実行は各ブロックの締め、最初のデプロイの前（受け入れ）、そして各デプロイの後、読み取り専用で。
• 入力：保留項目の受け入れ基準（5）、データの入ったテスト環境、そして誰がいつ実行するかの決定。
• 成果物：触れたフローごとに一つのケースを持つ docs/MANUAL_TESTS.md（識別子、保留項目、前提条件、何をし何が見えるかの手順、人が検証できるバックエンドでの効果を含む期待される結果、データ、実行の表）。記録された実行。失敗ごとに一つの修正の保留項目。
• ゲート：画面に触れる保留項目はケースなしに閉じない。日付と名前のない実行はない。人の言葉を持つ保留項目のない失敗はない。
• 誰が決めるか：オーナーまたは信頼できる利用者が実行する。エージェントがケースを書き保留項目を開く。モデルはケースを実行済みと決して印さない。
• 防ぐ失敗：毎回違うものを見つける台本なしの人によるテスト。その場で直されて失われる人の発見。コースのガイドプロジェクトで、どのテストも見なかったが担当者は見つけた、使いにくいドロップダウンメニュー。
• 附属書H：附属書Hのアンカー4。各手動ケースは影響を受けるプロフィールごとに一度走らせ、プロフィールは実行する人の記憶ではなく第8段の行列から出る。一つのプロフィールだけで走らせたケースは実行済みに数えない：権限とメニューの問題の半分は、作った人のものでないプロフィールからしか見えない。
• 契約：peldanos/peldano-10-casos-de-prueba-manual.md。

ステップ 11 — 生産者と消費者の対称性、そしてアンチパターンの記録

一方の端（サーバー、データベース、ロボット）を変えたら、もう一方の端（画面、カウンタ、レポート）も同じコミットで変わらなければならない。それを支える原則はすべてのリストには一人の所有者しかいないということだ。そして既に一度払った誤りは、二度払わないよう自動検証付きで記す。

• 意図：一方の端の変更が常に、同じコミットで、他方を引きずること。
• いつ：システムの二つの部分間の契約に触れる各保留項目とともに。契約の地図は既に画面とサーバーがある二つ目の機能ブロックを開くときに構築する。アンチパターンの記録は何かが二度目に壊れるたびに育つ。
• 入力：誰が各契約を生産し誰が消費するかの地図。アンチパターンの記録。
• 成果物：サーバーがリストを定義し消費者がそれを読む。生産者/消費者の地図。匂い、根本原因、修正、早期検知付きのアンチパターンの記録。
• ゲート：自動：エージェントは変更を閉じたとする前に相手側を探す。
• 誰が決めるか：誰でもない。自動だ。
• 防ぐ失敗：クエリと一致しないカウンタ Ref. 26。同期しなくなる同じモジュールの二つのコピー Ref. 41。単一の源の解決は共済組合で課した Ref. 27。
• 契約：peldanos/peldano-11-simetria-y-antipatrones.md。

ステップ 12 — 誠実な検証と釣り合った報告

コードを読まないのなら、エージェントの報告は信頼できなければならず、それは自然には起きない。モデルは役に立ち完全であるよう訓練されており、「これは検証できなかった」と言う報告は「完了」と言う報告より役に立たないと感じられる。だから悪い知らせ、盲点、やらなかったことを明示的に要求すること。

• 意図：オーナーがコードを読まずにエージェントの報告が信頼できること。
• いつ：各保留項目の各報告で、プロジェクト全体を通じて。エージェントがあなたに言うすべてが持つべき形だ。
• 入力：なされた仕事とそれを求めた保留項目。
• 成果物：三つのブロックを持つ報告：検証済み（隣に証拠付き）、信じている（そしてなぜテストしなかったか）、盲点（いる場所から見えないもの）。頼まれた各項目を網羅する。悪い知らせを最初に。
• ゲート：証拠のない主張はない。そっけなく「完了」とは言わない。「まだ壊れている」に対しては、まず公開されているバージョンと修正を持つバージョンを比べる。
• 誰が決めるか：オーナーが信頼するか、証拠を求める。決してコードをレビューしない。
• 防ぐ失敗：成功として報告されたエラーと、検証されていないものを検証済みと宣言した報告 Ref. 43。1時間43分見えないまま働いたターン Ref. 16。検証の誠実さのルールは六月に書いた Ref. 8。
• 附属書H：附属書Hのアンカー5。報告は附属書のグループについても伝える：何を測り、何が測られずに残り、どのルールが記録付きで消されているか。附属書に適用された同じ誠実さのルールだ：インストールが測り方を知らないルールは未測定として報告され、決して緑としては報告されない。
• 契約：peldanos/peldano-12-verificacion-honesta.md。

ステップ 13 — 計画への入力としての定期監査

ときどきシステム全体を新鮮な目で見なければならず、見えたものは保管される報告には行かない：保留項目のキューに行く。重要なのは「新鮮な目」：構築していない誰かが監査すること。構築した者は自身の前提を共有するからだ。別の指示ファイルを持つモデルの別のセッションで足りる。

• 意図：ときどきシステム全体を見て、見えたものを保留項目に変換する。
• いつ：本番への最初のデプロイの前に必須（本番リリース区間を開く）。運用中は変更のペースに応じて一、二か月ごとに、そして各大きな段階の締めに。
• 入力：リポジトリ全体と読み取り専用の本番。
• 成果物：段階付けされた発見を持つ報告、それぞれ位置、リスク、証拠、優先度付き。次元ごとの評点。そして既に保留項目に変換された緊急の発見。
• ゲート：監査を閉じたとする前に、各緊急の発見に開かれた保留項目がある。
• 誰が決めるか：オーナーが発見に優先順位を付ける。
• 防ぐ失敗：テーブル全体を読むクエリ Ref. 18。別の人が見るまで誰も見なかった二つの管理者の扉 Ref. 40。既知の脆弱性と巨大なコンポーネント Ref. 41。
• 契約：peldanos/peldano-13-auditoria.md。

ステップ 14 — フェイルクローズド、錠、静かな損害ゼロ

疑いや故障の前で、システムは行動しない。そしてそう言う。当たり前に聞こえるが、ソフトウェアが既定でやることの逆だ。ソフトウェアは疑いの前で進む。この段は世界に作用する機能を構築する前に来る。後ではない。

• 意図：システムが疑いや故障の前で行動せず、知らせること。
• いつ：本番リリース区間で、請求し、送信し、承認し、削除する機能を構築する前に。帰結のある新しい行動ごとに見直す。新しい自動化はドライランモードで始め、数日その記録を見た後に有効化する。
• 入力：オーナーとともに行った、帰結のある行動の調査。
• 成果物：錠の表：各行動にその可逆性、錠、戻り道。錠ごとに赤で証明されたテスト。ドライランモードの新しい自動化。
• ゲート：すべての不可逆な行動に錠と文書化された戻り道がある。
• 誰が決めるか：オーナーが錠ごとに承認し、システムは決してそれを飛ばさない。
• 防ぐ失敗：二重請求、人を通さない自動承認、顧客データの削除。共済組合の錠が模範で Ref. 28、リスト全体を壊さない反射もそうだ Ref. 25。
• 契約：peldanos/peldano-14-fail-closed.md。

ステップ 15 — プロダクトの一部としての継続的インテグレーション、環境、秘密、デプロイ

本番に至ることは再現可能なパッケージでなければならない：テストは一度走り、デプロイはパッケージしてアップロードするだけ、設定はリポジトリではなくサーバーに住み、ロールバックは試されている。この大半は骨組みから既に存在する。この段はそれを本番へ向けて完成させる。

• 意図：本番に至ることが、テストを一度だけ実行し設定をリポジトリの外に置いた、再現可能なパッケージであること。
• いつ：インテグレーションの連鎖とテスト環境へのデプロイは第4段で組む。本番への締め ——実環境、秘密、昇格、試されたロールバック、秘密に対する錠——は監査と錠の後、本番リリース区間で行う。各デプロイのルーチンは運用全体で適用する。
• 入力：環境とアクセスの調査。インテグレーションを持つ骨組み。
• 成果物：コミットごとに一度テスト群を走らせる継続的インテグレーション。その結果を待ちパッケージするだけのデプロイ。サーバーのみの設定。書かれた繰り返し可能な昇格手順。試されたロールバック。秘密のアップロードを防ぐ検証。
• ゲート：本番に触れる前に同じバージョンでテストが緑。試されたロールバック。リポジトリにもチャットにもローテーションされていない秘密がない。
• 誰が決めるか：オーナーが本番へ昇格し、エージェントがすべてを準備する。
• 防ぐ失敗：コミットごとに三度走るテストと燃え尽きたクォータ Ref. 39。遅く発見されたために保留項目を重ねて強化されたデプロイ Ref. 32。チャットに貼られた秘密 Ref. 42。
• 契約：peldanos/peldano-15-ci-entornos-secretos-deploy.md。

ステップ 16 — 設定可能なレベルを持つ、完全な可観測性とトレーサビリティ

本番で何かが失敗したとき、一つの識別子だけで、コードを開かずに、画面からデータベースまで一つの行動を追いたい。本番での記録の詳細さを一分で、再デプロイせずに上げられるようにしたい。そして帰結のあるすべての行動が、アプリケーションが消せない跡を残すようにしたい。

• 意図：システムが走っている間にそれが見えること（可観測性）、そして重要な各行動がその跡を持つこと（トレーサビリティ）。詳細さのレベルは設定で変える。
• いつ：本番リリースで、第15段の後、第19段の前。レガシーでは最低限のレベルが安全ベルト（N4）に入り、完全なレベルはここ。「新しいモジュールはすべて記録し伝播する」というルールは運用の全期間にわたって効力を持つ。
• 入力：環境ごとの設定（15）、錠の表（14）、調査の個人データのリスト、そして記録がどこに住むかという決定。
• 成果物：デプロイせずに設定可能なレベルを持つ構造化された記録。各記録の中の、画面からデータベースまでの相関識別子。帰結のある行動の不変の監査。健全性と指標のエンドポイント。 docs/OBSERVABILITY.md。
• ゲート：実際の識別子がすべての層を通って追われること。デプロイなしに変えられたレベル。記録の中に個人データが一つもないこと。
• 誰が決めるか：オーナーが、記録がどこに住むか、どれだけ保存するか、何が個人データかを決める。エージェントが組み立てる。
• 防ぐ失敗：1時間43分生き続け、ログで見つかったプロセス Ref. 16。読むべき記録がなければ盲目で運用する常駐エージェント Ref. 13。
• 契約：peldanos/peldano-16-observabilidad-y-trazabilidad.md。

ステップ 17 — 永続化層の最適化、前と後を計測して

データベースはシステムがゆっくり死ぬ場所だ：百件ではよく、十万件では悪く、いつ始まったのか誰も知らない。ここでは数字で、本番の前に、そして第7段の方法で決める：計測し、変え、同じデータの上で計測し直す。

• 意図：サイジングの量における、システムの実際のクエリが業務の我慢できる範囲に収まること。そして再び外れないようにする予算とともに。
• いつ：本番リリースで、第16段の後、第19段の前。ブロックが大きいテーブルを追加したときや、監視（21）がクエリの範囲外を示したときに繰り返す。レガシーでは計測はN6から出て、ほとんどは「触れたときに払う」で払われる。
• 入力：サイジング（3またはN6）、生産者・消費者の地図（11）、可観測性（16）、そして期待される量を読み込んだテスト環境。
• 成果物：テスト付きのクエリの計器。docs/PERSISTENCE.md、変更ごとの前と後の表、経路ごとの予算、テーブルごとの保持とともに。予算ごとに一つのテスト。
• ゲート：重要なフローの中にテーブル全体を読むクエリが一つもないこと。各予算にそのテスト。最も遅い画面がサイジングの期待した範囲の中にあること。
• 誰が決めるか：オーナーが変更のリストを一つずつ承認する。エージェントが計測して適用する。
• 防ぐ失敗：生きたシステムでテーブル全体を読んでいたクエリ Ref. 18。計測値に締め直さなければならなかった予算 Ref. 37。ファイルの上の数百万行 Ref. 15。
• 契約：peldanos/peldano-17-persistencia.md。

ステップ 18 — 脆弱性の走査と解決、連鎖の中で、そして暦とともに

監査（13）はときどき、判断力でシステム全体を見る。この段はただ一つのこと、セキュリティを、いつも、機械で見る：依存関係、コード、履歴の中の秘密、そしてサーバーの設定。そして一つのルール：依存関係の更新は変更であり、ループから入る。

• 意図：既知の脆弱性が一つも本番に届かないこと。そして誰もシステムに触れなくても新しいものが独りで検知されること。
• いつ：本番リリースで、第15段の後、最初のデプロイの前。その後は各プッシュで、そして週次の暦で。レガシーでは最初の実行はN3の一部。
• 入力：継続的インテグレーション（4と15）、環境の調査、以前の監査、そして何が急を要するかについてのオーナーの基準。
• 成果物：連鎖の中と暦とともに走る四つの層の走査。docs/SECURITY_[日付].md、発見と未走査のものとともに。docs/SECURITY.md、方針とともに。docs/GATES.md のゲート。それぞれの保留項目とともに直されたP0とP1。
• ゲート：開いたP0があるものは本番に昇格しない。新しいP1は独りで保留項目を開く。
• 誰が決めるか：オーナーが何がP0かを定め、修正を承認する。エージェントが組み立てて走らせる。
• 防ぐ失敗：品質の監査で現れた既知の脆弱性 Ref. 41。別のセッションだけが見た管理者の扉 Ref. 40。一度チェックを付けるリストとして扱われたセキュリティ Ref. 23。
• 契約：peldanos/peldano-18-vulnerabilidades.md。

ステップ 19 — 量に対する性能テストと破断点

第3段は計算でサイジングした。この段は動いているシステムでその計算を確かめる：期待される量で、「十倍」で、そして何かが壊れるまで。破断点はこの区間で最も役に立つ数字だ。そこから第21段の警報の閾値が出るからだ。

• 意図：最初の利用者が入る前に、期待される量で、そして「十倍」でシステムがどうふるまうか、そしてどこでなぜ壊れるかを知ること。
• いつ：本番リリースで、第16段と第17段の後、最初のデプロイの前。アーキテクチャ、永続化、重要なフローを変えるデプロイのたびに繰り返す。レガシーではN6で計測した量で。
• 入力：サイジング、点いた可観測性、最適化された永続化、重要なフロー、そして最もよく使われる画面についての業務の許容。
• 成果物：リポジトリの中の、テスト付きの負荷スクリプト。docs/PERFORMANCE_[日付].md、三つの実行、破断点、診断とともに。docs/PERFORMANCE.md、閾値とゲートとともに。ボトルネックごとに一つの保留項目。
• ゲート：最もよく使われる画面が期待される量で許容の中にあること、またはその数字を持つ保留項目があること。何が壊れるかとともに書かれた破断点。
• 誰が決めるか：オーナーが許容を与え、どの量までボトルネックを今直すかを決める。
• 防ぐ失敗：本番を見ることでしかわからなかった実際の負荷 Ref. 12。テストの失敗に化けた破断点 Ref. 44。ゲートとしてのサイジング Ref. 14。
• 契約：peldanos/peldano-19-rendimiento-y-punto-de-ruptura.md。

ステップ 20 — 生きた文書と、人がAIなしで追えるマニュアル

システムはエージェントなしで、あなたなしで、使い、保守し、復旧できなければならない。エージェントがいない日にデプロイできないなら、完成していない。そしてモデルで文書を再生成するのは無料なので、ルールは「同じコミットで」になる。

誰でも読み終わる前に理解できる一語で言えば：これらのマニュアルがなければ、持ち主は持ち主ではなく、借主だ。システムを持ち、代金を払い、中に住んでいて、鍵を失くしたら入れない：起動するにも、復旧するにも、なぜ動かなくなったのかを理解するにも、作った人——あるいは作ったモデル——が引き続き手に入り、引き続き気が向いていることに依存する。システムの所有とはコードではない：許可を求めずに運用できることだ。（この定式化は方法を別の形式に翻案した最初のものに由来し、パートFで出典を示している。）

• 意図：エージェントなしで、構築者なしで、システムを使い、保守し、復旧できること。
• いつ：ユーザーマニュアルは各機能ブロックとともに、その締めに、新しい画面で育つ。三つの完全なマニュアルは本番リリース区間で、第15段の後に生成し、プログラミングをしない人によるテストは最初のデプロイの前に行う。同じコミットのルーチンは運用全体を支配する。
• 入力：テスト環境で動くシステム。第14段と第15段の成果物。
• 成果物：実際のスクリーンショット付きのユーザーマニュアル、保守マニュアル、そして午前三時に手でやらなければならない人のために書かれたインフラと復旧のマニュアル。それぞれ日付とバージョン付き。
• ゲート：文書が同じコミットで最新。プログラミングをしない誰かが復旧マニュアルを追った。 そしてその実行が記録を残した（下記）
• その試行は「やった」ではなく三つのものを書き残す：端から端までの測った時間（いつ始まり、いつシステムが再び動いたか）、人がつまずいた正確な地点——マニュアルの手順を、その人の言葉で——、そして理解できなかったすべての語。三つとも日付と試行をした人の名前とともに書く。そして理解できなかった各語は保留項目を開く：マニュアルで説明するか、そのものの名前を変えるかだ。その記録がなければ、たとえその人がシステムを復旧できたとしても関門は満たされていない：証拠を生まない試行は、何も測らない関門を持つ最も安い方法だ。
• 誰が決めるか：エージェントが保守し、オーナーはコードではなくマニュアルを読む。
• 防ぐ失敗：間違ったリポジトリへのコミットを引き起こした古い文書。履歴と化したプロジェクトファイル Ref. 41。手で再現可能なマニュアルは共済組合のもの Ref. 24。
• 契約：peldanos/peldano-20-documentacion-viva.md。

ステップ 21 — 資源、関数、クエリの範囲外の監視、周期報告とともに

第19段のテストは、ある一日にシステムがどうふるまうかを言う。本番は毎日であり、データは増え続ける。この段は、資源の使用と、各関数、各クエリの応答時間を、第19段の閾値と、そしてそれ自身の歴史と比べて見張り、何かが範囲外に出たら知らせ、オーナーと読む周期報告を生む。各逸脱は一つの保留項目だ。

• 意図：資源や性能の問題を、利用者が見る前に見ること。そして各逸脱が原因か保留項目を持つこと。
• いつ：本番への最初のデプロイとともに組み立てる。それ以降は独りで走り、報告はサイクルごとに読む（帰結があれば週次、小さいプロジェクトでは月次）。レガシーでは最初の読みが基準線。
• 入力：第16段の指標、第17段の予算、第19段の閾値、読み取り専用の本番、そしてオーナーと決めた経路とサイクル。
• 成果物：歴史を持つ収集。閾値による警報と逸脱による警報。独りで生成される周期報告。 docs/MONITORING.md。約束の中の読みのルーチン。
• ゲート：引き起こした警報が経路に届いたこと。最初の報告が各逸脱に原因か提案を持つこと。書かれた理由なしに上がった閾値が一つもないこと。
• 誰が決めるか：オーナーが経路、サイクル、そしてどの逸脱を今対応するかを決める。エージェントが組み立てて提案する。
• 防ぐ失敗：計測値に締め直さなければならなかった天井 Ref. 37。誰も見ないまま燃え尽きたクォータ Ref. 39。
• 検証可能な期間: 周期測定にはデータベースから読んだ最初と最後のレコードを添える。手入力の期間はそう明記し、警告するだけ。
• 契約：peldanos/peldano-21-monitoreo-de-recursos-y-rendimiento.md。

ステップ 22 — エラーの監視と周期報告：保留項目のないエラーは一つもない

本番のシステムは誰も報告しないエラーを生む。この段はそれらを、隠れる三つの場所（バックエンド、ジョブ、利用者のブラウザ）で捕捉し、まとめ、新しいものと増えているものを知らせ、周期報告を生む。ルールは二つ：保留項目のないエラーは一つもない。そして、なぜ許容するのかいつまで許容するのかを言う保留項目のない「既知のエラー」は存在しない。

• 意図：本番のどんなエラーも見られないまま過ぎないこと。そしてそれぞれが、それを再現する赤のテストとともに閉じられること。
• いつ：最初のデプロイとともに、第21段とともに組み立てる。それ以降は独りで走り、その場の警報と周期報告とともに。レガシーでは、初日に既に存在していたエラーは速度の印とともに保留項目になる。
• 入力：第16段の記録、錠の表（14）、ブラウザを含む本番、第21段の経路とサイクル。
• 成果物：中央でまとめられた捕捉、個人データなしで。新しいエラー、増えている繰り返すエラー、帰結のあるエラーによる警報。フローごとのエラー率を持つ周期報告。 docs/MONITORING.md。約束の中のルーチン。
• ゲート：ブラウザで引き起こしたエラーが報告まで追われること。保留項目も日付付きの理由もない繰り返すエラーが一つもないこと。
• 誰が決めるか：オーナーが報告を読み、何に対応するかを決める。エージェントが捕捉し、まとめ、提案する。
• 防ぐ失敗：成功として報告された認証エラー Ref. 43。エラーが再現されていなかったせいの、根本原因までの四往復 Ref. 22。
• エラーの発生源: システムを観測する道具のエラーは別扱いにし、レポートの独自の節に置き、保留項目を開かない。
• 契約：peldanos/peldano-22-monitoreo-de-errores.md。

ステップ 23 — システムの中のエージェント、そして数字による振り返り

最後の段には同じサイクルを閉じる二つの部分がある。第一：エージェントが限定された範囲で、人の名において行動しながら本番に常駐する。第二：方法自体が数字で見直され、学んだことが次のプロジェクトのために第0段へ戻る。

• 意図：エージェントが限定された範囲で本番に常駐し、方法が数字で見直されること。
• いつ：常駐エージェントは、本番への最初のデプロイの後、運用に入るとき。振り返りは各段階とプロジェクトの締めに。一ページでも必須だ。
• 入力：本番のシステム、インシデント、コスト。
• 成果物：システムの地図、範囲、人の名における認証情報、範囲外のものが拒否される証明を持つ常駐エージェントの文書。そして出所付きの数字、段に対応付けられた各インシデント、はしごへの少なくとも一つの具体的な変更提案を持つ振り返り。
• ゲート：エージェントはオーナーが承認していないことをできない。振り返りははしごへの少なくとも一つの変更を生む。
• 誰が決めるか：オーナー。
• 防ぐ失敗：地図なしに運用するエージェント。そしてプロジェクトごとに学ばずに同じことを繰り返す方法。マルチエージェントチームを廃止した数字による振り返りが模範で Ref. 6、常駐エージェントは共済組合のもの Ref. 13。
• 契約：peldanos/peldano-23-agente-residente-y-retrospectiva.md。

パートD — どう実行し、どれだけ要求し、どのツールで

各段をどう実行するか：契約

八つの部分のカードは、各段が何を目指し、いつ登り、何を残すかを言う。だが段が本当に理解されるのは、どう頼み、何が返ってくるべきで、完全に返ってきたとどう知るかを見たときだけだ。だから各段にはカードに加えて、peldanos/ 内の専用ファイルに契約があり、常に同じ五つの節を持つ：

1. 必要な文脈、一般的な名前で（「ボリュームデータの調査」「以前のシステムへの読み取りアクセス」「実際の帰結を持つ行動のリスト」）、システム工学の細部に降りずに。調査は本質的に不完全であり、フォームで完全にしようとはしない。
2. プロンプト、モデルに与えるもの、原文で。最初のものと、段が対話であるときは締めのもの。すべて同じ条項を持ち、それが事の核心だ：*モデルは文脈が十分か評価する。不十分なら進む前に足りないものをすべて求める。そして事業だけが持つデータを推定も発明もしない*。計算に何が足りないかを知っているのはモデルであって、フォームではない。そして各プロンプトの前には、「プロンプトを送る前に」と書かれた枠が置かれる：貼る前にあなた（または業務側とあなた）が作り終えていなければならないファイルと材料を、その名前、その内容、そして最低限受け入れられる状態とともに。プロンプトはそれらを名指しし、枠はそれらがどう作られているべきかを言う。その枠がなければ、プロンプトは、どう書けばよいか誰も教えてくれないファイルを名指しすることになる。
3. 期待される成果物：成果物の詳細な特徴。
4. 完全性の検証：オーナーが成果物に対してコードを読まずに行う検査のリスト。一つでも「否」なら段は登れていない。
5. 警告サイン：登ったように見えても段を登り損ねた二、三の症状。

その完全性の検証は三十二の契約に分かれている。段ごとに一つ、ステーションごとに一つだ。プロジェクトが進行中ならそれで役に立つ。だが三十二の契約が手元にない、もっと前の瞬間がある：誰かがあなたにシステムを作りましょうと申し出る会合だ。その瞬間のために一枚の紙がある：提供者への二十五の質問。同じ完全性の検証をまとめ、ソフトウェアを一度も発注したことのない人のために書き、何を約束されているかで並べたものだ。各質問は、どんな答えが見られるか——ファイル、コマンド付きの数字、赤を見たテスト、マニュアル、署名——と、どの段から出ているかを言う。印刷して持っていく。

そして各契約のヘッダに：区間、いつ、形式、規模（すべてのプロジェクトで必須か比例か）。

プロンプトは英語で、それぞれに翻訳が付く。 三つの理由で取った決定だ：同じ内容がスペイン語では30〜50%多くのトークンを占める。モデルの指示追従能力は英語でより良く較正されているため、英語のプロンプトは曖昧になることなく簡潔さによく耐える。そして業界の語彙（test、commit、 rollback、mock）は英語である。だが英語が方法を読む障壁になってほしくはない：各プロンプトの下に何を求めているかとなぜ各条項があるかの説明があり、HTML版には文書の言語に翻訳されたプロンプトを表示するボタンがある。モデルに貼り付けるプロンプトは英語。翻訳はあなたが理解するためのものだ。そしてすべて "Reply in my language" で終わる。プロンプトは英語でも、会話まで英語である必要はないからだ。

プロジェクトの規模に応じて、何が必須で何が比例か

すぐに出る問い：「小さいシステムにこれ全部？」答えは、二十四の段は二十四の長い段階ではなく、いくつかは一セッションで登れ、比例するものはプロジェクトとともに縮む、だ。縮まないのは譲れないもののリストだ。この表は方法を最初から最後まで使う最初のプロジェクトで確認すべき提案 仮説である：

だが表の前に、どうやって段を小さくするところに至るのかを言っておくとよい。表だけだと許可証のように読めるが、そうではない。三つの時機があり、順序がある。

まずは完全にやる。何のためかわからないものも含めて。 方法を初めて適用するとき、どの部分が余っているかを知る状態にはない：官僚的に見える段こそ、まだ起きていない問題を防ぐ段であり、リスト全体は既に起きた問題から出てきた。一度完全にやるほうが、何を飛ばすかの議論より安い。そしてそれが次の段階のための判断を与える唯一のものだ。

次に目の前にあるものに合わせる。 二十四段を一度登ったなら、それぞれが何を生むかを知っており、寸法を決められる：五ページではなく半ページ、経路ごとの予算ではなく一回の実行、週次の報告ではなく月次の報告。それがこの表の提案だ。そして決定は持ち主のもので、段ごとに、声に出して行う：このプロジェクトでどれを小さくし、どれを譲らないか。始める前に書き、最初の問題のあとではない。書かれた決定で小さくした段は釣り合いだ。黙って小さくしたら、それは負債だ。

そして最後に、あとから来る人たちのために改良する。 第23段は、梯子への変更提案としてここに戻ってくる振り返りで閉じる。適用して発見したことはあなたの逸話ではない：この表の次の行だ。この文書がバージョン4にあるのはそのためだ。

要約：どのプロジェクトでも譲れない段が十三（0、1、2、3、5、6、8、最低限の9、10、12、18の依存関係の走査、22のエラーの捕捉、23の振り返り）、プロジェクトに合わせて規模を変えるものが十一。

どんなツールでも使う方法

方法はツールに対して中立である。ツールごとに変わるのは、モデルが読めるよう各成果物をどこに置くかだ。2026年末時点で最も使われるツールへの対応：

Forgeの列が最も自動化するものだ。他の三つも、Forgeが自動でやることをオーナーが手でやれば同じくらい機能する：適切な瞬間に段のプロンプトを貼り、次へ進む前に完全性の検証を要求すること。それが、実際、コースの実践だ。

パートE — 練り上げるべき残り

1. 完全な第0段：重み付け基準の重み、閾値、そして反例としてのより多くの断ったプロジェクト。X1とX2はある。残りが欠けている。
2. 各段の覚えやすい名前、一文で、マニュアルと出版物のために。
3. Forgeへの輸出、おおむね解決済み。 方法はForge内でプロジェクトフローとして完全に動き、機械的なゲートと、進行中の段のプロンプトがチャットに注入される（D-035、D-036）。欠けているのは、この文書が言うこととツールが実際にすることのずれがたまる前にすぐ気づけるように、契約ごとの対応表をForgeが今実行していることと照らし合わせて作ることだ。
4. 契約を最初から最後まで試すことは、すでに進行中。 コースの指導用プロジェクト（Turnera）が書かれたとおりに二十四の契約を走らせ、24件中24件を閉じた。その途中で見つかったことはすでに方法そのものを修正している（D-037からD-040）。欠けているのは最初の完全な通し稽古ではない。それはもう起きた。欠けているのは、他人のプロジェクトがそれを走らせ、契約が想定していなかったことを私が隣で解決せずに済むことだ。
5. コースの最初のコホート、タイムラインの期間と典型的な誤りを修正する。今日それらは受講生からではなく私のプロジェクトから書かれている。
6. 進化・修正の道は、他人のではなく自分自身のレガシーで試された。 コースの指導用の引き継いだプロジェクト（引き継いだTurnera）が、書かれたとおりに八つのステーションと残りのはしごを走らせ、27件中27件を閉じ、方法の三つの決定を促した（D-038、D-039、D-040）。欠けているのは、コースのために自分で組んだシステムではなく、独自の歴史と独自の近道を持つ第三者の本物のレガシーで、同じ道を試すことだ。
7. はしごにないがあるべきもの 仮説：明示的な予算としてのトークンとクォータのコスト管理（今日は反応的）。インシデントではなくルーチンとしての秘密のローテーション。そして人間がコードを見るべきときの基準。今日の答えは「決して」だが、見た方がよい局所的な瞬間があると疑っている。

パートF — 関連する取り組み：似たものは何があり、この方法はどこが違うか

はしごを書き終えたとき、私は当然の問いを自分に向けた：これは別の名前で既に存在するのではないか？ 2026年10月までに公開された、人工知能でソフトウェアを構築するための方法論、エッセイ、学術研究について、英語、スペイン語、日本語で徹底的な調査を頼んだ。以下がその結果で、正直に要約したものだ：既に他の場所にあるものは、自分のものだと主張する代わりに引用し、見つけられなかったものは「存在しない」ではなく「見つけられなかった」と言う。この部は、新しいものが現れるにつれて広げていくことになる。新しいものは毎週現れる。

短い答え：この方法が束ねているものを束ねた、公開済みの方法は見つけられなかった。見つけたのは、2025年半ばから、その部品のいくつかに別々に収斂しつつある一つの分野全体と、私がこれを公開する三か月前に同じ急進的な前提にたどり着いていた一人の著名な実践者だ。

F.1 最も近い親戚たち

F.2 既に存在していて、主張する代わりに引用すべきもの

エージェントに課される緑の前の赤は、Beckに、Tsumikiに、Anthropicのプラクティスに、そして 2026年のSimon Willisonのパターンにある。文字どおりのプロンプトを持つ順序づけられた段階は、 Spec Kitに、Tsumikiに、Reedにある。レガシーに先立つ段階としての特性化はOsmaniにあり、この文書の一か月前に公開された。生成者とは別の評価者による、画面からのエンドツーエンドテストは Anthropicにある。前提条件としての要件工学は、仕様駆動開発の運動全体にある。そしてコードを読まない人間は、Uncle Bobに、使い捨てのものについてはKarpathyに、そしてYeggeとKimの本にある。

F.3 どこにも見つけられなかったもの

• 宛先。 あらゆる文献が、レビューするエンジニアを前提にしている。Uncle Bobがコードを読まないのは、防壁を築くための四十年の眼識があるからだ。この方法は決して読まないオーナーから出発し、残りすべてをその制約から導く。その反転は、どの研究にも提起されていない。プログラムを書かない人のためにあるのは、被害の記録だ：2026年6月の、「バイブコーディング」の道具で作られた9,041のアプリケーションについての研究は、監査したものの91%に脆弱性を見つけた（arXiv 2606.23130）。
• 必須の提出物としての、検証済み・信じた・盲点の報告（第12段）。問題は数字で診断されている：エージェントの完了宣言は、実際の承認を28から38ポイント上回り（SpecHarness、arXiv 2609.29921）、エージェント間の引き継ぎで「未検証」のラベルを失うと、危険な行動の承認が5%から60%に跳ね上がる（arXiv 2609.20211）。誰もそれを、一人の人に向けた説明責任の書式に変えていない。
• 自分のテストを持つ計器（第7段）。「決定を養う数字は、自分のテストを持つプログラムで計測する」というルールは、私が見つけたどの出典にも書かれていない。
• 完全なはしご、適格性から監視と振り返りまで。見つけた最も長いものは十段階。ほぼすべてがマージで終わる。AI-DLCとOsmaniだけが運用に触れる。
• ルールとしての期限なし（D-030）。反論されているのではなく、不在だ。
• 組み合わせ。 コードを読まない者は厳密にテストしない（Ronacher、Yegge）。厳密にテストする者は読む（Beck、Osmani、Hashimoto、GitHub）。Uncle Bobとold-coderはその交差を破るが、プロジェクト単位ではなくタスク単位でそうしている。

F.4 答えなければならない反論と、私がどう答えるか

Birgitta Böckelerは2026年8月に、エージェントにテストが先のサイクルを頼んでも品質が確実には改善しないことを計測した。エージェントはときに赤を装い、あるいは最初から通るようにテストより先に実装するからだ（martinfowler.com）。彼女の研究の中で、見張るテストと飾るテストを区別した唯一のものは、ミューテーションテストだった。同じ年の別の研究は、モデルが自分自身の誤りの三分の一を是認することを示し（arXiv 2605.21537）、また別の研究は、きれいなセッションと別のモデルの組み合わせの方が、同じモデルの二つのセッションより多くの誤りを見つけることを示している（arXiv 2610.01471）。

深刻な反論であり、私はそれを受け止める。方法の答えは三つの部品からなる（D-033）。第8段では、赤は語りではなくレシートだ：正確なコマンド、それが走った対象のバージョン、失敗の数、終了コードを、そのまま貼る。オーナーが一つのコマンドでもう一度走らせられるように、そしてそれをブロックごとに一度、無作為に選んだ保留項目で実際に行うように。第13段では、別のセッションによる監査が、それらのレシートの標本をもう一度走らせる。そして第9段では、ミューテーションテストが利用者のいるどんなプロジェクトでも必須だ（実際の利用者がいないときだけ任意のままになる）。各ブロックの締めにその得点をカバレッジの隣に置く。三つの部品のどれも、オーナーがコードを読むことを要求しない。三つとも、赤を装う方が走らせるより高くつくようにする。

F.5 方法を別の形式に翻案したもの、そしてそれが教えてくれたこと

2026年、オスカル・シュミッツは『El Arte de Forjar Sistemas』（『システムを鍛える技』、 191ページ）を出版した。この方法を翻案した小説で、梯子を取り上げて虚構として語る。決める持ち主と、作るチームがいる。上に挙げたものの意味での関連研究ではない——別の方法を提案していない——が、以前には起きていなかったことだ：誰かが別の作品を生むために全コーパスを読んだ。主張ごとに方法の文面と照合して検証し、その検証の報告はリポジトリに残してある。

そこから出てきたもの、そしてそれが参照ではなくこのパートにある理由：参照は自分の事例で、日付とコミットを持つ。小説は事例ではない。実際にしてくれたのは二つのことだ。

私のものより良い四つの定式化をもたらし、この出典表示とともにこの文書に採り入れた：「カバレッジはテストを数える。赤はそれが役に立つかを言う」（第9段）、「持ち主は持ち主ではない：借主だ」（第20段）、段を小さくするのは完全にやったあとに至ることだという考え（パートD）、そして復旧マニュアルの試行は時間、つまずき、理解されなかった語を記録しなければならないということ（第20段）。五つ目は提供者への二十五の質問の紙だ：完全性の検証を、持ち主が会合に持っていく一枚の紙にまとめるという考えは彼のものだ。このリポジトリの二十五の質問は方法の契約からゼロから書いた。彼の版は彼の作品であり、権利は留保されているからだ。

そしてどの監査も見ていなかった方法の構造的な欠陥を示した。これがすべての中で最も価値がある：著者は参照の六つの数字を続けて一つの誤りもなく再現し、附属書Hの四十五のうち二十七のルールを飛ばした。見落としたのではない：この文書が一度も名前を挙げていなかったので、それらが存在することを知らなかったのだ。すべてを読んで方法を適用する読者は、理由がわからないまま公開された五つの関門で止まることになる。それが、附属書がパートA、パートCの冒頭、そしてそれを担う六つの段のカードで名前を挙げられている理由であり、どれかのカードが名前を挙げるのをやめたら赤くなる検証が連鎖にある理由だ。第23段は振り返りが梯子への変更提案として戻ってくることを求める。これは読者から来た最初のものだ。

この方法を地図の上に置くのに役立つ枠組みは、2026年6月のMacedoの分類法だ（arXiv 2606.04967）：六つの次元（仕様、文脈、役割、実行、検証、可搬性）と、比較したフレームワークのどれも六つを同時には覆っておらず、プロセスの深さと可搬性のあいだに構造的なトレードオフがあるという確認である。Urazukeは六つすべてを狙い、英語の正確なプロンプトとツール中立への賭けは、まさにそのトレードオフを破ろうとする試みだ。