# VibeWork 納入 IwoooS 只讀 Handoff

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-04 |
| 狀態 | 草案，等待 owner review |
| 產品 | `VibeWork` |
| Schema | `docs/schemas/vibework_iwooos_onboarding_handoff_v1.schema.json` |
| Snapshot | `docs/security/vibework-iwooos-onboarding-handoff.snapshot.json` |
| 上游證據 | `docs/security/iwooos-posture-projection.snapshot.json`、`apps/web/src/app/[locale]/iwooos/page.tsx`、`/Users/ogt/Documents/VibeWork-current-main/README.md` |
| 模式 | `product_scope_handoff_only` |
| 執行面授權 | `false` |

## 0. 核心結論

P1-9 補的是 VibeWork 納入 IwoooS 後的 repo / product / surface / owner / evidence refs / 獨立產品邊界 handoff。它不是產品合併、不是部署批准、不是 repo / refs 同步、不是 workflow / secret 修改，也不是掃描或修復授權。

VibeWork 目前在 IwoooS 前端已是只讀納管範圍；本階段要補的是後台治理契約，讓 owner / reviewer 能逐項收件，而不是只靠前端卡片理解。

## 1. 已讀到的只讀 evidence

| 類別 | evidence | 判讀 |
|------|----------|------|
| 產品定位 | `/Users/ogt/Documents/VibeWork-current-main/README.md` | VibeWork 是獨立 AI Vibe Coding 接案媒合平台 |
| 技術棧 | `package.json` | Next.js 14、TypeScript、Prisma、PostgreSQL、Tailwind、Zod、Zustand |
| 產品邊界 | `docs/PROJECT_BOUNDARIES.md` | 第一階段不得共用既有產品資料庫、Session、RBAC 或核心流程 runtime |
| 部署策略 | `docs/DEPLOYMENT_STRATEGY.md` | 正式主線為獨立 Docker Compose；public host `https://vibework.wooo.work` |
| 推版流程 | `docs/RELEASE_PROCESS.md` | 正式 image 必須可追溯 Gitea commit，部署後跑 smoke check |
| IwoooS 前端 | `apps/web/src/app/[locale]/iwooos/page.tsx` | 已有 VibeWork 六項收件卡，runtime gate count 仍為 `0` |

## 2. Scope 摘要

| 指標 | 值 |
|------|----|
| onboarding handoff package | `ready` |
| package completion | `100%` |
| VibeWork product boundary merged into AWOOOI | `false` |
| owner response received / accepted | `false / false` |
| repo refs truth accepted | `false` |
| data classification accepted | `false` |
| deployment boundary accepted | `false` |
| runtime gate open | `false` |
| production deploy authorized | `false` |
| repo creation / refs sync / workflow modification authorized | `false / false / false` |

## 3. Repo / Refs Handoff

目前只讀觀察到兩個本機路徑與一個 Gitea remote：

| 類型 | 路徑 / remote | 只讀判讀 | 不可誤讀 |
|------|---------------|----------|----------|
| active workspace | `/Users/ogt/Documents/VibeWork` | 工作目錄存在大量本地修改與未追蹤檔；不適合作為 AWOOOI 直接引用的 canonical evidence | 不可自動 commit、rebase、push、刪檔或同步 refs |
| reference worktree | `/Users/ogt/Documents/VibeWork-current-main` | HEAD `1a902530141004d958cda639bea9a837282c867f`；`origin/main=421c834756b7f41ef554c0348274f3762c3fc2de`；`main=48275cc52be79107e887147d3fe10310a887afe9` | refs truth 需 owner 決定；不可自動把 worktree 當正式 main |
| Gitea remote | `ssh://git@192.168.0.110:2222/wooo/vibework.git` | VibeWork 正式版本來源候選 | 不收 SSH key、不改 remote、不 push、不建 GitHub mirror |

後續 owner response 必須回答：

1. canonical repo path / remote 以哪個為準。
2. `VibeWork` / `VibeWork-current-main` / `origin/main` / `main` 的 refs truth 如何處理。
3. 哪些 dirty workspace 檔案只是本機 WIP，哪些是待整合 release candidate。
4. 是否需要 GitHub target；若需要，也只收 target metadata，不建立 repo。
5. workflow、runner、secret name parity 是否要納入後續 source-control owner response；不收 secret value。

## 4. Product / Surface Handoff

| Surface | 類型 | 本階段 evidence | 邊界 |
|---------|------|----------------|------|
| `/`、`/en` | public marketing | 官網首頁與英文入口存在 | 不代表 production smoke 已在本段執行 |
| `/client/projects/new`、`/client/projects/*` | client workspace | 需求者 intake、PRD、媒合流程 | 不接 AWOOOI DB、不共用 Session |
| `/coder/matches`、`/coder/profile` | coder workspace | 接案者履歷、媒合機會與回應 | 不共用 AWOOOI RBAC |
| `/admin`、`/api/v1/admin/*` | admin / reviewer | 管理後台、審核、內容管理 | 需 VibeWork 自身角色邊界 |
| `/notifications` | logged-in user | 站內通知 | 不導入 AWOOOI Telegram approval 語義 |
| `/api/v1/health` | health | 正式 smoke 目標之一 | 只作 health evidence，不代表 runtime gate |
| `/api/ai/*` | AI assistance | intake / milestone / support agent 路徑 | AI evidence 必須保留 VibeWork 內部稽核與授權邊界 |

