# AWOOOI 全面工作盤點與產品 UI/UX 專業化推進清單

> 日期：2026-06-25（台北時間）
> 基線：`gitea/main=3e475bc0`（deploy `4e814393`，包含 Runs apply gate Work Item 審查入口、焦點優先讀取與 Telegram Work Item owner review 入口）
> 定位：回應「做了很多但使用者看不到成果」的產品真相盤點、頁面優化計畫與 AI 自動化落地路線。
> 邊界：本文件只建立盤點與推進清單；不開 runtime gate、不 SSH、不 active scan、不讀 secret、不發 Telegram、不修改主機或 workflow。

## 0. 結論先講

目前 AWOOOI 最大問題不是「沒有做事」，而是做了大量 read-only governance、snapshot、API、UI 卡片與文件，但沒有被整合成使用者能快速判斷狀況的產品體驗，也沒有完整打通真正 AI 自動化閉環。

必須拆成兩個百分比來看：

| 指標 | 目前狀態 | 判讀 |
|---|---:|---|
| AI Agent 只讀治理 / API / gate 契約 | `92%` | 已有很多 snapshot、API、治理頁與邊界顯示，但主要仍是「看得到、不能動」。 |
| 完整 AI 自動化產品閉環 | 約 `60-64%` | Sensor / Evidence / Classification / Gate / UI 有雛形；`repair_candidate_missing` 已拆出 owner-review-ready 草案狀態，但 execution、verifier、KM / PlayBook writeback、Telegram live receipt 仍不足。 |
| 真正 production autonomous repair | 約 `3-5%` verified success | 多數告警仍落在 manual review、draft ready owner review、general fallback 或 no-action；草案 ready 不等於 runtime success。 |
| 全站專業 UI/UX 產品化 | 約 `58%` | Google Ads 式 shell、主導航整併、Tenants 作戰圖 / mobile responsive 資產卡、AwoooP 首屏 AI 自動化真相帶、Work Items operator SOP rail、Approvals decision handoff rail、Runs apply gate Work Item 入口，以及 Telegram Work Item owner review 入口已上線；Observability / Knowledge Base 仍需大幅圖表化與重複頁整併。 |
| 全產品 / 網站 / 專案納管 | read-only `65%`，runtime `0%` | Tenants API 已列 `16` 個產品面、`31` 條公開路由、`10` 個候選 repo；owner accepted / runtime gate / action buttons 仍全為 `0`。 |

因此下一階段不能再以「新增更多文字卡」為主要進度。必須改成：

1. 把所有頁面變成「狀況圖、流程圖、拓樸圖、矩陣、時間線、證據表、決策 rail」。
2. 把所有告警、KM、PlayBook、腳本、排程、自動化機制沉澱到同一條 AgentOps truth chain。
3. 把相同功能頁整併，移除重複敘事頁，保留一個主控面與必要下鑽頁。
4. 把真正可行動的 AI 自動化分層落地：低風險 dry-run -> verifier -> owner gate -> canary -> audited execution。

## 1. 最新工作真相

### 1.1 正式 API 讀回

2026-06-25 讀回：

| API | 讀回重點 | 判讀 |
|---|---|---|
| `/api/v1/health` | `healthy`、`environment=prod`、`mock_mode=false`、Ollama route order `GCP-A -> GCP-B -> local` | 生產 API 健康，但這不代表 AI 自動修復已打通。 |
| `/api/v1/agents/automation-backlog-snapshot` | overall `92%`、current `P1-007`、next `P2-004`、done `23/25` | 自動化 backlog 的 read-only / gate 層接近完成；P2 / P3 runtime 與 provider / cost gate 還沒完成。 |
| `/api/v1/platform/tenants` | tenants `2`、product surfaces `16`、public routes `31`、candidate repos `10`、in-scope repos `9`、runtime gate `0`、action buttons `0` | 已有全產品資產台帳，但還不是完整營運控制台。 |
| `/api/v1/agents/product-code-review-gate` | product scope `16`、pre-deploy gates `8`、post-deploy gates `6`、AI reviewers `5`、mainstream tools `9`、critical gaps `6`、active write gate `0` | Code Review 防木馬機制已完成 read-only gate 模型，但外部 scanner / signing / provenance / all-products workflow gate 尚未落地。 |

### 1.2 本機工作區風險

目前 `/Users/ogt/awoooi` 存在大量本地漂移與刪除狀態，例如 `apps/web` 多個檔案顯示 deleted，且夾雜許多未追蹤 API / schema / template 檔。
這個狀態不能直接拿來做 release 或 UI 大改，否則很容易覆蓋其他工作線、遺失前端檔案或污染 deploy。

本輪盤點改用乾淨 worktree：

`/private/tmp/awoooi-uiux-inventory-20260625`

後續 UI/UX 大改也應從乾淨 worktree 開 branch，先做頁面切片，不在髒工作樹上硬修。

## 2. AWOOOI 目前工作域盤點

### 2.1 IwoooS / 資安治理

| 工作域 | 目前成果 | 缺口 |
|---|---|---|
| Source Control / GitHub primary readiness | Gitea / GitHub refs、S4.9-S4.13 owner response packet、source-control readiness、候選 repo 納管已大量完成 | owner response accepted 仍 `0`；GitHub primary readiness `0%`；不能切 primary / sync refs / 改 workflow。 |
| DNS / TLS / certbot / host service / SSH network | repo-only 清冊、主機服務配置、SSH / network access、Docker / systemd、high-value config coverage 已上 IwoooS | live evidence / owner accepted / maintenance window / rollback owner 仍 `0`。 |
| Wazuh | 已定位 Wazuh agent transport、Dashboard API / RBAC / TLS 退化、owner evidence preflight、release gate 分層 | production Wazuh route 仍需正式部署讀回；manager registry truth 仍未驗收；active response / host write `0`。 |
| Secrets / workflow / owner response | secret name parity、workflow secret owner handoff、canonical envelope、review checklist 已完成 | secret value 不可讀；owner response gate 仍 `0%`。 |

### 2.2 AwoooP / 告警 / 事故 / 修復

| 工作域 | 目前成果 | 缺口 |
|---|---|---|
| Incidents / Runs / Approvals / Work Items | 狀態鏈、MCP evidence、repair candidate draft、approval gate、learning record 等資料已可見；Work Items 已新增人工卡點與自動化缺口 SOP rail，Approvals 已新增 decision handoff rail，能把阻塞、證據、接手包與安全閘門集中判讀 | Runs 仍需同樣的 SOP rail；每個 blocked lane 後端仍要補 service-specific PlayBook、safe command route、verifier、rollback 與回寫狀態。 |
| Telegram 告警 | 已有 no-send / failure-only / AwoooI SRE 戰情室契約與紅線；2026-06-25 已修 `PostgreSQLSlowQueries` 被 backup / escrow token 誤分類的問題，並把 repair-candidate no-action / owner-review-ready 卡片補上 Work Item 第一層入口 | live send、receipt production write、Bot API、Gateway queue 多數仍 `0`；週報 / 日報出現全 0 代表資料源或報表邏輯未變成有效營運訊號。 |
| PlayBook / Ansible / Repair | PlayBook trust、repair candidate、Ansible evidence 已在多處顯示；database target 不再預填 K8s restart，改為 read-only DB evidence + owner review | 多數仍只「建議」或「草案」，缺 service-specific playbook、safe command route、verifier 與 rollback receipt；DB 類事件仍需真實 production formatter / Work Items / Runs readback 驗證。 |
| KM / learning | KM / PlayBook / writeback gate 被多次定義 | 使用者在頁面與 TG 看不到完整沉澱結果；KM 頁資料鏈仍需修。 |

