我在開始實作前會先寫下什麼

程式碼會讓一個想法看起來比實際更確定。開始實作前，我會先寫下幾個仍然可能改變專案形狀的問題。

使用者與重複發生的工作

我會先寫下一種人，以及他會重複做的一件事。「給開發者使用的工具」太寬。「找出是哪個 component 造成緩慢 render 的工具」才具體到可以測試。

這件工作也會決定產品邊界。如果 shell command 或瀏覽器內建功能已經能完成它，新產品就需要更好的存在理由。

唯一的資料來源

每個重要資料都需要一個擁有者。Cache 可以保留副本，但不能在沒有明確決策的情況下成為權威版本。設定、UI state 與 generated files 也適用同一個原則。

當兩個系統看起來都擁有同一個值時，我會先寫下 retry、部分失敗，或舊 client 重新連線之後，哪一邊才是最後結果。

會改變設計的失敗

有些失敗只需要錯誤訊息，有些失敗會改變架構。

如果一次寫入失敗可能造成金錢損失、資料損壞，或讓相同的外部操作執行兩次，這個 operation 就需要 durable identity 與安全的 retry path。這項決定應該在一開始處理，而不是留到清理階段。

這一版刻意不做什麼

簡短的排除清單很有用。它可以避免一個小工具在核心工作還沒成立前，就開始累積帳號、dashboard、plugins 與 collaboration features。

這份清單不是永久承諾。它只記錄目前這一版不需要證明的事情。