Files
cmbuyer/docs
QiuSWandClaude Opus 5 3c458bcf5b fix(tasks): make status git-authoritative, not Vikunja
修掉一处会让并行保护失效的设计缺口:AGENTS.md 声明「状态」权威在 Vikunja,
但离线门禁的检查 1 读的是 frontmatter 的 status,两者之间没有任何同步。
有人在看板上拖了卡片,frontmatter 不变,门禁就用过期数据放行了。

status 的权威定为 git frontmatter,理由与 write_paths 相同:它是判定
「两个活跃任务不得写同一路径」的输入,而门禁必须离线可跑;status 变更
决定谁能碰哪些文件,本来就该产生 commit。

- AGENTS.md:把 status 从 Vikunja 权威列表移入 git 原生表,并说明 bucket
  与 done 仅为人类视图,不一致时以 git 为准
- agent-context.json:tracker.git_native_fields 增加 status
- validate_agent_context.py:强制 git_native_fields 必须含 status,
  已用反例验证缺失时报错
- vikunja_export.py:新增只读漂移检测,导出时比对 frontmatter status 与
  Vikunja done,不一致则提示;只提示不修正,不反向写回
- docs/tasks/README.md、T-008 方案第 1/2 节:同步口径

顺带解决了窄 token 时期的 bucket 401 遗留问题——status 权威在 git,
agent 不再依赖 bucket 移动来表达状态。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 17:17:35 +08:00
..

项目文档导航

一句话定位

cmbuyer 是一个自动化采购系统:采购服务(网页端,admin/)负责建单与人工决策, 采购工具(Windows 桌面端,client/)驱动 Android 手机在拼多多完成选规格和下单, 付款始终由人完成。第一版先跑通「手工建单 → 定时领取 → 第一趟试选 → 人工确认 → 第二趟下单 → 待付款」闭环。

文档导航

任务 / 状态职责

  • tasks/(docs/tasks/T-<编号>.md):任务规格、依赖、状态(frontmatter)和执行记录。
  • 06-tasks.md:路线图,阶段划分与里程碑,不跟踪单任务状态。
  • current-state.md:当前快照,可覆盖更新。

必读的四处硬约束

新接手时如果只看四个地方,看这四个:

  1. 04-architecture.md 第三节两趟执行与三道价格闸门——为什么 分两趟、价格为什么只在两个地方读。
  2. 04-architecture.md 第四节安全边界与提交订单四条件——每条 都要有测试。
  3. 05-coding-rules.md 第 1 节红线——违反即拒绝。
  4. 00-ai-start-here.md 四条特有纪律——先取证、只收紧、 只在两处读价、第一趟不下单。

维护原则

  • 需求变化先改文档,再改代码。
  • 代码现实变化后同步 current-state.md;执行证据写进对应任务文件。
  • API、数据模型、路由、技术栈一旦定稿,代码不得另起一套。
  • 前序项目 cmroubao / cmpdd 是设计依据,不是事实来源。
  • agent 开始新任务前,必须从 00-ai-start-here.md 进入。