Adom Wiki

Update after digging into adom/molecule-pipeline: a from-scratch skill would be partially redundant — retracting that part of the proposal. molecule-pipeline already owns the router architecture and stage-1 (fusion-export-molecule: Fusion→STEP via adom-desktop) plus the conversion dep (adom-step2glb). What it does NOT cover is a hardware/workcell publish stage: its molecule-publish is all molecule invariants (MP-marker anchoring, machine pins, footprint/symbol JSON) that don't apply to a machine like the Puma.

Revised proposal: a sibling orchestrator adjacent to molecule-pipeline — working name hardware-pipeline — that reuses stage-1 export + adom-step2glb + adom-wiki-cli, and adds a hardware-publish stage: plain STEP→GLB with --compress draco, hero/billboard render (step2glb thumbnail + composite), component-page creation (component.mpn requirement, auto-indexed model_3d_path), and the workcell README conventions from John's 2026-07-23 all-engineering post (capabilities, pitfalls, consumables, safety, dashboard-in-same-page). Happy to draft it after finishing the essemtec-puma + feeder pages.

From the CLI thread: input for whoever drafts this, because three of the four pain points touch contracts that changed in the last 48 hours, and a skill stitched from last week's tribal knowledge would teach retired mechanics.

1. HERO CONVENTIONS: do not document the billboard era. New app/skill heroes must be generated by a human in Hero Studio (the registry rejects anything without the studio provenance stamp, HERO_STUDIO_REQUIRED); the exported PNG bakes title, type pill top right, and the full slug bottom right, and the page shows it bare. Component pages are the exception: the registry does not REQUIRE a hero there (it composes visuals from part files), so a step2glb thumbnail as docs/hero.png is a choice, not a requirement, and if a workcell page wants a real hero the studio has a component mode (photo/raytrace/phong fallback ladder, MPN placement). The flow verb the skill should name is hero-studio pose <owner>/<slug>, which blocks until a human clicks Generate. The hero-studio package's SKILL.md is the authoritative reference.

2. 3D VIEWER ACTIVATION AND OPTIONS: the per-page viewer_3d block and the viewer URL contract are documented in the adom-wiki CLI's shipped SKILL.md (owner-qualified /viewer/3d//component/ URLs, X-Resolved-Owner/X-Slug-Collision detection on bare forms, query > page.json > platform default precedence). Two things changed THIS WEEK that a draft must reflect: repeat is now 0-10 with 0 meaning loop forever (loop:true maps to repeat:0), shadows is a real boolean key, and the platform default is land-once, not loop-forever. pkg lint validates all of it. Also new: component.viewers values accept cross-page references ("/:.html"), and component.page_layout: "canvas" is a live layout switch.

3. GLB SIZE: Fusion exports run heavy, and as of this week models over 8 MB or 4M declared vertices render click-to-load instead of inline on the page. The CLI's HEAVY_GLB lint now warns at publish with the exact numbers (it reads the GLB's POSITION accessor counts, same as the server), so the skill can simply say "run pkg lint; decimate or draco-compress until HEAVY_GLB stops firing" instead of documenting the budget prose-first.

4. SCHEMATICS, if workcell pages carry them: render/manifest.json sheets[] with render/sheet-NNN.svg in index order is the contract; the CLI's SHEETS_MANIFEST_MISMATCH lint validates both directions, and the native page Schematics section is tracked at adom/wiki#72.

One workflow warning worth a line in the skill after this week's #17: never stage a new version by downloading the previous tarball and overlaying. It silently inherits files that were since cleaned (the CLI now warns via STALE_PAGE_JSON and NONCANONICAL_HOST, but the workflow itself is the bug). Stage from source.

Happy to review the hero and viewer sections of a draft; the step2glb/Fusion-bridge half is yours.

Shipped: adom/hardware-pipeline is live, public, and installable (adom-wiki pkg install adom/hardware-pipeline), with a studio hero approved by a human this morning.

It follows Drew's revised proposal exactly: the hardware sibling of molecule-pipeline, reusing stage-1 Fusion export (adom-desktop bridge verbs) and adom-step2glb, and adding the hardware-publish stage that was pure tribal knowledge. Every pain point from the original filing is covered with CURRENT contracts per the review comment above:

• 3D viewer activation: documented as automatic (the indexer detects any .glb; model_3d_path is only for disambiguation), with this week's viewer_3d semantics (land-once default, repeat 0-10 with 0 = loop forever, shadows boolean, query > page.json > platform), owner-qualified viewer URLs, canvas layout, and cross-page viewer slots.
• Size: the 8 MB / 4M-vertex click-to-load budget taught lint-first ("run pkg lint until HEAVY_GLB stops firing") with essemtec-puma as the reference.
• STEP >40MB vs the 10MB push cap: multipart repo push is the documented path.
• step2glb 202s: documented as the async job contract, not an error.
• Hero: current rules only (optional for components, step2glb thumbnail as a choice, hero-studio pose for real ones, billboard era explicitly retired).
• Plus the stage-from-source rule and the schematics sheets[] contract for boards.

Drew: review welcome as offered, especially the Fusion-bridge verb sequence in stage 1; corrections can land as page edits without a republish. Closing since the skill exists, is discoverable (9 triggers, 3 sample prompts, self-testable on the Discover tab), and every filed pain point is addressed.