Agent Orchestration on ICE-ICE-BEAR-BLOG

Creative Agent Studio #5 — Polish Week: LLM Token Telemetry, Multi-Session Isolation, Inline Rewind, and the Revision-Request Affordance

Thu, 28 May 2026 00:00:00 +0900

Overview

Previous post: #4 — five gates, four canvases, and the revise-mode system ended the build-out push. Six days later, 23 commits over four working days closed out polish week — the kind of work that turns a feature-complete system into something that holds up in production under a real user’s hands.

Four threads ran in parallel through the week. First, LLM-call observability — every model invocation now emits structured logs with token usage and a propagated logCtx, plus the runtime got LOG_LEVEL threshold control. Second, per-project state isolation under refresh — eight commits on 2026-05-26 hunted down hooks-order bugs, stranded bootstraps, and crypto.randomUUID gaps that surfaced once the multi-session work landed. Third, inline past-gate rewind — a single feat commit shipped the affordance that lets users say “change the third copy back at GATE 2” from inside an active storyboard session without leaving. Fourth, the revision-request affordance pass — five commits unified the marked-card visual across every canvas tab, softened the rewind dialog copy, and fixed a state bug where the gate selector forgot which card the user just clicked.

graph TD
 Prev["#4 — build-out (5cb4106)"] --> Thread1["Thread 1 <br/> LLM observability <br/> token usage + logCtx"]
 Prev --> Thread2["Thread 2 <br/> Per-project isolation <br/> hooks order + bootstrap fixes"]
 Prev --> Thread3["Thread 3 <br/> Inline past-gate rewind <br/> chat-driven pipeline edits"]
 Prev --> Thread4["Thread 4 <br/> Revision-request UX <br/> unified marked-card affordance"]
 Thread1 --> End["#5 end (67b820e) <br/> 2026-05-28"]
 Thread2 --> End
 Thread3 --> End
 Thread4 --> End

One running theme — the features were done; what remained was making them honest under refresh, under load, and under a confused user.

Thread 1 — LLM-Call Observability

The structured logger that landed in #2 was the foundation; this week wired it through every LLM call site so production telemetry actually means something.

Two commits did the heavy lifting:

feat(logger): add LOG_LEVEL threshold, silence node:sqlite warning — a LOG_LEVEL env var so production can drop the info chatter and keep only warn/error. The companion change suppressed the node:sqlite experimental-warning that printed on every worker fork.
feat(observability): emit structured logs across worker + lifecycle paths — runtime/workers/worker-loop.js and runtime/orchestration/run-lifecycle.js now log structured events at each meaningful transition (job claimed, run started, gate emitted, stage advanced, run completed/errored).
feat(observability): instrument LLM calls with token usage + logCtx — this is the load-bearing one. Every model call now logs:

// runtime/agents/_llm-instrument.js (paraphrased)
async function callModelWithLogging(model, prompt, logCtx) {
 const start = Date.now();
 try {
 const result = await model.generate(prompt);
 logger.info("llm_call", {
 ...logCtx,
 model: result.model,
 prompt_tokens: result.usage?.input_tokens,
 output_tokens: result.usage?.output_tokens,
 duration_ms: Date.now() - start,
 cached_tokens: result.usage?.cached_input_tokens ?? 0,
 });
 return result;
 } catch (err) {
 logger.error("llm_call_failed", { ...logCtx, error: err.message, duration_ms: Date.now() - start });
 throw err;
 }
}

logCtx is propagated from worker-loop.js and carries { runId, projectId, stage, role }. So a single LLM call’s log line tells you which project, which session, which gate, which agent, which model — and how many tokens it cost. The Grafana dashboard set up back in #2 now has actual data flowing into it.

The infra-side companion was feat(terraform): widen EC2 start cron to every day + fix(terraform): update daily stop schedule to 03:00 KST. The EC2 instance had been running on a weekday-only schedule from the prototype days; the cron now starts the box every day and stops it at 03:00 KST. Operational, not feature work.

Thread 2 — Per-Project State Isolation Under Refresh

The multi-session work in #4 introduced an entire class of refresh-time bugs. When the user hard-refreshes inside a workspace, the React tree mounts before any data is loaded — and the multi-session logic was making assumptions that only held if the user had navigated into the workspace from the launcher (where the bootstrap had already happened).

