Kronuz/campaign

campaign は何をしますか？

リーダー（メインセッション）は所有者の目標をクエストに変換します。コントリビューター エージェントは各クエストを自身のブランチで完了します。機械作業はジョブキューに送られ、エージェントが待機しないまま正確なコミットで実行されます。レビュアーエージェントは、リスクが必要とする場合に、新鮮なコンテキストからクエストを検証します。campaign land は、その正確なコードでチェックが合格し、各基準が必要とする証拠が揃い、必要な各レビューが目にしたコードに対して承認された場合にのみ、クエストをmainに統合します。重要なものはすべてリポジトリに存在するため、リーダーを含むあらゆるエージェントは交換可能です。

goals ─► PLAN ─► quests ─► campaign start ─► contributor ─► jobs (quiet) ─► evidence
                                                  │                              │
                                                  └─► reviewer (by risk) ─► accept ─► campaign land

不変条件

1. 証拠、物語ではない。 チェックは、ジョブがランドされるコード上で実行した場合にのみカウントされます。ジャーナルの行やレビュアーの発言は、決してグリーンテストにはなりません。
2. ファイルセットごとに1人の書き手。 campaign start は重複するファイルセットを拒否します。land はクエストのセット外の変更とリーダーのファイルへの編集を拒否します。
3. コードより先に基準。 リーダーは各クエストの合格基準と各基準が必要とする証拠を記述します。コントリビューターはこれらを決して編集せず、変更されたクエストファイルは以前の承認を無効にします。
4. レビューはリスクに従う。 リスクごとに1人の新鮮なレビュアー。承認は、そのレビューが確認したコードとレビューの正確な内容をカバーします。
5. 何も静かに弱められない。 リスクの引き下げ、レンズやチェックの削除、レビューの放棄、CIなしでのランディング、手動でのランディング記録には理由が必要であり、ツールがそれを記録します。
6. 状態はファイルに生きる。 .campaign/<campaign>/ と git がキャンペーンの実行方法を保持します。プロダクトの内容は、それが記述するリポジトリの docs/ に格納されます。
7. エージェントは決してマシンを待たず、測定は分離なしには実行されません。
8. 所有者は目標、スコープ、およびユーザー可視動作の削除や狭小化を決定します。 リーダーは残りを決定し、PLAN.md に記録します。Campaign は決してマシンをレンタルせず、その他の課金可能なリソースを作成しません。

ロール

ロール	役割	書き込むもの
所有者（人間）	目標、非目標、予約決定	PLAN.md の目標
リーダー（メインセッション）	クエストの計画、エージェントの起動、レビューの承認、ランディング、所有者への報告	state.json（campaign 経由のみ）、クエストファイル、PLAN.md、main
コントリビューター（campaign-contributor エージェント）	割り当てられた1つのクエストまたはタスク	自身のブランチとジャーナル
レビュアー（campaign-reviewer エージェント）	1つのレンズを通して1つのクエストを新鮮なコンテキストからレビュー	1つのレビューファイル

コントリビューターの割り当ては作業の種類を指定します。実装以外の各割り当てには、references/assignments/<name>.md にメソッドがあります。リーダーは、習慣ではなく作業に基づいて、割り当て、モデルティア、および労力を毎回の起動時に選択します。

割り当て	対象	ティア、労力
implementation	具体的な基準を持つ機能と修正	経済的、低および通常リスクには中; 高およびクリティカルリスク、または経済的な試みが停滞した後には強力、高
design	重要な計画のためのクエストリスト。フォーマット、プロトコル、耐久性、並行性	強力、高; 確定直前の設計には最大
research	稀に。メカニズム自体が制約である場合	強力、最大
performance	プロファイリングと最適化	強力、高
exploration	探索バッチの1つのターゲット、またはクイッククエスチョン	経済的、中
documentation	ドキュメント、ガイド、README	経済的、中
maintenance	リポジトリ全体にわたる1つの機械的な変更	経済的、中

レビュアーは強力ティアを高労力で使用します（クリティカルクエストには最大）。クリティカルクエストと計画チャレンジでは、ハーネスが提供する場合、別のモデルファミリーのレビュアーを使用します。各ハーネスのティアごとのモデルは references/harness.md にあります。デフォルトは結果に基づいて変更します（campaign usage、基準達成、手直し）。価格だけで変更しないでください。リーダーは小さな編集（5行の修正、些細な競合）を自身で行います。起動にはより多くのコストがかかります。

キャンペーンを開始する

