Sol design review — Mission & decisions spine

Part of the site’s external review; reproduced verbatim below the header. sol’s positions are folded into the design frontier as External review input lines.

• Date: 2026-07-18
• Reviewer: gpt-5.6-sol (via codex exec, model_reasoning_effort=xhigh), run on lane-182
• Scope: src/big-picture.md, src/part1/mission.md, src/part1/decisions-ledger.md — the whole-system big picture, the mission/principles/litmus, and the curated decisions ledger.
• Method: All three chapters were inlined verbatim into a single self-contained prompt (no filesystem context given to the reviewer); the reviewer was briefed to be direct and critical, and to return five structured sections plus a terminal sentinel line.

Orchestrator-facing summary (5 lines)

1. Verdict: the spine is directionally sound but oversells in three recurring ways — false absolutes (“a browser cannot install / own identity”; “native OS … but closed” ignoring Linux/BSD), slogans used as guarantees (“zero-trust”, “every rung is consented, receipted, and undoable”, “no cliffs”), and a trust chain described as user-owned that is operationally operator-owned (orchestrator holds the seeds; no user-selectable roots).
2. Strongest single criticism: there is no explicit threat model or trusted computing base — every security claim (origin isolation, engine/VM containment, launch resolution, delegation, audit) rests on an unnamed boundary, and both proposed decisions each widen an authority boundary that no invariant governs.
3. Contradicts our ledger where it bites: mission says regular apps need “no signing”, but d/079 + the Big Picture say install verifies a signature + content hash — sol demands we split publisher identity / catalog authorization / payload integrity / local consent into separate terms; and the “two independent axes” are not independent (a plain L1 app can be driven only because an L3 shell + browser-level CDP act on it; L3 is a genuine cliff, contradicting “no cliffs”). Also flags “unmodified, un-Xe-aware L1” as unsupported (re-origining breaks OAuth redirect URIs, WebAuthn RP-ID, cookies, service-worker scope) — one Excalidraw success is not a compatibility envelope.
4. Top-5 actionable asks (ranked): (1) publish an executable threat model + authority matrix before implementing d/103-B or d/104; (2) define a versioned App Contract v1 with an immutable app_id/instance_id (labels display-only) and a conformance suite; (3) replace blanket “undo” with a transactional action protocol (reversible / compensatable / irreversible classes); (4) specify and prove a portable-state format before shipping peer metadata schemas; (5) replace the single operator catalog root with a TUF-style, user-selectable trust system.
5. On the two PROPOSED decisions: take the distinct container-origin route type (overloading backend-proxy hides an authority change from an /api request boundary to an active-content publication boundary; the VM boundary does not contain the browser-side blast radius); and d/104 is “not ratifiable as written” — a mutable display label must not become a security principal, so bind launch to an immutable app_id + instance_id capability (not an arbitrary URL) and constrain post-launch navigation, not just the first URL.

1. Internal inconsistencies and weak arguments

1. The foundational “missing layer” argument is built on false absolutes. The text says, “A browser can open an app but cannot let you truly own its install,” while browsers already support installation, offline execution, origin-bound identity, storage, background workers, and updates through PWAs. It also says native operating systems provide these capabilities “but [are] closed,” ignoring Linux and BSD. Xe may offer a different ownership and composition model, but the claimed absence of any existing computer-like web layer is not established.

2. “Universal app package manager” does not describe the presented system. Regular apps explicitly have “no bundle format, no manifest requirement,” while installation is actually a signed catalog record plus payload or proxy configuration. There is no described dependency model, version solver, update-channel policy, uninstall contract, transaction protocol, or rollback mechanism. This is a catalog-driven application router, shell, and backend supervisor—not yet a universal package manager.

3. The isolation argument is circular and changes between chapters. Chapter A says each *.localhost origin gets “exactly the isolation the web already provides” and therefore needs no packaging. d/101 instead says isolation “is already delivered by the Controlled Frame.” Those are different boundaries: same-origin policy separates origins; Controlled Frame partitions and mediates an embedded guest; an engine VM contains backend execution. The design never states which boundary protects which asset from which attacker.

