# Gitea 認證清冊匯出請求

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-04 |
| 狀態 | 草案與交接封套已整理，等待 S4.9 owner response / 只讀批准 |
| 資料契約 | `docs/schemas/gitea_authenticated_inventory_export_request_v1.schema.json` |
| 快照 | `docs/security/gitea-authenticated-inventory-export-request.snapshot.json` |
| 後續驗收 | `docs/security/GITEA-AUTHENTICATED-INVENTORY-IMPORT-ACCEPTANCE.md` |
| 覆蓋 Attestation | `docs/security/GITEA-INVENTORY-COVERAGE-ATTESTATION.md` |
| 來源契約 | `gitea_repo_inventory_v1` |
| 模式 | `redacted_export_request_only` |
| 執行面授權 | `false` |

## 0. 核心結論

S4.5 把 Gitea 私有 / 內部全量 repo 清冊的下一步匯出請求正式文件化。

目前 `gitea_repo_inventory_v1` 仍是 `partial`：未認證 API / 公開搜尋只看到 2 個公開 repos，但本機 remote 清冊至少看到 4 個 unique Gitea repos。因此不能宣告「Gitea 目前所有專案版本」已盤完，也不能開始 GitHub primary 切換。

本文件只定義兩條安全路徑：只讀 token API 清冊，或已脫敏的管理匯出清冊。兩者都不得保存 token value，不得寫入 Gitea，不得 sync refs，不得切 GitHub primary。

S4.6 已補後續的匯入驗收契約：即使 owner 或管理者提供 payload，也必須先通過 schema、脫敏、coverage gap 與隔離規則，才能成為 `gitea_repo_inventory_v1.status=ok` 的候選 evidence。

S4.7 已補 owner coverage attestation：在補全量清冊前，owner 仍需判定 public-only 2 repos、本機 Gitea unique 4 repos、org/user endpoint 與 110 internal adjacent sources 的 scope。S4.7 不授權 token 收集、repo 寫入、refs sync 或 primary cutover。

S4.9 已補 owner response gate 與 2026-06-04 request dispatch preflight 交接包：P1-2 的只讀 token 或 redacted admin export 請求必須等 S4.9 五題 scope decision 進入可審狀態後，才能由人工批准進下一步。這仍不代表 token value 可以被貼到文件、對話、LOGBOOK 或 snapshot。

## 1. 摘要

| 指標 | 數量 |
|------|------|
| Gitea 基礎 URL | `http://192.168.0.110:3001` |
| 組織 / 使用者 | `wooo` |
| 未認證公開範圍 repos | 2 |
| 本機可見 Gitea unique repos | 4 |
| 本機 Gitea 覆蓋缺口 | 2 |
| 匯出來源選項 | 2 |
| 目標狀態 | `gitea_repo_inventory_v1.status=ok` |
| 允許收集 token value | `false` |
| 允許 write token | `false` |
| 允許 repo 寫入 | `false` |
| 允許 refs sync | `false` |
| 授權切換 GitHub primary | `false` |
| S4.7 owner attestation items | 5 |
| S4.9 owner response gate required | `true` |
| request handoff package | `ready` |
| request dispatch authorized | `false` |
| admin export payload received | 0 |
| admin export payload accepted | 0 |

## 2. 匯出來源選項

| 選項 | 允許 | 禁止 |
|--------|------|------|
| 只讀 token API 清冊 | 使用 `GITEA_READONLY_TOKEN` 環境變數跑既有 inventory 工具；輸出只保存 `token_present=true` | 保存 token value、使用 write token、寫入 Gitea、sync refs |
| 已脫敏管理匯出清冊 | 匯入已脫敏 repo list JSON；只保留 repo metadata | 匯入 DB dump、secret、webhook secret、deploy key private key、cookie、session |

## 3. 必要欄位

1. `full_name` 或 `owner.login + name`。
2. `name`。
3. `owner.login`。
4. `private`。
5. `archived`。
6. `empty`。
7. `default_branch`。
8. `clone_url_redacted`。
9. `ssh_url_redacted`。
10. `github_repo_candidate`。

## 4. 目前覆蓋缺口

| 缺口 | 現況 | 需要解決 |
|-----|------|----------|
| 未認證公開範圍 vs 本機 Gitea | API 只看到 `wooo/awoooi`、`wooo/ewoooc`；本機 remote 還看到 `wooo/clawbot-v5`、`wooo/wooo-aiops` | 認證清冊或 owner 證明必須解釋缺口 |
| Org endpoint 受阻 | `orgs/wooo/repos` 未認證查詢先前為 blocked / 404 | 不得把 404 解讀為沒有 private/internal repos |
| 110 內部相鄰來源 | 本機另看到 `bitan-pharmacy`、`root/momo-pro-system`、`tsenyang-website`、`wooo/wooo-infra-config` | Gitea inventory 完成後仍需 owner 判定是否納入 migration scope |

