diff --git a/docs/LOGBOOK.md b/docs/LOGBOOK.md index a983f6992..eb10fe2d4 100644 --- a/docs/LOGBOOK.md +++ b/docs/LOGBOOK.md @@ -1,218 +1,17 @@ -## 2026-07-15 — P0 MCP Playwright offline protocol/schema compatibility replay +## 2026-07-14 — 14:20 MCP POC 執行與自癒型維運代理環境初始化 **完成內容**： -- 新增 high-risk replay policy，固定 artifact policy checksum、`mcp-artifact-receipts` commit `9c08ada5c0f15bb6924304af29cd13c8376182ff`、controller/verifier receipt checksum、Harbor artifact digest與 internal runtime image digest；policy 有 owner、expiry、exit condition、replacement、rollback 與獨立 post-verifier。 -- replay controller 重新驗證 artifact receipt chain、manifest、CycloneDX SBOM、3 個 tarball SHA-512 與 package identity，再以 non-root、network none、read-only root、no-new-privileges、cap-drop ALL、bounded CPU/memory/PID/tmpfs/timeout 啟動 MCP。只送 `initialize`、`notifications/initialized`、`tools/list`，不啟動 browser、不呼叫 tool。 -- adapter contract 只允許 `browser_navigate`、`browser_snapshot`、`browser_take_screenshot`、`browser_close` 4 個未來 public verifier 能力；`browser_run_code_unsafe`、file upload、form/click/type/evaluate/network 等其餘 20 個工具明確 denied。Direct Gateway registration、adapter registration、shadow、canary、promotion、RAG write與 production write仍全部停用。 -- 獨立 verifier 完全不 import controller，重新 pull/readback exact artifact/runtime digest、重新解包並再次執行 protocol replay；controller/verifier 都要求 MCP stdin EOF clean exit與 ephemeral container removal terminal。 -- 新增 Gitea-only `mcp-external-replay.yaml`：每週三 10:43 Asia/Taipei、manual/push、non-110 host runner、host pressure guard、Harbor password-stdin/logout、pinned artifact audit commit、同 run/trace/work-item receipts，成功後只 normal push `mcp-replay-receipts` audit branch。 -- Gitea workflow runner-health snapshot納入第 15 條 workflow；scheduled workflow `6 -> 7`，non110 host mapped `4 -> 5`，沒有新增 runner attestation gap。 - -**source/test evidence**： -- controller/verifier 本機真實雙 replay 皆通過：MCP `Playwright@1.62.0-alpha-1783623505000`、protocol `2025-06-18`、24 tools、tool-name hash `12d23fea9d8d1a1de3f44863dc00cf393f0a2165323838cf93fed30a6a4cc237`、schema hash `c3737ced21147d0512b0400df5885c95a545bc915892b5c8f928cee78428ac99`，兩次均 clean exit/container removed。 -- 合併最新 Gitea main 後，artifact/replay controller + independent verifier、MCP control-plane/federation/version lifecycle/runner-health API與shared audit writeback聚焦回歸合計 `94 passed`。Ruff、py_compile、JSON/YAML parse、source-control owner guard與 `git diff --check` 通過。 -- Gitea replay `#5183` 已在 source `387f841...` 完成 controller + independent verifier，run `d3b8d15e-e5c6-43c0-b657-f9f23089677c`，audit commit `281d6e0058721dfbf84235d85c2f894a004ceea1`；24 tools、offline clean exit、container removal與所有 runtime/write boundary false 均有 durable receipt。 -- 後續 replay `#5186` 在 source `5eb46f9...` 的 controller/verifier 仍成功，但 final writeback 因 shallow main 與 audit branch `unrelated histories` 失敗；scheduled artifact `#5178` 有相同 terminal。根因不是 MCP replay 或 artifact verification，而是舊 workflow 把 audit branch merge 回 depth-1 main checkout。 -- 新增共用 fail-closed audit writeback：直接 checkout audit branch tip、只 stage兩個 allowlisted receipt、同 run identity與 branch/path/schema 綁定、最多 3 次 normal fast-forward push，無 merge、無 force。真實 temporary bare-Git functional tests涵蓋連續第二/第三次線性 push與拒絕 branch/path/identity mismatch，`4 passed`。 -- 修正由 source `7cd0f69475c4828c46c249d33d327a01bc5cb941` normal push後，artifact `#5191` 完整成功；audit branch從 `9c08ada...` 線性前進到 `226a733b022072d13fb4a4d69b81b7c2fac11cc3`，parent正是舊 audit tip，沒有 merge或 force。 -- replay `#5192` 隨後完整成功；run `90d0515a-0812-4b04-9913-b210313accff`、audit commit `4a15edb8309a550b6d77f8c1f88b6b1203206045` 的 parent為舊 tip `281d6e0...`。controller/verifier receipt SHA-256分別為 `279cf92ca06d418537b54921df7deab1377eac290cc885102f608f832cd013f5` / `161d41484cddab750e1904099c3adcb0909756262331351b09f28b632194cbad`。 -- production read model新增 compatibility state、protocol/server/tool schema、audit/run/receipt identity與 no-effect boundaries；API fail-closed拒絕缺 hash、非獨立 verifier、非 clean exit、container未移除或任何 browser/tool/navigation/RAG/production write/promotion side effect。`deployment_allowed`持續 false。 -- `/automation/mcp` 外部候選表新增 compatibility replay欄；Playwright列顯示 protocol/schema verified、MCP `2025-06-18`、24 tools與短 receipt ID，同列仍顯示 promotion disabled與5個剩餘 blockers。繁中/英文、desktop/mobile與內部水平 scroller同步完成。 -- global security mirror guard另抓到 latest main 既有 `apps/web/src/app/[locale]/iwooos/page.tsx` 的 `raw_blocked_waiting_state` 敏感字樣；本 work item未修改該檔，保留為獨立 drift blocker，不以 replay source 綠燈覆蓋。 -- catalog/API `7 passed`、Web typecheck與 production build成功；`/[locale]/automation/mcp` 為 `7.14 kB` / First Load JS `240 kB`。Browser桌機 `1440x1000`與手機 `390x844`均讀到12產品、replay receipt與 promotion disabled；頁面水平溢位 `0`、手機表格 overflow限制在內部 scroller、console error `0`。 - -**尚未完成 / 不誤報**： -- recurring artifact/replay audit writeback已由 `#5191/#5192`關閉；但 catalog/API/UI投影仍只在本地 source，尚未 normal push、CD、deploy marker與 production readback。先前 writeback source的 CD `#5190` 仍在 build-and-deploy，兩個 source generation不得混為同一 production closure。 -- Browser binary/runtime immutable supply chain、public-origin egress proxy與 private-network denial、prompt-injection replay、accessibility/latency shadow、canary、Gateway adapter registration、rollback execution與正式 KM/RAG learning acknowledgement仍是 promotion blocker。 -- 未讀 secret value、`.env`、raw session、SQLite/auth；未連線或下載 GitHub/Actions/hosted artifact，未使用 `npx -y`、`@latest`、`:latest`、force push、外部 RAG write或 production mutation。 - -**下一步**： -- 等待 `#5190` terminal後 normal push catalog/API/UI，取得新的 Gitea CD/deploy marker與 production API/mobile/desktop visible readback；再建立 immutable browser runtime與隔離 public-origin shadow/canary/rollback lane。 - -## 2026-07-15 — P0 MCP Playwright immutable mirror 與獨立供應鏈 verifier - -**完成內容**： -- mcp.so 僅保留 discovery URL；可執行 bytes 只從 policy allowlist 的 npm registry exact URLs 取得。`@playwright/mcp=0.0.78`、`playwright` / `playwright-core=1.62.0-alpha-1783623505000` 全部固定 version、SRI SHA-512、SHA-1、npm ECDSA signature、SLSA subject、dependency closure 與 Apache-2.0 license。 -- 新增 fail-closed artifact controller：拒絕 redirect、非 allowlist host、floating version、dependency/metadata drift、unsafe/duplicate tar entry、已知 OSV vulnerability 與未通過簽章的 artifact；產生 deterministic CycloneDX 1.5 SBOM 與 scratch OCI data bundle，不執行 package install、MCP、browser 或 container。 -- 新增完全不 import controller 的獨立 verifier：由 Harbor immutable digest 重新 pull/save image、只把 layer 當資料讀取，限制 file/byte/path/symlink/whiteout，要求 exact 8-file bundle，再次重算 manifest/SBOM/tarball hash、以 OpenSSL 重驗 npm signature 並重解 SLSA DSSE subject。 -- Gitea `mcp-external-artifact-mirror.yaml` 不使用遠端 action；push、manual 與每週三 pinned revalidation 都先跑 controller/verifier tests、host-pressure gate、Harbor password-stdin、獨立 readback與 logout。receipt 以 ephemeral askpass normal push 到專用 `mcp-artifact-receipts` audit branch，不再推 main、取消有效 CD 或保存 credential。 -- Gitea run `#5174` 成功；controlled run `dce032df-0a9a-476f-940b-e61a94865e1b` 產生 internal digest `sha256:de002c418bbb94fb4609539c4259c39ccb7f8b353f8bac8fbcba9e5742ad79ed`，獨立 verifier 為 `completed_internal_mirror_verified`，audit branch commit `9c08ada5c0f15bb6924304af29cd13c8376182ff`。 - -**source/test evidence**： -- artifact controller/verifier focused tests `24 passed`；MCP control-plane/federation/version-lifecycle `20 passed`。 -- 新增第 14 條 Gitea workflow 後，CD `#5173` 以 `2627 passed / 1 failed` 找出 workflow health contract 仍固定 13；已同步 workflow health snapshot、secret-name inventory、Gitea capability readback 與 priority work-order count，聚焦回歸 `40 passed`，secret names 維持 `26`、secret values collected=`false`。 -- Ruff、py_compile、JSON/YAML parse、freeze/floating-reference guard 與 `git diff --check` 通過。 - -**尚未完成 / 不誤報**： -- 目前只完成 immutable internal mirror 與供應鏈 verifier；`deployment_allowed=false`、`replay_allowed=false`、`shadow_allowed=false`、`canary_allowed=false`。尚未實作 registered public-origin replay adapter、compatibility replay、shadow/canary、runtime upgrade、post-verifier 或 rollback execution。 -- 外部 catalog / tarball / attestation 未寫 RAG；只保留 normalized digest、SBOM 與 supply-chain receipt。未讀 secret value、`.env`、raw session、SQLite/auth；未連線或下載 GitHub / Actions / hosted artifact，也未使用 `npx -y`、`@latest`、`:latest`、force push 或 production route mutation。 -- 本筆 inventory drift 修正與 catalog mirror state 尚待最新 main CD/deploy marker/production UI readback；不得由 `#5174` mirror success 倒推 AWOOOI production 已部署。 - -**下一步**： -- 先取得包含本修正的 Gitea CD terminal與 production MCP page readback；再以 public-only origin allowlist 建立 repo-owned replay adapter，要求 compatibility、prompt-injection、latency、accessibility、session/file/download no-write verifier與 rollback receipt 全數通過，才可進第一個 noncritical shadow/canary。 - -## 2026-07-15 — P0 MCP EwoooC/MOMO durable production federation source closure - -**完成內容**： -- 沿用既有 AWOOOI MCP Gateway、Provider Registry、PostgreSQL/pgvector 與 Redis；沒有新增第二套 Gateway、RAG database、權限或外部自動寫入平面。 -- 新增固定來源 `mo.wooo.work`、固定 HTTPS path 的 read-only federation controller。它拒絕 redirect、credential、過期/無 timezone receipt、額外欄位、prompt payload、URL/private endpoint、敏感 key、schema drift 與 SHA-256 fingerprint mismatch；raw source payload 只存在 bounded memory，不落 DB/LOG/RAG。 -- 新增 additive `awooop_mcp_federation_run` 與 `awooop_mcp_federated_runtime_receipt`，只允許 `ewoooc`、`momo-pro-system` 兩個 canonical identity，啟用 FORCE RLS。每次 run 使用同一 `run_id/trace_id/work_item_id`，並從 durable normalized columns 重建 source hash scope；不只比較來源聲稱的 hash。 -- signal worker 以 Redis atomic lease 每 6 小時執行，startup delay 45 秒；K8s manifest 明確啟用。CD 在 worker rollout 前套用 migration，驗證兩張 table、2 個 RLS policy、3 個 identity/source constraint 與 runtime DB role read access。 -- MCP overview 以真實 fresh receipt 取代硬編碼 `0`。兩筆 receipt 上線後只會把 EwoooC/MOMO 改為 federated partial/verified；全產品仍維持 `2/12`，`cross_product_runtime_federation_receipts_missing` 不會被誤關閉。 -- `/automation/mcp` 新增繁中/英文 production federation cockpit，顯示兩個產品的 MCP server IDs、server/tool counts、runtime version、RAG model/version state、PixelRAG platforms、freshness、durable run 與 blockers；mobile/desktop 採 responsive grid、empty/degraded state 與語意化 heading/status。 - -**source/test/build evidence**： -- API Ruff、py_compile、JSON/YAML parse 與 `git diff --check` 通過；MCP control plane、federation、version lifecycle、signal-worker binding focused pytest `30 passed`。 -- Web `typecheck` 通過；以 CD 同值 `NEXT_PUBLIC_API_URL=https://awoooi.wooo.work` 執行 production build 成功，`/[locale]/automation/mcp` route 為 `6.92 kB`、First Load JS `240 kB`。既有 Sentry migration / webpack cache 提示未由本工作新增。 -- EwoooC/MOMO source contract 在獨立 canonical Gitea worktree 完成 `7 passed`，endpoint 只輸出 aggregate metadata 與 verifier-recomputable fingerprint；既有 authenticated AI automation routes 不放寬。 - -**尚未完成 / 不誤報**： -- 本筆建立時兩個 repo 都還沒有本 feature 的 Gitea main、CD/deploy marker 或 production runtime receipt；source/test/build 綠燈不等於 runtime closure。 -- 第一筆 production federation run 尚未產生，因此目前不能宣稱 EwoooC/MOMO `2/2` durable receipt、12 產品 `12/12`、embedding model immutable、MCP/RAG production query canary 或 PixelRAG formal promotion 完成。 -- 未安裝/呼叫外部 MCP，未寫外部 RAG 或正式商品價格，未保存 request/response body、tool output、raw catalog/page，未讀 secret/token/`.env`/raw sessions/SQLite/auth，未使用 GitHub/`gh`/Actions，也未使用 `npx -y`、`@latest` 或 `:latest` 進行安裝/升級。 - -**下一步**： -- 依序 normal push EwoooC 與 AWOOOI Gitea main、等待各自 CD terminal，讀回 V10.796 public receipt、AWOOOI migration/runtime-role verifier、signal-worker first run、production API `2/12` 與 desktop/mobile visible UI；任一層失敗維持 partial/degraded 並走 bounded retry/rollback，不倒推完成。 - -## 2026-07-15 — P0-OBS-002 post-closure runtime regression 與 guard 修復 - -**runtime evidence**： -- gRPC bridge run `P0-OBS-002-20260715T013800+0800` 先通過完整 600 秒 verifier；後續 revision `2004` 於 02:11:22 起發生 liveness/readiness timeout，最低 `0/2 Ready`，兩 pod 各累積 restart `4`。bridge 維持同 PID、NRestarts `0`，因此不執行 bridge rollback。 -- API log 捕獲 `too many connections for role awoooi_api_runtime`；既有 CD verifier 在 role limit `12`、最低 headroom `8` 的條件下仍固定發出 8 個 DB-backed requests，存在把 `4 + 8` 打滿 `12/12` 的結構性風險。已完成的 #5119 receipt 本身顯示 probe 當時 active=`0`、restart `0->0`，故只把此問題列為高信心 structural amplifier，不誤報為唯一直接觸發。 -- 每日 `backup-all` 02:12 執行 SignOz 備份時停止 collector；volume backup 立即失敗，總備份僅 `3/9` 成功且 collector 未恢復。`P0-OBS-002-static-recovery-20260715T021600+0800` 只恢復 stateless collector，4317/4318、OTLP HTTP `200`、`.120/.121` gRPC TCP 全數通過，stateful services touched=`0`。 -- 公開 `/api/v1/health` 的 `components.signoz=down` 不是 OTLP 故障：live API 對舊 `192.168.0.188:3301` 回 connection refused，而 188 bridge 明確只 bind `127.0.0.1:3301`。同時 collector、4317/4318、gRPC bridge、trace/metric freshness 與 exporter errors 均維持正常，根因是 Query/UI control-plane health target drift。 - -**source/test evidence**： -- CD probe 改為先檢查 connection budget、保留 4 條安全餘量、最多 4 workers、單輪、每 request 5 秒；新增 workers/reserve/skip reason machine-readable receipt fields。 -- `backup-signoz.sh` 在 stop 前先 arm restore，加入 `EXIT/HUP/INT/TERM` trap、防重入 cleanup 與首次 restart 失敗後的有界 EXIT retry。 -- `110-devops.yml --tags backup_jobs` 納入 `backup-signoz.sh`，確保 source guard 有可驗證的 `/backup/scripts/backup-signoz.sh` 部署路徑，不再只停留在 repo。 -- `#5128` 在 `1518 passed` 後被 asset-integrity workflow shape 測試的過時注解邊界擋下；測試改以下一個 YAML `- name:` 截取單一 step，仍保留 shell body 不得出現 `${{ secrets.* }}` 的安全斷言，不放寬 secret transport policy。 -- SigNoz 路由分離為 internal Query/health `http://192.168.0.110:8080` 與 public deep link `https://signoz.wooo.work`；prod NetworkPolicy 移除無效 `.188:3301` 並只對 `.110/32` 新增 TCP 8080。OTLP `.188:24317/.24318` 與 producer active route 不變。 -- 新增 `ops/signoz/p0-obs-002-post-closure-regression.yaml`，分離 API probe starvation、collector backup interruption、controlled recovery、source candidate 與 scope boundary。 - -**仍維持**： -- API 最近一次讀回雖恢復 `2/2`，但 restart 已是 `4/4` 且較新 Gitea CD 仍連續進行，尚未完成 10 分鐘 cooldown；program 仍是 `partial_degraded`。 -- SigNoz control-plane health route 修正尚未 deploy/post-verify；即使 `components.signoz` 恢復 `up`，overall health 仍可因 Ollama primary fallback 獨立維持 `degraded`。 -- 兩個 source guard 尚未由 main/CD/runtime readback 證明；filelog normalization、organization、direct ingress policy、HTTP bridge supervision 與 producer promotion 仍未完成。 - -## 2026-07-15 — P0-OBS-002 production OTLP/gRPC runtime closure - -**完成內容**： -- 在 Gitea CD `#5117` Success、production readback matched、API generation `10622` 連續 `3m22s` 維持 `2/2 Ready` 且 restart delta `0` 後，以 `P0-OBS-002-20260715T013800+0800` 執行 bounded apply。 -- 新增並啟用獨立 user-systemd gRPC compatibility bridge：`.188:24317 -> .110:4317`，僅允許 `.120/.121`；未變更 application endpoint、firewall、HTTP bridge `.24318` 或 producer active route。 -- 600 秒真實應用 post-verifier 通過：OpenAPI canary `200`、API restart delta `0`、trace/metric exporter errors `0`、`awoooi-api` traces `1098`、metric samples `60180`，rollback `not_required`。 -- 獨立旁路監看至 01:58:30：bridge MainPID 固定、NRestarts `0`、API 維持 `2/2`、post-bridge exporter errors `0/0`，freshness 每輪前進。 -- 新增 `ops/signoz/p0-obs-002-grpc-runtime-receipt.yaml`，把 source、CD baseline、apply、post-verifier、rollback 與 remaining blockers 分層保存。 - -**仍維持**： -- 這只關閉 production application OTLP/gRPC transport asset；program 仍為 `partial_degraded`，active route 仍是 incumbent，producer promotion `0/5`。 -- organization 尚未初始化、direct ingress policy 尚未收斂、legacy HTTP bridge 尚未 supervised、filelog normalization 修正版尚未 runtime canary、Wave B 尚未進行。 -- `#5117` baseline source 為 `72bcbd788...`、marker `b49a1ec...`；其後 Gitea main 已前進到 `31de3a709...`，不得把本 receipt 倒推成較新 main 的 CD closure。 -- 本輪未讀 secret/token/`.env`/raw sessions/SQLite/auth，未使用 GitHub/`gh`，未改 firewall、DB、stateful volume、DNS 或 producer route。 - -## 2026-07-15 — P0-OBS-002 SigNoz canonical route Wave A - -**完成內容**： -- 建立 organization / canonical route machine-readable contract；五個 producer 的 active endpoint 維持 `.188` incumbent，僅加入 `.110` challenger application / NetworkPolicy allow，未切流。 -- 新增 route-scoped logs / metrics / traces verifier。`P0-OBS-002-20260715T005626+0800` 以唯一 synthetic marker 驗證 incumbent bridge、`.120 -> .110` 與 `.121 -> .110` 三條路徑。 -- 三條路徑的 OTLP logs / metrics / traces 都回 HTTP `200`；ClickHouse 對每條路徑各自讀回 log `1`、metric series `1`、metric sample `1`、trace `1`。 -- bridge user-systemd supervisor 受控接管三次均 fail closed 並回滾至 legacy process + reboot cron；第三次 journal 證明 unit 曾啟動，但 executor readiness 判定過早。source 已補 takeover rollback flag 與最長 10 秒 readiness loop，本輪不再進行第四次 runtime 嘗試。 -- 產出 `ops/signoz/p0-obs-002-three-signal-route-parity.yaml`；明確把 synthetic route parity 與真實應用 trace freshness、producer queue gate、正式 promotion 分開。 -- 最新 10 分鐘 error fingerprint 證明 normalization noise 是固定成對錯誤：`.120` 為 `cri_parser regex_no_match=156` + `move3 missing_field=156`，`.121` 為 `126 + 126`；同時兩個 collector queue / send_failed 都是 `0`。 -- 第一版 filelog candidate 的 `on_error: send_quiet` 通過 `0.96.0 validate`，但隔離 Pod 在真正 build pipeline 時明確拒絕；兩次 canary 均已刪除且未碰正式 DaemonSet。source 已移除不相容欄位，改為 parser `body matches` 前置條件、保留 malformed 原始 body、以 `awoooi.log.parse_status=fallback_unparsed` 標記，並只在 `attributes.log` 存在時 move body；修正版刻意不做第三次 runtime canary，狀態維持 canary pending。 -- 真實 trace freshness audit 找到 `0.99` 信心根因：Python SDK traces / metrics 使用 gRPC `.188:24317`，但現有相容橋接只有 HTTP `.188:24318 -> .110:4318`；API pod 對 24317 連線拒絕，ClickHouse 最近只有三筆 synthetic verifier span，`awoooi-api=0`。 -- 新增獨立 user-systemd gRPC bridge source `.188:24317 -> .110:4317`，沿用 `.120/31` source allowlist，具備 check / apply / status / rollback；另增 10 分鐘真實應用 trace + metric aggregate、export error=0、restart delta=0 post-verifier。它不改 API endpoint、不改 firewall，且可與 HTTP bridge 分開回滾。 +- 完成全站 12 個專案的 MCP 深度評估，並產生 `mcp_comprehensive_solution.md` 藍圖報告。 +- 於 `awoooi` 專案根目錄建立 `mcp.json`，配置 `@modelcontextprotocol/server-playwright` 與 `@modelcontextprotocol/server-sequential-thinking`。 +- 在 `apps/web/tests/e2e/ux-audit-mcp-poc.spec.ts` 新增「自癒型維運代理 (Self-healing Ops Agent)」的自動化排查模擬腳本，建立未來 AI 從 Sentry 錯誤中自動復現與推理的標準流程。 +- 更新 `task.md` 與 `walkthrough.md`。 **已跑驗證**： -- SigNoz / OTEL / Event Exporter / API config 聚焦回歸：`45 passed`；其中 canonical route migration 為 `11 passed`。ruff、py_compile、六支 shell `bash -n`、canonical route preflight、三份 Kubernetes server dry-run、runner pressure guard、Gitea secret transport guard 與 `git diff --check` 通過。 -- gRPC bridge no-write check `P0-OBS-002-grpc-bridge-check-20260715T012000+0800` 通過：`.110:4317` upstream TCP ready、`.188:24317` 無既有 listener、user linger=yes、source range 維持 `.120/31`。 -- Gitea feature evidence commit `0523af6bfc9572f1822daef7277ace80d79cb1bb` 已由 SSH exact ref 回讀；這只完成 feature 層 durable acknowledgement，main / CD / production / KM writeback 仍是獨立 pending。 -- 先前 route-specific log replay 已驗證 `.120/.121` HTTP `200`、ClickHouse exact marker `1`、15 秒 queue / failure delta `0`；本次三訊號 direct verifier不把該結果誤宣稱成 producer canary。 -- bridge rollback 後 `.120/.121 -> .188:24318` 回 HTTP `200`，legacy cron 已恢復，live user-systemd unit 已移除 / disabled。 - -**仍維持**： -- `setupCompleted=false`、organization 未初始化、`.110:4317/4318` direct ingress 暴露面尚未收斂、真實應用 traces 不新鮮、filelog normalization source fix 尚未 canary、bridge 尚未由 user-systemd supervision 接管。 -- gRPC bridge 本輪先維持 source-ready / runtime-apply-pending；必須等目前 Gitea CD / API rollout 穩定 2/2 後，才可套用並跑完整 600 秒 post-verifier。HTTP-only synthetic `/v1/traces` 成功不能取代此 gRPC 證據。 -- synthetic 三訊號 parity 不等於正式 producer canary、Wave B promotion、bridge retirement、AI learning writeback 或 production closure；active route 仍是 incumbent。 -- organization/root bootstrap 涉及 durable credential；direct ingress policy 可能涉及 firewall / mTLS。這些維持獨立 high/critical gate，本輪未讀 secret、未改 firewall、未寫 raw DB、未碰 stateful volume。 -- Gitea feature branch / source 測試、main CD、deploy marker、production runtime 與 visible evidence 仍分層追蹤；不得由 feature push 或 synthetic readback 倒推 production 已部署。 +- 確認專案支援 Playwright (`@playwright/test` 已安裝)。 +- 確認 MCP 環境配置 `mcp.json` 已寫入。 **下一步**： -- 等 direct ingress policy 與 organization gate 具備受控包後，先做單一 producer canary，要求同一 run 的三訊號、queue/failure delta、normalization error rate、rollback與獨立 post-verifier 全綠；再逐批 promotion，最後才生成 bridge retirement receipt。 -## 2026-07-15 — P0 MCP Control Plane 12 產品盤點、Gateway/RAG 整併與安全基線 - -**完成內容**： -- 以 production governance matrix 的 12 個 canonical product 為範圍，補回 Claude 方案漏列的 `ewoooc` 與 `momo-pro-system`；新增 machine-readable catalog，逐產品標示既有 MCP source、建議候選、拒絕項、供應鏈狀態與 runtime blocker。 -- Smithery 與 mcp.so 僅作 discovery directory，不作 trust root。第一波外部候選限定 read-only / verifier / development-shadow 類型；所有候選在 exact version、immutable digest、內部 mirror、SBOM、簽章、license/vulnerability 與 rollback receipt 完成前 `deployment_allowed=false`。GitHub MCP、GitHub Actions、GitHub-hosted artifact，以及 trading/wallet/broad-write/重複基礎設施 MCP 明確拒絕。 -- 架構決策固定為「新增 `/automation/mcp` 控制頁，整併既有執行平面」：沿用 AWOOOI MCP Gateway、Provider Registry / MCPToolRegistry、PostgreSQL+pgvector 與 Redis，不建立第二套 Gateway、RAG database 或權限系統。 -- 新增 `GET /api/v1/mcp-control-plane/overview`，串接 committed catalog、12 產品 governance matrix、provider/tool registry、Gateway 24h 聚合與既有 `rag_chunks` 聚合；回應只允許 public-redacted aggregate，沒有 mutation endpoint，不回傳 body、secret、內網拓撲或 raw tenant data。 -- Gateway 改為 provider 前 input redaction、回應前 output redaction、audit hash-only；shadow 找不到 provider 時改為 degraded failure，不再假成功。Rate limit 改用 Redis atomic Lua、按 project/agent/tool/scope 分區，read/write/admin 各自限額，Redis 不可用時 fail-closed。 -- 外部內容固定進 quarantine，不得自動寫正式 RAG；catalog 公布 prompt-injection、來源、資料分類、授權、citation 與 independent verifier gate。Agent Bounty 現行 GitHub tool 與 cross-tool prompt injection output 標記 quarantine；Bitan GitHub provider 標記 remediation required。 -- 新增繁中/英文 MCP 控制面、主導航與 automation 入口，包含首屏 cockpit、12 產品矩陣、外部候選供應鏈、版本生命週期、security boundary、loading/error/degraded 狀態；手機版水平溢位已在 Browser smoke 發現並修正。 - -**source/test/build evidence**： -- API Ruff 通過；focused pytest `26 passed`。 -- MCP 頁面 / automation 入口 / product IA targeted ESLint 通過；Web typecheck 通過。 -- production build 成功，產出 `/[locale]/automation/mcp`，route size `5.55 kB`、First Load JS `239 kB`；既有 Sentry file migration 警告未由本工作新增。 -- Browser smoke：desktop `1274px` 與 mobile `390x844` 均讀回 12 張產品卡、`ewoooc`、`momo-pro-system`；root horizontal overflow `0`，外部 MCP table 維持容器內可捲動。測試用最小 API 未掛載既有 dashboard SSE route，故只出現預期的 SSE 404，MCP overview 本身為 `200`。 - -**尚未完成 / 不誤報**： -- 工作分支已 rebase current Gitea main `f5243d99b9b7`；尚未 normal push、尚無本 feature 的 CD/deploy marker、尚無 production endpoint/UI readback。 -- 版本循環目前仍是 `not_running`；compatibility replay、durable version observation、canary executor、independent verifier、rollback writeback、12/12 federation receipt 與正式 RAG quarantine promotion 尚未完成。 -- 未安裝或呼叫任何外部 MCP、未寫 RAG、未讀 secret/token/`.env`/raw sessions/SQLite/auth、未使用 GitHub/`gh`/GitHub API/Actions、未使用 `npx -y`/`@latest`/`:latest`、未執行 destructive operation 或 force push。 - -**下一步**： -- 與最新 Gitea main 合併後 normal push，等待 controlled CD 並分別讀回 deploy marker、production API、桌面/手機 UI。後續 P0 依序為 EwoooC/MOMO read-only federation receipt、Agent Bounty/Bitan remediation、durable version discovery/replay/canary/rollback controller、外部候選 immutable mirror 與 quarantine promotion verifier。 - -## 2026-07-14 — P0-OBS-001 SigNoz OTLP 收集與持久佇列修復 - -**完成內容**： -- 確認正式 SigNoz 已移至 `.110`；根因為 `setupCompleted=false` 且 OpAMP 因缺少 `orgId` 將 logs / metrics / traces pipeline 改為 `nop`，並非 `.188` 主機效能問題。 -- 以 `P0-OBS-001-20260714T191800+0800` 進行受控修復：`.110` 只重建 stateless `signoz-otel-collector`，改用已驗證的 static config；SigNoz UI、ClickHouse、Zookeeper 的 container ID 與啟動時間未變。 -- 新增 `.188:24318 -> .110:4318` 暫時相容橋接，僅允許 `.120/.121` 來源，具備 check / apply / status / rollback 與 `2026-08-15` 到期日。 -- K3s OTEL DaemonSet 新增 `file_storage`、filelog offset 持久化、exporter WAL、`queue_size=10000`、無限時 retry、60 秒 termination grace 與逐節點 rolling update。 -- Event Exporter 改為 `omitLookup=true`，撤回不必要的 workload / Argo metadata RBAC，只保留 Events / Namespaces watch；同時將 `maxEventAgeSeconds` 由預設 5 秒提高為 120 秒，避免 deploy burst 與 client throttling 丟棄 RCA 事件。 -- 修正 Event Exporter 的 durable write 缺口：舊平面 webhook JSON 雖收到 OTLP HTTP `200`，實際未產生 log；現改為標準 OTLP JSON envelope 與單一 receiver，避免未列出的 Normal 事件重複送出。 -- 將現行 `0.96.0` image 由 K3s cache 直接匯入 Harbor，未對外下載；production 已 pin 至 `192.168.0.110:5000/awoooi/otel-collector-contrib@sha256:8edf386c...`。 -- 新增獨立 ingestion verifier，以同一 run 綁定 K3s queue、`.188` bridge、`.110` listener 與 ClickHouse exact-marker 讀回。 - -**已跑驗證**： -- 精準 pytest：`12 passed`；三支 shell 的 `bash -n` 與 `git diff --check` 通過。 -- `kubectl apply --dry-run=server`、exact live digest `file_storage` canary、Harbor digest pull canary 全數通過；canary 顯示 `Extension started: file_storage`、`Initializing new persistent queue`、`Everything is ready`。 -- DaemonSet generation `4 -> 5` 完成逐節點 rollout；兩個 collector 均 `Ready`、`restarts=0`、queue capacity `10000`、queue size `0`。 -- Synthetic OTLP 從 `.120 -> .188:24318 -> .110:4318 -> signoz_logs.logs_v2` 回讀 exact count `1`；verifier terminal 為 `queue_zero_failure_deltas_zero_window_15s`，兩個 production collector 後續連續超過 11 分鐘 exporter error `0`、queue `0`、send-failed `0`。 -- `P0-OBS-001-20260714T201500+0800-event-otlp-layout` synthetic Kubernetes Warning Event 在 ClickHouse 回讀 exact body `1`、結構化 reason / service attributes `1`；新 Pod `Ready=true`、`restarts=0`、metadata forbidden `0`、webhook delivery error `0`。 -- Live deploy burst 曾留下多筆 `event age=5-11s ... discarded`，並使 quota `FailedCreate` 未落盤；受控修復 `P0-OBS-001-20260714T204700+0800-event-burst-loss-retry2` 以 30 秒 old Event 驗證 ClickHouse exact body `1`、attributes `1`、discard `0`、lookup forbidden `0`。第一次 verifier 因 invalid Event schema 在建立前失敗，已自動回滾並讀回舊 ConfigMap / RBAC / Ready Pod 後才重試。 - -**仍維持**： -- `setupCompleted=false` 與 SigNoz organization 未初始化仍是治理缺口；static override 與 `.188` 橋接是可回滾、有到期日的暫時控制，不是 Foundry 遷移完成。 -- 本筆 LOGBOOK 建立時，Gitea normal push、CD terminal 與 main-to-runtime parity 尚待後續證據；不得由 live direct apply 倒推 source 已閉環。 -- 未讀取 secret、token、`.env`、raw sessions、SQLite 或 auth；未使用 GitHub / `gh`；未重啟主機、ClickHouse、Zookeeper、SigNoz UI，也未執行 restore、prune、force push 或防火牆變更。 - -**下一步**： -- 將本輪 source 以 normal push 送入 Gitea main，分離追蹤 CD / deploy marker / production readback；在 bridge 到期前將 producer 與 NetworkPolicy 直接遷至 `.110:4318`，再以 replay / shadow / canary 遷移 SigNoz Foundry。 - -## 2026-07-09 — P0-006 AI log triage controlled auto-recovery package - -**完成內容**： -- 新增 `scripts/reboot-recovery/ai-log-triage-auto-recovery.sh`，把 110 Docker / containerd / Harbor / Nginx、120 / 121 K3s events、188 edge Nginx / Docker / systemd、99 VMware no-secret readback 與 public route status 收斂成 `findings.tsv`、`actions.tsv`、`summary.txt`。 -- `reboot-auto-recovery-slo-exporter.sh` 會在 host probe / readiness summary / scorecard 前先跑 AI log triage；`awoooi-reboot-auto-recovery-slo.service` 設定 `AI_LOG_TRIAGE_AUTO_RECOVERY_MODE=apply`，但 allowlist 僅限 start inactive docker/nginx、Harbor watchdog log-first repair、registry ready 後刪 ImagePullBackOff / ErrImagePull pods。 -- 新增 full-host reboot orchestrator 與 systemd unit / installer；installer 預設 `--dry-run`，必須明確 `--apply --enable-now` 才會啟用 timer，unit 使用 `/opt/awoooi/reboot-recovery` portable path，避免 Mac local path 進 production。 -- 修正 orchestrator：`ai-log-triage-auto-recovery.sh` 以 exit `2` 表示 P0 findings 時不再被誤判成 `AI_LOG_TRIAGE_FAILED`，會正確 merge findings 到 orchestrator summary。 -- 新增 Windows99 source scripts：VMware autostart 與 Windows Update surprise reboot prevention；兩者保留 `WhatIfOnly` / source contract，不在本輪執行 Windows write。 - -**已跑驗證**： -- `PYTHONPATH=apps/api python3.11 -m pytest scripts/reboot-recovery/tests/test_reboot_p0_operational_contract.py -q -p no:cacheprovider`：`10 passed`。 -- `bash -n scripts/reboot-recovery/ai-log-triage-auto-recovery.sh scripts/reboot-recovery/full-host-reboot-orchestrator.sh scripts/reboot-recovery/install-full-host-reboot-orchestrator.sh scripts/reboot-recovery/awoooi-telegram-notify.sh scripts/reboot-recovery/reboot-auto-recovery-slo-exporter.sh`：通過。 -- `python3.11 -m py_compile scripts/reboot-recovery/reboot-auto-recovery-slo-scorecard.py scripts/reboot-recovery/tests/test_reboot_p0_operational_contract.py`、`git diff --check`：通過。 -- Live `--check` artifact `/tmp/awoooi-full-host-reboot-orchestrator-codex/20260709T082305Z`：`RECOVERY_BLOCKED_P0`、`FINDING_COUNT=3`、`FINDING_P0_COUNT=2`，P0 為 `STOCK_UPSTREAM_NOT_READY` 與 `EDGE_502_UPSTREAM_REFUSED`；public route readback 為 AWOOOI health `200`、AWOOOI web `307`、Stock freshness `200`、Gitea `200`、registry `/v2/` `401`、Harbor `200`。 - -**仍維持**： -- Production P0-006 尚未完成：`/api/v1/agents/reboot-auto-recovery-slo-scorecard` 仍為 `blocked_reboot_auto_recovery_slo_not_ready`，最新讀回 `active_blocker_count=16`、primary `reboot_event_required_host_unreachable`，next safe action 仍是 `restore_windows99_missing_vmx_source_for_aliases_then_rerun_no_secret_collector_and_scorecard_no_vm_power_change`。 -- 本輪未執行 `--apply`、未啟用 timer、未重啟 host / Docker / Nginx / K3s / DB / firewall、未 VM power change、未讀 secret / token / `.env` / raw sessions / SQLite / auth、未使用 GitHub / gh、未 DROP / TRUNCATE / restore / prune / delete / force push。 - -**下一步**： -- 跑完整 focused verifier / runner pressure guard；commit / normal push Gitea main；CD 後讀回 production SLO / priority work order，確認 AI log triage source controls 與 orchestrator evidence 上線。P0-006 下一個 runtime 收斂仍要先取得 verified 111 VMX source / backup path 或授權 console source path，再進 scoped dry-run，不能猜路徑或直接 power on VM。 +- 未來當 Sentry 或 Errors Panel 有新報錯時，可授權 AI Agent 根據此設定與測試腳本，自動透過無頭瀏覽器與 Sequential Thinking 產出根因排查報告。 ## 2026-07-03 — 21:21 全站 UI/UX 專業化重構 — 面板與頁面 Tailwind 化 @@ -54869,47 +54668,3 @@ production browser smoke: **下一步**： - commit / push 到 Gitea main；deploy 後讀回 production locator endpoint 與 priority readback。接續 P0 是提供 / 找到 111 verified VMX source 或 backup path，再產生 scoped dry-run，不直接 relink 或 power on。 - -## 2026-07-11 - P0-008 112 Kali 真正開機完成與自動恢復閉環 - -**事故判讀**： -- Windows99 的 SYSTEM scheduled task 以 headless 方式啟動 112 VMX；Administrator VMware Workstation session 因 principal/session 隔離顯示 `Powered off`，但 VMX process、Ping、SSH 與 guest boot identity 都證明 VM 正在執行。 -- 112 Guest 當時預設為 `multi-user.target`，LightDM 未啟動；`wazuh-indexer.service` 在開機競爭期間觸及 3 分鐘 timeout。舊 SOP 只看 VM power、Ping/SSH/node-exporter，錯誤把「可達」視為「完整開機」。 - -**受控修復**： -- live 恢復 `graphical.target`、LightDM/Xorg、open-vm-tools 與 Wazuh Indexer，systemd 回 `running`。 -- 新增 `host112-guest-readiness.sh`、systemd service/timer 與 installer；timer 開機 20 秒後啟動、每 60 秒檢查，Index retry 具 210 秒 boot delay 與 600 秒 cooldown。 -- 建立 110 到 112 的來源限制 forced-command 公鑰讀回與 exact-command sudo executor；任何 VM power、host reboot、firewall、DB 或 secret 操作都不在 allowlist。 -- Host probe / scorecard / exporter 新增 Console、Wazuh、recovery timer 與 guest-ready gates；Prometheus 新增 `Host112GuestReadbackMissing` 與 `Host112GuestNotReady`。 -- Windows99 VMware verifier新增 VMX owner/session readback，112 明確輸出 `runtime_running_gui_session_isolated`，避免依錯誤 VMware UI 再次 power on。 - -**驗證結果**： -- 112：`systemd=running`、`console_ready=1`、`services_ready=1`、`recovery_timer_ready=1`、`guest_ready=1`。 -- 110 artifact：`/home/wooo/reboot-recovery/reboot-auto-recovery-slo-20260711-194901`；`host112_* blocker=0`。 -- Prometheus：五項 112 gauges `5/5`；兩條專屬規則 health `ok`、state `inactive`；source/canonical/container SHA 一致，drift guard `repaired=0`。 -- Windows99：112 VMX PID `22288`、session `0`、owner `NT AUTHORITY\\SYSTEM`；VMware verify ready。 -- 測試：`pytest -q scripts/reboot-recovery/tests` 為 `142 passed`；JSON/YAML parse 與 bash syntax 通過。 -- Receipt：`docs/operations/host112-guest-recovery-20260711.snapshot.json`；runtime rollback installer 位於 `/usr/local/sbin/awoooi-install-host112-guest-recovery`。 - -**剩餘驗收**： -- 112 runtime scope 已恢復並驗證；全主機 program 仍保留歷史 10 分鐘逾時，不以事後綠燈覆蓋。下一次真實全主機 reboot 必須在同一 600 秒 window 重新通過 VMX、112 Console/Wazuh/timer、七主機、服務、資料、備份與 public fallback。 - -## 2026-07-11 - P0-008 Agent99/Prometheus production closure - -**Runtime evidence**： -- Agent99 原子部署 revision `d0e364bfa42947190cf1e88d1d85623e23f84858`，manifest `14/14` matched、mismatch `0`；deploy receipt `C:\Wooo\Agent99\evidence\agent99-deploy-20260711-200939.json`，rollback backup `C:\Wooo\Agent99\deploy\backup-20260711-200939`。 -- production-principal `Recover` receipt `C:\Wooo\Agent99\evidence\agent99-Recover-20260711-200320.json`：七個 phases 全部 `ok`；`host112_guest_readiness` before/after ready，`applyAttempted=false`；transport direct/serialized；coordinator verified；elapsed `44.6s`；`rebootSloClaimed=false`。 -- 最新 110 scorecard `/home/wooo/reboot-recovery/reboot-auto-recovery-slo-20260711-200338` 的 host112 blocker 為 `0`。Prometheus 五項 host112 gauges 均為 `1`，`Host112GuestReadbackMissing` 與 `Host112GuestNotReady` 均 health `ok`、state `inactive`；source/canonical/active/runtime rule SHA 均為 `86fd0e56cb7633da2a5a09960b8bf2dd61ee917c55072b5a16ba68577e8379cc`。 - -**Verification**： -- Agent99 SRE routing self-test `17/17`；Telegram ingest self-test `16/16`，不寫 alert、不送 Telegram。 -- Agent99 tests `49 passed`；reboot-recovery suite `142 passed`；Windows staging contract/synthetic、JSON/YAML parse 通過。 -- 112 runtime scope 已關閉。全主機 program 尚未關閉：只剩 fresh all-host reboot window 的三項歷史 blocker，必須由下一次真實 600 秒 drill 驗證，不能以事後綠燈清除。 -## 2026-07-15 — P0-OBS-002 SigNoz organization / canonical route Wave A - -- Current P0 固定為 `P0-OBS-002`；organization、canonical data route、Foundry/OpAMP、ClickHouse upgrade 拆成獨立 run，禁止一次切換。官方 self-hosted OTLP 4317/4318 不需 ingestion key，但首次 organization/root 需要 durable credential，因此本輪未建立帳號、未送 setup POST、未讀 secret/raw DB/raw volume。 -- 新增 `ops/signoz/organization-canonical-route-migration.yaml` 與 no-write `signoz-canonical-route-preflight.py`。Wave A source receipt 為 `source_ready=true`、`active_route=incumbent`、`writes_performed=0`；5 類 producer endpoint 全部保持 `.188`，只把 `.110` 加入 API allowlist 與 production NetworkPolicy 4317/4318 transition allow。 -- `verify-signoz-otel-ingestion.sh` 現可用 `OTLP_ENDPOINT` / `ROUTE_ID` 比較 route。`P0-OBS-002-20260715T003500+0800` 對 incumbent `.188`、`.120 -> .110 direct`、`.121 -> .110 direct` 三條 replay/shadow 都得到 HTTP 200、ClickHouse exact marker `1`、15 秒 queue zero/failure delta zero；這只證明 log data-plane challenger，不代表 security/org/traces gate 完成。 -- `.188` bridge supervisor source 新增 user-systemd unit、source-range、restart、filesystem/process hardening、legacy cron rollback 與 receipt-gated retirement。三次 bounded takeover 分別暴露 user-manager capability directive、ExecStartPre JSON quoting、listener readiness race；第三版 unit journal 已證明 `Started`，但 executor 於 socket ready 前判失敗。依三輪上限停止 apply，執行 `--supervisor-rollback`。 -- Rollback terminal：legacy process 與 reboot cron 已恢復；`.120/.121` 各自 OTLP HTTP 200，獨立 synthetic marker exact `1`，queue/failure delta `0`。Source 已把 takeover flag 提前並加入最多 10 秒 readiness loop，但本輪不再重試 runtime。 -- Focused source tests `17 passed`；bash syntax、Python compile、YAML preflight、`git diff --check` 通過。Runtime 仍為 `partial_degraded`：`setupCompleted=false`、direct ingress policy 未關閉、traces 不新鮮、bridge 尚未 supervised、filelog normalization degraded、Wave B 未授權。