App test program tab plan

Yes: add a Test & program tab to the Cricket assembly.
Use it to see the approved setup, results, quality and unfinished work.
Start in the app; open the Mac tester station to program and test boards.
Show batch progress on builds and each board’s evidence in its unit history.
Keep InvenTree’s test records and the existing tester evidence pipeline.
Start with a read-only tab; onboard Cricket before enabling production actions.

Status: proposal — research only; no implementation or production changes.

Recommendation: make this the assembly’s testing home, beside Builds and Documents. Reuse the app’s object tabs, native InvenTree tests and Universal Tester. Build only the missing product-to-station connections. A new top-level Test stations page is unnecessary initially.

Numbered owner decisions — recommendations awaiting a decision

Approve the read-only tab first, including honest “not configured” states for Cricket. Suggested scope: phases 0–1 below.
Keep flashing, measurements and operator test decisions on the Mac station. Add an app handoff after Cricket’s station workflow works; defer a station directory.
Keep the approved ownership split: InvenTree owns required tests and recorded unit summaries; the tester service retains detailed attempts and delivery state. Do not create another editable results database.
Confirm the actual Cricket board revision, assembly/build identity, quantity and fitted parts. Recommend a staged electrical test → final assembly/production programming → smoke-test workflow, with Engineering defining the exact stages and limits.
Confirm the shipping firmware’s exact artifact and behavior, separate test image, fixture and responsible release approver. Recommend the existing Engineering/Manufacturing/Quality role approvals; one owner may exercise multiple recorded roles.
Keep the Manufacturing System reference bench gate before new production activation. Cricket preparation can proceed in parallel; any change to that rollout order needs an explicit owner decision.

What the app should show

Proposed route: #part/<part-pk>/test. Show the tab on testable assemblies and an onboarding empty state for assemblies awaiting configuration. Use stacked cards and short result rows on phones; load this pane on demand.

Setup: assigned workflow/test program, version, commit/hash and draft/candidate/active state; hardware revision; approved release and approval evidence.
Firmware: separate production and manufacturing-test versions, artifact links and SHA-256 hashes. Keep workflow, station software and tester-controller firmware versions distinct. Unknown provenance must say “unknown,” not “latest.”
Equipment: fixture model plus accepted physical serials, revision/pin-map, verification/calibration state, compatible stations and last reported activity. “Last seen” is not proof a station is online or ready.
Required tests: InvenTree PartTestTemplate names, descriptions, required/enabled flags and evidence requirements, mapped to the released workflow’s stages/steps. Show the source and version of limits.
Quality: first-pass yield with numerator/denominator, failures by step, retest count and open quarantine count. Filter by build, revision, release and time; show data freshness and missing evidence.
Recent units: serial, build, stage, outcome, attempt time, station and ERP sync status; link to #unit/<stock-pk>/tests. Use #serial/<serial> only as a lookup fallback; it already handles ambiguous matches.
Open work: quarantine/rework cases, age, original failure, repair state and next required stage, linked to the same unit/case. A case awaiting an ERP unit remains visible under its permanent case identity.

Assembly configuration answers “how do we test this product?” Build progress answers “what remains in this batch?” Unit history answers “what happened to this board?” These are views of the same records.

Actions and their boundaries

Now: open unit/build/history, approved instructions and existing quality report; download an immutable firmware artifact with its manifest/checksum. Downloading does not approve or install it.
Later, controlled release: request/review/promote a candidate firmware or test program combination. Preview affected hardware/builds and differences; record Engineering, Manufacturing and Quality approvals, then activate the exact hashes. Never offer an unrestricted “flash latest.”
Pinning: selecting the production release is an approved change. Builds retain their release snapshot; changing a default does not rewrite existing builds or historical results. Rollback selects a previously approved compatible combination and appends an audit event.
Open on station: hand over product, build, release and optional unit/case context. The station authenticates, resolves the server’s permitted stage, checks fixture compatibility and waits for the operator before power or programming.
Fixture label: useful only from a selected, registered physical fixture. Reuse existing label preview/printing; include model, serial and record QR. Printing a label never provisions EEPROM or certifies calibration. Defer until fixture records exist.

The station owns hardware discovery, safe power sequencing, UPDI flashing/verification, instruments, operator prompts, actual tests and safe shutdown. Preserve FAIL → Retest or Quarantine, unlimited recorded retests, and accepted quarantine before receipt/bag-label printing. Repair tests follow stored history; no app button may turn a failure into a pass.

For the first handoff, offer Continue at station instructions and the existing local launcher. A web link cannot currently start that native program. A later registered macOS URL handler or small authenticated context-import mechanism is shop-specific glue, not an existing feature.

