← Site Atlas圆桌会议复盘kanban-collab-20260617

Roundtable Review

Kanban 做站协作最佳实践

把多 Agent 圆桌会议可视化成:参会者、共识、分歧裁决、行动项、观点矩阵和原始纪要。

13参会 Agent
2讨论轮次
26核心共识
11行动项

裁决流

Kanban 真相源Metadata ContractAtlas 只读驾驶舱Telegram 中断层圆桌复盘沉淀Registry 控制范围

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 还原真实状态

核心共识

✅ 全员基本一致反对一开始大改 Kanban schema。
✅ 当前痛点是语义不统一,不是数据库字段不够。
✅ metadata contract 可先在任务 body / run metadata / reports manifest 中落地,跑 2-3 个站后再把稳定字段上升为 schema。
✅ 当前判决 / launch allowed
✅ 最大阻塞
✅ 下一步 owner
✅ 关键交付链完整度
✅ 最近证据时间
✅ 红绿灯:Product / SEO / Quality / Compliance / Commercial / Data
✅ PRD approved
✅ QA verified
✅ legal blocking / compliance required passed
✅ launch_allowed
✅ data_chain_ready(上线后进入复盘/投放前)
✅ payment_ready(涉及收费站点)
✅ 自动纳入会污染 Atlas:测试 board、废弃 board、临时 board、敏感项目会混进驾驶舱。
✅ 新 board 进入 Atlas 前必须声明:board 类型、owner、contract version、是否 site pipeline。
✅ Day 0 / Day 1 / Day 3 / Week 1
✅ 或简化版 D7 / D30
✅ GSC indexed=0
✅ 关键事件为 0
✅ 转化异常
✅ 支付异常
✅ 流量突变
✅ API 成本异常
✅ P0 blocker

行动项

  1. [ ] 小墨/墨枢:定义 `site-kanban-v1 metadata contract`。
  2. [ ] 小墨:把 `site_atlas_generate.py` 改为读 board registry,而不是硬编码 board。
  3. [ ] 墨测/墨策:定义统一状态字典和阶段出口语义。
  4. [ ] 墨析:定义复盘 DAG:数据证据包父任务 → 专业子复盘 → fan-in verdict。
  5. [ ] Site Atlas 加 6 个红绿灯:Product / SEO / Quality / Compliance / Commercial / Data。
  6. [ ] Site Atlas 增加 `launch_allowed` 和 `next_owner` 首屏字段。
  7. [ ] Reports 增加 manifest 标准。
  8. [ ] 任务完成时校验 metadata contract,缺字段不允许标 verified。
  9. [ ] 跑 2-3 个站点后,把高频 metadata 字段上升为 Kanban schema 或辅助索引表。
  10. [ ] 实现 Atlas deep link 到具体 task/node/artifact。
  11. [ ] 实现阈值触发复盘:GSC/GA/Clarity/Stripe/API cost 异常自动建复盘任务。

Agent 观点矩阵

