ランディング：追加ソフトウェア
アーキテクチャの決定はプロジェクトオーナーの責任です。ルールの文言に違反することは精神に違反することです。
鉄の掟
スタック、ネットワーク、共有リソースに関するいかなる決定も、
事前に確認なしに行ってはなりません。高リスクフェーズ：フェリペのコマンド経由でのみ承認。
最初のアクション： node check-gate.js --cliente <名前> --antes-de software-extra を実行；01 と plano.md を読む；予約がある場合は references/agendamento.md を読む。
ゲート機能
- 未決定の事項（スタック、データベース、実行場所、共有リソース、メール、通知、バックアップ）をリストアップします。
- それぞれについて：選択肢、理由付きの推奨事項、間違えた場合のコストを提示します。質問してください。選択はしません。
03-decisoes.mdに記録します（D）。グローバルルールに違反する場合は、フェリペの承認を得てoverride: R-nnnを記録します。- フェリペが
! 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に設定します；チャットを通過したものは交換を推奨します。 - 時間、サービス、価格は1つのソース（データベース）から取得します；静的HTMLは予備としてのみ使用します。
- オプション名と所要時間は異なるフィールドです；画面は明示的なルールに従って表示内容を決定します。
- 内部画面は
landing-direcao-visualとfrontend-designを経由します；追加にはモックアップと項目ごとの確認が必要です。 - 本番環境：事前にバックアップ、リロード前に
nginx -t、ダウンタイムを発生させないウィンドウ、ロールバック手順を文書化します。root権限が必要なものは、フェリペに渡す1行コマンドにします。
危険信号：停止
- 「それが最善だから」という理由でデータベースを選ぶ ·
apiという名前を再利用する · バックアップなしでデプロイ - 自分自身で実行するであろう5000行の計画をサーバー上で繰り返す
- 隣人をテストせずに「ここでは動いた」と言う
| 都合の良い解釈 | 現実 |
|---|---|
| 「選択は明らかだ」 | フェリペがコードを見て驚くなら？それなら質問せよ |
| 「短い名前の方がすっきりする」 | edge ネットワーク内の api が隣人を502でダウンさせた |
| 「承認はランディング用だった」 | あるコンテキストでの承認は別のコンテキストでは無効 |