re0-memo

完了したサイクルを、次のサイクルが実際に活用できる教訓に変えます。

目標

re0-memo は、成果物を擁護することなく、作業サイクルから長く活用できる学びを抽出します。サイクルが実行され、テストに合格しても、目指すべきものを取り違えている場合があります。出力は変更履歴でもセラピーノートでもありません。何がうまくいき、何がビルドを誤った方向に導き、次の試行でどのゲートを通過すべきかを記録した、ローカルの、証拠に裏付けられた記録です。

成果物が完成した、失敗した、期待外れだった、または曖昧で、次のエージェントに勢いよりもサイクルの教訓が必要な場合は、re0-memo を使ってください。

ワークフロー

1. 元の目標、最終成果物、QA の証拠、ユーザーからの不満、ローカルの計画メモを読みます。
2. 機能した資産と、誤解を招く進捗を切り分けます。再利用に値する契約、スキーマ、テスト、サービス、用語、例と、生産的に見えただけの UI、パネル、足場、抽象化を区別します。
3. 記録する前に一般化します。フィードバックが多数の具体的な苦情として届いた場合は、記録する前に、それらをより上位の共通パターンにまとめます。多くの項目に対する多数の具体的な指摘には、通常、共通の根本的な不足があります。教訓として記録するのは根本原因とそのパターン群です。個々の具体例は教訓そのものではなく、証拠としてその下に残します。
4. 各失敗を気分ではなく、アンチパターンとして名付けます。
5. 繰り返し発生した失敗や影響の大きい失敗を、次の試行に向けた品質ゲートに変えます。
6. 曖昧なユーザーの指示を、新しいエージェントが使えるアーキテクチャ用語に変換します。
7. サイクルに関するローカルドキュメントを作成または更新します。教訓を記録した re0-memo と、次のサイクルの契約、ゲート、用語をまとめた計画を用意します。
8. そのドキュメントだけを読んだゼロから始めるエージェントが、同じ失敗を避けられることを確認します。

ルール

• 成果物を擁護しないでください。プロダクトの目標を外したなら、何が外れたのかを述べます。
• 変更履歴を書かないでください。ファイルの一覧や作業量の要約は教訓ではありません。
• 具体的な苦情を、そのまま教訓として書き起こさないでください。報告されたケースだけを直す教訓では、システムが人間の介在を必要とする状態のままです。誰かが指摘しなかった場所で、同じ種類の失敗が再発します。個々の具体例はすべて、その一連の失敗全体を捉えるパターンへと一般化してください。報告者の正確な言葉は証拠であり、ゲートではありません。
• 失敗した事例群を保持してください。失敗した経路もトレーニングデータです。
• 助言よりも明確なゲートを優先してください。
• サイクルから得た証拠を引用してください。目標、ファイルに関する事実、QA の出力、スクリーンショット、トランスクリプト、差分、ユーザーからのフィードバックなどが該当します。
• 次のエージェントが行動に移せないなら、それはまだ教訓ではありません。
• 来歴情報はローカルに保管してください。出荷する成果物に失敗の痕跡を語らせないでください。

検証

完了する前に、次を確認してください。

1. すべての教訓が、観察されたサイクルの証拠に結び付いている。
2. すべてのアンチパターンが、具体的な失敗モードと、それを検出するゲートを示している。
3. どの教訓も、単一の報告事例を言い換えただけのものではない。それぞれが失敗の一群を対象とし、きっかけとなった具体例は、その下に証拠として記されている。
4. 新しいエージェントが、以前のセッション全体を読まずに、何を保持し、何を破棄し、何を最初にテストすべきか判断できる。