fix(ci): pin Tab5 to qualified ESP-IDF image

[vincentkoc]

Problem

The moving espressif/idf:release-v5.5 image no longer supplies the SDK base
required by the reviewed Tab5 compatibility patches. The
main build after PR42
pulled image digest
sha256:5976da28fd46671f66d8f96908e166f99bc34d1fc24f516ead9a8fbef9bdc109
and correctly refused before compilation:
SDK compatibility patch refused: SDK is not at the approved compatibility-patch base.

Change

• Pin only the Tab5 matrix row to
  release-v5.5@sha256:b05ef8f0e05ba8128668fce03a5798ea175ca94829d6bc4cf15f744895fd8482,
  the image used by the retained successful build with SDK
  362a1776ec212788fda95f75b733bfdde3a0c394.
• Use the same selected version in the action input and the complete
  espressif/idf: image reference passed to firmware packaging.
• Keep the other four lanes on release-v5.5. The action, SDK guards, vendor
  patches, application configuration, and manual-only release workflow are
  unchanged.

This restores the previously qualified build input; it is not an SDK upgrade
or a guard bypass.

Validation

• Actionlint and git diff --check passed.
• Parsed-YAML validation confirmed exactly five lanes, only one image override,
  identical action/provenance selections, and no other workflow-field changes.
• The registry returned HTTP200 for the pinned image index. Its bytes and
  Docker-Content-Digest matched the requested digest, with a Linux amd64
  descriptor present. This was a metadata-only check, not a new image pull.
• Fresh focused autoreview through P2 found no actionable issues.
• Independent source and implementation reviews cleared the same frozen diff.
• All five native CI jobs passed in
  run 34700508207
  for head 0144f89c09dc48e33332edb709be5b99a5ec38e4 and test merge
  bd4b4f8722700989de7f6873993477b7f3f296f8. CodeQL also passed.
  The component test-app job includes compilation; this does not claim its
  target-only Unity tests ran on hardware.
• No local SDK build, Docker-layer download, hardware test, provider call, or
  release was performed for this repair.

The existing SDK plus tracked compatibility/diagnostic patches remain
explicitly identified in firmware provenance. Broader hardware, encrypted
media, camera color, and successful end-to-end voice qualification are not
claimed by this CI repair.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 12, 2026, 10:53 AM ET / 14:53 UTC.

ClawSweeper review

What this changes

Pins the Tab5 firmware CI build to a qualified ESP-IDF container digest and records the same image selection in firmware provenance.

Merge readiness

✅ Ready for maintainer review

The pin remains necessary: current main still uses the moving image despite requiring an exact SDK base. The focused change preserves those guards, and no actionable patch defect was found.

Priority: P2
Reviewed head: 0144f89c09dc48e33332edb709be5b99a5ec38e4

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, maintainable CI repair with consistent image provenance and no identified correctness or security defect.
Proof confidence	🌊 off-meta tidepool	Not applicable: The MEMBER-authored CI repair is exempt from contributor runtime proof. Its changed image-selection path has registry metadata checks reported in the body; the actual Tab5 build remains pending, and no new firmware or hardware success is claimed.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The MEMBER-authored CI repair is exempt from contributor runtime proof. Its changed image-selection path has registry metadata checks reported in the body; the actual Tab5 build remains pending, and no new firmware or hardware success is claimed.
Evidence reviewed	7 items	Verified introduced change: The pinned base-to-head diff changes only the Tab5 image override and the two consumers of the selected image; the remaining four matrix rows retain their existing selector. git diff --check passed. Current main still needs the repair: Main selects release-v5.5 for all five lanes while running the exact-base Tab5 SDK guard before compilation. The releases API returned no releases, and this repair is not present in the inspected main revision. SDK identity and packaging safeguards: The helper requires SDK commit 362a1776ec212788fda95f75b733bfdde3a0c394, checks whole-file and patch hashes, and rejects unrelated modifications. Packaging independently verifies the selected patches and records both the actual SDK commit and requested image. Existing tests cover wrong-base refusal and tampering; these safeguards are unchanged.
Findings	None	None.
Security	None	None.

