Revise Sci

Revise-Sci

Overview

Use this skill to turn reviewer comments, the original manuscript, SI, and attachments into two deliverables: a revised manuscript and a structured Response to Reviewers. Both come out in Markdown and Word.

The workflow is script-gated. Do not skip steps. Do not fabricate experiments, data, statistics, or references. The comment parser accepts both atomic comment-unit HTML and reviewer-simulator style report HTML with critique lists. The manuscript atomizer recognizes numbered section headings such as 1, 1.1, and 2.3.4 even when the source Word paragraph style is not a formal heading style.

开场监工卡（每次启动必打印，逐字给用户）

返修改稿最容易在这几处翻车，AI 会做但只有你能核对是不是真做到了。启动本技能时必须原样打印这张卡：

1. 拆意见别信 AI 说全了：拆完 AI 应给你一份意见清单，你拿原始审稿信数条数：有没有被合并成一条、有没有整条漏掉。数目对不上就是漏了。
2. 改原意要逐处盯：每一处改动，AI 应贴「原句 → 改后句」，你确认意思没变、没夹带你没同意的新结论。看不到对照就别放行。
3. 覆盖看对照表：交付前 AI 应给「意见 × 是否回复 × 是否改稿 × 结局」对照表。「改稿」列为空**但结局标 push_back（有意驳回不改）**的是正常的，不是漏；真正的漏是：某条既没回复、结局又不是 completed/push_back/需作者确认。分清「有意不改」和「漏改」。
4. 缺证据写"需作者确认"是正常的：AI 没有你的数据/实验时应写「需作者确认」等你补，这不是 bug，请你补齐，别当故障报错。
5. 门禁 PASS 只保形式：门禁只查格式/覆盖/红线这类机械项，改得对不对、说理通不通，得你自己核，别把 PASS 当"改对了"。

【Python 解释器探测·开工第一件事，一次探测全程沿用】 本文命令里写的 python3 / python 只是 macOS/Linux 的习惯写法，不是硬性要求。动手前先跑一次 python3 --version：

• 打印出正常版本号 → 本次会话所有命令照抄用 python3。
• 报 command not found、没有任何输出、或弹出应用商店 → 改跑 python --version，能出版本号就把后续所有命令里的解释器统一换成 python。注意 Windows 自带一个 0 字节的 python3 占位程序，python3 --version 弹商店或无输出就是撞上了它，不算有 python3，按"没有"处理（用户也可在 设置 → 应用 → 应用执行别名 里关掉 python3.exe）。
• 反过来 python 出不了版本号就换 python3（macOS 12.3 起系统不再自带 python）。
• 两个都出不了版本号 = 这台机器没装 Python，停下来告诉用户先安装，不要硬跑。
• 探测只做这一次，之后所有命令沿用同一个名字，不要每条命令都再试。

跨会话接续（每次开局先跑，与监工卡是两件事）

监工卡是「启动提醒」，接续报告是「续上上一会话的进度」。每次进入本技能、且 project_root 已存在时，先跑接续命令再动手：

python "<技能>/scripts/session_journal.py" resume --root <project_root>

env_preflight.py 会把这条打印为 RESUME_CMD（连同 LOG_CMD / CITATION_CHECK_CMD，均为解析好的绝对路径）。读完接续报告后，据它跟用户打接续握手：复述当前 phase、已处理的 comment、以及 decisions_log.md 里用户历次要求，问「我接着做 <下一步>，对吗？还是先插新要求？」等用户确认再继续。

用户在会话中途插入任何临时要求（改哪节、换策略、加/撤某条意见的处理方式）时，当场 log，后续会话必读必守：

python "<技能>/scripts/session_journal.py" log --root <project_root> --note "<用户要求原话>"

Mandatory Intake Before Any Full Pipeline Run

When the user provides a comments_path, a manuscript_docx_path, or both, do not jump straight into run_pipeline.py.

First, env precheck (soft gate, before any pipeline run): python scripts/env_preflight.py <project_root> --cli esearch --py docx; it writes env_status.json, and the last line prints PRECHECK: OK|ASK|BLOCKED. BLOCKED (Python too old) → stop and guide upgrade; ASK (missing optional tools like esearch/python-docx) → ask the user per tool whether to install, give guidance, continue only after the user answers installed/skip; OK → continue. Rollback uses state_manager.py snapshot + Patch-hash (no git checkpoints).

Always run:

python scripts/intake_router.py --comments <comments_path> --manuscript <manuscript_docx_path>

Before any substantive revise work, report to the user:

• which comments_input_mode was detected;
• which branch-specific workflow will be used next;
• that the workflow preserves the same atomicization, fragment-only rewrite, anti-AI polish, state-window, anti-forgetfulness, and hard-gate rules;
• then ask the user to confirm that routing decision together with the desired project_root / output path.

If the input does not match any supported branch:

• do not proceed silently;
• ask the user whether to map the input to an existing branch or create a new branch;
• any new branch must still preserve the same atomicization, fragment-only rewrite, anti-AI polish, state-window, anti-forgetfulness, and hard-gate rules.

If the user has no reviewer comments and only provides the manuscript:

1. run python scripts/intake_router.py --manuscript <manuscript_docx_path>;
2. ask whether to use reviewer-simulator first to generate reviewer comments;
3. check global availability using python scripts/ensure_global_skill.py --skill-name reviewer-simulator;
4. if the skill is missing and the user confirms installation, install it from your own skills backup repository (reviewer-simulator subdirectory) before invoking that branch.

Comment Input Modes

• docx-review-comments: ordinary reviewer comments exported from email or web into a .docx. The parser expects reviewer / major-minor / numbered-comment structure and keeps multiline comments inside one unit.
• docx-review-letter: ordinary decision-letter style .docx files where the structure is usually editor email -> Reviewer #N overall statement -> numbered comments. The parser now distinguishes editor statements, reviewer overall statements, and actionable numbered comments instead of collapsing them into a single comment stream.
• reviewer-simulator-html: HTML generated by reviewer-simulator. The parser reads critique-section / critique-list blocks and preserves comment_title, problem_description, evidence_anchor, root_cause, and author_strategy.
• reviewer-response-sci-html: HTML generated by reviewer-response-sci. The parser extracts the original reviewer comment plus seeded response_en/zh, original_excerpt, revised_excerpt, and revision_location, then feeds those seeds back into localization and response drafting.
• atomic-comment-html: already-atomic HTML with comment-unit nodes. Existing comment_id values are preserved.
• no-comments-manuscript-only: manuscript exists but reviewer comments are not provided yet. This is not a revise branch by itself; it is an intake state that must first ask whether to bootstrap comments via reviewer-simulator.

For docx-review-letter, the workflow must:

