Is there an existing issue or feature request for this?

• I searched the existing issues and feature requests. This continues the unfinished administration workspace from ✨🧑‍💻 - Complete household administration APIs and workspace over verified schema9 profile storage #25 after the owner-authorized PR feat: Add household administration APIs and verified browser recovery (#25) #26 checkpoint merge. The open recurrence continuation ✨ - Complete relative recurrence lifecycle and protected calendar after the execution checkpoint #23 has a separate scope.

What area does this improvement affect?

User Interface

What actions does this improvement affect?

Issue, Pull Request, Commit

Description of the idea or improvement

Complete the accessible household administration workspace on top of the actual schema9 and API/controller foundations merged in PR #26 at 8b1cbc110c389b9cdb6ecd11317c95abf2c4b0a9. The reviewed head is b60b7677c07faf62c534943c09748b70ad4a6408; their trees are identical (9386f2ea5249b5ea0c0bb4e83f814f503012be47).

Preserve the owning contracts in specs/household-administration.md, specs/household-administration-integration.md and specs/household-administration-workspace.md. All 72 HADM owner cases, eight HADI refinements and 82 HADW workspace cases remain required. The original 80 workspace rows and two subsequent independent household-scope/lookup cases must remain distinct. Passing foundations do not establish full feature acceptance.

Implement the remaining work:

1. Compose the actual entry and administration controllers into one browser lifetime. Fence logout, expiry, context/authority changes, refresh, cancellation, BFcache and late responses across both controllers. Preserve existing entry intents and its separate journal. Reconcile verified installation/channel/subject and access before exposing private administration views; do not combine old and new contexts.
2. Deliver responsive, accessible English/Spanish roster, identity/provenance, own alias/private preferences, household settings, member access/overrides and HA-role mapping forms. Use actual current permissions, independent exact revisions, explicit confirmation and actionable denied/unavailable/stale/uncertain states. Preserve original commands and same-context drafts; no automatic replay, rebase or replacement.
3. Integrate the existing capability-v2 household binding and separate bounded journal. Explicit recovery uses protected original-action key/ID GET, including valid read-only outage leases and callers without aggregate-read permission. Never require new mutation CSRF/revision preconditions merely to query an original result.
4. Add complete Storybook states and real compiled-browser/Python/SQLite administration journeys in native Ingress and standalone deployments. Cover keyboard/focus/live announcements, narrow layouts, localization, privacy, concurrent writers, storage failure and lost-response/reload recovery.
5. Resolve safe HA avatar-source feasibility and show honest unavailable states when no supported source exists. HA source metadata remains bounded, distinct from authorization and outside SQLite write locks.
6. Audit every retained acceptance row against actual evidence, retain human UX review where required, and complete the supported owner-HA validation and packaging work without conflating historical Edge.5 entry evidence with current administration acceptance.

Current limitations or challenges

PR #26 implements protected profile APIs, bounded HA metadata/directory, exact int64 codecs, shared HTTP transport, separate immutable administration journal, pure authorization and an application AdministrationController. That controller is not yet imported into the browser entry composition; the compiled entry UI remains unchanged. Complete administration forms and actual administration browser journeys are absent.

At the checkpoint, CI Check passes the full 4,364-test backend campaign (151 modules, 100% supported statements/branches globally and per module), 1,020 Chromium unit executions (28 authored runtime files, all four metrics 100%), actual entry/Python/SQLite and Storybook suites, wheel acceptance, types and architecture. Both actual CPU images pass 32 checks each. Native review completes all 13/13 partitions with complete context and zero open/reopened/verification-required findings; three historical valid findings are fixed and one reproduced false positive is dismissed. These counts accept the checkpoint only.

The independent progress-publication failure is reported in vypdev/copilot#828, with exact current evidence at vypdev/copilot#828 (comment). The owner explicitly authorized merge despite reported Copilot-only failures once product CI, coverage and Bugbot findings were clear. Do not change Copilot or weaken checks.

Expected impact

Household members can safely manage their own presentation/preferences and authorized household administration through the actual Domus interface. Lost responses, reloads, current permission changes and HA outages retain truthful recovery without exposing another member's private facts or duplicating commands.