### 2.3 AgentOps / AI Agent

| 工作域 | 目前成果 | 缺口 |
|---|---|---|
| OpenClaw / Hermes / NemoTron | 已定義分工、治理頁、market governance、12-Agent War Room、owner review queue、action audit ledger | 多數還是 read-only layout，不是 live runtime worker；AgentSession / AgentEvent / handoff bus 未成為所有頁面的主資料骨幹。 |
| AI Router / provider | GCP-A / GCP-B / local route order、provider route matrix、fallback contract 已顯示 | provider 切換、shadow / canary、paid API 仍 blocked；頁面不應露出內部 IP，需用 provider alias + owner / project mapping。 |
| 市場主流 AI 技術 | 已開始 market governance 與 OpenClaw replacement gate | 需要固定 replay / shadow / canary 評分，並把 OpenAI Agents SDK、LangGraph、MCP、OTel GenAI、PagerDuty / Datadog AIOps 類模式納入 AWOOOI scorecard。 |

### 2.4 全產品 / 網站 / 專案納管

Tenants 目前已讀到：

| 類別 | 數量 | 目前狀態 |
|---|---:|---|
| Tenant table | `2` | `ewoooc`、`awoooi` |
| Product surfaces | `16` | 核心平台、行動商務、世界盃、VibeWork、agent bounty、股票、藥局、形象站、設計系統、n8n、Grist、Vault、Ollama、Gitea / GitLab / Harbor / registry、Sentry / SigNoz / Langfuse / monitor |
| Public routes | `31` | 大多仍 `read_only_pending_smoke` 或 `owner_response_required` |
| Candidate repos | `10` | in-scope `9`，primary ready `0` |
| Runtime gate / action buttons | `0 / 0` | 沒有可執行納管，只有只讀資產台帳 |

使用者要求「全部納入」是正確方向，但目前 Tenants 頁沒有把「已納管、待 smoke、缺 source、缺 owner、缺 runtime gate」用視覺層分清楚，所以看起來像沒有成果。

### 2.4.1 Tenants 作戰圖第一刀上線

2026-06-25 已將 `/zh-TW/awooop/tenants` 從單純租戶 / 資產表格往全產品作戰圖推進：

| 項目 | 完成 |
|---|---|
| 作戰圖 | `產品納管作戰圖` 顯示產品、網站入口、來源範圍、owner 閘門、執行閘門與操作入口 |
| 熱力圖 | 前 12 個產品以卡片呈現入口數、來源數、owner accepted，並保留剩餘產品數 |
| 下鑽 | 連到可觀測性、知識與自動化、推版審查 |
| 正式資料 | tenant `2`、product surfaces `16`、public routes `31`、candidate repos `10`、in-scope repos `9` |
| 正式站驗證 | deploy marker `3b552100`，desktop / mobile smoke 通過，作戰圖內水平溢出 `0` |
| 仍未完成 | 下方 route / source / tenant 寬表格仍需改成 responsive cards / drawer；owner accepted、執行閘門、操作入口仍為 `0` |

### 2.4.2 Tenants 資產表格響應式卡片化

2026-06-25 已完成第二刀，將 `/zh-TW/awooop/tenants` 下方的 `網站與服務入口`、`脫敏原始碼範圍` 從手機寬表格改為卡片式證據視圖。

| 項目 | 完成 |
|---|---|
| Code commit | `d52583d9 feat(web): make tenants asset tables responsive` |
| Deploy marker | `7f44bc3b chore(cd): deploy 20c2c81 [skip ci]`，包含 `d52583d9` |
| Mobile UX | `awooop-route-card-grid=true`、`awooop-source-card-grid=true`；兩張舊寬表格在手機 `visible=false` |
| Layout | mobile `clientWidth=384`、`scrollWidth=384`、`horizontalOverflow=false`、`overflowing=[]` |
| 桌機 | 保留表格供比對；作戰圖、全域產品資產台帳與核心產品名稱可見 |
| 邊界 | 沒有新增部署、掃描、修復、刪除、重啟或 runtime execution；owner accepted、執行閘門、操作入口仍為 `0` |

完成度同步：Tenants 全產品資產中心 `62% -> 68%`；全站 UI/UX 專業化 `47% -> 49%`。

### 2.5.1 AwoooP 首屏 AI 自動化真相帶

2026-06-25 已完成 `/zh-TW/awooop` 首屏第一刀，將使用者最關心的「AI 到底有沒有全自動、卡在哪、下一步去哪裡處理」放進 `OperationsDecisionMap` 首屏。

| 項目 | 完成 |
|---|---|
| Code commit | `092bd376 feat(web): add AwoooP automation truth rail` |
| Deploy marker | `291b6c0c chore(cd): deploy 092bd37 [skip ci]` |
| 顯示內容 | `AI 自動化真相`、閉環宣稱、卡點、下一步焦點、Runs / 工作項 / 批准下鑽 |
| Production desktop | `clientWidth=1274`、`scrollWidth=1274`、`horizontalOverflow=false`；truth rail 與下鑽入口可見 |
| Production mobile | `clientWidth=384`、`scrollWidth=384`、`horizontalOverflow=false`；truth rail 與下鑽入口可見 |
| 邊界 | 沒有新增部署、掃描、修復、刪除、重啟、Telegram send 或 runtime execution；仍只讀顯示 |

完成度同步：AwoooP 首屏操作台可判讀性 `52% -> 59%`；全站 UI/UX 專業化 `49% -> 51%`。

### 2.5.2 AwoooP Work Items 人工卡點 SOP rail

2026-06-25 已完成 `/zh-TW/awooop/work-items` 首屏第一刀，將使用者最常追問的 `manual_required_no_action`、`repair_candidate_missing`、`learning_recorded` 類卡點，收斂成 operator 可判讀的 SOP rail。

| 項目 | 完成 |
|---|---|
| Code commit | `aa70835c feat(web): add Work Items operator SOP rail` |
| Deploy marker | `2a9e816a chore(cd): deploy aa70835 [skip ci]` |
| 顯示內容 | 一眼判讀、驗證率、runtime gate、收件 / 證據 / 候選 / 接手 / 驗證流程、阻塞與人工閘門、修復候選品質、沉澱資產缺口、負責人接手 |
| Production desktop | `/zh-TW/awooop/work-items?project_id=awoooi&_v=2a9e816a-work-items-sop-prod-desktop` |
| Production mobile | `/zh-TW/awooop/work-items?project_id=awoooi&_v=2a9e816a-work-items-sop-prod-mobile` |
| Layout | desktop `clientWidth=1434 scrollWidth=1434`；mobile `clientWidth=384 scrollWidth=384`；`horizontalOverflow=false`；rail overflow `0` |
| 邊界 | 只讀 SOP 與下鑽；不發 Telegram、不改服務、不套用腳本、不新增部署 / 掃描 / 修復 / 刪除 / 重啟 / 執行按鈕，不提高 runtime gate |

