Web/phone foundation — define and test the shared task with agent-assisted construction #159

Outcome

Kiran and Chirayu share the web/phone main quest under #132. Kiran turns one useful task into requirements, observable acceptance and a small agent-assisted candidate; Chirayu leads the reusable UI/client foundation through #154. They build one coherent client journey together.

Primary: Kiran (@Kiranchaudhary537)
Partner: Chirayu (@ChirayuBatra99) — UI/client implementation and independent challenge.
Shared outcome: #132. Paired task: #154. Backend/request-result discussion: #131.

First result

• Choose one small Composition-owned task together. Explain who needs it, the useful result, and submit → progress/history → inspect → continue/stop on web and from the phone perspective. For the initial connected Companion, prefer a minimal Bridge client over the selected LAN/VPN transport, with the required identity/authority contract made explicit.
• Walk the existing client/API/Graph path. Identify current behavior, fixtures and missing integration; map the agent role, typed inputs/output and one existing or separately proposed workflow step. Follow current owners rather than inventing another task runtime.
• Produce one short acceptance table: success, refusal, unavailable execution, unknown outcome, refresh/interruption, narrow-screen use and accessible interaction. Preserve exact task/revision identity and the common Enter — design one request/result passage from Discord to the founder PC #131/Enter — design an Altar task people can inspect and steer #132 request/result envelope.
• Agree the small construction seam with Chirayu and the backend owner: UI versus retained state, API/transport, enrollment/object access, failure/recovery and data disclosure. Separate responsive web, the existing Kotlin/Compose Android client and the proposed connected-phone proof. Feed the same plan into Altar foundation — prove a reusable UI path and minimal Companion plan #154; do not write competing plans or screens.
• Use coding agents to produce one bounded test, fixture, prototype or implementation candidate. Specify its allowed area, expected result, acceptance and checks before construction. Review shared-contract changes before multiplying implementations; small labelled prototypes may inform that review.
• Independently try the selected scenario and one failure/interruption case. Bring the acceptance table, candidate, observed result and next small decision to the shared review; exchange the explanation with Nav/Anshuk.

Scope and next steps

This includes hands-on agent-assisted construction, not only requirements handoff. It completes with one scenario and one bounded candidate, not a finished mobile platform. #154 remains Chirayu's client-foundation task; this issue supplies the shared acceptance and construction brief.

#77 retains physical-device/local-audio qualification and its current no-Internet/no-upload fixture boundary. A connected client needs a separately selected implementation with reviewed host contracts; a reachable LAN/VPN supplies no application authority. Use public/synthetic fixtures while privacy and identity gaps remain; #25 and #62 route anonymization and egress requirements.

Scout #155 is Kiran's first side quest. GitHub Reach follows in #160; Gmail and YouTube follow later. These integrations need not block a useful main-quest scene. The later local music extension #161 exercises the same requirements/acceptance method after the basic client foundation.

The pair keeps at most one review-ready implementation slice awaiting the founder. Both can propose UI/UX and agent/workflow approaches, and contributors can help with bounded pieces. Authors inspect the complete generated output; founder architecture/code approval and CONTRIBUTING remain in force.