4. The anti-IWA argument conflates packaging, authenticity, and gatekeeping. d/101 argues that per-app IWA packaging “would just be a store-like gate.” A signed package format does not require a centralized store or publisher approval. Xe itself permits self-signed packages and depends on a signed catalog. Rejecting mandatory IWA packaging may be correct for compatibility, but the stated reason is a false equivalence.

5. The regular-app signing story contradicts itself. The mission says regular apps require “No signing,” while d/079 says they ship as “a signed catalog row + content-addressed static payload,” and the Big Picture says installation verifies “the signature and content hash before anything runs.” Either the catalog signature authenticates the executable mapping, in which case regular apps are indirectly signed, or it does not authenticate the publisher, in which case the claimed trust chain does not establish app identity. The document needs separate terms for publisher identity, catalog authorization, payload integrity, and local consent.

6. The “user-owned trust chain” is actually operator-owned. Distribution is controlled by an Ed25519 catalog, the orchestrator holds the signing seeds, public distribution waits for Luke, and the production ceremony is controlled by Luke and Jan. There is no design for user-selected roots, multiple catalogs, threshold recovery, root rotation, publisher delegation, compromise response, or catalog transparency. A user can inspect this trust chain but does not own or fork it in any operationally defined sense.

7. The two supposedly independent capability axes are not independent. The install spectrum mixes lifecycle state—“visited” and “installed”—with capability grants and a packaging/security class. L3 is an IWA-only tier with Controlled-Frame powers, which is a substantial cliff despite the claim that there are “no cliffs.” A plain L1 app can be “driven” only because an L3 shell and browser-level CDP authority act on it, so the achievable agency rung directly depends on another app’s install class.

8. The vocabulary collapses the same axes it claims to separate. “Super web app / super user agent” are declared interchangeable, while one is an app class on the install spectrum and the other is the terminal rung of the agency ladder. A shell capable of hosting Controlled Frames is not necessarily an agent, and an agent is not necessarily an installable app. Reusing the same term on both axes makes grants and audit records ambiguous.

9. “Every rung is consented, receipted, and undoable” is false. Sending correspondence, making a purchase, disclosing data, deleting remote data, or booking a non-refundable service cannot be made undoable by a journal. At most, Xe can support rollback for local state and compensating actions where an external service offers them. The mission’s “audit + undo” rule needs explicit irreversible and compensatable action classes.

10. The full-authority mission conflicts with the permission model. The mission defines the agent as acting “with full authority” across the user’s digital life, while d/027 requires attenuable delegation and the agency ladder requires per-action consent. User sovereignty can mean that the user retains ultimate authority; it must not mean that the resident agent receives root-equivalent ambient authority. The current language fails to distinguish those positions.

11. “Zero-trust” is being used as an uncheckable slogan. “The system assumes nothing and proves its own state” is impossible: Xe trusts the host OS, browser, browser update chain, workerd binary, engine, compiler, signing roots, device enrollment, and hardware. The design needs an explicit trusted computing base and compromise model. Calling the system zero-trust does not remove those dependencies.

12. The hard promise that L1 apps run “unmodified and un-Xe-aware” is unsupported. Re-origining an app to <app>.localhost changes OAuth redirect URIs, WebAuthn relying-party identity, cookie behavior, service-worker scope, storage identity, absolute URLs, CSP, framing policy, mixed-content behavior, backend discovery, and assumptions about TLS. _headers, catalog rows, proxy routes, and launch descriptors are also integration metadata even if application source code is unchanged. The promise needs a defined compatibility envelope, not a single successful Excalidraw example.

13. “Browsers treat *.localhost as a secure origin” is imprecise and security-critical. Loopback origins may be treated as potentially trustworthy for many secure-context checks, but plain HTTP localhost is not equivalent to authenticated HTTPS for all cookies, APIs, redirects, certificates, or origin-bound credentials. The document uses “secure origin,” origin isolation, transport authentication, and trustworthy context as though they were interchangeable.

