Skip to content

✨🧑‍💻 - Deliver the household entry interface for native and standalone deployments #8

Description

@efraespada

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.

Activity

  1. added
    enhancementNew feature or request
    featureLabel to manage feature branches
    priority: lowLabel to indicate a priority low
    on Oct 31, 2026
  2. added
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    on Oct 31, 2026
  3. added theissue type on Oct 31, 2026
  4. moved this to Todo in vypdevon Oct 31, 2026
  5. changed the title [-]Deliver the household entry interface for native and standalone deployments[/-] [+]✨ - Deliver the household entry interface for native and standalone deployments[/+] on Oct 31, 2026
  6. removed
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    on Oct 31, 2026
  7. vypbot commented on Oct 31, 2026

    @vypbot

    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 help to see the available commands, or mention @vypbot with your question.

  8. added
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    SDDAn SDD update is required before branch work.
    on Oct 31, 2026
  9. vypbot commented on Oct 31, 2026

    @vypbot

    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: 82519ee4e547dc347b8d0a18352bd1acc7783d70

    Links: SDD · Branch · Commit

  10. 78 remaining items

  11. moved this from Todo to In Progress in vypdevon Nov 1, 2026
  12. added
    branchedThe linked branch and required SDD commit are verified.
    on Nov 1, 2026
  13. changed the title [-]✨ - Deliver the household entry interface for native and standalone deployments[/-] [+]✨🧑‍💻 - Deliver the household entry interface for native and standalone deployments[/+] on Nov 1, 2026
  14. added
    state:workingWork can proceed on the verified branch or without a branch.
    and removed
    state:blockedThe workflow is blocked and needs human input.
    state:awaiting-maintainerThe next action requires a maintainer response or approval.
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    on Nov 1, 2026
  15. vypbot commented on Nov 1, 2026

    @vypbot

    Implementation plan

    Current status: Ready to start. No action is required from maintainers before implementation.

    1. Publish and verify the companion specification
      • Create specs/household-entry-interface.md under application-experience, preserving its parent and the reviewed companion’s complete source and path declarations.
      • Verify the exact managed branch and linked contracts before implementation begins.
    2. Define the entry contracts and server context
      • Document additive session and authorization context, setup and enrollment requests, receipt behavior, and failure handling against the existing API.
      • Keep identity, policy, idempotency, isolation, and access decisions server-authoritative.
    3. Implement the entry experience
      • Build the English and Spanish Lit interface for setup, enrollment, membership states, permitted household facts, and explicit result refresh.
      • Keep assets, API calls, and navigation relative to the verified application base in both native and standalone deployments.
    4. Add the bounded command journal
      • Persist each deliberate command before sending it, retaining its original key and payload for recovery without automatic retries or duplicate work.
      • Enforce the one-hour lifetime, eight-record and 64 KiB limits, and fail closed when session context changes or expires.
    5. Prove behavior and document delivery
      • Add unit, component, Storybook, and Playwright coverage, architecture boundary checks, and fail-closed CI with truthful artifacts.
      • Cover both deployments, all membership states, uncertain outcomes, outages, localization, and the required frontend coverage metrics.

    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.

  16. added
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    size: XXLLabel to indicate a task of size XXL
    state:blockedThe workflow is blocked and needs human input.
    state:awaiting-maintainerThe next action requires a maintainer response or approval.
    and removed
    state:workingWork can proceed on the verified branch or without a branch.
    state:ai-processingA Copilot agent is analyzing or working on the issue or change.
    on Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

SDDAn SDD update is required before branch work.branchedThe linked branch and required SDD commit are verified.enhancementNew feature or requestfeatureLabel to manage feature branchesin-progressStart work on an admitted issue.priority: lowLabel to indicate a priority lowsize: XXLLabel to indicate a task of size XXLstate:awaiting-maintainerThe next action requires a maintainer response or approval.state:blockedThe workflow is blocked and needs human input.

Projects

  • Status
    In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions