awoooi/docs/security/GITHUB-TARGET-OWNER-DECISION-RESPONSE.md

# GitHub Target Owner Decision Response 收件包

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-04 |
| 狀態 | 草案與 P1-3 handoff 已整理，等待 owner response |
| 資料契約 | `docs/schemas/github_target_owner_decision_response_v1.schema.json` |
| 快照 | `docs/security/github-target-owner-decision-response.snapshot.json` |
| 來源契約 | `github_target_decision_v1` |
| 目標契約 | `github_target_repo_approval_package_v1` |
| 模式 | `owner_decision_response_intake_only` |
| 執行面授權 | `false` |

## 0. 核心結論

S4.10 補的是「owner 要怎麼回覆 7 個 GitHub target 的 owner / visibility / canonical 決策」。

S4.10 不是 repo creation approval、不是 visibility change approval、不是 refs sync approval，也不是 GitHub primary approval。它只把 owner response request packet、回覆欄位、可接受決策、驗收規則、拒收規則與允許輸出固定下來，讓 AwoooP 能只讀顯示並等待人工補證。

此文件不要求貼 token，不接受 raw secret，不建立 GitHub repo，不修改 visibility，不 sync refs，不切 primary，也不停用 Gitea。

## 1. Response 摘要

| 指標 | 值 |
|------|----|
| owner response 狀態 | `waiting_owner_response` |
| GitHub target decisions | 8 |
| 需要人工決策 targets | 7 |
| owner response request packet | 1 |
| owner response template statuses | 7 |
| owner response audit event templates | 3 |
| owner response redaction examples | 5 |
| owner response collection checks | 6 |
| intake preflight checks | 6 |
| response templates | 7 |
| 已收到 response | 0 |
| 已接受 response | 0 |
| 已拒收 response | 0 |
| acceptance checks | 8 |
| rejection rules | 10 |
| 授權建立 repo | `false` |
| 授權修改 visibility | `false` |
| 授權 sync refs | `false` |
| 授權切換 GitHub primary | `false` |
| 允許收集 secret value | `false` |
| 允許 action button | `false` |
| P1-3 handoff package | `ready` |
| request dispatch authorized | `false` |
| `not_found_or_private` 當不存在 | `false` |

## 1.0 2026-06-04 P1-3 GitHub Target Owner Handoff

本段把 S4.10 從「收件包已定義」推到「P1-3 可交接請 owner 逐項回覆」。這是 handoff readiness，不是 request sent、不是 owner response received、不是 repo 建立或 visibility 變更批准。S4.9 owner response gate 與 P1-2 Gitea authenticated inventory request handoff 仍是前置依賴；未通過前不得把 GitHub target decision 視為可執行。

| 指標 | 值 |
|------|----|
| P1-3 handoff package | ready |
| handoff completion | 100% |
| request dispatch authorized | false |
| target probe candidates | 8 |
| approval-required targets | 7 |
| external scope summary target | `nexu-io/open-design` |
| `not_found_or_private` targets | 3 |
| owner response received | 0 |
| owner response accepted | 0 |
| repo creation authorized | false |
| visibility change authorized | false |

### 1.0.1 送件前檢查

| 順序 | 檢查項 | 完成條件 | 目前狀態 |
|------|--------|----------|----------|
| 1 | 基線同步 | 送件前確認 `gitea/main`、GitHub target probe、S4.9 / P1-2 最新狀態 | 已定義，未送件 |
| 2 | 七個 target 範圍 | 只向 7 個 approval-required targets 收 owner / visibility / canonical 回覆 | 已定義，未送件 |
| 3 | external scope 摘要 | `nexu-io/open-design` 只作 external scope evidence，不納入 AWOOOI target approval queue | 已定義，未送件 |
| 4 | `not_found_or_private` 語意 | 只能表示 read-only probe 看不到；不得視為 repo 不存在或可直接建立 | 已定義，未送件 |
| 5 | 回覆欄位 | 必須有 owner role/team、decision、reason、canonical source、target disposition、visibility review owner、redacted evidence refs | 已定義，未送件 |
| 6 | 執行要求拒收 | repo creation、visibility change、refs sync、workflow / secret 修改、primary switch 全部 hard reject | 已定義，未送件 |

### 1.0.2 交接封套欄位

