Story 资料与生命周期:现状及目标边界

蓝色为外部事实,绿色为本地执行,橙色为本次新增的长期上下文。虚线表示需要明确同步规则。

TAPD Story:外部需求事实

身份:workspace_id + TAPD item id

拥有:标题、负责人、优先级、截止时间、TAPD 状态、原始描述/附件

不应拥有:AI 当前阶段、session 状态、重试次数、执行上下文

本地 Story:开发执行聚合根

身份:story_key;通过 source_type/source_id 关联 TAPD

拥有:workspace、profile、stage、status、执行次数、错误、审计事件

当前已有:branches_json、context_json、TAPD 元数据镜像

新增:Story 长期资料包(持久化、可编辑、可注入)
范围

影响项目 / 仓库

需求

PRD 文档引用

设计

设计文档引用

代码

每项目对应分支

数据

DDL 文件或变更说明

配置

Nacos 变更项与环境

原则:这是“跨 session 仍然有效的事实”,不和临时推理、错误信息、运行标记混在同一个 JSON 中。

↓ 每次启动或重新开启 session 时生成快照
Context Resolver(只读事实)

读取 TAPD 镜像、本地资料包、当前 stage、workspace 中可用文档。

校验路径、缺失项和结构,不产生启动 session 等副作用。

Prompt Renderer → AI Session

渲染统一的“Story 长期上下文”章节。

新 session、恢复执行、重试阶段使用同一份解析结果,避免入口间行为漂移。

建议的双生命周期

TAPD 生命周期

待处理 → 处理中 → 已实现/待验证 → 已完成/关闭

业务协作状态,由 TAPD 工作流定义。

本地 Story 生命周期

已同步 → 待启动 → 执行中 → 暂停/阻塞 → 完成/终止

AI 编排状态,由本地状态机定义。

关键点:两套状态相关但不等价,不能用一个 status 字段互相覆盖。状态映射应产生“建议动作”,真正回写 TAPD 需要显式策略。