Kiro：提示詞庫與深度程式碼說明附錄

僅供教育工程用途。本內容是軟體架構演練，不屬於製程放行建議。

如何使用本附錄

在工作坊期間，請在 Kiro 中使用這些提示。這些提示刻意寫得具體，因為專業團隊應該提供情境、限制與驗收條件，而不是模糊地提出需求。

---

提示組 1 — 專案啟動

提示 1.1 — 建立專案骨架

You are helping me build a professional TypeScript workshop project from scratch. Create the minimal Vite project files for a static browser application. Use no frontend framework. Include scripts for dev, build, test, test:watch, and lint. Do not add business logic yet.

這個提示為何有效

• 它定義角色、技術與範圍。
• 它阻止過早實作領域邏輯。
• 它建立日後 hooks 可以呼叫的標準 scripts。

系統設計決策

• 提示縮小了第一個 Kiro 任務。 新專案很容易擴張出不必要的檔案。只要求骨架的請求提供受控基準，也避免將設定與產品行為混在一起。
• 不使用框架是一項架構限制。 工作坊重點是 Kiro 的 AI 工程工作流程，而不是元件函式庫的使用。純 TypeScript 讓產生的決策更可見。
• 標準 scripts 建立穩定合約。 未來的提示、hooks 與文件可以一致參照 npm test、npm run lint 與 npm run build。

---

提示組 2 — Steering

提示 2.1 — 產生基礎 Steering

Generate workspace steering files for this project. Create product.md, tech.md, structure.md, domain.md, and testing.md. The project is a local advisory-only Fab SPC portal. It must model CD-SEM risk but must never command equipment. Use deterministic TypeScript functions and Vitest tests.

提示 2.2 — 改善 Domain Steering

Review .kiro/steering/domain.md. Add missing terms for SPC blind window, TMG, Mandel Slope, Fleet deviation, Residual 3σ, FDC health-link, APC guard, and yield-loss triage. Keep the language concise and enforce advisory-only behavior.

系統設計決策

• Steering 提示應明確說明禁止的行為。 對敏感領域的工程工具而言，只描述要建置什麼並不夠。開發人員也必須定義不得產生什麼。
• 領域詞彙屬於 workspace 記憶。 Kiro 理解這些術語後，後續的 spec、程式碼與測試產生會更一致。這能減少重複解釋，並避免術語漂移。
• 測試期望應放在 steering 中。 如果及早說明需要決定性函式與 Vitest 覆蓋率，Kiro 更可能產生可測試的結構，而不是高度耦合的 UI 程式碼。

---

提示組 3 — 建立 Spec

提示 3.1 — 建立 Spec

Create a Kiro spec named fab-spc-portal. The feature is a local browser portal for detecting when routine SPC monitoring frequency is out of sync with actual mass production. Include requirements, system design, data model, risk scoring, UI behavior, accessibility, tests, and implementation tasks.

提示 3.2 — 強化驗收條件

Refine the requirements. Add acceptance criteria for: TMG above UCL, Mandel Slope outside 0.98–1.02, Fleet deviation above 2σ and 3σ, Residual 3σ above 0.18 nm, blind window above six hours, empty search results, and advisory-only safety language.

系統設計決策

• 第一個提示建立端到端計畫。 Kiro 應將功能理解成一個系統，而不是一堆隨機檔案。需求、設計與任務形成可追溯的交付路徑。
• 第二個提示強化邊界案例。 初始 AI spec 可能遺漏邊界條件。要求特定閾值與空狀態，讓最終程式碼更容易驗證。
• Spec 成為可審查的證據。 開發人員可以將產生的實作與 spec 比較，並拒絕偏離的程式碼。對採用 AI 輔助交付的專業團隊而言，這尤其重要。

---

提示組 4 — 領域邏輯

提示 4.1 — 實作純風險函式

Implement the risk engine as pure TypeScript functions. Inputs are CdSemTool objects. Outputs are RiskAssessment objects with score, level, action, and reasons. Do not read the DOM, localStorage, network, clock, or random values. Keep thresholds centralized.

提示 4.2 — 要求審查風險優先順序