完成度同步：AwoooP Work Items 可判讀性 `84% -> 89%`；AwoooP 核心頁產品化 `59% -> 62%`；全站 UI/UX 專業化 `51% -> 53%`。

### 2.5.3 AwoooP Approvals 審批決策 handoff rail

2026-06-25 已完成 `/zh-TW/awooop/approvals` 首屏第一刀，將卡在 `learning_recorded`、`execution_failed`、`manual_required`、逾時、Gate 5 投影與 Legacy HITL 的批准，收斂成 operator 可判讀的 decision handoff rail。

| 項目 | 完成 |
|---|---|
| Code commit | `01a8e9d3 feat(web): add approvals decision handoff rail` |
| Deploy marker | `66be2576 chore(cd): deploy bfc78d3 [skip ci]`，包含 `01a8e9d3` |
| 顯示內容 | 審批決策 Rail、請求 / 證據 / 決策 / 接手 / 驗證流程、阻塞與人工閘門、AI 證據可用度、接手包與工作項、安全閘門仍關閉 |
| Production desktop | `/zh-TW/awooop/approvals?project_id=awoooi&_v=66be2576-approvals-rail-prod-desktop` |
| Production mobile | `/zh-TW/awooop/approvals?project_id=awoooi&_v=66be2576-approvals-rail-prod-mobile` |
| Layout | desktop `clientWidth=1434 scrollWidth=1434`；mobile `clientWidth=384 scrollWidth=384`；`horizontalOverflow=false`；rail overflow `0` |
| Error 判讀 | `無法載入審批資料` 僅存在 Next messages script，visible error count `0`；production APIs `/platform/approvals`、`/approvals/pending`、`/health` 均回 `200` |
| 邊界 | 只讀審批判讀與安全導覽；不送 Telegram、不套用 PlayBook、不執行 Ansible、不重啟服務、不切換 provider、不新增部署 / 掃描 / 修復 / 刪除 / 重啟 / 執行按鈕，不提高 runtime gate |

完成度同步：AwoooP Approvals 可判讀性 `58% -> 66%`；AwoooP 核心頁產品化 `62% -> 65%`；全站 UI/UX 專業化 `53% -> 55%`。

### 2.5.4 Repair Candidate Draft Ready owner review 狀態模型

2026-06-25 已完成後端第一刀，將 `node-exporter-188` 類「診斷 PlayBook 已能預填修復草案」從 `REPAIR_CANDIDATE_MISSING` 中拆出，避免 Telegram 與 Approvals 繼續把「AI 已產出 owner review 草案」顯示成「AI 沒做事」。

| 項目 | 完成 |
|---|---|
| 狀態模型 | `RepairCandidateResult.draft_ready_for_owner_review` |
| 草案 ready 條件 | MCP evidence ready、Work Item 存在、repair template 不是 placeholder、route 為 `*_after_owner_review`、runtime gate 仍關閉 |
| Webhook action | `DRAFT_READY - REPAIR_CANDIDATE_OWNER_REVIEW_REQUIRED` |
| Executor 防線 | `DRAFT_READY` / `OWNER_REVIEW_REQUIRED` 被視為 no-action approval，不會排 executor |
| Telegram | 顯示 `repair_candidate_draft_ready_owner_review` 與 `Owner review 處置包` |
| Callback | 回 `ApprovedForOwnerReviewHandoff`、`manual_handoff_kind=repair_candidate_owner_review` |
| Operation log | ready 草案寫 `REPAIR_CANDIDATE_DRAFT_READY`，不再當缺候選 escalation |
| 驗證 | `py_compile` 通過；`DATABASE_URL=sqlite:///tmp/awoooi-test.db pytest apps/api/tests/test_repair_candidate_service.py apps/api/tests/test_telegram_ai_automation_block.py apps/api/tests/test_telegram_webhook_execution_handoff.py -q`：`21 passed` |
| 邊界 | 不執行 `systemctl restart`、不 SSH、不 Ansible apply、不發 Telegram、不開 runtime gate；owner review 前仍不可執行 |

完成度同步：Repair candidate missing 後端真相模型 `38% -> 48%`；Telegram 告警可判讀性 `58% -> 64%`；AwoooP AI 自動化真相鏈 `60% -> 64%`；production autonomous repair verified success 仍 `3-5%`。

### 2.5.5 Runs recurrence Work Item 草案狀態 chip

2026-06-25 已完成 `/zh-TW/awooop/runs` 小切片，讓 recurrence 卡片能讀出 work item 的 `owner_review_ready` / `draft_ready`，把「AI 已產出草案，等待 owner review」放到 Run 視角。

| 項目 | 完成 |
|---|---|
| UI | recurrence 卡片新增 Work Item status chip |
| 狀態 | `owner_review_ready`、`draft_ready`、`open`、`blocked`、`closed`、`none`、`unknown` |
| 判讀 | `owner_review_ready` 顯示「草案待 owner review」，不再只看到「無修復記錄」 |
| 驗證 | JSON parse、i18n mirror `RUNS_WORK_ITEM_STATUS_I18N_OK leaves=13652`、`pnpm --filter @awoooi/web typecheck`、`git diff --check` 通過 |
| 邊界 | 只讀顯示，不新增執行、重啟、Telegram send、PlayBook apply 或 runtime gate |

完成度同步：AwoooP Runs 可判讀性 `62% -> 65%`；全站 UI/UX 專業化 `55% -> 56%`；AwoooP AI 自動化真相鏈仍 `64%`。

### 2.5.6 Ansible check-mode 乾跑不再誤標為已修復

2026-06-25 正式 API 讀回 `INC-20260625-977E5F` 時確認：`node-exporter-188` 類告警已出現 Ansible `check_mode` 證據，但實際只有乾跑，沒有 apply，也沒有 verifier。舊狀態鏈把它顯示成 `execution_succeeded / executed_pending_verification`，會讓 operator 誤以為 AI 已經執行修復，實際上只是完成安全乾跑。

