awoooi/docs/workplans/2026-07-02-commander-inserted-requirements-priority-ledger.md

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

建立時間：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-03 18:19 最新 truth：production/runtime 仍 can_claim_all_services_recovered_within_target=false，primary reboot_event_required_host_unreachable；Windows99 locator 已從舊 generic candidate 收斂為 candidate_source_count=0，backup/source search package 顯示 120/121/local 未找到 verified 111 source、99 alias 無 Linux backup host mapping、110/188/112 SSH BatchMode unavailable	優先收斂 111 verified VMX source / backup path、授權 console source path 或離線備份 inventory、111 reachability 與 fresh all-host reboot event；不可宣稱 10 分鐘 SLA 已證明，不得用 RDP clipboard 片段或 generic VMX guess 當完成證據
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；08:23 host probe 有 7 列但 99 只有 ping/RDP reachable、uptime unknown，111 unreachable，112/120/121/188 uptime 都已超過 10 分鐘窗口	讓 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 已完成；18:19 no-write locator 確認 expected 111 VMX path 不存在、candidate_source_count=0、locate_status=blocked_missing_expected_vmx_source_no_candidate_found；backup/source package 顯示 candidate_source_count=0、blocked_host_count=4、apply_allowed_by_this_package=false；VMware services / scheduled task / Windows Update policy readback 已有，但 guest power 仍 not ready	不得直接 relink generic Ubuntu candidate；先取得授權 console source path 或離線備份 inventory verified source path，再做 scoped relink dry-run、rollback 與 post-verifier；不得從 public redacted path 或 scorecard 直接啟動 / 關閉 VM、重啟 Windows service、讀密碼或 host reboot
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	10:15 source/API patch：若 nested verifier 回 policy_blockers=["windows_update_policy_readback_missing"]，API 必須 fail-closed 重新提升 windows99_update_no_auto_reboot_policy_not_ready；不得只信舊 Prometheus windows99_update_no_auto_reboot_ready=true	補 no-secret policy readback / drift alert；若 policy 不綠，另走 controlled apply package + rollback + post-verifier，禁止要求或記錄 Windows 密碼，禁止由 scorecard 直接 apply registry
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 已存在；per-blocker reboot alerts 與 backup receipt rules 已 deploy/readback。Backup receipt 缺段已從 100 條 stage 噪音收斂為 110 / 188 兩條 host-level pending；仍需完整 shutdown/up E2E receipt	補 Prometheus / Alertmanager active/resolved 與 outbound receipt；backup alert 先補 /backup/alert-receipts/*.last_success 脫敏 marker，不送測試 secret、不重啟主機
7	CIR-P0-RBT-007	P0	「所有備份包含主機、DB、網站、服務、套件、工具、日誌都沒有監控告警」	Backup observability coverage：backup job inventory、last success、freshness、offsite、restore drill、Telegram/AwoooP receipt	已有 backup health exporter / alert rules / Gitea bundle restore dry-run；2026-07-03 runtime 讀回 110 有 88 個 receipt stage requirement、188 有 12 個，BackupAlertReceiptMetricMissing* inactive，BackupAlertReceiptStageMissing 聚合 pending 110 / 188 各一條	補 /backup/alert-receipts/*.last_success；再補 Gitea full dump / DB / settings / issues / packages / LFS 與所有工具/log 全量備份監控
8	CIR-P0-RBT-008	P0	「每次重啟排查都不一樣，也不知道多久恢復，不符合 SLA」	固定化 reboot runbook：fixed triage order、ETA、active blocker、remaining seconds、owner lane、next command	Production scorecard / priority readback 固定目前 P0：primary reboot_event_required_host_unreachable；Windows99 locator 最新 candidate_source_count=0，backup/source search package 已把 120/121/local searched、99/110/188/112 blocked 轉成機器可讀欄位	優先收斂 111 VMX source verified artifact、授權 console source path 或離線備份 inventory、111 reachability / fresh all-host reboot event、188 startup failed/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=bc8d3af3f chore(cd): deploy dacdd90 [skip ci]；CD #4558 log 顯示 API/Web build/push wrapper 全部 rc=0、deploy marker dacdd90、production deploy readback matched。Production SLO route 已讀回最新 API 行為：active_blocker_count=10、runtime_metric_runtime_readback_added_blockers=["windows99_vmware_autostart_config_not_ready","windows99_update_no_auto_reboot_policy_not_ready"]、windows99_update_no_auto_reboot_ready=false。StockPlatform public freshness / ingestion 仍為 ok，latest trading date 2026-07-02。	版本層已補到 AWOOOI production；下一步仍要建立全產品 readback 表，且收斂 Windows99 VMX / service / policy / power 與 host reboot-event blockers
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 latest source 已成功經 Gitea CD #4558 部署：bounded API/Web build/push wrapper 實跑 rc=0，deploy marker bc8d3af3f chore(cd): deploy dacdd90 [skip ci]，production deploy readback matched；queue reader 也已具備 cd_docker_step_timeout classifier	將 product governance matrix 接入各產品 Gitea CD readiness；CD Running 未 matched 時不得宣稱最新版已上 production
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 已開始補；09:22 已把 Windows99 console clipboard 不可靠經驗寫入 SOP v1.108、P0 workplan 與 scorecard regression；仍需 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 與契約測試
Backup alert receipt runtime contract	Source / runtime 已補 awoooi_backup_alert_receipt_expected_info、awoooi_backup_alert_receipt_stage_fresh、BackupAlertReceiptMetricMissing*、BackupAlertReceiptStageMissing、baseline contract、live visibility checker 與 focused tests；Prometheus rule 已部署，缺段 alert 已聚合成 110 / 188 host-level pending；不送 Telegram、不讀 token
CD Docker build/push timeout classifier production proof	.gitea/workflows/cd.yaml 已把 API/Web docker build / docker push 包進 run_docker_step，timeout 會輸出 BLOCKER cd_docker_step_timeout；read-public-gitea-actions-queue.py 已上卷 blocked_cd_docker_step_timeout / latest_visible_cd_docker_step_timeout* / fixed safe-next-action；本地 focused tests 92 passed。CD #4558 live log 已證明 API/Web build/push wrapper 全部 rc=0，deploy marker dacdd90，production deploy readback matched

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	2026-07-03 18:19 latest truth：仍 can_claim_all_services_recovered_within_target=false；primary reboot_event_required_host_unreachable，Windows99 locator candidate_source_count=0，backup/source search candidate_source_count=0 / blocked_host_count=4；111 VMX source / guest power / config / policy 仍 blocked	收斂 111 verified VMX source / backup path、授權 console source path 或離線備份 inventory、111 reachability、188 startup failed/degraded，再 rerun host probe + reboot-event detector
AWOOOI latest source production deploy readback	Gitea main=bc8d3af3f，deploy marker dacdd90；public CD #4558 log job succeeded / production deploy readback matched；production scorecard 已讀回 latest API 行為並把 Windows99 config / policy blockers 上卷	下一步轉回 Windows99 VMX / service / policy / power 與 host reboot-event blockers；不得因 deploy/readback 成功宣稱 10 分鐘 SLO 完成
99 Windows / VMware autostart	Source verifier / parser / API readback / collection packet 已完成；live 99 Verify output 已透過 no-secret collector 收集；VMX locator 最新顯示 expected 111 path missing 且 candidate_source_count=0，backup/source package 顯示 verified source 未找到、99/110/188/112 blocked	取得 verified VMX source / backup path，產生 scoped relink dry-run，重跑 no-secret collector，確認 VM 111/188/120/121/112 running
Reboot SLO blocker 收斂	production scorecard 已固定 10 blockers / readiness 60%，source / runtime 已補 per-blocker metric/alert；剩餘主 blocker 是 reboot event / unreachable + Windows99 111 VMX source / guest power / config / policy + 111 reachability / 188 degraded	依具名 blocker 收斂 99/111/188；不得用 route green 或 RDP 可見宣稱 SLA 完成
全備份監控告警 coverage	exporter/rule 已有 host/DB/site/service/package/tool/log coverage 與 backup alert receipt requirement；runtime rules 已部署，缺段 alert 聚合成 110 / 188 host-level pending；production receipt markers / full Gitea dump / DB/settings/issues/packages/LFS 尚未全綠	補 /backup/alert-receipts/*.last_success、Gitea full dump 與 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 reboot P0：用 18:19 locator / backup-search truth 收斂 111 verified VMX source / backup path、授權 console source path 或離線備份 inventory、111 reachability、188 startup failed/degraded，再 rerun host probe / reboot-event detector / 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：補 /backup/alert-receipts/*.last_success、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 後若使用者明確要求，先做風險評估。