1. ホームリポジトリのメインチェックアウトで: campaign init --name NAME [--ci github]。所有者は .campaign/<campaign>/PLAN.md に目標、非目標、制約、予約決定を記述します。
2. 目標をクエストに分割します: campaign new ID --title T --risk R --files GLOBS [--needs IDS] [--after IDS] [--provides C] [--consumes C] [--milestone M] --check NAME[:LEVEL[:MIN]]=CMD。各クエストファイル（.campaign/<campaign>/quests/ID.md）を記入します: 成果、基準A1...（それぞれが必要とする証拠（下記の証拠））、契約、決定、早期にランドできるもの。
3. アーキテクチャが重要な場合、1人のレビュアー（レンズ design）が、何かが構築される前に計画とクエストリストに挑戦します。これが待つ価値のある唯一のレビューです。

クエスト

• サイズ: レビュアーが頭に入れておける、完全で意味のある振る舞いを提供する最小の変更。通常は数百から約1,500行。大きいものは分割します。独自のランディングに値しない変更は、それがサービスするクエストに組み込みます。
• needs はクエストが開始する前にランドされなければなりません。after はクエストがランドされる前にランドされなければなりません。クエストは、その依存関係のクエストファイルが契約を固定している場合にのみ、after 依存関係に対して開始できます。
• 契約（--provides、--consumes）はAPI、フォーマット、プロトコルを指定するため、campaign check は2つのクエストが1つに触れていることを認識します。
• タスク: 1つのクエスト内の並列ライター（campaign start ID --task T --files GLOBS）、リーダーによってクエストブランチにマージされます。クエストはまだ1回レビューされます。
• インクリメント: campaign land ID --upto COMMIT --reason R は、クエストファイルの「早期にランド可能」が許可するプレフィックス（振る舞いを保持するリファクタリング、テスト、未使用の内部API、無効化スイッチの背後にあるコード）をランドします。決して早期にランドしてはいけないもの: ディスクまたはワイヤ上のバイト、公開API、ユーザー可視動作、またはレビューが存在する部分。
• リポジトリ間作業 は、after によって順序付けられた複数のクエスト（--repo PATH）であり、すべてのリポジトリのコミットを固定する統合ジョブ（--ref NAME=PATH@REF）があります。ランディングは順序付けられ、アトミックではありません。各中間状態は動作しなければなりません。
• メッセージ: 機械上の任意のキャンペーンで、自分が作業していないクエストに対して所見を持つエージェントは、campaign message NAME:ID "text" --from WHO を送信します。クエストは、そのジャーナルの1つがID（msg-N）で応答するか、リーダーがクローズする（campaign message ID --close msg-N --reason R）までランドできません。NAME: はそのキャンペーンのリーダーに書き込み、ランディングをブロックすることはありません。詳細と他の機械については references/host.md、メッセージを参照してください。
• スコープ変更: 新しい要求は最初にクエストファイル（基準、または単独でランドできる場合は独自のクエスト）に入れられ、次にコントリビューターに渡されます。置き換えられた作業は campaign set ID status=dropped reason=... で処理します。

直接パスを優先

次のステップを決定するものだけがそれをブロックします。クエストのゲートチェック（--check: ビルド、テスト、およびリスクが必要とする証拠）は、そのランディングをブロックします。遅延チェック（--later: 他のプラットフォーム、長時間の浸漬、完全マトリックス、拡張ファジング）は、ランドされたコードに低優先度でキューされ、マイルストーンがクローズされる前にグリーンでなければなりません。赤は campaign check のエラーです。前進修正またはリバートを行い、その後 campaign verify ID --deferred で main 上で再実行します。高またはクリティカルリスクが必要とする証拠（並行性にはTSan、デコーダにはファジング、耐久性にはクラッシュモデル）は常にゲートです。遅いCIワークフローも同じ方法で非ゲートにできます（campaign config ci_later=NAME,...）。

クエストを実行する

