Kiro: 2-Hour Professional Developer Workshop Guide

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

Workshop purpose

This workshop teaches professional developers how to use Kiro as the primary AI engineering service to build a production-style project from scratch. The project is a browser-based Fab SPC Drift Synchronization Portal: a static developer demo that tracks CD-SEM metrology risk, SPC blind-window duration, Fleet deviation, TMG, Mandel Slope, and recommended engineering actions.

The workshop intentionally focuses on Kiro only: specs, steering files, agentic chat, implementation tasks, hooks, code review, refactoring, test generation, and correctness workflows. The application is deliberately local and lightweight so developers spend the two hours learning Kiro’s engineering loop rather than cloud plumbing.

Audience

• Senior frontend, full-stack, platform, DevOps, or manufacturing software developers.
• Developers comfortable with TypeScript or JavaScript, test runners, and Git-based development.
• Teams evaluating spec-driven AI development for regulated, high-quality, or audit-heavy software delivery.

Learning outcomes

By the end, developers can:

1. Start a new Kiro workspace from scratch.
2. Create steering files that guide Kiro’s behavior consistently.
3. Convert a natural-language feature request into requirements, design, and implementation tasks.
4. Use Kiro to generate, review, and refine application code.
5. Ask Kiro to write tests, improve accessibility, and refactor logic.
6. Use Kiro hooks to automate repetitive developer checks.
7. Review generated code as an engineer rather than passively accepting AI output.
8. Understand where Kiro fits in professional development workflows.

Why Kiro for this workshop

Kiro is an agentic coding service that turns prompts into detailed specs, working code, documentation, and tests. It supports spec-driven development, agentic chat, steering files, and hooks that automate actions on development events. Kiro is built on Amazon Bedrock and uses multiple foundation models for its tasks. These capabilities make it a strong single-service focus for a technical developer workshop.

Two-hour agenda

---

Module 1 — Environment and workspace setup

Developer objective

Create a clean local workspace that Kiro can understand and evolve through specs, steering, hooks, tests, and source code.

Steps

1. Open Kiro IDE.
2. Create a new folder named kiro-fab-spc-portal.
3. Initialize Git.
4. Create the baseline files shown in the lab manual.
5. Open the Kiro agent panel and confirm the workspace is loaded.

Starter prompt for Kiro

Create a clean frontend project structure for a static browser application named Fab SPC Drift Synchronization Portal. Use plain TypeScript, Vite, CSS, and Vitest. Do not add backend services. Create a project skeleton only; do not implement domain logic yet.

System design decision

• Local-first architecture is intentional. The goal is to teach Kiro’s spec, implementation, test, and hook workflows without requiring every participant to provision accounts, IAM permissions, networking, or external services. A local static app keeps feedback loops short and makes the AI-generated code easy to inspect.
• A static TypeScript app is enough to expose real engineering concerns. Developers still model domain entities, risk calculations, UI state, filtering, sorting, tests, accessibility, and code organization. This gives Kiro meaningful context while preserving workshop speed and reproducibility.
• The project starts empty to demonstrate Kiro’s end-to-end value. Instead of modifying a prepared solution, developers see how steering, specs, implementation tasks, tests, and hooks accumulate into a maintainable codebase. This mirrors professional greenfield feature delivery.

---

Module 2 — Steering: make Kiro follow team rules

Developer objective

Create persistent instructions so Kiro consistently follows architecture, domain language, testing standards, security posture, and UI conventions.

Kiro capability used

• Workspace steering files.
• Reusable project knowledge.
• Team-aligned standards.
• Context loaded into later conversations.

Files to create

.kiro/steering/product.md
.kiro/steering/tech.md
.kiro/steering/structure.md
.kiro/steering/domain.md
.kiro/steering/testing.md

Prompt sample

Generate Kiro steering files for this workspace. The product is a local developer demo portal for Fab SPC drift synchronization. It must be advisory-only, must not command fab equipment, and must show CD-SEM risk using TMG, Mandel Slope, Fleet deviation, residual 3σ, blind-window duration, and FDC indicators. Use TypeScript, Vite, CSS, and Vitest. Keep functions deterministic and testable.