## 5. 驗收

1. `gitea_repo_inventory_v1.status=ok`。
2. `visibility_scope=authenticated` 或 `visibility_scope=admin_export`。
3. `repo_count` 大於或等於未認證公開範圍 repo count。
4. 必須解釋未認證公開範圍 2 個 repos 與本機可見 Gitea 4 個 repos 的差異。
5. 不含 token、password、secret value、webhook secret、deploy key private key、runner registration token、cookie、session。
6. 只更新 migration matrix、decision table、approval board 與 readiness gate。
7. 不建立 GitHub repo、不 sync refs、不切 primary。

## 6. AwoooP 可做

1. 顯示 S4.5 匯出請求與兩條安全來源路徑。
2. 顯示覆蓋缺口與 owner review lane。
3. 顯示 token value / write token / repo write / refs sync 全部禁止。
4. 把完成的脫敏匯出寫入 Audit evidence 等待人工 review。
5. 若 payload 含敏感值，送進 mirror 隔離。

## 7. AwoooP 不可做

1. 不要求使用者在 UI、對話或文件貼 token value。
2. 不保存 token value。
3. 不使用具寫入能力的 token。
4. 不寫入 Gitea。
5. 不建立、刪除、封存或修改 Gitea repo。
6. 不建立 GitHub repo、不 sync refs、不切 GitHub primary。
7. 不把清冊請求當成清冊已完成。

## 8. 2026-06-04 P1-2 請求交接封套

本段把 S4.5 認證清冊匯出請求對齊 2026-06-04 的 S4.9 owner response gate。它只代表「請求包可交接」，不代表 owner 已批准、不代表只讀 token 已提供、不代表 redacted admin export 已收到，也不代表 `gitea_repo_inventory_v1.status=ok`。

### 8.1 送件前條件

| 順序 | 條件 | 完成狀態 |
|------|------|----------|
| 1 | S4.9 五題 owner response request packet 已可交接，且 request / received / accepted 分離 | 已整理，未送件 |
| 2 | 只讀 token 路徑與 redacted admin export 路徑二選一，不要求同時提供 | 已整理，未執行 |
| 3 | 收件欄位只收 repo metadata、redacted URL、owner/team 與 evidence refs | 已整理，未收件 |
| 4 | 禁止 token value、write token、DB dump、git object pack、secret / webhook / deploy key material | 已整理，未收件 |
| 5 | 實際收到 payload 前，received / accepted / imported count 全部維持 0 | 已整理，未收件 |

### 8.2 交接封套欄位

| 欄位 | 內容規則 |
|------|----------|
| `request_id` | `p1_2_gitea_authenticated_inventory_request` |
| `prerequisite_gate` | S4.9 owner response gate 需先保持可審狀態；未通過前不可標記 inventory complete |
| `allowed_source_options` | `readonly_token_api_inventory` 或 `redacted_admin_export_inventory` |
| `recipient_role_or_team` | 只填角色或團隊，不填 token / PAT / cookie / session |
| `requested_outputs` | repo metadata、redacted clone / ssh URL、visibility scope、coverage notes、evidence refs |
| `forbidden_inputs` | token value、write credential、DB dump、repo archive、git object pack、deploy key private key、webhook secret、runner token |
| `intake_acceptance_ref` | `GITEA-AUTHENTICATED-INVENTORY-IMPORT-ACCEPTANCE.md` |
| `not_approval` | 必須為 `true` |

### 8.3 送件後不變條件

即使後續 owner / 管理者同意提供只讀來源，也只能把狀態推到「等待安全輸入」或「收到脫敏 payload 待驗收」。必須先通過 S4.6 import acceptance，並用 S4.7 / S4.9 owner response 解釋 coverage gap，才可把清冊候選交給 reviewer。任何 repo 建立、refs sync、workflow / secret 修改、GitHub primary cutover、Gitea 停用或 runtime gate 都需要另行人工批准。

## 9. 階段定位

S4.5 只是把 Gitea 認證清冊的下一步請求、欄位、拒收規則與驗收 gate 定清楚。

S4.7 會在此基礎上要求 owner 說明 coverage gap 與 scope decision。這補的是「完整轉移 Gitea 目前所有專案版本到 GitHub」前的資料缺口；仍然停在框架期，不進入執行、同步或主控切換。