1. campaign start ID は、独自のワークツリーとジャーナルを持つ quest/<campaign>/ID を作成します。コントリビューターをバックグラウンドで起動し、メッセージで再開できるようにし、「コントリビューター」プロンプト（references/prompts.md）を使用します。準備ができていて、互いに素で、同じ機械を待っていない場合にのみ、クエストを並列実行します。
2. コントリビューターは自身のワークツリーで作業し、ジャーナルを最新に保ち、証拠をジョブとして生成します: campaign job submit --quest ID --level L --minutes M -- CMD および campaign verify ID。ジョブのみが残った場合、それらのIDを記録してターンを終了します。
3. リーダーは1つのバックグラウンド campaign wait --commits（ジョブが終了するか、ブランチが動くか、メッセージが到着するまでトークンは不要）で待機し、コンテキストが小さいうち（約150kトークン）にメッセージでコントリビューターを再開します。より大きなコンテキスト、またはそれを再開できないハーネスは、「再開」プロンプト付きの新しいコントリビューターを取得し、ジャーナルとジョブレコードから再構築します。
4. ジャーナルに「レビュー準備完了」と記載されたら、リーダーは status=review を設定し、リスクが必要とするレビュアーを起動します。各レビュアーは .campaign/<campaign>/reviews/ID-LENS.md を書き込みます。リーダーはブロッキング所見をIDでコントリビューターに中継します。
5. レビューが承認されたら campaign accept ID LENS を実行します。確認ジョブ（リスクとレビュー）を伴う変更後も同様です。承認と共にレビューファイルをコミットします。次に campaign land ID を実行します。これによりクエストのワークツリー、マージされたブランチ、ビルドスロットも削除し、保持したものを記録します。

探索バッチ

探索する価値のあるリスト（新しいベンチマークの負け行、プロファイルのホットスポット、薄く証明されたコード、小さなバグのバックログ）には、現在の main 上の新鮮な測定から、複数の経済的コントリビューターを一度に送信します。各ターゲットに1つずつ。ターゲットは references/assignments/exploration.md から取得します。バッチのサイズは、ターゲットとリーダーがレビューおよびランドできるものに基づいて決定し、決してアイドルクォータに基づいてはなりません。

リスクとレビュー

リスク（最初に一致したものが勝ち）	構築前	最終ランディング前
クリティカル: 不可逆（リリース用のフォーマットまたはプロトコルの凍結、ユーザーデータの移行、ユーザー可視動作の削除）	所有者の承認; design レビュー	高リスクレビューに加え、レビュアー自身が実行した受け入れ証拠
高: 永続的なフォーマット、ワイヤプロトコル、耐久性、並行性、セキュリティ面、共有公開API	決定を元に戻すのにコストがかかる場合は design レビュー	支配的なリスクのレンズによる1つのレビュー（durability、security、または correctness）
通常: 通常の機能と修正	—	1つの correctness レビュー、または強力な証拠を伴う小さな変更には --waive REASON
低: ドキュメント、テスト、ツール、機械的な編集、振る舞いを保持するリファクタリング	—	チェックがグリーン; リーダーが差分を読む

• デフォルトで1人のレビュアー、クエストが提起するすべてのリスク質問を扱います（プロンプトは3〜5つを指定）。別の専門知識や独立性が必要な質問に対してのみ2人目を使用します。
• レビューはそれが見たものにバインドされます。 レビューしたコミット（Commit:）、評決、およびID、ブロッキング（はい/いいえ）、種類（欠陥、ギャップ、ニット）を1行ごとに含む所見テーブルを指定します。APPROVE はそのコミットのコードをカバーします。.campaign/ のみに触れるコミットはそれを保持します。承認後にレビューを編集すると承認は無効になります。
• 修正はジョブで確認され、再レビューではありません。 ブロッキング所見ごとに、固定されたコミットでプローブまたは新しいテストをジョブとして再実行し、次に campaign accept ID LENS --confirm C1=JOB --confirm C2=JOB を実行します。ジョブはクエストのリポジトリ内の承認されたコードで合格した場合にのみ確認します。ブロッキング欠陥には変更されたコードが必要です。ツールは、同じプローブがレビューされたコミットで失敗したかどうかを記録します。レビューが決して見なかったファイルを変更する修正は、レビュアーに戻されます（レビューは固定されたコミットを指定して承認します）。--fix-scope REASON がメカニズムを追加しない理由を説明する場合を除きます（所見のリグレッションテスト）。
• 2回の修正ラウンドで停止。 3回目はクエストまたは設計が間違っていることを意味します。再計画するか、所有者に問い合わせます。ブロッキングではない所見はフォローアップクエストになるか、理由とともに破棄されます。
• 設計は1回レビューされます。 争われた振る舞いは、別のテキストラウンドではなく、実行可能モデルまたはテストで解決します。
• クエストが通過しなければならないものは、記録上でのみ変更されます: campaign set ID ... --weaken REASON はリスクを引き下げ、レンズを削除し、チェックを削除、変更、または延期します。変更は履歴に保持され、campaign status ID で表示され、承認を無効にします。リスクが必要とするレビュー（低リスク以上のコードレビュー、クリティカルには設計レビュー）は削除できません。レビューが存在すると放棄は拒否されます。
• イベントベースのシステムレビュー（カレンダーベースではない）: campaign check が2つのクエストが1つのファイルまたは1つの契約を変更していると報告した場合、その特定の質問について1人のレビュアー（レンズ system）に依頼します。
• イールド: campaign status --reviews は評決とブロッキング欠陥をカウントします。オプションのレビュー（通常リスク）が約5つのクエストにわたって実質的なものを何も見つけなかった場合、その種類に対してドロップされます。高およびクリティカルレビューはイールドによってドロップされることはありません。