Review the risk engine priority order. Fleet deviation >3σ and Mandel Slope outside 0.98–1.02 should result in HoldReview. TMG above UCL should result in ApcGuard unless a higher-priority hold condition exists. Residual 3σ above limit should result in RunGoldenWafer unless a higher-priority condition exists.

系統設計決策

• 純函式降低非決定性。 當計算不依賴外部狀態時，Kiro 產生的程式碼更容易信任。開發人員可以有信心地測試、審查與重構領域層。
• 集中閾值改善可維護性。 散落在 UI 與測試中的閾值會造成未來漂移。單一常數區段讓審查與依圖層擴充更直接。
• 優先順序審查防止誤導性建議。 一般分數可能掩蓋嚴重條件。明確的優先規則確保安全相關發現優先於較低層級的觀察狀態。

---

提示組 5 — UI 實作

提示 5.1 — Render 儀表板

Implement the UI rendering layer. Show summary metrics, tool rows, risk score, blind-window age, TMG, slope, Fleet σ, residual 3σ, action button, and reason details. Add search and sort. Keep rendering separate from risk calculations.

提示 5.2 — 無障礙審查

Review the UI for accessibility. Add semantic headings, button labels, sufficient contrast, keyboard-accessible interactions, useful empty states, and readable status text. Do not change domain logic.

系統設計決策

• UI 使用評估結果，而不是自行計算。 這讓視覺程式碼專注在 render、互動與無障礙功能。業務規則留在領域層。
• 搜尋與排序會揭示模型品質。 良好的產生 UI 不應只顯示卡片，也應支援操作工作流程。依風險、TMG、斜率與 Fleet 偏差排序，能讓入口網站真正有用。
• 將無障礙視為實作品質。 開發人員應要求 Kiro 審查語意與互動狀態，再手動檢查結果。無障礙不能成為事後補救。

---

提示組 6 — 測試

提示 6.1 — 產生測試

Generate Vitest tests for the risk engine. Cover healthy release, TMG ApcGuard, Mandel Slope HoldReview, Fleet deviation HoldReview, residual RunGoldenWafer, blind-window Watch, reason strings, and priority ordering when multiple thresholds are breached.

提示 6.2 — 詢問遺漏案例

Analyze the current risk tests and list missing edge cases. Focus on threshold equality, just-over thresholds, negative inputs, NaN handling, empty series, and action priority conflicts. Do not modify files yet.

系統設計決策

• 閾值邊界測試是必要的。 Production bug 常在剛好等於限制值時出現。Kiro 應測試相等與剛超過的案例，讓規則解讀明確。
• 無效資料處理必須刻意決定。 Demo 可以很簡單，但專業開發人員應決定如何處理負值、NaN 或遺漏陣列，而不是讓產生的程式碼意外決定行為。
• 先分析再修改能改善控制。 先要求 Kiro 列出遺漏測試，為開發人員提供一個在接受產生變更前的審查檢查點。

---

提示組 7 — Hooks

提示 7.1 — 建立 Command Hook

Create a Kiro workspace hook that runs npm test after saving files under src/domain or tests. Use PostFileSave, a narrow matcher, command action, 60-second timeout, and enabled true.

提示 7.2 — 建立文件 Hook

Create a Kiro agent hook that updates docs/decision-log.md after a spec task is completed. The hook should summarize changed files, decisions made, and follow-up risks. Keep it workspace-local and do not modify source code.

系統設計決策

• Command hooks 用於決定性檢查。 測試與 linting 有明確的成功或失敗行為，因此自動化安全且可量測。
• Agent hooks 用於敘事工作。 Decision log 需要摘要與情境。Kiro 的語言能力在這裡很有用，但 hook 應限制在文件範圍。
• Matcher 保護開發人員生產力。 Hooks 只應在相關檔案變更時觸發。範圍過大的自動化會產生雜訊、拖慢開發並降低信任。

---

完整程式碼參考 — 領域層

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[];
}

說明

商業邏輯： 型別定義入口網站各處使用的領域合約，讓風險輸入與輸出清楚。

程式碼邏輯： AdvisoryAction 與 RiskLevel 是 union type，因此 TypeScript 會拒絕無效字串。介面定義必要欄位。

預期結果： Kiro 產生的模組共享相同資料合約，若欄位漂移，會在型別檢查期間快速失敗。

---

