# 統帥插入需求主線優先序台帳

> 建立時間：2026-07-02 13:04 CST
> 範圍：本輪 AWOOOI / Gitea / Product Governance 工作中，使用者在主線推進期間插入的要求。
> 目的：把插入要求轉成可排序、可驗證、可接續的工作項目，避免後續 Codex 把它們當成聊天雜訊或另開支線。

## 判讀規則

1. 「批准」、「繼續」、「只推進目前唯一目標」、「不要偏離」全部解讀為：沿目前 P0 主線往下一個可驗證工作項推進，不開 GitHub、不開新產品支線、不做未授權高風險操作。
2. 「我要看到實作結果」解讀為：每個主線工作項必須產出至少一種 evidence，優先順序為 commit / Gitea run / production readback / runner readback / queue readback / verifier output。
3. 「全面授權」只打開非事故級 controlled apply。secret 明文、raw session / SQLite、force push、repo / refs 破壞、reboot、node drain、destructive DB、Docker daemon restart、外部攻擊型 scan、付費 provider 切換仍維持 break-glass。
4. 使用者曾在聊天中貼入敏感值。台帳只記「敏感值已出現」這個事實，不記錄、不重印、不保存任何 token、密碼或 key。
5. GitHub account safety freeze 維持有效。GitHub 相關需求不刪除，轉為「停用狀態下的治理記錄與未來風險評估」，不得直接執行 GitHub / gh / GitHub API / GitHub Actions。

## 優先序定義

| 優先序 | 定義 | 可做 | 不可做 |
| --- | --- | --- | --- |
| P0 | 會直接影響 Gitea source truth、推版能力、repo identity、secret safety、runner / CD 連續性的事項 | 受控修正、正常 push、CD readback、runner metadata verifier、LOGBOOK / PlayBook / KM 記錄 | force push、repo / refs 破壞、讀 secret、重啟 Docker / host、GitHub 操作 |
| P1 | 會影響跨產品治理、工作排序、內部 KM / PlayBook / RAG / MCP / log 整合的事項 | 文件 / snapshot / API / UI read model、controlled apply packet、verifier / rollback 補齊 | 宣稱已完成 runtime closure、跳過 verifier |
| P2 | 會影響後續效率或觀測品質，但不阻擋當前推版主線的事項 | 優化 queue readback、SignOz / observability 分流、報表整理 | 把 P2 當成 P0 攔路 |
| P3 | 等外部狀態改變後才可恢復的事項 | 風險評估、未來恢復條件草案 | 在 freeze 期間嘗試外部操作 |

## 主線工作項目

