Build with Kiro: Create a Factory Automation Portal React UI

Educational engineering workshop only. This is a software architecture exercise and not process-release advice.

Summary: This standalone workshop teaches professional developers to rebuild the latest Factory Automation Portal as a React and TypeScript application using Kiro. Developers learn spec-driven UI decomposition, dark-mode design tokens, responsive grid conversion, accessible tab navigation, reusable Runtime, Tools, Governed Workflows, Process Windows, and Runbook panels, expandable analysis rows, SVG chart containers, simulated process-window updates, and Kiro hooks for UI consistency, documentation, and regression testing with production-quality learning outcomes.

---

Workshop purpose

This 2-hour workshop focuses on the frontend system design of the latest portal. Developers convert the single-file HTML/CSS/JavaScript implementation into a maintainable React + TypeScript application while preserving the automation-portal user experience:

● Top bar with AWS logo, portal identity, workflow subtitle, green live status dot, and HKT clock.

● Hero section with Factory Engineering positioning, service chips, mission card, and safety boundary chips.

● Status strip with six exact portal metrics: Runtime Entry Points, Tools, Specialists, Policy Checks, Evaluation Sets, and Session State.

● Tab navigation with six panels: Overview, Runtime, Tools, Governed Workflows, Process Windows, and Runbook.

● Overview cards for Runtime Workbench, Tool Inventory, and Governed Workflow.

● Runtime panel with six runtime cards, payload contract, and deterministic tool pattern.

● Tools panel with four tools, Tool flow, and JSON-RPC debug payload.

● Governed panel with four specialists, policy boundary, and telemetry event shape.

● Process Windows panel with status tiles, searchable/sortable automation leaderboard, expandable analysis panels, SVG charts, and simulated live updates.

● Runbook panel with 2-hour build path, promotion gate, and production backlog.

● Footer boundary stating data and charts are placeholders and no autonomous equipment operation is implemented.

The learning goal is not just to “copy UI.” The goal is to teach developers how to use Kiro spec-driven development, steering files, and hooks to convert a dense prototype into production-ready component boundaries for experienced Developers.

---

Coverage map

This workshop covers these parts of the latest portal:

● Document metadata: title and description use AWS service and technical terms: Amazon Bedrock, runtime, tooling, AWS Lambda, IAM, SigV4, Amazon SageMaker, Amazon Timestream, AWS Glue, AWS Lake Formation, AWS DataZone, OpenTelemetry, Apache Iceberg, Etch Process Window Automation.

● Page shell: .page, .shell, dark grid background, cyan and green radial glow layers, max-width 1440px, border #315875, and deep shadow 0 26px 90px rgba(0,20,36,.72).

● Sticky top bar: .topbar, .brand, .logo, .brand-main, .brand-sub, .status, .dot; AWS logo block; product name FACTORY AUTOMATION PORTAL; subtitle RUNTIME / TOOLS / POLICY / MEMORY / OBSERVABILITY / EVALUATIONS; live HKT status.

● Hero: eyebrow Automation Portal; title Factory Engineering; service chips RUNTIME, TOOLING, AI ASSISTANCE, TOOLS, SIGV4, JSON-RPC, AWS LAMBDA, AMAZON BEDROCK; mission card; boundary chips NO EQUIPMENT COMMANDS, EVIDENCE FIRST, BOUNDED MEMORY, HUMAN REVIEW.

● Summary statistics: Runtime Entry Points 3, Tools 4, Specialists 4, Policy Checks 2, Evaluation Sets 5, Session State ON.

● Tab navigation: Overview, Runtime, Tools, Governed Workflows, Process Windows, Runbook.

● Overview panel: Enterprise Automation Control Plane, Runtime Workbench, Tool Inventory, Governed Workflow, Architecture Layers, Adoption Notes.

● Runtime panel: runtime Automation, runtime cards, Runtime Payload Contract, Deterministic Tool Pattern.

● Tools panel: Tool Inventory, four tools, Tool Flow, Debug Payload for process_window_drift.

● Governed panel: Governed Photolithography Drift Automation, four specialists, Policy Boundary, Telemetry Event Shape.

● Process Windows panel: Etch Process Window Automation Leaderboard, status tiles, search field, sort buttons, automation rows, analysis expansion, charts.

● Runbook panel: Automation Portal Runbook, timeline steps, Promotion Gate, Production Backlog.

● Responsive breakpoints: desktop, tablet at max-width 1120px, and phone at max-width 560px.

---

Target developers

● Frontend developers building cloud automation dashboards.

● Full-stack developers modernizing prototype HTML into a typed app.

● UI engineers learning how Kiro can help with specs, steering, hooks, and refactoring.

● Developers who need to preserve runtime, tools, policy, memory, observability, and evaluation meaning while improving maintainability.

---

Two-hour agenda

---

Architecture

