CI Test Atlas

The Test Atlas connects a curated test catalog to execution results and captured device screens. Use it to understand what a test is intended to prove, what ran on a particular candidate and what still needs review.

Read the candidate first

The 2026-09-24 CI run  includes a test-report artifact containing an 81-page PDF, manifest, PDF hash and merged JUnit results.

• Firmware: efdeb678bc33c616cf8048fb5773548f0da96fa7.
• Python test client: b745562be6a13cc83b2a547d7ef86637f4556dbb.
• PDF SHA-256: d1b28f69cd541bba9190dcbfbb665bbd3b66f858d5dcefa6c635e96de54d5b4c.
• Curated PDF catalog: 392 tests — 249 passed, 140 skipped, 3 pending.
• Merged input census: 1,361 test cases — 1,183 passed, 178 skipped, no failures or errors in that input set.

These populations differ. Do not add them together or use them as a permanent company-wide test count. This is a development candidate, not a signed-release acceptance receipt. GitHub artifact downloads may require authentication and may expire.

The older 7.14.1 PDF is a historical report dated May 23, 2026; it is not the latest report.

How to use it as a manual

1. Match the firmware, host and artifact identity to the build you are evaluating.
2. Find the relevant section and read the test’s purpose and expected behavior.
3. Distinguish a passed test from skipped, pending or withheld coverage.
4. Inspect the captured screens. Sampled frames illustrate a test; only explicitly complete, ordered sequences can support a claim about the entire flow.
5. Follow the named test and JUnit result for exact inputs and assertions. A refusal can legitimately have no screen capture.
6. Record any remaining hardware, rendering or release-provenance checks separately.

Limitations and known report corrections

Emulator evidence does not establish physical device resistance to fault injection, side channels or supply-chain attacks. Human review must judge whether the words on the captured screen are understandable and accurate.

This report also contains presentation and narrative issues: long OLED-needed annotations clip, some frames are samples, and historical explanatory text can disagree with current evidence. In particular, the appendix’s immutable-bootloader claim conflicts with KeepKey’s bootloader-update process. Read test statuses independently of historical prose.

The Atlas authoring guide  describes catalog entries and full-sequence requirements. python-keepkey is the test client.

Try firmware without a device

KeepKey’s public emulator walkthrough  demonstrates loading firmware into KeepKey Desktop with an Orchard test wallet. Use a compatible candidate and disposable test wallet. Never import a real recovery phrase into an emulator. The walkthrough does not establish coverage of every firmware feature.

Continue to release status or device display examples.