完整程式碼參考 — 風險引擎

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);

  return {
    toolId: tool.id,
    score: normalizedScore,
    level: classifyRisk(normalizedScore),
    action: chooseAction(tool, normalizedScore),
    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";
}

說明

商業邏輯： 此函式將 fab 量測指標轉換為風險嚴重程度與建議動作，並凸顯哪些指標造成判定。

程式碼邏輯： 每個閾值都會增加分數與原因。分數上限為 100。動作選擇使用優先規則，避免嚴重條件被降級。

預期結果： 開發人員可以信任入口網站一致分類已知條件，並解釋機台為何具有風險。

---

完整程式碼參考 — Hook

.kiro/hooks/test-domain-on-save.json

{
  "version": "v1",
  "hooks": [
    {
      "name": "test-domain-on-save",
      "description": "Run risk tests when domain logic or tests are saved.",
      "trigger": "PostFileSave",
      "matcher": "^(src/domain/.*\\.ts|tests/.*\\.ts)$",
      "action": {
        "type": "command",
        "command": "npm test"
      },
      "timeout": 60,
      "enabled": true
    }
  ]
}

說明

商業邏輯： 領域行為必須保持穩定，因為它會驅動建議動作。

程式碼邏輯： Hook 監看狹窄的路徑樣式，並在儲存後執行決定性的指令。

預期結果： 當變更破壞風險計算時，開發人員會立即得到回饋。

---

最終 Capstone 提示

Act as a senior technical reviewer. Compare the implementation with the Kiro spec and steering files. Identify gaps in requirements coverage, domain correctness, tests, accessibility, maintainability, and hook safety. Return a prioritized list with recommended fixes. Do not change files.

最終開發人員練習

要求 Kiro 實作其中一項審查建議，但必須先：

1. 找出它對應的 spec 需求。
2. 預測哪些檔案應該變更。
3. 預測應新增或更新哪些測試。
4. 手動審查產生的 diff。
5. 執行 hook 觸發的測試指令或手動測試指令。

---

# 擴充提示詞與程式碼附錄：使用 Kiro 遷移 HTML Demo

本附錄加入以 Fab SPC Drift Synchronization HTML Demo 為基礎的更深入提示模式與程式碼範例。當教導開發人員如何從可運作的瀏覽器 prototype 移轉至模組化、可測試且由 Kiro 建立的專案時，請使用這些提示。

提示組 8 — Demo 匯入與結構化分析

提示 8.1 — 先解釋再變更

Read the HTML demo and explain its architecture before making changes. Group findings into: layout, styling system, data model, risk board behavior, chart rendering, tab state, FDC matrix, runbook rendering, live simulation, and safety boundaries. Then propose target TypeScript modules.

提示 8.2 — 建立遷移任務

Create implementation tasks to migrate the HTML demo into a TypeScript/Vite app. Each task must have input files, output files, acceptance criteria, and test strategy. Preserve visual behavior as much as possible but improve architecture, accessibility, and testability.

系統設計決策

• 先解釋的提示能降低盲目產生。 Kiro 應在撰寫替代模組之前展示它理解來源 prototype。這能避免意外遺失行為。
• 遷移任務必須包含測試。 沒有測試就重構可運作的 Demo 是有風險的。每個任務都應指出開發人員如何在擷取行為後驗證它。
• 提示區分 parity 與改善。 目標不是複製每個實作細節，而是在改善結構、無障礙與安全性的同時保留使用者可見行為。

---

提示組 9 — 擷取 CSS 設計系統

提示 9.1 — 擷取 CSS Token

Extract the visual design system from the HTML demo into src/styles.css. Preserve the dark factory-portal style, CSS variables, cards, grids, tabs, board rows, metric boxes, responsive breakpoints, and chart styling. Remove unused selectors and group CSS by responsibility.

程式碼範例 — CSS Token 擷取

:root {
  --bg: #061018;
  --panel: #081522;
  --panel2: #0c1f31;
  --line: #28465f;
  --text: #edf6ff;
  --muted: #9fb3c8;
  --cyan: #38bdf8;
  --cyan2: #77c7ff;
  --green: #31c48d;
  --red: #f05252;
  --yellow: #f6c85f;
  --orange: #fb923c;
  --mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, monospace;
  --sans: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans", Arial, sans-serif;
}

