Loomworks — Queued Direction — P7-2 Session Delivery: UI vs Agent — v0.1

Version. 0.1 Date. 2026-06-19 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai (scoping) on DUNIN7-M4. For. The P7-2 scoping / CR-drafting chat (Stele Phase 7, slice 2 — SDK surface + mountable router). Status. Queued direction — an explicit input for P7-2, not a P7-1 concern. Markdown primary (technical consumer). Lands in loomworks-record (queued-directions or the Phase 7 phase folder, Operator's filing call).

Plain-language summary

P7-1 (CR-2026-114) defers the cookie/session seam to P7-2. When P7-2 builds the mountable router, it must not default the session-delivery mechanism to cookie-only. The Stele session is a minted token; how that token is delivered to and presented by the caller differs between a web UI and an agent. P7-2 should treat token-delivery as an explicit decision with at least two shapes — cookie (UI) and bearer/explicit-token (agent) — over the same underlying Stele-minted token.

Why this is on the record

The inside/split decision in P7-1 (TOTP re-wrap) has no UI-vs-agent consequence — both options end KEK-direct, and encryption-at-rest is entirely below the API surface; a UI and an agent call the same TOTP-verify route, send the same code, get the same answer. That decision is settled and is not what this note is about.

The UI-vs-agent distinction is real one layer up, at the session-delivery seam — which P7-1 explicitly holds out of scope (the CR keeps COOKIE_NAME and the cookie set/clear helpers as P7-2 router work). This note captures that distinction so P7-2's router doesn't silently inherit a cookie-only assumption.

The ground (from Step 0)

Step 0 §C/§D established the separable facts P7-2 builds on:

• The session is a Stele-minted token. stele/session mints it (issue_session); COOKIE_NAME is Stele-owned.
• **The host owns the cookie mechanics.** Signup/login handlers set the cookie on the FastAPI Response; logout clears it via the host _clear_session_cookie helper; api/deps.py resolves sessions via stele.session.
• So token and delivery are already architecturally separable — the token is Stele's; the cookie set/clear is host-side mechanics over it. This separation is the seam that lets the same token be delivered two ways.

The distinction P7-2 must hold

• Web UI — authenticates and carries a session cookie. Browser-native: set on the response, sent automatically on every subsequent request, cleared on logout. Cookie mechanics (HttpOnly, SameSite, Secure, expiry) are the UI-shaped delivery.
• Agent — typically cannot use a cookie the browser way. It wants a token it holds and presents explicitly (e.g. a bearer header), because it has no browser managing cookie state. Same Stele-minted token; different delivery and presentation.

Both resolve to the same stele.session lookup on the engine side — the difference is purely how the caller receives the token and how it presents it on the next request.

The P7-2 decision this queues (surfaced, not decided)

When P7-2 builds the mountable router, decide explicitly:

• Does the Stele router ship only the cookie-delivery helpers (UI-shaped), leaving any token-delivery path to the host?
• Does it ship both a cookie path and an explicit-token path (UI + agent)?
• Or does it ship neither — Stele mints the token, the host owns all delivery (cookie and/or bearer), and the reference app demonstrates each?

This is a router-surface / SDK-boundary call — the same family as the §E fork P7-1 resolved B-first. It is not pre-decided here. The direction this note commits is only: carry UI-vs-agent delivery as an explicit input to that decision; do not let the router default to cookie-only by inheritance.

Relation to the primitives-only resolution (B)

P7-2 inherits B-first (primitives-only): Stele ships primitive-level routes, signup/login stay host compositions, the reference app wires them. Under B, the cleanest default is likely that Stele mints the token and the host owns delivery — which naturally accommodates both cookie and bearer without Stele taking a position. But that is a P7-2 finding to confirm against the router shape, not a conclusion to assume. The point of this note is that the question gets asked, with both caller shapes named.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Queued Direction — P7-2 Session Delivery: UI vs Agent — v0.1 — 2026-06-19