Run a scheduled hardware test bench and triage results

Why use this

1. A hardware team may finish code changes but still need bench availability, the correct image and interpretable test results before proceeding. A failed run can reflect fixture state or flashing problems rather than a defect in the software under review.

2. This job could coordinate a proposed bench run and structure its expected evidence for engineering triage. Keeping readiness, execution and result interpretation separate helps engineers avoid treating a scheduled job as proof that hardware validation occurred.

Why an agent / simpler alternative

Useful judgment

Match code/test artifacts to the bench, identify readiness dependencies and classify result gaps without diagnosing hardware from incomplete evidence.

Simpler alternative

Use the existing bench scheduler directly when run configuration and result interpretation are routine.

Unsuitable when

The task would flash or energize equipment without qualified authorization and safe fixture control.

Proposed inputs

1. Name

   Bench-run brief

   Owner

   Authorized engineer

   Minimum scope

   Target hardware, firmware/test identifiers and intended scope

   Quality check

   Check compatible versions and protected equipment

2. Name

   Bench readiness manifest

   Owner

   Lab owner

   Minimum scope

   Availability, fixture state and approved safety prerequisites

   Quality check

   Confirm exclusive access and recovery procedure

Access and setup — proposed or unknown

Proposed minimum

1. Review fictional job manifests and result summaries; no GitLab trigger, flashing, hardware access or live tests.

Compatibility unknowns

1. Current bench interfaces, fixture compatibility, scheduling behavior and runtime support are unknown.

External actions requiring approval

1. Starting benches, flashing devices, changing fixtures, consuming resources and sending reports requires explicit engineering authorization.

Expected deliverable and review checks

Proposed artifact

Run-plan candidate with readiness checks, artifact mapping and triage categories for future results.

Critical checks

1. Tie results to exact firmware/bench IDs; distinguish setup failure from test failure; preserve incomplete runs and safety holds.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Results belong to a previous firmware image

   Why it matters

   The report assesses the wrong change

   Proposed response

   Verify artifact identifiers before interpretation.

2. Signal

   A fixture failure resembles a product defect

   Why it matters

   Engineering effort follows the wrong cause

   Proposed response

   Separate setup diagnostics from observed test outcomes.

Effort and cost — unknown

Setup work

1. Define run ownership, safe state and evidence identifiers.

Ongoing review

1. Engineers review authorized results and decide on any rerun or repair.

Unknowns

1. Bench availability, hardware risk, test coverage and operating costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent a run manifest with a firmware mismatch and a fixture-not-ready result; draft a triage checklist only.

Acceptance checks

1. Hold the run; separate setup/result states; claim no hardware validation; trigger nothing.

Stop conditions

1. Stop if fixture safety, exclusive access or bench-start approval is unresolved.

Limits

1. A scheduled-run plan cannot establish hardware safety, test completion or product correctness.