System design decision

• Steering files are treated like architecture memory. Professionals should avoid repeating standards in every prompt. By storing product, technology, structure, domain, and testing guidance in markdown files, the team turns tacit conventions into versionable engineering assets.
• Domain steering protects correctness. SPC, CD-SEM, TMG, FDC, and Fleet deviation terms carry operational meaning. Steering reduces the chance that generated code invents unsafe behavior, mixes advisory actions with equipment control, or loses important manufacturing constraints.
• Testing steering forces deterministic design. If Kiro is told early that calculations must remain pure and testable, later generated code is more likely to separate domain logic from rendering. That separation improves reviewability, unit testing, and refactoring safety.

---

Module 3 — Spec-driven planning

Developer objective

Use Kiro to transform business intent into structured requirements, technical design, and sequenced implementation tasks before generating code.

Kiro capability used

• Specs.
• Requirements generation.
• Design generation.
• Task breakdown.
• Requirement-to-code traceability.

Prompt sample

Create a Kiro spec named fab-spc-portal. The feature is a static web portal that helps fab engineers detect when routine SPC monitoring frequency is out of sync with actual mass production. Include requirements, edge cases, data model, risk scoring rules, UI sections, accessibility constraints, and implementation tasks. Keep the application local and deterministic.

Required requirements in the spec

1. The app shall display a high-level summary of monitored CD-SEM tools.
2. The app shall compute a risk score from TMG, Mandel Slope, Fleet deviation, residual 3σ, and blind-window duration.
3. The app shall show recommended advisory actions: release, watch, run golden wafer, route limit, APC guard, or hold review.
4. The app shall allow search and sorting.
5. The app shall include an FDC health-link section.
6. The app shall include a triage section for yield-loss review.
7. The app shall not issue equipment commands.
8. The app shall include unit tests for scoring and action assignment.

System design decision

• The spec is the source of intent. In professional development, code review alone is not enough because generated code can be plausible yet misaligned. A Kiro spec creates a durable contract that connects requirements, design, tasks, and tests.
• Risk scoring is explicit instead of hidden in UI code. The score determines operational recommendations, so it must be documented, testable, and independently reviewable. Kiro should generate a pure domain function rather than embedding scoring rules inside event handlers.
• Advisory-only behavior is a safety boundary. The portal can recommend hold review or route limitation, but it must not represent autonomous equipment control. This design keeps the training project technically realistic while avoiding unsafe operational assumptions.

---

Module 4 — Build with Kiro agentic chat

Developer objective

Use Kiro to implement the app task by task while reviewing generated diffs.

Implementation sequence

1. Data model and sample data.
2. Risk scoring engine.
3. Action assignment engine.
4. App shell and navigation.
5. Risk board with search and sort.
6. FDC health-link section.
7. Dynamic matching and triage sections.
8. Tests.
9. Hooks.
10. Final review.

Prompt sample

Implement task 1 from the fab-spc-portal spec. Create TypeScript domain types for tools, risk factors, actions, FDC links, and runbook steps. Add realistic sample data for ten CD-SEM tools. Keep the sample data in src/data/sampleData.ts. Do not build the UI yet.

System design decision

• Implementation is sequenced to reduce AI blast radius. Kiro can generate large changes, but professional developers should prefer small, inspectable diffs. Implementing data, scoring, UI, tests, and automation separately makes review easier and failure recovery faster.
• Domain logic comes before interface work. Risk score and action assignment are the most important correctness paths. Building them first allows developers to test behavior independent of CSS, DOM state, or rendering libraries.
• Sample data is explicit and versioned. A deterministic demo dataset makes the workshop repeatable. It also lets Kiro reason about real fields, thresholds, and UI states without requiring live manufacturing data or external integration.

---

Module 5 — Tests and correctness

Developer objective

Ask Kiro to write unit tests, edge-case tests, and refactoring suggestions for the risk engine.

