軟體開發實務

良好的軟體開發生命週期（software development lifecycle, SDLC）是一段持續不斷的歷程，但若不知道前進方向，就很難取得進展。本文件提供一份檢查清單，讓 ROOST 專案在逐步成熟的過程中逐項落實。

文件狀態： 工作草案。以下類別、檢查項目與優先順序皆為建議。

品質願景

項目	說明／備註	優先順序
意圖聲明	說明我們要為誰打造什麼樣的軟體，以及所依循的理念。	P0

版本管理

項目	說明／備註	優先順序
版本管理	ROOST 專案使用語意化版本（Semantic Versioning）。	P1
分支	起步階段，ROOST 專案應以 `main` 作為開發分支，並透過 GitHub Release 功能，以帶有語意化版本標籤的 commit 標示發行版本。專案成熟並需要回移修補程式時，應重新檢視此做法，但整體理念仍是「最低可行複雜度」。	P0

發行節奏

項目	說明／備註	優先順序
初始流程	* 以 12 個月為期程辨識大型功能。這些是重大變更，可想成足以成為部落格文章標題的項目。 * 以季度估算大型功能的交付時間，將時程相近的功能分組。可行時，將破壞性變更集中處理。 * 將次要功能與變更加入時程，盡量組成一致的發行節奏。 * 修補版本可依錯誤修正需求隨時發行。	P0

專案慣例

項目	說明／備註	優先順序
README.md	所有專案與 repository 都必須有 Markdown 格式的 README。README 至少要說明專案用途、如何開始使用（可連結至較完整的入門文件），並連結至 CONTRIBUTING.md 與行為準則。	P0
AGENTS.md	依照開放的 AGENTS.md 格式，加入一份用來引導 AI 程式開發助手的 Markdown 文件。詳細作法見 ROOST AGENTS.md 實務。	P1
API 格式	專案應遵循 ROOST API 規格實務。	P1
CHANGELOG.md	專案必須有 CHANGELOG.md，並採用 Keep a Changelog 格式。	P0
貢獻者指引	所有專案至少必須有 CONTRIBUTING.md。預設會繼承 ROOST `.github` repository 中的版本，也可在個別專案層級更新。建議另提供首次貢獻者文件，說明專案慣例與程式碼品質要求。	P0
CODE_OF_CONDUCT.md	所有專案必須有包含 ROOST 行為準則的 CODE_OF_CONDUCT.md。此檔案會自動繼承自 ROOST 的 `.github` repository，不應修改。	P0

測試實務

項目	說明／備註	優先順序
所有 commit 的測試	1）單元測試 2）lint 檢查 3）整合測試 4）建置檢查	P0
發行測試	主要版本與次要版本發行時執行端對端測試。	P0
CI 檢查	確認專案所需的 CI 檢查，並強制所有 CI 檢查皆須通過。	P0

相依套件處理

項目	說明／備註	優先順序
版本提醒	建立自動提醒與更新相依套件的流程。	P0
漏洞提醒	建立自動提醒與更新有漏洞相依套件的流程。	P0
授權掃描	透過 CI 確認新增相依套件的授權相容。	P1
內含相依套件政策	是否會把相依套件原始碼納入專案（vendoring）？	P2

安全

安全事件應變流程與安全更新的詳細說明，請見獨立的安全頁面。

CI/CD

項目	說明／備註	優先順序
模糊測試	確認哪些介面或介面特性應執行模糊測試及其頻率，並規劃相同節奏的分類與修補流程。	P2
程式碼分析	CodeQL、secret 與 token 掃描等。	P1
二進位成品偵測	標記被納入版本控制的二進位檔。	P2
commit 階段漏洞偵測	標記具有已知 CVE 的套件。	P2

發行

項目	說明／備註	優先順序
簽署發行版本		P3
安全問題報告受理	見安全。	P0
事件應變流程	見安全。	P1

PR 分類與程式碼審查

項目	說明／備註	優先順序
Issue 標籤	如何自動化，或降低維護負擔？	P2
PR 標籤	如何自動化、降低維護負擔，並辨識優先順序？	P2
程式碼審查指引	專案文件應說明如何協助程式碼審查，並標示審查者應特別留意的領域。	P1

支援

項目	說明／備註	優先順序
破壞性變更政策	依照語意化版本，破壞性變更會放在主要版本。此政策說明何時適合引入破壞性變更，以及如何向使用者溝通時程、預期與支援方式。	P1
長期支援（LTS）政策	社群會向前支援幾個版本？	P3，稍後處理

淘汰

項目	說明／備註	優先順序
淘汰流程		P3，需要時處理