本模組各章的作法——判斷標準與實作分開產出、維度交叉盤點、性質式測試、突變測試——成本差很多。這一篇是授權的降級版本，所以進出都要留下痕跡：用它之前寫下哪一項前置不成立（沒有 CI、團隊人數、該語言沒有工具），用它之後訂一個回看的時點或訊號。少了這兩件，「資源很少」會變成不必再檢查的長期狀態。

前置成立時照這個順序取用：

1. 判斷標準與實作分開產出——開兩個會話、寫測試那一次不餵程式碼。工具層的成本接近零，真正的成本落在需求描述必須自足；擋掉的是最大宗的那一類失效。
2. 維度表先攤前四個維度（狀態、事件、順序、邊界），這四個靠產品知識就推得出來。併發與失敗需要系統經驗，但不要整個跳過——需求已經明寫的（例如「付款失敗要回滾」）照補，其餘降級成「這個交叉發生時使用者該觀察到什麼」的陳述，實際的競態驗證留給整合層。
3. 性質式測試挑兩類：往返與冪等。這兩類最好認、也最常在小系統裡成立。
4. 突變測試整章暫緩。它的兩個硬前置（確定性套件、可用的語言工具）加上一個成本條件（CI 時間預算）通常一個都不成立，強行導入會卡在第零步。暫緩要記進模組的 backlog 並寫明是哪一個前置擋住——回補的訊號跟著那一項走（隔離清單清空、CI 時間預算鬆動、該語言出現生產可用的實作），沒有訊號的暫緩會變成永久豁免。

反過來說，人手充足而決定權不在自己手上時，順序完全不同——先看判斷標準的推導來源那一章的產出、組織、契約與監理主體表，確認要動的是哪一層。