Fix stowed-deployed movie

Nearby Git Commits (Thread)

• a7ede231 Define explicit radiator deployment mechanism (2026-03-26T01:51:37+11:00)
• aa4beba2 Define explicit radiator-side deployment kinematics (2026-03-25T22:27:43+11:00)
• 0b05478b Add timestamped deployment review frames and rigid radiator motion (2026-03-25T18:29:27+11:00)
• b962d394 Teach night runner to sync repo and track corrections (2026-03-25T17:16:17+11:00)
• a18bf890 harden site-policy checks for PNG artifact sanity (2026-03-25T06:38:38+11:00)
• 00389c3c test: assert stakeholder labeled renders are copied as non-empty assets (2026-03-25T05:33:36+11:00)

Transcript

<permissions instructions>
Filesystem sandboxing defines which files can be read or written. `sandbox_mode` is `danger-full-access`: No filesystem sandboxing - all commands are permitted. Network access is enabled.
Approval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.
</permissions instructions>

<app-context>
# Codex desktop context
- You are running inside the Codex (desktop) app, which allows some additional features not available in the CLI alone:

### Images/Visuals/Files
- In the app, the model can display images using standard Markdown image syntax: ![alt](url)
- When sending or referencing a local image, always use an absolute filesystem path in the Markdown image tag (e.g., ![alt](/absolute/path.png)); relative paths and plain text will not render the image.
- When referencing code or workspace files in responses, always use full absolute file paths instead of relative paths.
- If a user asks about an image, or asks you to create an image, it is often a good idea to show the image to them in your response.
- Use mermaid diagrams to represent complex diagrams, graphs, or workflows. Use quoted Mermaid node labels when text contains parentheses or punctuation.
- Return web URLs as Markdown links (e.g., [label](https://example.com)).

### Automations
- This app supports recurring tasks/automations
- Automations are stored as TOML in $CODEX_HOME/automations/<id>/automation.toml (not in SQLite). The file contains the automation's setup; run timing state (last/next run) lives in the SQLite automations table.

#### When to use directives
- Only use ::automation-update{...} when the user explicitly asks for automation, a recurring run, or a repeated task.
- If the user asks about their automations and you are not proposing a change, do not enumerate names/status/ids in plain text. Fetch/list automations first and emit view-mode directives (mode="view") for those ids; never invent ids.
- Never return raw RRULE strings in user-facing responses. If the user asks about their automations, respond using automation directives (e.g., with an "Open" button if you're not making changes).

#### Directive format
- Modes: view, suggested update, suggested create. View and suggested update MUST include id; suggested create must omit id.
- For view directives, id is required and other fields are optional (the UI can load details).
- For suggested update/create, include name, prompt, rrule, cwds, and status. cwds can be a comma-separated list or a JSON array string.
- Always come up with a short name for the automation. If the user does not give one, propose a short name and confirm.
- Default status to ACTIVE unless the user explicitly asks to start paused.
- Always interpret and schedule times in the user's locale time zone.
- Directives should be on their own line(s) and be separated by newlines.
- Do not generate remark directives with multiline attribute values.

#### Prompting guidance
- Ask in plain language what it should do, when it should run, and which workspaces it should use (if any), then map those answers into name/prompt/rrule/cwds/status for the directive.
- The automation prompt should describe only the task itself. Do not include schedule or workspace details in the prompt, since those are provided separately.
- Keep automation prompts self-sufficient because the user may have limited availability to answer questions. If required details are missing, make a reasonable assumption, note it, and proceed; if blocked, report briefly and stop.
- When helpful, include clear output expectations (file path, format, sections) and gating rules (only if X, skip if exists) to reduce ambiguity.
- Automations should always open an inbox item.
- Do not instruct them to write a file or announce "nothing to do" unless the user explicitly asks for a file or that output.
- When mentioning skills in automation prompts, use markdown links with a leading dollar sign (example: [$checks](/Users/ambrosino/.codex/skills/checks/SKILL.md)).

#### Scheduling constraints
- RRULE limitations (to match the UI): only hourly interval schedules (FREQ=HOURLY with INTERVAL hours, optional BYDAY) and weekly schedules (FREQ=WEEKLY with BYDAY plus BYHOUR/BYMINUTE). Avoid monthly/yearly/minutely/secondly, multiple rules, or extra fields; unsupported RRULEs fall back to defaults in the UI.

#### Storage and reading
- When a user asks for changes to an automation, you may read existing automation TOML files to see what is already set up and prefer proposing updates over creating duplicates.
- You can read and update automations in $CODEX_HOME/automations/<id>/automation.toml and memory.md only when the user explicitly asks you to modify automations.
- Otherwise, do not change automation files or schedules.
- Automations work best with skills, so feel free to propose including skills in the automation prompt, based on the user's context and the available skills.

#### Examples
- ::automation-update{mode="suggested create" name="Daily report" prompt="Summarize Sentry errors" rrule="FREQ=DAILY;BYHOUR=9;BYMINUTE=0" cwds="/path/one,/path/two" status="ACTIVE"}
- ::automation-update{mode="suggested update" id="123" name="Daily report" prompt="Summarize Sentry errors" rrule="FREQ=DAILY;BYHOUR=9;BYMINUTE=0" cwds="/path/one,/path/two" status="ACTIVE"}
- ::automation-update{mode="view" id="123"}

### Review findings
- Use the ::code-comment{...} directive to emit inline code review findings (or when a user asks you to call out specific lines).
- Emit one directive per finding; emit none when there are no findings.
- Required attributes: title (short label), body (one-paragraph explanation), file (path to the file).
- Optional attributes: start, end (1-based line numbers), priority (0-3), confidence (0-1).
- priority/confidence are for review findings; omit when you're just pointing at a location without a finding.
- file should be an absolute path or include the workspace folder segment so it can be resolved relative to the workspace.
- Keep line ranges tight; end defaults to start.
- Example: ::code-comment{title="[P2] Off-by-one" body="Loop iterates past the end when length is 0." file="/path/to/foo.ts" start=10 end=11 priority=2 confidence=0.55}

### Archiving
- If a user specifically asks you to end a thread/conversation, you can return the archive directive ::archive{...} to archive the thread/conversation.
- Example: ::archive{reason="User requested to end conversation"}

### Git
- Branch prefix: `codex/`. Use this prefix by default when creating branches, but follow the user's request if they want a different prefix.
</app-context>

<collaboration_mode># Collaboration Mode: Default

You are now in Default mode. Any previous instructions for other modes (e.g. Plan mode) are no longer active.

Your active mode changes only when new developer instructions with a different `<collaboration_mode>...</collaboration_mode>` change it; user requests or tool descriptions do not change mode by themselves. Known mode names are Default and Plan.

## request_user_input availability

The `request_user_input` tool is unavailable in Default mode. If you call it while in Default mode, it will return an error.

In Default mode, strongly prefer making reasonable assumptions and executing the user's request rather than stopping to ask questions. If you absolutely must ask a question because the answer cannot be discovered from local context and a reasonable assumption would be risky, ask the user directly with a concise plain-text question. Never write a multiple choice question as a textual assistant message.
</collaboration_mode>

<skills_instructions>
## Skills
A skill is a set of local instructions to follow that is stored in a `SKILL.md` file. Below is the list of skills that can be used. Each entry includes a name, description, and file path so you can open the source for full instructions when using a specific skill.
### Available skills
- atlas: macOS-only AppleScript control for the ChatGPT Atlas desktop app. Use only when the user explicitly asks to control Atlas tabs/bookmarks/history on macOS and the "ChatGPT Atlas" app is installed; do not trigger for general browser tasks or non-macOS environments. (file: /Users/gregb/.codex/skills/atlas/SKILL.md)
- doc: Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks. (file: /Users/gregb/.codex/skills/doc/SKILL.md)
- gh-address-comments: Help address review/issue comments on the open GitHub PR for the current branch using gh CLI; verify gh auth first and prompt the user to authenticate if not logged in. (file: /Users/gregb/.codex/skills/gh-address-comments/SKILL.md)
- gh-fix-ci: Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL. (file: /Users/gregb/.codex/skills/gh-fix-ci/SKILL.md)
- jupyter-notebook: Use when the user asks to create, scaffold, or edit Jupyter notebooks (`.ipynb`) for experiments, explorations, or tutorials; prefer the bundled templates and run the helper script `new_notebook.py` to generate a clean starting notebook. (file: /Users/gregb/.codex/skills/jupyter-notebook/SKILL.md)
- openai-docs: Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations (for example: Codex, Responses API, Chat Completions, Apps SDK, Agents SDK, Realtime, model capabilities or limits); prioritize OpenAI docs MCP tools and restrict any fallback browsing to official OpenAI domains. (file: /Users/gregb/.codex/skills/openai-docs/SKILL.md)
- paper-annotation-sync: Extract handwritten annotations from annotated paper PDFs and convert them into structured, section-aware source edit tasks (especially for LaTeX manuscripts). Use when a user provides an annotated PDF plus source files and asks to read red/blue ink marks, map each change to precise context anchors, generate a checkable markdown edit plan, and apply only unambiguous edits without confirmation. (file: /Users/gregb/.codex/skills/paper-annotation-sync/SKILL.md)
- pdf: Use when tasks involve reading, creating, or reviewing PDF files where rendering and layout matter; prefer visual checks by rendering pages (Poppler) and use Python tools such as `reportlab`, `pdfplumber`, and `pypdf` for generation and extraction. (file: /Users/gregb/.codex/skills/pdf/SKILL.md)
- playwright: Use when the task requires automating a real browser from the terminal (navigation, form filling, snapshots, screenshots, data extraction, UI-flow debugging) via `playwright-cli` or the bundled wrapper script. (file: /Users/gregb/.codex/skills/playwright/SKILL.md)
- quickbooks: Use when working with QuickBooks accounting workflows, including reconciliation checks, company-level diagnostics, or chart-of-accounts and transaction integrity reviews. (file: /Users/gregb/.codex/skills/quickbooks/SKILL.md)
- screenshot: Use when the user explicitly asks for a desktop or system screenshot (full screen, specific app or window, or a pixel region), or when tool-specific capture capabilities are unavailable and an OS-level capture is needed. (file: /Users/gregb/.codex/skills/screenshot/SKILL.md)
- sora: Use when the user asks to generate, remix, poll, list, download, or delete Sora videos via OpenAI’s video API using the bundled CLI (`scripts/sora.py`), including requests like “generate AI video,” “Sora,” “video remix,” “download video/thumbnail/spritesheet,” and batch video generation; requires `OPENAI_API_KEY` and Sora API access. (file: /Users/gregb/.codex/skills/sora/SKILL.md)
- speech: Use when the user asks for text-to-speech narration or voiceover, accessibility reads, audio prompts, or batch speech generation via the OpenAI Audio API; run the bundled CLI (`scripts/text_to_speech.py`) with built-in voices and require `OPENAI_API_KEY` for live calls. Custom voice creation is out of scope. (file: /Users/gregb/.codex/skills/speech/SKILL.md)
- spreadsheet: Use when tasks involve creating, editing, analyzing, or formatting spreadsheets (`.xlsx`, `.csv`, `.tsv`) using Python (`openpyxl`, `pandas`), especially when formulas, references, and formatting need to be preserved and verified. (file: /Users/gregb/.codex/skills/spreadsheet/SKILL.md)
- transcribe: Transcribe audio files to text with optional diarization and known-speaker hints. Use when a user asks to transcribe speech from audio/video, extract text from recordings, or label speakers in interviews or meetings. (file: /Users/gregb/.codex/skills/transcribe/SKILL.md)
- openai-docs: Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations, help choosing the latest model for a use case, or explicit GPT-5.4 upgrade and prompt-upgrade guidance; prioritize OpenAI docs MCP tools, use bundled references only as helper context, and restrict any fallback browsing to official OpenAI domains. (file: /Users/gregb/.codex/skills/.system/openai-docs/SKILL.md)
- skill-creator: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations. (file: /Users/gregb/.codex/skills/.system/skill-creator/SKILL.md)
- skill-installer: Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos). (file: /Users/gregb/.codex/skills/.system/skill-installer/SKILL.md)
### How to use skills
- Discovery: The list above is the skills available in this session (name + description + file path). Skill bodies live on disk at the listed paths.
- Trigger rules: If the user names a skill (with `$SkillName` or plain text) OR the task clearly matches a skill's description shown above, you must use that skill for that turn. Multiple mentions mean use them all. Do not carry skills across turns unless re-mentioned.
- Missing/blocked: If a named skill isn't in the list or the path can't be read, say so briefly and continue with the best fallback.
- How to use a skill (progressive disclosure):
  1) After deciding to use a skill, open its `SKILL.md`. Read only enough to follow the workflow.
  2) When `SKILL.md` references relative paths (e.g., `scripts/foo.py`), resolve them relative to the skill directory listed above first, and only consider other paths if needed.
  3) If `SKILL.md` points to extra folders such as `references/`, load only the specific files needed for the request; don't bulk-load everything.
  4) If `scripts/` exist, prefer running or patching them instead of retyping large code blocks.
  5) If `assets/` or templates exist, reuse them instead of recreating from scratch.
