DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path phases/phase-18-manifestation-room-ui/phase-18-cr-manifestation-room-ui-v0_1.md

DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-032 — Phase 18: Manifestation Room UI (v0.1)

Version. 0.1 Date. 2026-04-27 Author. Marvin Percival (DUNIN7), prepared via Claude. Target. /Users/dunin7/loomworks-ui (frontend) on DUNIN7-M4 (MacMini). Substrate unchanged. Priority. Standard. Confidential. Internal. Supersedes. Nothing for Phase 18 specifically. Companion to. Phase 18 scoping note v0.1, Phase 11 CR v0.1 (Manifestation substrate), Phase 12 CR v0.1 (memory-status substrate), Phase 16 CR v0.1 (Memory room and room switcher), methodology v0.18, brand guide v0.15. Status. First draft. Consumes six settled scoping decisions (S1–S6). Frontend-only phase — no substrate changes, no migrations, no new substrate tests. The substrate endpoints (Phase 11 Manifestation operations, Phase 12 memory-status and downstream-impact queries) are already built and tested.


Contents


1. Executive summary

Phase 18 builds the Manifestation room — the second methodology room in the UI. The room shows the Operator the current state of the engagement's snapshot of Memory, how much Memory has moved since that snapshot, and what downstream work depends on it. The Operator's primary action is deriving a new Manifestation when Memory has accumulated enough to warrant one.

This is a frontend-only phase. The substrate endpoints exist (Phase 11 for Manifestation operations, Phase 12 for memory-status and downstream-impact queries). Phase 18 surfaces them through the product UI. No substrate code changes, no migrations, no new substrate tests.

The work has five components: the room page with three display sections (Manifestation summary, memory-status delta, downstream dependency), the two-step derive flow (preview + confirmation modal), the Manifestation history timeline, the room-switcher and lobby wiring, and the frontend API proxy routes.


2. Grounding

Layer 1 — Methodology document v0.18. The four-step pipeline (Memory → Manifestation → Shaping → Render) is the methodology's core. The Manifestation room is the Operator's interface to the second step. The Operator decides when Memory is ready to be snapshotted; the system never derives automatically.

Layer 2 — Reference Design v0.1.2. S-1 (journey is information): the Manifestation room shows derivation history and provenance. S-3 (the comprehensive manifestation): the Manifestation captures all of Memory at a point in time; the room shows what that capture contains.

Layer 3 — Playground Specification v0.10. The Manifestation room is a UI surface over Sec-C.1 (Manifestation derivation) and Sec-C.2 (memory-status queries).


3. Prerequisites

3.1 Baseline

3.2 Pre-flight checks

CC confirms before Step 1:

  1. Frontend repo is at the Phase 17 tag. npm run lint && npx tsc --noEmit && npm run build passes clean.
  2. Substrate is running at localhost:8000.
  3. The following substrate endpoints exist and respond (confirmed via curl or equivalent):
  1. The RoomSwitcher component exists in the frontend with four entries. The Manifestation entry currently shows a count but is not clickable.
  2. The EngagementRoomLayout shared component wraps room pages.
  3. The /engagement/[id]/memory page is the structural reference for the new Manifestation page.

Endpoint path note. The exact substrate endpoint paths may differ from what this CR names. Phase 11 and Phase 12 CRs specify the endpoints; CC may have implemented them under slightly different paths. Pre-flight confirms the actual paths, and the frontend proxy routes (Section 12) are wired to match. If any endpoint is missing or returns unexpected shapes, stop and reconcile before Step 1.

3.3 CR archival

Archive this CR to docs/phase-crs/phase-18-cr-manifestation-room-ui-v0_1.md at Step 0 before Step 1 begins.


4. The Manifestation room page

4.1 Route and structure