14. The stable-origin promise has no stable identifier. d/077 derives origins from names and resolves collisions with suffixes; d/104 proposes “app label → plane origin.” Labels are mutable, localizable, attacker-influenced, and collision-prone. Installation order could therefore change the hostname across devices, breaking cookies, IndexedDB, service workers, grants, OAuth configuration, and audit identity.

15. “No cross-app CORS, ever” is incompatible with the composition mission unless the bypass is specified. Generated composition requires the agent to read panes A and B, and the driven rung uses CDP. That means an L3 component intentionally crosses the isolation boundary that “no cross-app CORS” supposedly protects. This can be a capability-mediated bypass, but the design must name it, bind it to grants, and constrain its outputs rather than presenting origin isolation as absolute.

16. The peer narrative overstates what is peer-to-peer. The catalog trust root, forge, release process, and relay infrastructure remain centralized operational dependencies. “There is no central hub” is true only of the intended device-state topology. It is false as a description of control, bootstrap, discovery fallback, and software distribution.

17. The state-sync premise is not supported by the selected scope. The mission promises users can “sync your own state,” but d/068 syncs only source pins, serial anchors, and receipts while app volumes remain single-home. Byte-identical transfer proves static artifact transport, not application-state synchronization, conflict handling, recovery, or continuity when the home device is unavailable.

18. The phone role is internally inconsistent. Chapter A says the phone is “not a sync peer”; d/042 calls iOS a “full group member”; d/062 includes a future Android runtime; and Chapter A already claims an Android on-device plane is proven. The design does not distinguish group membership, identity membership, runtime participation, serving, synchronization, and consent-only operation.

19. The zero-resident Boot Service claim evades the wake problem. A service that wakes a runtime needs an OS-managed activation mechanism or a resident listener. d/053 admits that the wake channel is undecided. “Zero resident processes” is therefore either delegated to launchd/systemd/Windows—making the OS service manager the resident mechanism—or technically unexplained.

20. The project is not universal while its core shell depends on Chromium-specific experimental surfaces. Xenon does not exist as a built artifact, stock browsers require flags, Controlled Frame is Chromium-specific, and iOS cannot host the shell. “Any of your devices” and “universal” are future aspirations contradicted by the current dependency structure.

21. The ledger’s “higher number wins” rule is not design governance. Superseding a decision requires compatibility impact, migration rules, affected artifacts, and conformance tests. d/094 still has a stale TCP implementation, d/103 contradicts its own code comment, and the serving scheme changed materially. Number ordering records intent; it does not reconcile deployed state or protect mixed-version peers.

22. The claimed proof boundary is too weak for the claims attached to it. Byte equality, successful rendering, and an offline notice prove narrow integration paths. They do not prove isolation, app authenticity, rollback resistance, permission attenuation, revocation, audit completeness, compromised-peer behavior, or recoverable updates. Calling the entire path “proven” without naming the property under test invites security claims to inherit evidence that only establishes functionality.

2. Prior art and standards alignment

3. Top five highest-leverage improvement proposals

1. Publish an executable threat model and authority matrix before implementing d/103-B or d/104

Define the principals—ordinary web page, L1 app, L3 shell, resident agent, local process, engine workload, peer, catalog publisher, and compromised device—and list which assets each may read, mutate, launch, or delegate. State whether SOP, Controlled Frame, VM isolation, signed metadata, or a capability protects each edge, then add negative tests for DNS rebinding, hostile Host headers, CSRF, path confusion, redirect escape, replayed grants, malicious peers, compromised catalogs, prompt injection, and engine escape.

Touches: d/027, d/028, d/053, d/075, d/082, d/094, d/100–d/104, and the “zero-trust” claim.

Expected payoff: It replaces overlapping security slogans with reviewable invariants and prevents route, launch, wake, and agency mechanisms from independently widening the same boundary.