Additional context or comments

Use Clean Architecture, tests first, complete supported coverage globally/per authored module, independent inventories, every-PR CI Check and actual amd64/aarch64 package checks. Keep code, documentation and issues in English; UI in English and Spanish with English fallback.

No new owner product decision is needed for the retained scope. Keep every prior confirmation: HA names by default and optional alias editable by self/administrators; owner-private preferences; configurable household profiles/member exceptions; HA account per participant; local read-only outage lease until original expiry; no caller-selected identity/installation/channel; original-action authorization before receipt disclosure.

The Action owns admission, SDD publication, exact base selection and remote branches. Start from the actual merged develop baseline above, not bootstrap master. Reuse the existing three owning SDDs; declare any new implementation/test paths and validate the unchanged original Copilot SDK before implementation on the exact admitted branch. Do not create a replacement ref, change Copilot code/resources/configuration/workflows/credentials/bounds or touch the integrated gateway.

The complete all-domain product goal remains active. Recurrence/calendar continuation #23 remains required after actual schema9. Do not mark the whole administration workspace, owner adoption, Stable/Edge release or full product complete from this checkpoint or from lifecycle labels.

Maintainer-approved companion recovery (supersedes the failed update route)

The original update attempts failed response-size validation after their one bounded repair: run41521889438/ref7277b01c-193d-426b-a510-9429e3e10aac and the already queued start event41522456887/ref286bf5be-ed46-422f-822b-094d413bf65f. A substantive proportional integration-owner appendix was then supplied, independently passing original SDK checks at17,504 rendered/58,906 composed characters. Nevertheless native run41524885407/job125550058643 also failed response-size validation, expected18,000, ref48c140e4-f41b-4249-83ab-c29ada8d3726. This does not establish the rejected candidate's content/length or root cause. All observations are reported in vypdev/copilot#763 (comment).

Use the supported explicit COMPANION recovery: action companion, capabilityId household-identity, NEW unregistered path specs/household-administration-browser.md. This is the maintainer's approved ownership decision for this same issue, not a new capability or product-scope reduction. Do not reuse the failed update plan, append to an existing owner or regenerate/copy the large owner documents. Preserve all existing HADM/HADI/HADW specifications verbatim; reference their complete contracts and cases. No linked issue27 branch has been published, so no established branch owner is being silently changed.

The exact bounded proposal below passes ownership/format/consistency/case-budget/traceability/path validation using all seven byte-verified original policy modules at3e7ceea08e6131360e026937d1c0cc1b120472e0: raw16,515 characters, rendered17,598, well within the unchanged70,000 companion bound. Rendered SHA25667be304207a22c695c8d055d179db0ce96d4091e1d0760cc94ec2cf37809a3c8. This local proof does not establish native publication/readiness or implementation. Keep the two raw derived-table slots and use the existing trusted renderer; no validator, model, bound or Copilot resource is changed.

All72 HADM owner cases/eight HADI refinements/82 HADW workspace rows remain required, including the original80 plus two independent scope/lookup controls. Keep all24 additional browser refinements below without counting retained rows as newly completed journeys. The full pending interface, actual runtime/browser/SQLite, human UX and package acceptance remains required. No new product choice is needed. Start from actual PR26 merge8b1cbc110c389b9cdb6ecd11317c95abf2c4b0a9 on develop. The exact future managed branch and verified native SDD are publication outputs; do not require them as prior product answers or create a contributor replacement ref.

Proposed bounded companion (raw; derive the two tables normally)

Household administration browser completion

• Draft companion specification, 2026-11-02, issue ✨🧑‍💻 - Complete the household administration workspace after the verified API and controller checkpoint #27, existing household-identity capability.
• Selected new companion: specs/household-administration-browser.md; Domus maintainers.
• Review gates: product UX, architecture, testing, security/operations, documentation.
• No unresolved product decision. Native SDD/exact Action branch readiness is still required.

Preserve specs/household-administration-integration.md verbatim and all contracts in specs/household-administration.md and specs/household-administration-workspace.md: 72 HADM cases, eight HADI refinements and 82 HADW rows (original80 plus two independent scope/lookup cases). This companion adds24 browser refinements; it replaces none and claims no newly completed journeys. Full administration and all-domain scope remains required.

