Loomworks — seed viewer — scoping note — v0.1

Document: loomworks-seed-viewer-scoping-note-v0_1 Version: v0.1 Status: scoping note — precedes a CR. Shape settled below; one engine fact to confirm at CR drafting (whether a read endpoint exists). Grounded in loomworks-seed-model-grounding-inspection-v0_1 (the seed-model strand). Date: 2026-06-28 Origin: Surfaced while grounding the seed editor. After an engagement is active, the Operator cannot see its committed seed anywhere on the surface — the seed is visible only during creation (the live draft the Companion co-authors), then disappears from the in-engagement view. You can't edit (or carry, or refer back to) a seed you can't see. Why this is first: the seed viewer is a hard prerequisite shared by three directions — the seed editor (you can't edit what you can't see), the Example-Generator → create integration (its payoff is "here's your seed"), and create itself (the create conversation builds a seed the Operator then loses sight of). It is the cheapest of the seed-related pieces and unblocks the most downstream.

Plain-language summary

When you create an engagement, the Companion builds a seed with you and you watch it take shape. After you commit, that seed vanishes from view — the in-engagement screen shows the four rooms and the title, but nowhere to see the engagement's own foundation document. This adds a way to view the committed seed: what the work is, who it's for, the voice, the constraints, the success conditions — the engagement's commitments, readable at any time. View only — no editing in this piece (that's the seed editor, which builds on this). Mostly surfacing something the engine already holds.

What's true today (from the grounding inspection)

The seed substrate is fully built; the gap is purely surface:

• Seeds are first-class versioned and retained. Event-sourced in memory_events — one immutable row per version (object_id stable, object_version increments, object_type='seed', full Seed in the payload). The active seed is found via Engagement.seed_ref (a version-pinned pointer). Corrections-preserved is automatic — every revision is append-with-version-bump, never overwrite.
• A read function exists internally. get_current_seed(engagement_id, db) (engagement/seed_lookup.py) reads the active seed — but it is used for prompt context loading, not exposed as an HTTP route (the inspection's flagged caveat; see open item).
• The seed is shown ONLY during creation. DraftSpecification.tsx renders the live seed the Companion co-authors, used in ChatView during drafting. After commit, nothing on the in-engagement surface shows it: InEngagementHeader renders only title + identifier; seed_id is on the wire (projects.ts) but never fetched; ProjectSummary carries no seed fields; no fetchSeed/getSeed client method exists.

The gap: the committed seed has no viewer. The data is held, versioned, and readable internally — it just never reaches the Operator after creation.

Seed alignment

Directly aligned. The seed is the foundation document — it names what the engagement is committed to. An Operator running an engagement should be able to see its commitments; the seed governs the work, and working against commitments you can't see is the surface hiding the most foundational thing the engagement holds. "Only show what is available" applies — the seed is available (held and readable); its absence from the surface is the surface failing to show it. Showing the seed read-only also respects Operator-authority cleanly: viewing changes nothing, so there's no state-transition concern in this piece (that arrives with the editor).

Shape (settled, one engine fact to confirm)

A read-only view of the active engagement's committed seed, reachable from the in-engagement surface.

• What it shows: the committed seed's fields in plain terms — what the work is, who consumes it, the voice, the constraints, the success conditions (the canonical R-A5..R-A11 fields, in Operator-facing language, not codebase keys). Plain-terms discipline applies — methodology nouns in plain English.
• Version awareness: the seed is versioned; the viewer shows the current version, and (lean) names which version it is (e.g. "Foundation document — version 3"). Whether the viewer also shows version history (the trajectory of prior versions, corrections-preserved made visible) is a refinement — lean: current-version only in this first piece; history is a natural follow-on that pairs with the editor (since editing is what produces new versions worth browsing).
• Where it lives: reachable from the in-engagement view. Lean: a dedicated view/panel reached from the in-engagement header (which today shows only title + identifier — the natural "about this engagement" location), rather than crammed into a room (the seed is not a room, same category care as the mobile Companion). Confirm placement against the real header/surface at CR time.
• Read-only: no editing in this piece. The viewer is the editor's prerequisite, not the editor.

The one open item — confirm at CR drafting (engine fact)

The inspection found get_current_seed internally but no HTTP GET-seed route consumed by the frontend, and flagged it for direct confirmation. This decides the CR's size:

• If no read route exists (likely): the CR is frontend + a thin engine endpoint — a GET …/seed wrapping get_current_seed, returning the current seed (fields + version), plus a fetchSeed client method + a display component.
• If a read route already exists: the CR is frontend-only — client method + component over the existing route.

Either way the substrate (versioning, retention, the read function) is done; the question is only whether the read is already exposed. CR Step 0 confirms this against the live engine before drafting executable steps. Lean assumption for planning: a thin endpoint is needed (the smaller-surprise direction — easier to drop a planned endpoint than to discover a missing one mid-build).

What this reuses (so it's not a rebuild)

• The seed read logic exists (get_current_seed) — the endpoint (if needed) wraps it, doesn't reimplement it.
• The seed shape is defined (the R-A5..R-A11 contract) — the viewer renders known fields.
• DraftSpecification.tsx already renders a seed during creation — the committed-seed viewer can reuse or adapt that rendering rather than build a fresh seed-display component (confirm at CR whether it's reusable for the committed read or create-bound).

Scope boundary — what this does NOT include

• No editing. Read-only. The seed editor (conversational-first revision, on the built revise_seed/considerations machinery) is the next piece and depends on this one.
• No version history browser (lean) — current version only; history pairs with the editor.
• No generator integration — that's its own direction; this viewer is a prerequisite it will use, not part of it.

Sequencing

After create-restore (or alongside — both are "surface what exists end-to-end" and both touch the in-engagement / home surface). Prerequisite for the seed editor and a building block for the generator integration. Frontend (+ likely a thin engine read endpoint). Ships on the Operator-Layer feat-companion-surface branch (with the engine endpoint on engine main if needed).

Operator decisions before a CR

1. Confirm the shape: a read-only view of the committed seed (fields in plain terms, current version), reached from the in-engagement header. (Settled — this note's basis; confirm.)
2. Current-version only (lean) vs. include version history in this first piece?
3. Confirm read-only scope — editing is the separate seed-editor piece that builds on this.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — seed viewer — scoping note — v0.1 — 2026-06-28 After commit, an engagement's seed is invisible on the surface though the engine holds it, versioned and readable. This adds a read-only viewer of the committed seed (fields in plain terms, current version) reached from the in-engagement header. Likely frontend + a thin GET-seed endpoint (confirm at CR). Read-only — the prerequisite for the seed editor and a building block for the generator integration.