Creative Agent Studio 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.

Creative Agent Studio #3 — The 134-Commit Megapush: PR1 Launcher, PR2 Workspace, PR3 SSE, PR4 ApproveGate

Tue, 19 May 2026 00:00:00 +0900

Overview

Previous post: #2 — Bitbucket migration, production-readying, React rewrite begins ended with the React infrastructure bootstrapped: empty Zustand store, Vite + Tailwind + TS, three primitives, a <T> i18n component, and a PR1 plan. Twenty-four hours later, 134 non-merge commits had landed four PRs in sequence and produced a working React frontend with real database persistence and live SSE streaming.

The work fell into four PRs and one stack underneath:

PR1 — Launcher (projects CRUD, ProjectCard, NewProjectCard, CreateProjectModal, ProjectGrid)
PR2 — Workspace shell (StageStepper, ProjectSubbar, SessionsRail, Composer, ChatPanel, CanvasPanel placeholder)
PR3 — SSE + chat flow (chat-stream parser, dispatch-sse mapper, useChatStream hook, AgentAvatar, all 7 FeedItem variants, ChatFeed)
PR4 — ApproveSheet + Gates (3-mode drawer, ApproveGateCopy / Scenario / ResearchInput variants)
Underneath — projects, artifacts, diff_history tables; CRUD operations; full REST API; soft-delete semantics

graph TD
 Prev["#2 — bootstrap (752095f)"] --> DB["DB layer <br/> migrations + CRUD + REST"]
 DB --> PR1["PR1 — Launcher <br/> projects survive reload"]
 PR1 --> PR2["PR2 — Workspace shell <br/> StageStepper + SessionsRail + Composer"]
 PR2 --> PR3["PR3 — SSE chat flow <br/> chat-stream + dispatch-sse + 7 feed variants"]
 PR3 --> PR4["PR4 — ApproveSheet <br/> 3-mode drawer + 3 gate variants"]
 PR4 --> End["#3 end (9a2f851) <br/> restore project gate from artifacts"]

One running theme — build the surface bottom-up, and never let a commit cross a layer it shouldn’t.

The Database Layer — Same Day as the UI

Three migrations and a small handful of CRUD modules made projects, artifacts, and diff_history first-class. The first commit (feat(db): add projects, artifacts, diff_history tables via migrations) set the shape:

CREATE TABLE projects (
 id INTEGER PRIMARY KEY,
 title TEXT NOT NULL,
 brand TEXT,
 gate TEXT, -- which gate the project last paused at
 created_at INTEGER NOT NULL,
 updated_at INTEGER NOT NULL,
 deleted_at INTEGER -- soft delete
);

CREATE TABLE artifacts (
 id INTEGER PRIMARY KEY,
 project_id INTEGER REFERENCES projects(id),
 stage TEXT NOT NULL,
 kind TEXT NOT NULL,
 payload TEXT NOT NULL, -- JSON
 evidence_uri TEXT, -- §8.2 — provenance
 created_at INTEGER NOT NULL
);

CREATE TABLE diff_history (
 id INTEGER PRIMARY KEY,
 project_id INTEGER REFERENCES projects(id),
 gate TEXT NOT NULL,
 before TEXT, -- JSON (nullable for first selection)
 after TEXT NOT NULL, -- JSON
 created_at INTEGER NOT NULL
);

Three commits later, the CRUD module landed: createProject, listProjects (active only, updated_at desc), getProject (returns deleted rows for audit), renameProject (partial patch semantics), softDeleteProject (idempotent — no double-flip of deleted_at).

The idempotency rule was specifically tested in fix(db): softDeleteProject preserves deleted_at on idempotent re-call. The original implementation called UPDATE ... SET deleted_at = ? which would overwrite an earlier deletion timestamp if called twice. The fix: UPDATE ... SET deleted_at = ? WHERE deleted_at IS NULL. Small bug, larger principle — soft-delete is a tombstone, not a flag.

Then the REST API came up on top in five commits:

POST /api/projects → createProject
GET /api/projects → listProjects
GET /api/projects/:id → getProject (404 if deleted — fix(api))
PATCH /api/projects/:id → renameProject
DELETE /api/projects/:id → softDeleteProject

A separate fix made GET and PATCH treat soft-deleted projects as 404 (audit-visible via the lower-level CRUD path, but invisible at the REST surface). The diff_history module added appendDiff with a guard against storing literal 'null' strings when after was null — the kind of bug that’s only obvious when you find someone’s project history showing the string "null" rendered in the UI.

