← Commit history

Publish 0.8.42

John Lauer ·dc1b4ab750 ·15d ago ·parent ea4ea4e
5 files changed +96−2
install.sh

  
package.json+1−1
@@ -1,7 +1,7 @@ {   "slug": "adom-wiki-skillpack",   "title": "Adom Wiki Skill Pack",-  "version": "0.8.41",+  "version": "0.8.42",   "type": "skill",   "hero": {     "path": "screenshots/hero.png"
page.json+1−1
@@ -131,7 +131,7 @@       "prompt": "Before I create this wiki page, check whether the thing already has a home."     }   ],-  "version": "0.8.40",+  "version": "0.8.42",   "description": "The Adom Wiki Skill Pack : one main skill plus the focused sub-skills that teach the AI to publish to wiki.adom.inc without breaking pages, name the wiki repo archetypes (Page, Skillpack, Family), and publish rich component pages (chips, molecules, boards). The wiki is six tools in one: git, package manager, releases, discussions, pull requests, and discovery. One package manager install drops the whole set onto your container. Includes reviewed Z-up component artwork, surface-selected MPN marking, reusable thumbnail caches and component-page widgets.",   "dependencies": {     "adom/adom-wiki-hero-image": "^0.2.2",
skills/wiki-component/SKILL.md+47
@@ -994,3 +994,50 @@ Validate the actual written LOD transforms and visible MPNs; micrometre offsets ## Ship the bench with a board or project page  A board, molecule or project page can carry its author's Hydrogen layout: `hydrogen/workspace.json` in the page repo, with the 3D layout pane, the KiCad or Altium dashboard, the parts search and the project page arranged the way you work. Export it from a live Hydrogen with `adom-cli hydrogen workspace export --out hydrogen/workspace.json`, push it with `adom-wiki repo push <owner>/<slug> --files hydrogen/workspace.json`, and readers of a fork or clone open it with `adom-cli hydrogen workspace apply <owner>/<slug>` (Hydrogen Cloud lists it under Project workspaces with an Apply button). Apps are referenced by wiki page, never by URL; declare each in `page.json` `dependencies`. The full contract and the `WORKSPACE_*` hints are in the wiki-workspaces skill.++## Gentle state demonstrations in component heroes++When a component declares states, deliberately review whether its hero GLB can+show those states clearly and quietly. Prefer a restrained demonstration of the+part's actual behavior, not arbitrary model or camera motion. For a fan, hold+still, ease into rotation, hold a readable speed, ease back to rest, and remain+idle for several seconds. Use smooth speed transitions and a seamless stationary+loop boundary. A useful starting point is 4 seconds idle, 4 seconds ramp-up,+4 seconds running, 4 seconds ramp-down, and 4 seconds idle. Prefer one cycle and+rest unless a gentle repeating demonstration helps; never use frantic spinning,+strobing, flashing, abrupt jumps, perpetual camera orbit or attention-grabbing+pulses. Honor reduced-motion/animation-off controls and keep a useful still frame.++Keep the presentation clip separate from operational state animations. Do not+export two animation groups that fight over the same property when the canonical+viewer autoplays all groups. Publish the hero-only cycle in model_3d and retain a+clean board/runtime asset in model_3d_plain or the state model mapping. Baked glTF+rotation/transform/material animation can demonstrate states even when a widget+does not yet implement a proposed state-metadata extension. Verify actual viewer+support; new metadata alone does not implement runtime behavior.++Record the hero's named animation, target scene nodes, duration, dwell/ramp+schedule and demonstration source in states.json under an explicitly described+presentation extension. If physical RPM would alias or look frenetic, use a+clearly disclosed presentation scale. Demonstrated or commanded speed is not+measured speed. Unknown/stale telemetry must remain unknown, not look like a+confirmed stopped or running device. STEP remains static. Hero playback must not+control equipment. Test the full cycle, repeat seam, animation-off state, manual+camera interaction, hidden/offscreen lifecycle and the real published viewer;+record a short representative clip.++For parts with cables or flying leads, include the leads and termination in the+asset review. Verify exact ordering variant, lead count/colors/gauge/length,+stripped ends, connector housing and contact MPNs, mating part, contact numbering+and orientation from primary evidence. Never invent a factory connector. If the+part ships bare-ended, preserve an as-supplied variant and label any added+connector as an assembled harness variant, with a separate BOM and pin map.+Model the termination in that hero, disclose installation-dependent cable routing,+and keep its stationary nodes outside moving rotor/actuator branches. Provide+symbols, mechanical mounting templates and mating PCB footprints where applicable;+a cable housing has no PCB solder footprint. Explicitly distinguish these assets+so an AI cannot mistake mounting holes for electrical terminals. Verify mating+geometry, polarity, crimp/wire compatibility and native EDA import before calling+the assembly qualified.++For mechanical-only components without copper pads, do not fabricate electrical pads to satisfy a hero-overlay tool. Retain the genuine mounting template and separate mating connector footprint, document the tool limitation, and verify the authored mechanical hero independently.
skills/wiki-hero-glb/SKILL.md+47
@@ -196,3 +196,50 @@ not a page load.    frame reads too. 5. No GPU instancing; Draco or quantization is fine; open the page and read    the browser console once: the viewer says what it refused.++## Gentle state demonstrations in component heroes++When a component declares states, deliberately review whether its hero GLB can+show those states clearly and quietly. Prefer a restrained demonstration of the+part's actual behavior, not arbitrary model or camera motion. For a fan, hold+still, ease into rotation, hold a readable speed, ease back to rest, and remain+idle for several seconds. Use smooth speed transitions and a seamless stationary+loop boundary. A useful starting point is 4 seconds idle, 4 seconds ramp-up,+4 seconds running, 4 seconds ramp-down, and 4 seconds idle. Prefer one cycle and+rest unless a gentle repeating demonstration helps; never use frantic spinning,+strobing, flashing, abrupt jumps, perpetual camera orbit or attention-grabbing+pulses. Honor reduced-motion/animation-off controls and keep a useful still frame.++Keep the presentation clip separate from operational state animations. Do not+export two animation groups that fight over the same property when the canonical+viewer autoplays all groups. Publish the hero-only cycle in model_3d and retain a+clean board/runtime asset in model_3d_plain or the state model mapping. Baked glTF+rotation/transform/material animation can demonstrate states even when a widget+does not yet implement a proposed state-metadata extension. Verify actual viewer+support; new metadata alone does not implement runtime behavior.++Record the hero's named animation, target scene nodes, duration, dwell/ramp+schedule and demonstration source in states.json under an explicitly described+presentation extension. If physical RPM would alias or look frenetic, use a+clearly disclosed presentation scale. Demonstrated or commanded speed is not+measured speed. Unknown/stale telemetry must remain unknown, not look like a+confirmed stopped or running device. STEP remains static. Hero playback must not+control equipment. Test the full cycle, repeat seam, animation-off state, manual+camera interaction, hidden/offscreen lifecycle and the real published viewer;+record a short representative clip.++For parts with cables or flying leads, include the leads and termination in the+asset review. Verify exact ordering variant, lead count/colors/gauge/length,+stripped ends, connector housing and contact MPNs, mating part, contact numbering+and orientation from primary evidence. Never invent a factory connector. If the+part ships bare-ended, preserve an as-supplied variant and label any added+connector as an assembled harness variant, with a separate BOM and pin map.+Model the termination in that hero, disclose installation-dependent cable routing,+and keep its stationary nodes outside moving rotor/actuator branches. Provide+symbols, mechanical mounting templates and mating PCB footprints where applicable;+a cable housing has no PCB solder footprint. Explicitly distinguish these assets+so an AI cannot mistake mounting holes for electrical terminals. Verify mating+geometry, polarity, crimp/wire compatibility and native EDA import before calling+the assembly qualified.++For mechanical-only components without copper pads, do not fabricate electrical pads to satisfy a hero-overlay tool. Retain the genuine mounting template and separate mating connector footprint, document the tool limitation, and verify the authored mechanical hero independently.