✨🧑‍💻 - Implement Home Assistant identity and SQLite platform persistence #6

Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

New Feature

What actions does this improvement affect?

Pull Request
Commit

Description of the idea or improvement

SDD publication selection (maintainer-approved recovery after the 18,000-character appendix limit): use action companion, existing capability ID platform-foundation, and NEW unregistered path specs/platform-foundation-identity-sqlite.md. This path is absent at the immutable base 0012a172492515e282be09c37921f4014a451e64. Preserve specs/platform-foundation.md and specs/household-identity.md as the existing owners; reference their invariants from the companion. Do not generate an update appendix in either existing document or invent another capability owner. The full companion may use the normal complete-document limit while retaining every resolved requirement and distinct acceptance scenario. This selection changes the publication container only, not the product scope or quality gates. All owner-confirmed answers remain applicable, including the exact configurable role defaults confirmed in issue comment 6537210338, the per-target HA identity paths, console-approved recovery and bounded read-only HA-outage behavior.

Implement the next M1 platform increment after PR #5, merged into develop at 0012a17: verified Home Assistant human identity and durable SQLite persistence, with meaningful tests from the first source file and enforced Clean Architecture.

Owning contracts are specs/household-identity.md and specs/platform-foundation.md, supported by specs/delivery-quality.md. Reuse their capability ownership; any generated implementation SDD must keep the installed twenty-section format and must not create a competing owner for the same domain state.

Required behavior:

1. Authenticate human users through Home Assistant's supported authorization/token flow and server-side Core identity proof. Use a fixed trusted HA endpoint, OAuth state/PKCE and bounded sessions; never infer a caller's identity or administrator status from submitted IDs, person entities, untrusted forwarding/Ingress headers or an installation transport credential. Recheck current HA identity/administrator source and current Domus authorization before protected actions.
2. Implement explicit household setup, verified membership linkage, the three owner-confirmed administrator mappings (all_ha_administrators by default; setup_administrator; selected_ha_user), predefined profiles, household permission adjustments and member exceptions with deterministic precedence. Keep ordinary self-enrollment pending until authorized activation. Enforce scope, stale revisions, suspension/revocation and last-administrator safety.
3. Provide authenticated recovery for the selected-user/setup-only modes using the newly confirmed policy: a current proven HA administrator plus explicit approval from the installation console. The local approval is bound to a short-lived request and target identity; fresh HA proof is required to complete it. No arbitrary-browser fallback, shared password/PIN or silent widening to all HA administrators.
4. Persist household, members, authorization policy/revisions, command receipts, audit and outbox through a SQLite infrastructure adapter. Domain/application modules depend only on semantic ports and pure policies, not FastAPI, HA, HTTP or SQL.
5. Atomically commit domain state, receipt, audit and outbox. Same key/payload returns its original result; changed-payload replay conflicts; current permissions still govern result lookup. Preserve replay evidence across restart, cleanup and consistent backup/restore.
6. Add versioned atomic migrations, reject future or unrelated database schemas before writes, serialize competing writers with bounded busy/conflict results, and verify real database-file restart/concurrency/rollback/backup behavior. Channel/instance metadata must prevent accidentally opening another installation's database for mutation.
7. Expose a small versioned FastAPI identity/household/member/policy surface, with strict validation, safe error envelopes and no credential persistence or diagnostic leakage. The common server contract must remain compatible with Supervisor/Ingress and standalone wiring; actual deployment/package acceptance is tracked separately from protocol/adapter fixtures.
8. Add a separate backend coverage scope and real application import graph to CI Check. Preserve the existing tooling/Node/documentation suites, every-PR triggering and fail-closed aggregate. Enforce 100% supported first-party backend metrics with behavior tests, not broad exclusions.

Current limitations or challenges

PR #5 implemented reproducible developer tooling and 85 passing tooling/architecture tests. It did not implement the household runtime, HA identity, SQLite storage, HTTP domain API or their coverage. Existing product SDDs are still Draft with authentication, concurrency and recovery proof explicitly outstanding.

This increment supplies concrete evidence for those boundaries. Other household domains, product UI, HA entity/service companion integration, full packaging/channel acceptance and release publication remain sequenced work; no absent capability may be declared implemented to satisfy catalog validation.

Expected impact

A real HA user can authenticate to the initial server, receive only the intended household permissions, explicitly initialize or join the household and retain authorized identity/policy state through a process restart. Unverified headers, stale grants, suspended users, competing mutations and replay cannot bypass authorization or duplicate committed effects.

Acceptance:

• HA authorization and identity adapter contracts cover invalid/revoked credentials, malformed/oversized responses, correlation, timeout/unavailability and cleanup, without secrets in errors/logs.
• All three administrator mappings and member/profile exceptions have allowed/denied/revocation fixtures; no first-arriving-user privilege exists.
• Console-approved recovery requires both authorities, expires and is single-use/replay-safe.
• Real SQLite fixtures prove atomic rollback, schema/migration guards, restart durability, competing revisions, scoped idempotency and consistent backup/reopen.
• Domain/application import and cycle checks run against actual product modules.
• Backend coverage is enforced separately at 100%; the full CI Check runs on every PR head, including a documentation-only update.
• A controlled local HA/Google Chrome proof may use the owner's prior authorization, with owned test data and cleanup. If a target-specific/live step is not proven, record that limitation explicitly rather than claiming acceptance.
• Copilot and the existing gateway remain unchanged.

Alternatives considered

Keep authentication, HTTP and persistence as replaceable adapters around pure identity/authorization policies and application use cases. SQLite uses explicit transaction boundaries and parameterized operations; backend transport schemas do not become domain entities. Product-facing UI and integration packaging follow their own contracts after this common identity/persistence layer.

Version of copilot

Installed vypdev/copilot@v3; do not modify its implementation or installed configuration/resources.

Additional context or comments

The owner explicitly authorized merging PR #5 and implementing this identity/SQLite block. The owner also confirmed recovery must require a current HA administrator and installation-console confirmation.

All issues, documentation, source identifiers, comments and tests are English; conversation with the owner is Spanish. Individual HA accounts, one household per installation, Clean Architecture, maximum coverage from first code, both first-release deployment targets, isolated Stable/Edge channels and the existing integrated gateway remain fixed requirements.

• Previous increment: chore: bootstrap tested development tooling and CI Check #5
• Identity contract: https://github.com/vypdev/domus/blob/0012a172492515e282be09c37921f4014a451e64/specs/household-identity.md
• Persistence contract: https://github.com/vypdev/domus/blob/0012a172492515e282be09c37921f4014a451e64/specs/platform-foundation.md
• HA WebSocket protocol: https://developers.home-assistant.io/docs/api/websocket/
• HA authorization protocol: https://developers.home-assistant.io/docs/auth_api/
• Existing upstream reports: 🐛🧑‍💻 - Expose completed progress assessment validation failures instead of opaque agent.failed copilot#774 and 🐛🧑‍💻 - SDK proposed capability catalogs have no truthful greenfield SDD bootstrap route without implementation evidence copilot#777

Use the installed feature lifecycle and Action-managed branch. Answer any pre-branch technical questions with existing confirmed decisions or verified primary-source evidence. Preserve truthful proposed-capability evidence; report genuine Copilot problems upstream rather than changing its source, schema, statuses, workflows or checks. Merge/release/deployment of the resulting implementation PR is not authorized by starting this feature.