2. Define a versioned App Contract v1 with immutable principals, typed routes, and a conformance suite

Create an immutable app_id derived from a publisher key or content identity, a distinct per-install instance_id, and a launch descriptor containing the exact route kind, expected origin, version/digest, frame policy, engine endpoint capability, redirect policy, and offline behavior. Labels must be display-only. Use a tagged container-origin route rather than overloading backend-proxy, map compatible Web App Manifest fields into the contract, and atomically activate the descriptor and router table.

The conformance suite must cover OAuth redirects, WebAuthn, cookies, service workers, IndexedDB, CSP, COOP/COEP, WebSockets, streaming, large uploads, absolute URLs, backend wake, offline behavior, and update rollback across representative real applications.

Touches: d/067, d/076–d/081, d/092, d/100–d/104.

Expected payoff: It makes stable origin identity enforceable, resolves both proposed decisions on a coherent schema, and turns “unmodified web apps” from a promise into a measurable compatibility class.

3. Replace blanket undo claims with a transactional action protocol

Define action classes as reversible, compensatable, or irreversible. Require a prepare step that exposes the exact principal, resource, input hash, external effects, grant, expiry, and available compensation; bind execution to that prepared operation; use idempotency keys; record the result and verification state; and require explicit confirmation for irreversible actions. Unify grants, invocations, external results, compensation attempts, and revocations in one tamper-evident journal.

Touches: the Power Design “audit + undo” rule, d/027, d/064, d/082, d/091, and the sovereignty audit clause.

Expected payoff: It produces a defensible agent-safety model for purchases, messages, disclosures, and deletions instead of promising an impossible universal undo.

4. Specify and prove a minimum portable-state format before shipping peer metadata schemas

Define a versioned export container containing catalog pins, app identity, configuration, grants, journal references, encrypted volume snapshots, integrity metadata, and application-specific export hooks. Specify quiescing, incremental snapshots, key rotation, failed restore, schema migration, deletion propagation, and recovery from a corrupt or lost home device. Require a fresh-machine export/import round trip and an independent reader before calling exit-without-loss met.

CRDT synchronization should be an optional data-type contract layered on this format, not a universal solution for opaque volumes.

Touches: d/062, d/068, the peer-topology claim, and sovereignty clauses 4 and 6.

Expected payoff: It prevents metadata sync from becoming an incompatible spine while the actual user data remains immovable and unrecoverable.

5. Replace the single operator catalog root with a user-selectable, TUF-style trust system

Define offline threshold roots, delegated publisher roles, expiry, snapshot/timestamp metadata, rollback and freeze protection, emergency revocation, key rotation, compromised-root recovery, and multiple user-selectable catalogs. Add build provenance, SBOMs, and reproducibility evidence, and specify how personal/self-signed packages coexist with catalog packages without acquiring catalog authority.

Touches: d/007, d/013, d/041, d/064–d/067, and the claims that users own the trust chain and can fork or leave.

Expected payoff: It moves control of installation policy from Luke, Jan, and the orchestrator to an actual user-governed trust configuration while making compromise recovery possible.

4. Risks and hidden coupling in the proposed decisions

d/103-B: container-origin versus overloading backend-proxy

The design should use a distinct, versioned container-origin route type. Overloading backend-proxy hides a change in authority behind a reused schema name.

A prefix proxy mediating /api exposes a bounded request surface. A whole-origin proxy publishes active HTML and JavaScript, controls navigation, sets origin-scoped storage, may register service workers, handles cookies and redirects, opens WebSockets, processes uploads, and can exercise APIs available to a trustworthy localhost context. This moves the connector from a backend request boundary to an active-content publication boundary.

The VM boundary does not contain the browser-side consequences. A compromised container may remain unable to escape the VM while still serving hostile code into Prism, phishing the user, persisting through a service worker, abusing redirects, exhausting storage, or targeting shell mediation and agent automation.

