vault-state-sync-and-note-publishing

name	vault-state-sync-and-note-publishing
description	同步 Vault 中滞后或矛盾的状态，并把 Daily Reflection 里的发布向内容转成可分发 note / package，自动补齐 ToDo、Direction、项目页与双平台成稿。

Vault 状态同步 + note 发布化工作流

适用时机

当用户提到任何“现实里已经发生，但数据库里还没同步”的事实，或当 Daily Reflection 中出现适合外发的判断时使用。

典型触发：

• 用户说“这条已经发了 / 已经做完了 / 这个就是那一篇”
• ToDo、Direction、项目页、Daily Reflection 之间前后不一致
• Daily Reflection 里有一句或一段已经适合做成发布向 note
• 用户提到合集、连续发布、跨平台分发、主页承接等新关系

核心原则

1. 现实结果优先于旧状态；一旦确认事实，应立即回写系统。
2. 不要只改一处。要联想到所有明显受影响的页面，并一次性同步。
3. 先判断 note 的用途：内部思考 vs 发布向内容。
4. 发布向内容优先收编进 media-dopamine 的 package 体系，而不是散落在普通笔记目录。
5. 平台只是分发层；内容对象本体按产出类型管理。
6. 在不增加用户沟通负担的前提下，主动补齐低成本高收益的后续动作。

一次同步时默认要检查的对象

当一个外部结果被确认后，默认至少检查：

• Daily Reflections/YYYY-MM-DD.md
• ToDo.md
• Direction/00_主线状态快照.md
• 当周周更新（如 Direction/2026-W15_主线周更新.md）
• Direction/10_现实信号入口.md
• 对应项目页 / package index.md / publish.md

如果用户明确说是同一合集、同一系列或同一内容线，还要顺手补：

• 合集关系
• 上下篇关系
• 当前阶段从“写作中”切到“已发布待回填 / pending-closure”

状态同步流程

1. 先确认现实事实

优先用可验证来源核实：

• opencli / opencli-operate / browser / 平台记录
• 现有 package 的 publish.md
• 用户刚刚明确补充的事实

2. 找出受影响文件

不要只盯当前页面。要联想到：

• 今日记录页
• 长期任务页
• 判断页 / 周更新
• 对应 package / 项目页

3. 统一更新状态字段

优先更新：

• 当前状态
• next action
• blocker
• completion definition
• note / publish facts

关键判断：

• 如果已经完成外部发布，但还需要承接、复盘、主页回填、数据记录，通常更像 pending-closure 或“已发布待回填”，而不是 pending-start

4. 回写主线判断

如果这条事实属于：

• 外部可见结果
• 主线放大器推进
• 系统结构变化

就要回写到：

• 主线状态快照
• 周更新
• 现实信号入口

Daily Reflection → 发布向 note 的判断规则

不要默认放进 Thinking

当用户说“把 daily reflection 里我自己写的部分转成 note”时，先判断用途：

• 内部思考沉淀 → Thinking/ 或用户既有内部目录
• 后续打磨、对外发布、进入内容生产系统 → Projects/Advertizing/notes/ 或直接进入 AaaS/media-dopamine/packages/notes/

不要过度切碎

如果几句判断属于同一个传播单元：

• 优先合成一篇更完整的 note
• 不要机械地拆成两三篇独立文档

扩写时优先补的 3 层

1. 真实阻力：例如怕输、怕暴露、怕无人回应
2. 心理机制：例如“很多人想要的不是慢慢变强，而是一出现就赢”
3. 行动落点：先上场、先进入现实、用反馈替代脑内预演

发布向短 note 的 package 收编规则

如果内容满足以下特征：

• 短情绪表达
• 可单独传播
• 适合小红书 / 推特等多平台分发

优先创建：

• AaaS/media-dopamine/packages/notes/<slug>/

包内最小结构：

• index.md
• final.md
• publish.md
• review.md
• assets/README.md
• assets/xiaohongshu-final.md
• assets/twitter-final.md
• 适合图文时再补 assets/xhs-card-copy.md

双平台文案处理经验

小红书版

• 保留停顿感、留白感、句子下落感
• 更适合分行、情绪推进、极简图文页

推特版

• 同一核心判断，但压紧段落
• 减少视觉留白，保持连续阅读体验

图文页文案

当一条 note 具备以下特征时，顺手生成 xhs-card-copy.md：

• 句子短
• 情绪张力强
• 核心判断可压缩成 1-2 句
• 适合两页或三页极简图文检查稿

联想补链路规则

用户给出一个新事实时，要主动问自己：

1. 这句话会影响哪些已有状态？
2. 哪些更新是低成本、高收益，应该直接顺手做？
3. 哪些不做会导致用户下一轮还要再提醒一次？

默认优先做“明显应该做”的后续动作，不要停在字面执行。

验证清单

完成前至少确认：

• 现实事实是否已经核实或被用户明确确认
• ToDo / Daily Reflection / Direction / package 是否已经对齐
• 是否还残留“现实已发生，但系统还写成未开始”的矛盾
• 发布向 note 是否进了正确目录或 package
• 双平台成稿是否都可直接使用
• 如果生成了图文页文案，是否真的足够短、可视化、适合检查稿

一句话：

用户说出一个新事实时，不要只更新一句话；要把这条事实真正吃进整个 Vault 和内容系统里。