factory-learn

factory-learn

このスキルの機能

factory-learn は、ソフトウェアファクトリーの継続的な改善に向けた学習ループを統括します。個々の学習関連スキル（team-init、team-levelup、change-init、change-clarify、change-publish、team-repair、evals-analyze）を調整し、ドラフトの指令を検証・公開済みの、最小限のチームコンテキストアセットへと移行させます。

factory-mission/references/executor.md にある共有実行エンジンのコントラクトに沿って、Kind-A DAG オーケストレーターとして動作します。

---

使用するタイミング

• セッションで得られた、苦労して得た学びを抽出し、チームの一元管理された team-ai-directives リポジトリにまとめたい場合。
• git のコミット履歴を調査して、過去のリバートやホットフィックスの背景にある理由（ChDR）を記録したい場合。
• 「Build to Delete」（Harness Decay チェック）を実行して、冗長なルールを削除したい場合。

使用しない場合：

• プロダクトレベルの仕様策定や開発を行う場合（代わりに factory-product または factory-mission を使用してください）。
• チームの指令リポジトリがまったく設定されていない場合（先に /team-setup を実行してください）。

---

ライフサイクル DAG とステップの解決

factory-learn は、固定の名前付きスキル DAG（fixed ステップ解決）を実装しています。

セッションの学びを扱うルート（セッション終了時のデフォルト）

1. specify（generate フェーズ） -> team-levelup を呼び出し、アクティブなセッションから候補となる Context Directive Record（CDR）とコンプライアンスを抽出します。
2. clarify⭐（clarify フェーズ） -> team-levelup を呼び出し、保留中の CDR をレビューします。evals-regression ゲートを適用します（品質の低下がないことを確認するため、verify サブフェーズとしてコンプライアンスの goldset を実行します）。
3. publish（build フェーズ） -> team-levelup を呼び出し、承認済みの CDR をパッケージ化してインデックスを作成し、team-ai-directives リポジトリを対象とするドラフト PR を作成します。
4. prune（analyze フェーズ） -> 指令ストアにクリーンアップボットを実行し、置き換えられたルール、矛盾するルール、古くなったルールを検出して、非推奨化を提案します。非推奨化の情報は team-levelup にフィードバックされます。

履歴の調査ルート（既存のコードベース向け）

1. init（generate フェーズ） -> change-init を呼び出し、git の履歴と課題トラッカーを調査して Change Decision Record（ChDR）を抽出します。
2. clarify⭐（clarify フェーズ） -> change-clarify を呼び出し、抽出した主張の出所を対話形式でレビューします。
3. publish（build フェーズ） -> change-publish を呼び出し、承認済みの ChDR を docs/adlc/memory/chdr/ に反映して、インデックスを再生成します。

メンテナンスと Build-to-Delete ルート（定期実行）

1. verify（verify フェーズ） -> team-repair --build-to-delete を実行します。ルールを一時的に無効にして goldset 評価を再実行します。各ルールについて、次の 2 つの問いを確認します。
   • Build-to-delete：ルールがなくてもモデルが合格する場合、そのルールを冗長としてマークします。
   • Promote-to-check（決定論的チェックを優先、EVAL-010）：決定論的チェック（ユニットテスト／バイナリ判定機／pre-commit フック／lint ルール／CI ジョブ）でルールを機械的に適用できる場合、昇格候補としてマークします。あいまいなルールを毎回のセッションに再注入する代わりに、チェックに一度だけコストをかけます。
2. clarify⭐ -> 冗長なルールの非推奨化と、機械的なルールの昇格を提案し、team-levelup に渡して人間によるレビューを受けます。昇格はアクション P — Promote to check（team-levelup Phase 2b）に振り分けられます。チェックが作成されて CI で実行されるようになったら、CDR は非推奨化されるか、簡潔なポインターに縮小されます。両方の提案は findings として公開されます。

ワークフローの振り返りルート

定期的またはオンデマンドで実行し、ほかのファクトリースキル（例：factory-mission、factory-product）の過去の実行を分析して、ワークフローのメモリーを生成します。

1. analyze（analyzeフェーズ）-> 完了／失敗した実行の共有状態（adlc-cli workflow statusを介して.adlc/workflows/runs/<run_id>/state.jsonを参照）と証拠ファイルをスキャンします。パターン、繰り返し発生するエラー、または成功した修正を特定します。
   • .adlc/drafts/{adr,pdr,chdr,cdr,evals}/にある未明確化のエントリー（フロントマター／見出しのステータスがproposed/discovered/draft）も確認し、それぞれを所見（Draft ID + 種類 + 経過期間）として提示します。session_end／file_editedフックが実行されたかどうかは問いません。
2. clarify⭐ -> 提案されたメモリー（activeとtentative）をユーザーに提示するか（ゲート付き／ハイブリッドモードの場合）、自動承認します（自律モードの場合）。
3. publish（buildフェーズ）-> 承認されたメモリーを.adlc/workflows/memory.jsonl（ワークスペース全体）に書き込みます。メモリーには重みと使用回数が付与され、古くなったメモリーや逆効果のメモリーは自動的にアーカイブされます。

---

共有エグゼキューターのオーバーライド

factory-learnは、共有エグゼキューターエンジンのプリミティブを次のようにオーバーライドします。

1. 公開先：external-repoに固定されています。設定済みのteam-ai-directivesリポジトリにドラフトプルリクエストを作成または更新します。公開先はディレクティブリポジトリのPRであるため、コメントバスはそのPR上で動作し、ステップの出力（決定事項、所見）はディレクティブPRへのマーカーコメントとして公開されます。
2. 出力タイプ：ステップでは、次のoutput_type割り当てを使用します。
   • specify/init → draft（CDR/ChDRのドラフトは.adlc/drafts/に残り、コメントバスには公開されません）
   • clarify⭐ → decision（承認／却下されたCDR/ChDRの一覧がディレクティブPR上のコメントバスに公開されます）
   • publish → artifact-ref（PR URL参照が公開され、内容はディスク上に残ります）
   • prune/verify → findings（冗長性／非推奨化のレポートがコメントバスに公開されます）
3. フィードバックループの取り込み：evals-analyzeの出力を自動的に取り込みます（仕様の問題によりアプリケーションテストが失敗した場合、evals-analyzeは自動的にteam-levelupにルーティングし、このオーケストレーターを起動します）。
4. 監督のデフォルト：hybridです。clarify⭐（CDR/ChDRエントリーの承認）と最終PRの作成時には、人間によるゲートが必ず適用されます。
5. 事前チェック：team-levelup、change-*、team-*スキルがインストールされていること、およびディレクティブリポジトリのパスが.adlc/init-options.jsonに設定されていることを確認します。