Eight commits on 2026-05-26 hunted down the edge cases:

fix(web): bootstrap projects on workspace refresh, fix hooks order — the workspace page assumed projects was already loaded. It wasn’t on a refresh. The fix added a bootstrap call inside the workspace effect — but that triggered a React hooks-order violation because the bootstrap call was conditionally inside a useEffect. Both got fixed in one commit.

fix(web): isolate per-project state on switch, show loader during session hydration — switching from project A to project B was leaving A’s session list visible while B was loading. The fix: when projectId changes, immediately clear the per-project slices and show a loader, then hydrate B’s data. The user sees a brief loader instead of mistakenly attributing A’s sessions to B.

fix(web): don't strand /sessions bootstrap behind a stale ref guard — there was a “don’t re-bootstrap if already bootstrapping” guard implemented with a ref. The ref was being set to true and then never cleared on certain error paths, so subsequent navigations got stranded. Fix: track the bootstrap state in the slice instead of in a ref, and clear it on success and failure.

fix(web): make Composer first-brief-only, flip ApproveBar toggle label — the Composer (chat input) had been the entry point for every user turn. But once a session was past the first brief, the gate-based flow took over — the Composer’s role should be hidden. The fix made the Composer visible only before the first brief is submitted; after that, the ApproveBar is the user’s surface.

fix(web): make bootstrap dep stable so /sessions can't be cancelled forever — useChatStream was using an AbortController whose dependency array was unstable, causing it to abort on every re-render. The fix stabilized the dep so the controller only aborted on actual user cancel or unmount.

fix(web): polyfill crypto.randomUUID so HTTP prod can create projects/sessions — the production EC2 was serving over plain HTTP for some clients (an intermediate proxy stripped HTTPS), and crypto.randomUUID is only available in secure contexts. Projects and sessions couldn’t be created. The polyfill restores it.

The last one is the most “production reveals what your dev environment hid” of the week. Localhost is a secure context. The deploy target isn’t always. A one-line polyfill kept the EC2 build usable.

fix: preserve 분석 보고서 across key-concept revisions — the runtime fix companion. When the user revised the key-concept selection at GATE 1, the analysis report (도서 단계의 산출물) was being recomputed alongside, which was unnecessary work and produced a slightly different report each time. The fix kept the original analysis frozen across key-concept revisions.

And docs(claude): register Diffs Runtime harness pointer in CLAUDE.md added a pointer so Claude Code sessions could find the runtime’s harness conventions automatically.

Thread 3 — Inline Past-Gate Rewind From Chat

A single commit shipped a major UX move: feat(web): add inline past-gate rewind for chat-driven pipeline edits.

The setup: by polish week, the user had ApproveBar with revise-mode for the current gate, and the workflow advanced one stage at a time. But what if the user wanted to change a past decision? “Actually, go back to the second key concept” while sitting in the storyboard stage?

Previously this required leaving the canvas, navigating back to GATE 1 manually, reselecting, and walking forward through every subsequent gate again. Painful, and a violation of the chat-first principle.

The inline rewind detects past-gate intent in chat:

// (paraphrased — combined chat-stream + dispatch-sse path)
// Backend classifies the chat message:
// "두 번째 키 컨셉으로 다시 가자" → rewind_intent: { gate: "GATE_1", selection: 2 }
// Frontend receives a rewind_proposal SSE event:
{
 kind: "rewind_proposal",
 fromGate: "GATE_5",
 toGate: "GATE_1",
 affectedDownstreamGates: ["GATE_2", "GATE_3", "GATE_4", "GATE_5"],
}
// UI shows the inline ConfirmRewindDialog (the one polished in Thread 4)

The dialog explicitly lists what will be discarded — copy approval at GATE 2, scenario approval at GATE 4, etc. — so the user knows the cost before confirming. On confirm, the runtime walks the project back to the target gate, regenerates everything downstream, and the user lands at the target gate’s approval surface ready to make the new choice.

This is the natural extension of the gate-based-auto-run principle (decision 3 in interaction-model.md) — but in reverse. The principle says: each stage advances to the next on user approval. The rewind says: each stage can also walk back, and the runtime knows what to invalidate.