| 順序 | ID | 優先序 | 使用者插入要求 | 正規化工作項 | 目前狀態 | 下一個可驗證動作 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | CIR-P0-001 | P0 | 「不要偏離」、「只推進目前唯一目標」、「照順序推進」 | 建立單一主線執行規則：任何插入需求都先歸入本台帳，再依 P0/P1/P2/P3 排序 | 已建立本台帳 | 後續每次回報引用 current P0 / action / evidence / next action |
| 2 | CIR-P0-002 | P0 | 「我要看到實作結果」 | 主線工作必須回報 commit、Gitea CD run、production readback 或 verifier output；不能只回覆規劃 | 已落地：建立時基準 CD `#4373` Success，deploy marker `ab748b1a` | 新變更也必須正常 push、CD readback、必要時 production readback |
| 3 | CIR-P0-003 | P0 | 「GitHub 我已申訴了，你先做其他工作」 | GitHub freeze 下，所有 GitHub 需求暫停執行，工作轉回 Gitea / local / production truth | GitHub 停用有效 | 只維持 stopped / do_not_use 記錄；未來若要恢復，先出風險評估 |
| 4 | CIR-P0-004 | P0 | 「為什麼還沒把全部專案推上 GitHub」 | 不執行 GitHub 推送；改成全產品 Gitea repo identity、backup health、source-control readiness 台帳 | Gitea 9 expected repos 已回讀 OK；GitHub 不做 | 把全產品 source truth 優先對齊 Gitea / Gitea SSH / backup health |
| 5 | CIR-P0-005 | P0 | 「你做了什麼讓帳號 suspended」 | 建立 account safety 事故邊界：不再碰 GitHub，避免任何 read-only / write 操作造成二次風險 | GitHub freeze 已在規則中 | 不要求 token、不讀 suspension 細節、不碰 GitHub API |
| 6 | CIR-P0-006 | P0 | 使用者貼入 runner token / 密碼類敏感值，並說「授權你直接操作」 | 敏感值不入檔、不重印、不保存；runner registration 只允許互動 hidden prompt 或 metadata verifier；已出現的敏感值後續應視為需輪替 / 廢止評估 | 已遵守：未保存 token，registration script token-safe | 建立 secret exposure follow-up，不含任何明文值；需要時只列 rotate / revoke checklist |
| 7 | CIR-P0-007 | P0 | 「我沒辦法複製貼上 token」 | Runner 註冊流程要支援使用者在遠端 TTY hidden prompt 輸入，不要求把 token 貼給 Codex | 已完成 source：`register-awoooi-110-controlled-cd-lane-drain.sh` token-safe | live 110 lane 仍需 staging artifacts / registration metadata，不能讀 `.runner` 內容 |
| 8 | CIR-P0-008 | P0 | 「Gitea 恢復正常」、「所有專案儲存庫恢復」、「原本儲存庫不是新增」 | 儲存庫恢復以原 Gitea repo identity / SSH heads / backup health 為準，不建立替代 repo 來假裝恢復 | 已有 handoff truth：9 expected repos SSH heads OK、backup health missing=0 | 若再出現 404，先判斷 private visibility / auth，不宣稱 history 消失 |
| 9 | CIR-P0-009 | P0 | 「所有專案都沒辦法推版」 | 先保 AWOOOI Gitea CD 主線 green，再逐產品恢復 dev/prod CI baseline；不能把 GitHub 當解法 | 建立時基準 AWOOOI CD `#4373` Success；後續需以 Gitea queue / deploy marker readback 刷新 | 下一步按 product governance matrix 推 Gitea-only baseline |
| 10 | CIR-P0-010 | P0 | 「趕快修復 Gitea」、「不要開 legacy runner」相關壓力事故 | 188 non-110 runner 為主 CD lane；110 legacy / generic runner 維持 fail-closed；110 drain lane 只在 guardrails 全綠時 controlled enable | 188 ready；110 live verifier 仍顯示 config / registration / staging blockers | 補 110 drain staging artifacts 後只跑 readiness verifier，不直接開服務 |
| 11 | CIR-P0-011 | P0 | 「所有已開始、進行中、已完成工作全部看清楚」 | 工作狀態必須拆成 Done / In Progress / Blocked / Next，不再用單句「差不多完成」 | 本台帳補齊主線插入需求 | 後續 LOGBOOK 每次新增狀態要帶 status 與 evidence |
| 12 | CIR-P0-012 | P0 | 「所有主線工作持續推進」 | 主線推進順序固定：Gitea source truth → CD / runner → production readback → product governance → KM / PlayBook / RAG integration | 正在執行 | 不因支線問題改做 GitHub、Wazuh、host reboot 或未授權 console |
| 13 | CIR-P0-013 | P0 | 「這些安全硬閘哪裡來的」、「全部打開」 | 建立 gate taxonomy：非事故 gate 轉 evidence / ledger；事故 gate 保留 break-glass | 規則已整理於本台帳 | 後續 UI / API 需顯示 gate source、可自動處理方式、不可越線項 |
| 14 | CIR-P0-014 | P0 | 「批准/繼續會不會讓你誤會」 | 將簡短批准語句解讀規則文件化：批准等於沿目前排序繼續，不等於開新支線或解除事故級 hard gate | 已建立判讀規則 | 後續回覆避免把批准解讀成 GitHub、secret、force push 授權 |
| 15 | CIR-P0-015 | P0 | 「為什麼搞成這麼亂」 | 收斂亂象來源：多視窗、長上下文、重複 gate、GitHub freeze、Gitea recovery、runner pressure 必須進同一台帳 | 本台帳為收斂入口 | 新任務先看本台帳與 LOGBOOK，不再靠散落聊天句子 |
| 16 | CIR-P1-001 | P1 | 「為什麼沒有整合到 MCP、RAG、KM、PLAYBOOK、LOG」 | 內部治理資料要沉澱到 KM / PlayBook / RAG / MCP / log，而不是只存在對話 | 待實作 | 定義 `work_item_id`、evidence source、verifier、rollback、trust writeback 欄位 |
| 17 | CIR-P1-002 | P1 | 「所有工作的優先順序你都不知道嗎」 | 建立跨產品 priority matrix，區分 AWOOOI P0、Gitea/source-control P0、product governance P1、UI/UX P2 | 部分已有 scorecard；本台帳補 current thread | 將本台帳映射到 existing product runtime governance dashboard |
| 18 | CIR-P1-003 | P1 | 「所有儲存庫都不重要？」 | repo identity / backup health / private visibility 要成為 product governance 第一層，不再只看單一 AWOOOI repo | Gitea P0 恢復 truth 已有 9 repos OK | 補全產品 source-control readback rows，標示 canonical repo / branch / backup evidence |
| 19 | CIR-P1-004 | P1 | 「是你打開瀏覽器連 Gitea 嗎，需要 token 嗎」 | Gitea 操作要區分 public HTML readback、API token readback、SSH git readback、runner token registration | 已區分：public HTML 可讀；API 未登入 401；SSH push 可用 | 建立 runbook：何時需要 token、何時不需要、不得要求貼 token |
| 20 | CIR-P1-005 | P1 | 「用 VMware Console 去 192.168.0.99 操作 110」 | VMware console 是 break-glass / local console lane，只能在 SSH/Gitea control path 無法修復且有明確目標時使用 | 未作為本輪主線執行 | 若需要，先列 non-secret console checklist，不輸入或保存密碼 |
| 21 | CIR-P1-006 | P1 | 「sudo 為什麼不能用密碼」 | sudo / account / SSH auth 行為只做 metadata audit，不要求或記錄密碼；若需修復，用 authorized console SOP | 未在本輪 runtime 修改 | 補一份 sudo / auth metadata check playbook，禁止收密碼 |
| 22 | CIR-P1-007 | P1 | 「先做其他工作」 | GitHub blocked 時不得原地等待，改推 Gitea / CD / product governance / backup / KM mainline | 已照做：Gitea CD 已 success | 下個 P0 仍照排序，不等待 GitHub appeal |
| 23 | CIR-P2-001 | P2 | 「為什麼會偏離工作目標」 | 將每輪回報固定成 current P0 / action taken / evidence / next action | 待持續執行 | final / handoff 必須先列結果，再列下一步 |
| 24 | CIR-P2-002 | P2 | production health readback 顯示 degraded | SignOz component down 不阻擋本次 CD success，但要分流到 observability lane | 已觀察到 `signoz` connection refused | 排入 Observability P2，不在本輪重啟服務 |
| 25 | CIR-P3-001 | P3 | GitHub appeal 後的未來恢復 | 只有使用者未來明確要求恢復 GitHub，才先做風險評估與人工確認 | 等外部狀態 | 未確認前維持 freeze |

