DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-036 — Phase 22: Rendering Room UI (v0.1)

Version. 0.1 Date. 2026-04-28 Author. Marvin Percival (DUNIN7), prepared via Claude. Target. /Users/dunin7/loomworks (substrate, Step 0) and /Users/dunin7/loomworks-ui (frontend, Steps 1–5). DUNIN7-M4 (MacMini). Priority. Standard. Confidential. Internal. Companion to. Phase 22 scoping note v0.1, Phase 10 CR v0.1 (Render substrate), Phase 9 CR v0.3 (Shaping substrate), candidate seed v0.5, methodology v0.19. Status. First draft. Addresses eight scoping decisions (S1–S8).

1. Executive summary
2. Grounding
3. Prerequisites
4. Step 0 — substrate registration, display-readiness, archival
5. The Rendering room page
6. DeclaredRenderType groups and sections
7. Render cards
8. Request Render modal
9. Retire Render
10. Invalidated Renders
11. Async production and job polling
12. Retired and invalidated sections
13. Room switcher and lobby wiring
14. Frontend API proxy routes
15. Order of operations (steps with checkpoints)
16. Acceptance gate
17. Post-CR state
18. What this CR does not specify
19. Kickoff prompt for the Claude Code session

1. Executive summary

Phase 22 builds the Rendering room — the fourth and final methodology room in the UI. After this phase, the full pipeline (Memory → Manifestation → Shaping → Rendering) is live and navigable.

The room is organized by DeclaredRenderType from the seed, grouped into two categories matching the seed's structure: Build (11 render types) and Commons (2 render types). Each declared render type is a subsection; Renders produced for that type appear as metadata cards within. The Operator can request a Render against a confirmed Shape, retire a Render, and see invalidated Renders. Render content is not displayed inline (renders can be full documents); a content viewer is future work.

Step 0 registers the five DeclaredShapeTypes from candidate seed v0.5 in the Loomworks engagement, unblocking the Shaping room's sections. Step 0 also performs display-readiness pre-flight on Rendering response schemas and files amendments if needed, following the Phase 21 §3A pattern.

2. Grounding

Layer 1 — Methodology document v0.19. Render produces the consumer-facing artifact from a Shaping. The Shaping has selected, recast, foregrounded, traversed, and filtered; Render produces the document, the application, the audio file, the conversation — whatever the consumer actually receives. Render configuration pinning records the full configuration so output can be reasoned about later.

Layer 2 — Reference Design v0.1.2. S-3 (render delivery): the Rendering room is where the Operator sees produced Renders and their lineage back through Shaping to Memory.

Layer 3 — Playground Specification v0.10. Sec-C.1 R-C3 (Render production), Sec-C.4 R-C10 (Render confirmation via Shape layer), R-C13 (Render indexing).

3. Prerequisites

3.1 Baseline

Substrate repo: tag phase-21-shaping-room-ui on main. 1134 tests, 2 skips. Full Render layer from Phase 10.
Frontend repo: tag phase-21-shaping-room-ui on main. Lint + tsc + build + test clean. Twelve surfaces. 55 component tests, 1 E2E test.

3.2 Pre-flight checks

CC confirms before Step 1 (after Step 0 substrate work):

Frontend builds clean. npm run test passes.
Substrate is running at localhost:8000.
The following substrate endpoints exist and respond (CC confirms exact paths and response shapes):

DeclaredRenderType: list for an engagement
Render production: POST /renders/ (explicit_request)
Render job status: GET /render-jobs/{jobid}
Render list: GET /renders/ with filters
Render read: GET /renders/{object_id}
Render retire: POST /renders/{object_id}/retire
Render candidates: GET /renders/candidates
DeclaredShapeType: list for an engagement (confirms Step 0 registration)
Shape events: list confirmed shapes (for the Request Render modal)

Five DeclaredShapeTypes are registered in the Loomworks engagement (Step 0 prerequisite).
Display-readiness of Rendering response schemas is confirmed (Step 0 amendments applied if needed).
The RoomSwitcher component, EngagementRoomLayout, and Shaping room page are identified as templates.

Endpoint path note. The exact substrate endpoint paths may differ from Phase 10 CR specifications. CC confirms at pre-flight and wires proxy routes accordingly. 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-22-cr-rendering-room-ui-v0_1.md in the substrate repo at Step 0. Archive candidate seed v0.5 to docs/seeds/loomworks-candidate-seed-v0_5.md.

4. Step 0 — substrate registration, display-readiness, archival

Three substrate tasks before frontend work begins.

