# Claude Round 2: Pushback & Follow-Up

Good analysis on the Execution vs Orchestration distinction. Option B is clearly right. But I have pushback on several points:

## 1. "Sequence is the Shot" — Too Simplistic?

You said map `SEQ01` → `shot_id` in ExecutionStore. But consider:

- **Multiple takes per sequence.** If I run SEQ08 three times with different start frames, I need 3 takes tracked. StepRunner.execute_multi_shot already handles this — it registers takes on the primary shot_id. So far so good.
- **But what about individual shot prompts?** If shot 3 of 5 in a sequence looks bad, I might want to tweak just that shot's prompt and re-run the whole sequence. The sequence-level tracking doesn't give me shot-level prompt iteration history. Is that fine? Or will I regret it later?
- **What about mixed-mode sequences?** Some sequences might work better as individual I2V shots (with specific start frames per shot) rather than one multi-shot call. Should the orchestrator support both modes per sequence?

## 2. Grid Exploration as StepRunner Method — Wrong Layer?

You proposed adding `execute_grid_exploration()` to StepRunner. But StepRunner is the **execution** layer — it runs API calls and manages state. Grid exploration is an **interactive** workflow:

1. Generate grid (API call — this IS StepRunner's job)
2. **Human picks a quadrant** (interactive — NOT StepRunner's job)
3. Crop the quadrant (image processing — utility)
4. Use as start frame (feeds into execute_multi_shot)

Steps 1 and 3 are StepRunner-appropriate. Step 2 requires human interaction. Shouldn't grid exploration live in the orchestrator (ClientSequenceRunner) with only the generation part in StepRunner? Or should we formalize it as `execute_keyframe` already exists — generate the grid, save it, let the human approve it, then the orchestrator crops?

The real question: **how does the Production Console's Dailies tab present grid options for human selection?**

## 3. Simplified State Machine — You Dodged the Hard Part

You said "just use a subset of states." But the ExecutionStore VALIDATES transitions. If I create a shot starting at `video_pending` and try to transition to `video_submitted`, it works. But `execute_multi_shot` internally calls `update_shot(sid, status="video_submitted")` — and if the shot doesn't exist yet, what happens?

The real workflow is:
1. `ClientSequenceRunner.init_sequence("SEQ01")` — creates the shot in ExecutionStore. What initial state?
2. Grid exploration (if needed) — what state during this? `grid_pending`? That doesn't exist.
3. Start frame approval — what state?
4. `execute_multi_shot` — transitions through video_submitted → video_processing → video_complete

Do we need to add `grid_exploring` and `start_frame_pending` states to the state machine? Or should grid/start frame state live entirely in the orchestrator, with ExecutionStore only seeing the video generation states?

## 4. Console Integration — Need More Detail

"Dailies tab will work out of the box" — I'm skeptical. The Dailies scanner reads `projects/{project}/state/starsend/shots/*.json` and renders video takes. But:

- It also shows prompt text, model used, cost, and gate verdicts. Multi-shot takes have a concatenated prompt summary, not individual shot prompts. Is that good enough for review?
- The Dailies tab has approve/reject buttons that transition state. Will `SEQ01` as a shot_id work with the existing approve flow?
- The **Board tab** shows episode structure. For client video, there's no episode structure — just 12 sequences mapped to song sections. Hiding it is fine short-term, but should we build a **Sequence Board** view eventually?

## 5. What About the CLI Tool?

`tools/test_via_steprunner.py` is the existing CLI for running generation through StepRunner. Should the new client workflow:
- (a) Extend test_via_steprunner.py with `--client-sequence SEQ01` flag?
- (b) Build a new `tools/client_generate.py` that wraps ClientSequenceRunner?
- (c) Both?

The CLI is how JT actually triggers generations during development. Console is for review. What's the right split?

## 6. ElementManager — Already Works

You flagged ElementManager schema mismatch as a risk. I want to push back: ElementManager.build_fal_elements() takes `element_ids` and `project` — it resolves refs from the filesystem (`refs/characters/{id}/`, `refs/props/{id}/`), not from the bible JSON. The bible is only used for prompt text, not for element resolution. So this is actually fine as-is.

The REAL risk with elements is the **3-element cap with start frame** (vs 4 without). If a sequence has 3 characters + wants a start frame, one character gets dropped. The orchestrator needs to handle element priority when a start frame is in play.

## Concrete Ask

Given this pushback, revise your architecture proposal. Specifically:
1. Where does grid exploration state live? StepRunner or orchestrator?
2. How do you handle mixed-mode sequences (some multi-shot, some individual I2V)?
3. What's the exact state flow for a client sequence from init to approved?
4. Should there be a CLI tool, and what does it look like?