Prompt sample

Generate Vitest tests for the risk engine. Cover normal tools, high TMG, Mandel Slope outside 0.98 to 1.02, fleet deviation above 3σ, residual 3σ above 0.18 nm, and blind-window duration above six hours. Include expected action recommendations and explain any missing edge cases.

System design decision

• Tests validate intent, not only syntax. The critical question is whether a tool with unsafe metrology indicators receives the correct advisory action. Tests encode those expected outcomes so future Kiro changes cannot silently alter the risk model.
• Edge cases are a Kiro collaboration opportunity. Developers should ask Kiro what cases are missing, then review its suggestions. This uses Kiro as a reasoning partner without delegating final engineering judgment.
• Pure functions make generated tests reliable. By keeping scoring logic free of DOM, network, random numbers, or time, the test suite remains fast and deterministic. This also makes hooks practical because tests can run automatically after relevant file changes.

---

Module 6 — Hooks for automation

Developer objective

Create Kiro hooks that run routine checks or ask Kiro to update documentation when relevant files change.

Prompt sample

Create workspace Kiro hooks for this project. Run npm test after saving TypeScript domain files. Run npm run lint after saving source files. Add an agent hook that updates docs/decision-log.md when files under src/domain change. Keep hooks safe and workspace-local.

System design decision

• Hooks move repetitive review into the workflow. Developers often forget to run tests or update documentation. Kiro hooks make quality checks event-driven, reducing manual overhead while keeping developers in control of generated changes.
• Command hooks and agent hooks serve different needs. Commands are ideal for deterministic checks like linting and tests. Agent prompts are better for documentation summaries, design notes, or review reminders where natural-language synthesis is useful.
• Workspace-local hooks avoid global side effects. The workshop creates .kiro/hooks inside the project so behavior is transparent, reviewable, and portable with the repo. This is safer than hidden user-level automation during team training.

---

Module 7 — Final review

Developer objective

Use Kiro to review code quality, compare implementation against the spec, and identify production gaps.

Prompt sample

Review this workspace against the fab-spc-portal spec. Identify gaps in requirements coverage, code quality, test coverage, accessibility, security posture, and future production readiness. Do not modify files yet; produce a review report with prioritized findings.

System design decision

• AI-generated code still needs engineering review. Kiro accelerates planning and implementation, but developers remain accountable for correctness, safety, and maintainability. A final review step reinforces professional ownership.
• Spec-to-implementation comparison catches drift. The team should verify that the built portal matches the approved requirements and design, not only that it runs. This mirrors regulated feature delivery and audit-friendly engineering practices.
• Production readiness is separated from workshop scope. The demo is local and advisory-only. A review report can capture future needs such as authentication, authorization, telemetry, validation with source data, and formal change-control integration.

---

Instructor checklist

Before the workshop:

• Verify Kiro IDE or CLI access.
• Prepare a clean machine or container image with Node.js LTS.
• Confirm participants can create local files and run npm install.
• Prepare a fallback zip or repository in case network access is limited.

During the workshop:

• Keep Kiro changes small and reviewable.
• Ask participants to reject or edit output that violates steering.
• Emphasize code review responsibility.
• Avoid turning the app into backend infrastructure.

After the workshop:

• Ask participants to compare their generated specs.
• Discuss how steering would differ for their own team.
• Discuss where hooks are valuable and where they may be risky.
• Capture lessons learned in docs/decision-log.md.

---

learning outcome: migrate a monolithic demo into engineered modules

Professional teams often start from a working proof-of-concept, demo HTML, notebook, or internal prototype. The higher-value skill is not merely asking an AI assistant to generate a new app. The professional skill is asking Kiro to understand a working demo, extract the intent, preserve visible behavior, and redesign the implementation as reviewable modules.

In this workshop, developers will use the HTML demo as a target reference for:

1. Visual structure: hero header, status cards, tabs, risk board, detail panels, timeline, and footer.
2. Domain data: CD-SEM tools, FDC health links, runbook steps, risk thresholds, and advisory actions.
3. UI behaviors: tab switching, search, sort, row expansion, metric coloring, and SVG charting.
4. Engineering improvements: pure domain logic, deterministic tests, typed data models, accessible markup, and event isolation.