How this fits together

CI builds firmware for five board and test targets using Espressif SDK containers. Tab5 applies narrowly verified SDK patches before compilation, then packages firmware with SDK and image provenance.

flowchart TD
  A[CI build matrix] --> B{Tab5 target?}
  B -->|Yes| C[Pinned SDK image]
  B -->|No| D[Moving SDK image]
  C --> E[Exact SDK and patch checks]
  E --> F[Firmware build]
  D --> F
  F --> G[Firmware and provenance artifacts]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Image selection scope	1 of 5 build lanes pinned	The repair targets the lane with an exact SDK compatibility requirement while preserving other build inputs.

Technical review

Best possible solution:

Keep Tab5's build input immutable and its exact SDK checks intact, with the selected image consistently recorded in packaged firmware.

Do we have a high-confidence way to reproduce the issue?

Yes, the source establishes that a moving image containing a different SDK commit is rejected before Tab5 compilation; GitHub confirms the cited Tab5 build failed. No build was executed during this review.

Is this the best way to solve the issue?

Yes, pinning only the image-dependent lane is a narrow repair that preserves intentional compatibility checks and keeps packaging provenance consistent.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against c459d59a1221.

Labels

Label changes:

• add P2: This restores a single board's firmware CI build after SDK image drift, with a bounded change.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The MEMBER-authored CI repair is exempt from contributor runtime proof. Its changed image-selection path has registry metadata checks reported in the body; the actual Tab5 build remains pending, and no new firmware or hardware success is claimed.

Label justifications:

• P2: This restores a single board's firmware CI build after SDK image drift, with a bounded change.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The MEMBER-authored CI repair is exempt from contributor runtime proof. Its changed image-selection path has registry metadata checks reported in the body; the actual Tab5 build remains pending, and no new firmware or hardware success is claimed.

Evidence

What I checked:

• Verified introduced change: The pinned base-to-head diff changes only the Tab5 image override and the two consumers of the selected image; the remaining four matrix rows retain their existing selector. git diff --check passed. (.github/workflows/ci.yml:35, 0144f89c09dc)
• Current main still needs the repair: Main selects release-v5.5 for all five lanes while running the exact-base Tab5 SDK guard before compilation. The releases API returned no releases, and this repair is not present in the inspected main revision. (.github/workflows/ci.yml:78, c459d59a1221)
• SDK identity and packaging safeguards: The helper requires SDK commit 362a1776ec212788fda95f75b733bfdde3a0c394, checks whole-file and patch hashes, and rejects unrelated modifications. Packaging independently verifies the selected patches and records both the actual SDK commit and requested image. Existing tests cover wrong-base refusal and tampering; these safeguards are unchanged. (scripts/idf_tab5_compat.py:55, 0144f89c09dc)
• Dependency contract supports the image selector: The affirmative dependency signal is the workflow's direct use of espressif/esp-idf-ci-action@v1. Its action.yml concatenates the default espressif/idf repository, a colon, and esp_idf_version directly in docker run, preserving the supplied tag@sha256 selector. The v1 reference resolved to the recorded dependency SHA. (action.yml:45, 9d38657f3d78)
• Prior merged compatibility contract: fix: recognize P4 SPM stacks in flash guard #42 is merged and explicitly documents intentional refusal when the moving image stops matching the approved SDK base, with image pinning reserved for separate work. Its recorded successful build used the required SDK commit; this PR addresses that separate input-selection problem. (37dedfbae80e)
• Build observations and inspection limits: GitHub confirms the cited main run failed only its Tab5 lane and the retained earlier Tab5 build succeeded. The pinned head's Tab5 check remains in progress. The PR body reports registry digest verification but no new SDK build. Downloading detailed job logs was blocked by the artifact host allowlist, so the digest-to-SDK association was not independently revalidated from those logs. Local source inspection succeeded; historical blame/show encountered unavailable objects, and GitHub commit metadata supplemented the history review. Broader PR search was unavailable.

Likely related people:

• vincentkoc: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.