feat(可行性檢查): 新增架構、邏輯、資料、時程四份檢查清單

四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問
使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把
它變成一句能收斂的提問，那才是實際卡住的地方。

四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經
做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡），
時程問未知數最大的一項（它決定整體估算的可信度）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

references/feasibility-architecture.md

@@ -0,0 +1,22 @@
+# 架構可行性檢查
+
+問的是「這件事該不該在這裡做、做了會不會把結構弄壞」。
+
+每一條都要對著需求議題的內容回答，回答不出來就是一個要問使用者的問題。
+
+## 檢查項
+
+1. **落點** — 這個需求該由哪一個 repo 承接？若需求議題的「影響範圍」列了多個 repo，
+   哪一個是主要落點、其餘各自要改什麼？
+2. **放錯地方的徵兆** — 若照目前的落點做，是否需要把原本屬於別處的知識搬進來？
+   需不需要讀別的 repo 的資料表或內部模組？
+3. **相依方向** — 新增的相依是誰依賴誰？會不會造成循環相依（A 依賴 B，B 又回頭依賴 A）？
+4. **既有邊界** — 這次改動會不會穿過既有的分層或模組邊界？若會，是邊界本來就畫錯，
+   還是這次該繞過？
+5. **對外介面** — 會不會改變既有的對外介面？既有呼叫端有誰、要不要同時改？
+6. **可回復性** — 做錯了要怎麼退回？是可以直接 revert，還是會留下已遷移的資料或已發布的介面？
+
+## 問題怎麼問
+
+每一條檢查若在議題裡找不到答案，就轉成一個問題。問題要具體到能用一句話回答，
+不要問「架構上有什麼考量嗎」這種無法收斂的問法。