## 2026-07-02 全主機重啟後插入需求補全

> 本節補登使用者在全主機重啟、Gitea repository、110/188 CPU 壓力與 SLA 責任追問期間插入的明確要求。這些需求不得再被視為對話噪音；後續所有工作視窗必須先查本節，再按排序推進。

| 順序 | ID | 優先序 | 使用者插入要求 | 正規化工作項 | 目前狀態 | 下一個可驗證動作 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | CIR-P0-RBT-001 | P0 | 「主機重啟後 10 分鐘內全部恢復，且要自動判斷所有主機被重啟」 | 建立 99/110/111/112/120/121/188 reboot event detector + 10 分鐘 SLO scorecard + fixed triage order | 2026-07-02 18:28 live scorecard 已更新：readiness `43%`、active blockers `11`；`windows99_verify_collection`、`windows99_management_channel` 與 `windows99_local_console_channel_reachable` 已進 API / scorecard；仍缺 fresh all-host 10 分鐘證明，111 不可達，99 uptime / VMware verifier 未閉環 | 優先收斂 99 local console Verify output / no-secret management channel 與 111 reachability；不可宣稱 10 分鐘 SLA 已證明 |
| 2 | CIR-P0-RBT-002 | P0 | 「沒有偵測到主機重啟」 | 修正 host reboot/shutdown/up detection：boot_id / uptime / node exporter / Windows exporter / VMware VM power state 都要進同一事件 | Scorecard 已接 collection packet + management probe；99 host reachable 但 uptime unknown，111 unreachable，stale hosts 仍存在 | 讓 99 verifier / Windows exporter 或等效 no-secret readback 進入 host boot event，並補 111 reachability 證據 |
| 3 | CIR-P0-RBT-003 | P0 | 「192.168.0.99 VMWare 要自動啟動，裡面 111/188/120/121/112 也自動啟動」 | Windows 99 VMware host autostart + guest VM autostart contract；VM host 111/188/120/121/112 開機順序與 readback | Source verifier / parser / API readback / collection packet 已完成；management probe 讀回 `host_reachable=true`、RDP open、`2179` VMConnect / console channel open、SSH BatchMode `permission_denied`、WinRM timeout；snapshot active blockers=`windows99_remote_execution_channel_unavailable`、`windows99_vmware_autostart_readback_missing` | 收集 local console Verify output 或恢復 no-secret management channel，再確認 `VMRUN_PRESENT`、scheduled task、VMware services、VM power、VMX present 全綠 |
| 4 | CIR-P0-RBT-004 | P0 | 「192.168.0.99 不可因 Windows Update 無預警重開」 | Windows Update reboot policy：active hours / no auto-restart / maintenance window / update notification audit | Source verifier 已補 `WINDOWS_UPDATE_POLICY` 與 `WINDOWS_UPDATE_NO_AUTO_REBOOT_READY`；collection packet 已列 forbidden actions；99 management channel 尚不能收 policy readback | 取得 Verify output；若 policy 不綠，再走 controlled apply，禁止要求或記錄 Windows 密碼 |
| 5 | CIR-P0-RBT-005 | P0 | 「網站重啟後 502 嚴重影響體驗，要維護頁，外部雲端或專業做法」 | Public maintenance fallback：Nginx / edge / external static maintenance page / status page / fail-open UX，避免 502 直出 | Source + runtime verifier 已實作；Gitea CD `#4459` Success、deploy marker `8d7a6faaf`，production API scorecard 已讀回 `public_maintenance_fallback.ready=true`、raw 5xx=`0`、unreachable without L1=`0`，P0 blockers `11`、readiness `47`；仍不可宣稱整體 10 分鐘 SLO 完成 | 若未來 public route 出現 raw 5xx，先走 L0 Nginx intercept / header verifier；若 edge unreachable，才產生 L1 external static origin / CDN decision record + rollback |
| 6 | CIR-P0-RBT-006 | P0 | 「所有主機關機立刻 Telegram 告警，重啟後也要告警，其他告警一併完整思考」 | Down / shutdown suspected / reboot detected / reboot recovered / SLO missed / backup failed / freshness stale / CPU pressure / Gitea queue 告警矩陣 | HostDown / HostRebootEventDetected / RebootAutoRecoverySLOMissed 已存在；本輪補 `awoooi_reboot_auto_recovery_slo_active_blocker{blocker=...}`、`RebootAutoRecoveryActiveBlocker` 與 metric-missing guard，避免只看到總 SLO 告警；仍需完整 shutdown/up E2E receipt | 部署 alert rules 後讀回 Prometheus / Alertmanager active/resolved 與 outbound receipt；不送測試 secret，不重啟主機 |
| 7 | CIR-P0-RBT-007 | P0 | 「所有備份包含主機、DB、網站、服務、套件、工具、日誌都沒有監控告警」 | Backup observability coverage：backup job inventory、last success、freshness、offsite、restore drill、Telegram receipt | 部分已有 backup health exporter / alert rules；全域 coverage 與 restore drill 未全綠 | 建立 backup coverage matrix：host / DB / website / service config / package list / tool scripts / logs，每列有 metric、alert、last_success、restore_verifier |
| 8 | CIR-P0-RBT-008 | P0 | 「每次重啟排查都不一樣，也不知道多久恢復，不符合 SLA」 | 固定化 reboot runbook：fixed triage order、ETA、active blocker、remaining seconds、owner lane、next command | Production scorecard readback 已固定 `status=blocked_reboot_auto_recovery_slo_not_ready`、readiness `47%`、active blockers `11`；本輪再補 per-blocker Prometheus metric / Telegram alert 投影，避免只剩總 blocker_count；`next_safe_action=restore_windows99_no_secret_management_channel_or_collect_local_console_verify_readback_then_rerun_reboot_scorecard_no_reboot` | 優先收斂 99 no-secret Verify / 111 reachability / backup_core / service_green / Wazuh degraded；不得用不同排查路徑繞過 scorecard |
| 9 | CIR-P0-RBT-009 | P0 | 「所有產品、網站都要是最新版本；版本和數據是否最新要驗證」 | Product freshness/version matrix：source commit、deploy marker、runtime image、public health、data freshness、latest source availability | AWOOOI Gitea main 已到 deploy marker `c68b74686`，production source readback `5d5bc86fed` verified；StockPlatform public freshness / ingestion 讀回 `ok`，latest trading date `2026-07-02`，core price/chips/margin/AI recommendations 都是 `2026-07-02` | 建立全產品 readback 表：product、canonical repo、main SHA、deploy marker、public URL、data freshness、blocked reason |
| 10 | CIR-P0-GIT-001 | P0 | 「Gitea 儲存庫都不見了？Gitea 沒完整備份嗎？」 | Gitea repository identity + backup proof + restore drill：不能只看 UI visible，要比對 SSH heads、repo path、bundle backup、restore sample | 2026-07-02 production `/api/v1/agents/gitea-repo-bundle-backup-readback` 已 ready：9 expected repos present/ok、missing=0、failed=0、checksum_missing=0、bundle_fresh=true、all_expected_ok=true、sample_restore_dry_run_ok=true；repo bundle / restore dry-run 層已關閉，不是 repo missing。 | 維持每日 bundle backup + restore dry-run monitoring；另補 Gitea full dump / DB / settings / issues / packages / LFS 備份 readback。禁止刪 repo / 改 visibility / 讀 token / restore 到 production |
| 11 | CIR-P0-CPU-001 | P0 | 「110 / 188 CPU 負載持續過高，為什麼沒監控告警、沒主動修復」 | Sustained CPU pressure automation：Alertmanager → controller → evidence → service playbook → verifier → KM writeback | 110 已有 `Host110SustainedModeratePressure`、Gitea playbook、Stock/Postgres evidence；188 仍需同級 controller/alerts readback | 下一步接 `postgres_hot_query_or_backup_export_playbook`；並補 188 equivalent readback，不以單次下降結案 |
| 12 | CIR-P0-CPU-002 | P0 | 「噪音會影響真問題，要整合一起做」 | Alert noise / real issue correlation：backup aggregate noise、CPU pressure、Gitea queue、Stock freshness 要分清主因與次因 | 部分已在 SOP 註記；仍需統一 correlation scorecard | 建立 incident correlation readback：primary_blocker、secondary_noise、ignored_noise_reason、evidence_ref |
| 13 | CIR-P0-CD-001 | P0 | 「所有專案都不能推版 / 要看到實作結果」 | Gitea-only CD baseline：每次 main push 要有 visible run、deploy marker、production readback；GitHub 不作解法 | AWOOOI 最新 main 可推，CD success/deploy marker 已多次證明；全產品未全綠 | 將 product governance matrix 接入各產品 Gitea CD readiness，不再只報 AWOOOI |
| 14 | CIR-P1-AI-001 | P1 | 「AI 專業在哪？要能主動發現、主動修復」 | AI controlled repair loop：detect → classify → candidate → check-mode → controlled apply → post verifier → KM / PlayBook trust | CPU / Gitea / Telegram receipt 已部分落地；全域 AI loop 未全部接上 | 將每個 P0 runbook 補 `candidate_action`、`controlled_apply_allowed`、`post_verifier`、`trust_writeback` |
| 15 | CIR-P1-KM-001 | P1 | 「修復過程、經驗完整沉澱進 SOP，整合到目前版本」 | 所有 P0 修復必須同步 LOGBOOK、SOP、PlayBook、workplan ledger；不能只留在對話 | 本台帳、LOGBOOK、SOP 已開始補；仍需 API/UI read model | 把本台帳轉成 read-only API / governance UI row，並建立 `last_updated` / `evidence_count` |
| 16 | CIR-P1-WORK-001 | P1 | 「所有已開始、進行中、已完成工作全部看清楚」 | 工作狀態盤點：Done / In Progress / Blocked / Deferred / Next Action + evidence | 本台帳已有初版 Done/In Progress/Blocked；需納入本節新 P0 | 更新下方 Done/In Progress/Blocked，把 reboot/backup/VMware/maintenance/CPU 全列入 |
| 17 | CIR-P1-OPENCLAW-001 | P1 | 「OpenClaw 要有像 Gather Town 的工作畫面，而且是持續動畫」 | OpenClaw Live Ops Space：animated room、agent avatars、flow packets、work tokens、scene-state API、desktop/mobile smoke | `/zh-TW/openclaw/live-ops-space` route 已存在；仍需 production desktop/mobile animation smoke 與 AwoooP 導流 | 跑 OpenClaw live-ops desktop/mobile smoke，補 AwoooP 導流與截圖證據 |
| 18 | CIR-P2-OBS-001 | P2 | 「其他還有哪些告警也要完整思考」 | Observability coverage expansion：SignOz/Sentry/Langfuse/Harbor/Registry/K3s/DB/backup/freshness/route/TLS 告警 | 多數 rule 分散存在；coverage matrix 不完整 | 建立 alert coverage matrix，區分 P0 actionable 與 P2 observability debt |
| 19 | CIR-P2-UX-001 | P2 | 「維護頁外部雲端或其他專業做法評估」 | Maintenance UX 可先做設計 / decision record；實際 DNS/edge cutover 需 controlled apply | 尚未開始 | 先出 no-write design / rollback / smoke verifier，不直接切 DNS |
| 20 | CIR-P2-UX-002 | P2 | 「不要又是一大堆文字頁 / 文字牆，要像主流網站與專業 AI 產品」 | AI professional UI：first-viewport cockpit、metrics/cards/flow rows、expandable technical detail、desktop/mobile screenshot smoke | AwoooP 已有插入需求工作項面板；仍需把長文區塊持續收斂成可掃描 cockpit | 針對 AwoooP / governance / OpenClaw live ops 做 visual smoke 與長文字區塊收斂 |

