做事从下往上，看事从上往下——同一棵树，两个遍历方向。
飞飞同时在推进汉堡MVP、灯箱首单、日本签证、涮肉馆运营……这些项目性质不同、节奏不同、合作方不同，但都在同一个对话里流动。
真正的问题不是"怎么记录"，而是：当你说了一件事，我怎么知道它属于哪里，该做什么？
没有一套"项目更新触发什么动作"的元规则，每个项目各自为政，靠经验判断要不要更新文件，容易漏。这才是症结。
不用平铺列表，用树状结构——长期项目是树干，短期项目是枝叶。
出海日本、Nomi成长。里程碑级别才更新。有战略背景和决策历史。
汉堡MVP、灯箱首单。每次有进展就更新。完成后归档不删除。
短期项目可以归属于长期项目。国内练能力维持现金流，出海换位置积累势能——两者是同一棵树的根和冠。
这不只是项目管理技巧。这是认知与执行的分离——两者用的是同一棵树，但遍历方向相反。
执行时从下往上，是因为你只能站在当下这个节点行动。
研究时从上往下，是因为只有站在高处才能看到节点之间的关系。
这个发现对应了三条道。飞飞说这是"现实世界的物理规律"——做事和看事方向相反，两者缺一不可，合在一起才构成完整的事件。
决策（go/no-go）、里程碑（阶段完成）、阻塞解除、新信息（改变判断的输入）
闲聊、脑暴、探索性讨论——这些是思考过程，不是状态变化
追加时间线条目 + 更新 projects.md 对应条目 + 写 daily notes
轻量动作 + 更新状态区块 + 部署网页 + 发 Telegram Topic + 更新索引
整棵树的鸟瞰图。每个项目只存"现在在哪"——状态、下一步、阻塞项。从上往下看用这个。
每个项目的完整过程记录。决策历史、关键人物、时间线、素材。随项目推进自然成长。
即使上下文压缩后也会注入的规则。项目树结构、专题模板、触发规则、更新分级。
memory/project-template.md，填完 frontmatter这套系统建立之后，项目管理不再是额外的认知负担——它藏在对话里，自动运转。