The companion docs(claude): add triage-prod-bug skill trigger to enforce browser-first debugging is a harness rule — when a bug is reported, look at the browser first (devtools, network, console) before reading any code. The chat-first product principle has a debugging analogue: see-first, code-second.

Thread 4 — The Revision-Request Affordance Pass

The final five commits unified the revision-request UI across every canvas tab. Before this work, every tab had implemented its own marked-card style — yellow background on Copy, red dashed border on KeyConcept, blue left-edge bar on Storyboard (only this one), no visual treatment at all on Scene — and users kept asking “why does only 콘티 (Storyboard) show this blue mark?”

Soften rewind dialog copy + hide final gate from discard list

Commit e27316a. The first attack was the most jarring piece of copy. The rewind dialog read:

“이 결정을 되돌릴까요?” “카피 검토 단계부터 다시 진행합니다.” “아래 후속 결정이 새 버전으로 대체됩니다:” – 컨셉 확정 결정 – 시나리오 검토 결정 – 최종 승인 결정 ← shouldn’t be in this list

Two problems: the discard list included the final approval gate (but that gate is what you would re-confirm at the end, not something that vanishes), and “결정” felt corporate when the actual artifact is a creative judgment about a draft.

// web/src/components/approve/ConfirmRewindDialog.tsx
<ul data-testid="confirm-rewind-discard-list">
 {gates
 .filter(g => g.kind !== 'final-approval')
 .map(g => <li key={g.id}>{g.softTitle}</li>)}
</ul>

Filter final-approval gates out of the discard preview, and use softTitle (e.g., “콘티 검토” instead of “콘티 검토 결정”). Both come from the same Gate interface but rendered differently in destructive vs. informational contexts.

Gate titles in the rewind dialog

Commit 4ddff68. The dialog had been using machine-generated gate ids (g-2, g-3) as titles. A small label map fixed comprehension:

const GATE_LABELS: Record<GateKind, string> = {
 'concept-confirm': '컨셉 검토',
 'scenario-review': '시나리오 검토',
 'storyboard-approve':'콘티 검토',
 'cut-finalize': '컷 검토',
 'final-approval': '최종 승인',
};

Now the dialog reads “콘티 검토 단계부터 다시 진행합니다” — a phrase that matches the canvas tab labels exactly, so users see in advance which tab they’ll land on after rewinding.

ApproveBar gate preselection on 수정요청 enter

Commit c55891b. When the user clicked 수정요청 on a card, the ApproveBar slid up with a gate selector — but the selector started empty, so the user had to re-click the same gate they just marked. A two-line useEffect synced the implicit context into the explicit selection:

// web/src/components/approve/ApproveBar.tsx
useEffect(() => {
 if (mode === '수정요청' && activeCard) {
 setGateSelection(activeCard.gateId);
 }
 if (mode === 'idle') {
 setGateSelection(null); // clear on 닫기
 }
}, [mode, activeCard]);

A security-review pass on this change surfaced one note: the gate id flows from a user-controlled DOM event into a state field that gets passed to a server-side mutation. Since gateId is validated server-side against the current workflow’s gate set anyway, no additional client-side validation was needed — but the review made that invariant explicit.

Unifying the marked-card visual across five tabs

Commit 2804420. The visual unification pass. The unified treatment lives in a single design token:

// design-system / marked-card.css
.marked-card {
 position: relative;
 outline: 2px solid var(--color-revision);
 outline-offset: -2px;
}
.marked-card::before {
 content: '';
 position: absolute;
 top: 0; bottom: 0; left: 0;
 width: 3px;
 background: var(--color-revision);
}

And every tab component now wraps the card in:

<div className={cn('card', card.marked && 'marked-card')}>
 {card.marked && <RevisionLabel kind={card.kind} />}
 {/* tab-specific content */}
</div>

RevisionLabel was also extracted — previously each tab built its own label inline with different copy (“수정 요청됨”, “리비전”, “Edit Pending”). Now there is one component, one string.

Show every gate marker once and reflect live gate state

The very last commit of the day (67b820e). The StageStepper at the top of the workspace was showing duplicate gate markers in some states (a re-emitted gate event would add a second dot) and was lagging behind the actual gate_state transitions. Two bugs in one fix:

