Project requirements
The Wiki now includes a bounded, project-wide HDRFP snapshot. Jira issues are authoritative evidence for reported problems, requested features/tasks and workflow state, but not every issue is an approved long-lived requirement. Implementation-derived candidates remain distinct from Jira-backed direction.
Stable project responsibility candidates
| ID | Requirement candidate | Evidence class | Owners | Validation |
|---|---|---|---|---|
| FPS-REQ-001 | Fingerprint lifecycle: Support device initialization, capture, enrollment, identification/verification, template management and cancellation. | Implementation + recurring Jira problem evidence | WBF + niseCore | WBF/niseCore tests plus customer scenarios |
| FPS-REQ-002 | Windows integration: Expose WBF/WBDI behavior and manage power, wake, Modern Standby and power-button transitions. | Implementation + Jira bug evidence | WBF wrapper + niseCore | Virtual/unit plus device/OS power tests |
| FPS-REQ-003 | Customer composition: Build only compatible customer_project and source-ref combinations defined by customers.json. | Delivery configuration + Jira automation tasks | driver-build + niseCore + WBF + include | Matrix checks and exact customer builds |
| FPS-REQ-004 | Firmware compatibility: Maintain the host side of command IDs/payloads/status semantics, update orchestration, IOTA and version/product compatibility while firmware implementation remains external. | Driver implementation + user-approved scope + Jira boundary issues | WBF + niseCore + include; firmware team external | Host tests plus joint device/firmware integration |
| FPS-REQ-005 | Targeted delivery: Support configured X64 and ARM64 targets through explicit EWDK/build inputs. | Delivery configuration | driver-build + WBF + niseCore | Customer build evidence |
| FPS-REQ-006 | Secure delivery: Validate and sign release packages without exposing credentials. | Workflow-enforced | driver-build | Signed artifact and workflow result |
| FPS-REQ-007 | Source-grounded testing: Resolve target branch variants, extract current production functions and report build/run outcomes. | Implementation + Jira test tasks | utest | utest workflow artifacts |
| FPS-REQ-008 | Traceability: Retain exact source refs/SHAs and connect Jira intent/problem → commit/PR solution → Action validation without collapsing the evidence classes. | Wiki/delivery policy | all | Checkpoint, links and evidence ledger |
| FPS-REQ-009 | Adapter migration: Establish observable-behavior parity evidence before replacing C++ WBF adapter/policy-service behavior with Rust components. | Jira features HDRFP-12243/12256 + implementation | WBF + utest + driver-build | C++/Rust integration and replay evidence; customer build/runtime tests |
| FPS-REQ-010 | Engineering feedback: Apply rule-based IOTA, code-format/static checks, daily-build failure notification and quality automation as independently observable controls. | Jira tasks/features HDRFP-12216/12258/12267/12268/12269 | driver-build + source repos + utest | Action run/job evidence with failures/skips explicit |
Jira-backed current direction
| Jira | Type/state | Intended problem or work | Current evidence assessment |
|---|---|---|---|
| HDRFP-12268 | New PNP Request / In Progress | Refine daily build parameters, failure notifications and reusable actions. | Commits in three repos, three merged PRs and successful builds; still not accepted/closed. |
| HDRFP-12258 | DevOps / Open | Expand IOTA rule checking to current projects. | Merged changes and mixed build history; current Open state means coverage is not assumed complete. |
| HDRFP-12243 | New Feature / In Progress | Finalize Rust project 864 integration. | Rust branch/build evidence exists; direct per-commit Jira linkage is incomplete. |
| HDRFP-12256 | New Feature / In Progress | Captured-behavior replay for C++/Rust parity. | ETW/replay code and Actions are semantically aligned; no Jira-linked PR/build at observation. |
| HDRFP-12269 | New PNP Request / Open | Define automatic quality verification scope and adoption. | Planning only; no implementation is claimed. |
See current project direction and Jira/Git/Actions traceability.
Requirement completeness gap
The one-month Jira snapshot explains current problems and work direction, but does not replace complete historical product requirements or customer acceptance criteria. Older epics, customer specifications and firmware-team contracts still need explicit authoritative sources where they control behavior.