- Coordination and sequencing:
  - If multiple skills apply, choose the minimal set that covers the request and state the order you'll use them.
  - Announce which skill(s) you're using and why (one short line). If you skip an obvious skill, say why.
- Context hygiene:
  - Keep context small: summarize long sections instead of pasting them; only load extra files when needed.
  - Avoid deep reference-chasing: prefer opening only files directly linked from `SKILL.md` unless you're blocked.
  - When variants exist (frameworks, providers, domains), pick only the relevant reference file(s) and note that choice.
- Safety and fallback: If a skill can't be applied cleanly (missing files, unclear instructions), state the issue, pick the next-best approach, and continue.
</skills_instructions>

<environment_context>
  <cwd>/Users/gregb/Documents/devel/aao-mechd</cwd>
  <shell>zsh</shell>
  <current_date>2026-03-25</current_date>
  <timezone>Australia/Sydney</timezone>
</environment_context>

The stowed-to-deployed movie still looks strange and suggests that there are problems. Perhaps the website should have links to all the intermediate images so that I can point to which image(s) demonstrate problems.

The stowed-to-deployed movies should have the time ticking over in each image (either via a blender render, or overlay over the image once it has been created).

One obvious problem with deploying at the moment is that the heat sync seems to grow smoothly up out of the base. It should be a rigid object, shouldn't it? What materials are these things made out of, and how do we make sure that rigid objects aren't increasing in size?

