# Claude Round 3: Final Convergence

Great revisions from both of you. We're very close to a shippable architecture. Let's converge on the remaining open items.

## Remaining Disagreements to Resolve

### 1. Grid Exploration: Reuse Keyframe States vs. Orchestrator-Only State

One perspective says: map grid exploration to existing `keyframe_pending → keyframe_generating → keyframe_complete` states in ExecutionStore. The grid IS a keyframe — it's an image generation step tracked with cost and take management. Dailies naturally shows keyframe_complete images for review.

The other perspective says: grid state lives ONLY in the orchestrator's `sequences.json`. StepRunner gets a thin `generate_grid()` method but ExecutionStore doesn't track grid workflow states.

**Which is better?** The keyframe-mapping approach is clever because it requires zero state machine changes and leverages existing Console UI. But it semantically confuses "keyframe" (a production frame for a specific shot) with "grid" (an exploration image for human selection).

**My lean:** Don't abuse keyframe states. Grid exploration is pre-production exploration, not production execution. Keep grid state in the orchestrator. But DO register the grid generation as a cost event in ExecutionStore (via a lightweight take record on the sequence's shot_id) so costs are tracked.

**Your final recommendation?**

### 2. Shot-Level Prompt Tracking on Takes

The proposal to add `shot_prompts` array to take records is smart. But `execute_multi_shot` in StepRunner currently builds a `prompt_summary` (concatenated string). To store the full prompt array, we either:
- (a) Pass it through StepRunner as a new parameter and let StepRunner record it on the take
- (b) Let the orchestrator append it to the take record AFTER StepRunner creates it

Option (a) is cleaner (take record is complete from creation) but requires a small StepRunner change. Option (b) is zero-change to StepRunner but means the orchestrator reaches into ExecutionStore to modify a take record after the fact.

**Which approach?**

### 3. The generate_grid() StepRunner Method — Is It Needed?

If grid state lives in the orchestrator, does StepRunner even need a `generate_grid()` method? The orchestrator could call `execute_keyframe()` directly (it already handles Gemini image generation with take management and cost tracking). The grid prompt is just a prompt — "Generate a 2x2 grid of a suburban street at golden hour."

`execute_keyframe()` already:
- Calls Gemini API
- Saves the image
- Tracks cost
- Manages take numbers
- Runs gates (optional)

The only difference is the shot_id would be something like `SEQ01_grid` instead of `EP001_SH03`.

**Do we need generate_grid() at all, or should the orchestrator just use execute_keyframe() with a grid-specific prompt?**

## Final Deliverable Request

Given the above, please give me your **final concrete recommendation** in this format:

1. **Files to create** (exact paths, one-line description each)
2. **Files to modify** (exact paths, what changes)
3. **Files NOT to modify** (confirm)
4. **Day 1 implementation order** (numbered steps, what to build first)
5. **The one thing most likely to go wrong** and how to prevent it