1. distinguish top-of-letter editor statements from numbered editor action items;
2. capture reviewer-level Overall statement / General assessment / Reviewer statement text as reviewer-summary seeds, not as the first numbered comment;
3. preserve those statement seeds into downstream response rendering so the exported response package can still show editor/reviewer context explicitly.

For reviewer-response-sci-html, do not trust the incoming response package at face value:

1. treat seeded response/revision content as structured hints rather than auto-approved final output;
2. prioritize seeded location/original-excerpt hints when localizing the target paragraph;
3. still rerun revise -> polish -> literature/reference checks -> strict_gate before delivery.

Required Inputs

• comments_path
• manuscript_docx_path
• project_root
• output_md_path
• output_docx_path

Optional but supported:

• si_docx_path
• attachments_dir_path
• reference_docx_path
• journal_style
• paper_search_results_path
• references_source_path
• expected_comments_mode
• context_token_budget
• context_tail_lines

Output Contract

Always produce:

• response_to_reviewers.md
• response_to_reviewers.docx
• revised manuscript markdown at output_md_path
• revised manuscript Word at output_docx_path
  • 默认 in-place 保原稿格式：当原稿是 .docx 时，改后稿基于原始 manuscript docx 编辑，未被改的段落、表格、图片、样式、对齐原样保留，只替换被点名改写的段落的文字，并按行内标记（*斜体*/**粗**/<sup>/<sub>）重建 run、继承原段落基础字体（font.name/size/eastAsia）。定位/身份对不上时 fail-closed 硬停：export_docx.py 退出码 3，把拒绝原因和两个选项（① 重跑加 --allow-rebuild-fallback 接受重排版本；② 修锚点后用未改动原稿重跑）显式打给用户，不再默认静默降级为 md 全量重建（那会丢原稿表格/图位/对齐并按期刊模板重排，用户却不知情）。只有显式传 --allow-rebuild-fallback（run_pipeline 同名 flag 透传）才回退 md 全量重建。原稿非 docx 或无原稿时正常走 md 全量重建（legacy fallback，非降级）。导出模式记录在 project_state.json 的 outputs.manuscript_export_mode（in-place / in-place-tracked / md-rebuild）。response_to_reviewers.docx 不受影响，维持现有固定样式脚本（含 eastAsia）。
  • 可选 --track-changes 词级修订痕迹（默认关闭，仅 in-place 生效）：改动段落按 original vs current 的词级 diff 写成带 Word 红蓝增删痕迹的 docx（<w:ins>/<w:del>，仅包住真正变化的词，行内斜体/上下标/粗体在痕迹两侧保留），导出模式记为 in-place-tracked。关闭时行为与原 clean in-place 完全一致。详见 Pipeline 段 export_docx.py 的 --track-changes 说明。
• precheck_report.md
• issue_matrix.md
• manuscript_edit_plan.md
• final_consistency_report.md
• data/literature_index.json
• data/revision_claims.json
• data/synthesis_matrix.json
• data/synthesis_matrix_audit.json
• data/reference_registry.json
• data/reference_coverage_audit.json
• figure_index.json / reference_index.json,反向抽取的图、参考交叉索引(每项含 cited_by 与 orphan_type)
• abbreviation_index.json,反向抽取的缩略语交叉索引(每项含 defined_count / used_count / orphan_type:undefined_use / duplicate_definition / title_abbreviation 为硬错,defined_unused 为软警告)
• manuscript_index.md,人读版图/参考/缩略语索引与孤儿汇总。启发式抽取,作审查辅助而非红线核验
• figures/figure_NN.<ext> + figures/image_manifest.json,从源 docx word/media/ 解出的内嵌图(按 zip 出现顺序命名),供最终返修 docx 嵌回。仅二进制搬运,不做 OCR/图像识别;非 docx 输入则目录可能为空
• manuscript_section_index.json 每个 section 条目含 figures 字段:该节图注/裸图标题锚定的图清单(figure_id / caption / image_file / source)。图注文本落在哪节该图即归哪节(definitive);图号→图片文件走 manifest idx 启发式(zip 顺序 ≈ 阅读顺序),故图片绑定标 image_binding: ordinal_heuristic

Pipeline

Run the scripts in this exact order:

