yovision/docs/tasks/T-002.md

id, title, phase, deps, status, created, issue, context_ref, claim_branch, work_branch, write_paths

id	title	phase	deps	status	created	issue	context_ref	claim_branch	work_branch	write_paths
T-002	关闭架构影响型需求开放问题	0		DOING	2026-08-03	2	96a64df98f	claims/T-002	agent/codex/T-002	docs/tasks/T-002.md docs/raw/01-需求收集.md docs/01-vision.md docs/02-requirements.md docs/03-tech-stack.md docs/04-architecture.md docs/current-state.md

问题 / 背景

docs/raw/01-需求收集.md §8 中仍有会改变架构、合规或工作量的问题。M0 出口要求关闭这些问题，否则 M1/M3 可能在错误假设上开发。

关联需求与交互（如适用）

• 用户故事：影响 US-001～US-006，具体由决策结果确定。
• 交互清单：本任务不实现 UI；若决策改变 UI 范围，必须同步 IX。
• 来源：docs/raw/01-需求收集.md §8 的 Q1、Q2、Q4–Q12。

方案

1. 为每个开放问题指定产品/客户/技术/法务责任人和最晚决策点。
2. 记录选项、证据、决策、日期、批准人、受影响里程碑和撤销条件。
3. 回填原始需求，并同步 harness 愿景、需求、技术栈、架构与当前状态。
4. 仍不能关闭的问题必须转为明确 blocker，说明阻塞哪个任务和可继续的安全范围。

不可变约束

• 阈值 / 数值边界：默认 16、最大 128 的已定容量不在本任务中降级或改写。
• 判定式 / 状态转换：没有责任人、证据和影响分析的口头意见不算“已关闭”。
• 安全边界：法务、许可证、人脸和未成年人数据问题不得由 agent 代替授权人拍板。
• 既有契约：事件 v0.1 字段不随开放问题原地修改；需要变化时单独发起契约版本任务。

验收要点

• 任务相关验证：Q1、Q2、Q4–Q12 每项有闭环记录或明确 blocker；摘要与原始文档一致；运行三条 harness 治理命令。
• 完整门禁：若修改 schema/API/路由，触发对应契约与导航完整检查。
• 人工 / 设备验收：必需；产品负责人确认范围，法务确认合规项，技术负责人确认架构影响。
• 构建产物：不适用。

边界（不改什么）

不实现生产代码，不自行选择客户、前端框架、硬件或供应商，不修改已冻结事件契约。

协作约束

• 责任 Agent：codex。
• 唯一写入者：codex；外部责任人只提供决策和证据。
• 委派：默认不启用。
• Gitea：主 Issue 为 #2；context_ref 为 96a64df98f39f44ae01090fe566979f8209b5570，claim 为 claims/T-002，工作分支为 agent/codex/T-002。

任何新增写路径先由 dispatcher 与活跃任务做前缀冲突检查。

执行记录

2026-08-03 领取与基线

• dispatcher ila 已将任务分配给 codex，Issue #2 已切换为 status/doing。
• claim 与工作分支均从精确 context_ref 96a64df98f39f44ae01090fe566979f8209b5570 创建并读回一致。
• 在独立 worktree D:\OPC\yovision-T-002 运行 ./init.ps1：上下文校验、16 个治理单测和完整治理检查全部通过。