PR1 — The Launcher

The user’s first screen. Project list, create-new affordance, search.

A handful of structural commits set up the page architecture:

feat(web): real projects slice (CRUD) — useProjects hook with sort-by-updated
feat(web): add userName + setUserName to ui slice — persisted user name shown in the bilingual greeting
feat(web): add AppTopbar with logo + lang toggle — site chrome
feat(web): add LauncherTopbar + LauncherHero with bilingual greeting
feat(web): add SessionsRail hidden-mode stub (PR2 fills workspace mode)

Then the actual list and creation flow:

feat(web): add ProjectsSearch with bilingual placeholder and count kicker
feat(web): add ProjectCard with progress bar and brand/status
feat(web): add NewProjectCard with dashed border and accent hover
feat(web): add CreateProjectModal with title + optional brand + validation
feat(web): wire ProjectGrid — search filter, modal, navigation

The card progress bar reads from the same gate field the project advanced to — so the launcher card is a live snapshot of how far along each project is. Click → navigate to /projects/:projectId. Done.

What’s clean about this PR is its strict layering: every interactive piece reads from the store, the store reads from the REST API, the REST API reads from the CRUD module, the CRUD module reads from SQLite. No shortcuts. The component itself only knows about the slice.

PR2 — The Workspace Shell

The screen users land on after clicking a project card. Three columns: sessions rail on the left, chat in the middle, canvas placeholder on the right. The actual stage-by-stage workflow lives inside this shell.

Eleven commits, structural:

feat(web): add stage-labels lib (gate ↔ stage + ko/en short/long labels) — the canonical mapping of stages to their bilingual labels, used by both the stepper and the canvas
feat(web): add Session type + real workspace slice (sessions + composer) + store-init test
feat(web): add sessionsPanelOpen + toggleSessionsPanel to ui slice — the rail collapses
feat(web): add StageStepper (6 dots + bilingual long-form label) — the stage progress indicator
feat(web): add ProjectSubbar wrapping StageStepper
feat(web): fill SessionsRail workspace mode (project header + sessions list + new + back)
feat(web): add Composer (pill input + send button, console-log submit only) — chat input, no submission wiring yet
feat(web): add ChatPanel skeleton (header + welcome bubble + Composer)
feat(web): add CanvasPanel placeholder (PR5 fills variants) — explicit deferral
feat(web): assemble WorkspacePage (.shell grid) + swap workspace route

The placeholder pattern is worth noticing. CanvasPanel was added as a placeholder that explicitly said “PR5 fills variants” in the commit message. That deferred a large piece of work without leaving a hole in the layout — the layout was done, the slot was wired, the actual content was a stub that wouldn’t ship to users yet. PR5 could land cleanly because PR2 had reserved its address.

PR3 — SSE Plumbing, Chat Flow, and the Seven Feed Variants

This is the PR that turned a static shell into a live app. Twenty-something commits across three layers — store, plumbing, components.

Store layer

// web/src/store/slices/feed.ts (paraphrased)
type FeedItem =
 | { kind: "user", text: string }
 | { kind: "assistant", text: string }
 | { kind: "streaming", text: string }
 | { kind: "agent_progress", agent: string, status: string }
 | { kind: "stage_complete", stage: string }
 | { kind: "system_error", message: string }
 | { kind: "task_update_note", text: string };

type FeedSlice = {
 feed: FeedItem[];
 appendChunk: (text: string) => void; // streaming
 splitParagraphs: () => void; // streaming → final
 pushAgentProgress: (agent, status) => void;
 pushStageComplete: (stage) => void;
 // ...
};

A discriminated union for the seven feed item types, with per-kind reducers on the slice. Plus a pipeline slice for the gate/stage/context/lastSubmit state, and a workspace slice that gained tasks + activeSubAgents (sink for agent_activity envelopes).

Plumbing layer

Three pure modules and one hook:

feat(web): add chat-stream lib (POST /api/chat + SSE parse + Zod-validated envelopes) — the wire-level parser
feat(web): add dispatch-sse mapper (SSEEnvelope → store actions) — pure mapper, no DOM
feat(web): add useChatStream hook (submit/cancel + AbortController lifecycle) — lifecycle owner

