Gitea 清冊負責人證明補件草稿
| 項目 |
內容 |
| 日期 |
2026-06-04 |
| 狀態 |
草稿與送件前交接包已整理,尚未送出 |
| 對應階段 |
S4.9 |
| 對應收件包 |
docs/security/GITEA-INVENTORY-OWNER-ATTESTATION-RESPONSE.md |
| 快照 |
docs/security/gitea-inventory-owner-attestation-request-draft.snapshot.json |
| 模式 |
owner_request_draft_only |
| 執行面授權 |
false |
1. 草稿目的
此草稿把 S4.9 需要負責人補齊的五項 Gitea 清冊證明整理成可交付內容。它只用於人工判讀與後續送件準備,不代表已送出請求、不代表已收到回覆,也不代表任何 Gitea / GitHub / refs / workflow / secret / Kali 執行授權。
2. 五個補件題目
| 順序 |
Template |
負責人需要回覆 |
目前狀態 |
| 1 |
response-public-only-vs-local-gitea-gap |
wooo/clawbot-v5、wooo/wooo-aiops 是否屬本輪 inventory / migration scope |
草稿完成,未送出 |
| 2 |
response-org-user-endpoint-identity |
wooo 在 Gitea 中應以 user、org 或兩者盤點 |
草稿完成,未送出 |
| 3 |
response-internal-110-adjacent-scope |
bitan-pharmacy、root/momo-pro-system、tsenyang-website、wooo/wooo-infra-config 是否納入本輪 scope |
草稿完成,未送出 |
| 4 |
response-repo-owner-canonical-scope |
in-scope repo 的 owner、canonical source、GitHub target candidate 與 visibility review owner |
草稿完成,未送出 |
| 5 |
response-legacy-or-inaccessible-disposition |
legacy、inaccessible 或 external repo 的 disposition、理由與後續 owner |
草稿完成,未送出 |
3. 回覆格式
每一題都只接受下列欄位:
owner_role_or_team
decision
decision_reason
affected_repos、affected_sources 或 canonical_namespace
evidence_refs
followup_owner
evidence_refs 只能指向 repo 內文件、snapshot 或負責人提供的脫敏 metadata。若資料可能包含 token、secret、private key、cookie、session、DB dump、git object pack 或 repo archive,必須改用 quarantine pointer,不得貼原文。
4. 明確禁止
- 不收 token、PAT、webhook secret、repository secret value、runner registration token 或 deploy key private key。
- 不收 DB dump、repo archive、git object pack、裸 repo tarball 或可還原憑證的 artifact。
- 不建立、不刪除、不封存、不修改 Gitea repo。
- 不建立 GitHub repo、不改 visibility、不同步 refs、不刪 refs、不 force push。
- 不切 GitHub primary、不停用 Gitea、不啟用 GitHub hosted runner。
- 不啟動 Kali、SSH、掃描、主機更新、修復或部署。
5. 目前狀態
| 指標 |
值 |
| request draft package |
ready |
| request draft template count |
5 |
| request sent |
false |
| request sent count |
0 |
| recipients confirmed count |
0 |
| owner response received count |
0 |
| owner response accepted count |
0 |
| runtime gate opened |
false |
| action buttons allowed |
false |
6. 2026-06-04 送件前交接包
本段把五題補件草稿提升成可交接的人工送件封套。它只代表 reviewer / AwoooP operator 可以照表核對送件內容,不代表已送出請求、不代表收件對象已確認、不代表收到 owner response,也不代表任何 repo、refs、workflow、secret、GitHub primary、Kali、主機維護或 runtime execution 授權。
| 指標 |
值 |
| dispatch preflight package |
ready |
| dispatch preflight completion |
100% |
| dispatch authorized |
false |
| request sent |
false |
| request sent count |
0 |
| recipients confirmed count |
0 |
| owner response received count |
0 |
| owner response accepted count |
0 |
| runtime gate opened |
false |
6.1 送件前檢查
| 順序 |
檢查項 |
完成條件 |
目前狀態 |
| 1 |
同步基線 |
送件前先確認 gitea/main 與另一個 AwoooP Session 最新 commit,不使用舊 refs / 舊 deploy marker |
已定義,未送件 |
| 2 |
題目版本 |
五題 template id、必填欄位與收件包版本需一致 |
已定義,未送件 |
| 3 |
收件角色 |
收件對象只記錄 role / team,不收個人敏感資料或憑證 |
已定義,未送件 |
| 4 |
證據參照 |
僅附 repo 內文件、snapshot、ticket id、hash 或脫敏 metadata ref |
已定義,未送件 |
| 5 |
禁止條款 |
明確標示此包不是 approval、不是 execution、不是 source-control mutation |
已定義,未送件 |
| 6 |
稽核紀錄 |
只有實際送件後才可記錄 request shown metadata;不得預填已送出 |
已定義,未送件 |
| 7 |
計數不變 |
無實際送件證據前,request_sent_count、received、accepted、rejected 全部維持 0 |
已定義,未送件 |
6.2 交接封套欄位
| 欄位 |
內容規則 |
request_id |
固定對應 S4.9 Gitea owner attestation request,不建立新的 runtime action id |
stage_id |
固定 S4.9 |
requested_templates |
只能引用本文件第 2 節五個 template id |
recipient_role_or_team |
只填 role / team;不得填 token、PAT、cookie、session 或私人聯絡資訊 |
sender_role_or_team |
只填送件操作角色;不得把 AwoooP approval 視為資安批准 |
requested_response_deadline_or_window |
可填人工約定窗口;空值不得阻擋 0 / false gate |
allowed_response_format |
只接受本文件第 3 節欄位與脫敏 evidence refs |
redacted_evidence_refs |
僅指向既有文件、snapshot、ticket id、hash 或 quarantine pointer |
forbidden_payloads |
secrets、repo archive、DB dump、runner token、deploy key private key、git object pack 全部拒收 |
followup_owner |
只記後續補證 role / team |
not_approval |
必須為 true |
6.3 送件後不變條件
即使後續有人實際送出此請求,也只能在有可稽核的人工送件 metadata 後,把 request_sent_count 從 0 調整為真實數字;不得同時把 owner response received / accepted / rejected 拉高。收到回覆後仍需經過 S4.9 response preflight、敏感材料隔離、跨包一致性檢查與 reviewer 驗收,才能更新對應 read-only matrix。任何 GitHub primary、repo / refs / workflow / secret、Kali、SSH、主機維護或 runtime gate 都必須另走人工批准與 rollback / post-check。