Landing: 額外軟體
架構決策由專案擁有者主導。違反文字就是違反精神。
鐵律
未經事先詢問，不得做出任何關於技術棧、網路或共享資源的決策。
高風險階段：僅接受 Felipe 指令的批准。
首要動作： node check-gate.js --cliente <名稱> --antes-de software-extra；讀取 01 和 plano.md；如果涉及預訂，讀取 references/agendamento.md。
關卡函數
- 列出所有待決策項目（技術棧、資料庫、運行位置、共享資源、電子郵件、通知、備份）。
- 針對每一項：列出選項、附帶原因的建議、錯誤的成本。提問，不要自己選擇。
- 記錄在
03-decisoes.md（格式 D）。如果違反了全域規則，則記錄override: R-nnn並需 Felipe 批准。 - Felipe 執行
! node approve.js --file <03> --fase software-extra --via comando。僅在此之後才開始實作。 - 採用 TDD 實作。完成後由獨立審查者審查。
- 部署後：檢查隔壁系統的真實路徑（例如：
GET /api/health）以及docker logs <proxy> --since 2m | grep -c "502|refused"。
固定規則
- 專案前綴用於所有服務、容器和共享網路別名（
agenda-api、agenda-db）。在加入網路前，列出隔壁系統能解析的名稱（set $api、upstream、proxy_pass）。 - 密碼僅存於伺服器上的
.env檔案，權限設為 600；經由聊天傳遞的密碼建議更換。 - 時間、服務和價格來自單一來源（資料庫）；靜態 HTML 僅作為備用。
- 選項名稱和持續時間是不同的欄位；畫面根據明確規則決定顯示內容。
- 內部畫面需經過
landing-direcao-visual和frontend-design；新增時需有 Mockup 並逐項確認。 - 生產環境：先備份、重載前執行
nginx -t、不造成服務中斷的維護時段、撰寫復原指令。需要 root 權限的操作會整理成一行指令給 Felipe。
紅旗：立即停止
- 因為「它最好」而選擇資料庫 · 重複使用
api這個名稱 · 沒有備份就部署 - 在伺服器上重複一個自己都無法執行的 5,000 行計畫
- 未測試隔壁系統就說「在我這裡可以運行」
| 合理化理由 | 現實狀況 |
|---|---|
| 「這個選擇很明顯」 | 如果 Felipe 是從程式碼才發現，他會驚訝嗎？如果會，就該問 |
| 「短名稱看起來更乾淨」 | 在 edge 網路中的 api 導致隔壁系統出現 502 錯誤 |
| 「批准是給 landing 頁面的」 | 某個情境下的批准不適用於另一個情境 |