React application
├─ src/app/App.tsx
├─ src/styles/tokens.css
├─ src/styles/layout.css
├─ src/styles/portal.css
├─ src/styles/charts.css
├─ src/data/portal.ts
├─ src/domain/formatting.ts
├─ src/domain/charts.ts
├─ src/domain/simulator.ts
├─ src/components/GraphicWorkspaceShell.tsx
├─ src/components/TopBar.tsx
├─ src/components/HeroPanel.tsx
├─ src/components/StatsStrip.tsx
├─ src/components/PortalTabs.tsx
├─ src/components/OverviewPanel.tsx
├─ src/components/RuntimePanel.tsx
├─ src/components/ToolsPanel.tsx
├─ src/components/GovernedAgentsPanel.tsx
├─ src/components/ProcessWindowPanel.tsx
├─ src/components/StatusTileStrip.tsx
├─ src/components/AutomationCellRow.tsx
├─ src/components/AnalysisPanelShell.tsx
├─ src/components/RunbookPanel.tsx
└─ src/components/FooterBoundary.tsx
Kiro workspace
├─ .kiro/steering/product.md
├─ .kiro/steering/ui-design-system.md
├─ .kiro/steering/accessibility.md
├─ .kiro/steering/automation-boundary.md
└─ .kiro/specs/factory-portal-ui/
   ├─ requirements.md
   ├─ design.md
   └─ tasks.md

---

Portal terms used in this UI

---

Step 1 — Scaffold the React app

npm create vite@latest kiro-aws-factory-portal -- --template react-ts
cd kiro-aws-factory-portal
npm install
npm install -D vitest @testing-library/react @testing-library/jest-dom
mkdir -p .kiro/steering .kiro/specs/factory-portal-ui src/components src/data src/styles src/domain src/dev

Business logic: The original portal is a single HTML file. That is useful for fast prototyping, but professional teams need separable components so the automation portal can evolve without high regression risk.

Code logic: Vite provides a fast TypeScript React baseline. The folder structure separates application composition, component rendering, data, domain helpers, and CSS tokens.

Expected result: npm run dev starts an empty React application that Kiro can inspect and modify.

System design rationale:

● A local React app is selected because the workshop is 2 hours and must focus on extracting UI architecture, not cloud deployment.

● The project separates data, components, and styles from the beginning. This prevents Kiro from generating one large component that mixes portal data, rendering logic, and design tokens.

● The test dependency is installed at the start because accessibility and rendering tests should be part of the migration, not added after the UI is complete.

---

Step 2 — Add Kiro steering files

Create .kiro/steering/product.md:

# Product overview
Build an Factory Automation Portal for developer education.
The UI shows architecture telemetry, process-window automation data, and governed AI workflow patterns.
Preserve the original portal concepts: runtime, AWS tool gateway, tools, AI assistance, policy, memory, observability, evaluations, process-window telemetry, runbook, and footer boundary.
Preserve the exact navigation tabs: Overview, Runtime, Tools, Governed Workflows, Process Windows, Runbook.

Create .kiro/steering/ui-design-system.md:

# UI design system
Use dark portal styling with cyan, green, red, yellow, muted blue-gray, and monospace metric text.
Use CSS variables for tokens.
Keep visual hierarchy: topbar -> hero -> stats -> tabs -> portal panel -> footer.
Preserve tab navigation and responsive behavior equivalent to desktop, tablet, and phone.
Map the original `.shell` portal frame, dark grid body background, cards, rows, chips, and SVG chart styles into reusable CSS modules.

Create .kiro/steering/accessibility.md:

# Accessibility rules
All search inputs need labels.
Tab buttons need accessible names and active state.
Analysis buttons must show expanded/collapsed state with aria-expanded.
Do not rely only on color for positive/negative values; keep plus/minus symbols and labels.
Keep keyboard-visible focus on tab, sort, search, and analysis controls.

Create .kiro/steering/automation-boundary.md:

# Automation boundary
The portal is for engineering analysis, architecture review, and test automation planning.
Do not implement autonomous equipment operation.
Do not hide policy, memory, observability, or evaluation boundaries.
Always show that data and charts are placeholders for review workflows.
Preserve boundary chips: NO EQUIPMENT COMMANDS, EVIDENCE FIRST, BOUNDED MEMORY, HUMAN REVIEW.

Prompt sample for Kiro

Read the steering files and create a spec for converting the single-file Factory Automation Portal into React components. Preserve layout sections, dark design tokens, responsive behavior, tabs, process-window leaderboard, Runtime/Tools/Governed/Runbook panels, analysis expansion, SVG charts, status tiles, runbook timeline, and footer boundary. Generate requirements, component design, and implementation tasks.

Business logic: Steering tells Kiro which prototype details are mandatory: workflow labels, statistics, tabs, search, sorting, analysis expansion, runbook gates, and boundary note.

Code logic: Steering files are Markdown instructions Kiro applies across future code generation. The design-system file directly influences generated CSS and component boundaries.

Expected result: Kiro produces a componentized plan rather than rewriting the as another large file.

System design rationale:

● Product steering and design steering are separated because product requirements describe what must be preserved, while design-system steering describes how it should look and behave.

● Accessibility is treated as a first-class steering file because automation dashboards are often keyboard-driven.

● The automation boundary file prevents the portal from being mistaken for an equipment-control application.

---

Step 3 — Capture portal data for the UI

Create src/data/portal.ts:

export type PortalTab = 'overview' | 'runtime' | 'gateway' | 'governed' | 'leaderboard' | 'runbook';

export type PortalCard = {
  title: string;
  body: string;
  tags: string[];
};

export type ToolCard = {
  name: string;
  desc: string;
  signals: string[];
};

export type SpecialistCard = {
  name: string;
  focus: string;
  tools: string;
};

export type RunbookStep = [string, string, string];