// web/src/hooks/use-chat-stream.ts (paraphrased)
export function useChatStream() {
 const controllerRef = useRef<AbortController | null>(null);

 const submit = useCallback(async (text: string, context: ChatContext) => {
 controllerRef.current?.abort();
 const controller = new AbortController();
 controllerRef.current = controller;

 for await (const envelope of streamChat({ text, context, signal: controller.signal })) {
 dispatchSse(envelope); // store action
 }
 }, []);

 const cancel = useCallback(() => controllerRef.current?.abort(), []);

 return { submit, cancel };
}

The split was: chat-stream parses, dispatch-sse maps, useChatStream owns the lifecycle. Three things, three modules — no module ever did more than one job. Tests for each (tighten test fetch types etc) shipped on the same day.

Component layer

Once envelopes could land in the store, the components rendered them:

feat(web): add AgentAvatar + fix shared/events runtime exports
feat(web): add User/Assistant/Streaming bubble components
feat(web): add AgentProgress + StageComplete + SystemError + TaskUpdateNote
feat(web): add FeedItem discriminated dispatcher (7 variants)
feat(web): add AgentStrip ('Running now' active sub-agents)
feat(web): add ChatFeed (auto-scroll + FeedItem map + welcome empty state)
feat(web): wire ChatPanel to AgentStrip + ChatFeed (replaces static welcome bubble)

The FeedItem dispatcher is the discriminated-union pattern paying off — one place that maps every variant to its component, with exhaustiveness enforced by TS.

The AgentStrip was the materialization of decision 2 from interaction-model.md — “one-line status, no full dashboard.” It shows only the currently-running sub-agents as a horizontal strip across the top of the chat. Not a side panel, not a dashboard, just an inline strip that appears when work is happening and disappears when it isn’t.

PR4 — The ApproveSheet and the Three Gate Variants

The piece that turned the chat-only flow into a chat + approval flow.

The ApproveSheet is a bottom drawer with three modes — collapsed (just the gate prompt), half-open (gate + summary), full (gate + everything). Drag-to-resize via pointer events. Esc collapses. Three gate variants drop into the same shell — each gate stage gets its own variant component.

Twelve commits, structural again:

feat(web): add ApproveGate payload types
feat(web): add approveSheetMode + setApproveSheetMode to ui slice
feat(web): pipeline slice gains copy/scenario history + idx setters — the back-pointer state for switching between historical drafts
feat(web): projects slice gains bumpProjectGate + assert PR4 fields in store-init
feat(web): dispatch-sse pushes copy/scenario history + bumps project gate on stage_complete — the SSE → store glue for gate advance

Then the drawer mechanics:

feat(web): add useApproveSheetDrag hook + PointerEvent jsdom polyfill — the drag-handle hook. PointerEvent isn’t in jsdom by default, so a polyfill shipped alongside.
feat(web): add ApproveSheet base (3-mode drawer + collapse toggle + drag handle)

And the three gate variants:

feat(web): add ApproveGateCopy (grid + select + approve / request-edit) — the user picks one of N copy drafts
feat(web): add ApproveGateScenario (acts list + approve / request-edit) — the user approves or revises a multi-act scenario
feat(web): add ApproveGateResearchInput (question + answer + send) — a different shape: the agent asks the user a research question and waits for a typed answer

Wired together by ApproveGate dispatcher (variant selection + submit wiring), then mounted inside ChatPanel with submit forwarded from WorkspacePage. The user’s flow is now: ask in chat → agent runs → drawer rises with the artifact → approve or revise. Decision 3 from interaction-model.md (gate-based auto-run between stages) is alive.

The End-of-Day State

The last commit of the day (9a2f851 feat(web): restore project gate from artifacts on workspace mount (Slice K)) closed an important loop: when the user reloads the workspace page, the project’s gate state is restored from its persisted artifacts. The day’s work survives a refresh.

Between the underneath stack and PR1–PR4, the React frontend at end-of-day had:

A working launcher (real projects, persisted across reloads)
A workspace shell with a three-column layout
Live chat with SSE streaming
All 7 feed variants rendering
An ApproveSheet drawer with 3 gate variants
Project state surviving reload

The mockup wasn’t deleted yet, but everything it was supposed to demonstrate now ran in React.

Insights

The day worked because every commit respected its layer. The store slices were declared in PR2 with the shape they’d need for PR4. The SSE plumbing in PR3 was three modules — parser, mapper, lifecycle — that could each be tested independently. The ApproveGate variants in PR4 plugged into a dispatcher pattern matching the FeedItem dispatcher from PR3.

