triz-verify

name	triz-verify
description	TRIZ Step 4 驗證與複雜度檢查。判定解法為進化或補丁，產出工程規格書或技術債記錄。Use when TRIZ solution proposals need verification, complexity assessment, or downstream deliverable generation.

TRIZ Step 4: 原型驗證 + 複雜度檢查

Overview

本 skill 實作 Auto-TRIZ 閉環流程的 Step 4（Section 6 of docs/auto_triz_strategy.md）。

接收 Step 2-3 產出的解法方案（F/S/OZ/OT + 分離策略 + 標準解），執行：

1. Px 分離驗證
2. 四問複雜度判定（補丁 vs 進化）
3. 新 TC 偵測
4. 下游交付物產出

宣告： 「正在使用 triz-verify skill — 執行 Step 4: 驗證與複雜度檢查。」

---

輸入要求

從 .claude/context/triz/.triz-state.json 讀取 step3 產出，或從對話上下文取得：

必要輸入	來源
解法方案（F/S/OZ/OT）	Step 3 產出
Px 和 PC 造句	Step 3 產出
分離策略 + 邊界條件	Step 3 產出
原始 TC 定義	Step 2 產出

---

Phase 1: Px 分離驗證

1.1 邏輯驗證

用 PC 造句檢查解法是否真正分離了 Px：

原始 PC：Px 必須是 [A]（為了 P1）且 [非 A]（為了 P2）
解法後：
  - 在 [分離維度的一側]，Px = A → P1 滿足 ✓/✗
  - 在 [分離維度的另一側]，Px = 非 A → P2 滿足 ✓/✗

1.2 驗證結果判定

結果	動作
兩側皆滿足	通過，進入 Phase 2
一側不滿足	分離不完整 — 回到 Step 3 調整分離策略
兩側皆不滿足	解法無效 — 回到 Step 2 重新選擇原理

---

Phase 2: 四問複雜度判定

依序問四個問題：

Q1: 結構複雜度 (Structural)

「零件/組件是否變多了？」

• 是 = 新增零件修正舊零件 → 補丁信號
• 否 = 現有零件多功能化 → 進化信號

Q2: 能量複雜度 (Energy)

「能量消耗是否變大了？」

• 是 = 引入新能量系統 → 補丁信號
• 否 = 利用環境資源替代 → 進化信號

Q3: 認知複雜度 (Cognitive)

「別人理解這個邏輯的時間是否變長了？」

• 是 = 依賴鏈變長 → 補丁信號
• 否 = 縮短轉換步驟 → 進化信號

Q4: 演化對齊 (Evolution Alignment)

「解法方向是否符合以下至少一個演化趨勢？」

• 理想度增加（更多功能，更少成本/危害）
• 朝微觀發展（材料層級解決）
• 動態化增加（感測器驅動的狀態切換）

判定規則

Q1-Q3 中有 ≥2 個「是」 → 補丁
           或
Q4 為「否」            → 補丁
           否則
                       → 進化

---

Phase 3: 補丁 vs 進化路徑

進化路徑

解法品質良好，產出下游交付物（Phase 4）。

補丁路徑

判定為補丁
│
├─ 時間/成本允許重新深挖？
│  ├─ 是 → 建議回到 Step 3 (PC) 重新深挖
│  │       詢問使用者是否要返回
│  │
│  └─ 否（出貨壓力）→ 有意識地選擇補丁：
│     1. 記錄為「已知技術債」
│     2. 標記哪個 PC 未被真正解決
│     3. 排入下一代 TRIZ 待辦清單
│     4. 繼續產出交付物

---

Phase 4: 新 TC 偵測

檢查解法是否引入新的技術矛盾：

新方案是否引入新的 TC？
│
├─ 否 → 完成
│
├─ 新 TC 與原 TC 形成迴圈
│  （解 A → 惡化 B → 解 B → 惡化 A）
│  └─ 進入迴圈診斷（檢查 OZ/OT/Px 重疊）
│     └─ 重疊 → 其實是同一個未正確定義的 PC
│     └─ 不重疊 → 兩個獨立 TC
│
└─ 獨立新 TC → 回 Step 1（螺旋上升）

---

Phase 5: 下游交付物

5.1 工程規格書

將 F/S/OZ/OT 轉為可交付的工程規格：

## 工程規格書

### 解法摘要
- **問題**: [原始 TC 描述]
- **解法**: [一句話描述]
- **分離策略**: [類型 + 邊界條件]

### 規格參數
| 參數 | 值 | 單位 | 來源 |
|:-----|:---|:-----|:-----|
| F (場) | [數值] | [單位] | [控制方程] |
| S (物質) | [材料] | [物性] | [資料來源] |
| OZ | [位置] | - | [設計圖] |
| OT | [時機] | [頻率/週期] | [操作條件] |