System design decision

• A working demo is treated as product evidence, not production architecture. The HTML demo proves the intended user experience and domain vocabulary, but its single-file structure couples data, rendering, styling, and behavior. Kiro should preserve product behavior while changing implementation structure into maintainable modules.
• The migration path teaches refactoring under constraints. Developers must instruct Kiro to keep visual parity, avoid unsafe equipment-control behavior, preserve the advisory workflow, and introduce tests. This is closer to real enterprise modernization than greenfield code generation alone.
• The same demo drives spec, code, and tests. The HTML functions such as tab switching, sorting, detail expansion, and SVG path generation become explicit requirements and testable units. Kiro can then generate code that is easier to review because every module maps back to an observable demo feature.

Demo-to-module decomposition

The HTML demo mixes responsibilities in one file. The workshop asks Kiro to extract them into this structure:

src/
├── data/
│   ├── tools.ts              # CD-SEM sample tool records from demo
│   ├── fdc.ts                # FDC health-link matrix from demo
│   └── runbook.ts            # Implementation runbook steps from demo
├── domain/
│   ├── types.ts              # typed contracts
│   ├── thresholds.ts         # TMG, slope, fleet, residual, blind-window limits
│   ├── risk.ts               # risk score and advisory action
│   └── filters.ts            # search and sort helpers
├── ui/
│   ├── app.ts                # top-level render orchestration
│   ├── tabs.ts               # tab activation behavior
│   ├── board.ts              # risk board rows and detail panels
│   ├── chart.ts              # SVG path, sparkline, fleet chart helpers
│   └── staticSections.ts     # FDC cards, runbook, overview sections
└── styles.css                # extracted design system and layout

System design decision

• Data modules isolate workshop fixtures from business rules. CD-SEM records from the demo are valuable because they contain varied risk states. Keeping them in src/data makes them easy to replace with real integration data later.
• Domain modules own engineering decisions. Thresholds, score calculation, reason codes, and action priority should not be hidden inside DOM rendering. Kiro should generate pure domain functions first, then make the UI consume their output.
• UI modules own browser behavior only. Tab activation, search input, sort buttons, SVG rendering, and detail panels are browser concerns. Separating them prevents accidental changes to process-risk logic when styling or interaction behavior changes.

Additional Kiro capability coverage

1. Spec refinement from existing code

Prompt:

Read the existing HTML demo and create a Kiro spec that preserves its user-visible behavior but redesigns the implementation into typed TypeScript modules. Include requirements for tab navigation, risk-board sorting, row-detail expansion, FDC matrix rendering, runbook rendering, SVG charts, and advisory-only safety boundaries.

2. Steering generation from prototype language

Prompt:

Generate steering files from the HTML demo vocabulary. Capture terms such as SPC blind window, CD-SEM, TMG, Fleet Mean, FDC health-link, Mandel Slope, Residual 3σ, APC Guard, Hold Review, and Yield-Loss Watch. Make Kiro preserve these terms consistently in code, tests, and documentation.

3. Refactor planning

Prompt:

Analyze the monolithic HTML demo and propose a refactoring plan into TypeScript modules. Do not write code yet. Identify each original JavaScript function, its responsibility, target module, test strategy, and dependency direction.

4. Test generation from UI behavior

Prompt:

Generate tests for functions extracted from the HTML demo: id normalization, SVG path generation, search filtering, sort comparison, risk classification, action selection, and status box rendering. Use deterministic fixtures.

5. Review for unsafe automation

Prompt:

Review all labels, actions, and generated code for unsafe automation language. The application may recommend Hold Review, APC Guard, Route Limit, Watch, Release, or Golden Wafer check, but it must not issue commands to equipment, tools, MES, APC, or dispatch systems.

Workshop facilitation detail: how to review Kiro output

Developers should review Kiro output in four passes:

1. Behavior pass: Does the generated feature match the HTML demo behavior?
2. Architecture pass: Is domain logic separated from rendering?
3. Safety pass: Does the code remain advisory-only?
4. Test pass: Are threshold and edge cases covered?

System design decision

• Behavior parity comes before visual perfection. The first engineering goal is to reproduce tabs, board sorting, detail expansion, and risk logic. Pixel-perfect CSS can be refined later.
• Architecture review catches AI shortcuts. Kiro may generate code that works but mixes concerns. Developers should insist on modules, typed boundaries, and pure functions where the design requires them.
• Safety review is domain-specific. Generic linters cannot detect that “auto-hold tool” is unacceptable language. Professional developers must review generated labels and workflows against domain constraints.

---

Project architecture

The project is a local static TypeScript application generated and refined with Kiro. It has deliberately small moving parts:

kiro-fab-spc-portal/
├── .kiro/
│   ├── steering/
│   ├── specs/
│   └── hooks/
├── docs/
│   └── decision-log.md
├── src/
│   ├── data/
│   │   └── sampleData.ts
│   ├── domain/
│   │   ├── risk.ts
│   │   └── types.ts
│   ├── ui/
│   │   └── render.ts
│   ├── main.ts
│   └── styles.css
├── tests/
│   └── risk.test.ts
├── index.html
├── package.json
├── tsconfig.json
└── vite.config.ts

Step 1 — Create baseline project files

Kiro prompt

Create a new Vite TypeScript project for a local static app. Add package.json, tsconfig.json, vite.config.ts, index.html, src/main.ts, and src/styles.css. Keep the initial main file minimal. Use no framework.

Code sample — package.json

{
  "name": "kiro-fab-spc-portal",
  "version": "0.1.0",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "test": "vitest run",
    "test:watch": "vitest",
    "lint": "tsc --noEmit"
  },
  "devDependencies": {
    "@vitejs/plugin-legacy": "latest",
    "typescript": "latest",
    "vite": "latest",
    "vitest": "latest"
  }
}

Explanation

Business logic: This file defines the developer workflow, not product behavior. The workshop needs predictable commands for running the app, building the app, checking TypeScript, and running tests.

Code logic: dev starts Vite, build compiles TypeScript and bundles the site, test runs Vitest once, test:watch runs tests continuously, and lint uses TypeScript as a strict static checker.

Expected result: After npm install, developers can run npm run dev to start the portal and npm test to verify business rules.

System design decision

• Vite is chosen for minimal ceremony. The workshop must focus on Kiro, not framework setup. Vite gives fast local feedback, a simple TypeScript pipeline, and enough structure for realistic source organization.
• No frontend framework keeps generated code transparent. React or Vue would add component conventions and build abstractions. Plain TypeScript forces generated logic to be explicit, making Kiro’s decisions easier to inspect.
• Scripts become hook targets. Kiro hooks need stable commands. Defining test and lint early lets later automation reference standard project operations without hardcoding complex shell pipelines.

---

Step 2 — Add steering files

Kiro prompt

Create workspace steering files in .kiro/steering. Include product.md, tech.md, structure.md, domain.md, and testing.md. The project is advisory-only and must never command equipment. Domain calculations must be pure functions with Vitest coverage.

Code sample — .kiro/steering/domain.md

# Domain Steering

This project models Fab metrology risk for a local developer demo.

Required domain terms:

- CD-SEM: Critical Dimension SEM metrology tool.
- SPC blind window: elapsed production time since the last trusted SPC or golden-wafer check.
- TMG: total matching guarantee. Workshop demo UCL is 0.20 nm unless a function receives a layer-specific value.
- Mandel Slope: linearity indicator. Safe range is 0.98 to 1.02.
- Fleet deviation: tool mean deviation from Fleet Mean in sigma units.
- Residual 3σ: random measurement noise indicator. Workshop demo UCL is 0.18 nm.

Safety boundary:

- The app may recommend review, watch, route limit, golden-wafer check, or APC guard.
- The app must not issue machine commands or represent autonomous fab control.

