AI Flow

Follow-up source audit of tools/project-page.py (installed aiflow 0.2.47), generic, no project data:

1. --no-push does NOT keep the packaging local. In main(), when any part has a wiki page, the code calls cloud_library(...) (around line 978), which runs adom-wiki library create, library add and library export against the remote service. The dry-run check (cfg.get("push"), around line 938) only controls page creation and never gates cloud_library. A user who expects --no-push to be local-only can upload a board's parts list and component selection to a Cloud Library.
2. Precedence: distinct_parts, completeness and pcm_package treat a part as project-library only when not p.get("wiki") (around lines 566, 749, 806, 866). When a wiki page matches an MPN, a verified private projectLib entry for that MPN is silently dropped from the package. There is no per-part source override.

Requested: (a) --no-push (or a separate --local-only) must skip every remote call, including library create/add/export; (b) either an explicit per-part source: projectLib override, or a check that fails when a wiki page and a projectLib entry disagree on the same MPN.

Thank you, Josh, for the report and the source audit. Both checked out against the code. In adom-aiflow 0.2.56 the precedence and --no-push parts are fixed; the geometry check is still open.

1. A verified project-library entry could not win over a wiki page. You were right. parts only looked in the project library for rows with no wiki page, and project-page.py treats a part as project-library only when it has no page (not p.get("wiki")), so a matched page silently replaced your entry.

• A project-library entry can now say "prefer": true in provenance.json ("precedence": "project-lib" works too). When that entry is complete (symbol, footprint, STEP, source), parts uses it for that MPN: the row gets wiki: null, projectLib with your files, and wikiOverridden with the page it replaced. project-page then never adds that page to the Cloud Library and packages your symbol, footprint and model instead. On Altium, altium library builds it from your files too. The parts list shows "project library (preferred over adom/...)".
• When an MPN has both a page and a complete entry with no marking, parts now says so, names both, uses the page, and tells you how to switch. A marked entry that is incomplete keeps the page and says what is missing.
• The rule for which source wins is now in the aiflow-sourcing skill: a page named in the netlist, then a complete "prefer": true entry, then the page parts matched, then an unmarked entry.

2. --no-push still called the wiki. You were right here too. The Cloud Library create, add and export ran on every dry run, because the wiki parts' files come from that export.

• New project-page --local-only: no wiki call at all. It packages only the project-library parts and lists the wiki parts it left out. Implies --no-push.
• --no-push keeps building the full package. It now says plainly that it added the wiki parts to your private Cloud Library to export their files, and that --local-only skips that step.

3. Covered pages are not checked against datasheet geometry: still open. You asked for a warning or failure when a page's footprint or 3D model disagrees with the datasheet. That check is not built yet. When we build it, it will be a finding with a suggested fix, not a failure, because AI Flow is a suggestion engine and never refuses a step. For now, the overlap note asks you to compare pads, thermal pad, 3D height and manufacturer, and "prefer": true lets your verified entry win. For the four parts you listed, marking their entries "prefer": true keeps the public pages' assets out of your package.

How it was verified:

• Unit tests for the preference rules: unmarked, marked, and marked but incomplete.
• A new CLI suite (tests/parts-sources-workflow.py) runs parts with a project library before and after adding "prefer": true.
• Two new project-page tests. One shows a preferred part's page is never added to the Cloud Library. The other shows --local-only makes zero adom-wiki calls.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.56.

Josh, the part left open here, checking a page against the datasheet, is in AI Flow 0.2.70.

Reading a datasheet stays the AI's job, so the AI writes what each datasheet says in design/part-checks.json: the maker, the body height, and the recommended land pad by pad in the footprint's frame, with the source (datasheet, revision, page, figure). adom-aiflow part-check then compares it with the footprint and the STEP the board will actually use, the wiki page's or the project library's, and with the BOM's maker. It reports:

• a pad whose centre or size is more than 0.05 mm off the datasheet's land (a split thermal pad is compared piece by piece);
• a 3D model more than 0.05 mm outside the datasheet's body height;
• a page, or the BOM, naming a different maker.

Your four cases are each a unit test: the thermal pad, the 0.35 mm 0402 against 0.5, the shunt's generic IPC pads, and the TVS page's maker. It also ran end to end against a real component page, fetching its footprint and STEP. parts now says a page matched by MPN isn't a checked one yet. finish lists part-check findings as open items and notes any parts never checked. The aiflow-sourcing skill has the steps, including what to do with a wrong page (an issue on it, plus a "prefer": true project-library entry meanwhile).

Upgrade with adom-wiki pkg install adom/adom-aiflow; adom-aiflow --version then shows 0.2.70.