Requirements and Status

Requirements and Status

PCController tracks requirements as GitHub issues and pull requests, with generated repository documentation as the reviewable local mirror.

Sources of truth

• GitHub issues
• GitHub pull requests
• Requirements backlog
• Project acceptance checklist
• PCController Delivery project board

The issue or PR records the requested outcome, discussion, and accountable work. The generated backlog records normalized acceptance criteria and status. The acceptance checklist distinguishes source-level implementation from exact-artifact and physical-hardware proof.

Status language

State	Meaning
Backlog	Requirement is captured but work has not started.
Ready	Scope and acceptance criteria are clear enough to implement.
In progress	An active branch/PR or named owner is working on it.
Blocked	A concrete dependency, failing gate, hardware requirement, or user decision prevents progress; record the reason.
Verification	Code is implemented but exact build, packaged UI, target OS, or hardware evidence is still required.
Done	Acceptance criteria and required verification are complete and the qualifying PR is merged.

Do not turn a warning-only build or source-level unit test into a claim of physical verification. Conversely, do not leave a passing, reviewable PR open merely because work was previously managed as a long-running alpha batch: qualifying PRs should be approved and merged; incomplete ones should be marked draft/WIP with the specific remaining evidence.

Prompt traceability and privacy

Applicable issues and PRs should begin with the user's original request excerpt as a Markdown blockquote, lightly corrected for grammar where needed. Passwords, tokens, device codes, private keys, and unrelated private machine details must be redacted rather than copied into public GitHub text. Link related issues and PRs instead of duplicating divergent requirements.

Every new request must first reconcile with existing issues, PRs, and docs. Update the existing record when it already owns the requirement; create a new issue only when the work has a distinct outcome and acceptance boundary.

Current verification boundary

The repository checklist is authoritative for detailed evidence. In general:

• automated checks can prove source and package properties;
• Windows/TUI/WebUI behavior needs exact packaged-artifact observation;
• bootloader, fuse, UART, key-latency, peripheral, and recovery claims need the intended physical board and connection;
• optional missing peripherals should be reported as unavailable while remaining diagnostics continue.