review(2-6): story 2-6 passes all ACs — mark done, add deferred items

Code review of stateful Renderer and DisplayInterface: all 10 review
criteria pass with no code changes required. Add two deferred items for
WaveshareDisplay NotImplementedError stub (wired in 2-7) and pixel-space
trail staleness on re-provisioning. Mark story done in story file and
sprint-status.yaml.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Matt Edholm
2026-04-22 23:35:13 -04:00
parent 25076dc1f3
commit 709053debf
3 changed files with 17 additions and 3 deletions
@@ -148,3 +148,17 @@ Description: `_draw_label` uses `ImageFont.load_default()` which renders at appr
Story: `2-5-per-aircraft-drawing`
Category: Technical debt
Description: Arrow tip distance (12px), base half-width (6px), and base offset (8px) are hardcoded inline in `_draw_arrow`. These control icon size and aspect ratio. For Pi Zero 2W or larger displays these values may need tuning. Future hardening: extract to named constants in `constants.py` (e.g. `ARROW_TIP`, `ARROW_BASE_HALF`, `ARROW_BASE_OFFSET`) so they can be adjusted without touching drawing logic.
---
## Story 2.6: Stateful Renderer & Display Interface
### [2-6] WaveshareDisplay.show() raises NotImplementedError
Story: `2-6-stateful-renderer-and-display-interface`
Category: Infrastructure/environment
Description: `WaveshareDisplay.show()` is a stub that raises `NotImplementedError`. The real SPI driver implementation (using the Waveshare Python library) is deferred to story 2-7. The stub satisfies the `DisplayInterface` protocol structurally but cannot be used in production or tests until story 2-7 wires in the hardware driver.
### [2-6] Trail positions are in pixel space — stale after map re-provisioning
Story: `2-6-stateful-renderer-and-display-interface`
Category: Technical debt
Description: Trail entries are `(x, y)` pixel coordinates computed against the `MapBounds` in use at render time. If map bounds change (e.g. after re-provisioning at a different home location or radius), any trails accumulated before the change will plot at incorrect pixel positions on the new map. At runtime this is unlikely — bounds are fixed at startup — but a future enhancement that supports live re-provisioning without restart would need to flush `Renderer._trails` whenever bounds change.