| 欄位 | 內容規則 |
|------|----------|
| `request_id` | `p1_3_github_target_owner_response_handoff` |
| `stage_id` | `S4.10` |
| `prerequisite_gates` | S4.9 owner response gate、P1-2 Gitea authenticated inventory request handoff |
| `requested_templates` | 只引用本文件第 3 節七個 template id |
| `target_probe_summary` | 8 個 candidates、5 個 exists、3 個 `not_found_or_private`、1 個 external scope summary |
| `recipient_role_or_team` | 只填 role / team，不收個人敏感資料或 credential |
| `required_response_fields` | owner role/team、decision、decision reason、canonical source、target disposition、visibility review owner、redacted evidence refs、followup owner |
| `forbidden_inputs` | token、secret、private key、private clone URL credential、repo archive、git object pack、API request body |
| `not_approval` | 必須為 `true` |

### 1.0.3 送件後不變條件

即使後續 owner 實際回覆，也只能先進 S4.10 intake preflight 與 reviewer validation。通過後可更新 read-only GitHub target decision table、approval package、approval board 與 readiness wording；不得直接建立 repo、修改 visibility、sync / delete refs、force push、改 workflow / secret、切 GitHub primary 或停用 Gitea。

## 1.1 Owner Response Request Packet

S4.10 request packet 只讓 AwoooP 顯示「要請 owner 回覆哪 7 個 GitHub target」。它不是 approval queue、不是 execution queue，也不得附加建立 repo、修改 visibility、sync refs 或切 GitHub primary 的按鈕。

| 欄位 | 內容 |
|------|------|
| request id | `s4_10_github_target_owner_decision_response_request` |
| 顯示狀態 | `ready_to_request_owner_response` |
| required response items | 7 |
| 顯示模式 | `display_owner_response_request_only` |
| execution authorized | `false` |
| not approval | `true` |

request packet 允許 owner 用 read-only markdown response、redacted metadata pointer、request_more_evidence 或 out_of_scope_disposition 回覆。所有 evidence 只能引用 repo 內文件、snapshot 或已脫敏 metadata pointer；`not_found_or_private` 只能代表需補證或 private access request，不能自動當成 repo 不存在或可建立。

request packet 明確拒收 token value、secret value、private key、cookie/session、private clone URL credential、repo creation command、visibility change command、write/admin API request、refs sync/delete request、force push/tag rewrite request、GitHub primary switch request、repo archive、git object pack、DB dump 與 unrelated history merge request。

## 1.2 Owner Response Template Status Ledger

S4.10 template status ledger 只讓 AwoooP 逐項顯示 7 個 GitHub target template 的收件狀態，避免只看整體 `response_template_count=7` 而漏掉單一 target 尚未回覆。

| 狀態欄位 | 值 |
|----------|----|
| collection status | `waiting_owner_response` |
| request status | `request_ready_not_sent` |
| received / accepted / rejected | `0 / 0 / 0` |
| latest outcome lane | `keep_waiting_owner_response` |
| 顯示模式 | `display_template_status_only` |
| execution authorized | `false` |
| not approval | `true` |

此 ledger 不代表 request sent、response received、response accepted 或 approval queue。任一 target 單項 response 即使未來通過，也只能更新 read-only decision table / approval package / approval board / readiness wording；不得建立 repo、修改 visibility、sync refs、delete refs、force push 或切 GitHub primary。

## 1.3 Owner Response Audit Event Templates

AwoooP 可用 `owner_response_audit_event_templates` 做未來 audit metadata 的格式參考：

| Event template | 用途 | 狀態 |
|----------------|------|------|
| `audit-github-target-response-request-shown` | 記錄 S4.10 request packet 已可顯示或已顯示的 metadata | `template_only_not_emitted` |
| `audit-github-target-response-received-metadata` | 記錄 GitHub target owner response 已收到的脫敏 metadata pointer | `template_only_not_emitted` |
| `audit-github-target-response-outcome-classified` | 記錄 acceptance / rejection 分類結果與下一步提示 | `template_only_not_emitted` |

這 3 個 event templates 目前都是 `template_only_not_emitted`，`emitted_event_count=0`。它們不代表 AwoooP production ingestion 已啟用，也不保存 owner response raw body、token、secret、private clone URL credential、repo archive、git object pack、DB dump、API request body 或 execution request payload。

## 1.4 Owner Response Redaction Examples

S4.10 redaction examples 只讓 AwoooP / owner 知道「可以怎麼安全描述 GitHub target owner decision」，避免把 token、private clone URL credential、API raw body、repo archive、git object pack 或 refs 執行指令貼進 response。

| Example | 用途 | 狀態 |
|---------|------|------|
| `redaction-github-target-doc-ref` | 用既有決策表與 snapshot 引用 GitHub target / refs blocker evidence | `template_example_only` |
| `redaction-owner-visibility-canonical-metadata` | 示範只回覆 owner、visibility review owner、canonical source 與 follow-up owner metadata | `template_example_only` |
| `redaction-private-target-access-metadata` | 示範 private / new target 只提供 repo slug、access request status 與 owner metadata | `template_example_only` |
| `redaction-refs-truth-dependency-summary` | 示範用 S4.11 / S4.12 blocker summary 取代 refs sync / delete / force-push 指令 | `template_example_only` |
| `redaction-github-target-quarantine-pointer` | 示範疑似含敏感 payload 時只留下 quarantine pointer，不保存原文 | `template_example_only` |

