Merge remote-tracking branch 'gitea/main' into codex/security-supply-chain-contracts-20260512

This commit is contained in:
Your Name
2026-05-13 19:45:50 +08:00
3 changed files with 122 additions and 3 deletions

View File

@@ -834,11 +834,15 @@ jobs:
# 感知層與備份通知都先走 AWOOI API/AwoooPTelegram 直發只保留 API 離線 fallback。
- name: Sync Ops Scripts to 188
continue-on-error: true
env:
SSH_KEY_188: ${{ secrets.DEPLOY_SSH_KEY_188 }}
run: |
mkdir -p ~/.ssh
echo "$SSH_KEY_188" > "${HOME}/.ssh/deploy_key_188"
# 2026-05-13 Codex: do not pass multiline deploy keys through
# step-level env; Gitea Actions prints env values in job logs.
# Keep the secret scoped to this shell and write it directly to disk.
cat > "${HOME}/.ssh/deploy_key_188" <<'DEPLOY_KEY_188'
${{ secrets.DEPLOY_SSH_KEY_188 }}
DEPLOY_KEY_188
sed -i 's/^ //' "${HOME}/.ssh/deploy_key_188"
chmod 600 "${HOME}/.ssh/deploy_key_188"
timeout -k 5s 10s ssh-keyscan 192.168.0.188 >> ~/.ssh/known_hosts 2>/dev/null \
|| echo "⚠️ 188 host key scan 失敗,改用 StrictHostKeyChecking=accept-new"

View File

@@ -8344,3 +8344,104 @@ verified_evidence_24h=0
- production smoke 尚未出現部署後新的 auto-approved 或 auto-repair live event因此仍不能宣稱完整閉環已被 production live-fire 證明。
- 下一步 T14c用安全 live-fire 或等待自然告警,驗證 `auto_approve_* -> auto_repair_executions -> incident_evidence.verification_result -> learning/KM -> truth-chain auto_repaired_verified` 實際打通;並把 Telegram 卡片改成明確顯示「目前跑到哪個節點 / 是否已自動修復 / 是否轉人工」。
- 目前整體進度更新:約 82%。
### 2026-05-13 — AwoooP truth-chain T14cTelegram 主卡顯示流程進度production deployed
**背景**
- Telegram 主卡已顯示「AI 自動化鏈路」,但那是靜態 flow 字串,值班者仍無法一眼知道:
- 是否真的有 `auto_repair_executions`
- 是否有 post-execution verifier
- 是否有 KM / MCP evidence
- 目前是等待審批、已自動執行、還是轉人工
- 本階段不發真實 Telegram 測試卡,避免洗版;用單元測試與 production deploy smoke 驗證格式/部署。
**變更**
- `TelegramMessage` 新增 `automation_quality` 摘要欄位,接 truth-chain `automation_quality`
- `send_approval_card()``incident_id` 時,嘗試讀取 `fetch_truth_chain(...).automation_quality`,失敗不阻斷送訊。
- ACTION REQUIRED 主卡新增「流程進度」區塊:
- 收件 / 診斷
- 匹配 / 執行
- 驗證 / KM / MCP
- truth-chain 判定與人類可讀結論
- `處置狀態` 也會根據 truth-chain 更新:
- `auto_repaired_verified``已驗證自動修復完成`
- 有執行紀錄但缺 verifier → `已自動執行,等待驗證證據`
- `approval_required``需要審批後才會執行`
- `manual_required*``未自動修復,需人工判斷`
**local verification**
```text
python3 -m py_compile apps/api/src/services/telegram_gateway.py apps/api/tests/test_telegram_ai_automation_block.py
OK
ruff check --select F821 apps/api/src/services/telegram_gateway.py apps/api/tests/test_telegram_ai_automation_block.py
OK
pytest tests/test_telegram_ai_automation_block.py tests/test_telegram_message_templates.py tests/test_telegram_integration.py tests/test_telegram_adr050.py -q
81 passed
```
**production deploy / smoke完成**
```text
Commit: 74c47672 feat(telegram): show automation flow progress
Gitea:
2070 code-review 74c47672 -> success
2069 CD Pipeline 74c47672 -> success
tests -> success
build-and-deploy -> success
post-deploy-checks -> success
Deploy marker: 2f5d8126 chore(cd): deploy 74c4767 [skip ci]
K8s image:
awoooi-api 192.168.0.110:5000/awoooi/api:74c47672da3d61dc649d118e9a95579b597ef848
awoooi-worker 192.168.0.110:5000/awoooi/api:74c47672da3d61dc649d118e9a95579b597ef848
awoooi-web 192.168.0.110:5000/awoooi/web:74c47672da3d61dc649d118e9a95579b597ef848
health:
https://awoooi.wooo.work/api/v1/health -> 200
quality summary, hours=24, limit=30:
verified_auto_repair_total=0
production_claim.can_claim_full_auto_repair=false
by_verdict:
manual_required_no_action=17
received_only=11
approval_required=1
execution_unverified=1
```
判讀:
- T14c 已完成並推版:新 Telegram ACTION REQUIRED 卡會把 truth-chain 的執行/驗證/KM/MCP/判定顯示在首屏,不再只有靜態流程字串。
- 仍不能宣稱完整 AI 自動修復閉環;目前 aggregate 仍是 `verified_auto_repair_total=0`
- 新觀察CD job log 會在 step env 區塊顯示 188 deploy key 內容。未在本文件記錄任何 secret 值,但必須列為下一個 P0輪換 188 deploy key並改造 workflow避免 multiline secret 以 env 形式出現在 Gitea Actions logs。
- 目前整體進度更新:約 84%。
### 2026-05-13 — T14d/P0Gitea CD 188 deploy key log exposure 止血workflow pushed
**觸發**
- T14c CD log 觀察到 `Sync Ops Scripts to 188` step 會在 Gitea Actions 的 step env 區塊顯示 188 deploy key 內容。
- 未在 repo 或本文件保存任何 secret 值;但已經出現在 CI log必須視為已暴露。
**止血變更**
- `.gitea/workflows/cd.yaml` 移除 `SSH_KEY_188` step-level env。
- 改在 shell 內直接寫入 `~/.ssh/deploy_key_188`,避免 multiline deploy key 以 env 形式進入 Gitea Actions log 的 env 區塊。
**verification**
```text
ruby -e 'require "yaml"; YAML.load_file(".gitea/workflows/cd.yaml"); puts "yaml ok"'
yaml ok
```
判讀:
- 這是 workflow-level 止血,不等於完成安全事件處置。
- 下一步仍需輪換 188 deploy key清理/限制歷史 job log 可見性,並用一次受控 workflow_dispatch 確認新 workflow 不再暴露 secret。
- 目前整體進度更新:約 85%。

