renewal-tracker

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 与示例

# 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）。

状态流转

active ──(发出不续约通知)──→ notice_sent ──(到期终止确认)──→ closed
   │                           │
   │                           └──(对方回应后续约)──→ renewed
   ├──(协商续约)──────────────→ renewed
   ├──(到期自然终止)──────────→ closed
   └──(合同被新合同替代)──────→ superseded

• 只有 active 进入 watcher 的倒计时分级；notice_sent 列入 watcher 的 「已闭环」简表，提示用户在到期后确认终止生效并改为 closed。
• renewed / closed / superseded 不再报警，仅留痕。

输出模板

本技能不产出面向用户的文件；向调用方的回执格式：

[renewal-tracker] 已登记 #<id>：<counterparty>《<contract>》，
cancel_by <YYYY-MM-DD>（通知期 <N> 天）。

本技能不做什么

• 不做续期决策（续不续是业务与法务的决定，本技能只记日期）。
• 不估算缺失的金额或日期（填 null + notes 说明，不编造）。
• 不删除或改写历史条目（状态变化只追加）。
• 不直接提醒用户到期（那是 renewal-watcher 的职责；本技能只维护数据）。
• 不登记没有时间敏感条款的合同。
• 不修改 watcher 已出具的报告（报告是 watcher 的产物；发现报告与登记簿 不一致时，修正登记簿或提示重跑 watcher，不改报告文件）。

收尾与下一步

1. 登记回执交给调用方写入 memo 的「下一步」区。
2. 提示用户：renewal-watcher 会按登记簿定期扫描并出分级提醒报告 （reports/renewal/ 目录）。
3. 合同后续修订、解除、续约时，由新的审查流程再次调用本技能做状态维护； 事项层面的日期同时建议在 matters/<slug>/intake.md 的时效提醒节登记。
4. 登记簿文件建议纳入工作区的版本管理（如 git）：变更历史即审计线索。