Explanation

Business logic: This steering file teaches Kiro the vocabulary and operating boundaries for metrology risk. It reduces incorrect assumptions and preserves the advisory-only nature of the portal.

Code logic: Kiro reads markdown steering as persistent workspace context. The file supplies thresholds, allowed recommendations, and prohibited behavior that future prompts should respect.

Expected result: Later generated specs, code, tests, and review comments should consistently use the same terms and avoid unsafe automation language.

System design decision

• Domain terms are centralized because they affect generated behavior. If every prompt explains TMG, Fleet deviation, and residual 3σ differently, Kiro may generate inconsistent code. Steering converts vocabulary into stable project context.
• Safety constraints are documented before implementation. The portal influences production thinking, so the boundary between advisory recommendations and equipment action must exist before UI labels or action names are generated.
• Thresholds are explicit defaults, not hidden constants. Kiro can reference these values when writing specs and tests. Developers can later override them per layer without losing traceability to the workshop baseline.

---

Step 3 — Create the Kiro spec

Kiro prompt

Create a spec named fab-spc-portal. Requirements: summary metrics, CD-SEM risk board, risk score, advisory action, search, sort, FDC health-link matrix, dynamic matching section, yield triage section, tests, accessibility, and no equipment commands. Generate requirements, design, and tasks.

Expected spec artifacts

.kiro/specs/fab-spc-portal/requirements.md
.kiro/specs/fab-spc-portal/design.md
.kiro/specs/fab-spc-portal/tasks.md

Example requirement style

## Requirement 3 — Risk calculation

The application shall compute a deterministic risk score for each CD-SEM tool.

Acceptance criteria:

1. Given TMG greater than the configured UCL, the risk score shall increase.
2. Given Mandel Slope outside 0.98–1.02, the risk score shall increase.
3. Given Fleet deviation greater than 3σ, the recommended action shall be Hold Review.
4. Given Residual 3σ greater than 0.18 nm, the recommended action shall be Golden Wafer or Route Limit.
5. Given no threshold violations, the recommended action shall be Release.

Explanation

Business logic: The requirement maps fab metrology indicators to explicit outcomes, making the portal’s recommendations auditable.

Code logic: These acceptance criteria become test cases for pure TypeScript functions. Kiro can use them to generate both implementation and Vitest assertions.

Expected result: Developers should have a traceable plan before writing feature code.

System design decision

• Acceptance criteria translate engineering policy into executable checks. Without them, Kiro may make subjective UI choices. With them, developers can verify whether generated behavior matches intended risk boundaries.
• The spec separates product behavior from code structure. Requirements describe what the portal must do; design describes how modules interact; tasks describe implementation order. This separation improves review quality.
• Generated tasks become a controlled execution plan. Developers can ask Kiro to implement one task at a time, inspect diffs, run tests, and only then proceed. This reduces unreviewed AI-generated changes.

---

Step 4 — Define domain types

Kiro prompt

Implement the domain types from the spec in src/domain/types.ts. Use explicit union types for advisory actions and risk levels. Include FDC health-link types and runbook step types.

Code sample — src/domain/types.ts

export type AdvisoryAction =
  | "Release"
  | "Watch"
  | "RunGoldenWafer"
  | "RouteLimit"
  | "ApcGuard"
  | "HoldReview";

export type RiskLevel = "low" | "medium" | "high" | "critical";

export interface CdSemTool {
  id: string;
  layer: string;
  symptom: string;
  blindWindowHours: number;
  tmgNm: number;
  mandelSlope: number;
  fleetDeviationSigma: number;
  residualThreeSigmaNm: number;
  deltaMeanSeries: number[];
}

export interface RiskAssessment {
  toolId: string;
  score: number;
  level: RiskLevel;
  action: AdvisoryAction;
  reasons: string[];
}

export interface FdcHealthLink {
  sensor: string;
  physicalMeaning: string;
  metrologyImpact: string;
  yieldRisk: string;
  rule: string;
}

