---
name: aiflow-project-page
description: Publish and review a great AIFlow board project wiki page with an explicit assembled-board hero GLB, 5–8 meaningful screenshots, a real project datasheet at the bottom and verified live asset bindings (a molecule page gets no pushed GLB: the wiki registry builds its model). Use before final delivery or when a chip or blank datasheet appears on a board page.
user-invocable: true
---
# Deliver the project page

## Design review: `project-page --results`

Analysis results belong on the page people read, not only on the run report. After `analyze current`, `analyze thermal` or `tour fields` (they say so when the page's review is missing or older than the board, and `finish` says it again), run `adom-aiflow project-page --results`: it writes `design-review/README.md` for the current board (Fields current and thermal tables, the screens' verdicts, your `artifact --kind analysis-image` figures, a molecule's contact table, and the parts table with unit and line prices and buy links when the BOM has those columns) under `<run>/page-results/`, records which board it describes, and prints the `adom-wiki repo push`. Link it from the README as a sub-README card. For a molecule, `--out <molecule-publish package folder>` writes it into the package instead. Still by hand: chip images on the parts table and the interactive schematic (circuit explorer); the command lists them as open.

## Revision 1: `project-page`

`adom-aiflow project-page --page <owner/slug> --create [--brief <text or file>]` makes one Cloud Library per board and keeps its `lib_` id in the run; a rerun reuses it and never makes a second library of the same name (when duplicates already exist it uses the fullest and says which to delete). Rate-limited adds (HTTP 429, `retry_after`) are retried with backoff (`ADOM_AIFLOW_WIKI_ATTEMPTS`, `ADOM_AIFLOW_WIKI_MAX_WAIT`). The step is an ERROR, and nothing is published, when the exported library is short of any BOM part (per part: its symbol is in the library, the symbol's Footprint names a footprint file in it, and that footprint's model file is in it; parts may share a footprint or a model, and a part marked `noModelExpected` needs none; the error names each part by MPN and references) or when the packaged symbol library does not load: the header is written as version 20241209 (KiCad 9 format, read by KiCad 10) and the file is parse-checked, with `kicad-cli sym upgrade` through `ADOM_AIFLOW_KICAD_CLI` when available. `--brief` takes text or a path to a file whose contents are used. Parts from the board's project library (`parts --project-lib`) are packaged beside the wiki parts; an entry marked `"prefer": true` replaces its MPN's wiki page (aiflow-sourcing, "Which source wins"). `--no-push` pushes nothing to the page but still adds the wiki parts to your private Cloud Library and exports it (that is where their files come from); `--local-only` makes no wiki call at all, packages only the project-library parts and names the wiki parts it left out.

The PCM package version follows its content (issue #169): the first build is 1.0.0; a rebuild whose files differ from the last build (the run's `pcm/build.json`, else the page's published `pcm/build.json` or `pcm/packages.json`) gets the next patch version, and the same content keeps its version, so KiCad's PCM sees an update. `pcm/build.json` (version and content hash) is pushed with the repository. `pcm check` reports an installed version older than the build, with the `kicad_pcm_install {"identifier": ..., "update": true}` call.

A board in a folder of an existing project page (one page per project): `adom-aiflow project-page --page <owner/slug> --page-dir <folder>` writes the board's README to `<folder>/README.md` (only when the folder has none yet, or with `--replace-readme`) and its PCM repository to `<folder>/pcm/`, with the repository, packages and download URLs under `.../files/<folder>/pcm/`. It never creates a page: the page must exist, `--existing` is implied and `--create` is refused. The library nickname (`PCM_<slug>-<last folder name>`), the PCM identifier and the Cloud Library name carry the folder, so two boards on one page never share a library. The step pages then go to `<folder>/steps/` and the build section to `<folder>/README.md`.

**A molecule is different.** When the spec has `molecule`, `project-page` creates the page with `--kind molecule`, not `board`. Do not push a GLB to it or bind `component.parts.model_3d` (steps 2 and 6 below do not apply to the model): the wiki's model registry builds a molecule page's GLB, footprint and symbol from the sources molecule-publish publishes after `export` (STEP, board, schematic, `<slug>-fab.zip`, `export.json`; skill aiflow-molecule, section 5), and molecule-publish refuses a pushed GLB (`REGISTRY_MODEL_FILE_REFUSED`). `project-page-check` skips the model on a page of kind molecule and suggests dropping a bound one.

A board project must showcase its board assembly, not one of its component assets. Never rely on recursive repository asset discovery: embedded component GLBs, STEP files and PDFs can silently win.

1. Read the live page and current immutable source HEAD before editing; preserve concurrent work. Confirm which README variant renders. Read wiki-hero-glb and the wiki publishing contract.
2. On a board page (not a molecule), 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.

A board page (or a molecule's) must carry this board's design review: when the run has analyses and `project-page --results` was never run, or was run for an earlier board or before the latest analysis, `finish` lists it as an open item and `deliver` says so (issue #199).

What a page says about fabrication readiness comes from the run's `summary.verified` (issue #192): it always holds the newest check (`checkedBy` is finish, export or deliver, with `at`), `lines` reads each item as people should see it ("fills in Gerbers not known (not exported yet)"), and `verdict` is written for readers. Never publish an older snapshot after a later check, never print a raw state object, and never put an instruction meant for the AI on a page. Build or refresh the page after `export` (and after `deliver`), so it shows that check.

Call this preflight and review before final delivery whenever the run publishes a project page. It supplements, never replaces, electrical, thermal, mechanical, fabrication or simulation gates. A draft may be published with explicit limitations; do not claim final delivery while page acceptance remains open.