python scripts/intake_router.py ...
python scripts/preflight.py ...
python scripts/atomize_comments.py ...
python scripts/atomize_manuscript.py ...   # 除切 section md 外,为每节写 figures 锚点(figure_id/caption/image_file/source);manifest 此时通常尚未生成,image_file 多为空,由 merge 阶段以 manifest 为准再解析
python scripts/manuscript_index.py --manuscript <manuscript_docx_path> --project-root <project_root> --units-dir units   # 反向抽取图/参考/缩略语交叉索引,辅助图文一致性、引用完整性与缩略语首展核查(产 abbreviation_index.json)。改稿合并后应对最终 output_md 重跑一次,使索引反映改后稿
python scripts/extract_docx_images.py --manuscript <manuscript_path> --project-root <project_root>   # 支持 docx 与 pdf,抠出内嵌图到 figures/,供最终返修 docx 嵌回(best-effort;pdf 需 PyMuPDF,缺失则优雅跳过;其他非 docx/pdf 输入自动 no-op)
python scripts/build_issue_matrix.py ...
python scripts/state_manager.py --project-root <project_root> refresh
python scripts/citation_guard.py ...   # if paper_search_results_path is provided
# 🔴 [意见清单核对·必停] atomize_comments 之后、revise_units 之前的强制关卡：见下方「## [意见清单核对·必停]（拆意见后、改写前的强制关卡）」。未经用户确认"条数对、无合并、无遗漏"，不得进入 revise_units。
python scripts/revise_units.py --project-root <project_root> [--paper-search-results <paper_search_validated.json>] [--comment-id <comment_id>]   # --comment-id 仅处理单条评论,用于迭代调试;默认全量
python scripts/build_literature_index.py --project-root <project_root> [--seed-index <writing_project_literature_index.json>]   # 不传 --seed-index：行为不变，从 global_id=1 重建库。传 --seed-index：复用撰写项目(gsw/review-writing)已有引文库作种子，**保留种子每条的既有 global_id**，本次返修新查到的文献按去重键(归一DOI>PMID>归一标题)与种子比对，命中种子的复用其编号不新增、真正新的从"种子最大 global_id + 1"续号追加，合并结果写 revise 自己的 data/literature_index.json。**只读种子、不写回撰写项目**(种子扩展语义)。种子读取兼容 gsw 松 schema(global_id/citation_number/id/number/ref_number 任一取号，都缺按数组顺序补号)与根级/data 下任意路径。
python scripts/matrix_manager.py bootstrap ...
python scripts/matrix_manager.py audit ...
python scripts/merge_manuscript.py --project-root <project_root> --output-md <output_md>   # md 全量重建(回退路径)时按各节 figures 锚点把图片 markdown 回填到对应节;fail-closed 防幻影删除:manifest 里有但未归到任何一节的图片全部回填到文末 "# Unplaced figures" 区并 stderr/JSON warn,绝不静默丢图。旧工程无 figures 字段则保持原纯文本拼接不变。注:in-place 导出路径不经此重建,图片在原稿内原样保留。图号→图片文件绑定走 ordinal_heuristic(zip 顺序≈阅读顺序,常不一致),故每次都输出一份「图号→图片文件」对照(stderr 醒目 banner + JSON `figure_map`,含 binding=atomize-prefilled/ordinal_heuristic/unresolved),一旦触发 md 重建回退,图按此绑定嵌入,必须人工核对是否错号错位
python scripts/reference_sync.py --project-root <project_root> --output-md <output_md>
python scripts/build_reference_registry.py --project-root <project_root> --output-md <output_md> [--references-source <ref_source>] [--reference-search-decision ask|approved|declined]
python scripts/export_docx.py --project-root <project_root> --output-md <output_md> --output-docx <output_docx> [--reference-docx <ref_docx>] [--manuscript-docx <original_manuscript_docx>] [--no-inplace] [--allow-rebuild-fallback] [--track-changes] [--author revise-sci] [--date <ISO8601>] [--journal-style journal-manuscript|nature-review|cell-press|lancet-review]
# 传 --manuscript-docx <原始稿.docx> 时改后稿默认 in-place 保原稿格式（仅替换被改段落）。定位/身份失败时**硬停退出码 3 并打印两个选项**，不再默认静默降级；显式加 --allow-rebuild-fallback 才回退 md 全量重建。--no-inplace 强制走 legacy 全量重建。run_pipeline 会在原稿为 .docx 时自动传入 --manuscript-docx（并透传 --allow-rebuild-fallback）。
# --track-changes（默认关闭）：in-place 导出时，改动段落不再整段重建成 clean 文本，而是对 original vs current 做**词级 diff**（英文按空白/标点切词、中文按单字切），生成带 Word 修订痕迹的 docx，删除词用 <w:del><w:delText>、新增词用 <w:ins><w:t>、替换=先删旧后插新；未变的词保持普通 run 不进痕迹。每处 ins/del 带唯一递增 w:id + w:author（--author，默认 revise-sci）+ w:date（--date，默认 datetime.now().isoformat()）。行内格式（*斜体*/**粗**/<sup>/<sub>）随词级 diff 完整保留在痕迹两侧。含内嵌图片的段落仍跳过（保图）。开关关闭时 clean in-place 行为**完全不变**。Word 里“接受全部修订”后正文==current，“拒绝全部修订”后==original。注意：python-docx 的 `.text` 不读 w:ins/w:del 内文，属正常现象（能正常打开），校验请用接受/拒绝后的文本或 docx 技能的 accept_changes.py。
python scripts/final_consistency_report.py ...
python scripts/numeric_candidates.py --manuscript <output_docx 或 output_md> --project-root <project_root>   # 数值一致性核查第1层确定性锚；三层(独立检测子代理+delegate_review反向验证+HALT)见下方"数值一致性核查"节。挂在 final_consistency 与 strict_gate 之间
python scripts/structure_outline.py --manuscript <output_docx 或 output_md> --project-root <project_root>   # 交叉引用核查(xref)第1层确定性锚(sections/figures/tables/items)；三层见下方"交叉引用核查"节。与 numeric 同源、numeric 之后
python scripts/methods_terms.py --manuscript <output_docx 或 output_md> --project-root <project_root>   # 方法学漏写核查(M)第1层弱锚(authority:weak_focus_map)；三层+实验稿门见下方"方法学漏写核查"节。综述稿(journal_style∈{nature-review,lancet-review})跳过 M
python scripts/strict_gate.py ...

数值一致性核查（三层·final_consistency 与 strict_gate 之间·HALT 交用户裁决）：数值矛盾天然跨摘要/结果/表，必须返修后全文成形后跑。读返修后的 output_docx（in-place 保格式，docx 表格 walk 头号用例，numeric_candidates.py 已额外遍历 doc.tables 抽单元格值 location.source=="table"）或 output_md。

• ① 第 1 层确定性锚：上面 numeric_candidates.py 已产 <project_root>/numeric_candidates.json。

• ② 第 2 层独立检测子代理（非作者自检·I2）：派一个 fresh context、没参与返修的独立检测子代理（TaskCreate/spawn_task），只喂 numeric_candidates.json + 返修全文，不给返修过程上下文/作者意图（防继承确认偏误，否则漏看的真矛盾第 3 层永远看不到→系统性假阴）。子代理产出零容差二元 schema [{"metric","same_measurement":bool,"values":[{"id","raw","location":{"region","para_index"}}],"conflict":bool,"evidence_quote","finding"}]（无 tolerance_state、无 severity）：先判是否同一指标/对象/分组/时间点/单位（跨措辞语义归一、跨单位如 μM vs nM 由 LLM 换算判），仅对同一测量判是否完全相等，same_measurement==true && 非完全相等 → conflict=true；不同剂量组/时间点/亚组/单位的正常差异不报。样本量 n 跨位置核对：核对同一实验/同一组的样本重复数 n（metric_clue=="样本量"）是否跨方法学 / 图注 / 结果与讨论三处一致；防假阳：不同图/不同实验的 n 本可合理不同，只有多处 n 明确指向同一实验、同一组样本时其不一致才报 conflict，无法确认的按 same_measurement=false 不报（拿不准交人工）。降级：派不出真正独立子代理时不得自问自答冒充，标注"数值一致性未经独立检测"交用户人肉核。

