AtomWeb 内容 schema 与未来行动足迹图谱讨论记录

本仓库是 AtomWeb 的内容子仓库，只负责维护内容源。schema、站点功能和内容渲染逻辑应在主仓库中开发。本文记录一次关于 ideas 内容类型和未来内容关系图谱的讨论，供主仓库开发 session 进一步设计。

当前 schema 调整建议

1. Ideas 的语义边界

ideas 不是项目生命周期记录，而是「项目想法 / 概念判断」的内容类型。

因此，ideas.status 不应承担完整项目阶段管理。项目是否已做、做到了什么程度，应由 works / projects 等内容类型表达。ideas 只负责表达一个想法目前处于怎样的思考状态。

2. Ideas status 建议

建议将 ideas.status 调整为：

type IdeaStatus =
  | "Just Come Up"
  | "Draft"
  | "Validated"
  | "Archived"
  | "Scrapped"
  | "implementation";

语义如下：

• Just Come Up：刚冒出来的 idea，只是先记录下来，还没有系统展开。
• Draft：已经初步整理成一篇可阅读、可讨论的 idea 文档。
• Validated：已经认真盘过，认为有真实价值，值得未来推进。
• Archived：暂时搁置，但不等于否定，未来可能重新打开。
• Scrapped：明确放弃，或被其他 idea 替代。
• implementation：这个 idea 已经真的流转到制作中了。

说明：不建议使用 Brainstorming 作为 status，因为 brainstorming 是作者接下来要做的动作，不是 idea 本身所处的稳定阶段。

3. 关系字段建议

建议为 ideas 增加：

relatedIdeas:
  - "ideas/example.md"

relatedWork:
  - "works/example.md"

约束建议：

• relatedIdeas 可以存在于所有 ideas 中。
• relatedIdeas 也应该允许存在于项目 / works 内容类型中，用来表达一个项目和哪些想法有关。
• 当 status !== "implementation" 时，relatedWork 必须不存在或为空。
• 当 status === "implementation" 时，relatedWork 必须存在且非空。
• relatedWork 表达这个 idea 已经进入实际制作对象或作品条目。

设计意图：

• ideas 负责记录想法本身。
• works / projects 负责表达实际制作出来或正在制作的项目。
• relatedIdeas 表达概念之间的关系。
• relatedWork 表达 idea 到实际制作对象的流转关系。

未来版本发展想法

行动足迹图谱 / Obsidian 式知识图谱

长期来看，希望 AtomWeb 不只是一个作品集或内容列表，而是逐渐形成一张个人行动与思考的知识图谱。

这个想法参考 Obsidian 的体验：不同笔记之间通过链接自然生长关系。随着时间积累，ideas、thoughts、works/projects、impact 等内容类型会互相连接，最后形成一张可视化图谱，展示一个人如何产生想法、如何思考、如何验证、如何把想法变成项目，以及项目又如何反过来影响后续判断。

可能的节点包括：

type ContentNodeType =
  | "idea"
  | "thought"
  | "work"
  | "impact";

可能的关系包括：

type ContentEdgeKind =
  | "related"
  | "references"
  | "inspired-by"
  | "evolved-into"
  | "implemented-as";

但这个方向不建议在当前版本直接做成复杂 zod 约束。

复杂度边界

这个图谱应该是未来版本能力，不应该让当前内容写作变重。

建议原则：

• 当前 zod 只增加少量必要关系字段。
• 不要一开始就在 frontmatter 中强制维护完整图谱。
• 正文中的自然链接可以以后支持类似 Obsidian 的 [[...]] 写法。
• 图谱应由主仓库的 graph builder 从 frontmatter 和正文链接中派生生成。
• 缺失或无法解析的正文链接前期应作为 warning，而不是阻断发布。
• 不应要求作者手动维护一份独立 graph 数据库。

也就是说，当前阶段采用：

relatedIdeas?: string[];
relatedWork?: string[];

未来阶段再考虑：

parseFrontmatterRelations();
parseWikiLinks();
buildBacklinks();
generateKnowledgeGraph();
renderGraphView();

目标是保留长期图谱的可能性，但不把复杂性提前压到内容 schema 上。

待主仓库 session 决定

具体开发细节由主仓库开发 session 再确认：

• status enum 是否使用展示名，还是机器友好的 kebab-case。
• relatedIdeas / relatedWork 使用路径字符串数组，还是对象数组。
• 主仓库内容类型到底叫 works、projects，或二者并存。
• zod refine / superRefine 的具体实现。
• 现有内容迁移策略。
• 图谱能力是否先只做数据派生，后续再做可视化页面。