The thing that didn’t happen — and was the reason 134 commits in a day was not chaos — was cross-layer commits. No commit added a <button> and a SQL column at the same time. No commit reached up from a CRUD module into a slice. When a commit needed to span layers, it was either preceded by a foundation commit one layer below or followed by an adopter commit one layer above. The discipline turned what would otherwise be a sprint of patchwork into a clean stack of additions.

The mental model worth keeping: fast does not mean shortcut. This day shipped four PRs because of the discipline that let each PR exist, not in spite of it.

Next: the canvas panel, the 5-gate workflow, the key-concept planner, and the revise-mode multi-select pattern that would let users surgically re-run a single card instead of the whole stage.

Creative Agent Studio #2 — Bitbucket Migration, Production-Readying, and the React Rewrite Begins

Mon, 18 May 2026 00:00:00 +0900

Overview

Previous post: #1 — the mockup era and Creative Warmth theme shipped six weeks ago. After a long quiet stretch, 2026-05-18 detonated with 27 commits in a single day — and they fell into three clean stacks. First, a bitbucket migration snapshot to mark the repo’s relocation. Second, a production-readying pass on the Node runtime — structured JSON logging, graceful worker shutdown via AbortSignal, /api/health + /api/metrics, single-EC2 deploy assets (systemd, nginx, litestream), and three refactors splitting the monolithic queue. Third, the React+Vite+TypeScript bootstrap that would replace the mockup entirely within 72 hours — Tailwind with Creative Warmth tokens carried over verbatim from April, a Zustand store with 5 empty slices, the <T> i18n component, and the first design primitives.

graph TD
 Prev["#1 — April mockup <br/> (21f0ebc)"] --> Stack1["Stack 1 <br/> bitbucket migration snapshot"]
 Prev --> Stack2["Stack 2 <br/> runtime hardening <br/> logger / shutdown / health / deploy"]
 Prev --> Stack3["Stack 3 <br/> web/ bootstrap <br/> React + Vite + Tailwind + Zustand"]
 Stack1 --> End["#2 end <br/> (752095f)"]
 Stack2 --> End
 Stack3 --> End

The day’s running theme: stop treating this as a prototype.

Stack 1 — The Bitbucket Migration Snapshot

The first commit of the day (9d414f2 chore: snapshot project state for bitbucket migration) wasn’t a code change — it was a marker. Repos move for reasons beyond engineering, and the snapshot commit made the cutover legible: this is the state shipped from the old home, and everything after is the new home.

Worth noting because future “what changed?” investigations can stop at this commit when looking for “code that survived the move” vs “code added after.”

Stack 2 — Production-Readying the Runtime

Structured JSON logger + adoption

Commits ead6854 and d0b9ea4 introduced a structured JSON logger and adopted it in the chat route + worker lifecycle paths. The pre-existing pattern was console.log strings, which would not survive an actual deploy to a log aggregator.

// runtime/observability/logger.js (paraphrased shape)
function createLogger({ component }) {
 return {
 info: (msg, ctx) => emit({ level: "info", component, msg, ...ctx, ts: Date.now() }),
 warn: (msg, ctx) => emit({ level: "warn", component, msg, ...ctx, ts: Date.now() }),
 error: (msg, ctx) => emit({ level: "error", component, msg, ...ctx, ts: Date.now() }),
 };
}

The contract was deliberately minimal — one severity, one message string, one context object. The chat route was the first adopter because that’s where SSE frames are emitted, and any unstructured console.log there would interleave with frame headers in stdout and corrupt logs.

Graceful worker shutdown via AbortSignal

Commit d9bf640. The pre-existing worker loop was an infinite while (true) claim-and-run. kill -TERM on the worker process would kill it mid-job, leaving the SQLite jobs row in running state with a stale worker_lock — eventually reclaimed by the stale-timeout mechanism, but with a delay measured in minutes.

The fix wired an AbortSignal through the loop:

// runtime/workers/worker-loop.js
export async function startWorkerLoop({ role, signal }) {
 while (!signal.aborted) {
 const job = await claimNextJob(db, role);
 if (!job) {
 await sleep(POLL_INTERVAL_MS, { signal });
 continue;
 }
 try {
 await runJob(job, { signal });
 } catch (err) {
 if (signal.aborted) {
 await releaseJobForReclaim(db, job.id); // explicit unlock
 return;
 }
 throw err;
 }
 }
}

