Repository navigation
✨🧑💻 - Deliver the household entry interface for native and standalone deployments #8
Description
Is there an existing issue for this?
- I have searched the existing issues.
Description of the idea or improvement
Create NEW specs/household-entry-interface.md under application-experience; preserve its parent. Owner confirmed both languages with English fallback. Preserve the complete source and path declarations below.
Publication clarification (documentation notation only): the complete companion below has been rendered and independently checked against the unchanged Copilot SDK at 3e7ceea08e6131360e026937d1c0cc1b120472e0, using immutable develop a63b231 and its complete owning SDD/catalog inventory. Format and consistency both pass; all eight requirements and all 48 original case rows are retained. This is pre-publication contract evidence, not runtime acceptance. Use this exact reviewed companion rather than inventing substitute file citations. The two existing entrypoints are backend/src/domus/entrypoints/http.py and backend/src/domus/entrypoints/native_http.py; a combined filename is not a repository path. Method-labelled HTTP routes, Content-Type notation and deployment/access alternatives describe protocols or values, not files. Browser requests must still remain relative to the accepted application base. Proposed source leaves are explicitly declared in section 15; preserve them and the owning contracts. No further owner product decision is pending here; Action publication and the exact verified managed branch remain prerequisites to implementation.
# Household entry interface
- Status: Draft
- Date: 2026-10-31
- Catalog capability ID: application-experience
- Last verified: not applicable; prospective
- Owners: Domus maintainer and product owner
- Scope: Explicit setup/join/landing in both deployments
- Related issues/PRs: [#8](https://github.com/vypdev/domus/issues/8); merged foundations in section 2
- Required review gates: UX, architecture, tests, docs, security/operations
- Open decisions blocking readiness: none; execution/acceptance unproven
## 1. Executive summary
Explicit native/standalone setup, join and landing. Entry/sign-in/reads never auto-write. M1 remains incomplete; all-domain, both-target, isolated Stable/Edge first-release scope stays mandatory.
## 2. Problem, current behavior, and evidence
Base a63b2315cd5121dde9585ba8875e286fdef5330e has no household UI. PR #7 supplies tested identity/storage; merged PR #10 proves locked Lit/Vite/Storybook/Chromium execution using a fictional fixture, not product coverage. PR #12 records task-policy defaults. Installed Edge.3 is separate. Before code, Action must publish/verify this NEW companion and its exact linked branch. Runtime acceptance remains unproven.
## 3. Actors, surfaces, and terminology
HA administrator sets up; verified participant requests own linkage; active member reads permitted facts; missing/grace visitor gets guidance; maintainer verifies execution/cleanup. Current authority, original receipt and absent historical effect stay distinct. Journal grants nothing; application base locates UI, never actor/HA endpoint.
## 4. Goals, non-goals, and fixed invariants
|Requirement|Behavior|
|---|---|
|ENTRY-01|Render a responsive owned Lit/TypeScript/Vite entry interface in English and Spanish with English fallback, actual loading/state/freshness and no invented domain facts.|
|ENTRY-02|Use existing native or standalone authentication and server-proven deployment/user context; keep all assets, API and navigation inside the verified same-origin base.|
|ENTRY-03|Offer explicit default-mapping household setup only when the server permits it; validate name/timezone and never initialize through sign-in, entry or refresh.|
|ENTRY-04|Support deliberate own enrollment and all membership states; pending has no active access and suspended/archived linkage cannot be replaced by self-enrollment.|
|ENTRY-05|Show only authorized actual household/own-permission facts; bounded HA outages remain visibly read-only until the original session deadline.|
|ENTRY-06|Preserve the exact bounded per-tab command journal, original key/payload and uncertain/historical outcomes; never create automatic duplicate work.|
|ENTRY-07|Keep framework-free inner layers, typed semantic ports, strict outer adapters and reproducible static delivery; enforce trust boundaries, isolation and resource cleanup.|
|ENTRY-08|Establish actual unit/component/Storybook/Playwright execution, all four authored frontend coverage metrics at 100%, architecture negatives and every-PR fail-closed CI with truthful artifacts.|
Hard invariants: server-proven identity/current policy, scoped receipt disclosure, atomic idempotency, household/channel isolation, source revocation and last-administrator protection remain unchanged. Client display cannot grant authority.
Later required work: full member/policy/recovery administration, alternate mapping selectors with verified directory, all domain UIs and the HA entity/service companion. No fake working controls/counts, Copilot/gateway changes, private HA UI dependency, mandatory cloud or new public port.
## 5. Current versus proposed product journey
```mermaid
flowchart LR
Open[Open] --> Verify[Verify]
Verify --> Journal[Explicit action and journal]
Journal --> Result[Result and refresh]
```
Text: opening only reads; deliberate action must persist its original command before send.
## 6. Functional behavior and state model
### Entry states
|Server state|Required next action|
|---|---|
|unconfigured, setup_allowed|Explicit name/timezone setup; explain all_ha_administrators; expected revision zero|
|unconfigured, denied setup|Ask an HA administrator; no write control|
|not_enrolled, enrollment_allowed|One deliberate Request membership for the exact current human|
|pending|Verified linkage but inactive access; Refresh status/contact administrator; no fresh enrollment|
|active|Current own permissions and actual permitted household facts|
|suspended or archived|Ask administrator to review/reactivate existing membership; no replacement linkage|
|missing/expired identity|Native reopen through HA; standalone deliberate sign-in|
|original unexpired read_only grace|Authorized local facts/deadline only; changes and recovery blocked|
A retained unresolved command has a distinct deliberate Check previous request after full fresh identical-context proof, including pending membership. It reuses the old command, never creates a new enrollment. Loading, denied, unavailable, stale and truly empty are distinct. Active membership without household-read permission exposes own context only.
### Existing internal API
Paths below name internal routes; browser requests resolve their relative equivalents under application_base, never the origin root through Ingress.
|Route|Contract|
|---|---|
|`GET /api/v1/session`|Existing SessionResponse: verified identity/admin, access/freshness/lifetime and next steps; native source home_assistant_ingress|
|`GET /api/v1/authorization`|Existing AccessResponse: states above, setup/enrollment flags, own member, policy_revision, effective_role, household_administration scope/permissions and next steps|
|`GET /api/v1/household`|Current permitted household_id, name, time_zone, revision|
|`GET /api/v1/auth/csrf`|Actual session CSRF; never journal it|
|`POST /api/v1/household`|Strict name, time_zone, expected_revision zero, mapping_mode all_ha_administrators; omit selected_ha_user_id|
|`POST /api/v1/members/enrollment`|Strict expected_revision zero; server derives actor|
|`GET /api/v1/operations/{operation_id}`|Original own receipt plus actual pending/delivered/suppressed delivery, under current original-command authority|
Own member contains member_id, role, status, revision and only permitted own linkage/exceptions. Omitted fields never imply a grant. Setup name <=160 characters and timezone <=128 are backend-validated. Other accepted mappings remain backend-supported but have no selector in this increment. No body selects actor/installation/household. Writes preserve actual Origin, X-CSRF-Token, original Idempotency-Key and strict JSON/revision/body/header/deadline guards; use `Content-Type: application/json`. Keys are 1..128 ASCII, initial alphanumeric, then alphanumeric/underscore/dot/colon/hyphen.
Receipt fields: committed/historical state, archived_by, operation_id, original result, UTC epoch-millisecond created_at, message/action_required. Historical effect is absent; receipts never assert current membership. Identical payload/key recovers the original receipt before stale-revision rejection; changed payload or a stale new write conflicts. Refresh actual state after results. Blocked errors contain code/message/action_required/correlation_id. Distinguish 401,403,409,422,503 from uncertain 500/timeout/transport loss. Preserve the original command; no automatic retry, rebase or new key. Never render raw errors. Console approval has no HTTP endpoint.
### Additive context and authentication
Authenticated session adds installation_id, stable/edge channel, native/standalone deployment, application_base, household_api_available and nonsecret server_time (UTC epoch milliseconds). Derive these from validated server Installation/composition and accepted native prefix or fixed standalone root, never request-selected host, command or journal. Existing ha_user_id/access remain proof/freshness. Preview without persistent APIs reports unavailable and offers no household commands. Server time plus monotonic page elapsed time anchors journal lifetime; regression fails closed.
Native retains actual Supervisor peer, accepted bounded prefix, current exact-human/binding checks and HA existing session; no second OAuth/Domus cookie. Technical Core authority never becomes a human role. Its nonpersonal shell/assets stay behind source/binding guards; personal APIs still require proof.
Standalone keeps operator origin, state/S256/single-use callback and private session. Deliberate `GET /api/v1/auth/start` may return successfully only to the fixed same-origin entry shell; no caller-chosen redirect. `POST /api/v1/auth/logout` keeps Origin/CSRF and truthful grant-revocation/unconfirmed guidance. Native invokes no standalone logout: clear owned tab data/presentation and explain HA-owned sign-out without claiming Supervisor revocation.
## 7. User-facing configuration
|Input|Default/bounds|Persistence|
|---|---|---|
|Household name/timezone|Explicit; backend 160/128 bounds and catalog|Draft, then authorized household command|
|Initial mapping|all_ha_administrators; explain before submit|Existing policy snapshot; other selectors later|
|Journal lifetime|Fixed one hour from original server-time anchor|Retries cannot extend|
|Journal capacity|Eight records, 64 KiB total|Versioned owned per-tab sessionStorage|
|Display|English and Spanish; English fallback; responsive, light/dark, reduced motion|Presentation preferences cannot grant access|
No new password/PIN, policy grant or browser-zone authority is introduced.
## 8. Clean Architecture design
Domain owns pure typed entry/journal values. Application owns the controller and semantic session/household/journal/clock/entropy ports. Neither imports DOM, storage, fetch, Lit or concrete adapters. Adapters strictly decode bounded untrusted HTTP/context and implement owned storage/URL/time ports. Lit presentation depends on semantic models/ports, never concrete adapters. Outer composition owns wiring, cancellation and resource release. Python delivery/context stays in existing entrypoints/composition; household application/domain remain authoritative and framework-free.
Enforce actual full-source inward imports, cycles/unresolved imports, production/test separation and forbidden private parent DOM/storage/HA object/message access with meaningful negative fixtures. No release skip-auth flag or fixture grant. Generation fencing prevents a retired view/session's late response replacing a newer view/subject. Reuse tooling/frontend-coverage.mjs for the separate UI scope. Use exact paths in section 15.
## 9. UI/UX and content contract
Use stable translation keys. A supported explicit UI choice wins; otherwise normalize browser en-* to en and es-* to es. Unsupported/missing languages or localized keys fall back to English. Match document language and accessible labels. Render every entry state in both languages; Existing UI cases retain their identities and gain these assertions. Language changes neither authority, API targets, journal lifetime nor business records. Code/comments/issues/docs remain English; Spanish translation data implements the confirmed UI choice.
Show Domus, actual channel/session freshness and one applicable entry action. Use labeled native forms, retained drafts, associated validation, visible keyboard focus, announced status, safe help and understandable next actions. Pending explains inactive access; suspended/archived asks review of existing linkage; historical says the old effect is absent. Current own permissions govern visible controls; missing/denied facts never become empty success or synthetic totals. Disable duplicate in-flight submission. Grace is visibly read-only with original deadline.
At 360 CSS pixels, no page-level horizontal scroll; require keyboard-only operation, accessible names, error focus, readable light/dark contrast, reduced motion and non-color status. Bind hostile text inertly, never unsafe HTML/code/commands/links. Storybook exercises actual loading/setup/join/pending/active/suspended/archived/denied/grace/invalid/uncertain/historical components with fictional data outside production. Human UX review follows concrete rendering, not the earlier API/console approval.
## 10. Failure, recovery, and cleanup
Persist exact action/payload/revision/original key, context, creation/immutable deadline, stage and known operation reference before first send. Validate shape/version, eight-record/64-KiB capacity and successful storage first. Missing/unavailable/corrupt/future-version/overflow/pre-send failure blocks mutation and preserves draft/guidance; do not silently evict unresolved work.
Scope to server-returned installation/channel/verified subject. Involuntary session loss retains but hides records until identical full fresh context. Only deliberate Check previous request replays identical bytes/semantics/key; the server rechecks current original-command authority. Another context clears incompatible owned records and never reveals/replays them. No automatic mutation queue/rebase/new key.
Use fresh server_time and monotonic page elapsed time; retries cannot extend the original one-hour deadline. Reload requires fresh context. Regression/future-dated inconsistency fails closed. Expiry/tab closure ends only browser retention; server history remains durable. After loss reread actual state before deliberate work; household singleton/unique linkage still protect these commands. Future domains must define recovery before shipping.
Deliberate logout/leave clears owned journal/presentation only. If clearing fails, report uncertainty, discard memory and finish applicable server sign-out; never claim persistent cleanup or resurrect authority. Never touch HA private storage/cookies. Teardown fences late results, aborts owned reads and releases listeners. Dispose identified fixture/build data while retaining compact evidence/current rollback; deterministic browser proof needs no owner household mutation.
## 11. Security, permissions, and privacy
Current server identity/policy/scope/receipt/atomic guards apply. Writes/recovery need full fresh proof; outage reads end at original expiry. Known rejection/suspension/context change/expiry is never grace or renewal; cached display grants nothing.
Journal/bundles/diagnostics exclude tokens, cookies, CSRF, OAuth material, raw errors and private HA storage. All asset/API/navigation targets stay in the verified same-origin supported base: reject foreign endpoints/redirects, traversal, malformed prefixes and credential forwarding. No private host hints, CDN, CORS expansion, service worker credential cache, new port or installation privilege expansion.
## 12. Observability and operational UX
Safe status/channel/freshness and useful validated operation/correlation references only. No journal/credential/private Ingress/household diagnostic leakage. Retain source/runtime/browser identity, commands/assertions/counts/screenshots/cleanup; source/build/fixture/package/owner claims stay separate.
## 13. Compatibility, migration, rollout, and rollback
Accepted stack: locked compatible Lit/TypeScript/Vite, Storybook/Playwright; existing policy-tool versions do not prove framework execution. Fix unsupported runner/measurement scope, never omit runtime/metrics. Native public base is accepted Supervisor prefix plus separator; standalone supports root only. Escaped bootstrap gives deployment/base, no grant/credential. Preserve native trust/fixed standalone callback, base-relative local assets, allowlisted MIME, traversal protection, actual CSP and no-store personal responses. Missing assets/API errors never become shell success. Version/reject unknown journal; loss never prunes receipts. No business migration implied. Edge.3 remains immutable; new package/adoption needs exact pin/artifact/rollback, isolated channels and separate live/companion acceptance.
## 14. Testing strategy and numeric budget
48 prospective UI cases; no UI execution claimed. Existing framework-fixture results add no case credit. Area labels retain their original meanings: Domain=domain/configuration/planning; Application=state/idempotency/races; Adapters=provider contracts; Delivery=workflows/setup/schema; UX=UI/localization/sanitization; Integration=security/migration. Trusted assembly derives counts/reverse links; repeated runs/viewports add no cases.
| Area | Minimum distinct cases | Behaviors/risks covered |
|---|---:|---|
| Domain | 8 | Observable scenarios in the case inventory. |
| Application | 9 | Observable scenarios in the case inventory. |
| Adapters | 8 | Observable scenarios in the case inventory. |
| Delivery | 7 | Observable scenarios in the case inventory. |
| UX | 8 | Observable scenarios in the case inventory. |
| Integration | 8 | Observable scenarios in the case inventory. |
| Total | 48 | Distinct inventory cases; repeated executions do not add cases. |
|Case ID|Area|Requirements|Scenario|
|---|---|---|---|
|household-entry-interface-C01|Domain|ENTRY-01, ENTRY-04|All server membership states choose their defined action; profile labels never grant access.|
|household-entry-interface-C02|Domain|ENTRY-02|Validated server metadata selects context; a host message cannot replace it.|
|household-entry-interface-C03|Domain|ENTRY-03|Default-only setup UI retains other backend mappings for later selectors.|
|household-entry-interface-C04|Domain|ENTRY-03, ENTRY-07|Invalid name/timezone preserves the draft; backend validation cannot be bypassed.|
|household-entry-interface-C05|Domain|ENTRY-06|Reject malformed/future journal version, action, shape or original command fields.|
|household-entry-interface-C06|Domain|ENTRY-06|Retry/backward clock cannot extend the original one-hour journal deadline.|
|household-entry-interface-C07|Domain|ENTRY-06|Unresolved command retains original payload, action, revision and key.|
|household-entry-interface-C08|Domain|ENTRY-01, ENTRY-05|Unavailable facts never become zero, empty success or synthetic totals.|
|household-entry-interface-C09|Application|ENTRY-02, ENTRY-03, ENTRY-04|Open, sign-in and refresh issue no setup/enrollment mutation.|
|household-entry-interface-C10|Application|ENTRY-04, ENTRY-06|Pending offers refresh/admin review; no new enrollment or replacement linkage.|
|household-entry-interface-C11|Application|ENTRY-06|Repeated in-flight submission produces one request/key and one pending result.|
|household-entry-interface-C12|Application|ENTRY-06|Lost committed response: deliberate same-key replay returns one receipt/effect.|
|household-entry-interface-C13|Application|ENTRY-05, ENTRY-06|Permission loss/suspension before retry is server-enforced; no cached grant.|
|household-entry-interface-C14|Application|ENTRY-06|Revision/key conflict retains draft; no silent rebase or new-key retry.|
|household-entry-interface-C15|Application|ENTRY-02, ENTRY-05|Outage reads end at original expiry; writes and lease extension remain blocked.|
|household-entry-interface-C16|Application|ENTRY-05, ENTRY-07|Retired view response cannot overwrite a newer view or another user context.|
|household-entry-interface-C17|Application|ENTRY-02, ENTRY-06|Fresh identical-context reauthentication enables deliberate recovery, never auto-write.|
|household-entry-interface-C18|Adapters|ENTRY-02|Actual standalone sign-in/logout and native existing-session contracts work.|
|household-entry-interface-C19|Adapters|ENTRY-02, ENTRY-07|Native prefixed assets/API/navigation stay within the verified public base.|
|household-entry-interface-C20|Adapters|ENTRY-02, ENTRY-07|Standalone supported root entry/reload resolves actual built assets and API.|
|household-entry-interface-C21|Adapters|ENTRY-07|Malformed/oversized/unexpected API data yields safe error/unavailability, not fake facts.|
|household-entry-interface-C22|Adapters|ENTRY-02, ENTRY-07|Writes require actual session CSRF/Origin; storage never authenticates.|
|household-entry-interface-C23|Adapters|ENTRY-02, ENTRY-07|Foreign endpoint/host hint/redirect cannot retarget the API or export credentials.|
|household-entry-interface-C24|Adapters|ENTRY-06, ENTRY-07|Storage/pre-send persistence failure blocks mutation and preserves draft/next action.|
|household-entry-interface-C25|Adapters|ENTRY-06|Eight-record/64-KiB overflow is rejected before send; prior records remain.|
|household-entry-interface-C26|Delivery|ENTRY-07|Reproducible built UI uses the existing listener; no port or UI dependency in the domain.|
|household-entry-interface-C27|Delivery|ENTRY-08|All runtime, including unimported modules: four metrics at 100% globally/per file.|
|household-entry-interface-C28|Delivery|ENTRY-08|Negative fixture fails for uncovered runtime or incomplete supported metrics.|
|household-entry-interface-C29|Delivery|ENTRY-07, ENTRY-08|Actual import/cycle/private-host gates accept valid graphs and reject violations.|
|household-entry-interface-C30|Delivery|ENTRY-08|Every PR update, draft/docs-only included, runs all suites and the strict aggregate.|
|household-entry-interface-C31|Delivery|ENTRY-01, ENTRY-08|Real built Storybook exercises normal, pending, denied, unavailable and uncertain states.|
|household-entry-interface-C32|Delivery|ENTRY-02, ENTRY-08|Real Chromium runs both compositions; retain browser/build/coverage artifacts.|
|household-entry-interface-C33|UX|ENTRY-01|At 360 pixels, primary actions/labels work without page-level horizontal scrolling.|
|household-entry-interface-C34|UX|ENTRY-01, ENTRY-08|Keyboard forms, focus, validation messages and accessible names cover full entry.|
|household-entry-interface-C35|UX|ENTRY-01, ENTRY-05|Loading/empty/stale/failed reads remain distinct, with an understandable next action.|
|household-entry-interface-C36|UX|ENTRY-01|English fallback, contrast/themes, reduced motion and status work without color alone.|
|household-entry-interface-C37|UX|ENTRY-01, ENTRY-07|Hostile text/markup/links stay inert; no HTML/script/command/unsafe URL execution.|
|household-entry-interface-C38|UX|ENTRY-03|Setup explains the default mapping; unimplemented selectors never appear working.|
|household-entry-interface-C39|UX|ENTRY-04|Suspended/archived guides review of existing linkage; no fresh self-linkage.|
|household-entry-interface-C40|UX|ENTRY-05|Active view shows current own permissions/denials; hidden controls grant nothing.|
|household-entry-interface-C41|Integration|ENTRY-02, ENTRY-06|Wrong subject/installation/channel cannot reveal or replay the old journal.|
|household-entry-interface-C42|Integration|ENTRY-02, ENTRY-06|Logout clears owned journal/local access; cleanup uncertainty never restores authority.|
|household-entry-interface-C43|Integration|ENTRY-02, ENTRY-07|Wrong source/origin/malformed host hints cannot alter identity, role or context.|
|household-entry-interface-C44|Integration|ENTRY-06|Historical receipt identifies absent effect; no automatic fresh-key resubmission.|
|household-entry-interface-C45|Integration|ENTRY-02, ENTRY-07|No tokens/cookies/CSRF/OAuth/private host storage in journal, bundle or diagnostics.|
|household-entry-interface-C46|Integration|ENTRY-06, ENTRY-07|Reload/session loss/expiry/tab closure preserve server receipts and uniqueness guards.|
|household-entry-interface-C47|Integration|ENTRY-03, ENTRY-06|Racing administrators reconcile singleton setup and losing conflict, no duplicate home.|
|household-entry-interface-C48|Integration|ENTRY-07, ENTRY-08|Teardown releases owned resources, records fixture cleanup and never claims owner adoption.|
Real Vitest unit/components: Chromium V8 includes every authored runtime/unimported module; statements/branches/functions/lines are 100% globally/per file, separate from backend/tooling/policy. Negatives fail on uncovered code/incomplete metrics. HTML/styles/config get actual build/browser checks. Owned code stays strict; runtime dependency declarations are checked. Only catalog third-party Storybook declarations may use the documented bounded skipLibCheck exception, with an owned-story type negative. No fake metrics or runtime exclusions.
Build/exercise Storybook and real Chromium prefixed-native/root-standalone journeys: disposable SQLite, outer HA/Supervisor fixtures, DOM/assets/requests, reload/reauth/context races, a11y/keyboard, layouts/CSP/teardown. Simulation is not live HA; no release bypass flag. Every PR (draft/docs-only too) runs actual architecture/host-access negatives plus all existing suites; aggregate fails on missing/skipped/failing required jobs. Retain separate coverage/browser/build artifacts. Full-context current-head Bugbot must have no unresolved findings; skipped/partial/neutral analysis cannot pass. Evidence-based dismissal preserves native review history.
## 15. Documentation and discoverability
|Path|Change|
|---|---|
|specs/household-entry-interface.md|create|
|frontend/src/domain/entry.ts|create|
|frontend/src/domain/journal.ts|create|
|frontend/src/application/ports.ts|create|
|frontend/src/application/entry-controller.ts|create|
|frontend/src/adapters/http.ts|create|
|frontend/src/adapters/session-journal.ts|create|
|frontend/src/presentation/domus-app.ts|create|
|frontend/src/presentation/styles.ts|create|
|frontend/src/presentation/messages.ts|create|
|frontend/src/composition/main.ts|create|
|frontend/index.html|create|
|frontend/vite.config.ts|create|
|frontend/vitest.config.ts|create|
|frontend/playwright.config.ts|create|
|frontend/tsconfig.json|create|
|frontend/.storybook/main.ts|create|
|frontend/.storybook/preview.ts|create|
|frontend/stories/entry.stories.ts|create|
|frontend/tests/domain.test.ts|create|
|frontend/tests/journal.test.ts|create|
|frontend/tests/controller.test.ts|create|
|frontend/tests/http.test.ts|create|
|frontend/tests/component.test.ts|create|
|frontend/tests/language.test.ts|create|
|frontend/tests/e2e/entry.spec.ts|create|
|tests/browser/entry_server.py|create|
|backend/src/domus/entrypoints/ui_http.py|create|
|tests/backend/test_ui_http.py|create|
|tests/backend/test_ui_session.py|create|
|docs/household-entry-interface.md|create|
|docs/evidence/household-entry-interface.json|create|
|frontend/package.json|update|
|package.json|update|
|pnpm-lock.yaml|update|
|tsconfig.json|update|
|architecture/frontend.mjs|update|
|tests/node/architecture.test.mjs|update|
|.github/workflows/ci_check.yml|update|
|tooling/domus_tooling/ci_policy.py|update|
|tests/python/test_ci_contract.py|update|
|backend/pyproject.toml|update|
|backend/src/domus/entrypoints/http.py|update|
|backend/src/domus/entrypoints/native_http.py|update|
|backend/src/domus/composition/server.py|update|
|backend/src/domus/composition/ingress.py|update|
|docs/contracts/auth-api.openapi.json|update|
|docs/contracts/household-api.openapi.json|update|
|docs/contracts/native-household-api.openapi.json|update|
|docs/household-api.md|update|
|docs/native-household-api.md|update|
|docs/development.md|update|
|docs/roadmap.md|update|
|specs/catalog.json|update|
|specs/CATALOG.md|update|
|specs/_template.md|reference|
|specs/application-experience.md|reference|
|specs/household-identity.md|reference|
|specs/platform-foundation.md|reference|
|specs/platform-foundation-identity-sqlite.md|reference|
|docs/administrator-recovery.md|reference|
|docs/ha-identity-protocol.md|reference|
|docs/m1-acceptance-audit.md|reference|
|pnpm-workspace.yaml|reference|
|vitest.config.mjs|reference|
|tooling/frontend-coverage.mjs|reference|
|docs/evidence/frontend-toolchain.json|reference|
|addon-edge/Dockerfile|reference|
|addon-edge/config.yaml|reference|
|docs/acceptance-plan.md|update|
Existing paths are base-verified; create rows are proposed. Declare refinements before code. Label protocol notation. Keep evidence/cleanup current; fixture proof is separate.
## 16. Acceptance scenarios
Exercise all 48 cases in both deployments, including explicit setup/join, pending and existing linkage, current authority/grace, original-command recovery and absent historical effects. No automatic writes. Each gate needs concrete evidence; both languages use the same case identities.
## 17. Requirements traceability
| Requirement | Cases |
|---|---|
| ENTRY-01 | household-entry-interface-C01, household-entry-interface-C08, household-entry-interface-C31, household-entry-interface-C33, household-entry-interface-C34, household-entry-interface-C35, household-entry-interface-C36, household-entry-interface-C37 |
| ENTRY-02 | household-entry-interface-C02, household-entry-interface-C09, household-entry-interface-C15, household-entry-interface-C17, household-entry-interface-C18, household-entry-interface-C19, household-entry-interface-C20, household-entry-interface-C22, household-entry-interface-C23, household-entry-interface-C32, household-entry-interface-C41, household-entry-interface-C42, household-entry-interface-C43, household-entry-interface-C45 |
| ENTRY-03 | household-entry-interface-C03, household-entry-interface-C04, household-entry-interface-C09, household-entry-interface-C38, household-entry-interface-C47 |
| ENTRY-04 | household-entry-interface-C01, household-entry-interface-C09, household-entry-interface-C10, household-entry-interface-C39 |
| ENTRY-05 | household-entry-interface-C08, household-entry-interface-C13, household-entry-interface-C15, household-entry-interface-C16, household-entry-interface-C35, household-entry-interface-C40 |
| ENTRY-06 | household-entry-interface-C05, household-entry-interface-C06, household-entry-interface-C07, household-entry-interface-C10, household-entry-interface-C11, household-entry-interface-C12, household-entry-interface-C13, household-entry-interface-C14, household-entry-interface-C17, household-entry-interface-C24, household-entry-interface-C25, household-entry-interface-C41, household-entry-interface-C42, household-entry-interface-C44, household-entry-interface-C46, household-entry-interface-C47 |
| ENTRY-07 | household-entry-interface-C04, household-entry-interface-C16, household-entry-interface-C19, household-entry-interface-C20, household-entry-interface-C21, household-entry-interface-C22, household-entry-interface-C23, household-entry-interface-C24, household-entry-interface-C26, household-entry-interface-C29, household-entry-interface-C37, household-entry-interface-C43, household-entry-interface-C45, household-entry-interface-C46, household-entry-interface-C48 |
| ENTRY-08 | household-entry-interface-C27, household-entry-interface-C28, household-entry-interface-C29, household-entry-interface-C30, household-entry-interface-C31, household-entry-interface-C32, household-entry-interface-C34, household-entry-interface-C48 |
Derive reverse links from section 14. Separate source, fixture, package and owner proof.
## 18. Implementation sequence
1. Action verifies SDD, exact branch and foundation ancestry.
2. Pure models/ports with complete meaningful coverage first.
3. Strict journal/HTTP/context/time adapters and fenced controller; failure/race tests.
4. Shared server delivery/context/OpenAPI and boundary tests.
5. Owned Lit/Storybook and browser/a11y/layout journeys.
6. Full CI/negative/review gates, docs/evidence/cleanup; identify package/live work separately.
## 19. Definition of Done
- [ ] Eight requirements/48 cases have exact executable assertions.
- [ ] Actual architecture/host-access negatives and all existing suites pass.
- [ ] All four frontend metrics: 100% global/per file, including unimported runtime.
- [ ] Real Storybook, both browser compositions, CSP/auth/journal, a11y/keyboard/layouts pass.
- [ ] Delivery/context/OpenAPI agree; no new port/fake authority/implicit mutation.
- [ ] Docs/catalog, separate measured evidence and cleanup are current.
- [ ] Rendered human UX review recorded; unexecuted package/live scope stays unproven.
- [ ] Current-head CI/full Bugbot clear; Copilot/gateway unchanged.
## 20. References and decisions
Owners/paths: section 15; base: section 2. Owner confirmed both languages with English fallback on 2026-10-31. Accepted journal/context/default entry/quality remain. Locked execution is required; this prospective contract proves no deployment acceptance.Current limitations or challenges
No product UI exists; merged framework fixtures are separate proof. New owner-confirmed languages and declared localization/packaging paths are incorporated.
Expected impact
Deliver explicit setup/join/landing in both targets, preserving all 48 cases and quality gates. Copilot stays unchanged.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIn Progress
Activity
[-]Deliver the household entry interface for native and standalone deployments[/-][+]✨ - Deliver the household entry interface for native and standalone deployments[/+]vypbot commentedon Oct 31, 2026
Hi! I’m @vypbot, the Copilot assistant for this repository.
I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.
Try
/copilot helpto see the available commands, or mention @vypbot with your question.vypbot commentedon Oct 31, 2026
SDD work status
Current status: The SDD is published; implementation can begin after branch verification.
SDD:
specs/household-entry-interface.md· Branch:feature/8-deliver-the-household-entry-interface-for-native-and-standalone-deployments· First commit:82519ee4e547dc347b8d0a18352bd1acc7783d70Links: SDD · Branch · Commit
78 remaining items
[-]✨ - Deliver the household entry interface for native and standalone deployments[/-][+]✨🧑💻 - Deliver the household entry interface for native and standalone deployments[/+]vypbot commentedon Nov 1, 2026
Implementation plan
Acceptance: The published companion is verified on the exact managed branch, and every-PR CI passes with all eight requirements and 48 original case rows retained, both deployments covered, and all four authored frontend coverage metrics at 100%.
Need something else? Mention the bot with a question or use
/copilot help.