body {
  margin: 0;
  color: var(--text);
  font-family: var(--sans);
  min-height: 100vh;
  background:
    linear-gradient(rgba(255, 255, 255, 0.025) 1px, transparent 1px),
    linear-gradient(90deg, rgba(255, 255, 255, 0.025) 1px, transparent 1px),
    radial-gradient(circle at 8% 0, rgba(56, 189, 248, 0.19), transparent 30%),
    #061018;
  background-size: 32px 32px, 32px 32px, auto, auto;
}

.card,
.panel,
.chart-card,
.metrics {
  border: 1px solid var(--line);
  background: #06111c;
  padding: 14px;
}

說明

商業邏輯： 入口網站的視覺識別傳達工程營運主控台：深色背景、青色／黃色重點、指標卡片與風險色彩。

程式碼邏輯： CSS 變數集中管理色彩與字型決策。共用卡片選取器避免重複撰寫 border、background 與 padding 規則。

預期結果： TypeScript 專案保留 HTML Demo 的深色工廠入口網站風格，同時以可維護的方式組織 CSS。

系統設計決策

• Design token 保留視覺一致性。 先擷取變數，可以避免 Kiro 產生新元件時發生樣式漂移。
• 共用選取器減少重複。 原始 Demo 使用重複的 panel／card 模式。將它們分組後，未來更容易加入 UI 區段。
• Responsive 規則保留在 CSS。 版面配置適應屬於 CSS，而不是 TypeScript。這讓 render 程式碼專注於內容與行為。

---

提示組 10 — Render 分解

提示 10.1 — 產生 Render 模組

Create src/ui/render.ts that composes the portal sections from smaller render functions. Include renderHeader, renderHero, renderStats, renderTabs, renderRiskBoard, renderFdcMatrix, renderMatchingSection, renderTriageSection, and renderRunbook. Do not put risk calculations inside this file.

程式碼範例 — Render 組合

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

export interface AppViewModel {
  tools: CdSemTool[];
  assessments: RiskAssessment[];
  fdcHealthLinks: FdcHealthLink[];
  runbookSteps: RunbookStep[];
}

export function renderApp(root: HTMLElement, model: AppViewModel): void {
  root.innerHTML = `
    <main class="page" id="top">
      <section class="shell">
        ${renderHeader()}
        ${renderHero()}
        ${renderStats(model)}
        <section class="content">
          ${renderTabs()}
          ${renderOverview()}
          ${renderRiskBoard(model.tools, model.assessments)}
          ${renderFdcMatrix(model.fdcHealthLinks)}
          ${renderRunbook(model.runbookSteps)}
        </section>
        ${renderFooter()}
      </section>
    </main>
  `;
}

說明

商業邏輯： Render 器組合與 Demo 入口網站相同的高階區段：header、hero、統計資料、分頁、風險看板、FDC、runbook 與頁尾。

程式碼邏輯： renderApp 接收 view model，並將每個區段委派給較小的函式。它不計算風險，也不修改資料。

預期結果： 開發人員可以個別審查、測試與修改各區段，而不必編輯一個大型 HTML 字串。

系統設計決策

• View model 邊界讓 render 可預測。 Render 器收到所需的全部資料，因此更容易測試，也能避免隱藏的全域相依。
• 小型 render 函式協助 Kiro 產生可審查的 diff。 如果 FDC matrix 變更，Kiro 應編輯該 render 器，而不是一個巨大頁面函式。
• 刻意排除領域邏輯。 Render 應顯示決策，而不是做出決策。這讓風險規則可以不設定 DOM 就進行測試。

---

提示組 11 — 看板資料列與狀態色彩提示

提示 11.1 — Render 看板資料列

Implement renderRiskRow(tool, assessment). It should display rank, tool id, layer, symptom, risk score, blind window, TMG, Mandel Slope, Fleet σ, and action label. Match the HTML demo's color logic: high risk is red, watch is yellow, safe is green/cyan.

程式碼範例 — 狀態色調工具

export type Tone = "pos" | "neg" | "yellow" | "cyan";

export function riskTone(score: number): Tone {
  if (score >= 80) return "neg";
  if (score >= 55) return "yellow";
  return "pos";
}