## 2026-07-02 AI Loop Agent / 全域 LOG / IA / UI 插入需求補全

> 本節補登使用者在 AI 自動化、所有 LOG 收攏、Telegram 告警、MCP / RAG / KM / PlayBook、IwoooS / 導航移除與 UI/UX 追問期間插入的明確要求。這些項目已同步到 `awoooi-priority-work-order-readback` API 與 `/zh-TW/awooop/work-items` spotlight，不得只停在 Markdown。

| 順序 | ID | 優先序 | 使用者插入要求 | 正規化工作項 | 目前狀態 | 下一個可驗證動作 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | CIR-P0-AILOOP-001 | P0 | 「你現在有在往 AI Loop Agent 這個方向目標前進嗎？」 | AI Loop Agent 北極星成為所有告警、工作項、Run、LOG 與前台主線：Sensor → Normalizer → AI Lane → Candidate → Gate → Execution Boundary → Verifier → Learning / Writeback | 已升為 API/UI 可見 P0 工作項 | 把 Telegram、LOG、KM/RAG/MCP/PlayBook 與 UI 工作項掛到 AI Loop Agent 節點 |
| 2 | CIR-P0-AILOOP-002 | P0 | 「所有 AI 自動化完整流程、節點必須完整且詳盡紀錄」 | 每次 AI 自動化事件記錄 trace_id、run_id、work_item_id、節點狀態、timestamp、evidence refs、verifier、rollback、KM/PlayBook trust writeback | 已升為 API/UI 可見 P0 工作項；節點 schema 待補 | 建立 AI automation node receipt schema，先套用 Telegram alert 與 P0 runtime lanes |
| 3 | CIR-P0-LOG-001 | P0 | 「所有專案、產品、網站、服務、套件、工具的 LOG 都要收進去」 | 建立全域 LOG source registry 與 ingestion adapters，含 redaction、retention、freshness、last_success、owner lane | 已升為 API/UI 可見 P0 工作項 | 先做 metadata-only LOG source registry，不讀 secret / raw payload |
| 4 | CIR-P0-LOG-002 | P0 | 「LOG 要貼標、分類、分群，讓 AI Agent 可以處理」 | LOG 自動貼 product/project/site/service/package/tool、severity、lane、confidence、AI route、cluster_id、fingerprint | 已升為 API/UI 可見 P0 工作項 | 定義 tag taxonomy 與 clustering readback，先覆蓋 Telegram、CPU、backup、freshness |
| 5 | CIR-P0-TG-001 | P0 | 「所有發送到 Telegram 的監控告警是否全面清查、完整寫入 DB 或日誌、符合 AI 自動化？」 | 每個 Telegram 告警映射 DB/log receipt、AI route、controlled queue、work item、post verifier、learning writeback；direct send / manual default 列缺口 | workflow / ops / API direct send 已收斂到 0；`/runs/ai-alert-cards` 已補 KM / PlayBook / RAG / MCP `learning_writeback_refs` read model，已投影 KM / PlayBook / RAG / MCP / verifier / AI Agent registry bindings，接進 AI Loop Agent consumer context receipt；verified context receipts 已 surface 到 AwoooP shared receipt panel；新增 `telegram-alert-monitoring-coverage-readback` API / UI coverage 區塊，會明確列 direct gap、DB/log readback、AI context verifier 與 monitoring live receipt gap | 推 Gitea CD 後讀回 production coverage endpoint；若 `monitoring_live_receipt_gap_count > 0`，下一步依 coverage action packet 進行 metadata-only live receipt ingestion / tag / cluster / KM-RAG-MCP-PlayBook context |
| 6 | CIR-P0-IA-001 | P0 | 「IwoooS 被移除、導航列菜單被移除，且沒有整合到相關頁面」 | 建立 IA/nav removal recovery ledger：被移除 menu/route/page 必須有保留、合併、替代目的地、redirect、權限邊界與 smoke | 已升為 API/UI 可見 P0 工作項；route/menu 盤點待補 | 盤點 navigation config、route list 與 removed-page destination，補 readback |
| 7 | CIR-P1-AUTO-001 | P1 | 「不能偏離不代表一定要每一個工作完成，才能進行下一個」 | 建立主線並行推進規則：不離開 P0/P1 主線，但依賴允許時可同時推 API/UI、LOG、Telegram、KM/RAG/MCP/PlayBook、verifier | 已升為 API/UI 可見 P1 工作項 | 後續回報以 active lane + evidence 更新，不等待單一項完全結束 |
| 8 | CIR-P1-UI-001 | P1 | 「UI/UX 工作項目不見；整個前端頁面一大堆文字，要主流專業產品做法」 | UI/UX 成為主線：first-viewport cockpit、cards/flow rows、少文字牆、route/nav 一致、desktop/mobile smoke | 已升為 API/UI spotlight | 先讓 AI Loop / LOG / Telegram / IA 工作項在 Work Items spotlight 可見，再排 UI smoke |
| 9 | CIR-P1-KM-002 | P1 | 「所有服務日誌、LOG 要完整跟 KM、MCP、RAG、PLAYBOOK 整合」 | LOG tag/cluster 產生 RAG chunk、KM entry、MCP evidence pointer、PlayBook candidate、trust update、verifier/rollback learning | 已升為 API/UI 可見 P1 工作項 | 把 LOG source registry 接到 KM/RAG/MCP/PlayBook writeback readback |
| 10 | CIR-P3-NON-001 | P3 | 「隱形鐵窗 + 防霾捲紗（陽台最推薦）」 | 非 AWOOOI / AI 自動化主線事項，記錄但不改變 P0/P1 排序 | 已歸檔 deferred | 不執行，除非使用者明確切換到家裝 / 陽台需求 |

