AI Flow

@@ -85,6 +85,24 @@ over a finished video that skipped this.  ## Publish +Read **wiki-video-captions** from `adom/adom-wiki-skillpack` before embedding.+Use `::adom-video` with synchronized speech captions and chapters; do not default+to a raw HTML video tag. The tag's `video=` is the MP4 and `src=` is a JSON+manifest. Absolute `/OWNER/SLUG/render/...` paths are required. A manifest may+inline WebVTT text and chapter rows, which also avoids unauthenticated caption+fetches on private pages. Put the widget first when the user requests it.++Reuse actual narration text, align phrase/sentence cues to the FINAL audio, and+regenerate VTT/SRT and chapters after every timing change. Measure padded silence+and trim it without clipping speech; preserve natural pauses and useful motion.+Do not pad the voice or picture just to hit a target runtime. Verify the real+widget frame using `document.querySelector('adom-video').adomDrive.state()`:+duration must match, captions and chapters must be nonzero, and beginning,+middle and ending cues must follow the spoken words. Inspect caption display,+muted test playback and the rendered README before delivery. Source publication,+package release and already-loaded AI skills are separate states.++ On the project's own wiki page: the player on the main README, and a sub-readme (`docs/process-video.md`) that explains how it was made: each scene's source clips, the full voice-over script, the tools. **Never a separate wiki page for the video**: that is wiki bloat. The web copy stays

@@ -11,6 +11,13 @@ A board project must showcase its board assembly, not one of its component asset 2. Explicitly set `component.parts.model_3d` to the reviewed complete board/assembly GLB and `component.parts.datasheet` to the project PDF in page.json. Bind any offered STEP to the real board too, never a component. Inspect the model visually; a nonempty GLB or many meshes do not prove assembly identity. Show connectors, cooling and mounting parts; label candidate revisions, missing details and clearance envelopes. Keep runtime models separate from gentle hero-only state animation. 3. Write a real project-authored engineering datasheet: revision and board identity, operating envelope and derating, modes, connectors/pinout, control protocol, power supplies, protection, mechanical/mounting dimensions, fabrication stack and qualification limits. Clearly separate design limits, simulation and measured specifications. Never repurpose a component-symbol PDF, blank placeholder or unrelated manufacturer datasheet. Inspect every rendered PDF page. Set `sections` to put `readme` before `viewers`, retaining other intended sections, so the datasheet is at the bottom. 4. Put 5–8 distinct real screenshots in the README with descriptive alt text and captions: assembled board, native board/layout, control panel, meaningful analysis, workflow and manufacturing review as available. Inspect each image. Reject blank video posters, duplicate angles, tiny unreadable UI and stale status presented as current. Caption historical revisions and simulated readings. Do not invent test results to fill the gallery.++   For any narrated project video, read **wiki-video-captions** from+   `adom/adom-wiki-skillpack` and use `::adom-video` with captions and chapters.+   Place it directly after the README title when asked to lead with the film.+   Regenerate timing after edits, check voiceover gaps, and inspect the real+   widget frame. The project-page checker does not prove video/caption playback.+ 5. Run `adom-aiflow project-page-check --project <root>`. It checks explicit assets, GLB structure, extractable PDF text (requires pdftotext), screenshot paths/count and section order. It does not certify image quality, model identity or datasheet accuracy; complete the visual review too. Keep generator sources with the project. 6. Push only the reviewed files. Fetch `/api/pages/<owner>/<slug>` into a local JSON and rerun with `--live-json <file>`; require exact model/datasheet binding equality and the intended rendered README. Verify uploaded bytes or hashes. Use one existing Pup window or Hydrogen tab according to the user's preference; never open duplicates. 7. Open the actual page, load the 3D hero, orbit it, inspect all screenshots and read the first and final datasheet pages. Verify the datasheet follows the README in live section order. Record screenshots/evidence and a short action clip where recording was requested. A successful push or HTTP200 is not rendered acceptance. Fix wrong assets before calling the project page delivered.