diff --git a/docs/task/172-任务主键改为采集采购独立序号.md b/docs/task/172-任务主键改为采集采购独立序号.md
new file mode 100644
index 0000000..38bcb81
--- /dev/null
+++ b/docs/task/172-任务主键改为采集采购独立序号.md
@@ -0,0 +1,85 @@
+# 172 Admin：任务主键改为采集 cj 与采购 cg 独立自增编号
+
+- 类型：需求
+- 父级大工单：#14
+- 所属 MVP / 版本：#15 / MySQL schema v13
+- 状态：已完成
+- 日期：2026-08-12
+- Gitea 工单：<http://ilaer.eicp.net:8418/chengma/cmautobuy/issues/172>
+
+## 背景与目标
+
+原采集和采购任务使用随机长编号，不符合客户按业务类型快速报号和
+查询的需求。本任务直接修改 `tasks.task_id` 真实主键：采集任务使用
+`cj1`、`cj2` ……，采购任务使用 `cg1`、`cg2` ……，两套序号独立递增。
+
+## 最终方案
+
+- MySQL schema v13 新增 `task_sequences`，`collect` 和 `purchase` 各占一行。
+- 在创建任务的同一事务内递增序列并插入任务，依靠 InnoDB 行锁防止
+  并发重号；事务回滚不消耗序号。
+- 存量任务按 `task_type` 、`created_at` 、旧 `task_id` 稳定排序改号，同步
+  迁移 `task_claims` 和 `task_syb_sources`，并清理无对应任务的孤儿领取历史。
+- 两张关联表对任务主键使用 `ON DELETE CASCADE ON UPDATE CASCADE`。
+- Client 把任务编号当作不透明字符串原样保存和回传；任务类型仍以
+  `task.type` 为准，不从前缀推导。
+- 页面直接显示真实编号，保留明确的“类型”文字列和编号搜索。
+
+与建单方案的差异：序列值列最初拟名 `last_value`，真实 MySQL 8.4 验证发现
+它与窗口函数关键字冲突，在进入生产前改为 `current_value` 并重新通过全部
+迁移测试。
+
+生产部署前发现 schema v13 已于 2026-08-12 09:16（中国时间）被另一个连接
+生产库的当前源码进程触发。部署前逐项核对表结构、5 条任务、序列、关联
+外键和采购结果，确认它正是本工单迁移且数据完整后，再部署匹配 v13 的新
+二进制。
+
+## 改了哪些
+
+- `admin/repository/mysql_db.go`：新增 v13 迁移、存量改号、外键和 schema 自检。
+- `admin/repository/task.go`：新增事务内的采集/采购独立发号器。
+- `admin/service/pdd.go`、`admin/service/purchase_workflow.go`：所有采集和采购
+  创建入口改用新发号器。
+- `admin/repository/mysql_db_integration_test.go` 及 service 测试：覆盖升级、重放、
+  并发、回滚和两类任务首号。
+- `docs/admin/`、`docs/client/`：同步数据模型、需求、界面和 Client 契约。
+- `client/test/`：使用 `cj1/cg1` 验证 Client 原样接收新任务编号。
+
+## 验收结果
+
+| 验收标准 | 结果 |
+|---|---|
+| 采集任务从 `cj1` 独立递增，采购任务从 `cg1` 独立递增 | 通过 |
+| 并发创建无重号，创建回滚不消耗序号 | 通过 |
+| v12 存量主键、领取历史和顺运宝来源一致迁移，重放不二次改号 | 通过 |
+| 已成功采购的订单号、下单时间和结果 JSON 不变 | 通过 |
+| Client 原样接收并回传新编号，Admin/Client 契约一致 | 通过 |
+| 生产 schema v13 、5 条存量任务和所有关联数据完整，新 Admin 公网可用 | 通过 |
+
+## 测试
+
+- 执行的命令：
+  - `GOTOOLCHAIN=go1.23.0 go vet ./...`
+  - `GOTOOLCHAIN=go1.23.0 go build ./...`
+  - `GOTOOLCHAIN=go1.23.0 go test ./... -count=1`
+  - 在独立的 `autobuy_task172_test` MySQL 8.4 基础库执行 v12→v13、重放、
+    16 并发发号、回滚发号和采集/采购创建测试。
+  - `python -m unittest discover -s test -p 'test_http_admin_gateway.py'`
+  - `python -m unittest discover -s test -p 'test_admin_gateway_contract.py'`
+  - 生产核对 schema、序列、编号正则、采购结果、孤儿关联、systemd 状态、
+    本机及 `https://buy.833729.com/login` HTTP 状态。
+- 结果：Go 静态检查、构建和测试通过；真实 MySQL 8.4 全部目标用例通过；
+  Client 26 项契约测试通过；生产为 schema 13，序列为采集 3/采购 2，
+  5/5 任务编号合规，2/2 成功采购结果完整，无活动采购任务，公网 HTTP 200。
+- **没验证到的部分**：没有为验收而在生产新建真实采购任务，避免产生不必要的真实下单风险；新建路径已在独立 MySQL 8.4 库验证。
+
+## 遗留问题
+
+生产 v13 由另一个连接生产库的当前源码进程在计划停服备份前触发，因此
+本次只能生成迁移后备份 `autobuy-after-v13-before-9ad0675-20260812T012426Z.sql.gz`。
+已确认数据完整并成功部署匹配二进制；以后生产迁移前应确保本地 `run_admin.bat`
+等进程没有连接生产库。
+
+## 相关提交
+
+- `9ad0675` `feat: 任务改用采集采购独立序号 (#172)`