1. Executive summary

Complete the retained EN/ES administration workspace in both deployments over the actual merged schema9/API/controller foundations. Integrate entry/admin lifetimes, complete authorized forms and truthful original recovery. No new product setting, schema or public action is introduced.

2. Problem and evidence

Reviewed b60b767 and PR26 merge8b1cbc110c389b9cdb6ecd11317c95abf2c4b0a9 have identical trees. APIs/controller/journal exist; the browser remains entry-only. Passing checkpoint CI/coverage/review does not accept the UI. Unmodified-source controls reproduce lost active proof on optional household-read failure in both modes; healthy controls pass. Correction and full runtime acceptance remain pending.

3. Actors, surfaces and terminology

Participants, current administrators and operators retain their existing distinct authority. Labels, aliases, provider facts and journals never authorize; receipts describe original processing only.

4. Goals

Non-goals: Copilot/gateway changes, new DDL, arbitrary external images, person-based authentication, notification delivery, automatic mutation retries, key replacement/rebase, automatic promotion or acceptance of recurrence continuation #23. Publication alone authorizes no release/tag or owner HA rollout.

5. Current versus proposed journey

Verified entry -> matched current admin context -> permitted facts/draft -> one original command -> receipt/current state -> deliberate original GET if uncertain

The current entry-only shell becomes the complete retained administration journey. Unknown facts remain unknown; independently permitted work stays usable. Logout, expiry and context replacement hide private presentation.

6. Behavior and state model

An application coordinator publishes private administration only for matched verified installation/channel/subject, access mode/grants and consistent available household scope. Hide private facts while revalidating; reuse safe same-context evidence and fence replaced controllers. One bounded entry reconciliation may align drift; persistent mismatch stays hidden with refresh action, never loops/writes. Optional aggregate failure retains independently verified authority after a current-grant recheck; authentication failure still retires access. Every command/original result retains its own operation-time authorization.

Serialize explicit commands; stale logout during either command cannot cancel runtime/timers. Teardown fences both controllers without claiming to undo server effects. Ticks never renew leases or send/lookup automatically; BFcache restoration requires fresh proof. Preserve same-context drafts and original revisions on language change/failed preflight; reset explicitly to adopt a revision. Retired authority/context clears private presentation; unresolved same-aggregate originals cannot be replaced.

7. Configuration

Retain all owner bounds/defaults: null alias, browser locale/English fallback unless an owner locale is saved, enabled stored routine-summary preference, existing configurable profiles/exceptions/mapping. Language switching is temporary until explicitly saved. Alias is public and editable by self/current administrators; preferences are owner-only. Journal v1 remains eight records/65536 UTF-8 bytes/one hour, separate from entry. Exact positive int64 revisions and closed formats remain unchanged; no credentials, CSRF, raw HA responses, arbitrary URLs or caller-selected identity are configurable.

8. Clean Architecture

Document composition -> application coordinator -> existing entry/admin use cases -> pure domain/semantic ports
Concrete HTTP/journal/clock adapters -> ports; immutable views -> localized Lit components -> closed intents

Coordinator has no DOM/Lit/fetch/storage/HA DTO/SQLite dependency. Composition owns resources, presentation inert rendering, existing application/domain owners mutations and authorization. Enforce inward imports, cycles, DTO contracts and independent authored-source inventories.

9. UI/UX and content

Show identity/access, permitted facts, action/impact, then technical details. Pending: “Checking access. No changes sent.” Action: “Review this pending member; confirm a restricted profile.” Blocked: “Access changed. Changes not saved; refresh.” Partial: “Household details unavailable; other permitted facts remain available.” Uncertain: “Check the original request; do not replace it.” Complete: “Preferences saved. Notification delivery is unavailable.” Historical receipts distinguish absent current effects.

