Loomworks — seed model (versioning, revision, viewer, corrections-preserved) — grounding inspection — v0.1

Document: loomworks-seed-model-grounding-inspection-v0_1 Version: v0.1 Status: grounding inspection — read-only, no build. Findings for scoping a post-creation seed-revision capability (the "seed editor") and its prerequisite seed viewer. Date: 2026-06-28 Scope: Whether a seed is first-class versioned in the substrate; whether any post-creation seed-revise path exists; whether the Operator can view a committed seed; whether revision is corrections-preserved (version-bump-and-retain vs overwrite); and whether the create-time seed-conversation routes can be reused to drive a revision.

Anchors (verified against live repos):

• Engine main 5ccc3d7
• Operator-Layer (OL) feat-companion-surface HEAD dac9fec

Headline: the substrate is already fully ready — seeds are first-class versioned, corrections-preserved is automatic, and a post-creation revise path even exists (Phase 6, via considerations). What's missing for a seed editor is the surface and the driver, not the substrate. The committed seed has no viewer post-creation, which is the binding prerequisite.

a. Seed versioning — first-class versioned, priors retained

Yes. Seeds are event-sourced in the memory_events table (one immutable row per version):

• object_id (stable seed id), object_version (≥1, increments per revision), object_type='seed', payload JSONB (the full Seed), event_kind ∈ {seed_drafted, seed_amended, seed_revised}. UNIQUE(object_id, object_version) — migration 0001_phase_1_substrate_events.py:44-89; ORM memory/events.py:67-111.
• Current-version pointer: Engagement.seed_ref: MemoryRef (id + version) — engagement/types.py:62, commented "version-pinned at commit_engagement; re-pointed on seed amendment (Phase 6)." The engine identifies the active seed by reading the current Engagement version and following its seed_ref.
• Read path (internal): get_current_seed(engagement_id, db) — engagement/seed_lookup.py:168-198 (→ _load_seed_by_ref :90-128), used in context loading at prompt.py:298 (_load_tier_1). Phase-43 fallback: tries the ADMINISTRATIVE engagement first, then the engagement itself.

Verdict: version-capable end-to-end, not create-time-only. Every amendment from draft onward is a retained, numbered version in the event log.

b. Post-creation edit path — exists, but only through the considerations apparatus

Yes — but not as a direct "edit seed" route. Revision flows through the Phase 6 considerations framework:

• POST /engagements/{eid}/considerations/{cid}/close with terminal_state="amend" + a Seed in scope → _close_seed_amend (engagement/considerations.py:1328-1336) → revise_seed (engagement/creation.py:273-295).
• The Operator opens a contributor_initiated consideration pinning the seed, deliberates, then closes it with amended_seed_fields. There is no dedicated PUT/PATCH /seed revise endpoint, no Companion intent (the IntentLabel enum classifier.py:48-119 has no revise_seed/amend_seed/edit_seed — only request_revision, which is for drafts/artifacts, not seeds), and no frontend for it.

Verdict: the post-creation revise capability is real and substrate-correct, but it's reachable only via the raw considerations machinery — no friendly route, no conversational driver, no surface.

c. Seed read/display — no viewer post-creation (the binding gap)

Frontend: No. The seed is visible only during creation via DraftSpecification.tsx:5-7 ("the live seed document the Companion has been co-authoring"), used in ChatView.tsx:517 during drafting. After commit, the in-engagement surface (Memory/Manifestation/Shaping/Rendering rooms) shows no seed anywhere; InEngagementHeader.tsx:89-123 renders only the title + identifier. seed_id is on the wire (projects.ts:22) but never fetched or exported — no fetchSeed/getSeed client method exists, and ProjectSummary (types.ts:312-315) carries no seed fields.

