# Sprint 5f Interview Transcript

## Q1: Batch behavior when ops are BLOCKED

**Q:** The spec proposes validation at the per-operation level (each op has validate:true). But when multiple ops are batched, should a BLOCKED op block ALL other ops in the batch, or only skip the blocked one and execute the rest?

**A:** Block ALL ops if any is blocked. Atomic behavior — if one op fails validation, none execute. Safer but more restrictive.

## Q2: Scene source for validation

**Q:** The scene_map needs a scene path to analyze. For the node_ops integration, how should we determine which scene to validate against?

**A:** Add optional 'scene' parameter to node_ops. Let the caller specify which .tscn to validate against. Falls back to main scene.

## Q3: Wall detection thoroughness

**Q:** For wall detection, the spec uses type='StaticBody3D' OR name contains 'Wall'. Research suggests also checking groups and collision layers. How thorough should v1 be?

**A:** Type + name heuristic (spec approach). Check StaticBody3D type and Wall/Floor/Ceiling in name. Simple, covers 80% of cases.

## Q4: Session access architecture

**Q:** The spatial_validator is pure Python taking a dict. But getting scene_map data requires a GodotIQSession. How should node_ops access it?

**A:** Pass session via MCP context (ctx). The MCP wrapper already has `ctx.request_context.lifespan_context['session']`. Thread it through.

## Q5: Room bounds

**Q:** The spec mentions room bounds validation from .godotiq.json config. Should v1 implement room bounds, or defer to a future sprint?

**A:** Defer room bounds to v2. v1 focuses on wall proximity, overlap, and sibling outlier checks only.

## Q6: Pushback suggestions

**Q:** When validation returns BLOCKED, should the response include a computed safe position suggestion (pushback from wall), or just report the problem?

**A:** Report problem only (v1). Tell the agent what's wrong and let it figure out the fix. Simpler.

## Q7: Scene parameter placement

**Q:** For the 'scene' parameter added to node_ops: should it be a top-level parameter alongside 'operations', or nested inside each operation dict?

**A:** Top-level parameter. `node_ops(operations=[...], scene='res://main.tscn')`. One scene for all ops.

## Q8: Validation default behavior

**Q:** Should validate:true be the default behavior for move/scale ops, or should it always require explicit opt-in?

**A:** Explicit opt-in (validate:true). No validation unless requested. Zero overhead by default, backward compatible.