| 項目 | 完成 |
|---|---|
| 真相來源 | `check_mode_total=1`、`apply_total=0`、`auto_repair_execution_records=0` |
| 狀態鏈 | 新增 `ansible_check_mode_only`，不再顯示 `executed_pending_verification` |
| Operator outcome | 新增 `dry_run_only_owner_review_required` |
| 下一步 | `owner_review_apply_gate_or_create_verifier_plan` |
| API evidence | `ansible_dry_run_only=true` |
| Telegram / Callback | 詳情、歷史與 callback snapshot 套用同一判定，避免 TG 把 dry-run 講成已修復 |
| 驗證 | `py_compile` 通過；`DATABASE_URL=sqlite:///tmp/awoooi-test.db pytest apps/api/tests/test_operator_outcome.py apps/api/tests/test_awooop_operator_timeline_labels.py apps/api/tests/test_telegram_message_templates.py -q`：`150 passed` |
| 正式站 | code `d7b3997b`、deploy marker `420b0b18`；`INC-20260625-977E5F` 讀回 `ansible_check_mode_only` / `dry_run_completed_no_apply` / `repair_status=not_executed`；`INC-20260625-66086A` 仍維持 `manual_required_no_action` 控制組 |
| 邊界 | 不執行 Ansible apply、不 restart、不 SSH、不發 Telegram、不開 runtime gate；只修正狀態鏈語意 |

完成度同步：AwoooP status-chain 真相語意 `64% -> 67%`；Telegram / AwoooP 乾跑誤導修正 source-side / production readback `100%`；真正 AI 自動化 verified repair 成功率不提高，仍需以 apply + verifier + KM / PlayBook writeback 計算。

### 2.5.7 Runs apply gate 串接 Work Item 審查入口

2026-06-25 已完成 `/zh-TW/awooop/runs` 小切片，讓 `INC-20260625-977E5F` 這類已完成 Ansible check-mode 乾跑但尚未 apply 的事件，可以從 Runs 事故焦點直接進 Work Items owner review。

| 項目 | 完成 |
|---|---|
| Work Item 入口 | `AwoooPStatusChainPanel` 在 `automation_handoff.work_item_id` 存在時顯示 `查看 Work Item 審查` |
| 目標連結 | `/zh-TW/awooop/work-items?project_id=awoooi&work_item_id=ansible-apply-gate%3Aawoooi%3AINC-20260625-977E5F&incident_id=INC-20260625-977E5F` |
| 焦點優先 | Runs URL `incident_id` 改為獨立優先讀取 status-chain，不再被整頁 Run 批次拖慢 |
| Code commits | `68f66476 fix(web): link Runs apply gate to Work Item`；`5ee68dc7 fix(web): prioritize Runs incident focus chain` |
| Deploy markers | `5e21c734 chore(cd): deploy 68f6647 [skip ci]`；`3e2890f6 chore(cd): deploy 5ee68dc [skip ci]` |
| Production smoke | desktop 約 `7.7s`、mobile 約 `8.3s` 出現 `乾跑後套用閘門` 與 `查看 Work Item 審查`；Work Items 目標頁 desktop / mobile 可讀到工作項、incident 與狀態鏈 |
| Layout | desktop / mobile `horizontalOverflow=0`；危險執行入口 `0` |
| 邊界 | 不執行 Ansible apply、不重啟、不 SSH、不發 Telegram、不新增 runtime action、不提高 runtime gate |

完成度同步：Runs apply gate operator handoff `100%`；AwoooP Runs 可判讀性 `77% -> 80%`；全站 UI/UX 專業化 `55% -> 57%`；production autonomous repair verified success 仍 `3-5%`，因為尚未 apply、verifier、KM / PlayBook trust writeback。

### 2.5.7 Runs 資產沉澱拆出乾跑 / 套用狀態

2026-06-25 已完成 `/zh-TW/awooop/runs` 前端語意小切片：`資產沉澱` ledger 不再把 Ansible candidate、check-mode、apply 全部混在「腳本」一格，而是拆成 `乾跑` 與 `套用`。

| 項目 | 完成 |
|---|---|
| UI | `AwoooPAutomationAssetLedger` 新增 `dryRun` / `apply` 兩格 |
| 判讀 | `ansible_dry_run_only=true` 或 `check_mode_total>0 / apply_total=0` 時，乾跑 ready、套用 blocked / `未套用` |
| Verifier | dry-run only 時 Verifier 不再淡化為 pending，改顯示卡點 |
| i18n | `zh-TW` / `en` messages 新增 `dryRun`、`apply`、`notApplied`；leaf diff `0` |
| 驗證 | JSON parse、i18n leaf diff、`pnpm --filter @awoooi/web typecheck`、`git diff --check` 通過 |
| 邊界 | 只改前端顯示；不新增執行、重啟、Telegram send、PlayBook apply、Ansible apply 或 runtime gate |

完成度同步：AwoooP Runs 可判讀性 `65% -> 68%`；AwoooP 操作台產品化 `66% -> 67%`；真正 AI 自動化 verified repair 成功率不提高。

### 2.5.8 Status-chain 乾跑後套用閘門 handoff

2026-06-25 已完成 status-chain 結構化 handoff：當 `INC-20260625-977E5F` 類事件只有 Ansible `check_mode` 成功、沒有 apply、沒有 verifier 時，不再只顯示一串「需人工」文字，而是把下一關拆成可審查 gate。

| 項目 | 完成 |
|---|---|
| API | `awooop_status_chain_v1` 新增 `automation_handoff` |
| Handoff kind | `ansible_check_mode_apply_gate` |
| 三段 gate | `dry_run=passed`、`apply_gate=blocked`、`verifier=blocked` |
| 資產 | `work_item_id`、dry-run asset、apply candidate、verifier asset |
| Owner review | checklist 與 forbidden actions 結構化輸出 |
| UI | `/zh-TW/awooop/runs` 共用 status-chain panel 新增 `乾跑後套用閘門` 三卡區塊 |
| 驗證 | `py_compile`、`pytest apps/api/tests/test_awooop_operator_timeline_labels.py -q`：`66 passed`、i18n JSON / leaf diff、`pnpm --filter @awoooi/web typecheck` 通過 |
| 邊界 | 不執行 Ansible apply、不重啟服務、不 SSH、不發 Telegram、不新增執行按鈕、不開 runtime gate |

完成度同步：AwoooP status-chain handoff 可判讀性 `67% -> 70%`；AwoooP Runs 可判讀性 `68% -> 71%`；真正 AI 自動化 verified repair 成功率仍不提高。

### 2.5.9 Runs incident filter 502 修正

2026-06-25 `4e329bce` 部署後，正式 status-chain API 已回 `automation_handoff`，但 Runs 頁帶 `incident_id=INC-20260625-977E5F` 仍看不到新區塊；追查後確認 `/api/v1/platform/runs/list` 單一事故 filter 會回 `502`。

| 項目 | 完成 |
|---|---|
| 問題 | incident filter 舊流程先載入 project 下大量 runs，再逐筆聚合 message context，production 歷史量大時 timeout |
| 修正 | `list_runs` 在 incident filter 存在時，先從 run trigger、conversation event、outbound message、source_refs、callback reply、persisted status-chain 預篩出 run_id |
| 效果 | 找不到 run_id 時直接回空列表；找到時只對相關 runs 建立 summary，不再全表掃描 |
| 驗證 | `py_compile` 通過；`pytest apps/api/tests/test_awooop_operator_timeline_labels.py -q`：`66 passed` |
| 邊界 | 只讀查詢修正；不寫 DB、不改 run 狀態、不執行修復、不發 Telegram、不開 runtime gate |