export function thresholdTone(value: number, limit: number, direction: "above-is-bad" | "below-is-bad"): Tone {
  if (direction === "above-is-bad") {
    return value > limit ? "neg" : "pos";
  }

  return value < limit ? "neg" : "pos";
}

export function slopeTone(slope: number): Tone {
  return slope < 0.98 || slope > 1.02 ? "neg" : "pos";
}

說明

商業邏輯： 工程師需要風險分數、TMG 違反、斜率不匹配、Fleet 偏差與殘差雜訊的視覺嚴重程度提示。

程式碼邏輯： 輔助函式集中管理色彩 class 決策，避免在不同 render 器中重複條件運算式。

預期結果： UI 色彩行為與 HTML Demo 一致，也更容易測試。

系統設計決策

• Tone 邏輯是 UI 邏輯，而不是領域動作邏輯。 領域決定建議，UI 決定色彩 class。將兩者分離，可避免視覺變更影響業務決策。
• 命名的輔助程式改善可審查性。 slopeTone() 比重複的 inline 比較更容易理解。Kiro 應產生有表達力的輔助程式名稱。
• 色彩 class 保留 prototype 風格。 使用 pos、neg、yellow 與 cyan，在模組化程式碼的同時維持與 Demo CSS 的相容性。

---

提示組 12 — 安全性與 Escaping 提示

提示 12.1 — 新增 HTML Escaping

Review all render functions that interpolate tool id, layer, symptom, FDC descriptions, and runbook text. Add an escapeHtml utility and use it consistently. Keep trusted static SVG structure unchanged.

程式碼範例 — src/ui/escapeHtml.ts

export function escapeHtml(value: string): string {
  return value
    .replaceAll("&", "&")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");
}

說明

商業邏輯： 今天的工作坊資料是靜態的，但未來資料可能來自檔案、API、匯出結果或使用者輸入。顯示的工程文字不應變成可執行標記。

程式碼邏輯： 輔助程式會在字串插入範本前，將 HTML 特殊字元替換為安全的 entity。

預期結果： 即使 tool symptom 與 FDC 文字包含 <、> 或 & 等字元，也會以文字呈現。

系統設計決策

• 安全改善是讓 Demo 專業化的一部分。 Prototype 可以假設字串可信。開發人員工作坊應示範更安全的預設做法。
• Escaping 應靠近 render。 領域模組不應知道 HTML。Render 工具應處理 presentation layer 的編碼。
• 應要求 Kiro 審查 injection 路徑。 AI 產生的範本字串可能意外插入未 escaping 的內容。專門的提示可以捕捉這項風險。

---

提示組 13 — Kiro 產生的 Commit 計畫

提示 13.1 — 建立以 Commit 為單位的實作計畫

Split the remaining work into commit-sized changes. Each commit should include purpose, files changed, tests to run, and review risks. Keep each commit small enough for a senior developer to review in under ten minutes.

輸出範例

## Commit 1 — Domain contracts and fixtures
Files:
- src/domain/types.ts
- src/data/tools.ts
- src/data/fdc.ts
- src/data/runbook.ts

Tests:
- npm run lint

Review risks:
- Action labels must remain advisory-only.
- Fixture values must match demo intent.

## Commit 2 — Risk engine
Files:
- src/domain/thresholds.ts
- src/domain/risk.ts
- tests/risk.test.ts

Tests:
- npm test
- npm run lint

Review risks:
- Priority order for HoldReview vs ApcGuard.
- Boundary behavior at exact thresholds.

系統設計決策

• Commit 規劃讓 AI 工作可審查。 大型 AI diff 很難信任。以 Commit 為單位的計畫保留工程紀律。
• 每個 Commit 都包含測試。 開發人員應確切知道在接受變更前要如何驗證。
• 明確列出審查風險。 Kiro 可以協助找出需要人類注意的地方，但開發人員仍須對最終決策負責。

---

額外程式碼範例 — Demo 的閾值常數

export const demoThresholds = {
  tmgUclNm: 0.2,
  slopeLow: 0.98,
  slopeHigh: 1.02,
  fleetWatchSigma: 2,
  fleetHoldSigma: 3,
  residualThreeSigmaUclNm: 0.18,
  siteToSiteDeltaUclNm: 0.3,
  blindWindowWatchHours: 6
} as const;

