/thorlabs-blender-optical-path

name: thorlabs-blender-optical-path
description: Design, reconstruct from photographs or schematics, correct, audit, and present Blender optical systems using provenance-bound CAD and measured optical and mechanical interfaces. Use for optics-only laboratory models, constrained revisions, stateful instruments, and publication renders with explicit evidence and privacy boundaries.
metadata:
  version: "2.0.0"

OpticalModeler 2.0 — Thorlabs Blender Optical Path

Turn a measurement requirement, schematic, or photographed apparatus into an editable, explainable Blender scene. Deliver the requested model and views with evidence that matches the claim. Manufacturer geometry, installed identity, visual readiness, and physical qualification are separate facts.

Load the relevant references

• Read [physical-gates.md](references/physical-gates.md) before geometry, CAD placement, or mechanical review.
• Read [evidence-contract.md](references/evidence-contract.md) before declaring any PASS or preparing a release.
• Read [history-derived-rules.md](references/history-derived-rules.md) when revising an existing scene or when old fixes may have regressed.
• Read [project-case-study.md](references/project-case-study.md) for the complete G1/G2 2D-to-3D example.
• Read [fresh-design-and-rendering.md](references/fresh-design-and-rendering.md) when the user requests a new measurement path, uses an old example as a quality reference, excludes electronics, or reports inadequate detail/beam visibility.
• Read [photo-reconstruction-and-revisions.md](references/photo-reconstruction-and-revisions.md) for photographed setups, constrained layout changes, repeated user corrections, or selectable ports/shutters.
• Read [presentation-and-delivery.md](references/presentation-and-delivery.md) for material/light changes, image reuse, interactive opening state, and final delivery.
• Read [publication-privacy.md](references/publication-privacy.md) before publishing laboratory-derived guidance or examples. Keep the private identity map outside the public tree.
• Read [end-to-end-workflow.md](references/end-to-end-workflow.md) before a whole-system build or large forward test. Use its single-run ledger instead of splitting one system into independently authored modules.
• Read [multi-run-qualification.md](references/multi-run-qualification.md) before a Skill release or scale/stress campaign that must compare multiple fresh whole-system runs.

Published detailed prompts, correction loops, and final handoffs: [six walkthroughs](https://github.com/k-telux/OpticalModeler/blob/v2.0.0/examples/v2.0/README.md), [English dialogues](https://github.com/k-telux/OpticalModeler/blob/v2.0.0/examples/v2.0/WALKTHROUGHS.md), and [中文交互案例](https://github.com/k-telux/OpticalModeler/blob/v2.0.0/examples/v2.0/WALKTHROUGHS.zh-CN.md). They are edited teaching examples, not raw conversations or a new qualification campaign.

Authority and revision rules

1. Apply system constraints first, then the newest explicit user wording or annotated screenshot, then active project rules, then this general skill, and only then older artifacts or PASS labels. 2. Freeze submitted or accepted packages. Make corrections in an active revision without overwriting frozen evidence; group related fixes before submission instead of publishing a version for every preview. 3. Keep one writer, run ID, revision root, deterministic generator lineage, saved-Blend lineage, and workflow ledger for the whole system. Use helpers only as read-only reviewers unless an isolated non-shared asset scope is explicit; never stitch independently authored modules into a whole-system claim. 4. Translate every correction into object families, fixed and editable degrees of freedom, world-space geometry, a measurable gate, and required evidence before editing. "Make it compact" does not authorize changing the optical order, internal spacing, or an accepted upper endpoint. 5. Use `BLOCKED` or `UNVERIFIED` when real geometry or evidence is missing. File existence, imported CAD, process success, labels, AABB contact, and self-reported text are not proof. 6. Use existing evidence and photographs before asking a material question. If the user requests a complete review candidate before further measurements, finish that authorized candidate with explicit unknowns; do not invent hardware identity or call it physically qualified. 7. When helpers are authorized, assign isolated scopes and keep ordinary findings in a consolidated queue read at checkpoints. A moving build/render is not stalled. External messages, uploads, and publication require the user's authorization for those actions.

Core workflow

First choose new measurement design, photograph/schematic reconstruction, constrained correction, presentation-only rerender, or audit-only work. Record which inputs are design authority, reusable assets, or visual references. A new measurement at an old example's quality starts from an empty scene. An explicitly retained reconstruction baseline can be reused read-only in a new revision. For optics-only requests, exclude electrical/data/circuit visualization while retaining optical detectors and their mechanical supports.

1. For a new whole-system build, initialize the run spec, state ledger, and append-only event hash chain with `scripts/workflow_ledger.py`. For a scoped correction, continue the existing lineage with a frozen input lock, declared change set, current evidence and delivery manifest; do not fabricate completion of pending whole-system stages. 2. Build a machine-readable map: `schematic node -> experimental role -> real asset -> optical/fiber/electrical ports -> support path`. 3. Inventory every directed edge, branch, optional/deferred node, component, beam segment, beam height, aperture, connector, and required detector endpoint. Never invent reciprocal edges. 4. Acquire official CAD only from manifest-locked manufacturer URLs into a private cache. Verify byte count and