export type AutomationCell = {
  name: string;
  strategy: string;
  indexPct: number;
  deltaPct: number;
  stability: number;
  processFactor: number;
  windowRatePct: number;
  skew: number;
  maxDriftPct: number;
  series: number[];
};

export type StatusTile = {
  key: 'RUNTIME' | 'GATEWAY' | 'POLICY' | 'EVAL';
  move: string;
  state: 'READY' | 'WATCH';
  up: boolean;
  series: number[];
};

export const runtimeCards: PortalCard[] = [
  { title: 'Synchronous Runtime', body: 'runtime entrypoint in app.py validates prompt, injects request and session context, runs an AI assistant backed by Amazon Bedrock, and returns structured engineering analysis.', tags: ['app.py', 'FactoryAutomationApp', 'boto3 invoke'] },
  { title: 'Streaming Runtime', body: 'Async entrypoint yields incremental chunks from agent.stream_async so portals and chat interfaces can render analysis progressively.', tags: ['app_streaming.py', 'async', 'partial output'] },
  { title: 'Large Payload Runtime', body: 'Base64 Excel and image fields are decoded into typed document and image content payloads for combined factory engineering analysis.', tags: ['xlsx', 'png', 'base64'] },
  { title: 'Payload Validation', body: 'Local validators check required prompt field, optional metadata, and unknown top-level fields before runtime invocation.', tags: ['JSON Schema', 'fail fast', 'client contract'] },
  { title: 'Smoke Tests', body: 'Deterministic tests validate payload contract and Python calculation tools without model calls, credentials, or latency.', tags: ['pytest', 'deterministic', 'local'] },
  { title: 'Session Cleanup', body: 'Runtime sessions are treated as managed resources and stopped explicitly after workflow completion.', tags: ['session ID', 'cleanup', 'operations'] }
];

export const tools: ToolCard[] = [
  { name: 'throughput_throughput', desc: 'Assess WIP queue stress, tool availability pressure, wafer throughput, and hot-lot preference.', signals: ['queue depth', 'tool availability', 'wafer throughput', 'hot-lot preference'] },
  { name: 'metrology_drift_widening', desc: 'Assess inline and lot-level drift widening, CD-SEM pressure, yield-loss watch, and measurement capacity.', signals: ['inline drift', 'lot drift', 'CD-SEM index', 'yield-loss watch'] },
  { name: 'process_window_drift', desc: 'Assess process capability, overlay error, recipe divergence, lot flow, and process-window drift.', signals: ['overlay error', 'process capability', 'recipe divergence', 'lot flow'] },
  { name: 'tool_to_tool_mismatch', desc: 'Assess overlay mismatch, backlog pressure, baseline offsets, and control context.', signals: ['overlay mismatch', 'baseline offsets', 'control context', 'tool matching'] }
];

export const specialists: SpecialistCard[] = [
  { name: 'throughput', focus: 'throughput stability, WIP queue stress, hot-lot preference, and tool capacity depth', tools: 'bpu_change, throughput_buffer' },
  { name: 'metrology', focus: 'CD-SEM drift widening, yield-loss pressure, defect-risk drift, and measurement capacity', tools: 'bpu_change' },
  { name: 'overlay', focus: 'tool-to-tool mismatch, lot flow, overlay drift, baseline offsets, and control context', tools: 'control_amount' },
  { name: 'etch-process', focus: 'overlay error, process capability, recipe divergence, controller reaction, and process-window drift', tools: 'bpu_change' }
];

export const runbook: RunbookStep[] = [
  ['0-10', 'Environment and architecture check', 'Confirm AWS identity, region, Python environment, project resources, and role boundaries.'],
  ['10-25', 'Prompt and schema contracts', 'Create runtime system prompt, orchestrator prompt, canonical tool schema, and payload contract.'],
  ['25-45', 'Local agent and tooling build', 'Implement AI assistance tools, local runtime logic, local FastAPI tool server server, and discovery client.'],
  ['45-65', 'Validation, policy, and smoke tests', 'Run payload validators, deterministic tool smoke tests, policy tests, and tool schema linting.'],
  ['65-85', 'Managed deployment', 'Launch runtime, package Lambda target, create AWS tool gateway, and register tooling target.'],
  ['85-105', 'Invocation and debugging', 'Invoke runtime with boto3, run Tools semantic search, direct tools/call, and tools/list debugging.'],
  ['105-115', 'Governed orchestration', 'Run specialists, bounded memory, response policy checks, and structured observability events.'],
  ['115-120', 'Evaluation and handoff', 'Run safe and blocked evaluation fixtures, capture session ID, cleanup, and backlog follow-up tasks.']
];