說明

商業邏輯： 閾值反映 Demo 的決策邊界：TMG UCL、Mandel 斜率安全範圍、Fleet 警告與暫停限制、殘差雜訊限制、Site-to-site 限制與過時盲窗限制。

程式碼邏輯： as const 讓物件唯讀並保留 literal 值，協助 TypeScript 捕捉意外修改。

預期結果： 所有風險邏輯都匯入相同閾值，而不是重複定義數字。

---

額外程式碼範例 — 以程式碼表示動作優先順序表

import type { AdvisoryAction, CdSemTool } from "./types";
import { demoThresholds } from "./thresholds";

export function choosePriorityAction(tool: CdSemTool, score: number): AdvisoryAction {
  const t = demoThresholds;

  if (tool.fleetDeviationSigma > t.fleetHoldSigma) {
    return "HoldReview";
  }

  if (tool.mandelSlope < t.slopeLow || tool.mandelSlope > t.slopeHigh) {
    return "HoldReview";
  }

  if (tool.tmgNm > t.tmgUclNm) {
    return "ApcGuard";
  }

  if (tool.residualThreeSigmaNm > t.residualThreeSigmaUclNm) {
    return "RunGoldenWafer";
  }

  if (tool.blindWindowHours > t.blindWindowWatchHours) {
    return "RunSpc";
  }

  if (score >= 65) {
    return "RouteLimit";
  }

  if (score >= 35) {
    return "Watch";
  }

  return "Release";
}

說明

商業邏輯： 當多個風險因素同時存在時，入口網站應建議最強的建議動作。Fleet hold 與斜率不匹配代表系統性的量測可信度問題，因此優先級較高。

程式碼邏輯： 函式先評估高優先級閾值違反，再退回以分數為基礎的動作。

預期結果： 同時具有過時 SPC 與斜率不匹配的機台會收到 HoldReview，而不只是 RunSpc 或 Watch。

---

額外程式碼範例 — 風險原因代碼

export type RiskReasonCode =
  | "TMG_ABOVE_UCL"
  | "SLOPE_OUT_OF_RANGE"
  | "FLEET_SIGMA_WATCH"
  | "FLEET_SIGMA_HOLD"
  | "RESIDUAL_NOISE_HIGH"
  | "BLIND_WINDOW_STALE"
  | "NO_THRESHOLD_BREACH";

export interface RiskReason {
  code: RiskReasonCode;
  message: string;
  evidence: string;
}

說明

商業邏輯： 原因代碼讓建議更容易稽核、測試、翻譯與摘要。

程式碼邏輯： 結構化原因包含穩定的代碼、人類可讀的訊息，以及像 fleetDeviationSigma=3.2 這樣的證據。

預期結果： UI 可以顯示清楚的解釋，而測試則能斷言穩定的原因代碼。

---

額外提示 — 要求 Kiro 升級原因

Refactor risk reasons from plain strings into structured reason objects with code, message, and evidence. Update tests to assert reason codes. Update UI to display message and evidence. Preserve existing action behavior.

系統設計決策

• 結構化原因優於純字串。 測試不應依賴精確的句子措辭。代碼提供穩定斷言，而訊息仍可保持對使用者友善。
• 證據欄位改善可稽核性。 建議應顯示是哪個指標造成它，以及觀察到的值為何。
• 重構原因是安全的 Kiro 任務。 既有動作行為已經過測試，開發人員可以要求 Kiro 改善可解釋性，而不改變決策。

---

最終擴充 Capstone 提示

Perform a final migration review. Compare the TypeScript/Vite app to the original HTML demo. Confirm parity for: header, hero, stats, tabs, risk board, sorting, search, detail panels, FDC matrix, matching section, triage section, runbook, SVG charts, responsive layout, and advisory-only safety text. Then identify production-hardening gaps such as data validation, authentication, audit logging, telemetry, model governance, and integration boundaries. Do not modify files.

最終擴充開發人員練習

1. 要求 Kiro 找出一項遺漏的 parity 項目。
2. 要求 Kiro 提出修正它的最小程式碼變更。
3. 預測會變更哪些檔案。
4. 要求 Kiro 只實作該項變更。
5. 手動審查 diff。
6. 執行測試。
7. 更新 decision log。