Silent dependencies include:

• Route-table schema versioning and mixed-version peer behavior.
• Hostname allocation and app identity.
• Workerd path normalization, header rewriting, redirect handling, cache behavior, WebSocket upgrades, streaming, range requests, and upload limits.
• Cookie Domain, SameSite, CSP, COOP/COEP, CORS, and frame policy.
• Engine lifecycle, socket ownership, readiness, restart behavior, and per-app endpoint authorization.
• Controlled-Frame permissions and storage partitioning.
• Peer forwarding and whether dynamic responses can still be described as byte-identical or content-addressed.
• Service-worker and browser-cache invalidation during app updates.
• Offline notices, health pages, and whether platform-generated failures can be distinguished from application responses.
• Router privacy policy versus the diagnostics required for a live whole-origin proxy.

A distinct route kind is only the first step. It must have a separate policy implementation and validation path. If container-origin merely dispatches to the same permissive proxy with a different string tag, the distinction is cosmetic.

The wrong decision will be discovered late when a real application uses nontrivial redirects, OAuth callbacks, WebSockets, streaming, large uploads, range requests, service workers, or unusual cookie and CSP behavior. Security failures will appear later still, after path-encoding, redirect, header-smuggling, and hostile-container tests. By then the route schema may already be synchronized across devices and embedded in catalog records.

d/104: catalog-resolved Controlled-Frame guest launch

The proposal is not ratifiable as written. “App label → plane origin” makes a mutable display label a security principal and turns mutable catalog/runtime state into Prism’s navigation authority.

The existing baked URL is inflexible, but it binds guest selection to the installed IWA artifact. Runtime resolution moves that boundary into the catalog, installed-app database, router generator, sync layer, and resolver API. A compromise, rollback, collision, or inconsistent update in any of those components can redirect a privileged shell toward a different guest while retaining grants associated with the expected app.

The descriptor must use an immutable app_id and per-install instance_id, not a label. It must be versioned and bind at least:

• Catalog/publisher identity and artifact digest.
• Exact allowed scheme, host template, port policy, and route type.
• Expected frame and navigation policy.
• Allowed redirects, popups, downloads, and external-protocol launches.
• Required engine and wake behavior.
• Offline and source-unavailable behavior.
• Grant principal and audit identity.
• Descriptor expiry, revocation, rollback, and migration rules.

Prism must receive a resolved, authenticated launch capability—not an arbitrary URL—and grants must remain bound to the immutable app principal across hostname or port changes. Navigation after initial launch must also be constrained; validating only the first URL leaves redirects and guest-initiated navigation outside the boundary.

Silent dependencies include:

• Signed catalog schema and serial-anchor semantics.
• Unsigned personal-app installation policy.
• Catalog sync and stale-device behavior.
• Router-table atomicity: the descriptor and route must never disagree.
• IWA update caching and old Prism versions consuming new descriptors.
• App rename, uninstall, reinstall, catalog fork, and collision handling.
• d/081 generated wrappers, deep links, dock shortcuts, and protocol handlers.
• Permission caches, consent receipts, CDP targets, and journal identity.
• Android lifecycle behavior when the plane sleeps or the source peer disappears.
• Configurable ports, multiple Xe instances, and recovery after partial updates.

The wrong call will first appear as intermittent platform-specific launch failures, stale-cache behavior, or grants attached to the wrong guest after rename/reinstall. A malicious redirection or rollback would be found much later because the current success criterion—“Android renders the app in-frame”—does not test descriptor tampering, split-brain router state, downgraded catalogs, or navigation escape.

5. Questions missing from the Luke + Jan review agenda

1. What is the explicit threat model? Which attackers are in scope: hostile websites, malicious regular apps, compromised L3 apps, local unprivileged processes, hostile engine workloads, malicious peers, compromised catalogs, stolen devices, and compromised browser updates?

2. What is the trusted computing base for each security claim? Which exact components must be correct for origin isolation, engine containment, launch resolution, delegation, and audit integrity?