The QR should open an authenticated app context page; it carries no station credential and never starts hardware. On an iPhone, localhost means the phone, not the Mac. Do not expose the immediate-action engineering control panel or make a public URL to it.

Builds, units and station navigation

On #build/<pk>/test, show the pinned release and stage completion against the build target, plus untested, in-test, quarantine, scrap and ERP-confirmed finished units. Link every output to its unit. Distinguish final-test PASS from finished inventory and show pending sync separately; pending is an overlay, not another board to count.

Extend the existing unit Test results and Repairs & notes views with full attempt evidence, both firmware hashes, fixture/station identity, release, repair and synchronization status. Preserve historical failures after a retest passes.

Add a MAKE → Test stations directory only when multiple active stations or recurring calibration/maintenance work warrants it. It would own station/equipment status and links, never a second product configuration editor. Initially a station card in this tab is enough; generic job failures already belong in Workflows.

What exists, checked 2026-10-04

Local app checkout: ~/assistant, commit caf6f0b (v2026.10.19). This is source/configuration evidence, not a live browser or bench acceptance test.

static/app.js:1386,1412,1462,2858,2903,5250: shared tab helper, assembly tabs, build tabs, unit history, serial lookup and Documents wrapper. No Test & program assembly pane exists. Build output rows do not yet link to units.
objects.py:452–511: reads /api/stock/test/ and /api/part/test-template/, computes latest-result summaries and derives repair history from ERP tracking notes. Its bounded history reads are unsuitable as an unqualified whole-product yield calculation.
tester_api.py:715,912,968: creates required stage templates, creates/links an unfinished unit after pretest PASS or explicit quarantine, backfills failures and posts native stock test results. Result value currently carries the run ID; notes carry the event ID, tester version and raw-log path. Individual step measurements/hashes are not normalized into separate ERP results here.
tester_api.py:220–276,1233–1328: SQLite indexes serials, events, cases/dispositions and ERP operations; raw events also go to the test-data store. Serialized retries mirror pending work, normally every 120 seconds. API acceptance and ERP completion are separate acknowledgements.
systemd/tester-api.service: Plex service loads tester_api:app, loopback port 8210. Operating notes record tester.embeddedera.com with station authentication. Reading runtime service status was sandbox-blocked; running release/health was not independently confirmed.
Inspected default ~/.config/tester-api/products.yml maps Cow Robot and Cow Remote only, with no active release blocks or Cricket mapping. Runtime overrides were not inspected. The candidate config is explicitly nonproduction.
tester_api.py:415,690: accepts only pre_coating/post_coating and resolves exactly one open Production build. Cricket needs deliberate stage mapping/generalization and explicit build binding; a launch-link build ID alone does not fix this.
erp-config/reporting/tools/sync_tester_reports.py: existing disposable reporting mirror of events/serials, used by the documented Grafana Quality dashboard. Reuse its reporting path before inventing analytics storage.

The Mac station is outside Plex control; there is no SSH route. Memory’s “PR #11 unmerged” is superseded by the later Universal_Tester log: launcher merged September 26. That does not mean the Phase 4 shared workflow is active. The same log identifies manufacturing-test firmware command incompatibilities; manufacturing-operating-system-plan still requires physical acceptance.

Plex’s Cricket checkout ends September 16, while cricket-product records firmware/tool work through October 4. Treat the newer note as reported development state, not proof of the Mac’s installed binary. No exact Cricket firmware versions/hashes or complete current ERP test-template inventory were verified here.

Native InvenTree support and ownership

InvenTree already provides PartTestTemplate: testable parts, names/keys, descriptions, required/value/attachment requirements, enabled state and variant inheritance. Retire templates by disabling them; deleting a template also deletes linked results. Native template documentation.

StockItemTestResult links a stock item and template, with pass/fail, value, notes and optional attachment; API uploads support automation. Multiple results are retained, and the latest determines that test’s current status. This is not first-pass yield or a complete manufacturing release decision. Native result documentation.

Use these native records. They do not replace executable sequencing, hardware interlocks, release approvals or detailed measurement storage. Validate the deployed InvenTree version and completion/shipment settings in phase 0 rather than assuming current online documentation matches the installation.

Fact	Authoritative home
Required ERP test definitions and recorded unit summaries	InvenTree templates/results
Stock, builds, serial-to-stock identity and confirmed disposition	InvenTree
Executable workflow, numerical limits, compatibility intent	Versioned product/fixture release
Firmware bytes, manifests and hashes	Immutable product release artifacts
Approved production combination and activation	ERP-linked release registry; proposed by the existing contract
Detailed attempts, measurements, raw evidence and delivery journal	Tester service/store
App cards, counters and reporting tables	Read-only derived views

