README file from
GithubSeqTK
为长期复杂任务而做的 Obsidian 项目管理插件。
用一句话概况理念：切分长线任务的设计与执行，设计阶段不承诺时间，执行阶段不重复设计。
形式上：把「一件事」写成独立节点文档，通过类似 MOC 的方式以从属、状态和依据组织与串联不同节点，形成组合项目
内容上：设计鼓励通过先设计、再分发的形式，将复杂任务进行拆解后再进行分发安排
自动化：（尚未完成由旧版的迁移工作，因为换了数据层的实现方式）让流程与脚本按你定下的规则，不需要即时决策的向你推送下一件要做的事。
针对「长期、多并行项目」需求：论文、长线开发、活动筹备、研究跟踪、需要留痕的决策过程。
如果你对我的想法感兴趣，欢迎来找我聊聊：
- QQ 1569830316
- WX Taffy-331
需要 Obsidian 1.13.0 或更高 · 桌面与移动端均可用
- 这个插件的开发首先是为了满足我个人需求，因此，我会对其进行长期的更新与维护
- 这个插件正处于重构过程中，目前仅有 事务设计 、模板模式 、线路模式 被确认为完全可用
- 流程 相关功能正处于测试中
- 其余可用视图会进行继续迁移与继续开发
- 等待所有主要视图完善后，会重写 README 与增加教程 WIKI ，目前这里的信息可能是过时的。
它解决什么问题
其他个人任务管理工具，长线任务通常会难以维护：
- 结构散乱 —— 没有确切项目层次、生命周期，均以任务、清单为层级管理
- 组织困难 —— 难以使用文本进行批量编辑或写入，必须依靠其提供的不便利的可视化工具
- 信息分离 —— 信息和任务项分散在不同软件中，或分散在不同任务项的描述，对长描述、复杂带有结构的描述难以审阅和组织
- 缺乏设计 —— 无法嵌入和任务同级的信息，这意味着无法针对设计过程留下思考痕迹
- 规则推送 —— 没有一套根据规则将任务进行推荐的系统，清单上始终会显示完整的待完成项，你始终要对下一件使其想做什么做即时决策，这在任务体量大时很消耗心力
这里要做的，就是在确保可视化的基础上，提高个人长线任务管理的自由度
SeqTK 的做法是把这三件事各归其位，彻底以节点文件形式进行信息管理：
- 结构交给框架与事务的层级，
- 状态交给可传播的节点属性，
- 依据交给挂在节点上的节点。
三者都在同一套节点体系里，可以互相引用、整体重排、批量改写。
设计取向
- 节点即文档。 每个节点就是库里的一篇 Markdown 文档。你随时可以离开插件，用 Obsidian 原生方式阅读、搜索、同步、做版本控制——插件不是数据的看门人。
- 关系写进文档，不另立私库。 从属、顺序、状态、证据都记录在节点文档自身，插件另外维护的只是一份可随时重建的查询缓存。
- 设计先于执行。 先用「事务设计」把结构和依据想清楚，再用「流程草稿 → 流程设计 → 流程推送」把它交给时间和脚本。设计阶段不承诺时间，执行阶段不重复设计。
- 只碰它管的目录。 插件只在自己的数据根目录内读写节点；你其它笔记不受影响。卸载插件不会丢失任何节点。
- 不替你做决定。 不强制工作流、你需要自己指定任务投注到时间轴的顺序和位置；破坏性操作（归档、删除）按你配置的确认级别执行。
核心概念
节点与分类
节点按用途分五类，每一类下面再分具体类型（新建时给你的就是这些具体类型）：
| 分类 | 具体类型 | 用途 |
|---|---|---|
| 框架 | 事务框架、信息框架、模板框架 | 装东西的骨架：一整个项目、一块资料区、一套可复用结构 |
| 事务 | 构想、方向、目标、工序、清单、行动、事件 | 你要推进的事本身，从想法一路拆到可执行动作 |
| 证据 | 对象、条件、信息、状态 | 支持某个事务判断的依据：涉及对象、前置条件、资料线索、快照状态 |
| 运行 | 编辑日志、行为日志、流程状态 | 自动留痕：什么时候发生了什么改动、流程跑到哪一步 |
| 脚本 | 流程脚本、执行脚本、查询脚本 | 把规则写成可执行的东西，让流程按时间或事件自动推进 |
层级与从属
节点之间有明确的从属与顺序，所以「一件事属于哪个阶段、排在第几位」是结构本身，不需要靠标签或命名约定去暗示：
- 框架可以套框架，形成「大项目 → 子项目 → 具体方向」这样的层级；
- 事务沿链条层层拆解（构想 → 方向 → 目标 → 工序；清单 → 事项），每一层只容纳它该容纳的类型，落错位置会被拦住；
- 同级之间有先后顺序，直接拖动即可重排；拖动会自动维护顺序与从属两边的记录，不会出现「看着移了、实际没变」的错位。
状态
事务类节点带状态：规划 / 进行 / 完成 / 放弃。另有正常 / 搁置 / 阻塞这组附加状态，用来表达「在做、但暂时推不动」。
状态可以按你配置的规则在父子之间传播：父节点进入某状态时把子节点一起改写，或子节点全部达标时向上聚合结果。规则在设置里配置，也可以完全不配。这就是「状态不可见」那一侧的解法——进度从结构里自动长出来，不用手工维护一份进度表。
证据
证据是挂在事务节点上的独立节点（对象、条件、信息、状态），不是正文里的一段文字。好处是它可以被单独检索、可以被多个事务复用、可以跨事务连接，也可以在「证据总览」里作为一张关系网整体浏览。外部材料（网页链接、库内文件、时间戳文档）作为「外部信息源」单独挂在节点上，与内部关系互不干扰。
模板、归档与回收
- 模板：任何一棵子树都可以「存为模板」，之后套用到别的框架上；模板库在「模板模式」里统一管理。
- 归档：不再活跃但还想留着的东西归档掉，默认视图里不再打扰你；归档时后代的处理方式可以配置。
- 回收：归档节点集中在「回收模式」里，可以还原，也可以彻底删除（删除的确认级别可配置）。
典型用法
从一段草稿开始。 把脑子里的想法按缩进写成列表，选中它，用命令或右键菜单提取成节点组，然后在事务设计里继续调整结构：该拆的拆、该挂证据的挂证据、该定状态的定状态。
边用边定型。 层级不对就拖，名字不对就用行菜单的「重命名」原地改，一次要改很多就用「以文本批量编辑」把整棵子树导出来改完再回写。整个过程不离开这张双栏界面。
把成熟结构变成模板。 某套框架拆法好用，就存成模板；下个项目直接套用，只需要改占位内容。
让时间接手。 结构定下来之后，用流程草稿排出并行事件轴、敲定起止时间；再用流程设计写成推送规则；日常工作时侧栏的流程推送会告诉你此刻该做什么。
收拾现场。 做完的事归档，需要时在回收模式里还原；过时的彻底删除。