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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user