3. How is the entire 127.0.0.1:5454 plane protected from hostile web pages and local processes? The wake channel is only one endpoint; Host-header validation, DNS rebinding, CSRF, browser Private Network Access, route enumeration, and unauthenticated management endpoints require a separate ruling.

4. What is the blast radius of a compromised Prism or Xenon update? An L3 shell hosting Controlled Frames and driving CDP can bypass ordinary app boundaries; what authority remains unavailable to it?

5. How are prompt injection and confused-deputy attacks handled when an agent reads hostile app content and then acts in another app? Origin isolation does not protect an agent that intentionally consumes both origins.

6. Which actions are reversible, compensatable, or irreversible? What consent rule applies to purchases, messages, data disclosure, remote deletion, and actions whose consequences cannot be undone?

7. What is the canonical app principal? How do rename, collision, reinstall, publisher-key rotation, catalog forks, and cross-device installation affect the origin, storage, grants, and audit history?

8. Who may change a launch descriptor, and how is that change authenticated and made atomic with routing state? What happens during rollback, expiry, partial update, or disagreement between peers?

9. What is the catalog-governance model after the initial key ceremony? Scheduling a ceremony does not answer publisher delegation, user-selected roots, multiple catalogs, key compromise, emergency revocation, threshold recovery, or succession if Luke and Jan are unavailable.

10. How are device keys enrolled, rotated, recovered, and revoked? What happens when a phone is stolen, a disk is cloned, a removed peer returns with stale state, or two restored backups present the same device identity?

11. What is the actual L1 compatibility envelope? Which CSP, OAuth, WebAuthn, service-worker, cookie, WebSocket, TLS, backend, framing, and storage patterns are supported without source changes, and what representative application corpus gates the claim?

12. What is the browser-fork sustainability plan? Who tracks Chromium security releases, how quickly must Xenon rebase, what is the emergency patch SLA, and what happens if Controlled Frame or IWA behavior changes upstream?

13. What is the fallback if Controlled Frame remains unavailable on iOS or changes incompatibly on Chromium? The architecture currently treats a vendor-specific browser surface as a universal platform primitive.

14. What does the VM isolation class guarantee? What are the engine’s network-egress policy, resource quotas, filesystem mounts, socket credentials, host integration, patch policy, and response to a backend escape?

15. How does Xe recover from corrupt or malicious synchronized metadata? Serial anchors do not solve conflicting updates, tombstones, rollback from restored backups, journal divergence, poisoned route records, or lost encryption keys.

16. How are audit records protected from the audit system itself becoming a surveillance archive? The journal may contain prompts, correspondence, purchase details, credentials, and cross-app observations; encryption, retention, redaction, selective export, and access control are unspecified.

17. What are the atomic update and rollback rules across catalog, router, Prism, engine, and peer schemas? “Higher decision number wins” provides no operational answer for mixed versions or crashes between activation steps.

18. What happens when dependencies are unavailable for days rather than seconds? The design needs behavior for relay outage, catalog outage, home-device loss, expired metadata, exhausted disk, engine crash loops, port collision, and unavailable browser updates.

19. What evidence is required before a property is called proven? Functional rendering, byte equality, containment, authenticity, rollback resistance, offline recovery, and audit completeness need separate test claims and independently reproducible evidence.

20. What makes the project forkable beyond source availability? Licensing, protocol governance, conformance suites, trademark policy, catalog federation, reproducible builds, and migration away from the operator’s forge and keys are not defined.

21. What is the adoption path for application developers and ordinary users? The current path requires a local runtime, router, browser flags or an unbuilt browser fork, catalog metadata, and possibly an engine. The design does not state which existing app classes work immediately or why developers would target Xe-specific capabilities.

22. What operational metrics are permitted? Router privacy forbids per-request logging while debugging whole-origin proxying and agent actions requires evidence. The review must decide what can be observed, by whom, for how long, and with what user control.

SOLREV-MISSION-DONE