完成度同步：Runs incident drilldown 穩定性 `60% -> 72%`；Runs apply-gate 正式頁驗證需下一個 deploy marker 後重跑。

### 2.5.10 Runs incident filter 接入 status-chain 焦點

2026-06-25 `e5a0aa13` 部署後，正式 API 已證明 incident drilldown 不再 502：

| 項目 | 結果 |
|---|---|
| Health | `/api/v1/health`：`healthy / prod / mock_mode=false` |
| Status-chain | `INC-20260625-977E5F` 回 `ansible_check_mode_only`、`automation_handoff.kind=ansible_check_mode_apply_gate`、`runtime_execution_authorized=false` |
| Runs list | `/api/v1/platform/runs/list?incident_id=INC-20260625-977E5F` 回 `200`、`total=3` |
| 新缺口 | run list 摘要不一定帶 `remediation_summary.incident_ids`，前端只靠 run summary 推導 status-chain 時，URL 已帶 incident id 仍可能看不到焦點 handoff |

修正：Runs 頁若 URL `incident_id` 符合 `INC-*` 格式，直接把該 id 納入 `useIncidentStatusChains`，保留原本從 run summary 收斂多事故關聯的邏輯。

完成度同步：Runs incident drilldown 穩定性 `72% -> 82%`；AwoooP Runs apply-gate 正式頁驗證需前端修正 deploy 後重跑。

### 2.5.11 Runs 事故焦點狀態鏈面板

2026-06-25 `5a76316a` 部署後，正式 Runs 頁面可載入且沒有 502 / JS error / 水平溢出，但仍未顯示 `乾跑後套用閘門`。原因是 status-chain 只被表格列用來補欄位，沒有固定的 incident drilldown 焦點區；而這次 `INC-20260625-977E5F` 的 run summary 又缺 incident ids，讓使用者只看到 Run 摘要和大量文字。

| 項目 | 調整 |
|---|---|
| 焦點面板 | URL `incident_id` 合法時，在 KPI 區下方固定顯示「事故焦點狀態鏈」 |
| 狀態鏈 | 直接渲染 `AwoooPStatusChainPanel`，顯示 verdict、repair_state、apply gate、verifier 等 |
| 資產總帳 | 直接渲染 `AwoooPAutomationAssetLedger`，讓 KM / PlayBook / 乾跑 / 套用 / Verifier 狀態同屏可見 |
| 表格列 | incident filter 模式下，列資料也可使用 URL 焦點 status-chain 補齊來源流程與資產總帳 |
| 文案 | 新增 `awooop.runsIncidentFocus` i18n，zh-TW / en key 鏡像 |
| 邊界 | 不新增任何執行按鈕；不寫 DB、不發 Telegram、不開 runtime gate |

完成度同步：Runs incident drilldown 可判讀性 `82% -> 90%`；真正修復自動執行成功率仍不提高，下一步要補 owner review apply gate / verifier plan 的實際狀態閉環。

### 2.5.12 Runs incident focus 正式站驗證

2026-06-25 `f01458c2` 正式部署後，`INC-20260625-977E5F` drilldown 已完成 end-to-end 可視化驗證。

| 項目 | 正式結果 |
|---|---|
| Deploy marker | `f01458c2 chore(cd): deploy 4076c3c [skip ci]` |
| Health | `healthy / prod / mock_mode=false` |
| Runs list | `incident_id=INC-20260625-977E5F` 回 `200`、`total=3`，不再 `502` |
| Status-chain | `ansible_check_mode_only`、`automation_handoff.kind=ansible_check_mode_apply_gate`、`runtime_execution_authorized=false` |
| Desktop smoke | `事故焦點狀態鏈`、`乾跑後套用閘門`、`套用審查 / 阻擋`、`驗證回寫 / 阻擋`、`runtime=false`、Work Item 可見；console error `0`、horizontal overflow `0`、危險操作入口 `0` |
| Mobile smoke | 同 desktop，`390x844` 下 horizontal overflow `0` |
| 不可誤讀 | 沒有 Ansible apply、沒有 service restart、沒有 Telegram action send、沒有 verifier success、沒有 runtime gate |

完成度同步：Runs incident drilldown 可判讀性 `90% -> 100%`；AwoooP Runs apply-gate 正式頁驗證 `100%`；真正修復自動執行成功率仍不提高。

### 2.5.13 Runs apply gate handoff 審查包

`INC-20260625-977E5F` 已有 `automation_handoff`，但畫面只呈現三段 Gate 與部分 ID，operator 仍不容易知道「要審什麼、為什麼不能按、下一步資產在哪」。本段把 API 已有欄位完整產品化成審查包。

| 區塊 | 調整 |
|---|---|
| Owner Gate | 顯示 `work_item_id`、`owner_review_gate`、`next_action` |
| 候選 PlayBook | 顯示 catalog、risk、match score、check-mode playbook、apply playbook |
| 資產 ID | 顯示 dry-run asset、apply candidate asset、verifier asset |
| 審查清單 | 顯示 `owner_review_checklist`，讓人工接手不再只看到「需人工」 |
| 禁止動作 | 顯示 `forbidden_actions`，避免誤把 dry-run 或 approval UI 當執行授權 |
| Mobile | 長 ID / playbook path 改用換行處理，避免水平溢出 |

本地驗證：i18n leaf diff `0`、`pnpm --filter @awoooi/web typecheck`、`source-control-owner-response-guard.py`、`security-mirror-progress-guard.py`、`git diff --check` 皆通過。

完成度同步：Runs apply gate handoff 可審查性 `70% -> 78%`；AwoooP Runs 可判讀性 `71% -> 74%`。真正自動修復成功率不提高；正式站驗證需 deploy marker 後重跑。

### 2.5.14 Runs apply gate handoff 正式站驗證

2026-06-25 `e558c727` 正式部署後，`INC-20260625-977E5F` Runs drilldown 已確認把 apply gate handoff 審查包完整顯示。

| 項目 | 正式結果 |
|---|---|
| Code commit | `6ed461cf feat(web): enrich Runs apply gate handoff` |
| Deploy marker | `e558c727 chore(cd): deploy 6ed461c [skip ci]` |
| API readback | `candidate.catalog_id=ansible:188-ai-web`、check/apply playbook、owner checklist `4`、forbidden actions `3`、`runtime_execution_authorized=false` |
| Desktop smoke | `候選 PlayBook`、`Owner 審查清單`、`禁止動作`、dry-run / apply / verifier asset、`runtime=false` 可見；console error `0`、dangerous action `0`、horizontal overflow `0` |
| Mobile smoke | 同 desktop；`390x844` 下 `scrollWidth=clientWidth=384`、horizontal overflow `0` |
| 不可誤讀 | 沒有 Ansible apply、沒有 service restart、沒有 Telegram send、沒有 verifier success、沒有 KM / PlayBook trust writeback |

完成度同步：Runs apply gate handoff 正式站可審查性 `78% -> 100%`；AwoooP Runs 可判讀性 `74% -> 77%`。下一步仍是把 owner review / verifier / KM writeback 變成真正狀態機，不是把人工卡點藏在長文字裡。