export interface RunbookStep {
  timebox: string;
  title: string;
  outcome: string;
}

Explanation

Business logic: These types describe the project’s core language: tools, risk assessments, health links, and implementation runbook steps.

Code logic: Union types restrict valid advisory actions and risk levels. Interfaces make each data object explicit, searchable, and refactorable.

Expected result: Kiro and TypeScript will catch unsupported action names, missing fields, or inconsistent data shapes during development.

System design decision

• Types act as contracts between Kiro-generated modules. The data file, risk engine, renderer, and tests all depend on the same interfaces. This reduces accidental mismatch as Kiro adds code across files.
• Union types prevent unsafe action drift. The application must recommend only known advisory actions. A union type stops generated code from inventing labels like “AutoHoldTool” or “ChangeRecipe.”
• Series data is included for future visualization. The workshop renders simple trajectories, but the domain model already supports trend analysis. This shows developers how to design for extension without adding backend complexity.

---

Step 5 — Add sample data

Kiro prompt

Create src/data/sampleData.ts with ten realistic CD-SEM tool records, four FDC health-link records, and eight runbook steps. Include normal, watch, hold, residual-noise, slope-mismatch, and blind-window cases.

Code sample — src/data/sampleData.ts

import type { CdSemTool, FdcHealthLink, RunbookStep } from "../domain/types";

export const cdSemTools: CdSemTool[] = [
  {
    id: "CDSEM-01",
    layer: "Gate ADI",
    symptom: "Stable master, production anchor",
    blindWindowHours: 1.2,
    tmgNm: 0.12,
    mandelSlope: 1.0,
    fleetDeviationSigma: 0.4,
    residualThreeSigmaNm: 0.08,
    deltaMeanSeries: [0.02, 0.01, 0.03, 0.01, 0.02]
  },
  {
    id: "CDSEM-03",
    layer: "Fin Dense CD",
    symptom: "Deflector DAC wobble, slope mismatch",
    blindWindowHours: 7.4,
    tmgNm: 0.23,
    mandelSlope: 1.031,
    fleetDeviationSigma: 3.2,
    residualThreeSigmaNm: 0.16,
    deltaMeanSeries: [0.02, 0.03, 0.06, 0.08, 0.12]
  }
];

export const fdcHealthLinks: FdcHealthLink[] = [
  {
    sensor: "Gun chamber vacuum",
    physicalMeaning: "Electron beam environment stability",
    metrologyImpact: "Residual 3σ and TMP rise",
    yieldRisk: "False alarms and random CD noise",
    rule: "Tighten TMG UCL and schedule golden-wafer check when vacuum degrades with residual noise."
  }
];

export const runbookSteps: RunbookStep[] = [
  {
    timebox: "Day 0",
    title: "Select POC scope",
    outcome: "Choose one critical layer, one product family, and representative CD-SEM tools."
  }
];

Explanation

Business logic: Sample data simulates real operating states: stable master tool, slope mismatch, excessive TMG, Fleet deviation, and residual noise.

Code logic: The arrays satisfy the domain interfaces and become deterministic input for rendering and tests.

Expected result: The app can render meaningful risk states without live fab data.

System design decision

• Representative sample data makes the demo realistic. Developers need both good and bad tools to validate sorting, colors, recommendations, and tests. A single happy-path record would not exercise the portal.
• Data is separated from calculations. This allows Kiro to modify UI or testing without rewriting the source records. It also makes later replacement with live data easier.
• The sample intentionally includes threshold breaches. High-risk values prove that advisory actions, reason strings, and visual states work. Kiro can also use these records to infer missing test cases.

---

Step 6 — Implement risk engine

Kiro prompt

Implement src/domain/risk.ts. Create assessTool(tool) and assessFleet(tools). Keep the logic deterministic. Use demo thresholds: TMG UCL 0.20 nm, slope safe range 0.98 to 1.02, fleet hold above 3σ, fleet watch above 2σ, residual 3σ UCL 0.18 nm, blind-window watch above 6 hours.

Code sample — src/domain/risk.ts