• ③ 第 3 层反向验证：每条 conflict==true 过 delegate_review.py（不改它，只 pack/verify，gate=numeric-verify，checklist 内自由 key，不查 gate_registry）。⚠️ revise 的 delegate_review.py 是 fork（md5 ≠ base）——pack/verify 与 fail-closed 行为须对 fork 实测，不假设 base 行为。 动态合成 <project_root>/numeric_verify_checklist.json：item 只放两处 raw/location/metric + 核验所需原文切片（绝不放子代理 finding/reasoning），默认硬项（不标 "severity":"soft"）；≥3 值的组拆成两两配对的多个 item（id num-<组>-<配对序>，任一配对 pass → 该组整体保留、全部 fail → 剔除）。🔴 check 逐字用零容差极性模板（禁占位符、禁自由发挥）：

  "到给你的原稿全文里独立核实：{locA} 处的值『{valA}』与 {locB} 处的值『{valB}』，两者据称都是指标『{metric}』的测量结果。请逐字回源确认两点——(1) 两处是否确指同一指标、同一测量对象、同一分组、同一时间点、同一单位（即本就应当相等；跨单位如 μM vs nM，请换算到同一单位后再判是否本应相等）？请到原文找出各自邻近的分组/剂量/时间点/亚组/单位线索比对。(2) 若确为同一测量，两值是否非完全相等（零容差：只要不是完全相同的数值即算不等，含末位舍入差异如 58% vs 58.3%）？只有『同一测量且非完全相等』才判 pass（矛盾属实，保留交人工裁决）；只要发现两者其实是不同分组/不同时间点/不同亚组/不同单位（正常差异），或换算后完全相等，一律判 fail（非矛盾，剔除）。 evidence 必填：逐字引出 A、B 两处原文句及各自的分组/时间点/单位线索。"

  --files 给返修全文；pack → 独立空白子代理逐条裁 pass|fail|na 附逐字证据 → verify。verdict 映射：pass→confirmed（矛盾属实）；fail/na→refuted（剔除）；verify 的 problems（空证据/未裁决/verdict 非法）照 fail-closed 视为未核验、不进清单（宁漏报）。极性写反 = 假批评全放行，务必对准 pass=矛盾属实。 ⚠️ 退出码陷阱（务必理解）：本 numeric-verify 复用通用门禁 delegate_review，任一 item fail 会让 verify 报 ok=false / exit 1 / stderr『盲检未通过』——但在数值反向验证里 fail = 成功剔除假矛盾 = 正常好结果。主 agent 必须忽略退出码，只读返回 JSON 的逐条 verdict + problems：verdict=pass→confirmed 保留、fail/na→refuted 剔除、problems 内→fail-closed 不进报告。切勿把 exit 1 误读成核查失败 / 报告不能完成。

• ④ HALT：命中 confirmed conflict → HALT 交用户裁决（列 metric + 两处 raw/location + evidence_quote），暂停 pipeline、用户逐条裁决是否需统一，处置后重跑本步至无 confirmed conflict 再进 strict_gate.py。不 auto-block 硬拦、不静默判等放过（零容差 + 灰区交人工）。

交叉引用核查（xref，三层·numeric 之后·strict_gate 之前·HALT 交用户裁决）：改稿最爱动图/节/表编号（删段、并段、重排），"见图5/见3.3节"指向对不对是返修高发坑；必须返修后全文成形、编号冻结后跑（与 numeric 同挂点、同源）。读返修后的 output_docx（in-place 保格式）或 output_md。revise 对交叉引用一致性零覆盖，纯新增能力。

• ① 第 1 层确定性锚：上面 structure_outline.py --manuscript <output_docx 或 output_md> --project-root <project_root> 已产 <project_root>/outline.json（稿中真实存在的全部 sections/figures/tables/items）。脚本零改造、docx 读取现役已具备（走 manuscript_index.read_manuscript_paragraphs 抽 docx 段落，含 Heading 样式认小节）。JSON 落 <project_root> 根，不进托管 glob。

• ② 第 2 层独立检测子代理（非作者自检·I2）：派一个 fresh context、没参与返修的独立检测子代理（TaskCreate/spawn_task），只喂 outline.json + 返修全文，不给返修过程上下文/作者意图（防继承确认偏误→系统性假阴）。逐条指向型表述（见 3.1/如前文 4.1.2 所述/见图3/见表2/见(2)）对着 outline.json（唯一权威真值，不凭记忆假设稿子有某小节，拿不准标 uncertain）判存在性（missing_target）与语义对应（semantic_mismatch）。产出 schema [{"ref_id","citing_location","cited_target","issue_type":"missing_target|semantic_mismatch|uncertain","evidence_quote","outline_says","finding","severity"}]（severity 仅信息字段，HALT 不按它路由）。🔴 补充材料护栏：S 前缀编号（Figure S1/Table S3/见图 S22/Supplementary Fig. 5）一律强制 skip 丢弃（不产 finding、绝不标 uncertain、绝不报 missing_target、绝不送第 3 层——否则补充材料图注天然不在正文稿，第 3 层"连定义处都找不到→pass=confirmed"会把整份补充材料 S1–Sn 批量假报为悬空引用、假阳 HALT）。降级：派不出真正独立子代理时不得自问自答冒充，标注"交叉引用未经独立检测"交用户人肉核。

• ③ 第 3 层反向验证：每条发现过 delegate_review.py（不改它，只 pack/verify，gate=xref-verify，checklist 内自由 key，不查 gate_registry）。⚠️ revise 的 delegate_review.py 是 fork（md5 ≠ base）——但 D1 numeric-verify 已在这份 fork 上实测 pack/verify + 退出码陷阱 + fail-closed 全通；xref 复用同一 fork、同一 gate 机制，pack/verify 一律不传 --comments（那是 RR 专用可选 arg，不传则 pack 行为等同 base）。 动态合成 <project_root>/xref_verify_checklist.json（{"skill":"revise-sci","gates":{"xref-verify":{"title":"交叉引用一致性·反向验证","items":[{"id","name","check"}]}}}）：item 只放 cited_target+evidence_quote+issue_type+核验所需原文切片（绝不放子代理 finding/理由、也不放 outline），默认硬项。按 issue_type 分流喂料：missing_target/uncertain 的 item --files 给返修全文（让核验人独立回源检索该编号定义存否，反查第 1 层漏抽真小节造成的假 missing_target）；semantic_mismatch 的 item 给引用处上下文切片 + outline 里该编号标题/caption。🔴 check 逐字用极性模板（禁占位符、禁自由发挥），两类分写：

  missing_target/uncertain："到给你的原稿全文里，找得到编号「{编号}」的定义处吗？定义处专指：图/表的图注行（以『Figure {N}』『图{N}』『Table {N}』『表{N}』开头、后接说明文字的 caption 行），或该编号的小节标题行（如独占一行的『3.2 方法』）；把它当引用来提及的句子不算定义处（如『见 Figure 3』『as shown in Figure 3』『详见 3.2 节』这类指向句，即便含该编号也一律不算）。只有连定义处都找不到（该编号只被引用、从未被定义）才判 pass；只要找到定义处就判 fail，并逐字引出该定义/caption 行。" semantic_mismatch："正文该引用处的具体断言，与目标「{编号}」的标题/caption 是否明确无关？只有'正文明确断言见 X 讨论了 Y、而 X 根本不涉及 Y'这种明确错位才判 pass；若只是笼统指向或目标标题能合理概括该引用，一律判 fail。"

  pack → 独立空白子代理逐条裁 pass|fail|na 附逐字证据（写回 .review_return_xref-verify.json）→ verify。verdict 映射：missing_target/uncertain 连定义处都找不到（悬空）→ pass=confirmed 保留、找到定义处（caption/小节标题行，非引用句自身）→ fail=refuted 剔除；semantic_mismatch 明确无关→ pass=confirmed、笼统指向/合理概括→ fail=refuted；verify 的 problems（空证据/未裁决/verdict 非法）照 fail-closed 视为未核验、不进清单（宁漏报）。⚠️ 极性关键：核验人必须区分"定义处"与"引用处"（引用句自身含该编号不构成"找得到"），写反 = 假批评全放行。⚠️ 退出码陷阱：任一 item fail 会让 verify 报 ok=false/exit 1/stderr『盲检未通过』——但在 xref-verify 里 fail = 成功剔除假问题 = 正常好结果。主 agent 必须忽略退出码，只读返回 JSON 的逐条 verdict + problems。

