# Stage 3: Page & Component Construction (Consuming Design Brief)

**Core Change**: page-builder now directly consumes the design_brief.json produced by Stage 2, embedding ext design decisions into the code generation process rather than patching them after the fact.

## Page Manifest Completeness Assurance (v7.2 New)

Before invoking page-builder, the orchestrator consumes the page_manifest.json pre-generated by stage-2 and performs a completeness check:

```
Action: Page Manifest Validation (consuming stage-2 pre-generated result)
Trigger Condition: page_manifest.json exists (pre-generated by stage-2)
Input:
  page_manifest: output/ui-frontend/page-manifest/page_manifest.json
  prd_json: output/pm-design/design-prd/prd.json (optional, for cross-validation)
  ia_proposals: output/pm-design/design-ia/ia_proposals.json (optional, for cross-validation)
Process:
  1. Read page_manifest.json
  2. Cross-validate with prd.json/ia_proposals.json (if available)
  3. Use prd.json as authoritative source for inconsistencies, update page_manifest.json
  4. Pass to page-builder
Output: output/ui-frontend/page-manifest/page_manifest.json (validated version)
Validation: page_manifest.json generated and pages[] is non-empty
Mode: AI
```

**Fallback when no PM input and stage-2 did not generate page manifest**:

When page_manifest.json does not exist (theoretically should not happen since stage-2 always pre-generates), the orchestrator extracts the page manifest from the user-provided page requirement description:

```
Action: Fallback Page Manifest Generation without PM Input
Trigger Condition: page_manifest.json does not exist
Input:
  Page requirements: Provided by user (string/markdown)
  prd_md: output/pm-design/design-prd/prd.md (optional, text description only)
Process:
  1. Extract all page names and functional descriptions from page requirement description
  2. Assign page_id for each page (slug format, e.g., "User Center" -> "user-center")
  3. Infer route paths (based on page names and common conventions)
  4. Generate page_manifest.json with source marked as "user_input"
  5. [GATE] Human confirmation required for page manifest completeness (without PM output, human confirmation is the sole completeness guarantee)
Output: output/ui-frontend/page-manifest/page_manifest.json
Validation: page_manifest.json generated + human confirmed
Mode: AI->Human
```

page_manifest.json Schema definition: [schemas/page-manifest.json](../schemas/page-manifest.json).

| Input | Source |
|--------|------|
| Page requirements | Provided by user / output/pm-design/design-prd/prd.md |
| **Page Manifest** | **output/ui-frontend/page-manifest/page_manifest.json (orchestrator-generated)** |
| Visual direction / Design tokens / Component library | output/ui-project-init/project-init.json |
| **Design Brief** | **output/ui-frontend/design-brief/design_brief.json (Stage 2 output)** |
| Target framework / Target language / project_dir | Determined during project information collection phase |
| PRD | output/pm-design/design-prd/prd.md (optional) |
| PRD structured data | output/pm-design/design-prd/prd.json (conditionally required, must consume when present) |
| Route structure | output/pm-design/design-ia/ia_proposals.json (conditionally required, must consume when present) |
| Interaction specification | output/pm-design/interaction-spec/interaction-spec.md (optional) |

**page-builder Execution Mode**:

When design_brief.json exists, page-builder enters "design brief-driven mode":
1. Step 1 Page structure planning: Consume design_brief.layout_instructions and brand_color_strategy
2. Step 2 Component generation: Consume design_brief.component_specifications and color_specifications/typography_specifications
3. Step 3 Page assembly: Consume design_brief.animation_specifications
4. Step 4 Quality check: Additionally validate design_brief.visual_bans and differentiation_direction

When design_brief.json does not exist, page-builder falls back to "token-driven mode" (consuming only visual_direction + tokens).

Output: output/ui-frontend/page-builder/ + code written to {project_dir}/src/
Validation: P0 issues=0 + Token reference rate 100% + WCAG AA compliant + Responsive 375/768/1024px + Mandatory visual review completed
[GATE] Human confirmation required for page layout and component scheme

## Mandatory Visual Review (v7.2 New)

After stage-3 completion and before stage-4 enhancement, the orchestrator must execute a mandatory visual review. This is the **only human visual quality gate** in the entire full flow -- stage-4's audit/critique are automated scores and cannot replace human judgment on design aesthetics.

```
Action: Mandatory Visual Review
Trigger Condition: After stage-3 gate passes, before stage-4 execution
Input:
  Page code: {project_dir}/src/
  Running dev server: npm run dev
  design_brief: output/ui-frontend/design-brief/design_brief.json
  visual_direction: output/ui-project-init/project-init.json -> visual_direction
Process:
  1. Ensure dev server is running (npm run dev)
  2. Prompt human to view each page in the browser
  3. Human evaluates on the following dimensions (each rated 1-5):
     - Overall visual impression: Is it visually appealing at first glance?
     - Brand consistency: Does it match the brand tone?
     - Color harmony: Is the color palette comfortable and well-layered?
     - Typography rhythm: Is the font size hierarchy clear and rhythmic?
     - Layout breathing room: Is whitespace sufficient, is information density reasonable?
  4. Any dimension <=2: Flag that dimension as "requires priority enhancement", pass to stage-4's ext Skill as priority fix item
  5. Average score <=2.5: [GATE] Human decides whether to roll back to stage-2 to regenerate design_brief
Output: visual_review_result (persisted to output/ui-frontend/visual-review/visual_review_result.json, also passed inline to stage-4)
Validation: Human has completed visual review
Mode: Human (must be executed by human)
```

**Visual Review and stage-4 Enhancement Connection**:
- Dimensions scored <=2 in the review are prioritized in stage-4's ext invocations
- If "Color harmony" <=2: Stage-4 prioritizes invoking ext-impeccable colorize/bolder
- If "Typography rhythm" <=2: Stage-4 prioritizes invoking ext-impeccable typeset
- If "Layout breathing room" <=2: Stage-4 prioritizes invoking ext-impeccable layout adapt

## design_feedback Propagation Handling (UI->PM Reverse Feedback Channel)

When page-builder output includes design_feedback.json with non-empty suggestions, the orchestrator executes the following propagation flow:

```
Action: design_feedback Propagation
Trigger Condition: output/ui-frontend/page-builder/design_feedback.json exists and suggestions is non-empty
Process:
  1. Read design_feedback.json
  2. Sort suggestions by priority (high->medium->low)
  3. [GATE] Human confirmation required for feedback suggestions:
     - Accept: Copy design_feedback.json to output/pm-design/design-feedback/ for design-orchestrator consumption
     - Reject: Note rejection reason, page-builder continues executing per design_decisions deviation decisions
     - Partially accept: Only propagate accepted suggestions
  4. If human accepts any suggestion:
     - Write design_feedback.json to output/pm-design/design-feedback/design_feedback.json
     - Mark ui-orchestrator checkpoint: feedback_pending=true
     - Next design-orchestrator execution will consume this feedback
  5. If human rejects all:
     - Do not generate feedback file
     - page-builder continues executing per design_decisions
Output: output/pm-design/design-feedback/design_feedback.json (only when human accepts)
Validation: Feedback file generated (if accepted) or rejection reason noted
Mode: AI->Human
```

**Feedback and design-orchestrator Connection**:
- design-orchestrator checks output/pm-design/design-feedback/design_feedback.json on startup
- If it exists, processes feedback suggestions with priority after phase-1 (PRD) completion, triggering change-impact-analysis to assess impact
- Deletes feedback file after processing to avoid duplicate consumption
