プロダクト
現在、Intent-System はこう動いています。
フィードバック経路を持つ二領域の運用ループです。確立済みの mode では実装と review を timer loop で動かします。新しい preview の Orchestrator Mode では、実装と review を loopless にし、1 つの orchestrator がメッセージで作業を委譲します。ただし正本は intent-cli と GitHub です。
ノードにホバーすると、関連する受け渡し / 通過 / 差し戻しの経路が浮かび上がる。
Ⓐ 意図
人間によるキュレーション
- 推定意図の取り込み — エージェントが提案、人間が採否を決める。
- ツリー配置 — Purpose / User Context / Means。
- クラリフィケーションループ — 曖昧さが解けるまで。
- 昇格: inferred → clarified → canonical。
- 実装可能な issue へスライス。
Ⓑ 実装
エージェントによる駆動
- 実装スレッドが Issue を拾う ── 確立済みの timer loop、または preview mode の orchestrator message によって開始します。
- エージェントは Issue に埋め込まれた情報のみを文脈にして実装し、PR は ai-develop に向けて開かれます。
- AI レビュー ── 別 cwd の review thread が、読み込んだ Intent ツリーと packet を基準に実装と差分を取ります。通過は次へ。差し戻しは Ⓐ-③ にクラリフィケーションを戻します。
- ai-develop ／ main への昇格前に、人間が最終承認します。
- クローズアウトが diff を canonical としてツリーに書き戻します。
Ⓒ Intent-Bug フィードバック
リリース後の不具合も同じループに戻る
実装は完璧にはなりません。それは前提です ── Intent-System はリリース後のフィードバック経路を、ループの「例外」ではなく「正規の一部」として扱います。出てきた不具合や想定外の挙動は、ひとつずつ Intent-Bug Issue として起票され、Intent ツリーに照らしてトリアージされます:
- 実装バグ. 意図は正しいが、コードが守れていなかったケース。同じ意図スライスのまま Ⓑ-① に再投入し、ai-develop 上で修正します。
- 意図の漏れ. 意図が何も言っていなかった点について、実装者が独自に判断し、結果が望むものではなかったケース。Ⓐ-③ にクラリフィケーションとして再投入し、ツリーを昇格させてから、鋭くなった意図で改めて Issue を切り出します。
どちらの場合も、最後は同じ AI レビュー → 人間承認 → 昇格の経路で main に出ていきます。この線を正しく引けることで、ツリーは「ただ膨らむ」のではなく「鍛えられて強くなっていく」ものになります。
実装レベルの詳細を見るには?
本ページは 2 領域の運用モデルです。次ページではスレッド分割にズームインし、Orchestrator Mode ページでは新しい message-driven preview を説明します。