Adom Wiki Skill Pack
Public Made by Adomby adom
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 marki
master
Verification, recording and recovery
Before opening a large assembly on the user's desktop, inspect the actual GLB primitives and decoded sizes. Test expensive generation and the initial scene in an isolated process with explicit limits. After a reported freeze, do not reopen the same unbounded scene to obtain a screenshot or repeat the demonstration.
Required evidence for a complete LOD implementation:
- All four levels exist, hashes match their source manifest, and units, axes, pivots and footprint transforms agree. Missing/stale cache files produce actionable diagnostics.
- Close-up high detail matches the physical chip portion of the reviewed component page (hero-only footprint/silkscreen/label overlays must be absent): exact virtual MPN and placement, manufacturer markings, colors, terminal geometry and relevant pin-1 indicator. The same comparison is made in the assembled board. Shared symbol thumbnails remain derived from the reviewed art.
- Coarse silhouettes and critical features remain recognizable. Zoom transitions do not jump, flip or visibly change component placement. Orthographic/perspective, large/small packages, viewport resizing and scaffold-wide views are covered.
- Cold start fetches coarse assets only. Repeated near/far zoom cycles demonstrate lazy detail fetch, hysteresis, reuse across identical parts, canceled stale requests and eventual eviction. Network logs and resource counters prove the behavior. Bound memory after repeated cycles, including reload/dispose and switching boards; one FPS sample is insufficient.
- Capture startup evidence before the first screen-size promotion. A large part may legitimately request more detail immediately after coarse startup finishes. Verify request ordering and the initial coarse inventory; do not confuse later promotion with eagerly downloading high assets before the first usable frame.
- Compare resource counts after each return to the same coarse state. Container/geometry counts and decoded-byte estimates should return to baseline. In isolated WebGL tests, instrument createBuffer/deleteBuffer to verify live buffer counts also stabilize; this is stronger than merely hiding meshes, but still does not measure hardware driver VRAM or qualify desktop performance. Fail the run on browser exceptions, even if the screenshot looks correct.
- Hover/select identifies the same physical reference in 2D and 3D at every LOD. LED/material states, moving joints and digital-twin controls survive swaps. A static electronics test does not qualify motion-state swapping.
- Hidden/idle views stop rendering. Active frame times, draw calls and decoded/resident resource budgets meet the deployment target. Frame drops or budget exhaustion trigger diagnostics and reduced detail, not disappearing components.
- Full-scene native CAD parity, model seating and fabrication checks remain separate from presentation LOD qualification.
Recording is a separate resource user. Verify the actual recorder target, engine, frame progression and saved file. Hardware/GPU acceleration can help capture but cannot repair excessive scene draw calls or retained meshes. Stop this thread's recording and pause its renderer when the user reports slowdown; do not disturb other threads or take OS foreground. Record purposeful inspection motion after the resource checks pass. Keep per-take metadata so wrong-target, stalled or failed checks are excluded from product footage and retained only when useful for an explicitly chosen engineering edit.
For incidents, preserve evidence (versions, returned source, primitive counts, frame timing and logs), duplicate-check and file on the owning viewer/bridge/wiki project. Distinguish observations from suspected causes: a high static mesh count is not proof of a leak. Recheck a live process or recording handle before restarting. Source fixes, generated caches, published skills, installed skills and running AI context must each be verified separately.
Reject any board LOD containing footprint outlines, pad names/numbers, silkscreen or other nonphysical board art, including high. Inspect top and underside to distinguish real package terminals from footprint helpers. Verify the separately annotated hero remains unchanged.
A successful model download is not a visible result. Check actual scene readiness, loading-overlay dismissal and a rendered screenshot. Exercise enable when the button is near the bottom of a short viewport: reveal the expanded viewer before offscreen observation, then prove that later scrolling it offscreen releases resources. Record failed takes separately from accepted motion footage, with per-clip trim/crop and editorial metadata.
# Verification, recording and recovery
Before opening a large assembly on the user's desktop, inspect the actual GLB primitives and decoded sizes. Test expensive generation and the initial scene in an isolated process with explicit limits. After a reported freeze, do not reopen the same unbounded scene to obtain a screenshot or repeat the demonstration.
Required evidence for a complete LOD implementation:
- All four levels exist, hashes match their source manifest, and units, axes, pivots and footprint transforms agree. Missing/stale cache files produce actionable diagnostics.
- Close-up high detail matches the physical chip portion of the reviewed component page (hero-only footprint/silkscreen/label overlays must be absent): exact virtual MPN and placement, manufacturer markings, colors, terminal geometry and relevant pin-1 indicator. The same comparison is made in the assembled board. Shared symbol thumbnails remain derived from the reviewed art.
- Coarse silhouettes and critical features remain recognizable. Zoom transitions do not jump, flip or visibly change component placement. Orthographic/perspective, large/small packages, viewport resizing and scaffold-wide views are covered.
- Cold start fetches coarse assets only. Repeated near/far zoom cycles demonstrate lazy detail fetch, hysteresis, reuse across identical parts, canceled stale requests and eventual eviction. Network logs and resource counters prove the behavior. Bound memory after repeated cycles, including reload/dispose and switching boards; one FPS sample is insufficient.
- Capture startup evidence before the first screen-size promotion. A large part may legitimately request more detail immediately after coarse startup finishes. Verify request ordering and the initial coarse inventory; do not confuse later promotion with eagerly downloading high assets before the first usable frame.
- Compare resource counts after each return to the same coarse state. Container/geometry counts and decoded-byte estimates should return to baseline. In isolated WebGL tests, instrument createBuffer/deleteBuffer to verify live buffer counts also stabilize; this is stronger than merely hiding meshes, but still does not measure hardware driver VRAM or qualify desktop performance. Fail the run on browser exceptions, even if the screenshot looks correct.
- Hover/select identifies the same physical reference in 2D and 3D at every LOD. LED/material states, moving joints and digital-twin controls survive swaps. A static electronics test does not qualify motion-state swapping.
- Hidden/idle views stop rendering. Active frame times, draw calls and decoded/resident resource budgets meet the deployment target. Frame drops or budget exhaustion trigger diagnostics and reduced detail, not disappearing components.
- Full-scene native CAD parity, model seating and fabrication checks remain separate from presentation LOD qualification.
Recording is a separate resource user. Verify the actual recorder target, engine, frame progression and saved file. Hardware/GPU acceleration can help capture but cannot repair excessive scene draw calls or retained meshes. Stop this thread's recording and pause its renderer when the user reports slowdown; do not disturb other threads or take OS foreground. Record purposeful inspection motion after the resource checks pass. Keep per-take metadata so wrong-target, stalled or failed checks are excluded from product footage and retained only when useful for an explicitly chosen engineering edit.
For incidents, preserve evidence (versions, returned source, primitive counts, frame timing and logs), duplicate-check and file on the owning viewer/bridge/wiki project. Distinguish observations from suspected causes: a high static mesh count is not proof of a leak. Recheck a live process or recording handle before restarting. Source fixes, generated caches, published skills, installed skills and running AI context must each be verified separately.
Reject any board LOD containing footprint outlines, pad names/numbers, silkscreen or other nonphysical board art, including high. Inspect top and underside to distinguish real package terminals from footprint helpers. Verify the separately annotated hero remains unchanged.
A successful model download is not a visible result. Check actual scene readiness, loading-overlay dismissal and a rendered screenshot. Exercise enable when the button is near the bottom of a short viewport: reveal the expanded viewer before offscreen observation, then prove that later scrolling it offscreen releases resources. Record failed takes separately from accepted motion footage, with per-clip trim/crop and editorial metadata.