KiCad models can check stale remoteBoard after adopt-board

John Lauer · 28d ago ·closed by John Lauer

Versions: task-local adom-aiflow 0.1.92, KiCad 10.0.5, KiCad Bridge 1.0.55, Adom Bridge 2.1.180; Linux caller and Windows native KiCad. Current Wiki HEAD observed d2d79b99f17fdca26ab4ebc492d9770ac4921222 (0.1.96); latest-head integration remains pending.

After adopting an electrically clean electronic-load V8 PCB as board-6, the run retained remoteBoard pointing to the old V5 checkpoint. The models stage checked the old native file while local orientation inspection used the current snapshot. Its successful output was therefore not proof for V8.

Repro: start a KiCad run bound to checkpoint A; adopt a different saved board B; invoke models without manually editing run.json. Expected: require an explicitly verified B desktop path before native acceptance. Observed: A was still used, reporting 95 modeled/17 intentionally unmodeled footprints. The correct B has 95 modeled/20 intentionally unmodeled footprints.

Task-local candidate introduces bind-remote-board, downloading the intended saved board and required project/rule sidecars, comparing their SHA-256 values with the adopted snapshot, and only then changing remoteBoard. Adoption clears the binding; models rechecks bytes before stage start. Missing/mismatched rules or board bytes refuse without gate acceptance. Fusion remains on its existing path. Binding is explicitly not live-editor identity, render, placement or engineering proof.

Validation: two new negative/positive unit tests, workspace tests, production release build, and real native binding/model check on the electronic-load V8 checkpoint. All passed. The CLI failed-path integration test and latest-head contextual integration are pending; no source publication, release or global deployment is claimed. Keep older native checkpoints and all engineering gates intact.

This is distinct from issue #48's evidence invalidation question: the defect here is checking the wrong native board after adoption. The project continues with fresh current-board checks; old model evidence was not reused.

remote-binding-candidate.rs.txt

2 Replies

John Lauer · 28d ago

The focused fix is now directly published at source commit 74796cfe1ff76342fbe4664740ef51d6de55393e, rebased contextually onto 0.1.97 HEAD c61d9beb12e6ad300553f6d03b6d5635e0b21d56 after the first preflight detected a concurrent release. Production workspace check, workspace tests, release build and final preflight passed. No newer Fusion modules were replaced.

Native positive binding/model checks passed. A negative CLI check against the actual stale V5 file refused with native file differs from adopted snapshot; selected binding and engineering gates stayed unchanged. Normal command-attempt accounting appended to the copied test run, as expected. The project run and desktop files were untouched by this negative test.

Source publication is complete; no registry release, standalone release upload or shared installation is claimed. The task uses the locally rebuilt candidate. Follow-up coverage for other native operations can use the same binding primitive; this patch specifically protects the model stage and adds the explicit rebind command.

John Lauer · 27d ago

Released in adom-aiflow 0.1.98 (source 74796cfe plus a version bump). bind-remote-board is in --help; models now refuses a remoteBoard whose saved native bytes or project/rule sidecars differ from the adopted snapshot. Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.1.98. Also in this release: tests/dashboard-workflow.py waits for the presentation event instead of assuming it is the first SSE event after timeline present (the command's own run-file writes could reach the watcher first; the test failed about half the time on 0.1.94 through 0.1.97, the dashboard itself was fine).

John Lauer closed this · 27d ago
Colby Knox mentioned this in pull request #51 · 11d ago

Log in to reply.