export const automationCells: AutomationCell[] = [
  { name: 'Sofia Garcia', strategy: 'Etch Endpoint Depth Multi-Step Recipe Control', indexPct: 18.4, deltaPct: 0.42, stability: 0.73, processFactor: 1.8, windowRatePct: 58, skew: 0.44, maxDriftPct: 18, series: [100,101,100.7,102.2,104,103.2,105.7,106.1,108,109.8,111,112.4,114.9,116.2,118.4] },
  { name: 'Lucia Fernandez', strategy: 'Photolithography Overlay Drift Detection', indexPct: 16.9, deltaPct: 0.88, stability: 0.91, processFactor: 1.7, windowRatePct: 61, skew: 0.31, maxDriftPct: 22, series: [100,102.1,101.5,103.8,102.9,106.4,108.2,107.5,110.8,112.2,111.6,114.1,115.2,116,116.9] },
  { name: 'Carmen Lopez', strategy: 'Chamber Matching RF Power Pressure Stability', indexPct: 14.2, deltaPct: -0.31, stability: 0.68, processFactor: 1.6, windowRatePct: 56, skew: 0.22, maxDriftPct: 25, series: [100,99.4,101.7,103.2,104.8,103.7,106.8,108.9,110.4,109.2,112.6,113.8,115.1,114.8,114.2] },
  { name: 'Elena Martin', strategy: 'Factory Line Yield Trend Automation', indexPct: 11.8, deltaPct: 0.17, stability: 0.62, processFactor: 1.5, windowRatePct: 54, skew: 0.18, maxDriftPct: 17, series: [100,100.8,101.1,102.5,103.2,104,103.8,105.4,106.2,107,108.9,109.3,110.2,111.1,111.8] },
  { name: 'Marta Sanchez', strategy: 'Recipe Parameter Relative Stability', indexPct: 9.6, deltaPct: 0.09, stability: 0.57, processFactor: 1.4, windowRatePct: 53, skew: 0.09, maxDriftPct: 15, series: [100,100.2,99.9,101,101.8,102.5,102.2,103.6,104.1,105.4,106,106.8,108.2,109,109.6] },
  { name: 'Paula Romero', strategy: 'Metrology Feature Ensemble Scoring', indexPct: 7.1, deltaPct: -0.12, stability: 0.49, processFactor: 1.3, windowRatePct: 52, skew: -0.04, maxDriftPct: 14, series: [100,100.5,101.2,100.8,102.1,102.7,103.4,104.2,103.8,105,105.4,106.2,106.8,107.3,107.1] },
  { name: 'Ana Torres', strategy: 'Endpoint Signal Breakout Alarm System', indexPct: 5.4, deltaPct: 0.28, stability: 0.42, processFactor: 1.2, windowRatePct: 51, skew: 0.12, maxDriftPct: 19, series: [100,99.1,100.4,101.6,100.8,102.2,101.5,103.4,102.8,104.2,103.8,104.7,105.1,105.2,105.4] },
  { name: 'Laura Navarro', strategy: 'Multi-Tool Mean Reversion Control', indexPct: 3.8, deltaPct: -0.06, stability: 0.35, processFactor: 1.1, windowRatePct: 49, skew: -0.11, maxDriftPct: 16, series: [100,100.4,99.8,100.9,101.4,100.6,101.8,102.2,101.7,102.8,103.1,102.9,103.6,103.9,103.8] }
];

export const statusTiles: StatusTile[] = [
  { key: 'RUNTIME', move: '+0.38%', state: 'READY', up: true, series: [20,21,20,22,23,23,24,25,24,26] },
  { key: 'GATEWAY', move: '-0.22%', state: 'WATCH', up: false, series: [30,29,31,28,27,26,25,24,23,22] },
  { key: 'POLICY', move: '+0.62%', state: 'READY', up: true, series: [18,18.5,19,18.7,20,21,20.5,22,23,23.5] },
  { key: 'EVAL', move: '+2.18%', state: 'READY', up: true, series: [20,22,21,24,26,25,29,28,32,34] }
];

Business logic: This preserves runtime cards, tool cards, specialist cards, runbook steps, process-window row data, and status-tile values while giving developers a typed source of truth.

Code logic: Components import typed arrays rather than reading DOM or parsing embedded script data.

Expected result: The UI can render all portal sections, 8 automation cells, 4 status tiles, 4 tools, 4 specialists, 6 runtime cards, and 8 runbook steps without hardcoded values inside components.

System design rationale:

● Data is placed in a module because prototype data and rendering are mixed in the original single file.

● Field names clarify units: indexPct, deltaPct, and windowRatePct are percentages, while series contains indexed process-window points.

● The status tile type limits valid keys to the four automation lanes.

● Runtime cards, tools, specialists, and runbook steps are typed because portal panels should be generated from data, not copied as repeated JSX.

---

Step 4 — Create CSS design tokens

Create src/styles/tokens.css:

:root {
  --bg: #061018;
  --panel: #081522;
  --panel2: #0c1f31;
  --line: #28465f;
  --soft: rgba(40,70,95,.62);
  --text: #edf6ff;
  --muted: #9fb3c8;
  --muted2: #668197;
  --cyan: #38bdf8;
  --cyan2: #77c7ff;
  --green: #31c48d;
  --red: #f05252;
  --yellow: #f6c85f;
  --orange: #fb923c;
  --mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", monospace;
  --sans: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans", Arial, sans-serif;
}
body {
  margin: 0;
  min-height: 100vh;
  color: var(--text);
  font-family: var(--sans);
  background:
    linear-gradient(rgba(255,255,255,.025) 1px, transparent 1px),
    linear-gradient(90deg, rgba(255,255,255,.025) 1px, transparent 1px),
    radial-gradient(circle at 8% 0, rgba(56,189,248,.19), transparent 30%),
    radial-gradient(circle at 90% 8%, rgba(49,196,141,.13), transparent 28%),
    var(--bg);
  background-size: 32px 32px, 32px 32px, auto, auto, auto;
}
.metric { font-family: var(--mono); font-variant-numeric: tabular-nums; font-weight: 950; }
.pos { color: var(--green); }
.neg { color: var(--red); }
.cyan { color: var(--cyan2); }
.yellow { color: var(--yellow); }

