This directory is the project's source of truth for requirements, architecture, hardware, user experience, testing and release decisions.
01_Project/— vision, scope, product requirements, delivery plan and risks02_Architecture/— system context, components, data flow and deployment03_Hardware/— target computer, inspection, measurements and peripherals04_Software/— operating system, application stack and service design05_UI_UX/— screens, navigation and appliance behaviour06_Channel_Engine/— scheduling, timelines, adverts and programme selection07_Media_Library/— media organisation, naming and metadata08_Remote_Control/— input hardware and button mappings09_Enclosure/— CAD, thermal requirements and assembly10_Testing/— test strategy and acceptance criteria11_Release/— installation, upgrades, backup and release processADR/— Architecture Decision Records
01_Project/PRODUCT_REQUIREMENTS.md— agreed product behaviour and version-one scope01_Project/DETAILED_DELIVERY_PLAN.md— phased tasks, tests, outputs and exit criteria01_Project/Phases/Phase_02/TRACEABILITY.md— final Phase 2 requirement-to-evidence audit and Phase 3 handoff01_Project/Phases/Phase_03/REQUIREMENTS.md— Phase 3 catalogue and administration acceptance requirements01_Project/Phases/Phase_03/ARCHITECTURE.md— proposed catalogue, source, scanner, API, WebUI and security architecture01_Project/Phases/Phase_03/IMPLEMENTATION.md— reviewable Phase 3 implementation sequence and traceability01_Project/Phases/Phase_03/TESTING.md— planned automated and reference-platform validation matrix../ROADMAP.md— concise delivery sequence
- Requirements describe behaviour rather than implementation wherever possible.
- Major technical decisions require an ADR.
- Unknowns are marked
TBD; assumptions must not be presented as confirmed facts. - Code changes should trace back to a requirement, issue or ADR.
- Documentation should be updated in the same pull request as the behaviour it describes.
- A phase is complete only when its acceptance criteria and documentation are complete.