4.1 DeclaredShapeType registration

Register five DeclaredShapeTypes in the Loomworks engagement (ID 00000000-0000-0000-0000-000000000002) from candidate seed v0.5. Each registration writes a declared_shape_type_added event to memory_events following the Phase 9 pattern.

The five shape types:

| Shape type name | Consumer | Source for render-types | |----------------|----------|------------------------| | Phase execution context | Claude (CR drafter), CC (executor), Operator (reviewer) | Phase CR, scoping note, handoff, implementation notes | | Project state | Fresh Claude chats, Operator | Manifest, standing note, infrastructure CR, engagement seed | | Methodology narrative | Anyone understanding what DUNIN7 builds | Methodology document, philosophy/architecture document | | Discovery trajectory | Future methodology revisions, Operator | Discovery record | | Commons education | Every person in the system | Concept reference, contributor guide |

Each DeclaredShapeType carries:

shape_type_name — as listed above.
consumer_declaration — from the seed v0.5 consumer descriptions.
selection_criterion — from the seed v0.5 selection descriptions.
shaping_instructions — initial instructions derived from the seed v0.5 descriptions. CC drafts reasonable initial instructions; the Operator can amend later via the Shaping room.
state — "active".

After registration: the Shaping room shows five DeclaredShapeType sections instead of the dead-end message.

4.2 Display-readiness pre-flight

CC checks Rendering response schemas against this CR's display requirements. Likely gaps (based on Phase 21 precedent):

Render specialist display name. RenderEventResponse.render_specialist_ref may use ActorRefSchema (no display_name) instead of ActorRefResponse. Same pattern as Phase 21 Amendment A.
Triggered-by display name. RenderEventResponse.triggered_by may lack display_name.
DeclaredRenderType resolved name. The Render card (§7) needs the declared render type's name. The response may carry only declared_render_type_ref (object_id + version) without the resolved name.
Source Shape resolved name. The Render card needs the source Shaping's name. The response may carry only confirmed_shape_event_ref without resolved Shaping context.
Production timestamp. RenderEventResponse may or may not carry produced_at or equivalent.

CC identifies actual gaps at pre-flight. For each gap found, CC applies the same Step 0 amendment pattern as Phase 21: schema change, router population, migration if needed, tests. Accept null for pre-amendment rows where applicable.

If no gaps are found, Step 0 is registration + archival only.

4.3 CR and seed archival

Archive this CR (v0.1) to docs/phase-crs/phase-22-cr-rendering-room-ui-v0_1.md.
Archive candidate seed v0.5 to docs/seeds/loomworks-candidate-seed-v0_5.md.

Commit (substrate repo): Phase 22 step 0: CR archival, seed v0.5, DeclaredShapeType registration, display-readiness amendments.

5. The Rendering room page

5.1 Route and structure

