Story 长期资料：三种存储方案

请选择更符合长期维护预期的方案。重点比较多项目关联、AI 自动发现、证据审计和 Web 编辑能力。

story.context_json

projects: [...]

documents: [...]

changes: [...]

A. 扩展现有 context_json

改动最小，直接把所有资料塞进当前运行上下文。

优点

  • 实现快
  • 迁移少

问题

  • 长期事实与临时运行状态混杂
  • 并发更新易覆盖
  • 查询、审计、局部编辑困难
story_context 表

story_key

document_json

version / updated_at

B. 独立 JSON 文档

把长期资料从运行上下文中分离，但仍作为一个整体文档保存。

优点

  • 边界清楚
  • 读取和生成快照简单
  • 支持版本号防覆盖

问题

  • 项目/变更项难独立查询
  • 单项确认与证据历史较笨重
  • 后续发布清单仍需解析 JSON
结构化实体 + 注入快照

story_project

story_document

story_change_item

→ Context Snapshot

C. 结构化表（推荐）

项目、文档和 DDL/Nacos 变更分别建模，session 启动时生成只读快照。

优点

  • 按项目管理清晰
  • 证据、状态和确认可独立审计
  • 便于 Web 编辑、自动发现和发布检查

代价

  • 表和 API 较多
  • 首期实现量最大

我的推荐

选择 C，但控制为三个核心实体。不做通用 CMDB，也不把每个字段拆成独立表。结构化存储负责事实与审计，Context Resolver 负责生成给 AI 的轻量目录。