• ④ HALT：命中 confirmed → HALT 交用户裁决（列 cited_target + 引用处切片 + evidence），暂停 pipeline、用户逐条裁决，处置后重跑本步至无 confirmed 再进下一步。不 auto-block、不静默放过（灰区交人工）。

方法学漏写核查（M，三层·实验稿门·xref 之后·strict_gate 之前·HALT 交用户裁决）："结果做了某实验、方法学没交代"是审稿高频硬伤；revise 是改已有稿、不像 gsw 那样系统重建 Methods，M 在 revise 补的是一整块空白。读返修后的 output_docx（in-place 保格式，methods_terms 已自带 _read_docx_table_cells 遍历 docx 表格单元格）或 output_md。

• 🔴 实验稿门（M 节开头必判，判据可读可测）：读 <project_root>/project_state.json 的 inputs.journal_style（由 preflight.py/export_docx.py 写入、strict_gate.py 已校验合法，本挂点在 export 之后 → 字段必就绪）。

  • journal_style ∈ {"nature-review","lancet-review"} → 整个 M 节 skip，向用户打印"综述稿跳过方法学漏写核查"，直接进 strict_gate.py（xref 照跑、不受此门影响）。
  • journal_style ∈ {"journal-manuscript","cell-press"} → 跑 M（原始研究/Cell 系一次研究，有实验方法学）。
  • 字段缺失/非法（理论上 strict_gate 已挡）→ 保守跑 M（宁多跑不漏，第 3 层兜假阳）。

• ① 第 1 层弱锚：上面 methods_terms.py --manuscript <output_docx 或 output_md> --project-root <project_root> 已产 <project_root>/methods_terms.json（authority:"weak_focus_map"，method_hits/methods_sections）。弱锚缺失/损坏降级：methods_terms.py 若 exit 2 或 JSON 缺失/损坏，第 2 层降级为纯全文语义跑（它本就不依赖弱锚），不得静默失效。JSON 落 <project_root> 根。

• ② 第 2 层独立检测子代理（非作者自检·I2）：派 fresh context、没参与返修的独立检测子代理，只喂 methods_terms.json + 返修全文，不给返修过程上下文。读结果/讨论 + 方法学 + 弱锚，判每个本研究用到的实验方法方法学章节有没有交代，报 methods_missing。关键约束（逐条写进 prompt）：① 弱锚非穷尽、须自行语义补词典外方法（含隐含如"散点图门控"→流式）；② 只判本研究做的（头号假阳防线）——引用他人研究（previous studies used…）/未来工作计划（plan to/would/future work）/背景泛提一律不报，判据=人称时态 + 区段 + has_figure_adjacent + 语义；③ "交代了"从宽三选一（方法学出现方法名 / 主文指向补充材料 / 方法学引用文献描述该方法，任一即 methods_section_covers=true）。产出 schema [{"method","used_in_study":bool,"methods_section_covers":bool,"methods_missing":bool,"evidence_quote","finding"}]，判据 used_in_study==true && methods_section_covers==false → methods_missing=true。下游路由：methods_missing==true → 第 3 层；used_in_study==false 或 methods_section_covers==true → 丢弃。已知局限（明写交代用户）：仅核主文、不读补充材料文件——方法完全下沉补充材料且主文连"见补充材料"都没提的漏报核不出。降级：派不出真正独立子代理时不得自问自答冒充，标注"方法学一致性未经独立检测"交用户人肉核。

• ③ 第 3 层反向验证：每条 methods_missing==true 过 delegate_review.py（不改它，只 pack/verify，gate=methods-verify，checklist 内自由 key，不查 gate_registry，不传 --comments，fork 行为等同 base、见 xref ③）。动态合成 <project_root>/methods_verify_checklist.json（skill:"revise-sci"，gate=methods-verify）：item 只放 {method} + 结果处命中句（弱锚 sentence 或第 2 层 evidence）+ 核验所需切片（绝不放 finding/reasoning），默认硬项，--files 给返修全文。🔴 check 逐字用两条件极性模板（禁占位符、禁自由发挥）：

  "到给你的原稿全文里独立核实两点——(1) 结果/讨论是否确实报告了本研究做的『{method}』（有对应实验数据/图/门控/条带等本研究结果，而非仅在背景/引言/讨论里引用他人研究提及该方法，也非讨论/局限里"将来/拟/计划/would/planned to/future work"等表述里打算做但本研究并未做的未来工作/计划实验）？请回源找邻近的数据/图引用与人称/时态/引文线索比对。(2) 方法学章节是否确实【完全没有】交代『{method}』——须同时满足三个『没有』才算完全没交代：(2a) 既无该方法的小节标题、也无任何描述其如何做的句子；(2b) 也没有任何指向补充材料/附录的表述（如『见补充材料』『详见附录』『see Supplementary Methods』『described in the Supplementary/Supporting Information』）；(2c) 也没有【引用文献描述该方法】的表述（如『方法参照文献[X]』『按照[X]的方法进行』『as previously described [12]』这类带文献引用标记的方法指向）。只要出现 (2b) 指向补充材料 或 (2c) 引用文献描述该方法，即算已交代、不算漏写。只有『结果确实用了本研究的该方法』且『方法学确实没写、没指向补充材料、也没引用文献描述该方法』两条同时成立才判 pass（漏写属实，保留交人工裁决）；只要发现方法学其实写了该方法（哪怕只一句）、或主文有指向补充材料的交代、或方法学有引用文献描述该方法（带引文标记）、或结果里的该方法其实是引用他人研究/背景讨论（非本研究做的），一律判 fail（非漏写，剔除）。 evidence 必填：逐字引出结果处用到该方法的句 + 方法学处（有则引出该句证明写了/引出指向补充材料或引用文献的句，无则说明通读方法学未见）。"

  pack → 独立空白子代理逐条裁 pass|fail|na 附逐字证据（写回 .review_return_methods-verify.json）→ verify。verdict 映射：本研究确用 AND 方法学确未写/未指向补充材料/未引用文献描述 → pass=confirmed 保留；方法学其实写了 / 主文指向补充材料 / 方法学引用文献描述 / 结果只是引用他人 → fail=refuted 剔除；verify 的 problems 照 fail-closed 视为未核验、不进清单（宁漏报）。⚠️ 极性关键：核验人必须独立确认两件事——条件 (1) 本研究做的 vs 引用他人（M 头号假阳源）、条件 (2) 两类从宽交代（(2b) 指向补充材料、(2c) 方法学引用文献描述该方法），不能只问"方法学有没有直接写"，写反 = 假批评全放行。⚠️ 退出码陷阱：任一 item fail 会让 verify 报 ok=false/exit 1/『盲检未通过』——但在 methods-verify 里 fail = 成功剔除假漏写 = 正常好结果。主 agent 必须忽略退出码，只读返回 JSON 的逐条 verdict + problems。