## 目前 Done / In Progress / Blocked

### Done

| 項目 | Evidence |
| --- | --- |
| AWOOOI Gitea main 可正常推進 | `f426610d`、`f41f77cf` 已進 remote history |
| CD controlled-runtime 誤判已修 | `#4373` tests log 顯示 `B5 effective test profile=controlled-runtime`，B5 skipped |
| 建立時基準主線 CD 成功 | Gitea CD `#4373 Success` |
| Production rollout 成功 | ArgoCD `Synced` / `Healthy`，API / Web / Worker rollout success |
| Production deploy readback matched | `631fc785fa` matched runtime / desired image tag |
| Playwright smoke 成功 | `5 passed` |
| 建立時基準同步到 Gitea truth | local `main...origin/main` clean at deploy marker `ab748b1a` |
| 110 Gitea CPU 專用 check-mode playbook | `gitea-queue-hook-backlog-playbook.py` 已上 main；live readback 可輸出 health/version/hooktasks/active Actions |
| 110 CPU evidence / controller 分流一致性 | live evidence 與 controller 皆將 Stock/Postgres pressure 優先導向 `postgres_hot_query_or_backup_export_playbook` |
| 插入需求 API/UI 可見化 | `awoooi-priority-work-order-readback` 已把插入需求主線工作項產品化；Work Items 頁有 spotlight |
| Telegram alert AI Loop post-apply verifier + coverage surface | `telegram-alert-learning-context-post-apply-verifier` API / service / tests 已完成；`telegram-alert-monitoring-coverage-readback` API / service / UI 已新增，會把 monitoring inventory、alert_operation_log、AwoooP outbound mirror、AI automation matrix 與 post verifier 合成 coverage readback |
| Public maintenance fallback runtime readback | Gitea CD `#4459` / deploy marker `8d7a6faaf` 已讓 production scorecard 讀回 `public_maintenance_fallback.ready=true`、raw 5xx=`0`、P0 blockers `11`、readiness `47` |
| Reboot SLO per-blocker 告警投影 | Source 已補 `awoooi_reboot_auto_recovery_slo_active_blocker{blocker=...}`、`RebootAutoRecoveryActiveBlocker`、`RebootAutoRecoveryActiveBlockerMetricMissing` 與契約測試 |

