問題、severity、file:lineを構造化して返す。
CONCEPT
設計思想
「LLMを信用しないことで、LLMを最大限使う」という姿勢を3つの構造へ落とし込みます。
このページの内容
01
agentには発見・設計・実装の能力を求めますが、合否・遷移・完了条件を自己申告させません。能力ではなく権限を分離します。
判断は導出する
reviewerが返すのはfindingsであり、最終verdictではありません。CLIがfindingsからapprovedまたはneeds-fixを導出します。
blocking findingの有無から純関数で判定する。
iteration budgetと遷移をコードで管理する。
file:lineの実在、宣言された出力、tasksの完了もruntimeが機械検証します。モデルを差し替えても判定契約はCLI側に残ります。
02
stateはプロセスに住まない
実行の一次情報はbranch、change folder、GitHub、repository filesに置かれます。process、session、memoryにだけ存在する情報を作りません。
| 情報 | 置き場所 |
|---|---|
| job履歴・成果物 | branch-borne journal + change folder |
| 起動・再開・承認 | GitHub label・comment・PR state |
| 規律・review lens | repository内のMarkdown |
このため、回復は専用の裏経路ではなく、次の実行が同じstateから再導出する通常経路になります。
03
拡張はデータ
rulesとcustom reviewersはMarkdownとして追加します。reviewerの契約と防御がCLI側で標準化されているため、差分はprompt素材と設定だけです。
specrunner/rules/<step>/既存stepへ規律を追加specrunner/reviewers/<name>.md独立したreview lensを追加Pipelineの形データではなくコードの領分
どちらを選ぶか、定義をどう検証するかはRulesとCustom reviewersに実務手順をまとめています。
自己ホスティングによる検証
SpecRunner自身の機能はSpecRunnerのPipelineで実装・レビュー・mergeされています。escalation、差し戻し、修正、承認を含む履歴が、設計上の主張を検証する材料になります。
実装によってenforceされる保証と既知の限界は安全性と保証に分離して記載しています。