⚠️ Engine-side caveat to confirm: the read function get_current_seed exists, but no HTTP GET-seed endpoint consumed by the frontend was found — the function is used internally for prompt context, not exposed as a route. A viewer likely needs a thin GET …/seed endpoint wrapping get_current_seed, plus a client method + component. (Worth a direct confirm before scoping the viewer — captured as the open item in loomworks-seed-viewer-scoping-note-v0_1.)

Verdict: the Operator cannot view a committed seed today. A seed editor needs a seed viewer first — and probably a read endpoint to feed it.

d. Corrections-preserved — already structural, automatic

Yes — version-bump-and-retain, never overwrite. Every seed revision is an append_event INSERT with the same id, version+1, and a wasRevisionOf relationship to the prior version: amend_candidate_seed (creation.py:184/194), revise_seed (:275/:281), mark_seed_divergent (:354/:360). On commit the seed is relocated (moved, not copied) from the commons to the engagement, preserving all versions (creation.py:960-966; "founding stays v1, amendment chain increments unchanged").

Verdict: corrections-preserved is guaranteed by the event-sourced substrate. A seed editor inherits it for free — there is no overwrite risk to design around.

e. Seed-conversation reuse — create-bound (blocked on active engagements)

Create-bound. The create-time routes (POST …/seed, …/seed/induct, …/seed/converse/commit) all guard via _load_candidate_seed → 409 CONFLICT if state != "candidate" (engagements.py:181-185). They cannot run on an active engagement. The post-creation revise path is a different mechanism (considerations → revise_seed), not these routes.

Verdict: "tell the Companion 'make the voice warmer' → it proposes a new seed version" via the same create routes is blocked today. The revision substrate exists but behind a different door, with no conversational driver.

What a Seed Editor would need (scoping synthesis, no build)

The substrate is done. Three buildable layers, in dependency order:

1. Seed viewer (prerequisite). Surface the committed seed in the in-engagement view — a panel or an "About/Foundation" view. Likely needs a thin GET …/seed endpoint over get_current_seed (confirm one doesn't already exist), a fetchSeed client method, and a display component. This is the unambiguous first step — you can't edit what you can't see. Scoped separately in loomworks-seed-viewer-scoping-note-v0_1.

1. A revision driver — two forks:

• Fork A (reuse Phase 6): wrap the existing revise_seed-via-considerations machinery in a friendly surface (and/or a new Companion intent that opens→closes the consideration with amended_seed_fields). Substrate-correct, corrections-preserved, already built — lowest risk.
• Fork B (generalize create routes): lift the candidate-only 409 guard so seed/converse/commit can run on an active engagement and route through revise_seed (not a fresh draft). More reuse of the conversational UX, but touches the create-bound guards and must be careful to land on the corrections-preserved path.
• Lean: Fork A for the substrate path, with Fork B's conversational UX layered on top — a "change the seed" Companion intent that proposes amended_seed_fields and drives the consideration close. That keeps the version-bump-and-retain guarantee intact while giving the Operator the conversational "make the voice warmer" experience.

1. An edit intent + authority gate. No revise_seed intent exists; seed editing is an Operator-authority act, so it slots naturally onto the same human-approval pattern as held→commit (the Operator approves the new seed version). This is the same "structure the authority gate in code" instinct as the add-side commit-gate move.

Two clean observations for sequencing: the substrate work is zero (versioning + corrections-preserved + a revise function all exist); the cost is entirely surface + driver. And the viewer (§c) is both the cheapest piece and a hard prerequisite — it's the natural first ship even before the editor is scoped.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — seed model (versioning, revision, viewer, corrections-preserved) — grounding inspection — v0.1 — 2026-06-28 Net: seeds are first-class versioned and corrections-preserved automatically; a post-creation revise path already exists (Phase 6 via considerations) but with no friendly route, no Companion intent, and no surface; the committed seed has no viewer post-creation (the binding prerequisite); the create-time seed-conversation routes are create-bound (409 on active). The seed editor is surface + driver, not substrate. SHAs verified against live repos.