Page at /engagement/[id]/manifestation. Wrapped in EngagementRoomLayout (same as Memory room). Environment tint: env-manifestation (#DCE3DB, muted green).

4.2 Page header

Room header: "Manifestation" in {typography.h2}. Below the header, a subtitle in {typography.body} with {colors.ink-faint}:

> A snapshot of Memory at a moment in time. Downstream work — Shaping, Rendering — builds against this snapshot.

4.3 Conditional rendering

The page has two modes based on whether a current Manifestation exists:

The page fetches the current Manifestation on load. If the response indicates no Manifestation exists, render the empty state.


5. Empty state — no Manifestation

When no Manifestation exists for the engagement, the room shows:

A card ({components.card}) centered in the room content area containing:

> Memory is accumulating but no Manifestation has been derived yet. A Manifestation captures Memory at this moment so that downstream work — Shaping and Rendering — has a stable foundation to build against.


6. Current Manifestation view — summary section

When a current Manifestation exists, the top section of the room shows the Manifestation's summary as a card ({components.card}):

Manifestation version. "Version [N]" in {typography.h3}.

Summary facts in a two-column layout:

| Label | Value | |-------|-------| | Derived at | Timestamp (relative, absolute on hover) | | Derived by | Person name | | Memory version captured | Engagement-version at derivation | | Assertions | Count at derivation | | Relationships | Count at derivation | | Seed version | Version in force at derivation |

Labels in {typography.caption} with {colors.ink-faint}. Values in {typography.body}.

State badge. "Current" with {colors.state-attest} dot, or "Superseded" with {colors.ink-faint} dot (for history items — Section 10).

Re-derive action. A "Re-derive Manifestation" secondary button ({components.button-secondary}) below the summary. Clicking it starts the two-step derive flow (Section 9). The button label changes to "Derive Manifestation" in the empty state.


7. Memory-status delta display

Below the Manifestation summary, a delta section shows what has changed in Memory since the derivation. This section calls the memory-status endpoint.

7.1 Memory is current (no changes)

A single line in {typography.body}:

> Memory has not changed since this Manifestation was derived.

No categorized counts. No action needed.

7.2 Memory has changed

A card ({components.card}) with a subtle {colors.vellum} background (signaling attention):

Header. "Memory has changed" in {typography.body-em}.

Categorized counts. Each non-zero category as a line:

Displayed in {typography.body}. Zero-count categories are omitted.

Summary line. "Memory is at version [current] (Manifestation was derived at version [at-derivation])." In {typography.caption} with {colors.ink-faint}.

Re-derive prompt. Below the counts: "Re-derive the Manifestation to capture these changes." Not a button — the re-derive button is on the Manifestation summary section above. This is a contextual nudge, not a second action point.


8. Downstream dependency summary

Below the delta section, a downstream dependency section shows what Shapings, Shapes, and Renders depend on the current Manifestation. This section calls the downstream-impact endpoint.

8.1 No downstream work

A single line in {typography.body}:

> No Shapings have run against this Manifestation yet.

8.2 Downstream work exists

A list of Shaping summary cards. Each card ({components.card}) shows:

Cards are non-interactive in Phase 18 — no links to the Shaping room (the Shaping room does not exist yet). When the Shaping room is built in a future phase, these cards become links. Per "only show what is available": no disabled links, no "coming soon" treatment. Just cards with information.

Section header. "Downstream work" in {typography.body-em}.


9. Two-step derive flow

9.1 Step 1 — Preview

When the Operator clicks "Derive Manifestation" (or "Re-derive Manifestation"), the system calls the Manifestation preview endpoint. The response returns: the current engagement-version, assertion count, relationship count, seed version — what the new Manifestation would capture.

A modal opens (standard modal treatment from the brand guide).

Modal content:

9.2 Step 2 — Confirm

Modal actions:

After derivation: The room state updates. The Manifestation summary shows the new version. The delta section shows "Memory has not changed." The history timeline (Section 10) gains the prior Manifestation as a superseded entry.


10. Manifestation history timeline

Below the main content sections, a collapsible history section shows prior (superseded) Manifestations.

10.1 Toggle

"Show history · [N] prior versions" as a ghost button or text link. Clicking it expands the section. "Hide history" collapses it.

If there are no prior versions (the current Manifestation is the first), the toggle does not appear.

10.2 Timeline list

Each superseded Manifestation is rendered as a compact card with:

Ordered newest-first (most recently superseded at top). The current Manifestation is not in this list — it appears in the main summary section (Section 6).


11. Room switcher and lobby wiring

11.1 Room switcher

The RoomSwitcher component currently shows four entries. The Manifestation entry shows a count but is not clickable. Phase 18 makes it clickable: the entry becomes a link to /engagement/[id]/manifestation.

The count displayed on the Manifestation room switcher entry is the current Manifestation's version number (e.g., "Manifestation v3"), or "0" if no Manifestation exists. CC confirms what the room-summary endpoint returns for the Manifestation room and uses that value.

11.2 Lobby

The engagement lobby page (/engagement/[id]) has a Manifestation room badge. Phase 18 makes the badge a clickable link to /engagement/[id]/manifestation (currently count-only without a link). The badge treatment is unchanged — same environment tint, same count. Only the link is added.


12. Frontend API proxy routes

The frontend needs proxy routes to reach the substrate's Manifestation and memory-status endpoints. Following the Phase 16 pattern (proxy routes at /api/engagements/[id]/...):

New proxy routes:

| Frontend route | Substrate endpoint (CC confirms exact path) | |----------------|----------------------------------------------| | GET /api/engagements/[id]/manifestations/preview | GET /engagements/{eid}/manifestations/preview | | POST /api/engagements/[id]/manifestations/derive | POST /engagements/{eid}/manifestations/derive | | GET /api/engagements/[id]/manifestations | GET /engagements/{eid}/manifestations | | GET /api/engagements/[id]/memory-status | GET /engagements/{eid}/memory-status | | GET /api/engagements/[id]/downstream-impact | GET /engagements/{eid}/downstream-impact |

CC confirms the exact substrate endpoint paths at pre-flight and adjusts the proxy routes to match. The pattern (Next.js Route Handler forwarding to the substrate with session cookie auth) is established in Phase 16.


13. Order of operations (steps with checkpoints)

Auto-mode posture: Steps 1–3 auto, Checkpoint A. Steps 4–5 auto, Checkpoint B (final).

Step 0 — Pre-flight and CR archival.

Archive this CR. Confirm substrate endpoints exist and respond (Section 3.2). Confirm frontend baseline is clean.

Commit (frontend repo): Phase 18 step 0: CR archival and pre-flight.

Step 1 — Manifestation room page and empty state.

Create the page at /engagement/[id]/manifestation wrapped in EngagementRoomLayout. Implement the empty-state view (Section 5). Create frontend proxy routes for the Manifestation endpoints (Section 12). Fetch current Manifestation on page load; render empty state if none exists.

Verification: lint + tsc + build clean. Navigating to the Manifestation room for an engagement with no Manifestation shows the empty-state prompt.

Commit (frontend repo): Phase 18 step 1: manifestation room page and empty state.

Step 2 — Current Manifestation view: summary, delta, downstream.

Implement the three display sections (Sections 6–8). Fetch memory-status and downstream-impact data. Handle the "memory is current" and "no downstream work" cases.

Verification: lint + tsc + build clean. After deriving a Manifestation (via curl or substrate API), the room shows the summary, delta, and downstream sections.

Commit (frontend repo): Phase 18 step 2: manifestation summary, delta, and downstream display.

Step 3 — Two-step derive flow.

Implement the derive preview and confirmation modal (Section 9). Wire to the preview and derive endpoints. Handle the post-derivation room refresh.

Verification: lint + tsc + build clean. Operator can derive a Manifestation from the UI: click button → see preview → confirm → room refreshes with new Manifestation.

Commit (frontend repo): Phase 18 step 3: derive flow with preview and confirmation modal.

Checkpoint A — Manifestation room functional. Operator can view Manifestation state and derive new Manifestations. Operator confirms before history and wiring steps.

Step 4 — History timeline and room-switcher/lobby wiring.

Implement the collapsible history timeline (Section 10). Update the room switcher to make the Manifestation entry clickable (Section 11.1). Update the lobby badge to link to the Manifestation room (Section 11.2).

Verification: lint + tsc + build clean. History shows after re-derivation. Room switcher and lobby link to the Manifestation room.

Commit (frontend repo): Phase 18 step 4: history timeline and room-switcher wiring.

Step 5 — Implementation notes and tagging.

Create docs/phase-impl-notes/phase-18-implementation-notes-v0_1.md in the substrate repo recording what Phase 18 built, any findings, any divergences from this CR.

Verification: file exists and is reviewable.

Commit (substrate repo): Phase 18 step 5: implementation notes.

Checkpoint B — Final. Both repos green. Tag both repos as phase-18-manifestation-room-ui.


14. Acceptance gate

Phase 18 is accepted when:

  1. Substrate: all tests still pass (1110, 2 skipped). No substrate code changed.
  2. Frontend: lint + tsc + build clean.
  3. The Manifestation room is accessible at /engagement/[id]/manifestation.
  4. For an engagement with no Manifestation: the empty-state prompt appears with Memory summary counts and a "Derive first Manifestation" button.
  5. The derive flow works: click button → preview modal → confirm → Manifestation created → room shows summary.
  6. For an engagement with a current Manifestation: the room shows version, derived-at, derived-by, summary counts.
  7. The memory-status delta shows categorized counts when Memory has changed since derivation, or "has not changed" when current.
  8. The downstream dependency section shows Shaping summary cards (or "no Shapings" if none exist).
  9. Re-deriving supersedes the prior Manifestation and the history timeline shows it.
  10. The history timeline is collapsible.
  11. The room switcher's Manifestation entry is clickable and navigates to the room.
  12. The lobby's Manifestation badge links to the room.

On acceptance: tag both repos as phase-18-manifestation-room-ui. Write implementation notes.


15. Post-CR state


16. What this CR does not specify


17. Kickoff prompt for the Claude Code session


> Read the Change Request document at the path I supply below. This is
> CR-2026-032 v0.1, the Phase 18 Change Request (first version; no prior
> Phase 18 CR exists). You are the executing agent named in the CR.
>
> CR path: ~/Downloads/phase-18-cr-manifestation-room-ui-v0_1.md
> (confirm the latest approved version if more than one is present in
> Downloads).
>
> v0.1 drafts against the Phase 18 scoping note v0.1 (six settled
> decisions S1–S6). This is a frontend-only phase — no substrate
> changes, no migrations.
>
> Code baseline: tag phase-17-redirect-and-display-numbers on both
> repos. Substrate: 1110 tests, 2 skips. Frontend: lint + tsc + build
> clean.
>
> Run pre-flight (Step 0) per Section 3.2. CRITICAL: confirm the exact
> substrate endpoint paths for Manifestation preview, derive, list,
> memory-status, and downstream-impact. The CR names expected paths;
> the actual paths may differ. Adjust frontend proxy routes to match
> what exists in the substrate.
>
> Per Section 3.3: archive this CR to
> docs/phase-crs/phase-18-cr-manifestation-room-ui-v0_1.md at Step 0
> before Step 1 begins.
>
> Per Section 13, five steps with two checkpoints. Auto-mode posture:
> Steps 1–3 accept auto-mode-proceed; Checkpoint A halts until
> Operator confirms. Steps 4–5 auto; Checkpoint B (final) halts for
> tagging.
>
> Pre-flight surprises (substrate endpoint paths different from CR
> expectations, missing endpoints, unexpected response shapes) stop
> execution at Step 0 and drive a CR v0.2 revision; do not proceed
> through divergence.
>
> Implementation notes at Step 5:
> docs/phase-impl-notes/phase-18-implementation-notes-v0_1.md
> absorbs execution-time surprises and findings.

DUNIN7 — Done In Seven LLC — Miami, Florida Phase 18: Manifestation Room UI — CR v0.1 — 2026-04-27