--- name: renewal-tracker description: >- 续期登记簿维护技能(库技能,由审查技能在收尾步骤调用,不直接面向用户)。 合同审查发现自动续期、期限、提前通知解除等时间敏感条款时,把关键日期写入 contracts/renewal-register.yaml 登记簿:先读后写、不覆盖历史条目、id 自增, 保证 renewal-watcher 监控 agent 有唯一、干净的数据源。同义场景词:续期登记、 到期登记、自动续期跟踪、合同期限管理、续约提醒登记、renewal register。 user-invocable: false metadata: legal_frame: cn-mainland last_reviewed: '2026-08-18' --- # 续期登记簿维护(renewal-tracker) ## 目的 合同里最贵的一条往往不是写出来的条款,而是**没人记得的日期**:自动续期前 不通知就被续一年、提前解除窗口错过就要再等一年。本技能把审查过程中发现的 时间敏感条款统一登记到 `contracts/renewal-register.yaml`,供 `renewal-watcher` agent 定期扫描、分级提醒。 登记纪律三条(与 legal-core `matter-workspace` 的台账纪律同源): 1. **先读后写**:写入前必须完整读取现有登记簿,确认不重复、不冲突; 2. **不覆盖历史条目**:已登记条目只可追加 `status` 变化(如 active → renewed / closed)或补充 notes,不删除、不改写原始字段——历史留痕; 3. **id 自增不复用**:新条目 id = 现有最大 id + 1,已注销条目的 id 也不 回收。 ## 前置检查 - 调用方(nda-review / sales-contract-review / contract-review 通用规程)已完成审查, 且确认合同中**确实存在**自动续期、期限或提前通知解除条款;不登记没有 日期抓手(到期日、通知期、期限)的合同。 - 用户已被告知并同意登记(一句提示即可:「这份合同有自动续期条款,我把 关键日期登记一下?」);用户不同意的,在 memo FYI 区记录「未登记,用户 决定」,不擅自登记。 - 关键日期能从文本中明确读出;读不出具体日期的(如「续期前合理时间内 通知」),登记时在 notes 写明「日期不确定,条款原文:……」,不得编造 日期(G2:不静默补充)。 ## 操作规程 ### 第 1 步:读取现有登记簿 - 打开 `contracts/renewal-register.yaml`;文件不存在的,新建并写入文件头 注释与 `entries: []`。 - 检查同一合同(按 counterparty + contract 名称判断)是否已有 active 条目: - 已有且本次是复审/修订:不新增条目,更新原条目的 cancel_by 等日期字段, 并在 notes 追加一行「YYYY-MM-DD 修订更新」; - 已有且原合同已终止/重签:原条目 status 改为 `superseded`,另起新条目。 ### 第 2 步:构造新条目 按 schema(见下)逐字段填: - `counterparty`、`contract`:用合同原文名称,不简写、不意译; - `cancel_by`:**最迟行动日**。自动续期场景 = 到期日 − notice_period_days, 再按合同约定的通知方式留缓冲;文本没给依据的缓冲不编造,直接写 「到期日 − 通知期」并在 notes 说明计算方式; - `notice_period_days`:合同约定的提前通知天数;约定不明的填 null 并在 notes 写明; - `annual_value`:年度金额(元);合同无明确金额的填 null,不估算; - `status`:新登记一律 `active`; - `notes`:条款位置(第 X 条)、通知方式要求(书面/EMS/邮件)、日期不 确定之处; - `source`:指向本次审查 memo 或 matter 路径; - `registered_at`:登记日期(YYYY-MM-DD,以 `date` 命令取真实日期,不凭 记忆猜)。 ### 第 3 步:写入并回执 - 追加到 `entries:` 末尾,保持 YAML 格式与既有条目一致(两个空格缩进、 日期加引号); - 写完后向调用方回执一行:「已登记 #id:,cancel_by <日期>」;调用方把这一行写进 memo 的「下一步」区。 ### 第 4 步:状态维护(被 watcher 提示后或后续审查调用时) - 合同已发出不续约通知:status → `notice_sent`,notes 注明发送日期与方式; - 已续约:status → `renewed`,notes 注明新期限; - 已解除/到期不再续:status → `closed`; - 任何状态变化只追加、不改历史(纪律 2)。 ### 第 5 步:写入后自检 - 重新读取登记簿,确认:YAML 可解析;新条目 id 唯一且为最大值;日期字段 格式为带引号的 YYYY-MM-DD;status 为枚举值之一。 - 自检不通过的,立即修复并重新自检;不得把带格式错误的登记簿交给 watcher——格式错误会让监控静默失效,比不登记更危险。 ## Schema 与示例 ```yaml # contracts/renewal-register.yaml # 合同续期/期限登记簿。由 renewal-tracker 维护,renewal-watcher 定期扫描。 # 维护纪律:先读后写;不覆盖历史条目(仅追加状态变化);id 自增不复用。 entries: - id: 1 counterparty: 某科技有限公司 contract: 软件服务框架协议 cancel_by: '2026-12-02' # 最迟行动日:到期日 2027-01-31 减 60 天通知期 notice_period_days: 60 annual_value: 480000 # 年度金额(元),无明确金额填 null status: active # active / notice_sent / renewed / closed / superseded notes: 第 9.2 条自动续期条款;不续约须书面通知,EMS 留痕;cancel_by 按"到期日-通知期"计算 source: matters/ruanjian-fuwu/drafts/review-memo-v1.md registered_at: '2026-08-18' - id: 2 counterparty: 某供应链管理有限公司 contract: 仓储服务合同 cancel_by: '2026-11-15' notice_period_days: 45 annual_value: null # 按实际结算,无固定年费 status: active notes: 第 7 条;通知方式约定不明,已在 memo 标记项 #3 建议修订 source: matters/cangchu-fuwu/drafts/review-memo-v1.md registered_at: '2026-08-18' ``` 字段说明: | 字段 | 类型 | 说明 | | --- | --- | --- | | id | 整数 | 自增,不复用 | | counterparty | 字符串 | 相对方全称(合同原文) | | contract | 字符串 | 合同名称(合同原文) | | cancel_by | 日期 | 最迟行动日(YYYY-MM-DD,加引号) | | notice_period_days | 整数或 null | 约定提前通知天数 | | annual_value | 数字或 null | 年度金额(元),不确定填 null | | status | 枚举 | active / notice_sent / renewed / closed / superseded | | notes | 字符串 | 条款位置、通知方式、不确定事项 | | source | 字符串 | 来源 memo 或 matter 路径 | | registered_at | 日期 | 登记日期 | ## 边界情形处理 1. **同一合同多个时间抓手**:既有质保期、又有合作期限、还有自动续期的, 按「最早需要行动的日期」只登记一条,notes 列明其余日期,避免 watcher 对同一合同重复报警;后续日期成为「最近行动日」时,经状态维护更新 cancel_by 并在 notes 追加说明。 2. **多年期合同无自动续期**:只有固定到期日、无提前通知要求的,仍可登记 (cancel_by = 到期日,notice_period_days 填 0 并在 notes 写明「到期即 终止,无通知期」),以便 watcher 提醒到期重签。 3. **解除窗口类条款**(如「每年 X 月前可书面提出终止」):cancel_by 取 最近一个窗口关闭日,notes 写明窗口的周期性;本条状态维护频率高于普通 条目。 4. **日期依赖第三方行为的**(如「以甲方验收合格日为起算」):cancel_by 填 null——watcher 会列入「数据异常」节提醒人工跟进;notes 写明触发 条件与条款原文。这比编造一个日期安全(G2)。 5. **框架合同 + 订单**:框架合同登记一条;单个订单的交付/账期日期不进本 登记簿(那是履约管理,量大且短周期),需要跟踪的订单级日期建议记入 matters//intake.md 的时效提醒节。 6. **相对方更名/主体变更**:不新建条目;在 notes 追加「YYYY-MM-DD 相对方 更名为 XX」,保持历史可追溯(纪律 2)。 ## 状态流转 ```text active ──(发出不续约通知)──→ notice_sent ──(到期终止确认)──→ closed │ │ │ └──(对方回应后续约)──→ renewed ├──(协商续约)──────────────→ renewed ├──(到期自然终止)──────────→ closed └──(合同被新合同替代)──────→ superseded ``` - 只有 `active` 进入 watcher 的倒计时分级;`notice_sent` 列入 watcher 的 「已闭环」简表,提示用户在到期后确认终止生效并改为 `closed`。 - `renewed` / `closed` / `superseded` 不再报警,仅留痕。 ## 输出模板 本技能不产出面向用户的文件;向调用方的回执格式: ```text [renewal-tracker] 已登记 #》, cancel_by (通知期 天)。 ``` ## 本技能不做什么 - 不做续期决策(续不续是业务与法务的决定,本技能只记日期)。 - 不估算缺失的金额或日期(填 null + notes 说明,不编造)。 - 不删除或改写历史条目(状态变化只追加)。 - 不直接提醒用户到期(那是 renewal-watcher 的职责;本技能只维护数据)。 - 不登记没有时间敏感条款的合同。 - 不修改 watcher 已出具的报告(报告是 watcher 的产物;发现报告与登记簿 不一致时,修正登记簿或提示重跑 watcher,不改报告文件)。 ## 收尾与下一步 1. 登记回执交给调用方写入 memo 的「下一步」区。 2. 提示用户:`renewal-watcher` 会按登记簿定期扫描并出分级提醒报告 (reports/renewal/ 目录)。 3. 合同后续修订、解除、续约时,由新的审查流程再次调用本技能做状态维护; 事项层面的日期同时建议在 `matters//intake.md` 的时效提醒节登记。 4. 登记簿文件建议纳入工作区的版本管理(如 git):变更历史即审计线索。