# 圆桌会议纪要：Kanban 做站协作最佳实践

日期：2026-06-17
主持：小墨 / Host
参会：墨策、墨引、墨影、墨界、墨枢、墨测、墨运、墨账、墨盾、墨笔、墨析、墨探、墨投
资料：
- Round 1 brief: `/root/.hermes/reports/site-atlas/roundtable-kanban-collab-brief.md`
- Round 2 brief: `/root/.hermes/reports/roundtables/kanban-collab-20260617/round2-brief.md`
- Round 2 results: `/root/.hermes/reports/roundtables/kanban-collab-20260617/round2-results.json`

> 注：多个 profile 返回了完整发言，但 CLI 退出码为 -6；按 roundtable skill 规则，stdout 完整时采纳观点，并标记 CLI 退出异常。

## 最终结论

当前系统的最佳实践不是“再加一个聊天群”或“把 Atlas 变成第二套任务系统”，而是形成四层分工：

1. **Kanban = 唯一执行真相源**
2. **Metadata Contract = Agent 间交接协议**
3. **Site Atlas = 只读项目驾驶舱 / 项目记忆层**
4. **Telegram = 通知、Owner 确认、紧急阻塞，不承载长上下文**

第一优先级：先落地统一 `metadata contract v1` 和状态字典，不先大改 Kanban schema。

## 核心裁决

### A. Kanban schema 还是 metadata contract？

裁决：**先 metadata contract，后 schema 固化。**

理由：
- 全员基本一致反对一开始大改 Kanban schema。
- 当前痛点是语义不统一，不是数据库字段不够。
- metadata contract 可先在任务 body / run metadata / reports manifest 中落地，跑 2-3 个站后再把稳定字段上升为 schema。

### B. Site Atlas 展示什么？

裁决：Atlas 首屏只展示项目级判断，不复制 Kanban 全量任务表。

建议首屏字段：
- 当前判决 / launch allowed
- 最大阻塞
- 下一步 owner
- 关键交付链完整度
- 最近证据时间
- 红绿灯：Product / SEO / Quality / Compliance / Commercial / Data

专业细项全部进二级详情页：SEO、合规、商业、投放、数据、源码、时间线、历史。

### C. DAG 是否加更多 gate？

裁决：**少量硬 gate + 多个 readiness 灯。**

保留/新增硬 gate：
- PRD approved
- QA verified
- legal blocking / compliance required passed
- launch_allowed
- data_chain_ready（上线后进入复盘/投放前）
- payment_ready（涉及收费站点）

不建议所有专业都变硬 gate。SEO/合规/商业/投放/运营/数据中，只有红灯阻断，其余用 readiness 灯和 blocker reason 表达。

### D. 新 Kanban board 是否自动进入 Atlas？

裁决：**不自动全量纳入。必须 board registry / allowlist。**

理由：
- 自动纳入会污染 Atlas：测试 board、废弃 board、临时 board、敏感项目会混进驾驶舱。
- 新 board 进入 Atlas 前必须声明：board 类型、owner、contract version、是否 site pipeline。

### E. 复盘如何触发？

裁决：**固定周期 + 数据阈值双触发。**

固定周期：
- Day 0 / Day 1 / Day 3 / Week 1
- 或简化版 D7 / D30

阈值触发：
- GSC indexed=0
- 关键事件为 0
- 转化异常
- 支付异常
- 流量突变
- API 成本异常
- P0 blocker

复盘 DAG：
`数据证据包父任务 → 产品/SEO/运营/商业/合规/投放子复盘 → 墨析 fan-in verdict`

## Metadata Contract v1 草案

### 通用字段

