DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path investigations/loomworks-engine-boundary-inventory-v0_1.md

Loomworks — Engine boundary inventory & assessment

Version. 0.1 Date. 2026-06-03 Provenance. Engine-source trace, Operator: Marvin Percival. Steps up from the seed-creation investigations to the whole engine/wrapper boundary: what the engine's surface actually is today, and how far it is from an architecture-enforced API any foreign wrapper could talk to. Status. Investigation / inventory + assessment. Report-only — no design, no proposal, no engine changes. Reads with (the seed/boundary set).

Code citations. engine: = the loomworks-engine repo; OL: = the loomworks (operator-layer frontend) repo. Line numbers indicative, names load-bearing.


Decisive finding

There is no single engine boundary — there are two, because "the Companion" is two things:

So the boundary is enforced by architecture for the UI, and by discipline only for the brain — which sits inside and uses privileged shortcuts no external surface has.

1. What the engine exposes, and how

One FastAPI app, create_app() (engine: api/app.py:390, title="Loomworks", version=LOOMWORKS_VERSION — the package version, not an API contract). It mounts ~50 routers / ~197 HTTP routes flat (app.py:667-785), spanning the full domain (engagements, seed_view, seed_conversation, seed_extraction, seed_commit_from_brief, me_create_engagement, manifestations, shapings, renders, considerations, assertions, contributions, files, me/*, dashboard, workspaces, tags, auth, credits) — and the orchestration /operator/converse router mounted as a peer.

Reachability tiers:

2. How the Companion reaches the engine

A mix, not a uniform API client:

There is no uniform engine API the Companion is a client of.

3. The inconsistencies

4. Is there a deliberate, versioned, complete "engine API"?

No. No version prefix or contract version (grep for /v1, api_version, /api/v returns nothing); the only "version" is LOOMWORKS_VERSION on the app title (app.py:393) — the software version. ~197 routes grown phase-by-phase, mounted flat; the orchestration router is just another include_router peer; OpenAPI exists only as FastAPI's auto-generation, not a governed published contract. No code construct or doc asserts "this is the engine API, complete and versioned."

5. Assessment — distance to "one clean API, no privileged back doors"

Already API-shaped (partly done): a real, configurable HTTP boundary exists and is consumed by a wrapper (the frontend over NEXT_PUBLIC_API_URL). Not greenfield. Auth deps gate routes; the domain CRUD is genuinely externally reachable.

Welded / privileged (the gap): the Companion's brain is a co-resident insider, not a client — it bypasses the surface a foreign wrapper must use, with auth/billing shortcuts unavailable externally; so the route surface is not complete or parity-true. Phase 31 extraction is welded; wrapper-specific shapes bake one caller into engine code.

Missing: any versioned, governed, complete contract; any guarantee that everything a wrapper needs is reachable through public routes with no insider shortcut; parity between in-process-brain capability and HTTP-surface capability.

Answering Marvin's framing question: the boundary is enforced by discipline plus a partial physical HTTP boundary (the UI), but not by architecture — the brain reaches in from inside and uses privileged back doors. "Give the engine an API" is therefore two different-sized things:

  1. Formalizing/completing what's implicitly there — versioning/governing the route surface, removing wrapper-specific projections, ensuring completeness. Moderate; much HTTP plumbing exists.
  2. Building genuine architectural enforcement — relocating the brain to be a client of that surface, closing the in-process back doors (_check=None/_internal_delegation auth-and-billing skips, direct-handler calls, welded extraction). The real boundary-enforcement project, and what the standing note's "engine must survive any wrapper" actually demands.

Short version: a network boundary exists and one wrapper (the UI) respects it; the other wrapper (the brain) lives inside and bypasses it. The distance to architecture-enforcement is the distance of moving the brain out and closing those shortcuts — not of inventing an HTTP boundary from scratch.


Investigation / inventory only. No engine or wrapper code changed. No API designed or proposed. Filed in loomworks-record/investigations/. Pairs with the seed-creation map, the three-paths deep-dive, the engine-contract doc, and standing-notes/loomworks-standing-note-engine-wrapper-boundary-v0_1.md (the lens).