Take the next task on the to-do list and work on it. Confirm that all tests pass. Review your work for sanity (e.g. by looking at images and considering what to see there as well as reading reports) and add any new tests that would be needed for those sanity checks. When you have reached a suitable stopping point, git add, commit and push; then deploy to merah.

Nearby Git Commits (Thread)

• d592a27c Close Ariane LPSS interface assumptions with confirmed ICD values (2026-03-17T12:08:47+11:00)
• 94785735 Add optional image postprocessing provenance flow (2026-03-17T11:27:03+11:00)
• 516ea8ab Add explicit stowed launch hardware release data (2026-03-17T10:40:02+11:00)
• 8f4c75de Add geometry completeness release gate (2026-03-17T01:44:04+11:00)
• 2fe83451 Add coupled optical STOP screening gate (2026-03-17T00:43:27+11:00)
• cef34ee3 Add optics tolerance sensitivity analysis (2026-03-16T23:43:30+11:00)
• 413982f2 Add optical stop and obscuration checks (2026-03-16T22:42:20+11:00)
• bd9ed12a Add focal plane package layout release checks (2026-03-16T21:42:15+11:00)
• c7c60d96 Add explicit secondary alignment interface hardware (2026-03-17T13:38:27+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>

# AGENTS.md instructions for /Users/gregb/Documents/devel/aao-mechd

<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)
- 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.
</INSTRUCTIONS>

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

Take the next task on the to-do list and work on it. Confirm that all tests pass. Review your work for sanity (e.g. by looking at images and considering what to see there as well as reading reports) and add any new tests that would be needed for those sanity checks. When you have reached a suitable stopping point, git add, commit and push; then deploy to merah.

I’m going to find the repo’s to-do list, check the current branch/worktree state, and read any local instructions so I can pick the next task safely before changing code.

I found a clean `main` branch and a `TODO.md` at the repo root. Next I’m reading the task list and project docs so I can take the correct next item and understand the expected workflow and deployment path.

I’ve got the backlog and repo rules loaded. I’m listing the remaining open TODO items now so I can choose the earliest one that’s actually actionable in this repo, rather than getting stuck on an external ICD dependency.

The first unchecked engineering item is the Ariane interface assumption replacement, which may still be externally blocked. I’m checking current official launcher sources first so we know whether this can actually be closed now or whether I should move to the next actionable in-repo task.

The launcher item still looks blocked by public data: the latest official material I could find is the March 2021 Ariane 6 User’s Manual, mirrored again on ArianeGroup in late 2025, and it still leaves `PLA6 1666` dimensions/masses as `TBC` and doesn’t publish the detailed bolt-pattern ICD. I’m moving to the next in-repo geometry task and scoping the smallest solid chunk I can land cleanly with tests and release outputs.

I found a promising seam in the first broad geometry item: there’s a lot of released geometry and BOM machinery already, but I don’t yet see the explicit geometry-to-BOM completeness gate named in the TODO verification. I’m checking whether we can close that gap by formalizing the mapping and only touching geometry where the new gate exposes real holes.

I’m checking whether the released geometry and the BOM are already almost in agreement. If they are, I can formalize that as the missing gate and avoid bigger geometry churn than we actually need for this TODO item.

The geometry/BOM comparison surfaced exactly the kind of closure gap I hoped for: the released solids already include `primary_mount`, `primary_mount_pad`, and `primary_mount_fastener`, but the BOM doesn’t claim them, and the BOM still claims an `entrance_baffle_segment` family that isn’t actually generated. I’m going to wire in an explicit completeness gate around that mapping and then fix the metadata so the baseline passes honestly.

I’ve got the change scoped: add a dedicated geometry-to-BOM completeness gate, fix the current family metadata mismatch it exposes, and wire that gate into the normal release path so it can’t drift again. I’m editing the checker, the BOM metadata, and the tests now.

I’m at the edit point now. The new gate will read the released manufacturing BOM plus deployed/stowed manufacturing part exports, so it checks the actual package we ship rather than an in-memory approximation.

The edits are in. I’m running the new checker’s unit tests and the directly affected regressions first so I can tighten anything obvious before the full repo pass.

The new tests are green. The checker itself failed against stale generated outputs, which is actually useful: I’m rebuilding the manufacturing package now so the released BOM and part exports reflect the new metadata before I re-run the gate and inspect what remains.

The rebuild is in the heavy `run_cases --optimize` part now. While that runs I’ve already confirmed the earlier checker failure was driven by stale artifacts plus the intended BOM-family gap, not by the new logic itself.

The BOM row fix did land; the confusing report was from a parallel read racing the checker. The remaining real issue is narrower now: the released stowed package includes `sunshield_stow_pack_*` and `sunshield_pack_bracket_*` solids, plus the package-level `assembly.stl`, and those names need to be classified or excluded intentionally.