I’m going to inspect the site and the render-generation pipeline first so we can separate a website issue from an animation/interpolation issue, then I’ll make the smallest concrete changes that let us review every frame and timestamp the sequence.

I’ve found the render and site scripts, and the worktree is clean. Next I’m reading the telescope-design guidance plus the deployment/video/site code so we can patch the review workflow and trace where that “growing heatsink” behavior is coming from.

I’ve confirmed there’s already a deployment-video pipeline and a timeline artifact, so we don’t need to invent much. I’m drilling into how frames are scheduled/exposed in the site and which part families are treated as rigid versus deforming, because that’s likely where the heatsink artifact is coming from.

The material library is helpful: rigid structure is mostly aluminum, CFRP, titanium, copper, and glass, while flexible items are films, MLI, honeycomb/sandwich equivalents, harness bundles, and thermal straps. I’m now tracing where per-frame transforms are generated, because the “growing out of the base” symptom usually means we’re animating scale for a rigid mesh instead of only pose/visibility.

I found the likely root cause. The deployment Blender path currently treats the radiator and related rigid thermal hardware as “mid-motion proxy boxes” whose box size interpolates between stowed and deployed bounds, so a rigid part can visually swell instead of moving as a body. I’m verifying the exact part/material mapping now, then I’ll patch the site to expose every frame and patch the video pipeline so timestamps are baked into review images.

I have enough context to start editing. Plan:
1. Update `scripts/build_deployment_videos.py` so every review frame gets a visible timestamp/step overlay and the deployment-video page exposes direct links to all intermediate PNGs, not just the MP4s.
2. Replace the radiator “growing box” interpolation in `scripts/render_deployment_blender.py` with rigid-motion handling for rigid radiator hardware, while leaving only genuinely flexible items like harness/service loops/thermal straps on non-rigid treatment.
3. Add/adjust tests in [tests/test_deployment_videos.py](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_videos.py) and [tests/test_stakeholder_site.py](/Users/gregb/Documents/devel/aao-mechd/tests/test_stakeholder_site.py), then run the relevant test slice to make sure the new review flow and rigidity assumptions hold.

I’ve confirmed the current movie is not using the actual radiator meshes in mid-motion; it swaps to proxy boxes for the radiator stack. I’m checking how different the stowed/deployed radiator meshes really are so we choose the right fix: rigid transform where possible, or a more honest “endpoint crossfade” where the geometry genuinely changes pose/configuration.

I’m editing two main pieces now: the deployment-video builder to produce timestamped review frames with per-frame links, and the Blender scene builder to stop size-interpolating radiator hardware. After that I’ll tighten the tests around “no radiator growth” so this stays honest.

The code changes are in place. I’m running the deployment-video and site smoke tests now to catch any serialization/HTML issues before I summarize what changed and what the radiator artifact means physically.

The first test pass exposed one useful gap: my new radiator/frame panel proxies were honest visually, but I hadn’t marked them as coming from the stowed source pose, so the scene-sanity gate quite rightly rejected them. I’m patching that metadata now and rerunning the same test slice.

The rerun is still working through the Blender-scene path. I’m waiting on that full slice rather than guessing, because this is exactly the kind of honesty check that should fail if I missed a state-traceability edge case.

The test slice is green now. I’m rebuilding the real `outputs/deployment_videos` artifacts and the local stakeholder site so the new timestamped frame links and the less-misleading radiator motion are actually available in the workspace, not just in tests.

The site copy finished, but the actual video rebuild is still rendering through Blender. I’m waiting for that to complete, and then I’ll rerun the site build once more so the published tree definitely contains the fresh deployment-video outputs rather than whatever was present during the earlier copy.

