Project boundaries

The logical organization is Platform, Integrations, UI, Domain and Applications. The repository now uses those five top-level folders; packages retain their public names. Separate repositories have not been created. The main Next application is applications/main, not the orchestration root. See the current status and handoff checklist for what is done, unfinished, unverified and required before review or rollout.

Ownership groups

Arrows show code dependency direction, not provider plugins loaded by the executor. Applications compile their library definitions into closed data before execution.

flowchart TD
  subgraph A[Applications]
    O[Operational application definitions + configuration]
    S[Spell bespoke frontend]
    R[Allocation Risk bespoke frontend]
    H[Deployment host + operator console]
  end
  U[UI: configurable generic frontend]
  P[Platform: SDK + executor, API, storage, headless clients]
  I[Integrations: provider templates]
  D[Domain: inspectable definitions]
  O --> U
  O --> I
  O --> D
  S --> P
  R --> P
  U --> P
  H --> S
  H --> R
  H --> U
  H --> P
  I --> D
  I --> P
  D --> P

Platform has no dependency on the other four groups. Forms currently retains shared validation/value semantics plus some presentation helpers; a further UI split is deliberately deferred rather than creating a Platform-to-UI dependency now.

Internal workspace inventory

The following are internal build artifacts, not separate ownership concepts.

architecture.json is the enforced dependency graph. Each workspace has explicit package exports, dependencies, build/typecheck/tests and inherited ownership instructions. Cross-project source imports, private package paths, undeclared dependencies, reverse dependencies and cycles are rejected. Consumers scan installed UI output for Tailwind, not sibling source. Runtime object identity in the generic frontend is fixed per mount: explicitly change the provider key to replace the environment and discard in-progress form state.

Spell and Allocation Risk own their renderers, visual session controls, complete screens and app policy. They do not depend on the generic frontend. Main's compatibility routes select whole frontends, not arbitrary page/component overrides disguised as skins. The old profile registry has been removed. Headless session/transport and field-value semantics remain shareable Platform APIs.

Each operational workflow has its own generic application identity, including newly published templates. Skins contain only palette, spacing, fixed layout and logo references. Applications are view identities, not new security tenants: existing permissions and process sharing remain authoritative. Addresses are deployment configuration, independent of frontend implementation. The operator console remains separate and legacy deep links still work. See frontend ownership.

Independent-consumer proof

npm run verify:spell builds spell-owned source outside this repository using packed upstream artifacts, then runs it on its own origin against the separately running backend and controlled worker. Upstream sources and workspace symlinks are absent. Both this deployment and the main deployment run the same browser regression suite.

The app's API adapter accepts one configured HTTP(S) backend origin, streams request bodies, preserves authorization/status responses, does not follow upstream redirects, and maps backend-local redirects back into the frontend. It has a two-minute upstream deadline combined with request cancellation. This is a trusted deployment adapter, not an arbitrary URL proxy, authorization substitute or new security isolation boundary.

Remaining architectural work

• Continue shrinking the main application composition. Headless browser sessions and create/share sequencing are shared; visual controls belong to each frontend; app-specific membership/role policy stays explicit. HTTP handlers, Auth0 adapter and record/export services now live in the independent backend project; main application routes mount those public handlers.
• Keep the single browser session adapter and generic create/share mechanism independently tested. Applications explicitly choose sharing participants/roles; those choices may diverge.
• Exercise representative intended spell extensions, including app-owned event/polling and projection behavior, through public interfaces. The initial intake journey alone does not prove all future requirements are supported.
• Validate production OAuth callback/origin configuration separately. Synthetic fixtures do not prove real tenant invitations, org selection or login redirect portability.
• Add targeted upload, export, concurrent-storage and adapter-failure journeys, and establish per-project coverage ratchets from the new baselines.
• Only split repositories after these boundaries and release/compatibility contracts are proven. The folder move does not establish independent release compatibility on its own.

Preserve guarantees actually provided by the existing system. Previously unfulfilled claims remain explicit component roadmap work unless naturally solved by a boundary change. Do not infer immutable audit history, organization data isolation, historical reconstruction or verified retention from the passing regression suite.

Backend boundary verification

Packed Platform consumers exercise validated programs, canonical aggregates, interactions, revisioned persistence and generic effects without installing Integrations, Domain or Applications. The SDK proof checks typed immutable composition and generic fields, not removed provider unions. Application registries compile libraries to data before the executor sees them.

No runtime handler registration restores the old extension mechanism. Operational grants bind immutable execution authority; presentation edits are versioned separately. The full independent application/browser lanes passed on the post-layout code; future changes must rerun them rather than inherit an older proof.

Independently provisioned HTTP backend

platform/backend builds without installing the spell application package. It has no shipped workflow registry; trusted startup JSON supplies compiled registrations, capabilities and relative document assets as data. Generic route/service factories receive explicit ports, while the main application composition preserves its existing templates, assets and CORS default. The backend's default CORS origin set is empty; configure it explicitly for direct cross-origin consumers.

The independent verification lane first confirms empty compiled startup, then provisions the existing definitions/assets and exercises compiled API checks plus a separately built spell frontend and controlled worker. Tests now include Edge preflight, invalid credentials, attachment-reference/access checks, audit-only exports and local OAuth error redirects. The loopback proxy mapping handles Next's localhost normalization only at the configured protocol/port. None of this verifies a real Auth0 exchange or changes deployed configuration.

Application capability checks

Spell capability probes distinguish app-owned implementation work from generic API gaps and unresolved product policy. The independent lane now tests summary/metadata/graph authoring, Q/A, permitted cycle-date edits, denied manager-only edits and private app notes against public identity/process APIs. None enables unfinished UI.

Five-group ownership

Platform owns Contracts/SDK, Expressions, Runtime, Storage and generic client/form/document primitives; it cannot import Domain or Integrations. Integrations may compose public Domain protocol definitions, never app policy. UI owns the generic frontend product. Applications own bespoke rendering, editor metadata, graph source, concrete workflows, skin configuration and deployment bindings. Generic authoring fields remain Platform-owned; provider configuration and the app graph do not.

The generic/bespoke ownership split is now the implementation target. See deployment bindings for capability configuration rather than source ownership.