This preserves the already approved Manufacturing System boundary. The tester DB cannot simply be deleted: it currently allocates serials and owns pending case transactions as well as evidence. Its case state describes requested/in-progress operations; ERP owns their confirmed inventory effect. Surface discrepancies instead of choosing whichever looks newer.

The release registry is planned, not established by this inspection: today the API reads release configuration from YAML, and no promotion endpoint was found. Start with reviewed release manifests and explicit installed-state reporting. Later activation should produce a validated station/API configuration from one approved registry record, never a second independently edited approval.

Publish reviewed workflow-to-template mappings into InvenTree once. Do not maintain a second manually editable test checklist in the app. For changed acceptance criteria, pin a new release/template mapping and retain old evidence; do not silently rewrite requirements on old builds. Ordered steps and limits remain in the released workflow, even when corresponding template results are shown in ERP.

Recommended flow: station durable outbox → authenticated tester API/event journal → idempotent InvenTree results and stock transactions → app. A separate read-only evidence feed supplies detailed steps, provenance and pending cases. Link everything by event/attempt ID, product, unit, build and release; deduplicate retries before aggregating. Add stable evidence URLs rather than displaying only a server filesystem path.

Keep large logs in the existing evidence store, with hashes/links from ERP. Reconcile accepted events to ERP result IDs and inventory effects. Preserve the station outbox until acknowledged; distinguish “saved locally,” “accepted by server,” “ERP pending” and “ERP confirmed.” Offline results never imply saleable stock.

Yield without hiding failures

Start with stage first-pass yield: units whose first valid production attempt at that stage passed ÷ units with a valid first attempt at that stage. Show both counts. Group by physical unit, stage and relevant release/build cohort; a later PASS does not improve that first outcome.

Determine each unit’s first attempt across its full stage history before applying the report’s cohort/time filter. Deduplicate event IDs; retain attempt order/time. Track setup ABORTED, skipped steps, incomplete identity and engineering runs separately; they are neither successful production tests nor automatic board failures.

Use the complete accepted tester event journal for attempt metrics, including failures not yet mirrored to ERP. Use ERP for recorded summaries and confirmed stock disposition. Label the metric’s source and completeness; do not sum the same ERP and tester attempt twice. Unidentified attempts remain visible and prevent claiming complete unit yield until reconciled.

Failures by step require structured failed-step IDs in the evidence; today’s stage summary is insufficient. First delivery may show “step breakdown unavailable.” Count unique open quarantine cases, with ERP-pending cases visibly marked, rather than counting every failed attempt as quarantine.

Cricket onboarding using the existing contract

Reconcile EE-A-0003-A, physical hardware revision, current work order and stock outputs. Do not create another Cricket assembly or assume the original twenty boards are all 008. Identify fitted battery, motor and enclosure state.
Extend the existing Cricket repository using Project_Template conventions and the pinned Manufacturing_System contract (v0.1.0-draft.1 is the documented baseline). Add/validate board, workflow, fixture, firmware, routing and inventory manifests through review; do not create a competing template.
Review and reuse the reported cricket_firmware_008/tools/flash_test.py: identify MCU, fix approved fuses, run self-test, operator confirmation, production image and ships-asleep check. Adapt its hardware steps to shared station logging/outbox and the permanent serial service; CSV alone is not company traceability.
Define measurable acceptance: identity/fuses, programming/readback, piezo, motor, blue LED, standby/active current, USB charge indications and VBUS sense, production behavior and asleep shipping state. The note says flash_test.py does not cover charging/PA3. Published bench currents are characterization, not automatically production limits; Engineering approves limits, units and required evidence.
Freeze separate test/production images with versions, source commit, build provenance and SHA-256. The newer note supersedes the old 30-minute behavior with a 45-minute mean and one-hour arming delay; confirm intended shipping behavior. Verify production firmware after test and run its smoke check before release.
Define a Cricket fixture from the shared fixture profile/template: safe UPDI interface, pin map, power isolation, instruments, self-test and known-good/known-failure checks. Assign model and distinct physical serial; provision EEPROM in Engineering and match its durable label. Unknown/blank identity must block production.
Register Cricket/station permissions and its release mapping. Add approved stage/template mapping instead of pretending Cricket is coated. Publish PartTestTemplate acceptance records, including required production-programming/smoke evidence, and bind attempts to the selected build. Test rework routing against Cricket’s actual stages.
Define consumption by installed stage, including motor, battery, shell and packaging. Reuse the board-packing pattern where physically appropriate: Brother serial tape, Zebra bag label and ESD bag; confirm Cricket’s fit rather than copying Robot’s BOM/config blindly.
Rehearse in isolation, then run physical acceptance with actual Mac, adapter, fixture and printers. Prove failed/retried/unreadable boards, quarantine/repair, duplicate/offline replay and build reconciliation. Record approvals and update the existing SOPs during implementation before activating the release.