The new gate found a real release-hygiene issue: `build_manufacturing_package.py` was leaving stale `.stl` files behind in `outputs/manufacturing/.../parts`, and the part directories also intentionally contain `assembly.stl`, which shouldn’t be treated like a BOM line item. I’m fixing both so the gate checks the live package cleanly instead of being polluted by leftovers.

One unit test exposed a small mismatch between the public helper and the filesystem loader: the loader ignores `assembly.stl`, but the pure summarizer didn’t. I’m aligning those paths so the behavior is consistent everywhere.

The failing unit result was just from the pre-patch process; the helper now behaves correctly when called fresh. I’m letting the long rebuild finish, then I’ll rerun the updated tests and the manufacturing/completeness gates together from a clean start.

I’m moving from focused regressions to end-to-end verification now: full test suite, release/state/site gates, and then a quick sanity pass over the generated reports plus the rendered outputs so we’re not just trusting green checks blindly.

The end-to-end runs are underway now. I’ve already seen the full test run get past the launch-envelope-heavy cases, and `release-state` is through the early policy gates and into the artifact rebuild path.

The big verification pass is still grinding through the expensive artifact-backed checks, but nothing has tripped so far. I’m keeping an eye on the long runners and will only move on once we’ve got clean exits plus a manual sanity read of the generated artifacts.

The release-state run found one more real issue: my stale-file cleanup was deleting the just-written `assembly.stl` from the manufacturing package, which `release-state` correctly treats as required. I’m fixing the export order and adding a regression so we keep the cleanup without losing the package assembly file.

The release-state retry is back in the full rebuild path, and the targeted regressions are re-running with the new assembly-file guard in place. Once those are green, I’ll do the final full-test rerun and the site/deploy sequence.

I’m waiting on the long `release-state` finish now. After that I’ll do one last full-suite rerun against the final tree, then use the browser automation skill to spot-check the generated site imagery before I push and deploy.

The release gate is clean now. I’m doing a quick artifact sanity pass next by reading the release reports and then opening the generated site in a real browser so we can confirm the previews/render outputs still look like the geometry the reports are describing.

I’ve got the release gate green, so I’m doing the final pre-push website build/smoke run now. That gives us one more full `make all` path, rebuilds the stakeholder site, and validates the published-page tree before I commit.

`website-smoke` is still chewing through the phony `all` target path, so it’s effectively giving us one more clean-room full rebuild and test run. I’m letting it finish so the site validation result itself is part of the evidence, not just the intermediate checks.

The site smoke is green, and the generated homepage is pointing at the deployed/stowed render previews I expected. I’m doing one last lightweight image sanity check on those hero PNGs now so we’re not pushing a broken or blank visual even though the HTML/report checks passed.

I’ve got the code, reports, and site checks where I want them. I’m staging the changes now, then I’ll make a focused commit, push it, and use the local website deploy path to publish to merah.

The commit is on `origin/main` now. I’m running the local deploy path next so the published stakeholder site is rebuilt from the pushed tree and then rsynced to merah.

The local deploy path is doing exactly what we asked of it: it’s re-running the whole phony release/build stack from the pushed tree before it publishes. It’s slow, but it means the site going to merah is being rebuilt from the same commit we just pushed instead of reusing stale local output.

Implemented a geometry/BOM release gate and pushed it as `8f4c75d` on `main`. The main change is [scripts/check_geometry_completeness.py](/Users/gregb/Documents/devel/aao-mechd/scripts/check_geometry_completeness.py), wired into [Makefile](/Users/gregb/Documents/devel/aao-mechd/Makefile) and CI, plus BOM metadata fixes in [scripts/build_manufacturing_package.py](/Users/gregb/Documents/devel/aao-mechd/scripts/build_manufacturing_package.py). I also fixed a real release bug where stale manufacturing-part STLs could survive between runs, and added regressions in [tests/test_geometry_completeness.py](/Users/gregb/Documents/devel/aao-mechd/tests/test_geometry_completeness.py) and [tests/test_manufacturing_package.py](/Users/gregb/Documents/devel/aao-mechd/tests/test_manufacturing_package.py). I left the umbrella TODO item open, since this closes the verification gap and metadata drift but not every remaining geometry subtask under that section.

Verification is clean. The full unit suite passed twice on the final tree (`304` tests), `make release-state` passed, and `make website-smoke` passed. For sanity, I reviewed [outputs/release_state/report.md](/Users/gregb/Documents/devel/aao-mechd/outputs/release_state/report.md), [outputs/geometry_completeness/report.md](/Users/gregb/Documents/devel/aao-mechd/outputs/geometry_completeness/report.md), and [outputs/site_policy/report.md](/Users/gregb/Documents/devel/aao-mechd/outputs/site_policy/report.md); all were `PASS`. I also checked the deployed/stowed hero PNGs and labeled site previews: all are `1920x1080` and nonblank by pixel-stat sanity.

Git is clean, the commit is pushed, and the site has been deployed to merah:
`https://telescope.symmachus.org/`