Combined with a SIGTERM handler in server/index.js that calls controller.abort() and waits for workers to settle, this turns a 5-minute reclaim window into an immediate clean shutdown — important for any rolling deploy.

Daily maintenance + /api/health + /api/metrics

Three more commits closed the operational gaps:

3ac2dfa — periodic event-log retention. The events table grows monotonically as SSE frames are persisted. Without retention, a long-running deploy fills disk. Cron-like job runs daily, deletes events older than N days.
89c7b05 — /api/health (boot probe) and /api/metrics (Prometheus-style counters). A load balancer can now do its job, and a Grafana dashboard can finally exist.
d0b9ea4 — wired all three (shutdown, maintenance, logger) into server/index.js boot.

The Grafana setup itself got its own doc (4236122 docs: add Grafana Cloud setup guide for EC2 deployment) because the metric set was small enough to deploy once and forget — the runtime’s only telemetry concerns were queue depth, job duration, and gate-time-to-approval.

Single-EC2 deploy assets

Commit 9ac967f added the entire single-EC2 deploy stack: systemd unit files for the Node server + workers, an nginx config that terminates TLS and proxies to :7878, and a Litestream configuration that replicates data/runtime.sqlite to S3 continuously. Litestream is the linchpin — it makes SQLite a defensible production choice for a small-team app by giving you continuous point-in-time backup without changing application code.

Runtime refactors

Three companion refactors made the codebase ready for the upcoming PR0–PR4 spree:

1cf3bce refactor: split runtime/queue/jobs.js into runs/jobs/events modules — jobs.js had become a god-module conflating run lifecycle, job claiming, and event persistence. Split into three single-responsibility modules.
4ee661e refactor: extract stage state machine + route events through persistEvent — the “what stage is the run in, and what can transition out of it” logic was sprinkled across the worker. Extracted into a single state machine module; all event writes now route through persistEvent so a missing event can’t be a silent bug.
c7291af refactor: consolidate Google AI SDK on @google/genai — the codebase had been straddling two Google SDK packages. Consolidated on @google/genai.

The runtime SQLite was also relocated to data/ (2e3ac8a) so the .gitignore-by-intent file could live in a dedicated subdir alongside the WAL/SHM journals.

Stack 3 — Bootstrapping the React Rewrite

The mockup’s days were numbered. A design spec (253f83d docs: add design spec for mockup → web/ (React + Vite + TS) rebuild) and an implementation plan (c81b248 docs: add PR0 implementation plan for web/ infra bootstrap) declared the target. Twenty commits then materialized it.

Package + tooling

web/package.json React 18 + Vite + TypeScript
web/tsconfig.{json,app.json,node.json} Vite-standard 3-file split
web/vite.config.ts /api proxy → :7878 (matches Express port)
web/tailwind.config.ts Creative Warmth tokens
web/vitest.config.ts jsdom + RTL setup

The Tailwind config (17aecd9) is worth calling out — every Creative Warmth token from April’s mockup CSS was hand-translated into Tailwind extensions:

// web/tailwind.config.ts (paraphrased)
export default {
 theme: {
 extend: {
 colors: {
 'warm-white': '#FAF7F2', // body bg
 'warm-paper': '#F5F1EA', // raised surfaces
 'text-primary': '#2A2622', // not pure black
 },
 fontFamily: {
 display: ['"DM Serif Display"', 'serif'],
 hand: ['Caveat', 'cursive'],
 },
 },
 },
};

Zero design tokens were re-derived; they were lifted verbatim. The mockup was throwaway code, but the design system was load-bearing.

Store scaffold

Commit 0b469b8 feat(web): scaffold Zustand store with 5 empty slices set up the state architecture before any feature code:

// web/src/store/index.ts
type Store = UiSlice & ProjectsSlice & WorkspaceSlice & FeedSlice & PipelineSlice;

export const useStore = create<Store>()((set, get, api) => ({
 ...createUiSlice(set, get, api),
 ...createProjectsSlice(set, get, api),
 ...createWorkspaceSlice(set, get, api),
 ...createFeedSlice(set, get, api),
 ...createPipelineSlice(set, get, api),
}));

Five slices — ui, projects, workspace, feed, pipeline — declared empty on day 1, with a test (9543922 test(web): assert store init exposes all five slices) that locked the shape so subsequent commits could add fields without forgetting a slice. That decision would pay back across the next three days when 100+ commits added fields to those slices in parallel.