### 2.5.15 Telegram 修復候選 Work Item 入口

2026-06-25 已完成 Telegram 卡片小切片，讓 `INC-20260625-977E5F` / `node-exporter-188` 這類已產生 owner review 修復候選草案但 runtime gate 未開的告警，不再只顯示「處置包 / 重診 / Runs」，而是在卡片與批准後回覆都放入 `Work Item` 第一層入口。

| 項目 | 結果 |
|---|---|
| Code commit | `4e814393 fix(api): surface Work Item handoff in Telegram cards` |
| Deploy marker | `3e475bc0 chore(cd): deploy 4e81439 [skip ci]` |
| 文字提示 | no-action / owner-review-ready 卡片顯示 `Work Item -> 處置包 -> Runs` |
| Inline keyboard | 非可執行修復卡第一列加入 `Work Item` URL；保留 `處置包`、`重診`、`歷史`、`真相鏈`、`Runs` |
| Callback 後狀態 | 批准 NO_ACTION 後仍顯示 Work Item / 處置包資訊按鈕，並明確標示 `這不是執行中` |
| URL 正規化 | `/awooop/work-items?...` 會補成 `https://awoooi.wooo.work/zh-TW/awooop/work-items?...` |
| 測試 | Telegram 訊息與 keyboard 測試 `82 passed`；py_compile、source-control guard、security mirror guard、diff check 通過 |
| Production readback | health `healthy / prod / mock_mode=false`；Work Item / Runs deep link 皆 `200` 且不含錯誤文字 |
| 邊界 | 不發 Telegram 測試訊息、不執行 Ansible apply、不重啟、不 SSH、不寫 runtime state、不開 runtime gate |

完成度同步：Telegram 修復候選 operator handoff `64% -> 70%`；AwoooP AI 自動化可判讀性 `64% -> 66%`；全站 UI/UX 專業化 `57% -> 58%`。真正 production autonomous repair verified success 仍約 `3-5%`。

### 2.5.16 Telegram / Work Item 修復候選升級合約

2026-06-26 已完成 API / Telegram 小切片，讓 `DRAFT_READY - REPAIR_CANDIDATE_OWNER_REVIEW_REQUIRED` 不再只是一段 owner review 長文，而是能產生 `repair_candidate_promotion_contract_v1`：明確列出候選路由、修復模板、rollback、verifier、ready / blocked 計數，以及仍缺的 owner release、維護窗口、blast radius、KM owner 與 PlayBook trust owner。

| 項目 | 結果 |
|---|---|
| Code commit | `06dd4d0f feat(awooop): expose repair candidate promotion contract` |
| Deploy marker | `6be83053 chore(cd): deploy 06dd4d0 [skip ci]` |
| 合約 | `repair_candidate_promotion_contract_v1`，host-service 草案可顯示 `route=host_service_route_after_owner_review`、`ready=6/11`、`blocked=5` |
| Telegram | `Owner review 處置包` 會新增 `候選升級合約` 摘要；callback payload 也會回傳完整 promotion contract |
| Work Item | `awooop_repair_candidate_draft_work_item_v1` 帶入同一份 `candidate_promotion_contract`，後續可接 owner release / apply gate |
| 驗證 | API / TG 目標測試 `21 passed`；py_compile、source-control guard、security mirror guard、doc secret sanity、diff check 通過；Gitea code-review `#3448` 與 CD `#3447` 成功 |
| Production readback | health `healthy / prod / mock_mode=false`；舊 incident 不會 retroactive 生成新 contract，需下一筆同類告警或重診重新跑候選生成 |
| 邊界 | 不發 Telegram 測試、不執行 Ansible apply、不重啟、不 SSH、不寫 KM、不提升 PlayBook trust、不開 runtime gate |

完成度同步：Telegram 修復候選 operator handoff `70% -> 78%`；AwoooP AI 自動化可判讀性 `66% -> 68%`；全站 UI/UX 專業化維持 `58%`。真正 production autonomous repair verified success 仍約 `3-5%`。

## 3. 頁面 UI/UX 現況盤點

2026-06-25 對正式站桌機 / mobile 抽查：

| 頁面 | 現況 | 主要問題 | 優先級 |
|---|---|---|---|
| `/zh-TW/awooop` | Google Ads 式 shell 已存在，AwoooP 概覽與 AI 自動化真相帶可見 | 仍需把 Runs / Work Items / Approvals 的卡點與 owner SOP rail 串回同一首屏；後續要減少下方長文字卡 | P0 |
| `/zh-TW/awooop/runs` | Runs 狀態鏈、provider evidence、recurrence Work Item 草案狀態 chip 可見；後端與資產 ledger 已能分辨 Ansible check-mode 乾跑、套用與 verifier 卡點 | mobile 有長字串、內部 provider URL / key 類資訊外露風險；仍需補 Situation Strip / Agent Flow / Action Rail 才能一眼分辨「乾跑、已套用、待 verifier、需 owner apply gate」 | P0 |
| `/zh-TW/awooop/work-items` | 工作項目、repair candidate 與 operator SOP rail 可見；已能一眼看到人工卡點、候選品質、沉澱資產與負責人接手 | 底部長表格仍需 responsive data grid / drawer 化；每筆 item 還要補更細的 owner、rollback、verifier receipt 與狀態回寫 | P0 |
| `/zh-TW/awooop/approvals` | approval 狀態鏈、AI evidence 與審批決策 handoff rail 可見；已能一眼看到阻塞、證據、接手包與安全閘門；後端已能把 prefilled host-service 草案標成 owner-review-ready | 表格仍需 drawer 化；Runs / Work Items 仍要讀回 draft-ready 狀態、owner、rollback、verifier receipt 與資產 ID | P0 |
| `/zh-TW/awooop/tenants` | 16 產品、31 路由、10 repo 資產可讀；作戰圖與 route/source 手機卡片已上線 | 下一步補產品拓樸 drilldown 與租戶資料表 drawer | P0 |
| `/zh-TW/observability` | 有監控面板雛形 | 出現 error / 0% / -- 類狀態，沒有把主機、服務、工具、告警、SLO 串成拓樸與 blast radius | P0 |
| `/zh-TW/knowledge-base` | KB 頁存在 | 資訊讀取看起來像全部不見或全 0；需區分 loading、empty、error、stale、blocked、owner required | P0 |
| `/zh-TW/governance?tab=automation-inventory` | 大量治理卡與 API readback | 過度像文件頁，不像控制台；應改成 AgentOps cockpit + drilldown，不再堆字 |
| `/zh-TW/code-review` | Product code review gate 已 100% read-only | 需要連到所有產品 release lane，顯示 pre / post deploy gate、scanner candidate、AI reviewer verdict，而不是只列文字 | P1 |

## 4. 市場主流做法對 AWOOOI 的要求

### 4.1 導航與資訊架構

參考：

- Material navigation drawer：側欄應承載 app 的主要目的地，目的地數量要可掃描。
- IBM Carbon UI shell：企業後台 shell 應分清全域 header、左側 product navigation、內容區，避免把所有層級都同時攤開。
- Atlassian 新導航：主導航要讓使用者在大型產品中快速切換工作脈絡，不能靠深層巢狀選單找功能。