Page at /engagement/[id]/rendering. Wrapped in EngagementRoomLayout. Environment tint: env-rendering (#E6DCCA, cream).

5.2 Page header

Room header: "Rendering" in {typography.h2}. Subtitle in {typography.body} with {colors.ink-faint}:

> Renders are consumer-facing artifacts produced from confirmed Shapes. Each Render records what specialist produced it, what Shape it drew from, and what configuration was in force.

5.3 Conditional rendering

The page fetches the engagement's DeclaredRenderTypes and Renders on load. Three states:

No DeclaredRenderTypes: the seed has no declared render types. Show a message: "This engagement's seed does not declare any render types. Render types are defined in the seed."
DeclaredRenderTypes but no Renders: show the grouped sections with empty-state prompts.
Renders exist: show the full organized view.

6. DeclaredRenderType groups and sections

6.1 Group structure

DeclaredRenderTypes are grouped into two top-level sections matching the seed's structure:

Build — group heading in {typography.h3}. Contains the eleven build render types.
Commons — group heading in {typography.h3}. Contains the two commons render types.

CC determines the grouping by inspecting the seed's DeclaredRenderType metadata. If the seed carries a category or group field, use it. If not, CC can infer from the consumer_declaration or the DeclaredRenderType names (the eleven build types have build-team consumers; the two commons types have "every person" consumers). If inference is ambiguous, fall back to a flat list without grouping.

6.2 DeclaredRenderType subsections

Within each group, each DeclaredRenderType is a subsection.

Subsection heading: the render type's name in {typography.body-em}.

Subsection metadata in {typography.caption} with {colors.ink-faint}:

Consumer declaration — who this render type serves.
Render format — the content format (e.g., .md, .docx).
Source shape type — "From shape type: [name]" linking the render type to its source DeclaredShapeType.

Active Renders for this type appear as cards within the subsection (§7). If no Renders exist:

> No Renders have been produced for this type yet.

With a "Request Render" primary button if at least one confirmed Shape exists for the source shape type. Without the button if no confirmed Shapes exist (nothing to render against).

7. Render cards

Each produced Render is a card ({components.card}) within its DeclaredRenderType subsection.

Card content:

State badge — "Produced" with {colors.state-attest} dot. "Retired" with {colors.ink-faint} dot. "Invalidated" with {colors.state-amend} dot.
Render format in {typography.mono}.
Source reference — "From [Shaping name] · Shape v[N]" in {typography.caption}. Resolved from the confirmed_shape_event_ref. If resolution is unavailable, show "From Shape [id-prefix]".
Specialist — "Specialist: [display_name]" in {typography.caption}. Resolved from render_specialist_ref. If display_name unavailable, show "Specialist: [id-prefix]".
Trigger — "Requested by [name]" or "Auto-triggered" in {typography.caption}.
Timestamp — when the Render was produced, in {typography.caption}.

Action buttons (produced Renders only):

"Retire" — {components.button-ghost}. Confirmation flow (§9).

Per "only show what is available" — no action buttons on retired or invalidated Renders.

8. Request Render modal

Trigger: "Request Render" button on a DeclaredRenderType subsection.

Modal content:

Header kicker: "Request Render" in {typography.caption}.
Header title: "New Render for [DeclaredRenderType name]" in {typography.h3}.
Body:
Source shape type — displayed (read-only). The DeclaredRenderType's source shape type name.
Confirmed Shape — a list of confirmed Shapes for the source shape type, newest-first. Each entry shows: Shaping name, Shape version, Manifestation version it ran against, confirmation timestamp. The Operator selects one.
If no confirmed Shapes exist (edge case — the button should not have appeared), show: "No confirmed Shapes available for this source shape type."
Actions:
"Cancel" — {components.button-ghost}.
"Request" — {components.button-primary}.

On request: calls POST /renders/ with confirmed_shape_event_ref and declared_render_type_ref. Returns 202 with render_job_id. Modal closes. Async production begins (§11).

9. Retire Render

Clicking "Retire" on a produced Render shows an inline confirmation (same pattern as Shaping retirement — not a modal, an inline expansion):

> Retire this Render? It will no longer be current. The Render content is preserved for reference.

Reason — text input. Required.

"Confirm retirement" — {components.button-ghost}. "Cancel" — text link.

On success: the Render moves to the retired section (§12). State badge changes to "Retired" with {colors.ink-faint} dot.

10. Invalidated Renders

Invalidated Renders are system-driven — the substrate's drift detection (Phase 10's Check A' and Check B') invalidated them. The UI displays them but offers no actions.

Invalidated Render card additions:

State badge: "Invalidated" with {colors.state-amend} dot (iron-oxide — invalidation is consequential).
Invalidation reason — in {typography.caption} with {colors.ink-faint}: "Rule conformance drift" or "Translation drift" based on the triggering_reason if available in the response metadata. If not available, show "Invalidated by drift detection".

Invalidated Renders appear in the invalidated collapsible section (§12).

11. Async production and job polling

11.1 After request

The POST /renders/ endpoint returns 202 with { render_job_id, render_event_object_id }. The UI enters a polling state.

11.2 Polling

Poll GET /render-jobs/{jobid} at 3-second intervals. During polling:

The DeclaredRenderType subsection shows a subtle loading indicator ("Producing render...").
The "Request Render" button is disabled (one render at a time per subsection).

11.3 Completion

On job completion (success): the new Render card appears in the subsection. Polling stops.

On job completion (failure): an error message appears inline in the subsection. Polling stops.

11.4 Timeout

If polling exceeds 120 seconds without completion, stop polling and show: "Render production is taking longer than expected. Refresh the page to check for results." This handles the case where the specialist takes a long time or the job stalls.

12. Retired and invalidated sections

Within each DeclaredRenderType subsection, below active Renders:

"Show retired · [N]" collapsible toggle (collapsed by default). Contains retired Render cards. Same pattern as retired Shapings in Phase 21.
"Show invalidated · [N]" collapsible toggle (collapsed by default). Contains invalidated Render cards with drift reason.

Toggles appear only when the count is non-zero. Per "only show what is available."

13. Room switcher and lobby wiring

13.1 Room switcher