The recorded Cricket 008 programmer supplies 5.2 V to the battery header; the note forbids connecting it with the cell attached. Its PA3/VBUS issue also awaits engineering disposition. Safe fixture wiring and an approved handling/deviation or revised board are release gates, not problems a browser tab can solve. UT003 layout work is not a prerequisite for the app pane or a proven replacement station.

Phased estimate and acceptance

Estimates are focused engineering days for one experienced implementer with review, not elapsed promises. Hardware procurement, fixture fabrication, owner scheduling and unexpected electrical fixes are extra.

0 — Confirm data, 0.5–1 day. Read deployed schema/settings, current Cricket revision/build, station versions and release sources; agree stage/identity mappings and inspect representative attempt payloads. Exit: known sources and explicit missing fields, no inferred approvals.
1 — Read-only assembly tab, 2–4 days. Released/candidate firmware/workflow cards, recent ERP results, honest yield where complete evidence exists, open cases and links. Reuse reporting reads. Cricket may initially say “not onboarded / no results.” Exit: counted samples match source records; permissions, empty/error/stale states and phone UI pass.
2 — Cricket data integration, 4–7 days. Product manifests, workflow/template mapping, explicit build association, provenance/evidence links, stage-aware result/quarantine handling and reconciliation. Exit: isolated fail → retry → pass retains the first failure, produces one unit, consumes only installed material and never releases on upload acceptance alone.
3 — Station onboarding, 3–5 days software plus 1–2 shop days. Reuse flash-test steps, fixture identity and approved artifacts; prove safety, measurement coverage, rework and printers on real hardware. Depends on an accepted fixture and the reference rollout gate. Exit: signed bench evidence and deliberate activation.
4 — Controlled actions, 4–7 days after the pilot. Mac handoff, the minimal approved-release record/activation API and request/promotion UI, approved pin/download and selected-fixture label reuse. Keep reviewed repository releases as the interim specialist path. Exit: wrong revision, stale approval, unauthorized action and duplicate handoff fail safely; no URL energizes hardware.

Phases 0–1 are the smallest useful delivery: roughly 2.5–5 days. Complete production onboarding is a larger job. Defer phase 4 and the station directory unless the first batch demonstrates the benefit.

Implementation verification must use isolated data and sandbox ERP, preserve working Cow stations, run relevant backend checks and mandatory app-ui-check on iPhone WebKit, then follow app-release. Version firmware/tester changes under existing repository rules. No software check substitutes for the physical acceptance matrix.

Before phases 2–3, the owner also needs to identify the actual SerialUPDI adapter and available fixture/instruments, confirm whether the September 28 flash-test tool has since passed on hardware, and reserve a shop acceptance session. These answers determine hardware scope; they need not delay the read-only pane.

Reuse before building more

Keep InvenTree’s native tests, labels/reports and current printing services. Reuse Grafana’s existing quality reporting (or the established Metabase reporting layer for deeper analysis); this tab needs a few linked metrics, not a new BI system.

OpenHTF already supplies Python phases, measurement validation, hardware plugs and result records. The local universal-tester-product decision is to reuse its data shape and keep the existing station runner, rather than migrate now. Revisit an OpenHTF adapter only if a demonstrated sequencing gap justifies it; do not write another generic executive. Official OpenHTF repository.

No new paid analytics service is justified for this request. Existing station tooling, InvenTree and the current reports cover the immediate need; custom work is limited to release/context mapping, traceability and app views.

Evidence and remaining uncertainty

Read: cricket-product, manufacturing-operating-system-plan, universal-tester, Universal_Tester, universal-tester-003, universal-tester-product, robot-board-quarantine-rework-plan, embeddedera-app, company-operating-system-strategy, and the requested private tester-pickup/packing memories. Current source outweighs stale status prose; Mac installation, physical acceptance and live ERP inventory remain unverified.

Prepared by the primary Codex session; no helper models ran. Capacity readings were missing and read-only helper confinement was unavailable. Exactly this proposal was written; the one-file scope excludes sync, commits, memory updates and implementation.

10-line summary

Add Test & program to the assembly.
Start with read-only setup, results and honest yield.
Use builds for batch progress and units for history.
Open the Mac station for programming and testing.
Reuse native InvenTree templates and results.
Keep detailed attempts in the existing tester evidence store.
Preserve failures, pending synchronization and quarantine.
Onboard Cricket with approved firmware, workflow and fixture.
Require safe hardware and recorded bench acceptance.
Defer extra station pages and release automation until useful.