QiuSWandClaude Opus 5
ed489bd13e
窄权限 token 实测无法移动 kanban bucket（POST /projects/{p}/views/{v}/
buckets/{b}/tasks 返回 401，bucket 操作需要 project 级权限），导致
TODO / DOING / BLOCKED 的状态流转 agent 无法驱动。权衡后改用全量 token，
代价已在 T-008 方案第 5 节写明：任何配置此 MCP 的 agent 都持有该实例的
完整读写权，且 apiurl 走 http 公网 DDNS，token 明文过网。
AGENTS.md 增加各家 agent 的 MCP 配置片段（Claude Code 的 .mcp.json 与
Codex CLI 的 ~/.codex/config.toml），统一指向 scripts/vikunja-mcp.sh，
并明确任何配置文件内不得内联凭据——token 只存在于 vikunja.env。
看板卡片已归位：Doing #15，Done #12/#13/#14。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
项目文档导航
一句话定位
cmbuyer 是一个自动化采购系统：采购服务（网页端，admin/）负责建单与人工决策，
采购工具（Windows 桌面端，client/）驱动 Android 手机在拼多多完成选规格和下单，
付款始终由人完成。第一版先跑通「手工建单 → 定时领取 → 第一趟试选 → 人工确认 →
第二趟下单 → 待付款」闭环。
文档导航
../AGENTS.md：Codex / 通用 AI coding agent 的仓库级入口。../CLAUDE.md：Claude Code 的薄入口，规则以AGENTS.md为准。- AI 开发入口：agent 每次开始工作的入口、阅读顺序、任务领取规则， 以及本项目的四条特有纪律。
- 项目愿景：为什么做、为谁做、非目标、与前序项目的关系。
- 需求：功能清单、验收标准、风险点。
- 用户故事清单：US 编号、用户目标与验收场景。
- 技术栈：两端选型、运行命令、验证矩阵。
- 架构设计：双端职责、两趟执行、三道价格闸门、安全边界、数据模型。
- 编码规则：硬约束，第 1 节是本项目红线。
- 任务路线图：阶段划分、里程碑、建议拆分清单。
- 任务文件：一任务一文件约定与真机验收要求。
- API 合约：双端之间的唯一权威，含设备侧接口与本地模块合约。
- 路由与页面结构：采购服务页面路由与采购工具界面结构。
- 交互清单：IX 编号、状态与异常清单、无障碍要求。
- 设计原型输入约定：单文件 HTML 低保真原型的形态与边界。
- 当前实现状态：当前快照、可运行命令、下一步任务、已知风险。
- Agent 上下文清单 /
agent-context.json/ Schema：按任务类型选择文档。 - 收尾检查清单：会话结束前逐项检查。
- 方法对照表：失败模式 → 首要修复 → 工件。
- 评审评分表：单次会话输出的结构化评审。
- 质量文档：代码库长期健康度追踪。
../scripts/validate_agent_context.py：零依赖校验 上下文清单与仓库相对路径。
任务 / 状态职责
tasks/（docs/tasks/T-<编号>.md）：任务规格、依赖、状态（frontmatter）和执行记录。06-tasks.md：路线图，阶段划分与里程碑，不跟踪单任务状态。current-state.md：当前快照，可覆盖更新。
必读的四处硬约束
新接手时如果只看四个地方，看这四个：
04-architecture.md第三节两趟执行与三道价格闸门——为什么 分两趟、价格为什么只在两个地方读。04-architecture.md第四节安全边界与提交订单四条件——每条 都要有测试。05-coding-rules.md第 1 节红线——违反即拒绝。00-ai-start-here.md四条特有纪律——先取证、只收紧、 只在两处读价、第一趟不下单。
维护原则
- 需求变化先改文档，再改代码。
- 代码现实变化后同步
current-state.md；执行证据写进对应任务文件。 - API、数据模型、路由、技术栈一旦定稿，代码不得另起一套。
- 前序项目
cmroubao/cmpdd是设计依据，不是事实来源。 - agent 开始新任务前，必须从
00-ai-start-here.md进入。