Agent Output to Work Analysis Board

This document explains the Full Prompt -> code -> saved work -> analysis board path. It does not introduce a new generation flow. It documents how the existing Agent workflow, save route, and created-work analysis page exchange data.

2026-05-18 update: workflow versions and generated pages now also carry Prompt Intelligence fields: intent_profile, decision_brief, design-system panel/token/trace JSON, prompt-template payload, prompt-quality report, prompt trace, and interaction state. The created-work Style board reads panel data first and falls back to DESIGN.md.

One Sentence

Full Prompt is the code-generation contract, htmlCode/projectFiles are the implementation artifacts, Save work publishes the draft version into generated_pages, and the analysis page reads the saved Prompt, HTML, Design.md, and Skills back into Style, Prompt, and Code boards.

Stage 1: Agent Compiles Context Into Full Prompt

The project creation page sends user messages, uploaded assets, selected model, and Skills to the workflow stream route. The server decides inside runWorkflowGenerate whether the run should use standard planning, complete production-prompt conversion, HTML generation, or React/Vite generation.

Standard requests first produce planning fields: overview, designSystem, designSystemSections, siteArchitecture, contentInput, siteTemplate, and fullPrompt. If the user pasted a complete production prompt, the system can convert it into a SiteGenerationTemplate, then compile that structure back into the final Full Prompt.

Stage 2: Full Prompt Becomes Code

The system currently has three main code paths:

• Standard HTML path: fullPrompt is sent into the HTML generation request, the model returns a full single-file document, and the server normalizes it into htmlCode.
• Direct full-prompt path: a complete production prompt becomes a compact implementation brief, then CSS, body, and optional script are generated in parallel and assembled by htmlFromParts.
• React/Vite path: DeepSeek full prompts default to a real React/Vite file pack. The server runs Vite build, inlines the built CSS and JS into htmlCode, and keeps projectFiles, buildLog, and qaReport.

All paths still produce htmlCode, because iframe preview, community publishing, and the analysis page can all consume a single HTML document.

Stage 3: Output First Becomes A Workflow Draft

After generation completes, the SSE route writes the result to workflow_run_versions. This is a recoverable draft version, not yet a saved work.

Important fields:

• full_prompt: the Full Prompt used by this generation.
• html_code: the final previewable HTML.
• artifact_kind: html or react-vite.
• project_files: React/Vite source files.
• build_log and qa_report: build and quality metadata.
• design_md_zh/en: design documentation for analysis and reuse.
• site_template, site_architecture, content_input: planning-layer data.
• workflow_graph: canvas nodes, state, positions, and edges.

The ProjectWorkflow frontend listens for artifact:complete SSE events and merges these fields into artifacts, so the Full Prompt, Code, and Preview panels are different views of the same version payload.

Stage 4: Save Work Publishes The Draft

When the user clicks Save work, the frontend calls /api/generate/workflow/save. The save route does not regenerate code. It reads the current workflow_run_versions row and copies that version into generated_pages.

Field mapping:

• workflow_run_versions.full_prompt -> generated_pages.prompt
• workflow_run_versions.html_code -> generated_pages.html_code
• workflow_run_versions.project_files -> generated_pages.project_files
• workflow_run_versions.design_md_zh/en -> generated_pages.design_md_zh/en
• workflow_run_versions.workflow_graph -> generated_pages.workflow_graph
• workflow_runs.selected_skill_slugs -> generated_page_skills

After a successful save, the system writes workflow_run_versions.generated_page_id, linking the draft version back to the saved work. That is why a created-work analysis page can reopen the same workflow for editing or update the same work later.

Stage 5: The Analysis Page Reorganizes The Saved Work

The created-work analysis page reads generated_pages. If a linked workflow draft exists, the page prefers the draft's fullPrompt, htmlCode, and designMd so the latest editable version stays aligned.

The page then:

1. Uses generatedPageToTemplate to adapt a saved work into the shared TemplateWithRelations shape.
2. Uses buildWorkAnalysis to infer colors, typography, buttons, layout, motion, regions, and special-skill mapping from HTML and Skills.
3. Uses WorkDesignSystemBoard and WorkPreviewPanel to render designMd + fullPrompt + htmlCode + analysis as Style, Prompt, and Code boards.

The analysis board is therefore evidence organization for a saved work, not a second code-generation step.

Frontend Touchpoints

• Workflow workspace: src/components/project-workflow.tsx
• Save route: src/app/api/generate/workflow/save/route.ts
• Created-work detail page: src/app/[locale]/create/[id]/page.tsx
• Analysis builder: src/lib/work-analysis.ts
• Style / Prompt / Code board: src/components/work-design-system-board.tsx
• Preview panel: src/components/work-preview-panel.tsx

Maintenance Rules

Update this document when any of these change:

• The structure or meaning of Full Prompt.
• The HTML, Direct Prompt, or React/Vite generation path.
• The field mapping between workflow_run_versions and generated_pages.
• The behavior of Save work.
• The created-work analysis page adds or removes Style, Prompt, Code, or Skill board behavior.

The boundary to preserve is: generation happens in the workflow, publishing happens through the save route, and analysis happens on the created-work page. Do not collapse these into one opaque one-shot action.