The Rendering entry becomes clickable and navigable: link to /engagement/[id]/rendering.

All four room entries are now clickable. The room switcher is complete.

The count displayed: number of produced (active) Renders, or "0" if none exist.

13.2 Lobby

The Rendering room badge becomes a clickable link to the Rendering room. All four lobby badges now link to rooms.

14. Frontend API proxy routes

New proxy routes (CC confirms exact substrate paths):

| Frontend route | Substrate endpoint | |----------------|-------------------| | GET /api/engagements/[id]/declared-render-types | List DeclaredRenderTypes | | POST /api/engagements/[id]/renders | Request Render (explicit_request) | | GET /api/engagements/[id]/render-jobs/[jobid] | Poll render job status | | GET /api/engagements/[id]/renders | List Renders | | GET /api/engagements/[id]/renders/[rid] | Get Render by ID | | POST /api/engagements/[id]/renders/[rid]/retire | Retire Render | | GET /api/engagements/[id]/renders/candidates | List render candidates |

Some routes may already exist as proxy routes from earlier phases. "Do not duplicate" applies. CC confirms exact substrate paths and adjusts.

15. Order of operations (steps with checkpoints)

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

Step 0 — CR archival, seed archival, DeclaredShapeType registration, display-readiness amendments, pre-flight.

Archive this CR to docs/phase-crs/phase-22-cr-rendering-room-ui-v0_1.md.
Archive candidate seed v0.5 to docs/seeds/loomworks-candidate-seed-v0_5.md.
Register five DeclaredShapeTypes in the Loomworks engagement per §4.1.
Display-readiness pre-flight per §4.2. Apply amendments if gaps found.
Run full substrate test suite — 1134+ tests pass, 2 skips.
Confirm pre-flight checks per §3.2.

Commit (substrate repo): Phase 22 step 0: CR archival, seed v0.5, DeclaredShapeType registration, display-readiness amendments.

Step 1 — Rendering room page, DeclaredRenderType groups and sections, proxy routes.

Create the page at /engagement/[id]/rendering wrapped in EngagementRoomLayout. Implement group structure (Build/Commons) and DeclaredRenderType subsections (§6). Create proxy routes (§14). Handle three conditional states (§5.3).

Verification: lint + tsc + build clean. Room renders with grouped DeclaredRenderType headings.

Commit (frontend repo): Phase 22 step 1: rendering room page and declared render type sections.

Step 2 — Render cards, Request Render modal, retire flow.

Implement Render cards (§7). Request Render modal (§8). Retire flow (§9). Invalidated Render display (§10). Retired and invalidated collapsible sections (§12).

Verification: lint + tsc + build + test clean.

Commit (frontend repo): Phase 22 step 2: render cards, request modal, retire flow.

Step 3 — Async production, job polling.

Implement async production with job polling (§11). Loading states, timeout handling, error display.

Verification: lint + tsc + build + test clean. Operator can request a Render and see it appear after polling.

Commit (frontend repo): Phase 22 step 3: async render production and job polling.

Checkpoint A — Rendering room functional. All operations work. Operator confirms before wiring and final steps.

Step 4 — Room switcher, lobby wiring, component tests.

Room switcher Rendering entry becomes clickable (§13). All four rooms navigable. Lobby badge links to room. Write component tests for Render cards and key interactions.

Verification: lint + tsc + build + test clean.

Commit (frontend repo): Phase 22 step 4: room switcher wiring and component tests.

Step 5 — Implementation notes and tagging.

Create docs/phase-impl-notes/phase-22-implementation-notes-v0_1.md.

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

Checkpoint B — Final. Both repos green. Tag both repos as phase-22-rendering-room-ui.

16. Acceptance gate

Phase 22 is accepted when:

Substrate: all tests pass (1134+ with any amendment additions, 2 skips). Five DeclaredShapeTypes registered in the Loomworks engagement.
Frontend: lint + tsc + build + test clean.
The Rendering room is accessible at /engagement/[id]/rendering.
DeclaredRenderTypes from the seed appear as sections grouped by Build and Commons.
Each section shows consumer declaration, render format, and source shape type.
The Operator can request a Render against a confirmed Shape for a declared type.
Async production shows loading state and completes with a Render card appearing.
Produced Render cards show state, format, source reference, specialist, trigger, and timestamp.
The Operator can retire a Render (inline confirmation, reason required).
Invalidated Renders display with state badge and drift reason.
Retired and invalidated Renders are in collapsible sections.
The room switcher's Rendering entry is clickable. All four rooms navigable.
The lobby's Rendering badge links to the room.
The Shaping room shows five DeclaredShapeType sections (confirms Step 0 registration).
Component tests cover Render cards and key interactions.