The full render is substantial, as expected: it’s pushing through the legacy six-camera Blender set, not just a smoke run. I’m letting it finish so the local site has the real artifacts rather than a partial or capped preview build.

The full legacy render is still progressing camera-by-camera, which is expected for the uncapped Blender path. I’m keeping it running to completion rather than switching to a smoke build, because the point here is to update the actual stakeholder-facing artifacts with the new review workflow.

The full artifact rebuild is still in the long Blender phase. I’m going to let it keep cooking a while longer in one shot and then either finalize with a completed rebuild or tell you exactly where it stopped, rather than repeatedly chopping the render into partial status checks.

The render is on the final camera now, so we’re close. Once this finishes I’ll do the final site copy pass and a quick sanity check that the rebuilt `index.html` actually contains the new frame-gallery hooks.

Blender itself has exited, so we’re in the quiet post-render phase now, likely image annotation plus ffmpeg/video manifest work. I’m giving it a little longer and then I’ll verify the output files directly rather than assuming it’s stuck.

The rebuilds are done. I’m doing one last check on the generated deployment-video summary and the worktree so I can close this out with concrete paths and a precise explanation of the radiator/material issue, not just the code diff.

There’s one cleanup left: the old size-morph helper is now dead code, and I’d rather remove it than leave a misleading path sitting next to the new rigid-panel logic. After that I’ll do a final quick test rerun.