• ④ HALT：命中 confirmed → HALT 交用户裁决（列 method + 结果处切片 + evidence），暂停 pipeline、用户逐条裁决，处置后重跑本步至无 confirmed 再进 strict_gate.py。不 auto-block、不静默放过（灰区交人工）。

Or use the single entrypoint:

python scripts/run_pipeline.py --comments <comments_path> --manuscript <manuscript_docx_path> --project-root <project_root> --output-md <output_md_path> --output-docx <output_docx_path> [--journal-style journal-manuscript|nature-review|cell-press|lancet-review] [--expected-comments-mode <comments_input_mode>] [--context-token-budget 4200] [--context-tail-lines 80] [--paper-search-results <paper_search_results_path>] [--resume] [--resume-from <step>] [--resume-keep-unaffected] [--force-rebuild] [--allow-rebuild-fallback]

--expected-comments-mode is strongly recommended after the user confirms the branch chosen by intake_router.py. preflight.py will block execution if the confirmed mode and the detected mode do not match.

round22 一键 pipeline 状态机（可恢复人工/独立闸口，机器强制）

run_pipeline.py 自带 project_state.json.pipeline_gate（schema_version=1 + epoch）状态机，把上面「意见清单核对·必停」「通读定策略」「三层核查」「DoD 停」从纪律变成机器强制。退出码写死：0=complete、1=执行/检查失败、2=坏参数/非法转换/坏回执、3=预期人工/独立动作暂停（停点打印 PIPELINE_PAUSED phase=<phase>）。

• 首跑：原子化完成后生成 audit/comment_inventory.json（reviewer+comment_id+原意见规范空白文本，含 comments_source_sha256 与自摘要 inventory_sha256）即停 awaiting_comment_confirmation，不调用 revise_units。用户核对清单后 --resume --confirm-comment-inventory <inventory_sha256> 确认（摘要绑定内容，路径相同不等于内容相同）。
• 策略门：确认后每个 unit 必须先填四选一 revision_strategy（canonical 闭集 comply/partial/push_back/needs_data，别名 驳回/reject/pushback 归一到 push_back），缺失/非法停 awaiting_revision_strategies，不改稿。
• 三层独立核查：final consistency 后固定顺序跑 numeric→xref→Methods 锚（综述 nature-review/lancet-review 的 Methods 记 na+理由），生成 audit/detection_task.json（绑定 epoch/delivery/audit manifest，task_manifest_sha256 自摘要）停 awaiting_audit_detection。独立检测子代理写 audit/detection_{numeric,xref,methods}.json（round22 envelope，须回传 task hash）；普通 --resume 自动校验（缺轨/坏 schema/hash 不符/空证据 rc=2）。有真 finding 才生成 reverse 任务（pipeline 按 canonical item 生成稳定 finding ID <track>-<sha256前12位>），返回写 .review_return_{numeric,xref,methods}-verify.json（envelope），极性 pass=confirmed / fail|na=refuted / problems=未核 rc=2；受理后原子写 .pipeline_receipts/audit_reverse.json。有 confirmed 时用户在 audit/adjudication.json 逐条 fix|accept_with_rationale，--resume --confirm-audit-adjudication <audit_manifest_sha256> 受理：fix 要求交付物已实际变化并开新 epoch 从 detection 重跑；accept 要求理由非空且 manifest 未漂移。
• DoD 解环：进入 DoD 前 pipeline 自跑 strict_gate.py --preclose（只输出 STRICT_PRECLOSE: PASS，绝不冒充 final）；DoD JSON 里的 strict_gate 命令也全部带 --preclose。独立 DoD 返回写 .review_return_revision-dod.json（envelope），普通 --resume 走本地 delegate_review.py verify --expect-task-manifest 验证并原子写 .pipeline_receipts/revision_dod.json，随后停 awaiting_dod_user_confirmation 展示逐项裁决。唯一收口出口是 --resume --confirm-dod-closure <dod_manifest_sha256>：写 .pipeline_receipts/dod_closure.json 后才运行最终 bare strict_gate.py（成功唯一字面量 STRICT_GATE: PASS），pipeline 才 rc=0。
• 失效规则：审稿信/inventory/策略等上游内容变化一律 epoch+1，旧确认与全部下游 receipt 逻辑失效并回到对应早期停点；--resume-from 同样提升 epoch。bare gate 自行核 skill signature 与 closure 链（缺 pipeline_gate 默认 rc=2；pre-round22 旧项目仅 --legacy-direct + 精确 allowlist signature 可降级运行）。
• 旧项目迁移：无 pipeline_gate 的旧项目普通 --resume 非破坏性 rc=3 提示 --resume --migrate-round22；迁移只接受 allowlist 内旧 signature 且输入指纹未变，保留全部产物、不推断任何历史确认，落回 inventory 确认点。

[意见清单核对·必停]（拆意见后、改写前的强制关卡）

位置：atomize_comments.py 拆完审稿意见之后、revise_units.py 开始改写之前。这是流程内部的硬关卡，与开场监工卡不同：监工卡是启动时提醒，这一步是拆完意见后的当场核对。

拆完审稿意见后，立即停下，把每条 comment_id + 该条前 30 字列成清单打给用户，并原样问：

「请拿原始审稿信对照数一遍，条数对不对？有没有哪条被合并成一条、或整段漏掉？（尤其审稿人用连续散文、(i)(ii)、罗马数字、或一段里塞多个要求时最容易漏）」

用户确认"都在、没漏"后才继续改写。用户指出漏掉或被合并的，回去把它补成独立 comment（补进 units/、重新原子化）后再继续，不得跳过这一步直接跑 revise_units.py。

[通读定策略·前置阶段]（清单核对通过后、逐条改写前）

真人返修的第一件事不是逐条动手，而是先把所有意见通读一遍、定下每条的应对策略。这里也一样：意见清单核对通过后、revise_units.py 开始逐条改写之前，先做一轮 triage，不要从 atomize 直接跳到逐条改。

