Blame for harness/instance_template.txt

## Task

Write a Blender 4.5 Python script that builds the following scene and renders it as an animated white-model video:

<scene_description>
__TASK__
</scene_description>


## Script contract

- Write exactly one self-contained script: `main.py` in the current directory.
- It is executed headless as `blender --background --factory-startup --python main.py` with Blender 4.5, from the directory the video must be written to. Use only the Blender 4.5 API and the Python standard library; no external assets, files or add-ons.
- Start by removing every object in the default scene, then build the scene from scratch.
- Geometry: model with primitives, modifiers, `bmesh` or `mesh.from_pydata`. Name objects meaningfully. Keep the total scene under ~500k faces. Objects must not intersect unless the description implies contact.
- Animation: the video lasts 5-10 seconds at 24 fps, i.e. 120-240 frames; choose the length that suits the action. Set `scene.frame_start = 1` and `scene.frame_end` to that length, and animate with keyframes, drivers, constraints or physics so that the motion described actually happens within that range. Bake any physics simulation before rendering.
- Camera: create a camera, assign it to `scene.camera`, and frame the action so that it stays in view for all frames (animate the camera if the description asks for camera motion).
- Seed any randomness (`random.seed(...)`) so the result is deterministic. Prefer `bpy.data` / low-level API over `bpy.ops` where the operator needs UI context.
- Do not import subprocess, socket, shutil, urllib or similar modules, and do not call os.system/eval/exec.

## White-model render (required, at the end of the script)

Every video in this dataset uses the same look, so configure exactly this and then render:

- `scene.render.engine = 'BLENDER_WORKBENCH'`
- `scene.display.shading`: `light = 'STUDIO'`, `color_type = 'SINGLE'`, `single_color = (0.8, 0.8, 0.8)`, `show_shadows = True`, `show_cavity = True`, `cavity_type = 'WORLD'`. No materials or textures are needed; Workbench studio lighting ignores scene lights.
- Resolution 1280x720 at `resolution_percentage = 100`, `scene.render.fps = 24`.
- Output: `scene.render.image_settings.file_format = 'FFMPEG'`, `scene.render.ffmpeg.format = 'MPEG4'`, `scene.render.ffmpeg.codec = 'H264'`, `scene.render.filepath = os.path.join(os.getcwd(), 'output.mp4')`.
- Last statement: `bpy.ops.render.render(animation=True)`.
- Write no other files: no .blend files, images or caches outside the render. Do not quit Blender.

## Tools

Blender 4.5 is available through two commands (do not install anything):

```bash
check_script main.py   # fast static check: syntax, bpy import, camera, render call, forbidden calls
run_blender main.py    # executes the script exactly like the harness and renders output.mp4 (CPU, ~20-120 s)
```

`run_blender` reports the Python traceback if the script fails, whether output.mp4 has 120-240 frames matching the scene frame range at 1280x720, and a scene summary: object counts, animated objects, world positions of moving meshes at sampled frames, and meshes whose origin is outside the camera view. Use the numbers to verify that the motion, timing and framing match the description. It also returns 8 frames sampled evenly from the rendered video as images, with their frame numbers and times. It reports a problem when most frames are empty, nothing moves, or no object is in view.

## Workflow

1. Think & Plan: Before generating any code, explicitly reason about the scene: objects, their dimensions and positions in meters, the motion over time (frame timing), and camera placement/framing.
2. Write `main.py` with a heredoc: `cat <<'EOF' > main.py` ... `EOF`.
3. Run `check_script main.py` and fix every error.
4. Run `run_blender main.py`. Fix every error and problem it reports, and compare the scene summary against the description (positions, timing, clearances, camera framing).
   Then inspect the returned frames one by one against the description and write down every concrete problem you see: missing, unrecognizable or wrongly counted objects; wrong arrangement; motion that is missing, in the wrong order or at the wrong time; objects cut off, outside the frame or too small; objects passing through each other; wrong camera behavior. Fix the problems in the script and run `run_blender` again.
   Repeat until it reports RUN OK and the frames clearly show every element of the description. If a command keeps giving the same result, change the script or your approach instead of repeating it; repeated identical commands end the task.
5. Submit with `echo COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT` as a command on its own: the whole command is exactly that `echo`, never chained to another command with `&&`, `;` or `|`, and never in the same command as `check_script` or `run_blender`. You cannot continue after that. The harness then re-executes `main.py` from scratch; the task only counts if it renders a valid video.

## Command rules

- Make exactly ONE tool call per response: a single `bash` call with a single command (or one short chain that serves one purpose). Never put several tool calls in the same response; read the result of each command before deciding the next one. Every response must contain that tool call: never answer with text only, not even when you are finished (finishing means calling the submit command).
- Every tool call must be preceded by written reasoning in plain text in the same response: at least one sentence on what the previous result showed and what this command is for. This applies to every command without exception, including `check_script`, `run_blender` and the submit command; a response that contains only a tool call and no text is not allowed.
- Submit by itself: the command `echo COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT` must be the only command of its response. Do not append it to `check_script`, `run_blender` or any other command, and do not write that word anywhere else, not even in a comment. Run the final `run_blender` first, read its result, and only then send the submit command in a separate response.
- Each command runs in a fresh subshell in the task directory; `cd` and environment variables do not persist, so do not use `cd`.
- Only create or modify files in the current directory.
- Do not explore or probe the environment. Everything you need is described above. Do not run `pwd`, `which`, `whereis`, `type`, `env`, `printenv`, `echo $PATH`, `ls` of any other directory, `--help` or `--version` of any command, `pip list`, or `import` checks for Python packages, and do not look for Blender, ffmpeg, PIL or numpy. Your script may use only `bpy` and the Python standard library. Your first command is the one that writes `main.py`.
- Never print absolute paths of the machine, environment variables or the contents of `PATH`. If a command could print them, do not run it.
- Use only `check_script` and `run_blender` to check and execute scripts. Do not inspect or modify the harness itself (how these commands are implemented, `VCSFT_*` environment variables, the Blender/bpy installation) and do not run Blender or bpy any other way; such commands are blocked.
- Fix problems directly in `main.py`: change only the lines that are wrong (`sed -i`, or a short `python3` edit) and rerun `run_blender main.py`. Do not rewrite the whole file for a small fix.
- Throwaway experiment scripts are a last resort, for when the `run_blender` report is not enough to understand a problem: write a small script in the current directory and run `run_blender experiment.py` (whatever it `print()`s appears in the blender log). Use at most two experiments, and delete the experiment files before submitting.