### In Progress

| 項目 | 目前狀態 | 下一步 |
| --- | --- | --- |
| AI Loop Agent 主線 | 已升為 P0 工作項，對齊 MASTER §1.4 閉環節點 | 把 Telegram、LOG、KM/RAG/MCP/PlayBook、UI 工作項都掛到 AI Loop 節點 |
| AI 自動化流程 / 節點紀錄 | 已升為 P0 工作項；trace/run/work_item/node/evidence/verifier/writeback schema 待補 | 建立 AI automation node receipt schema |
| 全域 LOG 收集 | 已升為 P0 工作項；source registry / adapter / freshness / retention 尚未統一 | 建立 metadata-only LOG source registry |
| LOG 貼標 / 分類 / 分群 | 已升為 P0 工作項；tag taxonomy / cluster readback 待補 | 先覆蓋 Telegram、CPU、backup、freshness |
| Telegram 告警 AI 自動化 | direct send / DB receipt / AI route / controlled queue / learning registry / AI Loop consumer context / post-apply verifier / AwoooP shared surface / monitoring coverage readback 已有 source 與本地測試；production deploy/readback 進行中 | 正式 deploy 後讀 `/api/v1/agents/telegram-alert-monitoring-coverage-readback`，依 active blockers 推 metadata-only LOG ingestion、貼標、分群與 KM / RAG / MCP / PlayBook context writeback |
| IwoooS / 導航 IA 復原 | 已升為 P0 工作項；removed menu/route/page destination 待盤點 | 盤點 navigation config、route list、removed-page integration |
| 主線並行推進規則 | 已升為 P1 工作項；需在回報與 UI 顯示 active lanes | 後續以 active lane + evidence 更新，不因單一 blocker 停全局 |
| UI/UX 專業化主線 | 已升為 P1 工作項；Work Items spotlight 先呈現核心缺口 | 排 AwoooP / Approvals / Runs / Work Items / Alerts desktop/mobile smoke |
| 110 controlled drain lane | live verifier 仍不能宣稱 ready，需 staging artifacts / registration metadata / service guardrails 全綠 | 補 staging artifacts 後只跑 readiness verifier |
| 全產品 source-control governance | 9 expected Gitea repos OK，但跨產品 dev/prod CI baseline 尚未全綠 | 以 Gitea / Gitea SSH / backup health 為 source truth |
| KM / PlayBook / RAG / MCP 整合 | 已被列為 P1，不再遺漏 | 建立 work item schema 與 trust writeback 欄位 |
| OpenClaw / Gather-style 持續動畫工作室 | route 已存在，已列為 P1 工作項 | 補 production desktop/mobile smoke、AwoooP 導流與截圖證據 |
| AI 專業 UI / 非文字牆 cockpit | 已列為 P2 UX 驗收 | 將長文字區塊收斂成 first-viewport cockpit、cards、flow rows 與 expandable details |
| 10 分鐘 reboot auto-recovery SLA | scorecard source / snapshot / API 已補固定 phase / ETA / blocker / next action 欄位；仍缺 fresh all-host reboot/drill proof | 補 production API readback，缺事件則明確標等待下一次 reboot 或 approved drill |
| 99 Windows / VMware autostart | Source verifier / parser / API readback / collection packet 已完成；live 99 Verify output 尚未收集，scorecard 以 `windows99_vmware_autostart_readback_missing` fail-closed；collection packet 顯示 99 reachable、可收 no-secret Verify，但 uptime unknown | 收集 99 no-secret Verify output，確認 VM 111/188/120/121/112 running、scheduled task / services / Windows Update policy 全綠 |
| Reboot SLO blocker 收斂 | production scorecard 已固定 `11` blockers / readiness `47`，且 source 已補 per-blocker metric/alert；還沒部署本輪告警規則 | 推 Gitea CD 後部署/讀回 Prometheus rules，再依具名 blocker 收斂 99/111/backup/service/Wazuh |
| 全備份監控告警 coverage | 部分 exporter/rule 已存在，但 host/DB/site/service/package/tool/log coverage 未全列 | 建立 backup coverage matrix 與 restore drill verifier |
| Stock/Postgres hot pressure | 110 live 已導向 Stock/Postgres playbook；尚未完成 hot query / backup export playbook closure | 下一步執行 read-only Stock/Postgres evidence 與 source freshness / query attribution |