Business logic: Design tokens preserve the enterprise dark portal look while making the visual language reusable.

Code logic: CSS variables replace repeated hex values. Components use .metric, .pos, .neg, .cyan, and .yellow consistently for process metrics and status values.

Expected result: The application matches the dark-grid, cyan/green/red/yellow automation-portal aesthetic.

System design rationale:

● CSS variables are used instead of component-local colors so visual changes can be made in one place.

● Metric text uses tabular numerals because values should align visually when rows update.

● Positive and negative classes are named by semantic meaning rather than color.

---

Step 5 — Build top bar, hero, and tab navigation

Create src/components/TopBar.tsx:

import { useEffect, useState } from 'react';

export function TopBar() {
  const [clock, setClock] = useState('LIVE');

  useEffect(() => {
    const tick = () => setClock(`LIVE ${new Date().toLocaleString('en-HK', {
      hour12: false,
      month: '2-digit',
      day: '2-digit',
      hour: '2-digit',
      minute: '2-digit',
      second: '2-digit'
    })} HKT`);
    tick();
    const id = window.setInterval(tick, 1000);
    return () => window.clearInterval(id);
  }, []);

  return <header className="topbar">
    <div className="brand">
      <div className="logo">AWS</div>
      <div>
        <div className="brand-main">FACTORY AUTOMATION PORTAL</div>
        <div className="brand-sub">RUNTIME / TOOLS / POLICY / MEMORY / OBSERVABILITY / EVALUATIONS</div>
      </div>
    </div>
    <div className="status"><span className="dot" />{clock}</div>
  </header>;
}

Create src/components/HeroPanel.tsx:

export function HeroPanel() {
  const chips = ['RUNTIME', 'TOOLING', 'AI ASSISTANCE', 'tooling', 'SIGV4', 'JSON-RPC', 'AWS LAMBDA', 'AMAZON BEDROCK'];
  const boundary = ['NO EQUIPMENT COMMANDS', 'EVIDENCE FIRST', 'BOUNDED MEMORY', 'HUMAN REVIEW'];

  return <section className="hero">
    <div className="hero-grid">
      <div>
        <div className="eyebrow">Automation Portal</div>
        <h1>AI-assisted<br /><span>Factory Engineering</span></h1>
        <p className="subhead">A single automation portal for senior Developers building etch process window test automation, tool inventory, and governed photolithography drift orchestration. The portal connects runtime deployment, tool discovery, deterministic calculations, policy gates, memory summaries, telemetry, evaluations, and enterprise adoption patterns.</p>
        <div className="chips">{chips.map(c => <span key={c} className={c.includes('AWS') ? 'chip hot' : 'chip'}>{c}</span>)}</div>
      </div>
      <aside className="panel">
        <div className="panel-title">Portal Mission</div>
        <p><strong>Transform workshop assets into an enterprise automation console.</strong> Operators get deployment status, tool inventory, governed workflow controls, evaluation readiness, and original process-window leaderboard telemetry in one audit-friendly interface.</p>
        <div className="chips">{boundary.map(c => <span key={c} className={c === 'HUMAN REVIEW' ? 'chip warn' : 'chip ok'}>{c}</span>)}</div>
      </aside>
    </div>
  </section>;
}

Business logic: The top bar and hero tell users the automation-workspace context before they inspect panels or process-window numbers.

Code logic: TopBar owns clock state and cleanup. HeroPanel is static and renders chips from arrays.

Expected result: The top of the app visually matches the latest portal with live status, HKT clock, title, service chips, mission card, and boundary chips.

System design rationale:

● Clock logic is isolated in TopBar because it has a timer side effect.

● Hero content is componentized even though it is static because product copy often changes independently from portal panels.

● Workflow chips are arrays rather than repeated JSX to make it easy for Kiro or developers to add or reorder labels.

---

Step 6 — Build stats strip, portal panels, process-window rows, and footer

Create StatsStrip:

export function StatsStrip() {
  return <section className="stats">
    <div className="stat"><div className="stat-label">Runtime Entry Points</div><div className="stat-val cyan">3</div></div>
    <div className="stat"><div className="stat-label">Tools</div><div className="stat-val pos">4</div></div>
    <div className="stat"><div className="stat-label">Specialists</div><div className="stat-val pos">4</div></div>
    <div className="stat"><div className="stat-label">Policy Checks</div><div className="stat-val yellow">2</div></div>
    <div className="stat"><div className="stat-label">Evaluation Sets</div><div className="stat-val cyan">5</div></div>
    <div className="stat"><div className="stat-label">Session State</div><div className="stat-val pos">ON</div></div>
  </section>;
}

Create components for:

● PortalTabs: controls active panel state and keyboard-friendly tab behavior.

● OverviewPanel: renders Enterprise Automation Control Plane, Runtime Workbench, Tool Inventory, Governed Workflow, Architecture Layers, and Adoption Notes.

● RuntimePanel: maps runtimeCards and shows Runtime Payload Contract plus Deterministic Tool Pattern.

● ToolsPanel: maps tools and shows Tool Flow plus JSON-RPC Debug Payload.