証拠

クエストファイルの各基準は、必要な証拠を指定します。ジャーナルの証拠テーブルは基準ごとに1行を与え、ランディングはランドされるコードで各行をチェックします。

基準	その行が指定しなければならないもの
- A1 ...（タグなし）	そのコードで合格したジョブ（それ自体、または同じジョブの再実行）
- A2 [artifact] ...	クエストのリポジトリにコミットされた path
- A3 [decision] ...	PLAN.md の決定テーブル内のID
- A4 [manual] ...	誰が何を手動でチェックしたか。手動として表示され、自動証明としては決して表示されない

証明は主張に比例します（references/review.md）: テストは値をチェックし、カウントではありません。修正には、それがなければ失敗するテストがあります。主張には、テストが殺すミュータントがあります。サニタイザーは別のビルドで使用します。パフォーマンスの主張は references/measurement.md に従います: 指定されたコミットでの前後、exclusive は何かを決定する数値、正直な大きさ。

機械作業

レベル	対象	分離（quiet）
none	小さなシングルスレッドプローブ	保留なし
light	ビルド、テストスイート、ファジング	一度にいくつか、nice 19
strict	スモークタイミング、振る舞い実行	Linuxでは独自のコア。macOSでは単独
exclusive	何かを決定する数値	機械全体をロック、すべてのCPU、nice -20

ジョブレベルはジョブごとに名前を付けます。campaign wait はレベルに基づいてロックを保持します。ジョブは期待どおりに持続します。references/host.md で許可される並列性を定義します。

CI（GitHub Actions）

campaign init --ci github は .github/workflows/campaign.yml を生成し、プッシュで campaign ci を実行します。ワークフローはキャンペーンの queue からのジョブを実行します（レベルは references/host.md のルールに従います）。リモートランナー（--runner OS=LABEL）はクラウドで実行します。プルリクエストワークフローも追加します（.github/workflows/campaign-pr.yml）: campaign start で作成されたブランチへのプッシュで、quiet レベル light で campaign ci --ci を実行します。PR の CI はジョブキューを注入しません。

ジョブキュー

campaign submit はジョブを queue/ に置き、campaign dequeue がそれを実行します（自動的か、campaign worker 経由）。モニタリング用の campaign queue、クリア用の campaign queue --clear。queue/ は機械にローカルであり、異なるマシン上のリーダーはリモートキュー（references/host.md）を使用します。

キャンペーン状態

campaign status は、リーダーが知る必要があることを1つのビューで表示します。campaign status ID はクエストの進行状況を詳細に表示します。campaign log はキャンペーンのイベントログを表示します。campaign check はクエストがランド可能かどうか、何がブロックしているかをチェックします。campaign check ID は単一のクエストをチェックします。campaign check --all はすべてをチェックします。campaign cleanup は古いワークツリーとブランチを削除します。campaign reset ID はクエストをリセットします（ワークツリーを削除し、ステータスを planned に設定）。

測定

方法	対象	活用
time	単一の実時間値	高速プローブ
benchmark	統計的比較、regression 検出	履歴トレンド、決定論
profile	ホットスポット特定	最適化ガイド

references/measurement.md にプロトコルがあります。

ベストプラクティス

• クエストは小さく保ち、焦点を絞ります。
• 明確な合格基準を記述します。
• 適切なリスクレベルを使用します。
• リーダーがオーバーロードしないようにします。
• 適切な割り当てとモデルティアを使用します。
• 新鮮なレビュアーを使用します。
• すべての証拠をリポジトリに記録します。
• 無効にしないでください。
• 結果に基づいて調整します。

関連リファレンス

• references/prompts.md - エージェントプロンプト
• references/assignments/ - 割り当て定義
• references/host.md - ホスト設定
• references/harness.md - ハーネスモデル
• references/review.md - レビュープロトコル
• references/measurement.md - 測定プロトコル