## 5. Owner Response Handoff

此 handoff 只讓 AwoooP 或 reviewer 請 owner 補 VibeWork metadata。它不是 request sent、不是 approval queue，也不是可執行動作。

### 5.1 必填欄位

| 欄位 | 說明 |
|------|------|
| `product_owner_role_or_team` | VibeWork 產品 owner 或 team |
| `security_owner_role_or_team` | VibeWork 資安 / 資料保護 owner |
| `source_control_owner_role_or_team` | repo / refs / workflow / secret name owner |
| `deployment_owner_role_or_team` | Docker Compose / K3s / domain / smoke owner |
| `data_classification_owner_role_or_team` | 需求、PRD、個資、媒合、稽核與通知資料分級 owner |
| `surface_scope` | 本次納入 IwoooS 的 route、API、admin、worker、job 範圍 |
| `decision` | 允許值：`confirm_observe_only`、`defer`、`reject`、`request_more_evidence` |
| `decision_reason` | 決策理由摘要，不得貼 raw secret、token、cookie 或未脫敏截圖 |
| `redacted_evidence_refs` | 只填文件、snapshot、ticket、commit、hash 或脫敏 metadata pointer |
| `followup_owner` | 補件、拒收或下一階段 owner |

### 5.2 禁止輸入

| 類型 | 規則 |
|------|------|
| credential | 不貼 `.env`、DB URL、auth secret、job secret、webhook token、API key、cookie、session、private key |
| raw data | 不貼需求者原始需求、PRD 原文、媒合個資、會員資料、通知內容、稽核原文 |
| source-control action | 不要求建立 repo、同步 refs、rebase、push、改 workflow、改 runner、改 secret |
| production action | 不要求 deploy、restart、compose up/down、DB migration、drift guard apply |
| runtime coupling | 不要求共用 AWOOOI DB、Session、RBAC、Telegram approval 或 AwoooP execution router |

## 6. 獨立產品邊界

VibeWork 可以納入 IwoooS 的全產品資安視野，但第一階段仍必須維持獨立產品邊界：

1. 不共用 AWOOOI 或其他產品資料庫。
2. 不共用 AWOOOI 會員 Session。
3. 不把 VibeWork RBAC 綁到 AWOOOI 權限模型。
4. 不讓 VibeWork 核心流程依賴 AWOOOI runtime 可用性。
5. 不把 AwoooP approval 當 VibeWork 資安批准或部署批准。
6. 後續整合只能走版本化 API、Webhook、outbox、匯入匯出配接器、SSO / OAuth 或 Anti-Corruption Layer。
7. 即使未來做 SSO / OAuth，也不得取代 VibeWork 自己的 RBAC 與稽核事件。

## 7. 資料分級收件

| 資料類型 | 初期分級狀態 | 收件規則 |
|----------|--------------|----------|
| 需求者需求 / intake answer | waiting owner classification | 只收欄位類型、資料流與脫敏摘要，不收原文 |
| PRD block / source anchor | waiting owner classification | 只收資料模型與風險摘要，不收完整 PRD |
| 接案者履歷 / 作品集 | waiting owner classification | 只收欄位與公開 / 私有邊界，不收個資內容 |
| 媒合紀錄 / 分數理由 | waiting owner classification | 只收評分因子與稽核規則，不收個案資料 |
| AuditEvent / 通知 | waiting owner classification | 只收事件類型與保存策略，不收訊息原文 |
| admin / marketing content | waiting owner classification | 只收發布流程與權限邊界，不收未發布內容 |

## 8. 驗收規則

1. 本 handoff 完成不代表 VibeWork owner response 已收到或 accepted。
2. VibeWork 納入 IwoooS 只代表全產品資安視野可見，不代表掃描、部署、修復或 runtime execution。
3. canonical repo、refs truth、workflow / secret name、GitHub target 仍需 source-control owner response。
4. 正式 URL、Docker Compose、health endpoint 或 drift guard 可見，不等於本段已做 production verification。
5. 任何 `.env`、secret、DB URL、token、private key、cookie、session、auth header、job secret 都必須拒收或隔離。
6. 未來若要改 VibeWork production、deploy、compose、DB migration、worker、domain、TLS 或 smoke 帳密，必須另開 VibeWork owner approval 與 rollback / post-check。

## 9. 階段定位

P1-9 只把 VibeWork 從「前端已只讀納管」推到「owner / reviewer 可照表審 repo、product、surface、owner、data classification、deployment boundary 與 evidence refs」。它不改 VibeWork repo、不改 AWOOOI 前端、不部署、不掃描、不開 runtime gate，也不提高 IwoooS headline 64%。