這 5 個 examples 都是 `template_example_only`，`stored_raw_payload_allowed=false`。它們不代表 owner response 已收到、已驗收或已批准；也不授權 repo creation、visibility change、refs sync、delete refs、force push、GitHub primary switch 或 GitHub/Gitea write。

## 1.5 Owner Response Collection Checks

AwoooP 顯示 S4.10 request packet 後，必須用 `owner_response_collection_checks` 維持 request / received / accepted 三種狀態分離：

| Check | 目的 | 失敗 lane |
|-------|------|-----------|
| `collection-github-target-request-packet-displayed` | 只顯示 7 個 target templates、允許欄位、脫敏 evidence 規則與禁止 payload | `keep_waiting_owner_response` |
| `collection-github-target-read-only-submission-mode` | 收件模式只允許 read-only response 或 redacted metadata pointer | `quarantine_sensitive_payload` |
| `collection-seven-target-template-tracking` | 7 個 GitHub targets 必須逐項追蹤，不接受單一整體同意 | `request_more_evidence` |
| `collection-github-target-redacted-evidence-only` | 只收 repo 內路徑、snapshot path 或脫敏 metadata pointer | `quarantine_sensitive_payload` |
| `collection-github-target-no-approval-language` | 不把「同意 / OK / 可進行」升級成 repo / refs / primary approval | `reject_execution_request` |
| `collection-github-target-audit-metadata-only` | 只記錄 request / response / outcome 的脫敏 audit metadata | `quarantine_sensitive_payload` |

這 6 個 checks 都是 required，但只約束 AwoooP 如何顯示與收件。它們不是 owner response accepted，也不授權 repo creation、visibility change、refs sync、delete refs、force push、GitHub primary switch、workflow / secret / runner 變更或任何 runtime action。

## 1.6 Intake Preflight Checks

AwoooP 收到 S4.10 owner response metadata pointer 後，必須先跑 `intake_preflight_checks`，只判斷「可審、補證、隔離或拒收」，不得直接標記 accepted：

| 順序 | 檢查 | 失敗處理 |
|------|------|----------|
| 1 | 回覆必須對應已知 GitHub target | 要求 owner 修正 |
| 2 | GitHub target 必填欄位完整 | 要求補 evidence |
| 3 | `decision` 在模板允許值內 | 要求 owner 修正 |
| 4 | 只接受 GitHub target 脫敏 evidence refs | 進 mirror quarantine |
| 5 | 不得夾帶 source-control 執行要求 | 拒收 execution request |
| 6 | 接受前需覆蓋七個 GitHub targets | 維持 waiting 或 request more evidence |

這 6 個 preflight checks 只協助 AwoooP 過濾 response 形狀與敏感 payload。preflight pass 不等於 accepted，也不授權 repo creation、visibility change、refs sync、delete refs、force push、GitHub primary switch、workflow / secret / runner 變更、Kali scan 或任何 runtime action。

## 2. Owner Response 必填欄位

每筆 response 至少要能回答：

1. `owner_role_or_team`：回覆者角色或團隊，不要求個人敏感資訊。
2. `decision`：必須是該 target template 允許的決策值。
3. `decision_reason`：為什麼做此 owner / visibility / canonical 判定。
4. `canonical_source`：in-scope 或 candidate target 必須標示；未知時要明確寫 `unknown_requires_more_evidence`。
5. `github_target_disposition` 或 `internal_remote_disposition`：說明 target 是 existing candidate、private access request、new target candidate、out-of-scope 或需補證。
6. `visibility_review_owner`：repo visibility 的 review 責任人；若 out-of-scope，需提供 disposition。
7. `evidence_refs`：只能指向 repo 內文件、snapshot 或 owner 提供的脫敏 metadata。

## 3. 七個 Response Template