AWOOOI 應改成：

| 層級 | 做法 |
|---|---|
| 全域 shell | 只保留 5 個主區：總控台、AwoooP、Observability、Knowledge / Automation、Governance / Admin |
| 二層菜單 | 只顯示當前主區的 workflow，例如 AwoooP 顯示 Overview / Incidents / Runs / Work Items / Approvals / Tenants |
| 上方分頁 | 只做同一頁的視圖切換，例如 Overview 的 `狀況 / 流程 / 證據 / 歷史`；不要再拿 tabs 當導航 |
| 詳細資料 | 放到右側 drawer / bottom sheet，不要塞在主畫面長文字卡 |
| Mobile | 表格轉 cards / timeline，任何 `min-w-[760px]` 類寬表都要有替代卡片視圖 |

### 4.2 AI Agent 主流技術

參考：

- OpenAI Agents SDK：Agents、Tools、Handoffs、Guardrails、Tracing 是基本能力，不是只做聊天摘要。
- LangGraph：長任務 Agent 需要 durable execution、human-in-the-loop、memory，流程可以中斷 / 恢復 / 審核。
- PagerDuty / Datadog AIOps：事件要能 dedupe、correlate、orchestrate、runbook automation，並且把 incident management 與 responder context 串起來。

AWOOOI 缺的是：

| 主流能力 | AWOOOI 應落地方式 |
|---|---|
| Durable Agent State | 建立 `AgentSession`，每個 incident / report / deployment / route smoke 都有同一條狀態線 |
| Handoff | OpenClaw -> Hermes -> NemoTron -> SRE -> Security 的交接要變成可見事件，不是文字描述 |
| Guardrails | low / medium / high / critical 對應不同 gate、verifier、rollback 和 audit reason |
| Tool / MCP Registry | 每個 MCP call 要有能力、範圍、風險、結果、失敗原因 |
| Runbook Automation | PlayBook 必須有 trust score、適用條件、命令、rollback、verifier、owner review |
| Learning Writeback | KM / PlayBook 更新必須顯示來源、引用、owner、驗證結果，不能只是「KM +1」 |
| Agent Observability | 將 LLM / tool / MCP / approval / verifier 串成 trace，頁面以 timeline 與 spans 呈現 |

## 5. 目標產品形態

### 5.1 每頁固定資訊架構

每個主要頁面必須固定成 6 塊：

| 區塊 | 目的 | 內容 |
|---|---|---|
| Situation Strip | 3 秒內看懂現在發生什麼 | 健康、風險、卡點、下一步、owner、最近更新 |
| Flow / State Machine | 看 AI 自動化跑到哪 | 收件 -> 分類 -> MCP -> PlayBook -> Gate -> Execution -> Verifier -> KM |
| Decision Matrix | 看為什麼不能自動處理 | 風險、信心、證據、PlayBook trust、approval gate、rollback |
| Topology / Dependency | 看影響範圍 | 主機、服務、pod、路由、產品、repo、告警來源 |
| Evidence Table | 查細節 | MCP calls、Sentry / SigNoz、logs、metrics、timeline refs |
| Action / Gate Rail | 看下一步 | 可做 / 不可做 / 需要誰批准 / verifier / rollback / SOP |

### 5.2 要抽出的共用 visual components

| Component | 用途 | 優先級 |
|---|---|---|
| `AwoooProductShell` | 全站一致導航與 page toolbar | P0 |
| `SituationStrip` | 所有頁首狀況摘要 | P0 |
| `AgentFlowRail` | AI 自動化流程進度 | P0 |
| `RiskDecisionMatrix` | 決策支援 / 覆蓋率 / risk gate | P0 |
| `EvidenceTimeline` | incident / run / approval / report 共用時間線 | P0 |
| `TopologyMap` | 主機 / 服務 / 專案 / 路由關係 | P1 |
| `CoverageHeatmap` | Tenants / Observability / KB / Code Review 覆蓋狀態 | P1 |
| `ResponsiveDataGrid` | 桌機表格、手機卡片 | P0 |
| `EvidenceDrawer` | 長文字與 raw evidence 下鑽 | P0 |
| `PlayBookTrustPanel` | PlayBook / Ansible / verifier / rollback | P1 |

## 6. 優先順序與時程

### 6.1 頁面 UI/UX 還要多久

若以「所有主要頁面都達到專業 AI 運維產品水準」為標準，不是幾個小時的修補；合理估算如下：

| 階段 | 時間 | 完成後會看見什麼 |
|---|---:|---|
| Phase 0：止血與 IA 凍結 | `1-2 天` | 不再新增文字卡；修內部 URL / raw key 外露；列出重複頁與合併地圖；確定全站 shell 規則。 |
| Phase 1：共用視覺元件 | `3-5 天` | Situation Strip、Agent Flow、Risk Matrix、Evidence Drawer、Responsive Grid 可重用。 |
| Phase 2：AwoooP 核心頁改造 | `5-8 天` | Overview / Runs / Work Items / Approvals / Tenants 變成可判斷、可下鑽、可追蹤的操作台。 |
| Phase 3：Observability + KB 修資料鏈與視覺化 | `4-6 天` | 主機 / 服務 / 網站 / 告警 / KM / PlayBook 有拓樸、熱圖、狀態分類，不再全 0 / 讀取中。 |
| Phase 4：Governance / Code Review / Reports 統一 AgentOps | `4-7 天` | AI reviewer、release gate、日週月報、market watch、risk queue 同一套 cockpit。 |
| Phase 5：Runtime 自動化閉環 | `7-14 天` | 低風險 dry-run / canary / verifier / KM writeback 開始可被逐項驗收。 |

第一個可感受到的 UI 成效：`2-3 天`。
全站主要頁面專業化：`3-4 週`。
真正 AI 自動修復閉環：需再拆 owner gate 與 runtime gate，不能用 UI 改版假裝已完成。

### 6.2 P0 工作清單

| ID | 工作 | 驗收 |
|---|---|---|
| P0-UX-001 | 凍結目前資訊架構，不再往頁面塞新文字卡 | 新增 UI 變更需指定進 Situation / Flow / Matrix / Topology / Evidence / Action 其中一層 |
| P0-UX-002 | AwoooP Runs 移除 raw internal provider URL / key 顯示 | 正式 DOM 不出現 LAN IP / raw provider endpoint；改顯 provider alias、owner、route order、fallback reason |
| P0-UX-003 | Work Items / Approvals / Runs 加人工處置 SOP rail | Work Items 與 Approvals 首屏 rail 已上線；下一步 Runs 要同樣顯示 owner、why blocked、safe next action、dry-run / apply / verifier 差異、evidence missing、rollback / verifier status |
| P0-UX-004 | Tenants 改成全產品 Coverage Heatmap + Topology | 第一刀已上線；下一步移除舊寬表格依賴，改成 responsive cards / drawer |
| P0-UX-005 | Observability 修 `0% / -- / error` 語義 | 所有 0 要分成 no data、not connected、blocked、healthy zero、stale、error |
| P0-UX-006 | Knowledge Base 修讀取狀態與沉澱總帳 | 顯示 KM / PlayBook / scripts / schedules / owner / stale / trust score，不再像資料消失 |
| P0-UX-007 | 重複頁整併 | AwoooP / Governance / Observability / IwoooS / Code Review 的重複卡片改成 shared read model |
| P0-UX-008 | 所有頁面 mobile overflow 與 text density gate | `horizontalOverflow=0` 只是底線；還要檢查長字串、寬表、過長段落、按鈕溢出 |

