Obsidian Case Workspace Sync

Obsidian 案件工作台同步

一、用途

本技能解决“这个案件已经收到什么、读过什么、形成过什么文书、当前方案是什么、后续新增材料改变了什么”。它不代替民商事或刑事业务技能作实体分析，而是接收其已经形成的分析结果并持续登记。

默认 Vault：/Users/liudejun/Desktop/材料/04codex/本地知识库

默认案件位置：01 我的工作台/04 案件工作台/<案件名称>/

二、同步判断的硬规则

1. 读取案件文件夹或者成组案件材料后，必须同步

凡本次任务通过读取案件文件夹、法院材料文件夹、委托人材料文件夹、证据文件夹、刑事卷宗文件夹或者一组成体系的案件材料，完成下列任一工作，必须建立或更新案件工作台：

• 案情分析、证据分析或者法律意见；
• 金额计算或者复核；
• 起诉状、答辩状、代理词、上诉状、质证意见、证据目录、申请书等民商事文书；
• 会见意见、取保申请、不捕意见、不诉意见、阅卷报告、辩护词、刑事上诉材料等刑事成果；
• 对原有诉请、抗辩、辩护方案或者证据安排作出实质调整。

不得以“本次只读取了部分文件”“形成的不是主要文书”或者“文书较简单”为由省略同步。只要本次工作依赖对案件文件夹或者成组案件材料的读取，就属于同步节点。

2. 后续单独形成材料时，先判断是否关联既有案件

本次没有重新读取整个案件文件夹，只是单独起草、修改或者形成一份材料时，例如撤诉申请书、延期举证申请、退费申请、财产保全申请、补充代理意见或者庭后说明，应当先判断该材料是否属于已经建立案件工作台的案件：

• 能够通过案件文件夹路径、案号、当事人名称、案件名称或者已有工作台索引明确匹配的，必须增量同步；
• 能够确认属于既有案件，但当前文件未放在原案件文件夹内的，仍应登记到该案件工作台；
• 无法确认关联关系时，不得猜测归档，可暂不同步并标记待确认；
• 本案从未建立工作台，本次也未读取案件文件夹或成组案件材料，只是孤立起草一份简单材料的，不因该材料单独新建案件工作台。

3. 轻微修改的处理

• 单纯改标点、字体、分页或者不改变事实和方案的轻微润色，不单独形成同步节点；
• 但如果对应案件工作台已存在，且本次形成了新的正式版本或者文件状态由初稿变为定稿，应只登记文书版本和形成时间，不重新分析案件；
• 修改涉及事实、金额、请求、抗辩、辩护观点、证据安排或者程序进展的，必须同步相关变化。

详细判断规则见：references/sync-routing.md

三、时间增量原则

同步前先读取：

1. 00_案件总览.md中的“最后同步时间”；
2. 08_阶段纪要.md中的最近一次同步记录；
3. _sync_manifest.json中的文件路径、哈希、修改时间和读取状态。

以上一次同步时间为起点，优先检查此后：

• 新收到或者新形成的材料；
• 新增文件；
• 内容发生变化的既有文件；
• 上次已存在但尚未读取或尚未登记的文件；
• 本次新形成的文书和分析成果。

不得每次同步都重新分析全部旧材料。旧材料只有在以下情况下才回查：

• 新材料与旧材料发生冲突；
• 新材料改变了事实、金额、诉请、抗辩或辩护方案；
• 需要核实新文书引用的具体事实、证据或者页码；
• 旧摘要明确标记为未核实或待补完整版本。

时间用于确定增量范围，哈希和文件状态用于校验是否真正新增或变化。不得仅因文件系统修改时间改变就重新读取内容；也不得仅依赖时间而漏掉内容变化但时间异常的文件。

四、案件目录

默认建立：

• 00_案件总览.md
• 01_材料接收台账.md
• 02_事实时间线.md
• 03_证据与证明事项.md
• 04_诉讼请求_抗辩或辩护方案.md
• 05_金额计算底稿.md（无金额时可不建）
• 06_文书及工作记录.md
• 07_待办事项与补证清单.md
• 08_阶段纪要.md
• _sync_manifest.json
• 原始材料/、法院或办案机关材料/、对方材料/、委托人材料/、我方证据/、工作文书/

五、时间记录

每份材料区分：

• 材料自身形成或落款时间；
• 实际收到时间；
• 完成读取时间；
• 写入或更新工作台的同步时间。

每份工作文书区分：

• 文书形成时间；
• 初稿、修改稿或定稿状态；
• 本次登记时间；
• 所依据材料截至时间。

无法确认收到时间时写“待确认”，不得直接把文件修改时间当作实际收到时间。文件系统时间只作为筛选增量内容的技术线索。

六、第一次同步流程

确认本次属于文件夹或成组材料办案 → 扫描相关目录 → 识别重复和版本 → 按来源分类 → 读取本次办案所需材料 → 接收业务技能已形成的事实、证据、金额和方案 → 建立案件总览和台账 → 登记本次文书 → 写入最后同步时间 → 生成 manifest

第一次同步不要求为了填满工作台重新读取本次任务不需要的全部文件。对未读取文件只登记名称、路径和状态，后续需要时再读取。

不得移动或删除源文件。需要把材料复制进 Vault 时保留原始文件名，并通过哈希避免重复副本；用户已有固定案件目录结构时优先沿用。

七、后续增量同步流程

定位既有案件工作台 → 读取最后同步时间和 manifest → 筛选此后新增、变化、未读和本次形成内容 → 只读取必要增量 → 更新材料台账或文书记录 → 判断是否影响事实、证据、金额和方案 → 仅更新受影响笔记 → 写入本次同步时间和阶段纪要

新增材料必须判断：是否新增或否定事实、是否与旧证据冲突、是否改变金额、诉请、抗辩或辩护方案、是否需要修改已有文书。

单独形成撤诉申请书等程序性材料，且案件已经同步的，原则上只需更新：

• 06_文书及工作记录.md；
• 08_阶段纪要.md；
• 必要时更新 00_案件总览.md中的当前阶段和最近进展；
• 如撤诉、和解等事项改变案件状态，再更新诉讼方案和待办事项。

不得因此重新分析旧证据和金额。

八、文书登记

每份需要同步的文书记录：名称、形成日期、版本、依据材料截至时间、核心目的、主要请求或观点、是否改变原方案、文件路径和后续处理。初稿、修改稿和定稿不得混同。

对于简单程序性文书，不必重复摘录全部案件事实，只记录其程序目的、形成时间、案件阶段变化及文件路径。

九、案件库与专题库隔离

具体姓名、身份证、账号、流水、聊天、刑事卷宗和内部方案只留在案件工作台。需要沉淀通用法律经验时，应另行去标识化并使用 obsidian-legal-kb-sync，不得自动复制具体案件全文。

十、模块和脚本

• 同步路由：references/sync-routing.md
• 工作台结构：references/workspace-schema.md
• 第一次同步：references/initial-sync.md
• 增量同步：references/incremental-sync.md
• 文件哈希和版本：references/manifest-rules.md
• 可用脚本：scripts/build_case_manifest.py