プロダクト
現在、Intent-System はこう動いています。
フィードバック経路を持つ二領域の運用ループです。リリース済み v0.22.0 の 4 スレッドモデルでは設計を人間との対話側に残すことも herdr に置くこともでき、同じ環境に集まるチームでは herdr-only が推奨されるプレビュー外の経路です。実装とレビューはループなしのまま、正本は intent-cli と GitHub に保ちます。3 スレッドのタイマーループは対応する代替手段として残ります。
ノードにホバーすると、関連する受け渡し / 通過 / 差し戻しの経路が浮かび上がる。
Ⓐ 意図
人間によるキュレーション
- 推定意図の取り込み — エージェントが提案、人間が採否を決める。
- ツリー配置 — Purpose / User Context / Means。
- クラリフィケーションループ — 曖昧さが解けるまで。
- 昇格: inferred → clarified → canonical。
- 実装可能な Issue へスライス。
Ⓑ 実装
エージェントによる駆動
- 実装スレッドが Issue を受け取る ── オーケストレーターが選択済みのセッション層を通じて委譲するか、代替手段のタイマーループが拾います。
- エージェントは Issue に埋め込まれた情報のみを文脈にして実装し、PR は設定済みの対象ブランチまたは選択した名前付きレーンに向けて開かれます。
- AI レビュー ── 別 cwd のレビュースレッドが、読み込んだ Intent ツリーとパケットを基準に実装と差分を取ります。通過は次へ。差し戻しは Ⓐ-③ に明確化を戻します。
- 設定済みの対象ブランチまたは main への昇格前に、人間が最終承認します。
- クローズアウトが差分を正本としてツリーに書き戻します。
Ⓒ Intent-Bug フィードバック
リリース後の不具合も同じループに戻る
実装は完璧にはなりません。それは前提です ── Intent-System はリリース後のフィードバック経路を、ループの「例外」ではなく「正規の一部」として扱います。出てきた不具合や想定外の挙動は、ひとつずつ Intent-Bug Issue として起票され、Intent ツリーに照らしてトリアージされます:
- 実装バグ. 意図は正しいが、コードが守れていなかったケース。同じ意図スライスのまま Ⓑ-① に再投入し、同じ設定済みレーン上で修正します。
- 意図の漏れ. 意図が何も言っていなかった点について、実装者が独自に判断し、結果が望むものではなかったケース。Ⓐ-③ に明確化として再投入し、ツリーを昇格させてから、鋭くなった意図で改めて Issue を切り出します。
どちらの場合も、最後は同じ AI レビュー → 人間承認 → 昇格の経路で main に出ていきます。この線を正しく引けることで、ツリーは「ただ膨らむ」のではなく「鍛えられて強くなっていく」ものになります。
実装レベルの詳細を見るには?
本ページは 2 領域の運用モデルです。次に、herdr-only の 4 スレッド経路、またはよりシンプルなタイマーループという代替手段を確認できます。