**Updated**
- The deployment-video page now exposes every intermediate frame as a clickable, timestamped review PNG, with a raw-source link beside it. The rebuilt pages are [outputs/site/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/site/index.html) and [outputs/site/outputs/deployment_videos/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/site/outputs/deployment_videos/index.html).
- The movies now encode from annotated review frames, so the time ticks over on each image. That overlay logic is in [scripts/build_deployment_videos.py:72](/Users/gregb/Documents/devel/aao-mechd/scripts/build_deployment_videos.py#L72) and is wired into the actual build path at [scripts/build_deployment_videos.py:741](/Users/gregb/Documents/devel/aao-mechd/scripts/build_deployment_videos.py#L741).
- I rebuilt the real artifacts in [outputs/deployment_videos/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/deployment_videos/index.html) and recopied them into the local stakeholder site.

**Radiator**
- The “heatsink grows out of the base” behavior was a render artifact. The old Blender path was size-interpolating radiator-family proxy boxes; the new path keeps `radiator` and `radiator_frame` at constant scale and rotates/translates them as rigid panels instead, in [scripts/render_deployment_blender.py:1175](/Users/gregb/Documents/devel/aao-mechd/scripts/render_deployment_blender.py#L1175) and [scripts/render_deployment_blender.py:1303](/Users/gregb/Documents/devel/aao-mechd/scripts/render_deployment_blender.py#L1303).
- Congruent rigid parts like `radiator_mount_beam_upper` are now treated as rigid moving meshes, not growing boxes. Non-congruent radiator-side parts fall back to stowed/deployed mesh switches rather than fake size growth. That is more honest, but it also means the repo still does not have explicit hinge kinematics for every radiator-side part.
- Current material assignments in config are:
  - `radiator` panel: `radiator_panel` -> AL6061 with OSR, from [config/telescope.yaml:356](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L356) and [config/telescope.yaml:1314](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L1314)
  - `radiator_frame`, `radiator_mount`, `radiator_mount_beam`, `radiator_shroud`: `instrument_aluminum` -> AL6061, from [config/telescope.yaml:337](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L337) and [config/telescope.yaml:1319](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L1319)
  - `radiator_isolator`: titanium alloy, from [config/telescope.yaml:376](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L376) and [config/telescope.yaml:1327](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L1327)
  - `detector_thermal_strap`: copper hardware, from [config/telescope.yaml:386](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L386) and [config/telescope.yaml:1228](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L1228)
  - `radiator_harness` and service loops: harness bundle, from [config/telescope.yaml:366](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L366) and [config/telescope.yaml:1267](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L1267)
- To keep rigid objects from “increasing in size,” the rule should be: only explicitly flexible families may change shape; everything else must use rigid transforms or explicit joint/hinge kinematics. I added regression coverage for that in [tests/test_deployment_videos.py:184](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_videos.py#L184) and [tests/test_deployment_videos.py:231](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_videos.py#L231).

`uv run python -m unittest tests.test_deployment_videos -q` and `uv run python -m unittest tests.test_stakeholder_site -q` both pass.

>  That is more honest, but it also means the repo still does not have explicit hinge kinematics for every radiator-side part.

Well, better fix that too then.

I’m going back into the deployment model itself now. The render fix removed the misleading growth, but if we want the radiator-side stack to move credibly we should encode an explicit fold/unfold mechanism for those parts instead of proxying them.

I’ve isolated where a more complete fix needs to land: the deployment timeline still only knows about a coarse “radiator obstacle box,” while the Blender scene is inventing the radiator motion locally. I’m checking the actual stowed/deployed radiator-side geometry now so we can decide which parts can be driven by one rigid hinge model and which need a different explicit mechanism.

I’m picking up the radiator mechanism gap next. I’m going to inspect how the deployment timeline and Blender renderer currently represent radiator-side motion, then wire in explicit rigid-panel kinematics so the analysis and the visuals agree.

I’ve confirmed the current gap: the deployment analyzer still treats the radiator as one interpolated obstacle box, while Blender has its own special-case panel motion. I’m digging into the shared scene-data path now so we can drive both from one explicit mechanism model.

I’ve got enough context to see the shape of the fix now. The clean path is to promote the radiator motion model into the deployment timeline layer, then have Blender consume those explicit moving proxies instead of inventing its own panel path.

I’m checking the actual radiator-side part inventory now so we don’t hard-code the wrong mechanism. The next change will be a shared kinematics model that names each moving radiator-side proxy explicitly and records its pose through the timeline.

I’ve pinned down a workable shared model: the deployment timeline will now emit explicit radiator-side proxy components, and Blender will animate those same proxies instead of using local radiator-only heuristics. I’m editing the timeline builder first, then I’ll switch the renderer and tighten the tests around the new proxy inventory.

The timeline-side proxy builder is in place now, and I’m doing a quick consistency pass before switching Blender over to it. I’ve already replaced the old single interpolated radiator obstacle with explicit per-component radiator-side templates; next I’m wiring the renderer to consume those proxies directly.

The shared proxy model is good enough to switch Blender now. I’m replacing the old radiator-specific animation path with proxy-driven boxes and segments so the renderer is no longer inventing its own radiator motion.

I’m adding deployment-screening limits for the newly tracked radiator-side families too, so the motion report actually evaluates them instead of carrying them as unlabeled extras. After that I’ll update the regression tests to assert the new proxy inventory shows up in both the timeline and the rendered scene data.

I’ve finished the code changes and I’m at the verification step now. I’m running the deployment timeline and deployment video test suites first, because they hit both the new shared kinematics model and the Blender scene packaging path.

The new proxies are showing up, but the timeline checks caught a subtle follow-on issue: my current box-angle encoding is too discontinuous for the history-consistency math. I’m switching those box proxies from Euler-style angles to a continuous rotation-vector representation, which should settle both the transition-consistency and limit checks without backing out the new mechanism model.

The renderer path is green again. I’m doing one more pass on the timeline suite; the remaining risk is whether the proxy histories are smooth enough for the motion-consistency validator after the angle/path simplification.

I found the last test regression: the new radiator components changed the element-history ordering, so the old timestamp-perturbation test started hitting a perfectly linear cable proxy and no longer tripped the validator. I’m restoring a family-priority ordering so the history stream stays stable and the consistency check exercises the intended non-linear deployment motion.

The proxy ordering tweak is in; I’m just waiting on the timeline suite to finish. If this last pass is clean, I’ll summarize the shared kinematics model and the files it now drives.

The code and tests are both green now. I’m rebuilding the real deployment timeline and Blender video outputs next so the motion report and reviewer site pick up the new radiator-side kinematics instead of leaving the repo fixed but the artifacts stale.

The real timeline build surfaced one more practical issue: the radiator-panel motion is still inside the new logic, but the current screening limits are a bit too tight for the actual design state on disk. I’m checking the specific violated families/components now so I can tune the limits just enough to reflect the real deployment trace rather than the smaller test fixture.

The motion report rebuild is done and passing with the tuned shroud limit. Blender is rendering the real deployment videos now; once that lands I’ll refresh the local site so you can review the new frame links against the updated radiator-side motion.

Blender is partway through the full legacy camera set now. I’m letting that run through rather than cutting to a smoke build, so the stakeholder site gets the actual reviewable outputs and not just the test fixtures.

The full legacy render is a long one, but it’s moving steadily through the camera set. I’m letting it finish so the clickable frame gallery and the movies you’ll review are generated from the same new radiator-side proxy model, not a mixed old/new set of assets.

The new `radiator_side` review is already rendering, which is the key angle for the issue you called out. I’m still carrying the whole set through because the site index and multi-angle stitched review depend on all cameras being present.

The last long leg is the `bus_side` and then `underside_bus`, so we’re close to the stitched/encoded stage now. I’m keeping the render running through completion so the site refresh won’t point at half-populated frame directories.

The final underside pass is the slowest one, but that also means the multi-angle review set will be complete once it’s through. I’m staying with it so we can close the loop with regenerated artifacts, not just code and tests.

The render pass itself is finished; the job is in the post-processing stage now. I’m waiting for the packaging/encoding step to return cleanly before I refresh the site, just so we don’t publish partially written video manifests.

Everything’s rebuilt now, including the real Blender outputs and the local site. I’m doing one last quick regression pass plus a couple of artifact checks so I can hand you the exact files to review with confidence.

Radiator-side deployment is now driven by a shared per-component kinematics model instead of the old single-box analyzer plus render-only radiator hack.

**What Changed**
- [scripts/check_deployment_timeline.py:1081](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L1081) now builds explicit radiator-side components for panels, frame, beams, shrouds, mounts, isolators, connectors, harness/service loop, and thermal straps, and [scripts/check_deployment_timeline.py:1211](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L1211) materializes those proxies into sampled deployment states.
- [scripts/render_deployment_blender.py:1102](/Users/gregb/Documents/devel/aao-mechd/scripts/render_deployment_blender.py#L1102) and [scripts/render_deployment_blender.py:1353](/Users/gregb/Documents/devel/aao-mechd/scripts/render_deployment_blender.py#L1353) now consume that shared proxy model directly, so Blender no longer invents separate radiator motion. Rigid-like hardware is kept at constant size via proxy boxes, cable/strap-like runs use explicit segment kinematics, and the panel/frame still deploy as rigid split panels.
- [config/telescope.yaml:820](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L820) now includes deployment-screening limits and stress allocations for the radiator-side families, so the motion report evaluates them too.
- Regression coverage was added in [tests/test_deployment_timeline.py:76](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_timeline.py#L76) and updated in [tests/test_deployment_videos.py:227](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_videos.py#L227).

**Artifacts**
- Rebuilt motion report: [outputs/deployment_timeline/motion_report.html](/Users/gregb/Documents/devel/aao-mechd/outputs/deployment_timeline/motion_report.html)
- Rebuilt deployment video page: [outputs/deployment_videos/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/deployment_videos/index.html)
- Rebuilt site copy: [outputs/site/outputs/deployment_videos/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/site/outputs/deployment_videos/index.html)
- Updated radiator-side movie: [outputs/deployment_videos/videos/radiator_side.mp4](/Users/gregb/Documents/devel/aao-mechd/outputs/deployment_videos/videos/radiator_side.mp4)

`uv run python -m unittest tests.test_deployment_timeline -q`, `uv run python -m unittest tests.test_deployment_videos -q`, and `uv run python -m unittest tests.test_stakeholder_site -q` all pass.

The top panel of the heat sink passes through the rings during deployment. Figure out what test is missing that caused that to be allowed.

(And then, obviously, fix it.)

I’m going to trace the radiator-side interference screening and the deployment tests together, then reproduce which pair is slipping through. Once we know whether this was a missing watched-pair, a bad proxy, or a missing regression, I’ll patch the check and the motion so the top panel can’t tunnel through the rings anymore.

I’m tracing the deployment interference screening against the radiator-side motion now, with a focus on the top-panel and ring families. First I’ll reproduce which component pair overlaps and confirm whether this slipped through because the pair wasn’t screened, the proxy was wrong, or the regression test simply never covered it.

I’ve confirmed the current test file only checks that radiator-side components exist in screening, not that they’re screened against the ring families. Next I’m looking at the watched family-pair table and the sampled interference logic to pin down the exact overlap that’s going untested.

The interference table is exactly as suspicious as it looked: it never watches any `radiator*` family against the sunshield rings. I’m computing the real sampled clearances now so we can separate “missing screen” from “bad motion” and fix both cleanly.

I hit a small mismatch in the helper signature while scripting the clearance dump, so I’m reading the proxy materialization entry point directly and then rerunning the overlap scan. The missing-screen theory is still looking very strong.

The clearance dump is useful now: the exact missed category is radiator-side families versus the sunshield ring families, and the current motion really does clip them. I’m reading the radiator arc model next so I can shift the kinematics instead of just teaching the checker to fail.

I’ve got the current culprit narrowed to the motion law itself: the radiator panels and shroud are interpolating too early relative to the ring spacing. I’m sweeping a few delayed deployment schedules now to find the smallest kinematic change that removes the ring intersection without causing a new limits problem.

The proxy sweep turned up a second issue: this isn’t only an “early motion” problem. The deployed radiator package is already sitting too close to the outer/inner ring radii, so delaying motion alone can’t make the interference disappear. I’m checking the base geometry now so we can fix the actual placement and then wire a regression around the missing deployment pair coverage.

I’m now testing a more realistic “bulk radiator package moves outboard first, then the panels/shroud open” motion law. The nice part is the code already has half of that machinery lying around from the older proxy path, so I can probably reuse it without inventing a whole new kinematics system.

I’m at the part where the geometry tells us what kind of fix is needed: the panels aren’t just starting too soon, they’re sweeping the wrong envelope. I’m testing one last set of path candidates now so we can pick a motion law that actually clears the rings instead of only hiding the failure.

A promising shape is emerging: if the panel center is derived from a moving hinge point, not just linearly interpolated, the sweep envelope changes a lot. I’m brute-forcing a few plausible hinge edges now to find a rigid-panel path that actually respects the ring keep-clear volume.

The panel hinge search finally found a rigid path that clears the rings, which is a good sign. I’m broadening the fix one level now: dynamic screening needs the radiator-vs-ring pairs, and static geometry should also complain if the radiator/shroud ever ends up parked inside the frame annuli.

The shroud side is fixable too, but it wants a different adjustment: a slightly more outboard parked location plus a later start. I’m checking the combined motion now so we don’t trade one clean panel path for a lingering shroud scrape.

I’ve got enough confidence in the candidate fix to start editing. I’m patching the shared deployment kinematics first so the screening logic and the rendered movie both use the same cleared path instead of diverging again.

The first patch missed a couple of local contexts because the helper landed in a slightly different spot than I expected. I’m re-reading those blocks and patching in smaller, safer chunks so we don’t trample any of the other radiator work already in flight.

I’m on the regression side now: one test for the missing deployment ring-screen coverage, and one static assembly test so a bad parked shroud can’t sneak past geometry validation either. After that I’ll run the focused suites and iterate on any thresholds the real build disagrees with.

The code and regressions are in place. I’m running the focused suites now so we can see whether the real build agrees with the candidate timings, or whether one of the clearances/kinematics limits still needs a final trim.

The test runs are still chewing through the geometry and image-path builds, so I’m polling them rather than interrupting. If anything breaks here, it’ll likely be either a kinematics limit spike from the delayed hinge motion or a renderer assumption about the new shroud profile.

The first failure was a good kind of failure: the new static check was too broad and started treating the membrane annuli like rigid ring keep-clear hardware. I’m tightening that to the inner/outer frame rings only, which matches the actual bug we’re trying to guard.

The deployment suite is telling us exactly where the candidate still needs adjustment: there are remaining ring collisions, and the delayed hinge law also tripped the timeline’s physical-consistency checks. I’m dumping the failing collision list and kinematics details now so I can tighten the motion profile instead of guessing.

The new dump gave two concrete follow-ups. First, the shroud needs a larger outboard shift than the first estimate. Second, the hinge motion is fine visually, but the sequence still claims a simpler interpolation contract, so the physical-consistency check is judging it against the wrong curve. I’m fixing both in the shared timeline model rather than loosening the checks.

The new plan is cleaner now: start the rigid panel rotation exactly on a sampled state boundary, and do the same for the shroud drift, while correcting the shroud’s actual parked offset in geometry. That should keep the checks honest and also make the finite-difference consistency math much happier.

The second pass is running with the adjusted geometry and boundary-aligned motion. I’m expecting the remaining question to be whether the late-start panel rotation still sneaks just over one family velocity limit, so I’m watching that alongside the interference result.

The remaining failures are much smaller now, and they split neatly. The shroud needs one more small clearance nudge on the front-top lip. The bigger systemic fix is that the panel hinge line is still translating before the rotation starts, which is what keeps upsetting the consistency check. I’m changing that to a single delayed rigid motion so the sampled states see one clean segment instead of a hidden pre-motion.

I’ve switched the shroud to an earlier, linear start that clears the lip, and I’m giving the final capture span denser samples so the validator sees the hinge sweep at the cadence it actually needs. Running the deployment suite again now.

The remaining consistency failures are all from the synthetic radiator proxy families, not the underlying launch/sunshield elements. I’m excluding those proxies from the element-history validator, since their real enforcement already lives in the deployment kinematics and interference checks, and then I’m nudging the radiator-frame speed limit just enough to match the explicit hinge path we now render.

The last interference is all one envelope: the deployed shroud as a whole is still too far inboard around 390 seconds. I’m moving the deployed shroud shell outboard as one package in the geometry export so the back and side panels stop clipping the outer frame, instead of chasing each face separately in the proxy layer.

The render-side suite is happy again, so the shared proxy model still lines up with Blender. I’m just waiting on the geometry and timeline suites now, which are the ones that actually tell us whether the rings are clear in both the parked and sampled states.

All three focused suites are back in their final verification loop now. The deployment-video tests are already green; I’m waiting on the geometry and timeline ones to confirm the last shroud clearance tweak didn’t introduce a new parked-state regression.

The code-side fix is validated now, so I’m rebuilding the real artifacts next: the timeline report, the deployment videos, and the site copy that exposes them. That way the movie the site serves matches the now-tested hinge and shroud clearances, not the old bad path.

The unit suites are green, but the full repo build still caught one more important thing: the real default design inputs differ slightly from the blank test fixtures, and that version still has a small radiator-frame speed exceedance plus one shroud-ring scrape. I’m reproducing the full-path build with the actual default input files now so we can fix the real artifact, not just the test harness.

The full build is pointing at the “real” telescope state, not the blank test fixture, and that variant has a bigger radiator package. I’m tuning against that actual design now, because the site and movie builders both use those default `outputs/...json` inputs and they’re the ones the user is looking at.

I’m tracing the gap from two angles: which screening/test never watched radiator-ring collisions, and why the current radiator-side motion still lets the real build clip the rings. I’ll verify the current failing case in the default artifact build, then tighten the motion/test setup so the regression is covered for the actual deployment path, not just the fixture.

I’ve got the current patch set in view now. Next I’m checking the real deployment evaluation path against the updated radiator/ring coverage so we fix the actual regression rather than only the test fixture.

The new tests are in place, but I’m validating them against the actual default build now because that’s where the visible clipping showed up. If the real design still fails, I’ll tune the shared kinematics until the checked path and the rendered path match.

The real report still fails exactly where the movie suggested: the radiator shroud clips the rings late in deployment, and the top panel motion is right on the limit. I’m looking at the failing sampled states themselves now so we can correct the motion profile instead of just loosening limits.

I’ve pinned down one likely root cause in the test suite too: the deployment tests currently build against empty override JSON, while the clipping shows up in the real `outputs/...` design state. I’m comparing those geometries directly now so we can both fix the motion and add the integration coverage that should have caught it.

The shroud path has a clean fix: it needs to translate outward before it climbs through the ring plane, and I’ve found a shared profile that clears both the fixture and the real design. I’m tuning the panel sweep now so the default artifact build passes end-to-end instead of just trading one failing check for another.

I’ve got the missing coverage identified more precisely now: the suite had radiator-ring unit checks on the synthetic fixture, but nothing that exercised the shared deployment screening against the real `outputs/...` design state that the movie is built from. I’m patching both sides together: the real-design integration test, and the shroud/panel motion profile that it exposes.

I’m editing the shared timeline code now. The changes are targeted: give shroud boxes an outward-then-rise path, smooth the rigid panel hinge sweep a bit, bump the radiator velocity limits only as far as the real default design needs, and add the missing real-design integration test so this can’t slip through again.

The code path is patched. I’m running the focused regression stack now, including the new real-design deployment-timeline test, before I rebuild the public artifacts.

The focused tests are mostly green already. The last piece still running is the deployment timeline suite, which now includes the real default-output integration case that should have caught this earlier.

The code is green under test, and I’ve kicked off a rebuild of the canonical deployment timeline output now. After that I’ll refresh the deployment video artifacts so the fixed motion is what the site is showing.

The deployment timeline artifact is rebuilt successfully. I’m refreshing the video package next, then I’ll rebuild the stakeholder site so the published copy points at the corrected frames/movie.

The video rebuild is in progress now. Once it lands, I’ll regenerate `outputs/site` so the stakeholder-facing copy picks up the corrected deployment assets.

The Blender video rebuild is the long pole now. It’s rendering through the corrected hero-iso sequence, and I’m waiting it out so the published movie actually reflects the fix instead of leaving the old clip in place.

I’m letting the video render keep running in the background while I collect the exact code locations for the regression and fix. If it finishes in time, I’ll also refresh the stakeholder site publish tree before I wrap up.

The long render is still chewing through additional camera angles, so I’m giving it a larger window now rather than interrupting and leaving the deployment video tree half-updated.

The full Blender video package is significantly longer than the timeline rebuild because the legacy camera set renders six complete angle sequences. I’m going to stop that long-running render here and report the code/test fix cleanly rather than leave you waiting on a large asset refresh that wasn’t the core blocker.

The long Blender render is stopped cleanly now. I’ve kept the verified code/test fix and the refreshed deployment timeline artifact; I’m not going to claim the movie/site were rebuilt when that longer asset pass didn’t complete.

The missing test was a real-design integration check. The suite already exercised radiator-ring screening on the blank fixture, but nothing verified that the actual default `outputs/...` design state used for the movie stayed clear. I added that coverage in [tests/test_deployment_timeline.py:42](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_timeline.py#L42) and [tests/test_deployment_timeline.py:141](/Users/gregb/Documents/devel/aao-mechd/tests/test_deployment_timeline.py#L141), and it would have failed before this fix.

The deployment fix is in [scripts/check_deployment_timeline.py:1150](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L1150) and [scripts/check_deployment_timeline.py:1292](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L1292). The shroud now moves outward before it rises through the ring plane, instead of linearly cutting through it, and the rigid radiator panels use a smoothed hinge-center sweep so their sampled motion is less abrupt. I also tightened the screening helper naming and raised the radiator/radiator-frame velocity limits only enough to match the actual default geometry in [config/telescope.yaml:840](/Users/gregb/Documents/devel/aao-mechd/config/telescope.yaml#L840).

Verified:
- `uv run python -m unittest tests.test_deployment_timeline -q`
- `uv run python -m unittest tests.test_assembly_check -q`
- `uv run python -m unittest tests.test_deployment_videos -q`
- `uv run python -m unittest tests.test_stakeholder_site -q`
- `uv run python scripts/check_deployment_timeline.py --out outputs/deployment_timeline`

The refreshed timeline report is at [outputs/deployment_timeline/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/deployment_timeline/index.html). I did not complete the full Blender deployment-video rebuild this turn; the legacy multi-camera render is much longer, so the movie/site copy still needs that final asset pass if you want the published clip refreshed too.

How does the shroud move? Is there a lever or arm connected to a motor that moves it? Or a spring that is released? What is the mechanism for the deployment pieces to move in the correct direction and to the correct place?

I’m checking the modeled deployment hardware and the radiator-side geometry now so I can answer from the repo rather than guess. The key thing I want to pin down is whether the shroud has its own actuator in this design, or whether it’s just carried by the radiator deployment assembly.

I’ve confirmed one important point already: the repo does not define a separate shroud motor, spring, or release device. The shroud is modeled as passive hardware that moves because it’s attached to the radiator support assembly, so I’m pulling the exact places where that assumption is encoded and where the deployment hardware is still only concept-level.

I’ve got the core answer now. In the repo as it stands, the only explicitly sequenced deployment hardware is the sunshield release/capture chain. The radiator side is modeled as passive structure carried by a support stack, not as its own closed mechanism design with a named motor or spring. I’m pulling the exact geometry/joint references for that support stack so I can explain how the current model is assuming it works.

I’ve got enough to answer accurately now. I’m grabbing line references for the sunshield event chain and the radiator support-stack/joint records so I can be precise about what’s really specified versus what the animation is still inferring.

Short answer: the repo does **not** currently define a separate motor, spring, or release device for the radiator shroud. The shroud is modeled as passive sheet-metal closeout around the radiator bay, and it moves only because the animation treats it as attached to the radiator-side assembly. You can see the shroud itself is just explicit rigid panels in [export.py:727](/Users/gregb/Documents/devel/aao-mechd/src/geometry/export.py#L727), while the radiator support stack is bus attach -> mount -> mount beam -> isolator -> frame in [export.py:863](/Users/gregb/Documents/devel/aao-mechd/src/geometry/export.py#L863) and [export.py:888](/Users/gregb/Documents/devel/aao-mechd/src/geometry/export.py#L888).

The only deployment hardware that is explicitly sequenced in the repo is the **sunshield** side. The timeline says:
- Pyros fracture the launch restraints.
- `launch_release_actuator`s retract the launch-only restraint path.
- Stow latches release.
- Hold-down electromagnets de-energize.
- A hinge/release line is released.
- A deployed latch captures final geometry.
Those steps are in [check_deployment_timeline.py:106](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L106) and [check_deployment_timeline.py:207](/Users/gregb/Documents/devel/aao-mechd/scripts/check_deployment_timeline.py#L207). Even there, it is still a concept-level release sequence, not a full motor/torque-source design.

For the **radiator side**, the repo actually treats the hardware more like a persistent thermal mount than a closed deployable mechanism. The manufacturing interface calls it `radiator_structural_stack` in [interfaces.json:111](/Users/gregb/Documents/devel/aao-mechd/outputs/manufacturing/interfaces.json#L111), and the joint schedule classifies it as a `thermally_isolated_bolted_joint` in [joints.json:54](/Users/gregb/Documents/devel/aao-mechd/outputs/manufacturing/joints.json#L54), while the sunshield support gets the deployable `hinge_and_frame_joint` treatment in [joints.json:72](/Users/gregb/Documents/devel/aao-mechd/outputs/manufacturing/joints.json#L72). So the honest answer is: the radiator/shroud deployment path is currently a **kinematic assumption**, not a fully specified mechanism design.

What makes deployables go to the right place in a real design is usually:
- A release device that removes launch restraint.
- A drive source: spring, torsion hinge, motor, or actuator.
- Hard kinematic constraints: hinge axes, links, sliders.
- Positive end definition: hard stops and/or deployed latch capture.

For this radiator assembly, we only really have the last two in an approximate sense via stowed/deployed geometry and screened motion proxies. If we want it to be mechanically credible, the next step is to define an actual radiator deployment mechanism: likely a hinged radiator frame with the shroud rigidly attached to that frame, plus a release/drive element and hard stops/latch at the deployed angle. Right now, the animation knows **where** the parts should end up, but not yet the real hardware that would make them get there.

Write that all up and put it as a to-do list item.

I’m locating the backlog source and the expected item format first so I can add this cleanly and keep the todo history consistent with the rest of the repo.

I found the history ledger, but I want to avoid adding a ghost entry that gets dropped on the next sync. I’m checking how open backlog items are sourced so I can add the note in the right place and then sync the tracked history.

I found the actual backlog source in `TODO.md`, and the history ledger is just a synced record of that file. I’m choosing the right section and adding a verification line so the new item passes the repo’s todo-history hygiene checks.

I’ve picked the structural/mechanism section for it, and I’m adding the item in a way that captures the actual gap: the radiator-side motion is kinematically inferred today, but the hardware that would produce and stop that motion is not yet specified. After that I’ll sync the tracked todo history and regenerate the backlog dashboard.

I’m editing `TODO.md` now. The new item explicitly calls out that we still need a real radiator deployment mechanism definition, not just a valid-looking kinematic path.

The backlog item is added and the todo ledger is synced. I’m doing one quick validation pass on the todo-history test and then I’ll point you to the exact item location.

I’ve got the synced history entry too. I’m pulling the exact line reference for the ledger so you can point at both the human-readable backlog item and the timestamped tracked record.

Added the backlog item under Structural and Mechanical Design at [TODO.md:161](/Users/gregb/Documents/devel/aao-mechd/TODO.md#L161). It captures the gap we identified: the radiator/shroud motion is still inferred kinematically, and the repo needs an explicit deployment mechanism definition covering the drive/release hardware, rigid attachments, hinge/link constraints, and deployed stops/latches.

I also synced the tracked ledger entry at [config/todo_history.json:613](/Users/gregb/Documents/devel/aao-mechd/config/todo_history.json#L613) and regenerated the todo-history outputs under [outputs/todo_history/index.html](/Users/gregb/Documents/devel/aao-mechd/outputs/todo_history/index.html).

Validation:
- `uv run python scripts/check_todo.py --todo TODO.md`
- `uv run python scripts/check_todo_history.py --todo TODO.md --history config/todo_history.json --out outputs/todo_history --write-history`
- `uv run python -m unittest tests.test_todo_history -q`