Week 01 - May 18-24, 2026¶

Focus: Proposal validation, getting TZT hardware, setting up methodology

What I did¶

Received my TZT device
Went through the proposal and compared every claim to the actual code
Found discrepancies: two issues I planned to address were already closed, and the hardware plan was wrong (Amigo unavailable, TZT is my actual device)
There are 10 input event types, not 9 like I wrote in the proposal
There are 19 RGB constants + 2 aliases, not 23 like my research said
Tracked three more relevant GitHub items: #806 and #805 as maintainer PRs, plus #760 as an issue.
Ran all dev commands (simulator, test, lint, format) to make sure the toolchain works

My proposal had 5 factual errors. They only became visible by cross-referencing against the live code. Good thing I checked early.
Issue #862 (Stackbit 1248 vertical input) is an open PR touching layout consistency. Might intersect with my audit work.
Amigo has a unique info_background override at themes.py:132-134. No other device gets this. Exactly the kind of device-specific quirk the audit needs to catch.
The flash_success/flash_error pattern at pages/__init__.py:141 works well. Good reference for a potential flash_info() addition.

What's the actual methodology? I need to define what counts as a "finding" versus background noise.
WCAG AA or AAA as the target? AA is realistic for embedded hardware. AAA might be aspirational but impossible to hit given the constraints.