A visual guide to how Full Prompt, code, saved works, and the created-work analysis board connect.
Agent Output Path
Visual path from Full Prompt to analysis board
This board turns a generation run into traceable assets: the Full Prompt is the contract, code is the implementation, Save publishes the draft as a work, and the analysis page renders Prompt, HTML, Design.md, and Skills back into boards.
Runtime Path
Planning
Agent output
User input, assets, and Skills become overview, designSystem, siteTemplate, and fullPrompt.
siteTemplate
fullPrompt
designSystemSections
Contract
Full Prompt
The Full Prompt is the final code-generation contract for structure, copy, assets, style, and acceptance criteria.
Complete production prompts can become a compact implementation brief, then CSS, body, and script are generated in parallel and assembled by htmlFromParts.
Generation orchestrationsrc/lib/generation/workflow.tsrunWorkflowGenerate / generateReactViteWithModelSSE and versionssrc/app/api/generate/workflow/stream/route.tsinsertVersion / sendStandardArtifactsSave and publishsrc/app/api/generate/workflow/save/route.tsPOST /api/generate/workflow/saveWorkflow frontendsrc/components/project-workflow.tsxmergeArtifact / saveCurrentVersionAnalysis pagesrc/app/[locale]/create/[id]/page.tsxbuildWorkAnalysis + board components
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.
Rendering diagram...
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.
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.
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:
Uses generatedPageToTemplate to adapt a saved work into the shared TemplateWithRelations shape.
Uses buildWorkAnalysis to infer colors, typography, buttons, layout, motion, regions, and special-skill mapping from HTML and Skills.
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.
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.