Task Management & PRDs

Relevant source files

The following files were used as context for generating this wiki page:

• CLAUDE.md
• README.md
• docs/tasks/README.md (referenced in CLAUDE.md)
• docs/remaining-tasks.md (referenced in CLAUDE.md)
• package.json

The OpenAwair project utilizes a structured approach to development through Product Requirements Documents (PRDs) and a defined task lifecycle. This system ensures that the restoration of local-first functionality for Awair Glow C and Awair Element devices is handled systematically across both embedded firmware (C/C++) and host-side tooling (TypeScript).

Tasks are managed as individual Markdown files located within the docs/tasks/ directory, serving as the primary source of truth for features, technical requirements, and implementation status.

Sources: CLAUDE.md:144-147, README.md:1-12

Task Lifecycle and Directory Structure

The project tracks progress by moving PRD files through specific subdirectories that represent the current state of a task. This physical movement of files provides a clear visual indicator of project velocity and bottlenecks.

Status	Directory	Description
Pending	docs/tasks/	Task defined but not yet started.
Working	docs/tasks/working/	Task is actively being implemented.
In Review	docs/tasks/in-review/	Implementation complete; awaiting code review or validation.
Done	docs/tasks/done/	Task fully completed and verified.

Sources: CLAUDE.md:151-164

PRD (Product Requirements Document) Format

Every task in the OpenAwair project follows a standardized template to ensure technical consistency and clarity for developers and AI contributors alike.

Core PRD Sections

1. Overview: Detailed description of the problem, its impact, and general context.
2. Out of Scope: Explicit boundaries defining what the task will NOT address.
3. Solution: Proposed approach, user stories, and specific implementation notes.
4. Technical Requirements: System constraints, hardware dependencies, and relevant code references.
5. Acceptance Criteria: A checklist of success criteria required to mark the task as "Done."
6. Open Questions: A section for tracking unknowns that require further investigation.
7. AI Metadata: Machine-readable properties including task complexity, project phase, and current status.

Sources: CLAUDE.md:166-175

Project Roadmap by Phases

Task management is organized into five distinct phases, ranging from foundational hardware validation to final release documentation.

Phase Overview Table

Phase	Focus	Scope
Phase 1	Firmware Foundation	Hardware validation, dev environment, peripherals, sensors, storage, scheduler.
Phase 2	Networking	Wi-Fi driver, provisioning, BLE stack, MQTT, REST.
Phase 3	Device Features	Glow C specific features, Element specific features, shared features.
Phase 4	Bootloader & OTA	Bootloader implementation, DFU protocol, firmware validation, host tooling.
Phase 5	Polish & Release	Final testing and project documentation.

Sources: CLAUDE.md:177-194

Implementation Tracking

In addition to the granular PRD files, the project maintains a condensed view of progress through a legacy task checklist.

Conclusion

The Task Management system in OpenAwair provides a rigorous framework for transitioning discontinued proprietary hardware to an open-source, local-first model. By combining directory-based state tracking with detailed PRDs, the project maintains high technical standards across its dual-stack architecture of C/C++ firmware and TypeScript host tools.