Deduplicate by gate id so each gate renders exactly once
Wire the live gate_state from the pipeline slice (the 12-state field from #4) so the stepper reflects whatever transition just happened

The 12-state gate_state field had been in place for a week, but the stepper had still been using the older “last completed gate” inference. This commit closed that gap.

Commit Log (23 total)

Date	Message
2026-05-25	fix stale approve gates during storyboard runs
2026-05-25	feat(terraform): widen EC2 start cron to every day
2026-05-25	refactor(canvas): drop submit prop drilling, polish selected-copy card
2026-05-25	feat(logger): add LOG_LEVEL threshold, silence node:sqlite warning
2026-05-25	feat(observability): emit structured logs across worker + lifecycle paths
2026-05-25	feat(observability): instrument LLM calls with token usage + logCtx
2026-05-25	chore: refresh lockfile peer-dep flags
2026-05-26	fix(web): bootstrap projects on workspace refresh, fix hooks order
2026-05-26	docs(claude): register Diffs Runtime harness pointer in CLAUDE.md
2026-05-26	fix: preserve 분석 보고서 across key-concept revisions
2026-05-26	fix(web): isolate per-project state on switch, show loader during session hydration
2026-05-26	fix(web): don’t strand /sessions bootstrap behind a stale ref guard
2026-05-26	fix(web): make Composer first-brief-only, flip ApproveBar toggle label
2026-05-26	fix(web): make bootstrap dep stable so /sessions can’t be cancelled forever
2026-05-26	fix(web): polyfill crypto.randomUUID so HTTP prod can create projects/sessions
2026-05-27	docs(claude): add triage-prod-bug skill trigger to enforce browser-first debugging
2026-05-27	feat(web): add inline past-gate rewind for chat-driven pipeline edits
2026-05-27	fix(terraform): update daily stop schedule to 03:00 KST in variables
2026-05-27	fix(gitignore): add harnesskit session-logs to .gitignore
2026-05-28	fix(web): soften rewind dialog copy and hide final gate from discard list
2026-05-28	fix(web): update gate titles in ConfirmRewindDialog for clarity
2026-05-28	fix(web): preselect gateSelection on 수정요청 enter, clear it on 닫기
2026-05-28	fix(web): unify 수정요청 marked-card visual and label across all tabs
2026-05-28	fix(web): show every gate marker once and reflect live gate state

Insights

Polish week’s pattern: observability and isolation were both about exposing state that had been quietly assumed.

The LLM token telemetry exposed what was actually costing money — the prior dashboards showed queue depth and job duration, both important, but a slow agent might be cheap and a fast agent might be expensive depending on token usage. Wiring logCtx through every call surfaced the per-project, per-stage, per-agent breakdown the cost analysis needs.

The multi-session refresh fixes exposed what the workspace was assuming about its bootstrap. The features worked when the user navigated in from the launcher because the launcher’s bootstrap was a precondition that happened to be satisfied. When refresh broke that precondition, the bugs surfaced — but they had been there all along, latent.

The inline past-gate rewind is the same idea applied to the user’s mental model — the user thinks “I want to change something back at GATE 1.” The rewind feature exposed that intent to the system instead of forcing the user to translate it into navigation steps. The chat-first principle isn’t just an input mechanism; it’s a commitment that the system will understand intent.

The revision-request affordance pass is the small visible tip of the same iceberg. Three layers of clarity — visual unity, honest copy, state preservation — applied to a destructive workflow action, so the dialog asking for confirmation tells the truth about what will be lost.

Next: from here forward, the system is feature-complete enough that future dev logs will tilt toward production lessons rather than feature additions — agent prompt tuning, cost trending, the next round of UX patterns that emerge from real user sessions. The five-post backfill closes a clean arc: mockup, production-readying, megapush, gate workflow, polish. The product is real now.

Creative Agent Studio #4 — Five Gates, Four Canvases, and the Revise-Mode System

Fri, 22 May 2026 00:00:00 +0900

Overview

Previous post: #3 — the 134-commit megapush ended with PR4 (ApproveSheet + three gate variants) merged and project state surviving reload. Three days later, 153 more commits had completed every remaining piece of the four-stage agent workflow: a four-variant canvas panel that materialized the stage outputs (PR5), a workflow consolidation from three gates to five with the key-concept planner at the new GATE 1, a UI re-architecture that replaced the bottom-drawer ApproveSheet with a slim ApproveBar plus output tabs, and the revise-mode multi-select system that lets users surgically re-run a single key concept, copy draft, cut, or storyboard panel instead of redoing an entire stage.

Underneath, the runtime gained the Planner-Generator-Evaluator loop, continuity anchors authored from user feedback, evolution notes injected into prompts, an HTML template set for the planning report and storyboard, and session isolation so a single project can carry multiple parallel attempts.

graph TD
 Prev["#3 — megapush (9a2f851)"] --> Theme1["Theme 1 <br/> PR5 — 4 stage canvases <br/> + resize + collapse"]
 Prev --> Theme2["Theme 2 <br/> 5-gate workflow <br/> key-concept planner at GATE 1"]
 Prev --> Theme3["Theme 3 <br/> ApproveBar + output tabs <br/> drawer replaced"]
 Prev --> Theme4["Theme 4 <br/> Revise-mode system <br/> partial vs bulk revision"]
 Theme1 --> End["#4 end (5cb4106) <br/> 2026-05-22"]
 Theme2 --> End
 Theme3 --> End
 Theme4 --> End

Four themes, one recurring shape — the workflow stopped being “all or nothing” at every layer it touched.

Theme 1 — PR5: The Canvas Panel With Four Stage Variants

PR2 reserved a CanvasPanel placeholder. PR5 filled it. The canvas is the right-hand column of the workspace; it shows the current artifact of the current stage, rendered with a stage-specific component.

// web/src/components/canvas/stage-canvas.tsx (paraphrased)
function StageCanvas({ stage }: { stage: PresentationStage }) {
 switch (stage) {
 case "research": return <ResearchCanvas />;
 case "copy": return <CopyCanvas />;
 case "scenario": return <ScenarioCanvas />;
 case "storyboard": return <StoryboardCanvas />;
 }
}

Each variant reads its data from the pipeline slice and renders a stage-appropriate layout:

Stage	Variant	What it shows
research	`ResearchCanvas`	`AdBriefRecap` + `ResearchSummaryCards` from `pipelineContext` + active task list
copy	`CopyCanvas`	`ConceptGrid` of `CopyOptions` from `copyHistory`
scenario	`ScenarioCanvas`	`SceneStrip` per Act + `CutChip` strip from `scenarioHistory`
storyboard	`StoryboardCanvas`	1 `StoryboardPage` per scene from `storyboardImageUrls`

Storyboard image handling needed a small architectural choice. Base64 PNG payloads arrive via storyboard_image SSE events. The pipeline slice converts each to a blob URL (URL.createObjectURL) with a revoke-on-replace step so a re-generation doesn’t leak the previous image. The addStoryboardImage reducer holds the revoke logic:

addStoryboardImage: (scene, base64) => set(s => {
 const old = s.storyboardImageUrls[scene];
 if (old) URL.revokeObjectURL(old);
 const blob = base64ToBlob(base64, "image/png");
 return { storyboardImageUrls: { ...s.storyboardImageUrls, [scene]: URL.createObjectURL(blob) } };
}),

Resize + collapse

Two commits added the resize affordance:

feat(web): add useCanvasResizer hook (pointer capture + clamped delta -> ui.canvasWidth) — ui.canvasWidth is clamped to 360..800px in the ui slice
feat(web): add CanvasResizer component (vertical drag handle + warm hover tint) — the visual handle, hover tint follows Creative Warmth (a subtle warm gradient, no pure highlight)
feat(web): WorkspacePage grid column reads ui.canvasWidth + respects canvasCollapsed — the grid actually responds to the width

CanvasHeader got a collapse toggle so power users can hide the canvas entirely when they want to focus on chat.

PR6 — Polish + backend swap + mockup deletion

PR6 was the bridge between “everything in React works” and “we’re actually serving React to users”:

feat(web): ui slice gains fatalError + setFatalError
feat(web): add ErrorScreen (vercel_unsupported + unexpected kinds, ko/en)
feat(web): add AppErrorBoundary class component (catches descendants -> ErrorScreen)
feat(web): useChatStream detects Vercel 503 -> ui.fatalError = vercel_unsupported
feat(server): serve web/dist instead of mockup/ (MOCKUP_DIR -> WEB_DIST_DIR)
feat(deploy): vercel buildCommand + outputDirectory point to web/dist
chore: remove legacy mockup/ vanilla-JS SPA — the mockup, six weeks after birth, was deleted in one commit

The vercel_unsupported error is a specific kind: Vercel’s serverless functions can’t host long-lived SSE connections, so deploying the backend there produces a 503 on the chat route. The frontend detects it explicitly and shows a screen explaining the EC2-only constraint instead of a generic network error.

Theme 2 — The Workflow Consolidates to Five Gates

Through PR4, the workflow had three approval points — one after copy, one after scenario, one at the end of storyboard. May 21 introduced GATE 1 (key concept selection) and made the gate count five.

Why GATE 1 needed to exist

The pre-existing flow ran research → copy directly. The user submitted a brief, research happened, and then the copy stage emitted four parallel drafts (one each for 감성/직설/유머/하이브리드 angles). The problem: the copy drafts inherited the research agent’s interpretation of the brief without ever asking the user which direction they wanted. Two days of revisions per project were going into pushing the copy stage back to a different angle the user hadn’t asked for.

The fix was a new specialist between research and copy:

research → [key_concept_planner produces 10 candidate concepts: 3-3-2-2 distribution]
 → GATE 1 (user picks one)
 → copy stage runs anchored to selected concept

The 3-3-2-2 distribution (3 commercial, 3 emotional, 2 narrative, 2 conceptual) came from CATEGORY_PLAN. A later refactor (refactor(agents): derive key_concept distribution from CATEGORY_PLAN) made the distribution computed from the plan rather than hardcoded, so adjusting the mix in one place propagates.

Frontend — ApproveGateKeyConcept

The 10-card selection UI shipped as ApproveGateKeyConcept:

feat(web): add KeyConcept gate types
feat(web): ApproveGateKeyConcept 10-card selection drawer
feat(web): wire GATE 1 key-concept gate into ApproveGate

Backend pieces:

feat(runtime): emit GATE 1 key-concept gate after research stage
fix(runtime): only block key_concept_planner re-enqueue while job is in flight — prevented a race where a slow re-render dispatch was being filtered out
feat(runtime): route selectedKeyConcept to copy and feedback re-entry — copy stage receives the selected concept
feat(agents): copywriter_agent anchors copy to the selected key concept
feat(runtime): persist key_concept_set artifacts + record GATE 1 key-concept selections in diff_history

GATE 3 (concept approval) and GATE 5 (final approval)

Two more gates filled the workflow:

feat(runtime): add GATE 3 컨셉 승인 — two-phase scenario stage — scenario got split into concept-approval-then-full-scenario
feat: add GATE 5 (최종 승인) to the storyboard stage — the final approval before the project is considered done

Combined with GATE 2 (copy) and GATE 4 (full scenario), this gave the canonical 5-gate flow that all the UI labels would refer to from this point on.

gate_state — 12-state live transitions

feat(runtime): wire gate_state 12-state live transitions split the gate lifecycle from job lifecycle. The 12 states encode every meaningful transition (pending → emitted → awaiting_user → user_approved → user_revising → rerunning → reapproved → …), each surfaced to the frontend so the UI can render a meaningful “what’s happening with this gate” without polling for inferred state.

The planning report at GATE 1

feat: add report_writer agent + 리서치 분석 보고서 at GATE 1 added a second specialist that runs alongside key_concept_planner — it produces a structured 리서치 분석 보고서 (research analysis report) that gives the user the context behind the 10 key concepts. Without this, the user is picking from concepts cold; with it, they see the underlying reasoning.

Then a follow-up — feat: add report_writer planning mode for 최종 기획 보고서 — taught the same agent to produce a different kind of report at the end of the workflow (a planning report summarizing the entire project).

HTML template set

The reports needed to look like documents, not chat bubbles. A whole HTML template set arrived in successive commits:

feat: add base.css slide canvas and primitives
feat: add storyboard cover and continuity-grid templates
feat: add deck.css and four simple deck templates
feat: add photo-caption and fullbleed-caption deck templates
feat: add annotated-photo, product-lineup, info-card, creative-board templates
feat: add report_writer HTML conversion design spec + implementation plan
feat: add template gallery index + LLM-facing template catalog

The template catalog is the LLM-facing piece — the agent gets a structured list of templates to choose from when assembling a multi-page document. That’s how it can produce a storyboard cover, continuity grid, treatment grid, and conti sequence all from one prompt without hand-coding a layout per page.

Theme 3 — ApproveBar Replaces the Drawer; Output Tabs Replace the Inline Render

By 2026-05-21 the bottom drawer pattern (ApproveSheet) had become a UX problem: opening it covered the canvas, and the canvas was where the result lived. The user had to keep collapsing the drawer to look at the storyboard they were approving.

Three commits killed the drawer:

feat(web): add slim ApproveBar, replace ApproveGate in ChatPanel — a horizontal bar at the bottom of the chat panel
refactor(web): remove ApproveSheet/StageCanvas drawer stack
feat(web): show output panel on active gate + scenario gate advances

The ApproveBar is just two buttons (Approve / 수정요청) plus the gate context — minimal, no drawer to drag. The actual artifact to inspect lives in the canvas (right column), where it always did.

Output tabs — canvas pivots from “show current stage” to “tabbed history of all stages”

Right after the ApproveBar landed, the canvas itself was re-architected:

feat(web): add output-tabs definitions and visibility logic
feat(web): add activeOutputTab to ui slice
feat(web): add output fields to pipeline slice
feat(web): hydrate output slots from artifacts
feat(web): route gate/planning outputs into pipeline slice
feat(web): add analysis/keyConcept/planning/concept tab bodies
feat(web): add selectable copy tab body
feat(web): add OutputTabs container
feat(web): swap CanvasPanel body to OutputTabs

Previously the canvas only ever showed the current stage’s artifact. Now it has tabs across the top — Analysis, Key Concept, Concept, Copy, Scenario, Storyboard — and the user can flip back to look at any prior artifact while still working on the current stage. That changes the UX entirely: the canvas became a project workspace, not just a current-state display.

The Planner-Generator-Evaluator loop

The runtime equivalent of this UX move is the Planner-Generator-Evaluator loop:

feat: Planner-Generator-Evaluator loop + BDI structure
feat(web): register copy_evaluator in agent-copy map
feat(runtime): extend the evaluator loop to the scenario stage (§3.4)
feat(runtime): extend the evaluator loop to the storyboard stage (§3.4)
fix(runtime): re-assess regenerations in the evaluator loop

The pattern: every generation stage now runs Planner → Generator → Evaluator. The Evaluator decides whether the output meets quality bars; if not, the loop re-runs Generator with feedback. The user sees the final output after the loop converges (or hits a max iteration cap). This is also what made the output tabs valuable — the planning artifact and evaluation notes for each stage are visible if the user wants to dig in.

Theme 4 — The Revise-Mode System

This is the biggest UX commitment in this window. Before this work, “I want to redo just one card” meant “redo the whole stage” — the user had no way to surgically pin everything except the piece they wanted regenerated.

Intent classification

The first piece (feat: add revision-intent — classify chat revision as bulk/partial) is a small classifier on chat input. When the user types in a gate context, the system asks: is this a bulk request (“make all the copy more emotional”) or a partial request (“change just the third one”)? The output drives different runtime paths:

Bulk → re-run the entire stage with the feedback as context
Partial → enter “revise mode” in the UI, let the user pick which items to regenerate

// runtime/orchestration/revision-intent.js (paraphrased)
function classifyRevisionIntent(message, gateContext) {
 if (hasPartialMarkers(message)) return { kind: "partial", confidence: high };
 if (hasBulkMarkers(message)) return { kind: "bulk", confidence: high };
 return { kind: "ambiguous" }; // UI nudges the user to clarify
}

Revise-mode UI

The frontend gained a revise-mode toggle on the ApproveBar and multi-select checkboxes on every selectable tab:

feat: pipeline store — reviseMode + reviseSelection state
feat: add RevisionContext type + ChatContext.revision field
feat: ApproveBar revise-mode toggle with selection count
feat: KeyConceptTab multi-select checkboxes in revise mode
feat: CopyTab multi-select checkboxes in revise mode
feat: ScenarioCanvas cut-level revise checkboxes
feat: StoryboardCanvas panel-level revise checkboxes

reviseSelection is a Set<id> per artifact kind. The user toggles individual cards; the count appears live in the ApproveBar so they always know how many items will be regenerated.

Revision-merge — the index splice

The runtime side needed a way to actually merge the regenerated subset back into the existing set. That’s the revision-merge module:

// runtime/orchestration/revision-merge.js (paraphrased)
function mergeRevision(originalSet, regeneratedSubset, selectedIndices) {
 const merged = [...originalSet];
 regeneratedSubset.forEach((newItem, i) => {
 merged[selectedIndices[i]] = newItem;
 });
 return merged;
}

Pure function — splice at the indices that were selected, leave the rest frozen. Tested end-to-end: test: end-to-end partial revision keeps frozen items + 3-3-2-2.

Each agent learned partial regeneration

Five specialist agents learned to regenerate only the selected slots:

feat: key_concept_planner regenerates selected slots (category-preserving) — preserves the 3-3-2-2 distribution
feat: copywriter_agent regenerates selected copy drafts
feat: concept_anchor applies revision feedback (GATE 3, whole-doc) — GATE 3 is whole-doc only because concept anchor is itself a single artifact
feat: scene_designer cut-level revision (structure + cut count preserved) — preserves total cut count
feat: storyboard_generator regenerates selected panels + images

Each agent had to know what its frozen-item constraints were. Storyboard could regenerate just panel 3 without recomputing the cut count, but scene_designer had to preserve total cut count because the scenario’s structural contract is the cut count.

Routing layer

Two routing commits put it together:

feat: root-planner routes context.revision to single target agent — backend only enqueues the one specialist needed
feat: route chat revision intent — bulk runs, partial nudges revise mode — frontend dispatches to the right path
feat: dispatch revise_mode_hint — open revise mode on partial chat intent — backend can suggest revise mode to the frontend via a hint event, so a partial intent auto-opens the UI

The hint event was a careful boundary — backend never forces the frontend; it suggests. The frontend can override if its local state has reason to.

Theme 5 — Session Isolation (multi-attempt per project)

On 2026-05-22 the workspace went from one-session-per-project to multi-session-per-project. A project can now hold parallel attempts — a single creative brief might be tried three different ways, each as its own session, with their own pipeline state.

Key commits:

Isolate workspace sessions and restore state per session
server: project sessions list endpoint
web: session restore and run recovery
Start a fresh pipeline for a new session's first brief
launcher: show per-session states on project cards
launcher/workspace: deletable sessions + per-session gate
web: scope workspace canvas to the active session
web: honor session routes and preserve revision scopes

The launcher card now shows per-session gates — a project that had three sessions, two at storyboard and one at copy, renders all three states. Sessions can be deleted individually. The workspace canvas, the revise mode, and the gate state all scope to the active session.

The biggest invisible commit: Lock the session after final storyboard approval. Once GATE 5 is approved, the session is read-only. This prevents accidental edits to a sealed deliverable, and forces the user to consciously start a new session if they want to iterate further.

Insights

Four themes in three days, but the recurring shape is the same: collapse of “all-or-nothing” into something granular.

The drawer-or-canvas binary became the output-tabs continuum (you can see every artifact at once)
The three gates became five (with the new gate guarding the most expensive downstream cost: copy + scenario + storyboard run on a chosen direction)
The whole-stage-re-run became partial revision (you regenerate exactly what you want)
The one-session-per-project became multi-session-per-project (a project can hold parallel ideas)

Each of these moves cost more code than the binary version would have — partial revision alone required intent classification, frozen-item preservation logic in five agents, a Set-of-IDs in the store, and an index-splice merge function — but each one removed a class of frustration the user had been quietly bearing. The 153-commit count looks heroic; the through-line is more modest: every time the system said “all or nothing,” replace it with “exactly what you meant.”

Next: polish week — observability instrumentation, per-project state isolation under refresh, inline past-gate rewind from chat, and the revision-request affordance pass that finally unified the visual treatment across every tab.