角色與安全
FortressFlag 內建四種角色和一組正式環境保護，全部圍繞一個想法設計：在非正式環境快速行動應該毫不費力，而變更正式環境應該需要正確的角色，或者第二個人。
| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| 查看 flag 與團隊 | ✓ | ✓ | ✓ | ✓ |
| 變更非正式環境 | ✓ | ✓ | ✓ | |
| 提議與核准正式環境變更 | ✓ | ✓ | ✓ | |
| 直接變更正式環境 | ✓ | ✓ | ||
| 檢視 SDK 金鑰 | ✓ | ✓ | ✓ | |
| 鑄造與撤銷 SDK 金鑰 | ✓ | ✓ | ||
| 管理團隊、專案與環境 | ✓ | ✓ | ||
| 讀取與匯出稽核紀錄 | ✓ | ✓ | ||
| 帳務、用量與組織政策 | ✓ |
幾件表格裝不下的事：
- Viewer 和 Developer 只看得到被授予的專案。
- 沒有人能授予高於自己的角色。Admin 可以邀請 Developer，不能邀請 Owner。
- 完整的矩陣就發布在應用程式內，所以你在儀表板看到的，永遠反映伺服器實際強制執行的內容。
正式環境變更：第二雙眼睛
Section titled “正式環境變更：第二雙眼睛”Developer 不能直接寫入正式環境類別的環境，但他們也不必等 Admin。Developer 提議一項變更（一次切換、一次規則編輯），然後任何第二個人（另一位 Developer 或以上）審核並核准它，核准就等於套用。
這個形狀是刻意的，作為買家值得理解：
- 這是同儕審核，不是階層審核。兩位 Developer 一起就能變更正式環境。重點是，Admin 以下沒有任何單一個人能獨自變更它。
- 自己核准自己一律拒絕，依人而不是依角色。即使是 Admin 也不能核准自己的提案。
- 稽核紀錄會記下雙方，在每一個已套用的提案上：誰提議、誰核准。
Admin 和 Owner 仍然可以直接寫入正式環境；提案途徑的存在，是為了讓團隊其他人有一條安全的路進去。
布林 flag 的狀態可以排程：星期五 09:00 UTC 把 holiday-banner 開啟。變更會在你選定的時間對每一個讀取者準時生效，而排程一個環境需要的權限和現在寫入它的權限相同：排程只是一次帶時間戳的寫入，受到同樣的標準約束。
每一次狀態變更都會落進一份只能追加的稽核紀錄：誰、什麼、何時、從哪裡，以及變更前後的值。Admin 和 Owner 可以在應用程式內用篩選條件瀏覽它，並匯出成 CSV，用於事故檢討、合規要求或稽核人員。逐步說明見匯出稽核紀錄。
- 要求正式環境變更經過核准：這個流程，一步一步來
- 排程一項變更：把切換設定在稍後
- 邀請你的團隊：角色在邀請時指派