Enter — design one request/result passage from Discord to the founder PC #131

Outcome

A person asks the Discord bot for one bounded task and can understand whether it was admitted, executed and answered. Our first architecture target connects the VPS with the founder's PC.

Planning window: __enter__, 9–15 November. This ticket completes at a reviewed design and selected probe; it does not promise a finished remote platform.

Ownership

Nav and Anshuk co-own the passage, starting from backend, Linux/PostgreSQL/Litestar and CLI toward Graph and agents. Nav leads the backend execution trace: API/service boundaries, basic capability dispatch/readiness/orchestration and a simple Graph result, using Discord as the first user-facing entry. Anshuk leads PostgreSQL/state/transaction custody, including the selected task/result/human-feedback example, and the runtime/private-route implications. They share Linux host discussion and reproduction; neither direction is exclusive. Divide the work together and invite the other pair's feedback. These are starting responsibilities, not permanent area boundaries.

Foundation tasks — 11 November

• Runtime foundation — trace one Litestar/PostgreSQL task into Graph #152 — Anshuk leads, Nav partners: runtime/PostgreSQL/Graph foundations and one representative reproduction; inspect the merged Tether Add native Tether lifecycle with named isolated attachments #151 and current VPN / Tether — one private peer & explicit route #20 evidence before selecting lifecycle work.
• Backend execution foundations — dispatch, orchestration and task results #153 — Nav leads, Anshuk partners: backend execution fundamentals through the Discord admission/context/result use case, continuing Make the Reach operator's display name configurable and fix Podman hosts #149/Configurable model binding for Reach and an operator opt-in for Portal dispatch #150 and mapping the native Graph handoff.

These are the bounded contributions to this shared design outcome. Review the important contracts before multiplying agent-generated implementation; small prototypes may inform the design in parallel. Both people participate in agent/workflow design and can cross into other areas. Completing a child does not complete this parent or its retained capability owners.

Shared direction and order: founder-led #40 retains the SDLC design. The pair first explains the backend execution passage, durable task/result/feedback records and failure/cleanup boundaries; a deeper inquiry or construction slice remains to be selected. Discuss the basic flow together, then exchange a general explanation and one reproduction with Chirayu/Kiran through #133. Anshuk's #152 example makes later evaluation/training lineage an explicit persistence concern without implementing the trainer.

Scrolls over the private route: identify what crosses the wire (an exact admitted task/contract reference, permitted inputs and result), its receiver and current authority. VPN reachability does not itself transfer execution authority, import executable code or implement portable Scroll registration. #29 retains immutable identity/Resolution Lock acceptance; #19/#20 retain peer semantics and reachability. The sovereign-peer versus same-Lich decision below still governs the actual passage.

Acceptance

• Trace the existing Discord operator path and one native Agent/Graph request. Record what runs today, what is a fixture or dated observation, and what is missing.
• Draw one request-to-result sequence. The founder chooses whether the PC is a sovereign peer or compute belonging to the same Lich before dependent implementation. A2A A2A / Intercom — one outbound task & Graph resume #19, VPN/Tether VPN / Tether — one private peer & explicit route #20 and workflow identity Scrolls / Workflow — register and run one revision-pinned Scroll #29 keep distinct responsibilities; identify the missing receiver/private passage explicitly.
• Agree a small shared contract with Enter — design an Altar task people can inspect and steer #132: caller, permitted operation and inputs, task/revision identity, execution destination, result audience and success/refusal/unavailable/unknown outcomes.
• Specify two reproducible trials: ask the bot a public project question; request one pre-authorized PC task. Include an unrecognized caller and a disconnected PC without blindly repeating an uncertain operation.
• Propose the smallest runnable __init__ baseline and one bounded next change. A VPS bot probe may inform the design; installing a tunnel does not qualify private application authority.

Checkpoint: compare both pairs' designs with Debayan and the founder during Enter, then record the selected architecture and Init probe. Each pair may use coding agents for bounded alternatives and investigations.

Review: the founder owns architecture and reviews/approves every code change. Debayan coordinates integration and testing. Follow CONTRIBUTING.

Start: #52 · Shared acceptance: #133 · Owners of current truth: State, Reach operator.