On acceptance: tag both repos as phase-22-rendering-room-ui. Write implementation notes.

17. Post-CR state

Substrate: 1134+ tests (with any amendment additions), 2 skips.
Frontend: lint + tsc + build + test clean. Thirteen surfaces (twelve existing + Rendering room).
Room switcher: four rooms clickable (Memory, Manifestation, Shaping, Rendering). Complete.
Lobby: four room badges link to rooms. Complete.
Route: /engagement/[id]/rendering live.
Full pipeline: Memory → Manifestation → Shaping → Rendering live in the UI.
Loomworks engagement: five DeclaredShapeTypes registered. Shaping room functional.

18. What this CR does not specify

Render content viewer. Full rendered content display. Phase 22 shows metadata cards only.
Render download. Format-aware export of render_content to downloadable files.
Auto-trigger configuration UI. Auto-trigger wiring is substrate-internal.
Render specialist registration through the UI. API-only.
DeclaredRenderType CRUD through the UI. API-only; the seed declares them.
Render chaining. One Render's output as input to another Render.
Cross-engagement Render queries. Engagement-scoped only.
Render-layer confirmation framework UI. Position A: no Render-layer confirmation.
Shaping rule editor with syntax highlighting. Plain text.
Agent/skill registration through the UI. Still API-only.
Engagement creation through the UI. Still API/migration only.

19. Kickoff prompt for the Claude Code session


> Read the Change Request document at the path I supply below. This is
> CR-2026-036 v0.1, the Phase 22 Change Request. You are the executing
> agent named in the CR.
>
> CR path: ~/Downloads/phase-22-cr-rendering-room-ui-v0_1.md
>
> Also read the candidate seed v0.5:
> ~/Downloads/loomworks-candidate-seed-v0_5.md
>
> Phase 22 builds the Rendering room — the fourth and final methodology
> room. After this phase, the full pipeline is live.
>
> Step 0 carries three substrate tasks:
>   1. Archive CR and seed v0.5.
>   2. Register five DeclaredShapeTypes from seed v0.5 in the Loomworks
>      engagement (see §4.1 for the table).
>   3. Display-readiness pre-flight on Rendering response schemas
>      (see §4.2). Apply amendments if gaps found, same pattern as
>      Phase 21 §3A.
>   4. Full substrate test suite green.
>   5. Pre-flight checks per §3.2.
>
> Code baseline: substrate at tag phase-21-shaping-room-ui (1134 tests,
> 2 skips). Frontend at tag phase-21-shaping-room-ui (lint + tsc +
> build + test clean, 55 component tests, 1 E2E).
>
> Steps 1–3 auto, Checkpoint A halts for smoke-test.
> Steps 4–5 auto, Checkpoint B halts for tagging.
>
> Brand enforcement: four environment tints must be consistent across
> all surfaces. Memory #E4E6E8, Manifestation #DCE3DB, Shaping #E6D4C5,
> Rendering #E6DCCA. Audit before tagging.
>
> Implementation notes at Step 5:
> docs/phase-impl-notes/phase-22-implementation-notes-v0_1.md

DUNIN7 — Done In Seven LLC — Miami, Florida Phase 22: Rendering Room UI — CR v0.1 — 2026-04-28

DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-036 — Phase 22: Rendering Room UI (v0.1)

Contents

1. Executive summary

2. Grounding

3. Prerequisites

3.1 Baseline

3.2 Pre-flight checks

3.3 CR archival

4. Step 0 — substrate registration, display-readiness, archival

4.1 DeclaredShapeType registration

4.2 Display-readiness pre-flight

4.3 CR and seed archival

5. The Rendering room page

5.1 Route and structure

5.2 Page header

5.3 Conditional rendering

6. DeclaredRenderType groups and sections

6.1 Group structure

6.2 DeclaredRenderType subsections

7. Render cards

8. Request Render modal

9. Retire Render

10. Invalidated Renders

11. Async production and job polling

11.1 After request

11.2 Polling

11.3 Completion

11.4 Timeout

12. Retired and invalidated sections

13. Room switcher and lobby wiring

13.1 Room switcher

13.2 Lobby

14. Frontend API proxy routes

15. Order of operations (steps with checkpoints)

16. Acceptance gate

17. Post-CR state

18. What this CR does not specify

19. Kickoff prompt for the Claude Code session