### Blocked / Deferred

| 項目 | 原因 | 處理方式 |
| --- | --- | --- |
| GitHub 全產品 push / mirror | GitHub account safety freeze；不得用 GitHub / gh / API | 保持 stopped / do_not_use；未來需風險評估 |
| 直接使用聊天中貼出的敏感值 | secret safety hard gate | 不記錄、不重印、不保存；以 rotate / revoke / hidden prompt 取代 |
| VMware console / sudo 密碼路徑 | 屬 break-glass / local console lane | 只有控制路徑不可用且目標明確時才開 non-secret SOP |
| Windows Update policy apply | 需要 99 Windows 管理通道或 console；不得收密碼 | 先完成 policy verifier / checklist，再做 controlled apply |
| GitHub push / mirror / CI | GitHub freeze | 只保留 stopped / do_not_use 記錄，不列入可執行 P0 |

## 下一輪固定執行順序

1. 先確認 Gitea `main` / CD / production readback 是否仍與最新 truth 一致。
2. 接續目前 active P0-006：把 per-blocker reboot SLO metric / alert 修法推進到 Gitea CD，讀回 Prometheus / Alertmanager / production scorecard。
3. 補全 reboot auto-recovery P0：99/110/111/112/120/121/188 reboot detection、10 分鐘 SLO scorecard、Telegram down/up/recovered/SLO missed / active-blocker receipts。
4. 補 99 Windows / VMware autostart P0：99 host 自動啟動 VMware，VM 111/188/120/121/112 自動啟動；同時補 Windows Update no-auto-restart verifier。
5. 補 111 reachability / host boot readback，讓 `host_unreachable_after_reboot` 與 `reboot_event_required_host_unreachable` 有單一固定處理路徑。
6. 補 backup observability P0：host / DB / website / service config / package list / tools / logs backup matrix、last success、offsite、restore drill、Telegram receipt。
7. 補 service_green / Wazuh degraded readback，清楚分開 reboot service blocker 與 P2 observability debt。
8. 補 public maintenance fallback P0：production 已清掉缺讀回；後續只在 raw 502 再現時走 L0 Nginx intercept / header verifier，edge unreachable 才走 L1 external static fallback decision + rollback。
9. 補 product freshness/version P0：所有產品網站 source SHA / deploy marker / runtime image / public URL / data freshness readback。
10. 接續 110 / 188 CPU pressure P0：跑 `postgres_hot_query_or_backup_export_playbook` 的 read-only evidence / source freshness / query attribution，並補 188 equivalent readback。
11. 繼續補 110 controlled drain lane 的 staging / verifier，不恢復 generic runner。
12. 把全產品 repo identity / backup health / private visibility / dev-prod CI baseline 接到 product governance matrix。
13. 把 AI Loop Agent、AI 自動化節點紀錄、LOG 收集/貼標、Telegram 告警 AI route 與 post-apply verifier 接到上述 P0 lanes；不得讓它們取代 reboot/SLA 主線順序。
14. 補 OpenClaw Live Ops Space 的 production desktop/mobile animation smoke 與 AwoooP 導流。
15. 補 AI professional UI / 非文字牆 cockpit 驗收，避免只剩長文字頁。
16. GitHub appeal 前不做任何 GitHub 操作；appeal 後若使用者明確要求，先做風險評估。