```json
{
  "contract_version": "site-kanban-v1",
  "project_slug": "aicodingpricing",
  "stage": "design|frontend|backend|qa|launch|review",
  "status_type": "todo|running|blocked|waiting_human|verified|done_with_risk|superseded|budget_exhausted_partial",
  "verdict": "GO|NO_GO|CONDITIONAL_GO|REVIEW_REQUIRED|NOT_APPLICABLE",
  "inputs": [],
  "outputs": [],
  "evidence_paths": [],
  "acceptance": [],
  "blocked_reason": "",
  "blocker_type": "worker|provider|system|external_account|owner_decision|validation_failure",
  "next_owner": "mojie|moying|motest|owner|...",
  "handoff_to": "",
  "supersedes": [],
  "superseded_by": "",
  "verified_by": "",
  "launch_allowed": false,
  "updated_at": "ISO8601"
}
```

### 专业扩展字段

#### 市场 / 墨探
- `market_verdict`
- `primary_keyword`
- `intent`
- `serp_type`
- `competitors`
- `opportunity_grade`
- `kill_condition`

#### SEO / 墨引
- `target_keywords`
- `indexability`
- `canonical`
- `sitemap`
- `robots`
- `schema`
- `internal_links`
- `gsc_status`

#### 内容 / 墨笔
- `copy_version`
- `content_freeze`
- `page_matrix`
- `cta_contract`
- `faq_contract`
- `claim_risk_terms`

#### 设计 / 墨影
- `design_handoff_path`
- `opendesign_run_id`
- `design_source_status`
- `desktop_screenshot`
- `mobile_screenshot`
- `css_tokens`
- `handoff_checklist`
- `frontend_acceptance_status`

#### 前端 / 墨界
- `repo_path`
- `branch`
- `commit_sha`
- `deploy_url`
- `build_log`
- `lighthouse_summary`
- `source_synced`

#### 后端 / 墨枢
- `api_contract_path`
- `db_schema_status`
- `worker_deploy_url`
- `auth_status`
- `payment_status`
- `data_migration_status`

#### QA / 墨测
- `qa_verdict`
- `test_matrix`
- `p0_issues`
- `p1_issues`
- `evidence_paths`
- `launch_allowed`

#### 上线运营 / 墨运
- `ops_ready`
- `distribution_ledger`
- `channel_status`
- `proof_url`
- `next_check_at`

#### 商业 / 墨账
- `pricing_status`
- `cost_model_status`
- `paywall_status`
- `refund_policy_status`
- `unit_economics_risk`

#### 合规 / 墨盾
- `privacy_status`
- `terms_status`
- `cookie_status`
- `refund_status`
- `data_collection_scope`
- `ip_risk`
- `legal_owner`
- `reviewed_at`

#### 数据复盘 / 墨析
- `data_chain_status`
- `analytics_coverage`
- `funnel_events_status`
- `review_verdict`
- `missing_data_sources`
- `next_review_at`

#### 投放 / 墨投
- `paid_potential`
- `paid_readiness`
- `tracking_ready`
- `conversion_path_verified`
- `test_budget_cap`
- `owner_approval_required`

## Agent 间协作最佳实践

### 1. 每个阶段只允许结构化出口

推荐出口：
- `READY_FOR_NEXT`
- `DONE_WITH_RISK`
- `BLOCKED_WAITING_OWNER`
- `BLOCKED_EXTERNAL_ACCOUNT`
- `BLOCKED_PROVIDER`
- `NEEDS_REVISION`
- `SUPERSEDED`
- `KILLED`

禁止：
- “差不多完成”
- “已处理，后续看情况”
- “等待下一棒自行判断”
- “Telegram 里已经说了”

### 2. DONE 不等于 verified

必须拆开：
- `implemented`
- `verified`
- `owner_approved`
- `launch_allowed`
- `commercial_ready`
- `data_ready`

Atlas 不能把普通 DONE 显示成最终绿灯。

### 3. Superseded 必须有指向

任何旧分支、旧设计、旧 QA、旧上线任务废弃时，必须写：
- `superseded_by=<new_task_id>`
- 废弃原因
- 哪些产物仍可复用
- 哪些下游任务需要 relink

### 4. Telegram 只发短消息

标准 Telegram 消息格式：

