Component Widgets

@@ -224,3 +224,50 @@ After activation, verify off, offscreen, hidden-tab, disconnection and cancelled Fit iframe height from intrinsic widget content, coalesce callbacks and only emit changed heights. Never repeatedly add padding to documentElement.scrollHeight: the iframe viewport can become its own ever-growing input. Test within a parent that really applies readme-height, including repeated status updates and scrolling.  For every widget, record cold-load and scroll-only network/DOM/context evidence before clicking, then an activation and teardown cycle. Same-browser siblings can dominate the page's memory even when this widget reports zero. Source edits, shared package publication, registry script delivery, and already-open browser tabs are distinct deployment states.++## 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.

@@ -2,7 +2,7 @@   "slug": "component-widgets",   "title": "Component Widgets",   "type": "app",-  "version": "1.1.16",+  "version": "1.1.17",   "description": "Reusable component-page widgets for pinouts, thermal vias, molecule relationships, reviewed chip outlines and image-first LOD caches with an optional zoom-driven 3D preview.",   "license": "MIT",   "dependencies": {},

@@ -4,7 +4,7 @@   "type": "app",   "title": "Component Widgets",   "brief": "Reusable component widgets for pinouts, thermal vias, molecule relationships, reviewed chip outlines and lightweight four-level LOD cache listings.",-  "version": "1.1.16",+  "version": "1.1.17",   "visibility": {     "public": true   },

@@ -224,3 +224,50 @@ After activation, verify off, offscreen, hidden-tab, disconnection and cancelled Fit iframe height from intrinsic widget content, coalesce callbacks and only emit changed heights. Never repeatedly add padding to documentElement.scrollHeight: the iframe viewport can become its own ever-growing input. Test within a parent that really applies readme-height, including repeated status updates and scrolling.  For every widget, record cold-load and scroll-only network/DOM/context evidence before clicking, then an activation and teardown cycle. Same-browser siblings can dominate the page's memory even when this widget reports zero. Source edits, shared package publication, registry script delivery, and already-open browser tabs are distinct deployment states.++## 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.