Altar foundation — prove a reusable UI path and minimal Companion plan #154

Outcome

Chirayu establishes the UI foundations and one usable representative task, so later screens and client behavior can be built quickly without repeatedly changing their state/API contracts.

Primary: Chirayu (@ChirayuBatra99)
Partner: Kiran (@Kiranchaudhary537) — co-owner of the web/phone main quest; leads requirements, acceptance and coordinated agent-assisted construction through #159. Both design and build the same journey.
Shared outcome: #132. Related acceptance: #11, #24, #29, #77.

First result

• Trace the existing static Svelte/SvelteKit client, component boundaries, navigation, generated API contracts and backend authority. Explain which state is transient UI and which comes from retained task/history/result data. Start from the Altar source map and current Frontend Covenant.
• Agree the basic interaction/component patterns with Kiran and invite both pairs' design input. Use one small Composition-owned task to demonstrate submit → progress/history → inspect exact result → continue/stop.
• Define the agent role, typed input/output and one backend/workflow step with Kiran, using the common Enter — design one request/result passage from Discord to the founder PC #131 request/result envelope. The work includes agent behavior from the start.
• Show success, refusal, unavailable PC and unknown execution in a labelled prototype or reproduction, preserving request/task identity through one refresh/interruption. Include narrow-screen use, keyboard access, visible focus and understandable labels.
• Prepare the minimal connected-Companion plan: identify the existing Kotlin/Compose client separately from responsive web UI, select the first handset/transport proof, and identify the enrollment/identity, object-access and retained lookup contracts the selected phone passage requires, and any missing decisions. Review backend dependencies with Anshuk; LAN/VPN reachability is not application authorization.
• Review the representative foundation and any proposed contract changes before multiplying screens. Record one reusable pattern and the next bounded UI or client implementation.

Scope

Use agents actively for prototypes and implementation after understanding the foundation. #77 retains physical-device/local-audio qualification and the current no-Internet/no-upload fixture boundary; it is not the connected-phone task. Preserve that boundary until a separately selected connected slice changes its contract. Select live phone transport as a separate bounded follow-on once its host contract is agreed. Voice and a complete mobile platform are not prerequisites for this result.

Working method

Understand the existing foundations and review any proposed shared-contract changes before multiplying implementations. Use coding agents for investigation, bounded prototypes, implementation and independent challenge. A small prototype can run alongside design and inform it; it must identify fixtures and assumptions. After the representative path and its reusable pattern are understood, build quickly within those boundaries.

The primary coordinates this result; the partner helps design, reviews the explanation and reproduces the example. Others may contribute or propose a different approach. The author reviews the full generated diff. Founder architecture/code approval and CONTRIBUTING remain in force. Bring one concise evidence packet: demo/trace, changed contracts, failure observations, checks and the next decision.

Checkpoint: the next shared planning/demo after the first reproduction. This is one bounded foundation result, not completion of the larger linked capabilities. Keep at most one review-ready implementation slice per pair awaiting the founder.

Later extension: Kiran and Chirayu define local MP3 playback and favorite-passage requirements in #161; a contributor can take its bounded implementation after selection.