Complete every retained roster/source/provenance, own alias/preferences, household/member/policy form. Preserve untouched policy values, restricted activation/confirmation, protected-grant restrictions and stored/effective-role distinction. Provider failure is not empty success; unsupported avatars remain unavailable. Retain hidden same-context drafts through revalidation. Complete EN/ES labels/help/errors, saved-locale precedence, keyboard/focus/live status,360px,both themes/reduced motion; language switching sends no mutation.

10. Failure and recovery

Use impact -> cause -> action -> retained-state content. Preserve distinctions among denial, unavailability, invalid facts, conflicts/exhaustion, uncertain and historical results. Cancellation cannot undo an atomic effect. Only explicit protected original key/ID GET recovers administration results, under current original-action/operations and owner-private guards; never add aggregate-read, mutation-CSRF or expected-revision preconditions. Read-only outage leases allow these local reads until unchanged expiry and block mutations. Independent capability-v2 household scope binds facts/receipts. Original intent remains immutable; no automatic lookup/resend/rebase/replacement.

11. Security and privacy

Retain all owner privacy/authorization boundaries: matched current proof before private publication, operation-time reauthorization, no actor/context/URL/method injection, inert text, no cross-owner preferences through any view/receipt/audit/event/log, and no revival by retired responses.

12. Observability

Keep bounded authorized status/IDs and exact source/package/check evidence. Separate original failures, corrected results and owner-runtime proof; never log private data or infer user delivery.

13. Compatibility and rollout

Preserve schema9, genuine schema1..8/history, journal/intent compatibility and historical Edge.5 evidence. Verify current wheel/both CPU UI bytes and compatible rollback; no automatic owner rollout/release.

14. Testing strategy

24 additional browser integration refinements; every original owning case remains mandatory and is not recounted as newly completed work.

{{SDD_CASE_BUDGET}}

Tests first; full supported global/per-authored-module coverage, all four frontend metrics/backend statements-branches, independent inventories, deterministic clocks/fakes, actual browser/SQLite, types/architecture/style/docs and every-PR CI Check. Human UX review records actual reviewer/artifact and covers identity/provenance, activation and historical/uncertain recovery; never simulate approval.

15. Documentation and affected paths

Document the normal user journey, configuration precedence, current permission/provenance, provider availability, explicit original recovery, operator setup/rollback and architecture/lifecycle constraints. Update navigation, catalog and actual artifact evidence together. Declare any further new path before implementation; preserve historical evidence identities rather than rebinding them to new UI bytes.

16. Acceptance

Every new refinement and retained case needs evidence at its actual scope. Complete forms, EN/ES/a11y, original GET, real browser/SQLite/package journeys and required human UX review precede full administration acceptance. Neither unit counts, native publication nor a checkpoint proves the whole workspace, owner adoption, recurrence/calendar or all-domain release.

17. Traceability

{{SDD_REQUIREMENT_CASES}}

HADB-01: coordinator/lifetime tests. HADB-02: partial-read/original/draft contracts. HADB-03: localized form and privacy/a11y tests. HADB-04: actual browser/SQLite/package and human acceptance evidence plus user/operator/catalog docs. All original mappings remain unchanged.

18. Implementation sequence

1. Native validate/publish the bounded companion and exact managed branch; verify merged base.
2. Tests first for partial reads and joint lifecycle, then coordinator and both runtime lifetimes.
3. Complete closed intents/localized forms with tests; actual browser/SQLite/Storybook and CPU packages.
4. Audit all retained cases and human UX evidence; current-head no-open-finding review/full coverage, truthful docs and compatible rollback/cleanup.

19. Definition of Done

• All retained/new obligations have actual scoped evidence; complete supported global/per-module coverage.
• Inward architecture, current authority, private results, exact revisions/original intent and lifecycle fences remain enforced.
• Every current-head product/package/browser check passes; no unresolved Bugbot finding.
• User/operator/catalog docs, exact artifacts and human UX review complete; historical evidence preserved.
• No Copilot/gateway change, invented remote ref, automatic promotion or fabricated product completion.

20. Risks and unresolved work

Proof reads can observe transitions: bounded reconciliation must fail safely without loops. Partial sources, revoked grants and storage faults retain truthful states. Native readiness and implementation remain outstanding. All original administration and other domain requirements, including recurrence #23, remain required.