The `<T>` i18n component

Commit 24ff23e feat(web): add <T> i18n component with KO/EN toggle + tests. The app’s primary language is Korean, but launching with English support up front meant the bilingual prop pattern was established before any component was written:

<T ko="키 컨셉을 선택하세요" en="Select a key concept" />

A small choice — two props vs. an i18n key lookup — but it kept the source-of-truth co-located with the consumer. For a single-developer creative tool, that beat any framework-level i18n abstraction.

Design primitives

Three primitives shipped on day 1 to anchor everything that came after:

bf3ebaa feat(web): add cn() helper + minimal Button primitive — the cn() utility for conditional classnames + a Button that already wore Creative Warmth.
a0cc67e feat(web): add Radix-backed Dialog primitive with warm scrim — Radix for accessibility, custom warm scrim (rgba(42, 38, 34, 0.4) — translucent of text-primary, not pure black) to match the design language.
c2ee60f feat(web): add Input primitive with Creative Warmth styling — input field with the soft-edged warm-paper background.

Shared event schemas

Commit 0c37093 feat(shared): add SSE event Zod schemas + type re-exports — moved the SSE event types into shared/events/index.mjs so backend (Express) and frontend (React) could import the same Zod schema. Type-safe SSE on both ends, validated at the parser layer.

The PR1 prelude

The day ended with the PR1 planning docs (558e7ec docs: add PR1 (Launcher) implementation plan) and the first launcher building blocks: a Project type, filter/sort/progress helpers (752095f). The Launcher page itself — the screen users would see first — was implementation tomorrow.

Commit Log (selected, 27 total)

Stack	Commits
Bitbucket migration	snapshot project state
Runtime hardening	structured JSON logger; AbortSignal shutdown; event-log retention; /api/health + /api/metrics; wire all three at boot
Deploy stack	single-EC2 systemd/nginx/litestream; Node ≥ 22.5 engines field; relocate SQLite to data/; consolidate @google/genai
Refactor	split queue/jobs into runs/jobs/events; extract stage state machine; rename agents to snake_case; archive April plans
Docs	Grafana Cloud setup; web/ rebuild design spec; PR0 implementation plan; PR1 launcher plan
web/ bootstrap	package.json + Vite + tsconfig; Tailwind with Creative Warmth tokens; Vitest + jsdom + RTL; Zustand 5-slice store; T i18n component; cn() + Button + Dialog + Input primitives; SSE Zod schemas in shared/; React Router shell

Insights

A single 27-commit day did three things that would look unrelated in commit messages but were one decision: commit to the production target. The runtime got the observability and shutdown semantics it needed to survive a deploy. The deploy stack itself was drafted as code instead of a wiki page. And the React rewrite started on day 0 with the same design tokens, type-checked SSE, and architectural seams the production version would need.

What’s instructive is what didn’t happen on this day. No feature code. No new agents. No prompt tuning. The principle was: harden the floor first, build features on top of a hardened floor next. The next day’s 134-commit megapush would have been unsafe without this one — running PR1 → PR4 in a single day on top of a god-module queue, a console.log codebase, and a worker that didn’t shut down cleanly would have buried genuine bugs under operational noise.

Next: 134 commits in one day — PR1 Launcher, PR2 Workspace shell, PR3 SSE + chat flow, PR4 ApproveGate, and the database layer underneath all of it.

Creative Agent Studio #1 — The Mockup Era, and Why It Wore the Creative Warmth Theme

Tue, 07 Apr 2026 00:00:00 +0900

Overview

This is the first dev log for Creative Agent Studio — a Korean-language multi-agent system for advertising creative work. A single user message enters a chat-first pipeline that walks four presentation stages — research → copy → scenario → storyboard — gated by explicit human approval between stages.

April was the mockup era. Twelve commits over two days produced a static HTML/JS prototype of the canvas, a runtime-flow spec, a “Creative Warmth” design theme that would survive the eventual React rewrite, and a deployment shape to put it on Vercel. The code thrown away later was not the point — the decisions written down in interaction-model.md and the design tokens baked into the mockup were.