### 6.3 P1 工作清單

| ID | 工作 | 驗收 |
|---|---|---|
| P1-AI-001 | AgentSession / AgentEvent read model | 所有 incident / report / deploy / code review 都能看到同一條 Agent trace |
| P1-AI-002 | MCP / Tool registry | MCP call 不只顯示數量，要顯示工具、能力、風險、結果、失敗原因 |
| P1-AI-003 | PlayBook Trust Ledger | 每個 PlayBook 顯示版本、owner、成功率、失敗原因、verifier、rollback |
| P1-AI-004 | Low-risk dry-run worker | 只能 dry-run，輸出 verifier / rollback / audit，不 production write |
| P1-AI-005 | Report data source repair | 日報 / 週報 / 月報不能全 0；要能標示資料源斷線或尚未接入 |
| P1-AI-006 | AwoooI SRE 戰情室單一路由 | 全產品告警統一進 SRE 戰情室，其他 TG Bot / 群組改為停用或轉送 |
| P1-CR-001 | 全產品 pre / post deploy Code Review Gate | 16 產品都要有 pre-deploy、post-deploy、rollback、reviewer receipt |
| P1-CR-002 | ElephantAlpha / Aider / mainstream scanner 分工 | ElephantAlpha 做 high-risk review；Aider 只做批准後 patch；CodeQL / Semgrep / Gitleaks / OSV / Trivy 需 activation packet |

## 7. 頁面合併與保留策略

| 現有頁面 | 未來定位 | 行動 |
|---|---|---|
| AwoooP Overview | AI 自動化指揮中心 | 保留，重做為狀況總覽 / 流程圖 / 卡點 / 行動 rail |
| Runs | Agent execution timeline | 保留，下鑽頁；raw evidence 放 drawer |
| Work Items | Operator queue | 保留，加入 SOP rail、owner review、KM / PlayBook task |
| Approvals | Risk gate center | 保留，改成 decision tree / stale approvals / stuck gate |
| Tenants | 全產品資產中心 | 保留並升級為產品拓樸與 coverage heatmap |
| Observability | 全系統可觀測中心 | 保留，主機 / 服務 / 網站 / 告警 / SLO topology |
| Knowledge Base | Knowledge / PlayBook / Script ledger | 保留，修資料鏈與 trust score |
| Governance automation inventory | AgentOps governance cockpit | 降低文字量，變成政策 / gate / market / report 控制台 |
| IwoooS | Security posture cockpit | 保留，只顯示高價值 security posture，不再塞所有治理文字 |
| Code Review | Release safety gate | 保留，連到 all-products release lane |

## 8. 驗證規則

每個 UI/UX 切片都必須通過：

| 類別 | 驗證 |
|---|---|
| API truth | production API readback，不用 mock 當成果 |
| Browser | desktop + mobile smoke |
| Layout | `horizontalOverflow=0`、overflowing elements `0`、長字串不撐版 |
| Text density | 首屏不超過 3 個長段落；長證據進 drawer |
| Redaction | 不顯示 LAN IP、raw endpoint、secret key、內部工作視窗語彙 |
| i18n | `zh-TW` / `en` key mirror、placeholder 一致 |
| Icon | 前端 UI 禁 emoji icon，使用 lucide / design system icon |
| No fake data | 沒資料要標 `未接入 / 阻擋 / stale / error`，不可用假數字補滿 |
| Runtime boundary | UI 可見不得拉高 runtime gate、owner response、Telegram live send、host write |

## 9. 來源與主流參考

| 主題 | 參考 |
|---|---|
| Agent / tools / handoff / tracing | OpenAI Agents SDK docs：https://developers.openai.com/api/docs/guides/agents |
| Durable execution / HITL / memory | LangGraph overview：https://docs.langchain.com/oss/python/langgraph/overview |
| Human-in-the-loop | LangChain HITL：https://docs.langchain.com/oss/python/langchain/human-in-the-loop |
| Incident management | Datadog Incident Management：https://docs.datadoghq.com/incident_response/incident_management/ |
| Event dedupe / correlation | Datadog Event Management：https://www.datadoghq.com/product/event-management/ |
| Event orchestration / AIOps | PagerDuty Event Orchestration：https://support.pagerduty.com/main/docs/event-orchestration |
| Runbook automation | PagerDuty Runbook Automation：https://www.pagerduty.com/platform/automation/runbook/ |
| Enterprise shell / navigation | IBM Carbon UI Shell：https://carbondesignsystem.com/components/UI-shell-left-panel/usage/ |
| Navigation IA | Material Navigation：https://m2.material.io/design/navigation/understanding-navigation.html |
| Large product navigation | Atlassian Navigation System：https://atlassian.design/components/navigation-system |
| Data visualization | Material Data Visualization：https://m2.material.io/design/communication/data-visualization.html |

## 10. 下一步執行順序

立即下一步應是 P0-UX-001 到 P0-UX-004，不再先做更深的文件治理。

1. 從乾淨 worktree 建立 UI branch。
2. 抽 `AwoooProductShell`、`SituationStrip`、`AgentFlowRail`、`RiskDecisionMatrix`、`EvidenceDrawer`、`ResponsiveDataGrid`。
3. 先改 `/zh-TW/awooop/runs` 與 `/zh-TW/awooop/work-items`，因為使用者已直接指出「批准後沒有自動化 / 人工也不知道怎麼做」。
4. 再改 `/zh-TW/awooop/tenants`，把所有產品 / 網站 / 專案納管變成拓樸與 heatmap。
5. 接著修 `/zh-TW/observability` 與 `/zh-TW/knowledge-base` 的資料鏈，不讓使用者看到全 0 或資料消失。
6. 每階段都要 production desktop / mobile smoke，並回報「完成度百分比 + 卡住 gate + 下一步」。

本文件建立後，UI/UX 總體專業化進度基準固定為：

| 項目 | 基準完成度 |
|---|---:|
| 全站 UI/UX 專業化 | `58%` |
| 導航 / IA 整合 | `64%` |
| AwoooP 操作台產品化 | `68%` |
| Tenants 全產品資產中心 | `68%` |
| Observability 專業拓樸 / 告警中心 | `38%` |
| Knowledge / PlayBook 沉澱可視化 | `34%` |
| Code Review / Release Safety Gate | `58%` |
| AI Agent 只讀治理 | `92%` |
| 真正 AI 自動化 runtime 閉環 | `60-64%` |