```text
[BLOCKED] aicodingpricing · QA
原因：GSC 未验证
需要：Owner 登录确认
Atlas: https://atlas.shipsolo.io/sites/aicodingpricing.html#...
Task: t_xxx
```

不在 Telegram 写长报告，不让 Agent 自由互聊。

### 5. Reports 必须 manifest 化

每个阶段报告目录应有：

```text
reports/<project>/<stage>/manifest.json
reports/<project>/<stage>/HANDOFF.md
reports/<project>/<stage>/evidence/*
```

Atlas 优先读 manifest，不扫散文件猜含义。

## Site Atlas 最佳实践

### 首页
只看项目级状态：
- 当前判决
- 最大阻塞
- 下一步 owner
- 6 个红绿灯
- 最近证据时间
- 是否 launch allowed

### 详情页
- 作战摘要
- 阶段进度
- 关键交付链
- 当前阻塞
- 专业红绿灯详情
- 产物墙
- 源码只读编辑器
- 时间线
- 历史 / superseded 分支折叠

### Board 纳入规则
新增 `board-registry.json`：

```json
{
  "boards": [
    {
      "slug": "site-factory",
      "enabled": true,
      "type": "site_pipeline",
      "owner": "xiaomo",
      "contract_version": "site-kanban-v1"
    },
    {
      "slug": "site-review",
      "enabled": true,
      "type": "site_review",
      "owner": "xiaomo",
      "contract_version": "site-kanban-v1"
    }
  ]
}
```

Atlas refresh 只读取 registry enabled boards，不自动扫全部 board。

## 行动项建议

### P0 — 先做，不等
- [ ] 小墨/墨枢：定义 `site-kanban-v1 metadata contract`。
- [ ] 小墨：把 `site_atlas_generate.py` 改为读 board registry，而不是硬编码 board。
- [ ] 墨测/墨策：定义统一状态字典和阶段出口语义。
- [ ] 墨析：定义复盘 DAG：数据证据包父任务 → 专业子复盘 → fan-in verdict。

### P1 — 下一轮落地
- [ ] Site Atlas 加 6 个红绿灯：Product / SEO / Quality / Compliance / Commercial / Data。
- [ ] Site Atlas 增加 `launch_allowed` 和 `next_owner` 首屏字段。
- [ ] Reports 增加 manifest 标准。
- [ ] 任务完成时校验 metadata contract，缺字段不允许标 verified。

### P2 — 稳定后做
- [ ] 跑 2-3 个站点后，把高频 metadata 字段上升为 Kanban schema 或辅助索引表。
- [ ] 实现 Atlas deep link 到具体 task/node/artifact。
- [ ] 实现阈值触发复盘：GSC/GA/Clarity/Stripe/API cost 异常自动建复盘任务。

## 被明确否决的做法

- 否决 Atlas 写状态。
- 否决 Telegram 承载长上下文或作为 source of truth。
- 否决新 board 自动全量纳入 Atlas。
- 否决一开始大改 Kanban schema。
- 否决所有专业检查都变成硬 gate。
- 否决没有证据路径的 DONE。
- 否决单个 Agent 直接给全站 Kill/Scale 结论。
- 否决没有 superseded 指向的旧分支废弃。

## Host 裁决

采用以下路线：

1. **Contract-first**：先写 `site-kanban-v1 metadata contract`。
2. **Registry-controlled Atlas**：新增 board registry，禁止自动全 board 扫描。
3. **Atlas as cockpit**：只读、聚合、可视化，不写回状态。
4. **Telegram as interrupt layer**：短通知 + owner decision + Atlas deep link。
5. **Review as fan-in**：复盘必须基于数据证据包和多专业子复盘，不由单 Agent 包办。

下一步如果进入执行，建议先建一个小型改造 DAG：

- `moshu`: metadata contract + board registry 数据结构
- `moce + motest`: 状态字典 + gate 语义
- `moxi`: 复盘 DAG 和数据证据包 contract
- `xiaomo/host`: Site Atlas generator 改造
- `motest`: 验收 Atlas 是否能从 metadata 还原真实状态