🔧🧑‍💻 - Establish locked frontend toolchain and execution verification #9

Is there an existing issue for this?

• I have searched the existing issues.

Issue #4 / PR #5 established reproducible Python/Node architecture tooling and is complete. Issue #8 owns the actual household entry interface. This task extends the existing development infrastructure with real frontend framework execution; it does not replace or reclassify #8.

What area does this task affect?

CI/CD

Task description

Establish the locked frontend toolchain and its executable verification infrastructure under the existing delivery-quality contract. Provide reusable strict coverage configuration and a clearly labeled fictional framework fixture, outside product runtime source, that actually builds/runs Lit, Vite, Storybook and Playwright. The missing infrastructure is an independent prerequisite of the household interface.

1. Lock reviewed mutually compatible packages with the existing Node 24.20.0/pnpm 10.34.0/TypeScript 6.0.3 baseline. Initial public-registry candidates are Lit 3.3.3, Vite 8.3.5, Storybook and web-components-vite 10.6.5, Vitest/coverage-v8/browser-playwright 5.0.5, Playwright 1.64.1 and matching required development types. Confirm by execution rather than peer metadata alone. Preserve frozen workspace installs.
2. Keep a small owned framework fixture under tests, not frontend/src. It contains no household workflow, HA/session endpoint, grant, real account, production bypass flag or release control. Its component toggles actual DOM/event state and exposes keyboard/accessibility assertions. Never register this fixture as application-experience code or claim its coverage is product coverage.
3. Type-check all owned runtime/configuration/story/test source strictly. Record dependency-declaration compatibility limitations precisely. An observed Storybook declaration defect must not become an untyped application or silent suppression of owned errors; a negative owned-code fixture must still fail. Do not patch third-party or Copilot source.
4. Run actual Chromium component tests and V8 coverage of the complete fixture runtime, including unimported modules. Enforce statements, branches, functions and lines at 100 globally and per file through reusable policy. Meaningful negative executions must fail for an unimported/uncovered module and for incomplete supported coverage evidence. Keep policy/tooling, framework-fixture and future product scopes separate.
5. Build the Vite fixture with relative local assets, build the actual Storybook catalog and execute real Playwright journeys against both built outputs. Assert actual state changes, keyboard focus, accessible names and usable narrow/wide layout. These are toolchain fixture results, not native Ingress, standalone authentication, owner HA or the 48 application cases.
6. Add the required frontend-toolchain job to the project-owned CI Check on every PR update, drafts/docs-only included, and its fail-closed aggregate. Preserve every existing backend/tooling/architecture/docs/container suite and protected Copilot resource checks. Pin actions/runtimes and retain distinct coverage/build/browser artifacts. PR code runs without publication credentials.
7. Use bounded disposable loopback fixture servers, release owned processes/listeners and test data on success/failure, and retain compact exact-source/runtime/command/assertion evidence. No owner HA connection/configuration/household change is necessary.
8. Update development/acceptance documentation and actual delivery-quality catalog evidence. Distinguish established framework execution from the still-unimplemented household UI, companion, domains and deployment/channel acceptance. Do not count a successful fixture build as a completed product capability.

Minimum meaningful verification obligations: frozen dependency install; owned runtime/story type-check plus a failing owned-type negative; real Lit state/event execution; four-metric positive coverage; unimported-source and incomplete-metric negatives; actual Vite/Storybook builds; real browser/keyboard/a11y/layout assertions; owned server teardown; every-PR strict aggregate; protected-resource non-regression. Record concrete executed tests and commands, not a synthetic wrapper count.

Current issues or inefficiencies

The repository currently has architecture-policy Node tests but no authored frontend application, actual framework build, catalog, component/browser execution or product frontend coverage. The UI SDD must not infer framework support from those policy tests or from a validated catalog.

An isolated local compatibility investigation has installed exact packages and Chromium. It has found genuine Storybook dependency declaration errors with TypeScript 6; the bounded development-only handling and actual builds/browser runs remain under verification. No repository source was changed by that experiment, and no product coverage or CI-runner result is claimed.

Issue #8 has a complete locally validated companion proposal but its Action generation still fails before branch publication. This task is legitimate quality-infrastructure work under the existing delivery-quality requirements; it does not authorize household UI implementation on this branch, disable pre-branch SDDs, invent a feature branch or weaken any gate. The Action owns this task's admission, exact branch and parent selection.

Expected impact

Developers and CI can reproducibly execute the selected frontend stack and prove its coverage/type/build/browser guards before adding the real household interface. That interface will subsequently add its own authored runtime, catalog states, all 48 acceptance cases and independent complete coverage; this infrastructure is not their substitute. M1 and the complete all-domain, both-target, isolated Stable/Edge first release remain incomplete until their own evidence exists.

Alternatives considered

Keep the owner-approved Lit/TypeScript/Vite, owned components, Storybook and Playwright direction. Peer compatibility, a static generated catalog, an empty product suite, fake UI controls or excluded runtime cannot prove execution. Preserve backend/inner-layer independence. Installed Copilot/gateway resources stay immutable; only project-owned dependencies, tooling, fixtures, CI Check, docs and factual delivery-quality evidence are in scope.

Additional context or comments

Base foundation: develop at 302e440. Existing owners: specs/delivery-quality.md, docs/development.md and docs/acceptance-plan.md. Relevant existing code: architecture/frontend.mjs, tooling/domus_tooling/ci_policy.py, tests/node/architecture.test.mjs, tests/python/test_ci_contract.py and .github/workflows/ci_check.yml. Use the installed chore workflow; wait for the Action's exact linked branch before implementation.

All code, tests, docs, issues and PRs are English; communication with the owner is Spanish. Clean Architecture, maximum meaningful first-party coverage and full current-head CI/Bugbot without unresolved findings remain merge requirements. Report genuine Copilot errors upstream in English; do not modify Copilot or bypass its lifecycle. No release, promotion, production install or HA authorization is part of this maintenance task.