对每条 comment 定四选一的策略，并写进该 unit 的 revision_strategy 字段（units/*.json）：

硬规则：revise_units.py 逐条改写前，每条 unit 的 revision_strategy 必须先填（该字段已存在也要强制先确认/覆盖，不能留空跳过）。通读定策略是本阶段的产出，把结论落到字段里再进逐条改写。

[驳回/不改] 是一等合法结局（不是漏改）

除 completed / needs_author_confirmation 外，新增第三个合法结局 push_back：认定某条意见不应采纳，正文一个字不动，只在回复信里据理反驳。这是真实返修的常态（审稿人误解、超范围要求、与本文定位冲突等），不是缺陷。

• 怎么触发：该 unit 的 revision_strategy 设为 push_back（或 驳回/reject 等，见上表）。revise_units.py 即把该条 status 置为 push_back：正文不改、revised_excerpt 记为「N/A — manuscript unchanged」、回复信生成据理反驳的中英回应。反驳理由填 unit 的 push_back_rationale_zh / push_back_rationale_en（不填则回复信留占位提示作者补）。
• 覆盖判定别误报：issue_matrix.md 的「修改动作」列会显示「不改（驳回）」、状态列显示 push_back；监工卡第 3 条的对照表里，某条「改稿」列为空但结局是 push_back 的，是「有意不改」，不得判成「漏改」。判漏改的唯一标准是：status 既非 completed、又非 push_back、又非 needs_author_confirmation，或该 comment_id 在回复信里根本没有回应。
• 不阻断交付：push_back 是已决结局，delivery_status 只被 needs_author_confirmation 卡；push_back 计入 project_state.json 的 counts.push_back，不进待办。
• 红线仍在：驳回≠可以不回应。回复信里该条必须有据理反驳的 response（中英），否则仍算漏回。

[合并意见] 允许多条相关意见协调回应

原子架构默认每条意见一个密封 state window，但相关意见（同一处、同一诉求的不同侧面）应允许合并成一处协调回应 + 交叉引用，而不是各写各的、自相矛盾。

• 最小用法：给相关的几条 unit 设同一个 merge_group（任意稳定 id，如 MG-limitations），并指定其中一条为 merge_lead（主回应所在的 comment_id）。主条写完整协调回应；其余成员条的 response 里交叉引用主条（如「详见 R2.3 的统一回应」/ "see our unified response to R2.3"），不重复长篇。
• 窗口不封死：state/comment_windows/<id>.json 会带上 merge_group / merge_lead，据此从 comment_registry.json 找到同组兄弟条一起看，避免协同时上下文被切断。
• 不拆原子架构：合并只是「分组 + 交叉引用」，每条仍是独立 unit、独立 comment_id、独立覆盖核验，绝不把多条塞进一条。

Anti-Forgetfulness And Token-Budget Protocol

revise-sci does not load the entire manuscript and all comments into one context window. It uses the same approach as article-writing, review-writing, and sci2doc, adapted for revise work:

1. Intake-first routing: route the comment source first, then lock the branch before loading anything large.
2. Section-paragraph atomicization: only the target section and target paragraph are used for rewrite scope.
3. Comment-scoped state windows: every processed comment_id gets its own context package under state/comment_windows/<comment_id>.json.
4. Section digests, not full reloads: cross-section consistency uses state/section_digests.json, which stores only headings, paragraph counts, and key sentences, rather than full section text.
5. Token budget compaction: state_manager.py write-cycle estimates token load and compacts related digests / reviewer context / neighboring paragraphs if the bundle exceeds the configured budget.
6. Cycle log persistence: every revise action appends to state/comment_cycle_log.json and state/comment_memory/<comment_id>.md, so a future agent does not need to reconstruct local history from scratch.
7. Snapshot safety: state_manager.py snapshot writes state snapshots so runs can be resumed with smaller context and lower drift risk.

Recommended per-comment loading command:

python scripts/state_manager.py --project-root <project_root> write-cycle --comment-id <comment_id> --token-budget 4200 --tail-lines 80 --json-summary

This command is the revise-sci equivalent of the section-scoped state loading in article-writing, review-writing, and sci2doc. It is the preferred context entry before any manual or AI-assisted change to a specific comment-linked paragraph.

Patch 修订协议（可选的确定性修订路径）

This is an optional, additive deterministic path for applying scope-locked edits. It does not replace the atomize -> issue-matrix -> revise_units -> strict_gate flow. Use it when you need a hard guarantee that only the touched blocks can change and every other block stays byte-for-byte identical, rather than having the model regenerate whole sections (the main source of scope creep and drift).

Protocol (four phases):

1. anchorize: split the target draft into blank-line blocks, assign each a stable anchor id (block-NNNN-<hash8>), and write a block manifest (anchor -> exact original bytes + sha256 + byte offsets):

   python scripts/anchorize_draft.py --draft <draft.md> --manifest <project_root>/block_manifest.json
   

2. patch: for each reviewer comment that needs a block changed, author a patch entry {anchor_id, expected_hash, new_content} where expected_hash is the block's sha256 from the manifest. Patch only the blocks that must change; never touch other anchors. The patch file is a JSON array of such entries.
3. apply (deterministic, fail-closed): locate each block by anchor id, verify its current sha256 equals the patch's expected_hash, then splice only the patched byte-spans:

   python scripts/apply_revision_patch.py --manifest <block_manifest.json> --patch <patch.json> --output <revised.md>
   

   If any entry's hash does not match (the block already changed) or the source draft drifted since anchorize, the whole patch set is rejected, nothing is written, and the script exits non-zero. There is no silent partial apply.
4. finalizer: apply_revision_patch.py reassembles the full draft from the original source, copying every unpatched byte verbatim (blocks, separators, and trailing-newline state preserved). Feed <revised.md> back into the normal polish -> literature/reference checks -> strict_gate flow before delivery.

Rules:

• The patch path is fail-closed: a hash mismatch or source drift must abort and write nothing; never coerce or auto-relocate a patch onto a changed block.
• The patch path is an increment on top of the existing pipeline, not a replacement: atomize_comments.py, build_issue_matrix.py, the state-window protocol, and strict_gate.py all still apply to the resulting draft.

缩略语首展一致性(Abbreviation Consistency)

改稿最易破坏缩略语一致性:改某句时删掉了首展、在首展之前的位置裸用 ABBR、或新增术语未首展。规则:

• 首展格式:英文 Full Name (ABBR);中文正文 中文全称（English Full Name, ABBR）。同一缩写全文只首展一次,之后裸用 ABBR,不重复展开。
• Title 禁缩写(DNA/RNA/PCR 等通用词除外);Abstract 独立,即使正文已定义,Abstract 内首次出现仍应重新展开。
• 改稿守则:替换/删除句子时若该句承载某缩写的唯一首展,须把首展移到改后稿中该缩写的新首现处;新引入的术语必须在首现处首展。
• 核查:manuscript_index.py 对改后稿产 abbreviation_index.json。undefined_use(裸用未定义)/duplicate_definition(重复首展)/title_abbreviation(Title 含缩写)为硬错须修;defined_unused(定义后未再用)为软警告,人工取舍。通用缩写见脚本 UNIVERSAL_ABBREVIATIONS 白名单,自动跳过。索引为启发式辅助,可疑项人工复核。

Response Format

response_to_reviewers must use this hierarchy:

• # 回复审稿人的邮件
• optional ## Editor Statement when the decision letter contains editor-only overall instructions but no numbered editor comments
• optional # Editor when there are numbered editorial action items
• # Reviewer #N
• ## Major / Minor
• ### Comment k

Each comment must contain:

1. 审稿意见与中文理解
2. Response to Reviewer（中英对照）
3. 可能需要修改的正文/附件内容（中英对照）
4. 修改说明（中文）
5. Evidence Attachments

Rules

• Missing information must be written as Not provided by user or 需作者确认.
• If a reviewer asks for new literature, only paper-search is allowed as the external provider family.
• paper_search_results_path may be used to ingest confirmed paper-search results into citation-oriented comment handling.
• paper_search_results_path is not trusted directly. It must first pass citation_guard.py, which performs dual verification using provider trace and identifier/title consistency evidence before citations can auto-complete a comment.
• 新增文献真实性双验（B②，不许 --offline 交付）：审稿要求补新文献时，全部新引文献必须过 citation_guard.py 的 在线真实性双验（DOI/PMID 解析、撤稿检测、逐源标题一致性）。有已 completed 的 citation 类意见时，strict_gate.py 会读 paper_search_guard_report.json：summary.online_check 非 true（即用 --offline 或没加 --live 跑的）或 all_rows_guard_verified 非 true，一律 fail-close。交付前必须 python scripts/citation_guard.py --live ... 重跑，不许 --offline 跳过。
  • 已知限制（诊断提示在本技能里看不到，但请求照打）：--live 跑时，对每条没验过、带 DOI/PMID、标题≥3 个词的文献，底层核验会额外拿标题上网回查一次，本可给出「这条的 DOI/PMID 可能填错了，线上同名文章是这个」之类的提示；但本技能的 verification_details 只保留固定字段，这些提示会被直接丢掉——请求照打、结果照扔，白花一次网络往返和限流额度。判定结果完全不受影响（guard_verified / 撤稿 / fail-close 一条都不会变），只是新引文献多时 --live 那一趟会慢些。所以验不过的条目直接看 verification_details.failure_reasons 排查，别等诊断提示。注意这条省不掉：交付必须 --live，不能为了少打请求改用 --offline。
• 新引文献↔它支撑的回复论点，须过引文核证（B④）：真实性通过只说明该文献存在，不说明它真支撑你借它下的结论。对每条「新引文献 → 它在回复信/正文里支撑的论点句」，用该文献检索到的真实 abstract 判支撑度，落 claim_evidence.json（每条含 claim_sentence / is_load_bearing / ref_id / retrieved_abstract / verdict∈support/weak/contradict/unknown / user_confirmed），再跑共享 citation_claim_check.py（CITATION_CHECK_CMD）。跨批复用由脚本自动完成，AI 不必手动记账。脚本在核证前从项目根 ref_evidence_cache.json 自动回填缺失字段，核证后强制落盘。已在别处验过 abstract 的文献，本批该行 retrieved_abstract 可留空，脚本按 ref_id 回填。同一篇文献且完全同一论点句此前已人工确认过的，脚本自动复用其 verdict 与 user_confirmed，不再重复反向验证与逐条确认。只有新的 (文献, 论点) 组合才需要你补 abstract、判支撑度并逐条人工确认。门禁强度不变，承重句被判 contradict/unknown、缺 abstract、或 support/weak 但未确认一律硬拦，新 (文献, 论点) 无 verdict 仍 fail-close。同一篇文献换去支撑另一句论点，不复用旧确认，须独立判定。有 completed citation 意见时，strict_gate.py 复用共享 citation_claim_check._row_blockers 核验 claim_evidence.json，文件缺失或任一承重句阻断即 fail-close。abstract 的检索走工作流subagent（本脚本不含 MCP）。
• build_literature_index.py must convert validated citation support into review-writing style canonical artifacts: data/literature_index.json and data/revision_claims.json.
• build_literature_index.py accepts an optional --seed-index <path> to reuse the writing project's existing literature_index.json (produced by gsw/review-writing) as a seed. Seed entries keep their original global_id; revision-found references that match a seed entry (dedup key: normalized DOI > PMID > normalized title) reuse the seed number instead of getting a new one, and truly new references continue numbering from max(seed global_id) + 1. The seed is read-only; the merged result is written only to revise-sci's own data/literature_index.json, never back to the writing project (seed-extension semantics). The seed reader tolerates the looser gsw schema (global id under any of global_id/citation_number/id/number/ref_number, back-filled by array order when absent) and a seed located either at the project root or under data/. Omitting --seed-index keeps the original rebuild-from-1 behavior unchanged.
• matrix_manager.py must derive data/synthesis_matrix.json from the canonical literature index and emit data/synthesis_matrix_audit.json before delivery.
• build_reference_registry.py must extract the final manuscript reference list into canonical data/reference_registry.json and audit body-to-reference coverage into data/reference_coverage_audit.json.
• build_reference_registry.py may import a fallback reference seed from references_source_path when the manuscript reference list is empty or absent.
• If a manuscript already has a partial numeric References section, build_reference_registry.py should try to merge missing numbered entries from the detected legacy reference source instead of failing immediately.
• If unresolved reference gaps still remain after registry rebuild, build_reference_registry.py must emit reference_recovery_request.md so the author knows exactly which source formats to provide next.
• If no original or legacy reference source is available, ask the user whether to start a new literature-search-and-fill cycle; default state is reference_search_decision=ask, not silent auto-search.
• If the user approves new reference search, the search-and-fill path must follow the review-writing discipline: paper-search retrieval only, immediate citation_guard.py after each import batch, update canonical data/literature_index.json, then refresh data/synthesis_matrix.json / data/synthesis_matrix_audit.json before any new references can enter the manuscript.
• If reference_search_decision=approved and reference gaps still exist, the skill must generate reference_search_manifest.json and reference_search_task.md so the approved search cycle is executable and auditable rather than implicit.
• The approved search cycle should also emit `reference

…(truncated)