Avoid a green light that hides a partial test failure

Status Light can summarise automated checks through a software integration, but one passing result may cover only part of the required work. A green signal should not hide another failed or missing check. Define the required test set and calculate its overall state deliberately, rather than letting the last reported result decide what the desk sees.

Which checks are actually required?

List the checks relevant to the selected revision and the decision the signal supports. Distinguish required checks from optional diagnostics or experiments. Use the source's configuration as evidence instead of assuming every reported job has the same role.

Track the revision and attempt for each result. Results from an earlier change should not fill missing slots in the current set merely because the check names match. If the required set changes, make sure the aggregation policy changes with it rather than silently retaining an obsolete expectation.

How should missing and skipped results count?

Treat absent evidence explicitly. A check that has not reported is not automatically passing, and a skipped result can have different meanings depending on the workflow. Inspect the documented source behaviour and decide whether the condition satisfies the specific requirement.

Keep allowed-to-fail checks distinguishable from required passing checks. A source may legitimately mark an overall run successful despite an optional failure. Your desk legend should explain whether it follows that source summary or applies a narrower set of requirements for attention.

What should happen while results are incomplete?

Represent outstanding work without claiming that the whole set is healthy. Store individual outcomes and freshness, then compute the display from the complete selected set. If one required check fails while others continue, decide whether failure takes priority in the attention signal.

Provide a companion view or source link naming the unresolved checks. A colour that sends you hunting through unrelated runs is less useful than one tied to a clear detail list. Keep the displayed scope limited to what your integration actually observes.

How should the aggregation be tested?

Use controlled results for all-pass, one-required-failure, missing-result, skipped-check and optional-failure cases. Include a late success from an older revision to confirm that it cannot repair the current set accidentally. Compare the internal summary before sending any device command.

The Status Light hardware details describe the physical indicator. Confidence in a green test signal comes from correct membership, identity and result-handling rules in the integration, not from the colour itself or a single successful event.