実用ガイド7 分
changes と workflow
proposal、worktree、apply ループ、acceptance、merge が日々どう噛み合うかを整理します。
Conflux は「change を主単位として扱う」と理解がかなり楽になります。
change ディレクトリが契約になる
実務上、各 OpenSpec change は次の 3 つで契約を表します。
proposal.md: 何を変えるかtasks.md: 実装タスクspecs/.../spec.md: 期待する振る舞い
acceptance 役が意図を推測しなくても判定できるくらい具体的に書かれているほど、Conflux は強くなります。
日々の基本ループ
典型的には次の流れです。
- proposal を作る、または磨く
- proposal をコミットしてリポジトリを clean にする
cflxまたはcflx runを実行する- diff、ログ、acceptance verdict を見る
- archive / resolve / split のどれに進むか判断する
worktree が効く理由
Conflux は git worktree で change を隔離します。実務上の効き目は次の 2 つです。
- 独立した change を並列に進められる
- 失敗した change が main workspace を汚しにくい
これは、単一のチャットベース開発と Conflux を分ける大きな差です。
実務ルール
一緒にレビューするとつらい作業は、別々の OpenSpec change に分けるべきです。つまり別 worktree にする価値があります。
TUI と headless の使い分け
実行対象を対話的に決めたいなら TUI が向いています。
Terminal
cflxどの change を回すか決まっているなら headless が向いています。
Terminal
cflx run cflx run --change add-feature-xacceptance は後付けの飾りではない
Conflux が実装役と acceptance 役を明示的に分けるのは重要です。これによって:
- 実装側は速度を出しやすくなり
- acceptance 側は保守的に判断でき
- 自己評価の偏りを減らせます
この分離を飛ばすと、単一エージェント運用の盲点をそのまま再現しやすいです。
change を分割するべき時
次のような時は split を検討します。
tasks.mdが複数領域に広がりすぎている- acceptance が独立した理由で何度も落ちる
- diff が大きすぎて人間が追いきれない
- 一部だけ先に終えて merge したい
運用チェックポイント
安定して回すための最低限の確認です。
| チェック | 意味 |
|---|---|
git status が clean | 無関係な変更混入を防ぐ |
| proposal がコミット済み | 再現性を上げる |
| tasks が具体的 | acceptance が客観判定しやすい |
| change が狭い | エージェントの集中力とレビュー品質が上がる |
実行後に見るべきこと
run が終わったら次を見ます。
- diff は proposal / tasks を満たしているか
- acceptance 失敗は本当の不具合か、仕様不足か
- archive / merge して良いか、follow-up change に分けるべきか
この振り返りがあるからこそ、Conflux は「面白いデモ止まり」ではなく「使える開発フロー」になります。