# proj · 项目对接协议 v0.2（task card）

朋友/合作方之间共同做项目的 Agent 对接协议。当前以 **git 仓库为真相层**（API 未上线）：协议、卡片、状态板都在仓库里，改动有 diff 可查。

## 一条原则

**没有验收标准的卡，不允许开工；没有决策人的卡，不允许排期。**

项目沟通的浪费不在执行，在三件事：需求没写清、验收没对齐、变更没留痕。这份协议只解决这三件。

## task card：任务交接的最小单元

`.proj/cards/YYYY-MM-DD-标题.md`，front-matter：

```yaml
id: TC-YYYYMMDD-NN
title: 一句话说清做什么（动词 + 对象 + 结果）
owner: 执行者          # 一个人，不是"大家"
reviewer: 验收者       # 必须与 owner 不同人
decision_owner: 拍板人 # 范围/验收有争议时找谁
status: todo           # todo / doing / blocked / review / done
depends_on: []         # 其他卡片 id
deadline: 2026-11-05
hard_deadline: false   # 是否对外承诺/合规/对账类硬时限
outcome: |
  做成之后，谁的行为怎么变（一到两句）
non_goals: |
  这次明确不碰的 1-3 件事
acceptance:            # 必须可勾选、可当场验证
  - [ ] 具体到能当场验证的一条
  - [ ] 数据/口径与既有系统对得上（写明对哪个）
evidence: []           # 交付后填：链接、截图、diff、验收记录
context: |
  背景一段话：为什么现在做、以前怎么处理、有哪些坑
```

## 从一句话到卡片（六问）

收到「那个事你弄一下」，不要直接建卡。一次一问，问完六件再落卡：

1. **现象**：现在具体哪里不对？最近一次发生是什么时候、什么表现？
2. **目标**：做成之后，谁的行为会变？变成什么样？
3. **不做**：这次明确不碰什么？
4. **验收**：怎么算完成？给我一条能当场验证的句子（谁、看什么、达到什么）。
5. **时限**：什么时候要？硬性原因是什么？最晚能拖到哪天？
6. **决策人**：范围变了、验收有争议时，谁拍板？

答不齐就不建卡——这比建一张含糊的卡省时间。完整追问话术见 `/proj/SKILL.md`。

## 接卡确认（四步，做完才改 doing）

1. **复述**：把目标、范围、验收、时限用自己的话讲回去。
2. **找缺口**：有没有无法当场验证的验收项？依赖写全了吗？有就退回补卡。
3. **给方案**：一句话说怎么做、预计多久、需要对方配合什么。
4. **落状态**：确认后 `todo → doing`，留一条 comment 写下承诺完成时间。

## 状态机与权限

```
todo ──接卡确认──> doing ──提交验收──> review ──通过──> done
  ↑                  │  ↑                │
  │                  ↓  │                └──不通过（写清哪条没过）──> doing
  └──── 退回补卡 ──── blocked（写明等谁、等什么、从哪天起）
```

| 动作 | 谁能做 | 规则 |
|---|---|---|
| 建卡 | 发起方 | 六问答齐 |
| status → doing | 接手方 | 先完成四步确认 |
| status → blocked | 接手方 | 必须写清等谁、等什么、从哪天起 |
| status → review | 接手方 | 附 evidence（链接/截图/命令输出） |
| review → done | reviewer | 逐条勾 acceptance，勾不了就退回 |
| 改验收/范围 | 发起方 + decision_owner | 写变更理由，重估时间 |
| 改别人的卡 | 任何人 | 只能加 comment，不能直接改 status |

**阻塞超过 24 小时必须升级到人**：由 decision_owner 决定等、绕、砍还是换人。

## 沟通节奏

| 频率 | 谁对谁 | 内容 | 形式 |
|---|---|---|---|
| 每天 | Agent → 共享频道 | 今日完成 / 明日计划 / 阻塞（只列事实） | 自动生成，人不用开口 |
| 每天 | 对方 Agent → 自己主人 | 摘要对方日报，只上浮需要决策的事 | 自动 |
| 每周 15 分钟 | 人对人 | 只过阻塞、范围变更、下周取舍 | 视频/当面 |
| 随时 | 人对人 | 只有三类：决策、冲突、坏消息 | 其余一律进卡片 comment |

**坏消息必须当天说**：延期、做不出来、方向错了——早说 24 小时，价值大于任何解释。

## 评审礼仪

1. 48 小时内给结论；给不了就先说「我周五前看完」，不让对方停摆。
2. 结论只有三种：**通过** / **不通过（逐条指哪条 acceptance 没过）** / **改验收（说明原验收为何不成立）**。
3. 不评价人，只评价交付物与验收标准；不通过时给一条可执行的下一步。
4. 通过时把 evidence 链接补进卡里——这是下次复用的证据。

## 变更管理

- 需求变更是常态；**改卡不是失败，不改卡偷偷做才是**。
- 三步：写变更理由 → 重估时间 → 通知 reviewer。
- 范围超过原估算 30%，或交付推后超过一周：重新开卡，旧卡标 `cancelled` 并写明原因。
- 进入 `review` 后冻结需求；要改就退回 `doing`，不允许边验收边加需求。

## 收尾

1. 交付物链接、验收记录、踩坑记录回填进卡。
2. 复盘三问（10 分钟，双方各答）：哪里估错？哪里返工？下次协议改哪条？
3. 可复用的部分抽出来（模板/脚本/检查清单），写进项目资产，不留在聊天记录里。

## 边界

- 这套卡是**协作工具，不替代合同/报价/付款条款**。
- 涉密数据不进公开仓库；需要共享的文件走私有环境或脱敏版本。
- 对方没有 Agent 也能用：把卡当模板填，效果一样——同一扇门。