合同逐条要点与需盯条款清单（设计权威）

定位：把一份合同拆成两件事——条款级要点（每条指回原文那一页那一行）与七类需盯条款（哪一类在文的哪里、没见到的写没见到）。 不是律师，不出实务级意见，不判定效力，不评级排序，也不会自己上传或发布任何东西。

0. 是什么 / 不是什么

1. 输入

• 一份合同正文：本地文件，或经解析通道取回的 PDF／扫描件／远端链接正文（parsed-doc）。
• 可选：页标形状（本件认 第 N 页）；条款行认 第 N 条、N.、N、 三形，别的编号写法请先把正文整理成可回查的行。
• 签署版与本手不同版时，以哪一版为准由你指定；本件不猜。

2. 工作流（四步，每步都可停）

1. 取正文：远端走解析通道，本地直读；登记第四节的一行来源（定位＋解析日）。
2. 排骨架：python3 -B scripts/collect_clauses.py --source 合同.md --out 清单.md——它把条款行逐条搬进第二节并自带页码与行号，第三节按七类各留一个待核位。
3. 判要盯：逐类填「原文位置＋一句逐字引文」，文里确实没有这一类就写「未见到」；概览三件按文里有的填。
4. 过机检：python3 -B scripts/check_clauses.py 清单.md --source 合同.md，按详行 E-* 码逐条改。机检过完仍只是一份阅读材料：怎么谈、接不接受、要不要请律师，是人的判断。

3. 输出契约（四节，机检按此判）

1. ## 1、概览：只一行、≤80 字符，三件都标（标的／期限／价款），文里没有的那件写明未见。
2. ## 2、逐条要点：4–20 条；每条一句原文摘（用「」括出）、行末一个 [S#]、带页码或 文件:行号；两个定位同时给时各自都要成立。
3. ## 3、需盯条款：七类逐类在位，每类要么给定位＋逐字引文，要么写「未见到」；未读到的部分（缺页、附件没给、正文截断）也列在这一节。
4. ## 4、来源与解析日：一行一源，- [S#] 名称（文件:行号 或 URL ｜解析日 YYYY-MM-DD）——日期必须挂在「解析日」这个标签下且是日历上存在的一天；机检核的就是这两件（标签＋这一天存在），它核不了这天是不是正文真正被取回的那一天，那一层由取文的人自己负责。 首行必须是 # 标题；头部另有四件自标：AI 整理初稿／请回原文核对／不构成实务级法律意见或效力判断／判断位 [待人工]，逐字在位。

4. 通道与降级（两条路各自缺什么，写在同一句里）

• 主路＝解析通道：合同在远端（云盘 PDF、扫描件、签署页照片）时，正文走解析通道取回——逐字带页码或行号是这一腿的价值。连上判据按路分写：宿主列工具走 MCP 的 tools/list 握手——连上之后那份返回里应当能看到这些名字：remote-only 那一面是 parse、get_parse_status、cancel_parse 三枚，带 Bridge 的那一面再加 read_result、read_outline、discard_result、save_result 共七枚；两路枚数不同，拿一个固定数判两路必错一边。名字在场只证它们被暴露，不证解析跑得通——URL 那一腿要拿一枚真实 URL 跑一次 parse 才证该路，本地文件那一腿要拿一枚真实本地文件跑一次 parse 才证该路（remote-only 不读本地件）；本件不自证也不代跑。三层各自能证到什么，互不等价：装好 skill ≠ 已配凭据 ≠ 通道已连。配置指路：解析腿官方配置页 https://cuecue.cn/hub/omni-reader（本件只依赖这一条腿，数据腿那页不在本面上引）。命令与三层自查见 README.md 的「装上机 → 连通道 → 出结果」那一节。
• 降级＝只读本地：本件仍能跑 scripts/collect_clauses.py，把手上那份排成骨架；代价同句写清——远端那份正文读不进来，第四节只能登记本地那枚文件。版本同一性这一格两条路都不判：解析通道只按你指定的对象取回正文，本件既不读签署页标记也不对版本链，「手里这份是不是签署那一版」由你指定并对齐（§1 那条「以哪一版为准由你指定；本件不猜」就是这一格的口径）。
• 骨架不是清单：采集器在第三节留七个待核位，机检按设计在道四发 E-COVERAGE——「没命中关键词」不等于「合同里没有这一类」，那一格判断留给人做。

5. 红线（机检守，不由人守）

• 不出实务级法律意见、不判定条款效力、不替代律师审查：合法／违法／无效／可撤销／构成违约／有约束力／法院会支持／建议删除该条／风险等级 一类断言在作者句子里零命中；对裁判结果的表态单靠结果词就发条——「该条不被支持」这种不带情态词的裸断言同样发红，先写「大概率要再核」再换行写「最终不被支持」也算同一句（机检按语义段切，续行并入前段，不按物理行）；要提就挂 [待人工]，且要挂在同一语义段里。引号里的合同原文不算作者表态（机检先剥引号再判）。
• 不评级、不排序、不打分：一份合同内部不做「哪条最差」的排列，那需要法律判断。
• 未读到必须点名：缺页、附件未给、扫描截断，都写进第三节；不拿常识补，不拿范本套。
• 加引号必须逐字：回不到原文的那句不能穿引号（发 E-QUOTE）；页码与行号同时给时两个都算（各比各的）。
• 本件不发请求、不上传、不落盘到本包之外；合同通常含商业秘密与个人信息，存放与转发由用户负责并先告知对方。

6. 最小可复跑链（零网络、零计费、不执行合同里提到的任何程序）

python3 -B scripts/collect_clauses.py --source scripts/fixtures/target-contract.md --out 我的清单.md
python3 -B scripts/check_clauses.py 我的清单.md --source scripts/fixtures/target-contract.md   # 期望发 E-COVERAGE：七类仍是待核位
python3 -B scripts/check_clauses.py scripts/fixtures/good-clauses.md --source scripts/fixtures/target-contract.md   # 期望 PASS
python3 -B scripts/check_clauses.py --selftest        # 好样须过、七枚坏样须各发它该发的那一道
bash scripts/fixtures/run_fixtures.sh                  # 离线三档一次跑完，末行自报档数与不合枚数

7. 边界（含与自家四枚的分工）

• 本件只对「这份文档当页写着什么、我有没有把它指回那一页」负责，且只对形制负责：条款要不要接受、怎么改，是人与律师的判断。
• 与 omni2docx 的分工：那一件是格式转换（解析结果变成可交付的 docx／html／pptx），不改内容形状；本件不改格式，做的是条款级拆解。
• 与 cn-research-brief 的分工：那一件多源横向排速览（一批来源互校后成条）；本件单文档纵向拆条款，没有跨源比对这一层。
• 与 skill-review-cn 的分工：那一件审的是一枚 skill 自己的面文（对象是软件包）；本件读的是一份合同，且红线是「不判效力」而非「不下安装结论」。
• 与 cn-resume-jd-fit 的分工：那一件是两份文档互相对表（要求→证据成对）；本件是单文档内的条款级拆解（一条一句一位置，加七类点名），输入个数与产物形状都不同。
• 名册里另有两枚面上出现过「合同」二字，形状不同：公告速读那一路的对象是一份公告（事件分类＋关键数带出处），本件的对象是一份合同文本且拆到条款行；公开信息预尽调那一路拉的是一家公司的披露风险事实表（跨披露回指公告号），本件不跨文档取证、不拉风险清单。
• 一次一份，且只在拿到正文之后才做：不接「凭文件名猜条款」，不接跨合同比较。