| Template | GitHub target | 驗收重點 |
|----------|---------------|----------|
| `target-awoooi-refs-blocked` | `owenhytsai/awoooi` | 指定 canonical source、visibility owner、refs truth owner；維持 primary blocked |
| `target-clawbot-v5-refs-blocked` | `owenhytsai/clawbot-v5` | 判定 main SHA / tag 真相來源與 owner |
| `target-wooo-aiops-refs-blocked` | `owenhytsai/wooo-aiops` | 判定 GitHub-only branch / tags 的來源 owner 與 disposition |
| `target-wooo-infra-config-internal-remote` | `owenhytsai/wooo-infra-config` | 判定 110 internal remote 用途與 infra secret 名稱 inventory owner |
| `target-ewoooc-private-or-new` | `owenhytsai/ewoooc` | 判定 ewoooc / momo-pro-system canonical 關係與 private/new target disposition |
| `target-bitan-pharmacy-private-or-new` | `owenhytsai/bitan-pharmacy` | 判定 repo 是否仍 active、GitHub target disposition、owner 與 visibility owner |
| `target-tsenyang-website-private-or-new` | `owenhytsai/tsenyang-website` | 判定 repo 是否仍 active、GitHub target disposition、owner 與 visibility owner |

## 4. 可接受決策值

| Decision | 意義 |
|----------|------|
| `approve_existing_target_as_candidate` | 只同意既有 GitHub target 作為候選，不授權 refs / primary 執行 |
| `approve_private_target_access_request` | 只同意要求 owner 補 private target access evidence，不授權修改設定 |
| `approve_new_target_creation_candidate` | 只同意把新 target 建立列為候選計畫，不授權建立 repo |
| `hold_pending_refs_truth` | 維持等待 refs truth / tag disposition |
| `hold_pending_canonical_review` | 維持等待 canonical / owner review |
| `mark_external_or_out_of_scope` | 標示為外部或不納入本輪 scope，需附 owner 理由 |
| `unknown_requires_more_evidence` | 證據不足，需補脫敏 evidence |

## 5. 驗收規則

1. response 必須對應 7 個 approval-required GitHub targets 之一。
2. `decision` 必須在該 target 的允許值內。
3. 必須有 owner 與 visibility review 責任，或明確 out-of-scope disposition。
4. in-scope 或 candidate target 必須說明 canonical source。
5. 不得繞過 refs truth、workflow-secret parity、Gitea inventory、rollback ADR 或 server-side diff 缺口。
6. 不得夾帶 repo creation 或 visibility change 指令。
7. 不得夾帶 refs sync、primary switch 或 disable Gitea 指令。
8. `evidence_refs` 必須已脫敏，不得包含 token、credential、secret value、private key 或 deploy key value。

## 6. 必須拒收

1. token value、PAT、cookie、session、CSRF token、private key 或 partial credential。
2. repo creation command、API request body、CLI command 或 automation payload。
3. visibility change command 或要求立即修改 public/private/internal visibility。
4. push refs、delete refs、force push、mirror sync、tag rewrite 或 branch rewrite。
5. 切 GitHub primary、停用 Gitea、刪除 Gitea、封存 Gitea 或移除 fallback。
6. 缺 owner、visibility review owner、canonical source 或 out-of-scope disposition。
7. 把 `not_found_or_private` 自動解釋為 repo 不存在或可建立。
8. 要求自動合併 unrelated histories 或刪除 momo / ewoooc working tree。
9. 把 owner decision response 當成 repo migration approval、refs sync approval 或 primary approval。
10. 任何不確定是否含敏感值、私有 URL 憑證或未脫敏截圖的回覆。

## 7. AwoooP 可做

1. 顯示 1 個 owner response request packet。
2. 顯示 7 個 owner response template statuses。
3. 顯示 3 個 owner response audit event templates。
4. 顯示 5 個 owner response redaction examples。
5. 顯示 6 個 owner response collection checks。
6. 顯示 6 個 intake preflight checks。
7. 顯示 7 個 owner decision response templates。
8. 顯示 acceptance checks 與 rejection rules。
9. 在 owner response 到來後，只更新 read-only decision table、approval package、approval board、primary readiness gate 與 status rollup。
10. 將不完整或可疑 response 放進 mirror quarantine。
11. 持續顯示 `received_response_count=0`、`accepted_response_count=0`，直到真的收到脫敏 response。

## 8. AwoooP 不可做

1. 不要求使用者貼 token、secret、private key、cookie、session 或 deploy key。
2. 不把 response 當成 repo creation approval。
3. 不把 response 當成 visibility change approval。
4. 不把 response 當成 refs sync approval。
5. 不把 response 當成 GitHub primary approval。
6. 不建立 GitHub repo。
7. 不修改 GitHub/Gitea repo。
8. 不新增執行按鈕。

## 9. 階段定位

S4.10 是 S1.1 / S1.2 / S4.0 後面的安全收件包。

它讓 7 個 GitHub target 的 owner / visibility / canonical response 變得可審、可驗收、可拒收，但仍停在框架期。真正進入 GitHub primary 或 refs migration 前，仍必須等 Gitea inventory、refs truth、workflow-secret parity、rollback ADR、owner approval 與後續 runtime gate 全部補齊。