Agent观点第一优先级明确否决
moce支持“先 metadata contract,后 schema 收敛”。PM 角度先统一口径,不先扩表;否则会把做站流水线拖成平台改造项目。1. 定义 Kanban metadata contract + 状态枚举,先解决 DONE/BLOCKED/superseded/waiting human/verified/launch allowed 混用。 2. 做 Atlas 项目状态卡:当前判决、最大阻塞、下一步 owner、6 个红绿灯、关键交付链。否决一开始改大 schema、加全量 gate、让 Telegram 承载上下文、让 Atlas 写状态、让复盘由单 Agent 直接给最终结论。 session_id: 20260617_105810_47c6e1
moyin支持“先 metadata contract,后 schema 固化”。SEO 不需要更多口头状态,需要可审计的索引、结构化、内链、页面矩阵证据。1. 先落地 SEO metadata contract + 验收模板;没有证据路径不得标 DONE。 2. 新增一个轻量 SEO gate:上线前必须通过 `indexable + sitemap + canonical + schema + title/meta + internal links` 六项检查。- 否决一开始就改 Kanban schema,成本高且会拖慢协作。 - 否决把 SEO/合规/商业/投放/数据全做成硬 gate;SEO 只在上线前设硬门槛,其他放 Atlas 红绿灯和 BLOCKED reason。 - 否决 Telegram 承载 SEO 长报告;群里只发结论、风险、Atlas deep link。 session_id: 20260617_105810_1b4ed5
moyingKanban 不改 schema,先用 metadata contract 约束交付物结构。Atlas 红绿灯只保留与设计/前端直接相关的 3 个:视觉完成度、品牌一致性、交付物可交接性。- 否决"设计阶段加商业/投放/数据 gate"——设计不懂这些,加了只会拖慢交付或造假通过。 - 否决"Atlas 自动聚合所有 board"——设计需要人判断哪些 board 值得看,自动聚合=噪音。
mojie优先用 metadata contract,不动 Kanban schema。Atlas 红绿灯只保留 4 个:构建状态、SEO 合规、质量验收、上线许可。DAG gate 只加 SEO 和上线许可,其他靠 metadata 标注。- 改 Kanban schema:会打断所有在跑任务 - 6+ 红绿灯:信息噪音,前端不会看 - 复盘纯按周期触发:上线后 48h 数据异常必须能紧急插队复盘
moshu支持“先 metadata contract,后 schema 收敛”。不要第一步改 Kanban schema。1. 落地统一 metadata contract:status_type、verdict、blocked_by、superseded_by、evidence_paths、handoff_to、next_owner、launch_allowed。 2. Atlas 只读聚合这些字段,先做状态驾驶舱,不写回状态。否决把 Telegram 状态、Atlas UI 状态、Kanban 状态各自定义一套。 否决一开始大改 Kanban schema 或把所有专业检查都变硬 gate。 session_id: 20260617_105810_dcb29c
motest支持“先 metadata contract,后 schema 演进”。QA 不需要更多自由状态,需要统一可判定的门禁语义:`pass / conditional_pass / fail / blocked / superseded`,另设独立字段表达 `launch_allowed`、`verified_by`、`evidence_paths`、`blocking_issues`。- 否决立刻大改 Kanban schema。 - 否决把所有专业 gate 都设成上线阻塞。 - 否决新 board 自动纳入 Atlas;必须 registry/allowlist,且声明 contract version。 session_id: 20260617_105825_267019
moyunKanban metadata contract 先落地,不改 schema;Atlas 红绿灯控制在 3-4 个;DAG 只在上线节点加一个 "ops-ready" gate,不在做站全链路铺 gate;复盘用上线事件 + 数据阈值双触发。1. 定义并落地 6 字段 metadata contract,先在 3 个活跃站跑通。 2. 锁定 "ops-ready" gate 的验收清单,写入 Kanban task template。否决一切"加更多 gate 才算严谨"的做法。gate 多了没人执行,等于没有。
mozhang支持先用 metadata contract,不先改 Kanban schema。商业化视角第一优先级是把“能不能上线、能不能收钱、会不会亏钱”变成硬字段,而不是再加复杂流程。1. 落地商业 metadata contract:价格、成本、毛利红线、支付状态、退款政策、商业 owner。 2. Atlas 增加“商业红灯阻断上线”规则:毛利不清、成本无上限、支付未验收、退款口径缺失时 launch_allowed=false。否决一开始大改 schema、把所有 gate 都硬阻断、Atlas 自动纳入所有 board。这样会制造假治理,拖慢出站节奏,还会让商业判断淹没在流程噪音里。 session_id: 20260617_105838_fa4b0c
modun我支持“先 metadata contract,后 schema 迁移”。合规状态必须先被统一表达,不要一上来改 Kanban 底层 schema。1. 落地统一合规 metadata contract,DONE 不能只写“合规完成”,必须有文档路径、适用地区、数据处理范围、未决风险。 2. Atlas 增加 Launch Allowed 判决:没有合规通过,不允许显示 launch allowed。- 否决“Telegram 确认即合规通过”。 - 否决“自动纳入所有 board”。 - 否决“合规只在上线后补文档”。合规必须前置到 PRD 后和上线前。 session_id: 20260617_105841_a061a0
mobi支持先用 metadata contract,不急着改 Kanban schema。内容侧最怕状态字段漂亮,交付物还是散的。1. 建立内容交付 metadata:最终文案路径、页面清单、SEO title/description、CTA、FAQ、免责声明/敏感词检查、下一棒。 2. Atlas 展示“当前可用文案版本”和“是否允许设计/前端使用”,别让过期草稿混进生产。否决 Telegram 长文交付、否决口头 DONE、否决没有 superseded 指向的改稿。内容一旦被 Stitch/前端使用,改文案必须生成新版本,不要在原地偷偷改。 session_id: 20260617_105842_4d2b0e
moxi支持先落 metadata contract,不急着改 Kanban schema。数据复盘最怕状态语义漂移,先把每阶段交付写成机器可读 contract:data_sources、evidence_paths、coverage_matrix、verdict、blocker_type、next_owner、superseded_by、review_due_at。1. 统一状态字典和 metadata contract,特别是 blocked / waiting_human / superseded / verified / launch_allowed。 2. 建“数据证据包父任务 → 专业子复盘 → 墨析 fan-in verdict”的固定 DAG。否决让 Atlas 直接写状态;否决 Telegram 承载长上下文;否决单个 Agent 直接给全站 Kill/Scale;否决没有证据包就进入复盘结论。 session_id: 20260617_105846_316e27
motan支持先用 metadata contract,不急着改 Kanban schema;市场侧最需要的是“机会判断可追溯 + 上线后可复盘”,不是更复杂的流程图。1. 定义做站 metadata contract v1,先覆盖市场证据、判决、阻塞、下一棒、superseded。 2. Atlas 首页做“当前判决 + 最大阻塞 + 下一 owner + 5 灯”,不要做全量任务看板复制品。- 否决把 Telegram 当长上下文或状态源。 - 否决所有 board 自动进 Atlas。 - 否决每个阶段都加硬 gate,流程会重到没人愿意走。 - 否决没有关键词/SERP/竞品证据的“值得做”结论。 session_id: 20260617_105858_da47a6
motou支持“先 metadata contract,后 schema 固化”。投放侧必须把 paid readiness 做成独立 gate,但不能让每个站默认进入投放评审重流程。1. 定义统一状态枚举,拆开 `DONE / VERIFIED / BLOCKED / WAITING_HUMAN / SUPERSEDED / BUDGET_EXHAUSTED`。 2. 给 Atlas 增加 paid 卡片:投放结论、阻塞、预算上限、是否需孟健确认。否决所有新站默认自动进广告上线流程;否决把“可投放”埋在普通 DONE 里;否决没有转化追踪和止损线就开预算。 session_id: 20260617_105901_b251b6

完整会议纪要

# 圆桌会议纪要: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 还原真实状态