The Review Agenda

This is the running order for the Luke + Jan review sitting. It consolidates the ten-question agenda from the decisions ledger and every “session questions” list across the eight Part III reviews — 43 raw questions — de-duplicated into 34 items in the order they are best taken. Each line is one decision: who decides, why it matters in a sentence, and a link to the section that argues it. The design frontier is the reasoning behind these; this page is the driver’s seat.

Decider key: ▲ Luke (litmus / security / frozen-schema) · ◆ Luke + Jan (ceremony / placement / strategy) · ○ Fable / orchestrator (reversible — confirm intent only). Take the sections top to bottom: ratifications unblock dispatch, so they come first; then the big forks that set the spine; then per-layer decisions; then quick confirmations that need a yes/no, not a debate.

1 · Ratifications (unblock dispatch first)

Two PROPOSED decisions gate real work — nothing downstream dispatches until they are disposed.

1. Ratify d/104 — the launch seam (▲ Luke) — Bless the catalog descriptor (label → http://<app>.localhost:5454) as the single Controlled-Frame launch seam on every platform? It unblocks Android’s two BLOCKED frame cells and unparks the P-188 responder; reversal is cheap, no code depends on it. → devices: launch seam

2. Rule on d/103-B — the whole-origin route type (▲ Luke) — Ratify a distinct container-origin route type, or bless the shipped backend-proxy empty-digest overload as permanent? It is the first change to the frozen route-table schema and gates P-210 (the Immich compose UI). → serving G1

2 · The big forks (set the spine)

The four decisions that shape the most downstream work. Budget real interview time here.

3. Membership-vs-ticket serving (▲ Luke) — Gate the serve tunnel on the existing MembershipRegistry (revocation cuts serving for free), or keep bearer tickets and add UCAN? A removed device still serves and consumes while it holds a live ticket — enrollment and authorization-to-serve are not the same graph today. (Sub-question: adopt a bounded-lifetime exp ticket now to unblock durable secrets, or wait for full membership gating?) → peer-serving: questions

4. https-vs-plain-http on loopback (▲ Luke) — Keep https-by-default with the name-constrained CA (Chromium-build-dependent enforcement), or lean on the browser’s localhost secure-context and drop the CA ceremony for regular apps? The code says https-default and d/101 says plain-http-default — the site needs one current truth. → serving G3

5. In-frame permission model (▲ Luke) — Does the shell broker all app permissions via the agency ladder (shield-by-default, journaled), or delegate to Chrome’s native per-origin prompts inside the partition? This decides whether “your agent answers for you” is real or marketing — the highest-leverage undesigned sovereignty surface in the whole system. → shell G6

6. v1-vs-v2 group document (▲ Luke) — Is crates/xe-sync (v2: Device/Companion kinds, endpoint bindings) or crates/net/group (v1: what gossip and the membership gate compile against) the canonical membership layer for shipped serving? This blocks item 3. → transport: questions

3 · Per-layer decisions

7. Movable memory & exit-without-loss format (▲ Luke) — Commit a per-app export/import format now, or stay single-home? Two litmus clauses are half-met: app data is single-home (sync moves metadata, not the data inside apps) and xe export is intent, not a proven whole-machine round-trip. → ledger: review agenda

8. Production key ceremony (◆ Luke + Jan) — When does the offline split-custody signing ceremony run (after Thailand?), and does compose’s always-UnsignedDerived identity get a publisher-key story? It gates all public distribution — every install reads “(DEV-SIGNED)” until then. → app-model AM-3

9. Boot Service wake-channel mechanism (▲ Luke) — Loopback + per-install token, IWA Direct Sockets with an authenticated handshake, or OS socket activation? An unauthenticated loopback TCP socket is disqualifying by our own standard (d/053); this is the load-bearing piece of the local-trust boundary. → shell G4

10. Authed-wake crux (AW-1 / AW-2) (▲ Luke) — Accept “same-network zero-resident desktop only; cross-internet asleep-wake is out of v1” (relay mailbox reserved), and membership-derived authorization vs. a group-doc Statement wake-policy type? The transport that reaches a device (iroh) is the one that cannot OS-socket-activate it. → devices G-4

11. Port custody / framing trust (▲ Luke + Jan) — Accept same-UID loopback squat as v1-scoped, or make Prism verify the plane’s identity before framing it (pinned leaf / handshake secret)? A shell that frames a squatter has been quietly compromised with no transport broken. → serving G2

12. Multi-OS-user plane (◆ Luke + Jan) — Is one-Xe-per-user-per-host an acceptable v1 boundary, or do we need per-user port derivation now — knowing the origin string is the storage/service-worker key and the most expensive thing to change later (SEQ-1)? → serving G4

13. Relay trust + self-hosted iroh relay (▲ Luke) — Run Agent54 relays pinned in the signed head, or accept number0’s public relays direct-preferred with relay-fallback documented? Relays see connection metadata; d/014 requires a self-hosted iroh-relay (a human packet: container + DNS + TLS) before any production peer traffic. → transport G3

14. Multi-person groups / sharing scope (▲ Luke) — In near-term scope, or explicitly post-camp? Everything today is one user’s own device group under a single-writer group doc; there is no decision covering sharing an app or data with another person. The local-first audience will ask first. → ledger: review agenda

15. GPU / ML backend class (▲ Luke) — Design a narrow, separately-consented device-grant carve-out, or keep ML backends off the container subset entirely? The isolation subset forbids exactly what GPU passthrough needs (devices: + privileged); Immich dropped its ML service to install. Ties the BYO-models litmus. → engines EB-4

16. Windows backend engine (◆ Luke + Jan) — Is Windows-with-backend in scope now (a WSL exec bridge or a named-pipe socket contract), or explicitly deferred? Serve and in-frame consume are proven on Windows; a backend behind the app is not. → engines EB-2

17. P-174 sequencing (○ Fable — confirm) — Dispatch P-174 to close the three compose-validator holes before P-210 runs a third-party manifest? The proofs so far used authored manifests; a third-party manifest is a different trust posture. → engines EB-3

18. Device recovery ceremony (▲ Luke) — Lost phone / new laptop: admin-re-invite (the current implicit answer), or threshold / social recovery of the group authority key? A new device inherits no grants, and a lost authority device is currently unrecoverable. → devices G-3

19. Sovereign push for force-stopped Android (▲ Luke) — UnifiedPush self-hosted (on-thesis, more to run), FCM opt-in (a Google dependency on the wake path), or both user-selected? The missing primitive behind the Android wake row (d/037 Q3). → devices G-6

20. Agent delegation / the UCAN decision (▲ Luke) — Is Reagent’s authority the same xenon-cap/xenon-grant substrate (Grant = long-lived delegation, Lease = attenuated invocation), and is agent://act enforced in v1 or kept declared + audited? Make the UCAN alignment an explicit product decision, not an implementation detail. → agent-layer G-2

21. Agent boundary siting + lease-signing root (D-1 / D-5) (◆ Luke + Jan) — Does the injection boundary ship in the shell now or wait for a real daemon, and what is the lease-signing root — given the shell shares an address space with the forgeable iwa: IPC channel, which can otherwise mint the very lease meant to bound it? → agent-layer G-1

22. BYO model wiring (▲ Luke) — A model-selection capability, a config file, or status-quo hardcoding for v1? Hardcoded model IDs in darc are a live sovereignty-litmus violation the kickoff flagged. → agent-layer G-1

23. Journal unification (▲ Luke) — Fold the standalone grant/trust JSON-lines logs into the hash-chained audit journal so the Console’s Activity view can witness them, and converge the two duplicate ledger implementations onto one discipline? An inspectability-litmus gap. → agent-layer: one ledger

24. Composition scope (▲ Luke) — Promote composition onto the Controlled-Frame + catalog path so any two fleet apps compose (d/103’s intended generalization), or keep it a curated shell feature over the two fixtures it runs on today? → shell G3

25. Chromium-fork maintenance cadence (◆ Luke + Jan) — Drive android-iwa toward zero patches as upstream Controlled Frame / IWA lands (accepting an upstream-timing dependency), or maintain a standing carry-patch set? Rebase cadence and patch-count budget are unset. → shell G5

26. Companion serving semantics (▲ Luke) — Should MemberKind::Companion (v2) be allowed to consume but never publish? No serving semantics exist for it today. Ties to item 6. → transport: questions

27. Route-table versioning under the freeze (○ orchestrator — confirm) — Confirm additive-only + fail-closed as the evolution rule, and whether the first type addition (item 2) should introduce explicit schema-version negotiation rather than relying on 404-on-unknown. → serving G5

4 · Quick confirmations (yes / no, not a debate)

Reversible or already-owned calls that just need a nod to keep the site and the code aligned.

28. The no-502 question (○ orchestrator → Luke if copy changes) — Distinguish 503 (plane can’t reach upstream) from 502 (upstream errored) in the honest-error contract, or keep the single synthesized 503? → serving: no-502

29. Windows exposure-tripwire (○ Fable — taste call) — Refuse-by-default on a non-owner ACE (Unix-symmetric) with --repair opt-in, or keep the silent repair plus a loud audit record? → peer-serving G2

30. Example-set hygiene (○ Fable — confirm intent) — Migrate the dev-signed swbn examples (scratchpad, appdex) to the plain-HTTP default tier so the set teaches d/101 cleanly, or relabel them explicitly as super-tier demos? → app-model AM-2

31. Doc hygiene (○ Fable) — Refresh the stale serving-and-placement-design.md (it still calls backend-proxy “dormant,” contradicted by shipped P-203), or supersede it with this documentation site as the live truth? → engines EB-6

32. darc → Reagent rename timing (◆ Luke + Jan) — Does review-session material and near-term copy say “Reagent” now, or keep “darc” until the rename (d/053) is actually performed by Luke + Jan? → ledger: review agenda

33. Naming glossary fix (○ Fable — agreed?) — Confirm the glossary keeps the product delegation model (capability-model + injection-boundary) distinct from the unrelated delegation-interfaces.md broker, so no reader conflates them. → agent-layer: questions

34. Xenon-is-Helium-based — phrasing check (◆ Luke + Jan) — The site’s shell primer states “Helium is its base (d/053),” and d/008 / d/061 record Helium as the confirmed Xenon base. The shell writer flagged this as a copy-phrasing point to confirm before it hardens — not a re-opening of the decision, just a nod that the phrasing is correct. → ledger: d/061

Reasoning and options for each item: The Design Frontier. Decision records: the decisions ledger, with PROPOSED items collected under Proposed / pending Luke.