Enter — design an Altar task people can inspect and steer #132

Outcome

A person submits one useful agent task, sees its history and result, and understands what to do when it is refused, interrupted or unavailable.

Planning window: __enter__, 9–15 November. Complete a reviewed user journey, agent/workflow contract and bounded prototype plan before scheduling implementation.

Ownership

Chirayu and Kiran co-own the complete task, starting from Altar and the phone perspective and following it into API, Graph and agents. Choose an agent role, typed inputs/output and a backend workflow step yourselves under the founder's architecture. The work includes the agent's behavior and result, as well as its interface. This is both people's main quest: Chirayu leads reusable UI/client foundations and construction; Kiran leads requirements, observable acceptance and a coordinated agent-assisted candidate. Select the Composition and agent purpose together and build one shared journey. Both participate in UI/UX, client code and agent/workflow reasoning.

Main-quest contributions — 12 November

• Altar foundation — prove a reusable UI path and minimal Companion plan #154 — Chirayu leads, Kiran partners: Svelte/SvelteKit state, components and generated API foundations, one usable task and a minimal Companion plan.
• Web/phone foundation — define and test the shared task with agent-assisted construction #159 — Kiran leads, Chirayu partners: one web/phone scenario, acceptance table and bounded agent-assisted candidate using the same client plan.

Side quests: Scout #155 is Kiran's first side priority, with Anshuk advising framework reuse and Chirayu the user journey. GitHub Reach #160 follows, then Gmail, then YouTube. Select a bounded slice before starting it; none is a prerequisite for the first main-quest scene. The local music extension #161 is a later candidate.

Discuss the shared UI/UX and request/result contracts with both pairs before expanding implementation. Agent-assisted prototypes can test those decisions in parallel; follow the agreed reusable pattern afterward. The connected-phone follow-on is separate from #77's local audio/device qualification. Full #43 acceptance remains with #43.

Durable human interaction: partner with Anshuk's #152 baseline to identify what submit/edit/assessment means, which exact candidate or revision it refers to, and how saved/reloaded state is shown. Preserve the original result and link a correction instead of silently replacing its history. Human quality feedback and permission to execute an effect are distinct. This is part of one shared scenario, not a separate frontend or a requirement to build training UI. Client/API/persistence basics come before deeper agentic expansion.

Acceptance

• Choose one small Composition-owned task and sketch submit → progress/history → inspect result → continue or stop. Explain its value in ordinary user language.
• Trace the existing Altar/API/Graph implementation and distinguish current behavior, synthetic fixtures and missing integration.
• Agree the same request/result contract with Enter — design one request/result passage from Discord to the founder PC #131. Keep exact task/revision identity through navigation; distinguish admission, execution and result adoption.
• Design the agent role and one backend step: allowed inputs, expected result and its acceptance. Identify whether the first probe uses an existing registered workflow or requires a separately scoped Scrolls / Workflow — register and run one revision-pinned Scroll #29 change.
• Show success, refusal, unavailable PC and unknown execution in a small fixture/prototype, clearly labelled as such. Include one refresh/interruption scenario.
• Sketch where voice and phone can enter this same journey. Select the first voice experiment for later work; Enter does not require a finished handset or speech stack.

Checkpoint: exchange designs with the backend pair, reproduce its selected passage in Init, and propose one bounded agent/backend implementation slice alongside the interface work. Participants can propose approaches and cross pair boundaries.

Review: the founder owns architecture and reviews/approves every code change; Debayan supports design and tests. Contribution procedure.

Start: #52 · Shared acceptance: #133 · Current boundaries: #11, #23, #24, #29, #48 and #77.