View File

@@ -2048,6 +2048,20 @@ Phase 6 完成後
- Smokequality summary 仍為 `verified_auto_repair_total=0``production_claim=false`deploy 後尚無新 auto-approved 或 auto-repair live event`auto_repair_since_deploy=0``auto_approved_since_deploy=0``verified_evidence_since_deploy=0`),所以仍不能宣稱完整閉環已 production live-fire verified。
- 下一步 T14c用安全 live-fire 或等待自然告警驗證 `auto_approve_* -> auto_repair_executions -> incident_evidence.verification_result -> learning/KM -> truth-chain auto_repaired_verified`;並把 Telegram 卡片改為明確顯示流程節點、是否自動修復、是否轉人工。
**T14c Telegram flow progress production deployed2026-05-13 台北)**
- 觸發Telegram ACTION REQUIRED 主卡雖然已有「AI 自動化鏈路」,但只是靜態 flow 字串;值班者仍無法從卡片判斷是否有 `auto_repair_executions`、verifier、KM、MCP evidence或目前是否等待審批 / 已自動執行 / 轉人工。
- 修正:`TelegramMessage` 新增 `automation_quality``send_approval_card()``incident_id` 時讀取 `fetch_truth_chain(...).automation_quality`;主卡新增「流程進度」區塊,顯示收件/診斷、匹配/執行、驗證/KM/MCP、truth-chain 判定與人類可讀結論。truth-chain fetch 失敗不阻斷送訊。
- Production`74c47672 feat(telegram): show automation flow progress` 已推 Gitea mainGitea run `2070` code-review success、run `2069` tests/build-and-deploy/post-deploy-checks 全 successdeploy marker `2f5d8126`API/Worker image `192.168.0.110:5000/awoooi/api:74c47672da3d61dc649d118e9a95579b597ef848`Web image `192.168.0.110:5000/awoooi/web:74c47672da3d61dc649d118e9a95579b597ef848`health 200。
- Smoke為避免 Telegram 洗版,本階段未發真實測試卡;以 message formatter 測試鎖住 `auto_repaired_verified` 顯示為「已驗證自動修復完成」且不再同時顯示等待人工批准。production quality summary 仍為 `verified_auto_repair_total=0``production_claim=false`
- Security noteCD job log 觀察到 188 deploy key 內容會出現在 step env 區塊;未在本文件保存 secret 值。下一步 P0 必須輪換該 deploy key並改造 workflow避免 multiline secret 以 env 形式進入 Gitea Actions logs。
- 下一步 T14d/P0先處理 CI secret log exposure再做安全 live-fire 驗證 Telegram 新卡在真實事件上的流程進度。
**T14d/P0 Gitea CD 188 deploy key log exposure stopgap2026-05-13 台北)**
- 觸發T14c CD log 觀察到 `Sync Ops Scripts to 188` step 以 step-level env 傳入 multiline 188 deploy keyGitea Actions 會在 job log 的 env 區塊顯示內容。未在 repo / docs 保存任何 secret 值,但應視為已暴露。
- 止血:`.gitea/workflows/cd.yaml` 移除 `SSH_KEY_188` step env改在 shell 內直接寫入 `~/.ssh/deploy_key_188`,避免 key 以 env 形式進入 Actions log。
- 驗證:`ruby -e 'require "yaml"; YAML.load_file(".gitea/workflows/cd.yaml"); puts "yaml ok"'` 通過。
- 邊界:這不是完整安全事件處置;仍需輪換 188 deploy key、清理/限制歷史 job log 可見性,並以受控 `workflow_dispatch` 驗證新 workflow 不再暴露 secret。
---
### 2026-04-20 晚 (台北) — C1-C4 全流程串接 — Playbook 鏈路保護commit de2d34d