# SeqTK

**为长期复杂任务而做的 Obsidian 项目管理插件。**

用一句话概况理念：切分长线任务的设计与执行，设计阶段不承诺时间，执行阶段不重复设计。

形式上：把「一件事」写成独立节点文档，通过类似 MOC 的方式以从属、状态和依据组织与串联不同节点，形成组合项目

内容上：设计鼓励通过先设计、再分发的形式，将复杂任务进行拆解后再进行分发安排

自动化：（尚未完成由旧版的迁移工作，因为换了数据层的实现方式）让流程与脚本按你定下的规则，不需要即时决策的向你推送下一件要做的事。

---

针对「长期、多并行项目」需求：论文、长线开发、活动筹备、研究跟踪、需要留痕的决策过程。

如果你对我的想法感兴趣，欢迎来找我聊聊：
- QQ 1569830316
- WX Taffy-331

> 需要 Obsidian 1.13.0 或更高 · 桌面与移动端均可用

- 这个插件的开发首先是为了满足我个人需求，因此，我会对其进行长期的更新与维护
- 这个插件正处于重构过程中，目前仅有 **事务设计** 、**模板模式** 、**线路模式** 被确认为完全可用
  - **流程** 相关功能正处于测试中
  - 其余可用视图会进行继续迁移与继续开发
- 等待所有主要视图完善后，会重写 README 与增加教程 WIKI ，目前这里的信息可能是过时的。

---

### 它解决什么问题

其他个人任务管理工具，长线任务通常会难以维护：

1. **结构散乱** —— 没有确切项目层次、生命周期，均以任务、清单为层级管理
2. **组织困难** —— 难以使用文本进行批量编辑或写入，必须依靠其提供的不便利的可视化工具
3. **信息分离** —— 信息和任务项分散在不同软件中，或分散在不同任务项的描述，对长描述、复杂带有结构的描述难以审阅和组织
4. **缺乏设计** —— 无法嵌入和任务同级的信息，这意味着无法针对设计过程留下思考痕迹
5. **规则推送** —— 没有一套根据规则将任务进行推荐的系统，清单上始终会显示完整的待完成项，你始终要对下一件使其想做什么做即时决策，这在任务体量大时很消耗心力

这里要做的，就是在确保可视化的基础上，提高个人长线任务管理的自由度

SeqTK 的做法是把这三件事各归其位，彻底以节点文件形式进行信息管理：

- **结构**交给框架与事务的层级，
- **状态**交给可传播的节点属性，
- **依据**交给挂在节点上的节点。

三者都在同一套节点体系里，可以互相引用、整体重排、批量改写。


---

### 设计取向

- **节点即文档。** 每个节点就是库里的一篇 Markdown 文档。你随时可以离开插件，用 Obsidian 原生方式阅读、搜索、同步、做版本控制——插件不是数据的看门人。
- **关系写进文档，不另立私库。** 从属、顺序、状态、证据都记录在节点文档自身，插件另外维护的只是一份**可随时重建**的查询缓存。
- **设计先于执行。** 先用「事务设计」把结构和依据想清楚，再用「流程草稿 → 流程设计 → 流程推送」把它交给时间和脚本。设计阶段不承诺时间，执行阶段不重复设计。
- **只碰它管的目录。** 插件只在自己的数据根目录内读写节点；你其它笔记不受影响。卸载插件不会丢失任何节点。
- **不替你做决定。** 不强制工作流、你需要自己指定任务投注到时间轴的顺序和位置；破坏性操作（归档、删除）按你配置的确认级别执行。

---

### 核心概念

#### 节点与分类

节点按用途分五类，每一类下面再分具体类型（新建时给你的就是这些具体类型）：

| 分类 | 具体类型 | 用途 |
| --- | --- | --- |
| 框架 | 事务框架、信息框架、模板框架 | 装东西的骨架：一整个项目、一块资料区、一套可复用结构 |
| 事务 | 构想、方向、目标、工序、清单、行动、事件 | 你要推进的事本身，从想法一路拆到可执行动作 |
| 证据 | 对象、条件、信息、状态 | 支持某个事务判断的依据：涉及对象、前置条件、资料线索、快照状态 |
| 运行 | 编辑日志、行为日志、流程状态 | 自动留痕：什么时候发生了什么改动、流程跑到哪一步 |
| 脚本 | 流程脚本、执行脚本、查询脚本 | 把规则写成可执行的东西，让流程按时间或事件自动推进 |

#### 层级与从属

节点之间有明确的从属与顺序，所以「一件事属于哪个阶段、排在第几位」是结构本身，不需要靠标签或命名约定去暗示：

- 框架可以套框架，形成「大项目 → 子项目 → 具体方向」这样的层级；
- 事务沿链条层层拆解（构想 → 方向 → 目标 → 工序；清单 → 事项），每一层只容纳它该容纳的类型，落错位置会被拦住；
- 同级之间有先后顺序，直接拖动即可重排；拖动会自动维护顺序与从属两边的记录，不会出现「看着移了、实际没变」的错位。

#### 状态

事务类节点带状态：**规划 / 进行 / 完成 / 放弃**。另有**正常 / 搁置 / 阻塞**这组附加状态，用来表达「在做、但暂时推不动」。

状态可以按你配置的规则在父子之间传播：父节点进入某状态时把子节点一起改写，或子节点全部达标时向上聚合结果。规则在设置里配置，也可以完全不配。这就是「状态不可见」那一侧的解法——**进度从结构里自动长出来，不用手工维护一份进度表**。

#### 证据

证据是挂在事务节点上的独立节点（对象、条件、信息、状态），不是正文里的一段文字。好处是它可以被单独检索、可以被多个事务复用、可以跨事务连接，也可以在「证据总览」里作为一张关系网整体浏览。外部材料（网页链接、库内文件、时间戳文档）作为「外部信息源」单独挂在节点上，与内部关系互不干扰。

#### 模板、归档与回收

- **模板**：任何一棵子树都可以「存为模板」，之后套用到别的框架上；模板库在「模板模式」里统一管理。
- **归档**：不再活跃但还想留着的东西归档掉，默认视图里不再打扰你；归档时后代的处理方式可以配置。
- **回收**：归档节点集中在「回收模式」里，可以还原，也可以彻底删除（删除的确认级别可配置）。

### 典型用法

**从一段草稿开始。** 把脑子里的想法按缩进写成列表，选中它，用命令或右键菜单提取成节点组，然后在事务设计里继续调整结构：该拆的拆、该挂证据的挂证据、该定状态的定状态。

**边用边定型。** 层级不对就拖，名字不对就用行菜单的「重命名」原地改，一次要改很多就用「以文本批量编辑」把整棵子树导出来改完再回写。整个过程不离开这张双栏界面。

**把成熟结构变成模板。** 某套框架拆法好用，就存成模板；下个项目直接套用，只需要改占位内容。

**让时间接手。** 结构定下来之后，用流程草稿排出并行事件轴、敲定起止时间；再用流程设计写成推送规则；日常工作时侧栏的流程推送会告诉你此刻该做什么。

**收拾现场。** 做完的事归档，需要时在回收模式里还原；过时的彻底删除。