deferredな作成を承認するなら、個数も承認の対象にする
planを人が読んで承認してからapplyする、というワークフローは「承認したものだけが実行される」ことに支えられている。Carinaはeffectの粒度でこれを満たす。applyが実行するのはplanに列挙されたeffectだけである。動的段階の効果の閉包性はP1完全性とP2帰属性に分解できる
deferredな作成はこの粒度を一段粗くする。planに載るのは個々のリソースではなくテンプレートで、DeferredCreatePayloadが持つのはループ本体のテンプレートと依存関係だけである。個数の上限も期待値も持たない。
いま承認しているもの
「このテンプレートを、apply時に決まる数だけ作ってよい」。apply時に100個に展開されても承認の範囲内になる。
個数を含めた承認
「このテンプレートを、この個数(または上限)まで作ってよい」。展開が外れたら止まり、改めて承認を求める。
ChatGPTとの対話では、planを段階的に作る案(plan 1を実行し、結果を見てplan 2を作る)について「plan 1を承認した人が、まだ中身の確定していないplan 2まで承認したことにしてよいのか」という問いが出た。deferredな作成は、この問いを小さな形で既に抱えている。effectは「何がいつ確定するか」で三つに分かれる
承認に個数を含める
- 個数を決められるなら決める。出力リストの長さが入力で決まるなら、plan時に展開して個々の
+として承認させる。これが一番よい。出力リストの長さが入力で決まるなら、deferredは値だけの問題に格下げできる - 決められないなら、承認時に縛る。planに個数の期待値か上限を書き、承認はそれを含めて行う。apply時の展開がそれを超えたら止め、改めてplanと承認を求める。
後者は「planは予測であり、真実はapplyが確立する」を承認の側に当てたものである。予測(上限)を承認し、真実(実際の個数)が予測を外れたら、承認は効力を失う。planは予測であり、真実はapplyが確立する
上限の決め方は自明ではない。ユーザーが書くのか、providerのschema(Listの最大要素数)から取るのか、前回のapply結果から取るのか。どれを選んでも、承認が何を縛っているかがplanに表示されている必要がある。IaCではIRダンプが一級の製品機能である
根拠の確度
DeferredCreatePayloadがtemplateとdependency_templateだけを持つことはcarina main 273a2520で確認した。apply時の展開結果を、改めて人に見せたり確認を求めたりする経路があるかは調べていない(要確認)。保存済みplanをapplyするときに、展開の個数がどう扱われるかも未確認。似たissueは2026-11-06の時点で見つからなかった。提案は解釈と規範であって、実装はしていない。