Tech Spike · 技術探索

---
doc_type: "tech-spike"
variant: "light"
status: "draft"
owner: "<your-name>"
last_updated: "YYYY-MM-DD"
upstream:
  required: ["problem-statement", "constraints"]
  optional: ["candidate-source"]
---

# Tech Spike Plan: <spike-name>

**Status:** Draft v0.X · **Owner:** <Architect / Senior Dev> · **Last updated:** YYYY-MM-DD

> [!IMPORTANT]
> **AI 填寫規則：** 本範本 6 段（編號 1, 2, 5, 6, 10, 12），全部必填——刻意沿用完整版章節編號讓兩版可對照。Spike goal 必為「決策問題」非「實作問題」；exit criteria **必為布林條件**（如「p95 < 200ms 且 cost < $X/月」）不能寫「感覺夠快」；time-box 必含 hard_stop 日期；缺資料寫 `_TODO_` **不編造 benchmark 數字**；每量化欄位 `[H/M/L]` badge。

---

## 1. Executive Summary

<!-- ai-fill: 3-5 行：決策問題、候選方案數、time-box、為何延後決策更貴 -->

<3-5 行說明>

> **TL;DR:** <一句話：本 spike 要在 N person-days 內回答什麼決策問題>

---

## 2. Spike Goal & Hypothesis

<!-- ai-rule: goal 必為一句話決策問題；hypothesis 必為可被推翻的形式 + null hypothesis -->

- **Decision question:** <例：Kafka 在我們的 throughput / latency / cost 條件下是否優於 RabbitMQ>
- **Decision owner:** <role>
- **Primary hypothesis:** <主要假設，可被推翻>
- **Null hypothesis:** <反例：若 X 則 Kafka 不優>
- **Confidence:** **[M]** — **Source:** problem §1

---

## 5. Candidate Options & Evaluation Criteria

<!-- ai-rule: ≤ 3 個候選（含「維持現狀」如適用）；evaluation 指標必含至少 1 個 NFR (latency / throughput / availability / cost) -->

### Candidates

| Option | Core assumption | Expected failure mode | Setup cost |
|---|---|---|---|
| A: Kafka | 高 throughput 可處理 burst | ops 複雜度高 | 1.5 day |
| B: RabbitMQ | 既有經驗 + 操作簡單 | throughput 上限可能不夠 | 0.5 day |
| C: 維持現狀 | 不引入新依賴 | 業務需求被卡 | 0 |

### Evaluation criteria

| Metric | Target | Measurement |
|---|---|---|
| p95 latency | < 200ms | k6 / wrk 模擬 |
| cost / million msg | < $X | vendor pricing + 自管 ops 估 |

---

## 6. Time-box & Exit Criteria

<!-- ai-rule: time-box 必含硬截止日；exit criteria 必為布林條件 -->

- **Duration:** 3 person-days
- **Hard stop:** YYYY-MM-DD（**不可延**）
- **Exit (success):** 所有候選跑完 + 至少 1 個達 evaluation 全部 target
- **Exit (abort):** time-box 到 / 第三方 SDK 不可用 / 主要假設已被推翻

---

## 10. Decision Log（key 2-3 條）

<!-- ai-rule: 每條必含 chosen + 至少 1 個 rejected + 拒絕原因 -->

| Date | Decision | Options | Chosen | Rejected why | Confidence |
|---|---|---|---|---|---|
| YYYY-MM-DD | 候選清單範圍 | A+B+C / A+B / A+B+NATS | A+B+C | NATS (社群討論不足，跨第三方學習成本) | **[H]** |

---

## 12. Confidence & Sources & TODO

- **整份文件最低 confidence 欄位：** <列出所有 [L] 與 [M]>
- **Fabricated assumptions：**
  - <例：假設 staging 環境 ≈ production 規格>
- **Highest-value next input:** <例：production 流量 sample / vendor pricing 確認>

### TODO（缺資料）

- _TODO: 需 DevOps 提供 staging 環境配置_

---

> [!CAUTION]
> **輸出前 AI 自檢：**
> - [ ] 6 段 H2 章節齊全（編號 1, 2, 5, 6, 10, 12）
> - [ ] Spike goal 是「決策問題」非「實作問題」
> - [ ] Hypothesis 含 primary + null（可被推翻形式）
> - [ ] 候選 ≤ 3 個，每個含 core assumption + failure mode
> - [ ] Evaluation 至少 1 個 NFR metric
> - [ ] Exit criteria 是**布林條件**（沒「感覺夠快」這類詞）
> - [ ] Time-box 含 hard_stop 日期
> - [ ] 沒編造 benchmark 數字（缺者 `_TODO_`）
> - [ ] 無 YAML / JSON schema 輸出（spike plan 是給人讀的 markdown）