### Hard Constraints
- [ ] 不違反 [具體物理定律]
- [ ] 相容於現有系統 [具體介面]

5.2 驗證計畫

## 驗證計畫

| 驗證項目 | 量測指標 | 判定標準 | 方法 |
|:---------|:---------|:---------|:-----|
| Px 分離有效 | [指標] | [閾值] | [實驗方法] |
| P1 改善 | [指標] | [目標值] | [量測方法] |
| P2 不惡化 | [指標] | [上限值] | [量測方法] |

5.3 技術債登記（補丁時必填）

## 技術債記錄

- **日期**: [YYYY-MM-DD]
- **未解決的 PC**: [Px 必須是 A 且非 A]
- **當前補丁**: [描述]
- **補丁風險**: [在什麼條件下會失效]
- **建議的真正解法方向**: [基於分離原理的建議]
- **預估解決時間**: [下一代/下下一代]

---

狀態更新

完成後執行兩件事：

1. 更新 state JSON

更新 .claude/context/triz/.triz-state.json 的 step4 區段：

{
  "step4": {
    "completed": true,
    "px_separation_verified": true,
    "verdict": "evolution | patch",
    "complexity_scores": {
      "structural": true,
      "energy": false,
      "cognitive": false,
      "evolution_aligned": true
    },
    "new_tc_detected": false,
    "deliverables": ["engineering_spec", "verification_plan"]
  }
}

2. 追加寫入 session 報告檔（最終區段）

從 .triz-state.json 讀取 report_file 路徑，用 Read tool 讀取報告檔現有內容，再用 Write tool 將以下 Step 4 + 工程交付物區段追加到報告檔末尾，並更新報告頭部的「判定」欄位：

## Step 4: 驗證

### Px 分離驗證
| 分離維度 | Px 狀態 | 參數滿足 | 結果 |
|:---------|:--------|:---------|:-----|
| {一側} | Px = {A} | {P1} 滿足 | {Pass/Fail} |
| {另一側} | Px = {非A} | {P2} 滿足 | {Pass/Fail} |

### 四問複雜度判定
| # | 問題 | 回答 | 信號 |
|:--|:-----|:-----|:-----|
| Q1 | 零件/組件是否變多了？ | {是/否} | {補丁/進化} |
| Q2 | 能量消耗是否變大了？ | {是/否} | {補丁/進化} |
| Q3 | 別人理解邏輯的時間是否變長了？ | {是/否} | {補丁/進化} |
| Q4 | 是否符合至少一個演化趨勢？ | {是/否} | {進化/補丁} |

- **判定**: {evolution / patch}

### 新 TC 偵測
- {否 / 是 — 描述}

---

## 工程交付物

### 工程規格書
| 參數 | 值 | 單位 | 來源 |
|:-----|:---|:-----|:-----|
| F (場) | {值} | {單位} | {來源} |
| S (物質) | {材料} | {物性} | {來源} |
| OZ | {位置} | — | {設計圖} |
| OT | {時機} | {頻率} | {條件} |

#### Hard Constraints
- [ ] {約束 1}
- [ ] {約束 2}

### 驗證計畫
| 驗證項目 | 量測指標 | 判定標準 | 方法 |
|:---------|:---------|:---------|:-----|
| Px 分離有效 | {指標} | {閾值} | {方法} |
| P1 改善 | {指標} | {目標} | {方法} |
| P2 不惡化 | {指標} | {上限} | {方法} |

### 技術債記錄（補丁時必填）
- **未解決的 PC**: {描述}
- **當前補丁**: {描述}
- **補丁風險**: {條件}
- **建議方向**: {分離原理建議}
- **預估解決時間**: {時程}

注意： Step 4 寫入後，同時更新報告檔頭部的 > **判定**: 未完成 改為 > **判定**: {evolution | patch}。

---

下一步導引

Step 4 完成後，依判定結果提示使用者：

判定結果	提示
進化 (evolution)	「Step 4 完成 — 判定為進化。工程規格書和驗證計畫已產出。TRIZ 閉環流程完成。可執行 /triz-status 查看完整 session 摘要。」
補丁 + 返回深挖	「Step 4 完成 — 判定為補丁。建議返回 Step 3 重新深挖 PC。請執行 /triz-solve 繼續。」
補丁 + 有意識接受	「Step 4 完成 — 判定為補丁（出貨壓力下有意識接受）。技術債已記錄，工程規格書已產出。可執行 /triz-status 查看完整 session 摘要。」
偵測到新 TC	「Step 4 完成 — 偵測到新的技術矛盾。建議螺旋上升，以新 TC 為輸入重新進入流程。請執行 /triz 繼續。」
Px 分離驗證失敗	「Px 分離驗證未通過。建議返回調整分離策略。請執行 /triz-solve 繼續。」