Use this index to find the current owner for project behavior. Root-level guides cover rules that
cross feature boundaries; feature behavior and acceptance procedures are grouped by the owning
src/modules/<feature>/ module.
- Start with Contributing to choose a task and understand the PR workflow.
- Use the development quick start to install and run the desktop app.
- Find the owner in the module index, then read the relevant architecture boundaries before changing cross-process behavior.
- Select contributor checks for the affected behavior.
Documentation-only contributions do not require a running app or provider credentials.
- Architecture: runtime topology, module ownership, dependency direction and process boundaries.
- Development: contributor setup, repository commands and local Git checks.
- Testing strategy: change-to-evidence mapping and test entry points.
- Test reliability: isolation, completion signals and intermittent failure investigation for asynchronous acceptance.
- Security and data boundaries: sensitive data, trust boundaries, persistence and required evidence for high-risk changes.
- Failure ownership and recovery: partial effects, recovery authority and truthful user-facing outcomes.
- Upgrade instructions: when and how to document incompatible changes.
See the module documentation index for guides grouped by source ownership.
The root guides contain shared rules and entry points. Detailed procedures and contracts have their own owners:
- Development: build and package, Git checks, diagnostics, Nix and release tooling.
- Security: diagnostic privacy, private runtime transport and the feature contracts linked from Security.
- Testing: native runtime, diagnostics, delivery and the feature coverage linked from Testing.
Add shared policy to a root guide, feature behavior to its module guide, and execution steps to the owning procedure. Dated execution results remain in their evidence records; keep active acceptance requirements and unresolved limits in the current reference.
Ownership cutover audit is a dated architecture snapshot, not a current readiness report. Use Architecture for current ownership and Testing strategy for current verification requirements.