Spike: hosted control plane boundary and local-first guarantees

[burakdede]

Parent epic: #8 (post-v0.1 backlog)

Context

§22.2 describes the future paid platform (managed build registry, hosted deployment, team projects, OAuth/SSO, audit logs, analytics, policy controls) and §22.3 sets the constraint that binds it: the open package format and local runtime must prevent lock-in, so users can always export a .lorepack and run it elsewhere. §4.2 adds that the hosted product sells operational convenience, never access to a deliberately crippled core.

Post-v0.1. Recorded here so the boundary is designed deliberately rather than discovered later.

Spec references

§22.1 Apache-2.0 open source, §22.2 Future paid platform, §22.3 Trust boundary, §4.2 Local-first means complete.

Scope

In: a design spike defining the hosted control plane's boundary: what it stores, what it adds, and how the local-first guarantees are preserved and provable.
Out: building any hosted service.

Design notes

• The design must be falsifiable: state the exact test that proves a user can leave, export a .lorepack from the hosted registry and run it locally with identical behavior.
• Team permissions and OAuth (§22.2) intersect with the source-permission synchronization that §5.2 deferred; the spike should identify what must be true in the core before that is possible.
• Nothing in the hosted design may require changing the open build format in a way that reduces local capability (§4.2).

Acceptance criteria

• Document defining the hosted control plane's responsibilities and its interface with the open-source core.
• Explicit list of guarantees that must remain true for local users, each with the test that proves it (notably the §22.3 export-and-run-locally test).
• Analysis of team permissions, OAuth/SSO, and audit logging requirements and what core changes they imply.
• Statement of what will never be moved behind the paid boundary (§4.2's complete local workflow).
• Recommendation on sequencing relative to open-source roadmap items.
• Recorded as an ADR entry (§23) with follow-up issues or an explicit deferral.

Tests / verification

• No implementation; the deliverable is a reviewed design document and ADR entry.

Dependencies

Blocked by the v0.1 release (#102).

Definition of Done

The commercial boundary is written down with testable local-first guarantees before any hosted work begins.