● GovernedAgentsPanel: maps specialists and shows Policy Boundary plus Telemetry Event Shape.

● ProcessWindowPanel: renders status tiles, search, sort controls, process-window rows, and analysis expansion.

● RunbookPanel: renders build timeline, Promotion Gate, and Production Backlog.

● FooterBoundary: preserves the automation boundary and no-autonomous-operation note.

Business logic: The panels convert the portal into a reusable enterprise navigation model.

Code logic: Static portal data maps to cards, while process-window rows keep search, sort, expanding analysis, SVG sparkline, and live simulation behavior.

Expected result: The UI displays the same portal sections as the while the implementation becomes maintainable and testable.

System design rationale:

● Tab panels prevent the page from becoming one large component.

● Runtime, Tools, and Governed content are separate review surfaces because each belongs to different platform owners.

● The Process Windows panel retains the original interactive leaderboard behavior as a focused component.

---

Step 7 — Add Kiro hooks for UI quality

Create .kiro/hooks/ui-regression-review.md:

# Hook: UI regression review
Trigger: when src/components/*.tsx or src/styles/*.css is saved
Action:
Ask Kiro to check whether the change preserves: topbar, hero, stats, tabs, overview cards, runtime cards, Tools inventory, governed-workflow cards, process-window leaderboard, runbook timeline, responsive labels, dark tokens, SVG chart surfaces, and footer boundary.

Create .kiro/hooks/accessibility-review.md:

# Hook: accessibility review
Trigger: when src/components/*.tsx is saved
Action:
Ask Kiro to review keyboard access, search input labels, tab active state, aria-expanded, focus visibility, and positive/negative value semantics.

Create .kiro/hooks/automation-boundary-review.md:

# Hook: automation boundary review
Trigger: when src/components/*.tsx, src/data/*.ts, or src/styles/*.css is saved
Action:
Ask Kiro to verify that no autonomous equipment operation text or controls were added, and that evidence-first, policy, memory, observability, evaluation, and human-review boundaries remain visible.

Business logic: UI regression hooks help protect prototype coverage and automation-safety messaging.

Code logic: Hooks run Kiro review prompts on file-save events. They do not replace unit tests, but provide immediate agent-assisted review.

Expected result: Kiro recommends fixes when a component loses a label, removes a required section, or breaks interaction semantics.

System design rationale:

● UI migration has many small details, so file-save review catches regressions when context is still fresh.

● Accessibility review is separated because visual parity does not guarantee keyboard or screen-reader quality.

● Automation-boundary review protects the portal from becoming an implied equipment-control UI.

---

Final lab challenge

Ask Kiro:

Compare the React UI with the latest Factory Automation Portal inventory. Produce a gap list covering layout sections, service chips, status stats, tabs, Runtime cards, Tools cards, Governed Agent cards, Process Window rows, runbook, responsiveness, live clock, footer boundary, status tiles, SVG chart surfaces, and analysis panels. Then generate implementation tasks for remaining gaps.

---

Completion checklist

● [ ] Top bar and HKT live clock work.

● [ ] Hero, mission card, chips, and footer boundary are present.

● [ ] Stats strip reproduces portal values.

● [ ] Tab navigation is accessible.

● [ ] Runtime, Tools, Governed, Process Windows, and Runbook panels match the.

● [ ] All 8 automation cells and 4 status tiles are represented.

● [ ] All 6 runtime cards, 4 tools, 4 specialists, and 8 runbook steps are represented.

● [ ] Search and sort controls are accessible.

● [ ] Expandable analysis rows preserve chart and automation-note slots.

● [ ] Responsive layout covers desktop/tablet/mobile.

● [ ] Kiro hooks review UI, accessibility, and automation-boundary changes.

---

Additional Hands-on Developer Labs for Advanced Developers — HTML Graphic Analysis

Advanced graphic-analysis goals

By the end of this section, advanced developers will be able to:

● Reverse-engineer the portal HTML file's visual grammar into reusable design tokens.

● Explain how the grid background, glow effects, borders, panels, status cards, tabs, and SVG chart surfaces create an factory automation-console feel.

● Build a visual inventory that maps CSS selectors to graphic intent.

● Validate responsive graphic behavior at desktop, tablet, and mobile breakpoints.

● Create Kiro review prompts that preserve visual fidelity and automation-boundary language while refactoring.

Graphic inventory from the portal HTML file

The uploaded portal HTML uses a compact but rich graphic system:

● Portal frame: .shell creates a bounded automation workspace with border, dark translucent background, and large box shadow.

● Layered body background: multiple linear gradients create a subtle grid, while radial gradients create cyan and green light blooms.

● Sticky command bar: .topbar, .logo, .status, and .dot establish live-workspace affordance.

● Hero composition: .hero, .hero-grid, .eyebrow, h1, .chips, and .panel define the portal identity and boundary story.

● Metric color language: .pos, .neg, .cyan, .yellow, and .metric encode positive, negative, highlight, warning, and tabular numeric text.

● Tab navigation: .nav, .tab, .portal, and .portal.active control the portal's panel model.

● Board density: .row, .cell, .rank, .strategy, .barwrap, .bar, and .mlabel create a dense process-window grid.

● SVG chart language: .spark, .eq, .dd, .hist, .line, .fill, .axis, .gridline, .ddarea, .ddline, .bp, .bn, .lbl provide reusable chart semantics.

● Responsive transformation: media queries at 1120px and 560px transform the board from table-like grid to mobile row cards.

Advanced Lab 1 — Build a visual-token extraction report

Objective: Convert the portal HTML's CSS values into a documented design-token report that explains each color, font, spacing, border, shadow, background layer, and chart mark.

Create docs/html-graphic-token-report.md:

# Factory Automation Portal HTML Graphic Token Report

## Color tokens
<table>
  <thead>
    <tr>
      <th scope="col">Token</th>
      <th scope="col">Value</th>
      <th scope="col">Graphic role</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>--bg</td>
      <td>#061018</td>
      <td>Workspace background</td>
    </tr>
    <tr>
      <td>--panel</td>
      <td>#081522</td>
      <td>Primary panel surface</td>
    </tr>
    <tr>
      <td>--panel2</td>
      <td>#0c1f31</td>
      <td>Raised control surface</td>
    </tr>
    <tr>
      <td>--line</td>
      <td>#28465f</td>
      <td>Grid and border system</td>
    </tr>
    <tr>
      <td>--soft</td>
      <td>rgba(40,70,95,.62)</td>
      <td>Low-contrast internal separators</td>
    </tr>
    <tr>
      <td>--text</td>
      <td>#edf6ff</td>
      <td>Primary text</td>
    </tr>
    <tr>
      <td>--muted</td>
      <td>#9fb3c8</td>
      <td>Secondary text</td>
    </tr>
    <tr>
      <td>--muted2</td>
      <td>#668197</td>
      <td>Tertiary text</td>
    </tr>
    <tr>
      <td>--cyan</td>
      <td>#38bdf8</td>
      <td>Interactive glow and primary highlight</td>
    </tr>
    <tr>
      <td>--cyan2</td>
      <td>#77c7ff</td>
      <td>Secondary cyan title highlight</td>
    </tr>
    <tr>
      <td>--green</td>
      <td>#31c48d</td>
      <td>Positive metric state and live dot</td>
    </tr>
    <tr>
      <td>--red</td>
      <td>#f05252</td>
      <td>Negative metric state and drift pressure</td>
    </tr>
    <tr>
      <td>--yellow</td>
      <td>#f6c85f</td>
      <td>Warning and review accent</td>
    </tr>
    <tr>
      <td>--orange</td>
      <td>#fb923c</td>
      <td>Reserved alert accent</td>
    </tr>
  </tbody>
</table>

## Typography
- `--mono` is used for metrics, controls, status, code blocks, telemetry examples, and dense labels.
- `--sans` is used for body copy, hero text, card descriptions, and process pattern descriptions.
- `.metric` enables tabular numeric scanning through `font-variant-numeric: tabular-nums`.

## Surface language
- Dark panels are separated with `--line` borders.
- Soft internal dividers use `--soft` to reduce visual noise.
- Cyan glow is reserved for active controls, hero emphasis, live workspace identity, and timeline dots.
- Green and red are paired with plus/minus symbols so meaning is not color-only.

Kiro prompt:

Analyze the portal HTML CSS and create a design-token report. Explain the visual purpose of every root variable, panel color, border, shadow, font family, metric class, positive/negative state, tab state, and SVG chart class. Keep the report implementation-oriented for React developers.

Expected result: Developers can describe the original graphic system before changing it.

Advanced Lab 2 — Reconstruct the layered background as a component

Objective: Isolate the portal file's grid-and-glow background into a named React shell class so it can be tested and reused.

Create src/components/GraphicWorkspaceShell.tsx:

import type { ReactNode } from 'react';

export function GraphicWorkspaceShell({ children }: { children: ReactNode }) {
  return (
    <main className="page graphic-workspace" id="top">
      <section className="shell graphic-portal-shell">{children}</section>
    </main>
  );
}

Create src/styles/graphic-background.css:

.graphic-workspace {
  min-height: 100vh;
  background:
    linear-gradient(rgba(255,255,255,.025) 1px, transparent 1px),
    linear-gradient(90deg, rgba(255,255,255,.025) 1px, transparent 1px),
    radial-gradient(circle at 8% 0, rgba(56,189,248,.19), transparent 30%),
    radial-gradient(circle at 90% 8%, rgba(49,196,141,.13), transparent 28%),
    var(--bg);
  background-size: 32px 32px, 32px 32px, auto, auto, auto;
}

.graphic-portal-shell {
  max-width: 1440px;
  border: 1px solid #315875;
  background: rgba(4,14,23,.96);
  box-shadow: 0 26px 90px rgba(0,20,36,.72);
  overflow: hidden;
}

Graphic logic: The first two gradients create the grid. The next two radial gradients create atmospheric cyan and green depth. The final color layer anchors the dark automation environment.

Kiro prompt:

Extract the portal HTML body background and shell frame into named React/CSS shell classes. Preserve the exact gradient order, background-size behavior, frame border, translucent shell surface, 1440px max width, and box shadow. Add comments that explain the graphic role of each layer.

Expected result: The background becomes a portable visual primitive rather than an undocumented body style.

Advanced Lab 3 — Create a visual hierarchy annotation overlay

Objective: Add a development-only overlay that labels visual sections: topbar, hero, stats, tabs, portal panel, status tiles, controls, board, detail panels, runbook, and footer.

Create src/dev/VisualHierarchyOverlay.tsx:

const zones = [
  ['topbar', 'Command / live status'],
  ['hero', 'Portal identity and service chips'],
  ['stats', 'Automation summary metrics'],
  ['nav', 'Portal tab navigation'],
  ['portal', 'Active content panel'],
  ['market', 'Runtime/Tools/Policy/Eval status tiles'],
  ['controls', 'Search and ranking controls'],
  ['board', 'Dense process-window table'],
  ['detail', 'Expanded analysis panel'],
  ['timeline', 'Runbook timeline'],
  ['footer', 'Boundary and navigation']
] as const;

export function VisualHierarchyOverlay() {
  return (
    <aside className="visual-audit-panel" aria-label="Visual hierarchy audit panel">
      <h3>Graphic hierarchy</h3>
      <ol>
        {zones.map(([selector, role]) => (
          <li key={selector}><code>.{selector}</code> — {role}</li>
        ))}
      </ol>
    </aside>
  );
}

Add development CSS:

.visual-audit-panel {
  position: fixed;
  right: 12px;
  bottom: 12px;
  z-index: 99;
  width: min(380px, calc(100vw - 24px));
  border: 1px solid var(--line);
  background: rgba(4, 16, 26, .94);
  color: var(--text);
  padding: 12px;
  font-family: var(--mono);
  font-size: 11px;
}

Expected result: Developers learn to inspect the page as a hierarchy of graphic zones, not just a list of components.

Advanced Lab 4 — Responsive graphic behavior audit

Objective: Verify that the HTML breakpoints preserve visual meaning when the portal changes shape.

Create docs/responsive-graphic-audit.md:

# Factory Automation Portal Responsive Graphic Audit

## Desktop view
- Board header row is visible.
- Ten-column grid supports automation-cell comparison.
- Hero uses two-column composition.
- Overview/runtime/tool/specialist cards use three-column grids where applicable.
- Runtime/Tools/Policy/Eval status tiles use four columns.
- Footer uses two-column layout with CTA at right.

## Tablet view, max-width 1120px
- Hero, card grids, and chart grids collapse to one column.
- Stats become two columns.
- Status tiles become two columns.
- Board header is hidden and each row exposes mobile labels.
- Metric grid becomes two columns.
- Analysis button expands to full width.

## Phone view, max-width 560px
- Page padding shrinks.
- Status text and brand subtitle are hidden to protect space.
- Stats and status tiles use single-column cards.
- Sort buttons become a two-column grid.
- Footer CTA stacks below the boundary note.
- Metric grid becomes one column.

Kiro prompt:

Create a responsive graphic audit from the portal HTML. For each breakpoint, document which visual structures change, why the change protects readability, and what regression tests should verify.

Expected result: Responsive design is treated as graphic behavior, not just CSS mechanics.

Advanced Lab 5 — Visual regression checklist for the portal look

Objective: Create a checklist that developers can use before accepting UI refactors.

Create docs/html-look-regression-checklist.md:

# Factory Automation Portal Look Regression Checklist

## Must preserve
- Dark grid body background with cyan and green glow layers.
- Portal shell border, max-width, translucent background, and deep shadow.
- Sticky topbar with AWS logo, live green dot, brand name, and workflow subtitle.
- Large high-contrast hero title with cyan secondary line.
- Service chips with normal and hot states.
- Boundary chips: NO EQUIPMENT COMMANDS, EVIDENCE FIRST, BOUNDED MEMORY, HUMAN REVIEW.
- Six summary stats with correct labels and values.
- Tab navigation with active state and hover state.
- Overview, Runtime, Tools, Governed Workflows, Process Windows, and Runbook panels.
- Dense metric typography with tabular numbers.
- Positive values with plus signs and green color.
- Negative values with minus signs and red color.
- Board row dividers and soft internal cell separators.
- Mobile labels when the header row disappears.
- SVG chart surfaces for sparkline, index path, drift waterline, and daily delta histogram.
- Footer boundary visibility.

## Must not introduce
- Autonomous equipment-operation controls.
- Hidden policy, memory, observability, or evaluation boundaries.
- Color-only meaning without textual sign or label.
- Breakpoint behavior that hides the footer boundary or analysis button.

Kiro prompt:

Compare the React UI against the portal HTML graphic system. Produce a regression checklist covering background, shell, topbar, hero, chips, stats, tabs, cards, status tiles, controls, board rows, responsive labels, detail panels, runbook, SVG charts, and footer boundary.

Advanced final challenge — HTML graphic fidelity review

Ask Kiro:

Perform a graphic fidelity review of the React UI against the latest Factory Automation Portal HTML file. Focus only on visual system behavior: background layers, portal shell, color semantics, typography, spacing, hierarchy, responsive breakpoints, dense process-window layout, tab states, focus states, SVG chart surfaces, and footer boundary visibility. Produce a severity-ranked gap list.

Advanced graphic-analysis completion checklist

● [ ] Design-token report explains the portal HTML visual system.

● [ ] Background and portal shell are extracted into named reusable classes.

● [ ] Visual hierarchy overlay documents the page's graphic zones.

● [ ] Responsive audit covers both breakpoint tiers.

● [ ] Regression checklist protects the original look and footer boundary.

● [ ] UI review confirms no autonomous equipment-control surface was introduced.