import type { AdvisoryAction, CdSemTool, RiskAssessment, RiskLevel } from "./types";

const LIMITS = {
  tmgUclNm: 0.2,
  slopeLow: 0.98,
  slopeHigh: 1.02,
  fleetWatchSigma: 2,
  fleetHoldSigma: 3,
  residualUclNm: 0.18,
  blindWindowWatchHours: 6
};

export function assessTool(tool: CdSemTool): RiskAssessment {
  let score = 0;
  const reasons: string[] = [];

  if (tool.tmgNm > LIMITS.tmgUclNm) {
    score += 30;
    reasons.push("TMG exceeds demo UCL");
  }

  if (tool.mandelSlope < LIMITS.slopeLow || tool.mandelSlope > LIMITS.slopeHigh) {
    score += 25;
    reasons.push("Mandel Slope outside safe range");
  }

  if (tool.fleetDeviationSigma > LIMITS.fleetHoldSigma) {
    score += 35;
    reasons.push("Fleet deviation exceeds hold threshold");
  } else if (tool.fleetDeviationSigma > LIMITS.fleetWatchSigma) {
    score += 20;
    reasons.push("Fleet deviation exceeds watch threshold");
  }

  if (tool.residualThreeSigmaNm > LIMITS.residualUclNm) {
    score += 20;
    reasons.push("Residual 3σ exceeds noise threshold");
  }

  if (tool.blindWindowHours > LIMITS.blindWindowWatchHours) {
    score += 15;
    reasons.push("SPC blind window is stale");
  }

  const normalizedScore = Math.min(score, 100);
  const level = classifyRisk(normalizedScore);
  const action = chooseAction(tool, normalizedScore);

  return {
    toolId: tool.id,
    score: normalizedScore,
    level,
    action,
    reasons: reasons.length > 0 ? reasons : ["No threshold breach detected"]
  };
}

export function classifyRisk(score: number): RiskLevel {
  if (score >= 85) return "critical";
  if (score >= 65) return "high";
  if (score >= 35) return "medium";
  return "low";
}

export function chooseAction(tool: CdSemTool, score: number): AdvisoryAction {
  if (tool.fleetDeviationSigma > LIMITS.fleetHoldSigma) return "HoldReview";
  if (tool.mandelSlope < LIMITS.slopeLow || tool.mandelSlope > LIMITS.slopeHigh) return "HoldReview";
  if (tool.tmgNm > LIMITS.tmgUclNm) return "ApcGuard";
  if (tool.residualThreeSigmaNm > LIMITS.residualUclNm) return "RunGoldenWafer";
  if (score >= 65) return "RouteLimit";
  if (score >= 35) return "Watch";
  return "Release";
}

export function assessFleet(tools: CdSemTool[]): RiskAssessment[] {
  return tools.map(assessTool).sort((a, b) => b.score - a.score);
}

Explanation

Business logic: The risk engine transforms metrology signals into a normalized score, reasons, risk level, and advisory action. It models the idea that TMG, slope mismatch, Fleet deviation, residual noise, and stale SPC windows increase operational risk.

Code logic: assessTool uses additive scoring and reason collection. classifyRisk maps score to severity. chooseAction prioritizes the most important safety conditions before using score fallback. assessFleet evaluates and sorts all tools.

Expected result: A healthy tool receives Release. A tool above Fleet hold threshold or outside Mandel Slope range receives HoldReview. A tool with excessive TMG receives ApcGuard. A noisy tool receives RunGoldenWafer.

System design decision

• The engine is pure and deterministic. It accepts a tool object and returns an assessment with no DOM, clock, random, network, storage, or side effects. This makes Kiro-generated tests dependable.
• Action selection is priority-based. Some violations require stronger advisory actions regardless of total score. For example, Fleet deviation above 3σ or Mandel Slope outside tolerance should not be hidden by a generic medium-risk classification.
• Reason strings support explainability. Professional users need to know why an action was recommended. Returning reasons with the score supports UI transparency, test assertions, and later audit logging.