graph TD
 Idea["Brief from user (chat)"] --> Research["Research stage <br/> 리서치 에이전트"]
 Research --> Gate1["GATE 1 <br/> key concept selection"]
 Gate1 --> Copy["Copy stage <br/> 4 draft workers"]
 Copy --> Gate2["GATE 2 <br/> copy approval"]
 Gate2 --> Scenario["Scenario stage <br/> 3 specialists"]
 Scenario --> Gate3["GATE 3-4 <br/> scenario approval"]
 Gate3 --> Storyboard["Storyboard stage <br/> image generation"]
 Storyboard --> Gate5["GATE 5 <br/> final approval"]

Twelve commits, one running theme — lock in the principles before any of the implementation rusts.

The Three Decisions That Would Outlast the Mockup

The most important file added in April wasn’t code — it was interaction-model.md, which crystallized three product decisions into a single load-bearing document:

결정 1. 인터랙션 모델 — 채팅 우선 (Chat-first). The user’s primary input is free-form chat. Clicking buttons to advance stages is forbidden. The orchestrator interprets what they typed and dispatches agents accordingly.

결정 2. 에이전트 투명성 — 한 줄 상태 표시 (One-line status). When an agent is running, the feed shows a single one-line status message. No full dashboards, no real-time logs.

결정 3. 게이트 기반 자동 실행 (Gate-based auto-run). After each stage completes, the pipeline pauses and waits for explicit human approval before running the next stage automatically.

Every UI commit that followed — through April and across the May rewrite — would be checked against these three rules. The first commit of the mockup (b67eb98 Add Diffs creative agent studio mockup) already had them encoded as DOM structure: no “next stage” button, agents appeared as bullet lists rather than a dashboard, and the composer was the only entry point.

“Creative Warmth” — The Design Theme

The third commit (72e0fdc) was the visual baseline that would survive everything: “Redesign: Apply Creative Warmth theme (warm white, DM Serif Display, Caveat).”

Three tokens, three reasons:

Token	Value	Why
Background	Warm white (#FAF7F2)	Pure white reads as software. Warm tints read as workshop.
Body type	DM Serif Display	A creative tool should feel literary, not productivity-coded.
Handwritten labels	Caveat	Specialist agent names get a handwritten badge — a small humanizing touch on what is otherwise a dense work surface.

The rule was negative: no pure black, no pure white, anywhere. A subsequent commit (640c755) had to fix the logo visibility because the original SVG was dark-on-dark — the fix was a filter: brightness(0) CSS hack to invert it for the warm background rather than re-exporting the asset. Pragmatic, but the underlying constraint stayed: the design system would not bend to accommodate an asset that fought it.

These tokens would migrate verbatim into web/tailwind.config.ts six weeks later as the first feat(web) commit on the React side — proof that the design decisions were the right load-bearing layer.

Three UI Cleanups That Made the Mockup Honest

Three commits in succession (3c225c9, 1be5253, d37b4c9) attacked things that violated the three decisions:

- <p class="eyebrow">Project Management</p>
- <ul class="agents">
- <li><span class="dot dot-1"></span>Agent 1</li>
- <li><span class="dot dot-2"></span>Agent 2</li>
- </ul>
+ <ul class="agents">
+ <li>리서치 에이전트</li>
+ <li>Copy Draft Workers</li>
+ </ul>

3c225c9 — Removed the “Project Management” eyebrow that framed the whole thing as a PM tool. Showed agent names as bullets instead of color-coded chips because the chips implied a dashboard.

1be5253 — Removed the “Background Agents” section from the status rail entirely. It violated decision 2 (one-line status, no full dashboard).

d37b4c9 — Composer overhaul. Moved the model selector into the input bar itself, added a file-attach icon, updated the model list. Why this matters: the composer is decision 1’s entire surface area. If the composer doesn’t feel like the right place to type “더 도전적으로” or “이 두 개 합쳐줘”, the chat-first principle fails by accident.

These weren’t features — they were deletions enforcing the spec.

Three docs and one feat commit on 2026-04-07 laid the runtime groundwork:

ecac2e5 docs: add production poc state and routing spec — defined what state the runtime would carry across the four stages.
7e26c12 docs: add runtime state cleanup spec — defined how state would be retired between runs (relevant later when the React app needed to isolate per-session state).
97df876 feat: refine workspace runtime flow — refined the actual flow code.
21f0ebc chore: add deployment and design reference files — committed the deployment shape and a design-reference folder.

The “deployment reference” was a Vercel buildCommand pointing at the mockup directory. That deployment target would survive the rewrite — when the React frontend shipped in May, the only change to vercel.json was outputDirectory: "web/dist".

Commit Log

Date	Message
2026-04-06	Add Diffs creative agent studio mockup
2026-04-06	Fix logo path for Vercel deployment
2026-04-06	Redesign: Apply Creative Warmth theme (warm white, DM Serif Display, Caveat)
2026-04-06	Fix logo visibility: apply brightness(0) filter for dark logo on light bg
2026-04-06	UI: Remove ‘Project Management’ eyebrow, show agent names as bullets, add LLM dropdown
2026-04-06	Remove Background Agents section from status rail
2026-04-06	Composer: move model selector into input bar, add file attach icon, update models
2026-04-07	docs: add production poc state and routing spec
2026-04-07	docs: add runtime state cleanup spec
2026-04-07	feat: refine workspace runtime flow
2026-04-07	chore: ignore local workspace artifacts
2026-04-07	chore: add deployment and design reference files

Insights

April produced one piece of software (a static mockup) and three pieces of writing (interaction-model.md, the routing spec, the runtime cleanup spec). The mockup would be deleted six weeks later — commit chore: remove legacy mockup/ vanilla-JS SPA lands in the megapush — but every paragraph of the writing would still be load-bearing.

The lesson worth keeping: product principles outlive implementation. Writing down “chat-first, one-line status, gate-based auto-run” as decisions — not as features, not as UI requirements, but as decisions with a 결정 heading and a 이유 heading — meant that every subsequent UI commit had a tribunal to pass through. When the React rewrite started in May, those three decisions were copy-pasted directly into the new web/ tree’s principles. The mockup was throwaway; the principles weren’t.

Next: bitbucket migration, production-readying the runtime, and starting the React+Vite+TypeScript rewrite that would replace the entire mockup in one weekend.

Creative Agent Studio on ICE-ICE-BEAR-BLOG

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

Overview

Thread 1 — LLM-Call Observability

Thread 2 — Per-Project State Isolation Under Refresh

Thread 3 — Inline Past-Gate Rewind From Chat

Thread 4 — The Revision-Request Affordance Pass

Soften rewind dialog copy + hide final gate from discard list

Gate titles in the rewind dialog

ApproveBar gate preselection on 수정요청 enter

Unifying the marked-card visual across five tabs

Show every gate marker once and reflect live gate state

Commit Log (23 total)

Insights

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

Overview

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

Resize + collapse

PR6 — Polish + backend swap + mockup deletion

Theme 2 — The Workflow Consolidates to Five Gates

Why GATE 1 needed to exist

Frontend — ApproveGateKeyConcept

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

gate_state — 12-state live transitions

The planning report at GATE 1

HTML template set

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

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

The Planner-Generator-Evaluator loop

Theme 4 — The Revise-Mode System

Intent classification

Revise-mode UI

Revision-merge — the index splice

Each agent learned partial regeneration

Routing layer

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

Insights

Creative Agent Studio #3 — The 134-Commit Megapush: PR1 Launcher, PR2 Workspace, PR3 SSE, PR4 ApproveGate

Overview

The Database Layer — Same Day as the UI

PR1 — The Launcher

PR2 — The Workspace Shell

PR3 — SSE Plumbing, Chat Flow, and the Seven Feed Variants

Store layer

Plumbing layer

Component layer

PR4 — The ApproveSheet and the Three Gate Variants

The End-of-Day State

Insights

Creative Agent Studio #2 — Bitbucket Migration, Production-Readying, and the React Rewrite Begins

Overview

Stack 1 — The Bitbucket Migration Snapshot

Stack 2 — Production-Readying the Runtime

Structured JSON logger + adoption

Graceful worker shutdown via AbortSignal

Daily maintenance + /api/health + /api/metrics

Single-EC2 deploy assets

Runtime refactors

Stack 3 — Bootstrapping the React Rewrite

Package + tooling

Store scaffold

The <T> i18n component

Design primitives

Shared event schemas

The PR1 prelude

Commit Log (selected, 27 total)

Insights

Creative Agent Studio #1 — The Mockup Era, and Why It Wore the Creative Warmth Theme

Overview

The Three Decisions That Would Outlast the Mockup

“Creative Warmth” — The Design Theme

Three UI Cleanups That Made the Mockup Honest

Runtime Flow Refinement — The Bones Underneath the Mockup

Commit Log

Insights

The `<T>` i18n component