superlab 0.1.72 → 0.1.74

package/lib/i18n.cjs

@@ -345,6 +345,9 @@ const ZH_SKILL_FILES = {
 - 如果出现 coverage、completeness、confidence 或类似健康度指标，必须明确说明这类指标回答的是“实验是否跑稳、证据是否完整”，而不是主要科学效应本身。
 - 报告开头必须写出核心洞见：结果让我们学到了什么、为什么更简单解释不够、哪个机制最能解释结果、哪些证据支撑它、它带来什么行动或设计含义，以及仍然不能外推到哪里。
 - 主表和消融要作为洞见的诊断证据，而不只是数字容器；每张表都应说明它回答的机制问题和不能证明的边界。
+- 报告必须按三轮分离修改：先做逻辑 / 证据轮，检查 bottom-line claim、证据链、主表到 claim 的映射、失败运行处理和结论是否来自已批准协议；再做理论 / 指标轮，检查术语、指标定义、分母、方向、baseline 含义、比较范围和解释是否符合领域或报告受众；最后才做语言 / 读者轮，处理白话解释、段落流、读表引导、简洁度和非营销语气。
+- 如果逻辑 / 证据轮或理论 / 指标轮仍有 blocker，不要进入语言润色；先修 blocker，或者把报告降级成 artifact-anchored interim。
+- 默认执行时可以无感跑完三轮，不需要每轮都等用户确认；只有失败轮会改变已批准 claim boundary、指标解释或行动建议时，才问一个问题。
 - 要把最关键的背景来源、方法/基线来源和指标来源直接写进报告，不要把它们藏在 \`.lab/context/*\` 里。
 - 把 \`report.md\` 当作给外部评审或合作者看的研究 memo；来源章节必须给出人类可读的 anchor references，不能拿本地路径或内部 provenance 充数。
 - 如果 \`.lab/context/terminology-lock.md\` 里已经冻结了方法名和 contribution bullets，就必须把它们带进报告。
@@ -950,6 +953,16 @@ const ZH_SKILL_FILES = {
 - 已避免的禁用修复：
 - 确认验证：
 
+## 分轮改稿纪律
+
+- 逻辑 / 证据轮结果：
+- 逻辑 / 证据 blocker：
+- 理论 / 指标 / 领域轮结果：
+- 理论 / 指标 / 领域 blocker：
+- 语言 / 读者轮结果：
+- 是否等上游 blocker 解决后才做语言润色：
+- 是否需要用户在各轮之间确认，为什么：
+
 ## 核心说明表
 
 | 问题 | 白话回答 |
@@ -1512,6 +1525,17 @@ const ZH_SKILL_FILES = {
 - 如果当前 section 是 Experiments，哪个机制被结果或消融诊断：
 - 如果当前 section 是 Conclusion，提炼了什么更广泛原则或行动含义：
 
+## 分轮改稿纪律
+
+- 逻辑轮结果：
+- 逻辑 blocker：
+- 理论 / 领域轮结果：
+- 理论 / 领域 blocker：
+- 语言轮结果：
+- 是否等逻辑和理论 blocker 解决后才做语言润色：
+- 是否需要用户在各轮之间确认，为什么：
+- 如果某轮失败，选择了哪条路径：revise / review / iterate / report / ask user：
+
 ## Terminology Clarity
 
 - Key terms introduced or revised this round:
@@ -1948,6 +1972,237 @@ for (const [relativePath, content] of Object.entries(ZH_SKILL_FILES)) {
   ZH_CONTENT[relativePath.replace(".codex", ".claude")] = content;
 }
 
+const zhRebuttalModeReference = `# Rebuttal Mode
+
+本文件是 reviewer panel 和外部 rebuttal intake 的唯一共享合同。review、write、auto 阶段只引用本文件，不复制四审稿人逻辑。
+
+## 触发条件
+
+- 用户提供 reviewer、AC、meta-review、rebuttal、同事或用户自己的批评意见
+- \`/lab:review\` 审查论文、section、表、图、report 或 claim set
+- \`/lab:write\` 在接受非平凡论文轮次前需要 reviewer gate
+- \`/lab:auto\` 包含 paper-facing report、write 或 reviewer-driven repair
+
+普通路径修复、依赖安装、实验轮询不触发本模式，除非它们会影响 paper-facing claim。
+
+## 外部 Rebuttal Intake
+
+外部批评必须先转成内部 issue，再进入改稿或实验。
+
+每条外部意见必须记录：
+
+- 来源：reviewer id、AC、meta-review、同事或用户
+- 批评摘要
+- 影响对象：claim、section、table、figure、protocol、metric、threat model、experiment 或 wording
+- 审稿轴：R1、R2、R3 或 R4
+- 严重性：fatal、major、minor 或 clarification
+- 路由：\`write\`、\`iterate\`、\`report\`、\`framing\`、\`data\`、\`spec\` 或 \`ask-user\`
+- 接受检查：什么证据或稿件状态算修完
+
+## Reviewer Panel
+
+### R1 Significance / Originality / Insight
+
+检查问题是否重要、贡献是否只是工程堆叠、核心 insight 是否回答社区学到了什么。
+
+### R2 Soundness / Technical Quality
+
+检查方法、假设、协议、baseline、实现细节、指标和统计是否站得住。
+
+### R3 Evaluation / Analysis
+
+检查消融、鲁棒性、泛化、失败案例、替代解释和指标解释是否完整。
+
+### R4 Presentation / Clarity
+
+检查叙事线、术语、图表自解释、引用、LaTeX 和 section flow 是否清楚。
+
+## Core Mutation Ledger
+
+核心变更包括改 paper-level claim、实验协议、指标定义、主指标、threat model、reviewer profile、数据集范围、benchmark 范围或 framing。
+
+L1/L2 默认把核心变更当作批准边界。L3 可以在已批准 envelope 内执行核心变更，但必须先用 \`.lab/.managed/templates/core-mutation-ledger.md\` 写入 \`.lab/writing/core-mutation-ledger.md\`。
+`;
+
+ZH_CONTENT[path.join(".codex", "skills", "lab", "references", "rebuttal-mode.md")] = zhRebuttalModeReference;
+ZH_CONTENT[path.join(".claude", "skills", "lab", "references", "rebuttal-mode.md")] = zhRebuttalModeReference;
+
+ZH_CONTENT[path.join(".lab", ".managed", "templates", "rebuttal-panel.md")] = `# Rebuttal Panel / rebuttal 面板
+
+## 审查目标
+
+- 目标工件：
+- 阶段：
+- 自治级别：
+- 证据基础：
+- 外部 rebuttal 来源（如果有）：
+
+## 外部 Rebuttal Intake
+
+| 来源 | 批评摘要 | 影响对象 | 审稿轴 | 严重性 | 路由 | 接受检查 |
+| --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |
+
+## 四类审稿视角
+
+### R1 Significance / Originality / Insight
+
+- 问题：
+- 为什么重要：
+- 必要修复：
+- 路由：
+- 接受检查：
+
+### R2 Soundness / Technical Quality
+
+- 问题：
+- 为什么重要：
+- 必要修复：
+- 路由：
+- 接受检查：
+
+### R3 Evaluation / Analysis
+
+- 问题：
+- 为什么重要：
+- 必要修复：
+- 路由：
+- 接受检查：
+
+### R4 Presentation / Clarity
+
+- 问题：
+- 为什么重要：
+- 必要修复：
+- 路由：
+- 接受检查：
+
+## 可执行问题登记
+
+| ID | 审稿轴 | 严重性 | 影响工件 | 问题 | 必要修复 | 路由 | 接受检查 | 是否需要核心变更 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |  |  |
+
+## 核心变更检查
+
+- 是否需要改变 paper-level claim、协议、指标、threat model、数据集范围、benchmark 范围或 framing：
+- 当前自治级别是否允许：
+- 核心变更台账路径：
+- 被废弃的旧 claim 或资产：
+- 新验证要求：
+
+## 决策
+
+- continue / revise / rerun / escalate / stop：
+- 下一路由：
+- 阻塞 issue：
+- 交接说明：
+`;
+
+ZH_CONTENT[path.join(".lab", ".managed", "templates", "core-mutation-ledger.md")] = `# 核心变更台账
+
+## 变更摘要
+
+- 变更 ID：
+- 日期：
+- Mutation trigger / 触发源：internal reviewer panel / external rebuttal / failed gate / anomaly / user request
+- 是否被当前自治级别允许：
+- campaign 或阶段：
+- owner：
+
+## 被改变的核心项
+
+- 类型：claim / protocol / metric / threat model / reviewer profile / dataset scope / benchmark scope / framing
+- 旧状态：
+- 新状态：
+- 为什么必须改：
+- 为什么不能只靠稿件措辞修复：
+
+## 来源 Issue
+
+- rebuttal 面板路径：
+- issue ID：
+- 审稿轴：
+- 严重性：
+- 外部批评来源（如果有）：
+
+## 作废或收窄的旧结论
+
+- Invalidated prior claims：
+- 作废 claims：
+- 受影响 sections：
+- 受影响 tables：
+- 受影响 figures：
+- 受影响 reports：
+- 被 supersede 的结果或运行：
+- 仍可在更窄解释下使用的证据：
+
+## 全文影响审计
+
+- Paper-wide impact audit：
+- Abstract：
+- Introduction：
+- Method：
+- Experiments：
+- Related work：
+- Conclusion：
+- Tables：
+- Figures / analysis assets：
+- Metric glossary：
+- Terminology glossary：
+- Paper plan：
+
+## 新验证
+
+- 需要的新证据：
+- rerun 或 validator 命令：
+- manuscript validators：
+- confirmation check：
+- 结果：
+
+## 回滚
+
+- 回滚条件：
+- 回滚目标：
+- 备注：
+`;
+
+const zhReviewRebuttalMode = `
+
+## Rebuttal 模式
+
+- 当目标是论文、section、表、图、report、claim set 或外部 rebuttal 批评时，必须读取 \`skills/lab/references/rebuttal-mode.md\`。
+- 不要在 review 阶段复制四审稿人逻辑；使用 \`.lab/.managed/templates/rebuttal-panel.md\` 写持久 reviewer panel 工件。
+- 外部 reviewer、AC、meta-review、同事或用户批评必须先转成内部可执行 issue，再进入改稿或 response draft。
+- Reviewer Panel 按 R1 Significance / Originality / Insight、R2 Soundness / Technical Quality、R3 Evaluation / Analysis、R4 Presentation / Clarity 四类审稿视角分类。
+- L1/L2 默认把核心变更当作批准边界；L3 通过共享核心变更台账策略处理核心 claim、协议、指标、threat model、数据集范围、benchmark 范围或 framing 变化。
+`;
+
+const zhWriteRebuttalMode = `
+
+## Rebuttal 模式
+
+- 当用户提供外部 reviewer、AC、meta-review、rebuttal、同事或用户自己的批评时，起草前必须读取 \`skills/lab/references/rebuttal-mode.md\`。
+- 非平凡 paper-facing 写作轮次应把 rebuttal mode 当成 reviewer acceptance gate，并用 \`.lab/.managed/templates/rebuttal-panel.md\` 写 critique artifact。
+- 不要实现 write-only rebuttal workflow；共享 rebuttal-mode 负责审稿轴、外部 rebuttal intake、issue routing 和核心变更策略。
+- fatal 或 major 的 R1/R2/R3 issue 未解决前，不要进入 prose polish；先修复、路由到 \`iterate\` / \`report\` / \`framing\` / \`spec\`，或用证据显式 waive。
+- L3 或显式授权的写作 campaign 可以改 paper-level claim、协议、指标、threat model、数据集范围、benchmark 范围或 framing，但必须通过 \`skills/lab/references/rebuttal-mode.md\` 里的 Core Mutation Ledger 策略。
+- 在 write iteration artifact 里记录 rebuttal panel 路径、核心变更台账路径和未解决 issue id。
+`;
+
+const zhAutoRebuttalMode = `
+
+## Rebuttal Mode Promotion Guard
+
+- 当 auto campaign 包含 paper-facing \`report\`、\`write\`、外部 rebuttal repair 或 reviewer-driven paper revision 时，必须读取 \`skills/lab/references/rebuttal-mode.md\`。
+- 使用 \`.lab/.managed/templates/rebuttal-panel.md\` 写持久 Reviewer Panel 工件，不要在 auto mode 里复制一套 reviewer workflow。
+- 外部 rebuttal 批评必须先转成内部 issue、route 和 acceptance check，再开始 \`run\`、\`iterate\`、\`report\` 或 \`write\`。
+- L1/L2 默认把核心变更当作批准边界；L3 可以在已批准 envelope 内修改 paper-level claim、协议、指标、threat model、reviewer profile、数据集范围、benchmark 范围或 framing。
+- L3 执行核心变更前，必须用 \`.lab/.managed/templates/core-mutation-ledger.md\` 写或更新 \`.lab/writing/core-mutation-ledger.md\`。
+- 核心变更必须触发全文影响审计：section、table、figure、report、metric glossary、terminology glossary 和 paper plan 都要标记为已更新、已 supersede 或仍待处理。
+- 当前 L3 envelope 允许修复且预算未耗尽时，不要因为可恢复 reviewer issue 停止；按 issue route 继续进入 \`write\`、\`iterate\`、\`report\`、\`framing\` 或 \`spec\`。
+`;
+
 ZH_CONTENT[path.join(".lab", "system", "core.md")] = `# Lab 系统核心
 
 本项目使用 \`.lab/\` 作为持久研究工作流根目录。
@@ -2259,6 +2514,10 @@ ZH_CONTENT[path.join(".codex", "skills", "lab", "stages", "write.md")] = `# \`/l
 - 一旦 paper-facing 模型名或消融名锁定，后续 prose、表格、caption 和排序摘要都必须复用 canonical label，不要再换回“完整模型”“去除结构主干”这类叙述性别名。
 - 整篇论文必须沿用同一个核心洞见锚点：Introduction 制造常规认知与本文发现之间的反差，Method 把洞见转成设计动机，Experiments 用结果和消融诊断洞见，Conclusion 提炼更广泛原则和边界。
 - 不要单开 \`Our Insights\` 或 \`核心洞见\` 章节来凑数；洞见要融入动机、机制、证据和限制。
+- 重要 section 不能一轮通写到底，必须按三轮分离改稿：逻辑轮先检查段落角色、claim 链、前提到结论的过渡、证据依赖和与相邻 section 的衔接，不做措辞润色；理论 / 领域轮在逻辑过关后检查概念、领域术语、指标定义、引用锚点和框架是否真的支撑 claim，不把语言流畅当成理论正确；语言轮只能在前两轮没有未解决 blocker 后再处理学术语气、句式节奏、过渡、简洁度和局部可读性。
+- 如果逻辑轮或理论 / 领域轮还有 blocker，不要继续语言 polish；先修 blocker，或者在证据问题上回到 \`review\`、\`iterate\` 或 \`report\`。
+- 默认自动执行不需要用户逐轮确认；把三轮结果写进 write iteration artifact。只有失败轮会改变 paper-level framing、claim、protocol 或下游 section 结构时，才停下来问一个问题。
+- 如果用户明确要求 interactive / human-in-the-loop 改稿，就每轮展示结果，等用户确认后再从逻辑轮进入理论轮、再进入语言轮。
 - 起草或润色前，先检查当前 section 在 \`section-style-policies.md\` 里的规则块，并遵守其中的 encouraged expressions、discouraged expressions 和 banned expressions / moves。
 - 不要默认当前 section 可以无限继续压句子；在同一个 section 上做新的 tighten、compress 或 polish 之前，先过一遍 section-level acceptance gate。
 - section-level acceptance gate 至少要显式确认命名一致性、前后文一致性、claim / metric / ranking 与当前证据的一致性、局部清晰度、局部简洁度和 section 风格合规（section-style compliance）。
@@ -3151,6 +3410,21 @@ ZH_CONTENT[path.join(".claude", "skills", "lab", "stages", "auto.md")] =
 ZH_CONTENT[path.join(".claude", "skills", "lab", "stages", "report.md")] =
   ZH_CONTENT[path.join(".codex", "skills", "lab", "stages", "report.md")];
 
+for (const platformRoot of [".codex", ".claude"]) {
+  const reviewKey = path.join(platformRoot, "skills", "lab", "stages", "review.md");
+  const writeKey = path.join(platformRoot, "skills", "lab", "stages", "write.md");
+  const autoKey = path.join(platformRoot, "skills", "lab", "stages", "auto.md");
+  if (ZH_CONTENT[reviewKey] && !ZH_CONTENT[reviewKey].includes("rebuttal-mode.md")) {
+    ZH_CONTENT[reviewKey] += zhReviewRebuttalMode;
+  }
+  if (ZH_CONTENT[writeKey] && !ZH_CONTENT[writeKey].includes("rebuttal-mode.md")) {
+    ZH_CONTENT[writeKey] += zhWriteRebuttalMode;
+  }
+  if (ZH_CONTENT[autoKey] && !ZH_CONTENT[autoKey].includes("core-mutation-ledger.md")) {
+    ZH_CONTENT[autoKey] += zhAutoRebuttalMode;
+  }
+}
+
 const zhStageReportCloseout = `
 
 ## 阶段报告收尾

package/lib/install.cjs

@@ -654,6 +654,7 @@ function localizeInstalledAssets(targetDir, lang, { newlyCreatedProjectOwnedPath
     path.join(".codex", "skills", "lab", "stages", "write.md"),
     path.join(".codex", "skills", "lab", "references", "workflow.md"),
     path.join(".codex", "skills", "lab", "references", "recipes.md"),
+    path.join(".codex", "skills", "lab", "references", "rebuttal-mode.md"),
     path.join(".claude", "skills", "lab", "SKILL.md"),
     path.join(".claude", "skills", "lab", "stages", "idea.md"),
     path.join(".claude", "skills", "lab", "stages", "data.md"),
@@ -667,6 +668,7 @@ function localizeInstalledAssets(targetDir, lang, { newlyCreatedProjectOwnedPath
     path.join(".claude", "skills", "lab", "stages", "write.md"),
     path.join(".claude", "skills", "lab", "references", "workflow.md"),
     path.join(".claude", "skills", "lab", "references", "recipes.md"),
+    path.join(".claude", "skills", "lab", "references", "rebuttal-mode.md"),
     path.join(".lab", ".managed", "templates", "idea.md"),
     path.join(".lab", ".managed", "templates", "data.md"),
     path.join(".lab", ".managed", "templates", "framing.md"),
@@ -677,6 +679,8 @@ function localizeInstalledAssets(targetDir, lang, { newlyCreatedProjectOwnedPath
     path.join(".lab", ".managed", "templates", "stage-report.md"),
     path.join(".lab", ".managed", "templates", "iteration-report.md"),
     path.join(".lab", ".managed", "templates", "review-checklist.md"),
+    path.join(".lab", ".managed", "templates", "rebuttal-panel.md"),
+    path.join(".lab", ".managed", "templates", "core-mutation-ledger.md"),
     path.join(".lab", ".managed", "templates", "final-report.md"),
     path.join(".lab", ".managed", "templates", "main-tables.md"),
     path.join(".lab", ".managed", "templates", "artifact-status.md"),

package/package-assets/shared/lab/.managed/templates/core-mutation-ledger.md

@@ -0,0 +1,66 @@
+# Core Mutation Ledger
+
+## Mutation Summary
+
+- Mutation ID:
+- Date:
+- Mutation trigger: internal reviewer panel / external rebuttal / failed gate / anomaly / user request
+- Allowed by autonomy level:
+- Campaign or stage:
+- Owner:
+
+## Changed Core Item
+
+- Core item type: claim / protocol / metric / threat model / reviewer profile / dataset scope / benchmark scope / framing
+- Previous state:
+- New state:
+- Why the change is necessary:
+- Why a smaller manuscript-only fix is insufficient:
+
+## Source Issue
+
+- Rebuttal panel path:
+- Issue ID:
+- Reviewer axis:
+- Severity:
+- External criticism source, if any:
+
+## Invalidated Prior Claims
+
+- Invalidated prior claims:
+- Claims invalidated:
+- Sections invalidated:
+- Tables invalidated:
+- Figures invalidated:
+- Reports invalidated:
+- Results or runs superseded:
+- Evidence that remains valid under a narrower interpretation:
+
+## Paper-Wide Impact Audit
+
+- Paper-wide impact audit:
+- Abstract impact:
+- Introduction impact:
+- Method impact:
+- Experiments impact:
+- Related work impact:
+- Conclusion impact:
+- Table impact:
+- Figure or analysis asset impact:
+- Metric glossary impact:
+- Terminology glossary impact:
+- Paper plan impact:
+
+## New Verification
+
+- New evidence required:
+- Rerun command or validation command:
+- Manuscript validators required:
+- Confirmation check:
+- Result:
+
+## Rollback
+
+- Rollback condition:
+- Rollback target:
+- Notes:

package/package-assets/shared/lab/.managed/templates/rebuttal-panel.md

@@ -0,0 +1,71 @@
+# Rebuttal Panel
+
+## Review Target
+
+- Target artifact:
+- Stage:
+- Autonomy level:
+- Evidence base:
+- External rebuttal source, if any:
+
+## External Rebuttal Intake
+
+| Source | Raw criticism summary | Affected unit | Reviewer axis | Severity | Route | Acceptance check |
+| --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |
+
+## Reviewer Panel Findings
+
+### R1 Significance / Originality / Insight
+
+- Finding:
+- Why it matters:
+- Required fix:
+- Route:
+- Acceptance check:
+
+### R2 Soundness / Technical Quality
+
+- Finding:
+- Why it matters:
+- Required fix:
+- Route:
+- Acceptance check:
+
+### R3 Evaluation / Analysis
+
+- Finding:
+- Why it matters:
+- Required fix:
+- Route:
+- Acceptance check:
+
+### R4 Presentation / Clarity
+
+- Finding:
+- Why it matters:
+- Required fix:
+- Route:
+- Acceptance check:
+
+## Actionable Issue Register
+
+| ID | Axis | Severity | Affected artifact | Finding | Required fix | Route | Acceptance check | Core mutation required |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |  |  |
+
+## Core Mutation Check
+
+- Does any issue require changing a paper-level claim, protocol, metric, threat model, dataset scope, benchmark scope, or framing:
+- If yes, is the current autonomy level L3 or explicitly approved for core mutation:
+- Core mutation ledger path:
+- Prior claims or assets invalidated:
+- New verification required:
+
+## Decision
+
+- Continue / revise / rerun / escalate / stop:
+- Next route:
+- Blocking issue, if any:
+- Handoff note:
+

package/package-assets/shared/lab/.managed/templates/stage-report.md

@@ -39,6 +39,16 @@
 - Forbidden repairs avoided:
 - Confirmation check:
 
+## Revision Pass Discipline
+
+- Logic / evidence pass outcome:
+- Logic / evidence blockers found:
+- Theory / metric / field pass outcome:
+- Theory / metric / field blockers found:
+- Language / reader pass outcome:
+- Was language polish delayed until upstream blockers were resolved:
+- Was user confirmation required between passes, and why:
+
 ## Core Explanation Table
 
 | Question | Plain Answer |

package/package-assets/shared/lab/.managed/templates/write-iteration.md

@@ -51,6 +51,17 @@
 - If the section is Experiments, which mechanism did the result or ablation diagnose:
 - If the section is Conclusion, what broader principle or action implication was stated:
 
+## Revision Pass Discipline
+
+- Logic pass outcome:
+- Logic blockers found:
+- Theory / field pass outcome:
+- Theory / field blockers found:
+- Language pass outcome:
+- Was language polish delayed until logic and theory blockers were resolved:
+- Was user confirmation required between passes, and why:
+- If a pass failed, what route was chosen: revise / review / iterate / report / ask user:
+
 ## Terminology Clarity
 
 - Key terms introduced or revised this round:

package/package-assets/shared/skills/lab/SKILL.md

@@ -53,6 +53,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Separate sourced facts from model-generated hypotheses.
 - Preserve failed runs, failed ideas, and limitations.
 - Use `skills/lab/references/recipes.md` as the quick path for common stage chains without inventing new commands.
+- Use `.codex/skills/lab/references/rebuttal-mode.md` or `.claude/skills/lab/references/rebuttal-mode.md` as the single shared reviewer-panel and external rebuttal intake contract. Do not copy four-reviewer logic into `review`, `write`, or `auto` stage guides.
 
 ## Stage Contract
 
@@ -220,6 +221,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Surface the strongest alternative explanation and any boundary risk that should narrow the claim.
 - Output findings first, then fatal flaws, then fix priority, then residual risks.
 - Use `.lab/.managed/templates/review-checklist.md`.
+- When reviewing paper-facing artifacts or external rebuttal criticism, use the shared rebuttal mode reference and write the panel artifact from `.lab/.managed/templates/rebuttal-panel.md`.
 - Write durable review conclusions back to `.lab/context/decisions.md`, `.lab/context/evidence-index.md`, or `.lab/context/open-questions.md` when they affect later stages. Do not use `.lab/context/state.md` as a primary write target.
 
 ### `/lab:report`
@@ -348,6 +350,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Workflow summary: `.codex/skills/lab/references/workflow.md` or `.claude/skills/lab/references/workflow.md`
 - Stage recipes: `skills/lab/references/recipes.md`
 - Brainstorming integration: `.codex/skills/lab/references/brainstorming-integration.md` or `.claude/skills/lab/references/brainstorming-integration.md`
+- Rebuttal mode: `.codex/skills/lab/references/rebuttal-mode.md` or `.claude/skills/lab/references/rebuttal-mode.md`
 - Idea stage guide: `.codex/skills/lab/stages/idea.md` or `.claude/skills/lab/stages/idea.md`
 - Data stage guide: `.codex/skills/lab/stages/data.md` or `.claude/skills/lab/stages/data.md`
 - Auto stage guide: `.codex/skills/lab/stages/auto.md` or `.claude/skills/lab/stages/auto.md`

package/package-assets/shared/skills/lab/references/rebuttal-mode.md

@@ -0,0 +1,135 @@
+# Rebuttal Mode
+
+Use this reference whenever a lab stage must turn reviewer-style criticism into executable research or writing work. Keep this logic here; stage guides should reference this file instead of copying the reviewer panel rules.
+
+## When To Trigger
+
+Trigger rebuttal mode when any of these are present:
+
+- external reviewer, AC, meta-review, rebuttal, or colleague criticism
+- a user asks for reviewer-style criticism before another write or auto round
+- `/lab:review` targets a paper, section, table, figure, report, or claim set
+- `/lab:write` needs a reviewer gate before accepting a nontrivial manuscript round
+- `/lab:auto` is allowed to run `write`, paper-facing `report`, or reviewer-driven repair
+
+Do not trigger rebuttal mode for routine implementation reviews, path fixes, dependency setup, or experiment polling unless the issue affects paper-facing claims.
+
+## Required Inputs
+
+- artifact under review: section, paper, report, table, figure, result, or claim set
+- evidence base used by the artifact
+- current framing or mission when available
+- current metric and terminology glossaries when relevant
+- external rebuttal text when provided
+- active autonomy level when the stage is `/lab:auto`
+
+## External Rebuttal Intake
+
+External criticism must be converted into internal issues before any rewrite.
+
+For each external comment, record:
+
+- source: reviewer id, AC, meta-review, colleague, or user
+- raw criticism summary
+- affected paper unit: claim, section, table, figure, protocol, metric, threat model, experiment, or wording
+- reviewer axis: R1, R2, R3, or R4
+- severity: fatal, major, minor, or clarification
+- route: `write`, `iterate`, `report`, `framing`, `data`, `spec`, or `ask-user`
+- acceptance check: concrete evidence or manuscript condition that resolves the issue
+
+Do not answer external criticism with prose-only reassurance. If the issue is valid, it must become a repair task. If it is invalid, state the evidence that rules it out.
+
+## Reviewer Panel
+
+Run four independent review lenses. Each lens must produce actionable issues, not vague advice.
+
+### R1 Significance / Originality / Insight
+
+Ask whether the problem matters, whether the paper teaches the community something beyond an artifact, whether the motivation is necessary, and whether the claimed insight is deeper than a module stack or benchmark gain.
+
+Typical fixes route to `framing`, `write`, or `iterate`.
+
+### R2 Soundness / Technical Quality
+
+Ask whether the method, assumptions, proofs, protocol, baselines, implementation details, metrics, and statistics are technically defensible and reproducible.
+
+Typical fixes route to `spec`, `run`, `iterate`, `report`, or `write`.
+
+### R3 Evaluation / Analysis
+
+Ask whether evaluation covers ablations, robustness, generalization, failure cases, alternative explanations, and metric interpretation.
+
+Typical fixes route to `iterate`, `report`, or `write`.
+
+### R4 Presentation / Clarity
+
+Ask whether the storyline, terminology, figure/table semantics, citations, LaTeX, and section flow are readable and self-contained.
+
+Typical fixes route to `write`.
+
+## Actionable Issue Register
+
+Every issue must include:
+
+- id
+- reviewer axis
+- severity
+- affected artifact
+- finding
+- why it matters
+- required fix
+- route
+- acceptance check
+- whether core mutation is required
+
+Prioritize fatal and major issues before language polish. Minor presentation fixes may be batched.
+
+## Core Mutation Policy
+
+Core mutation means changing any of:
+
+- paper-level claim or contribution
+- experiment or evaluation protocol
+- metric definition or primary metric choice
+- threat model, reviewer profile, dataset scope, or benchmark scope
+- paper-facing framing that invalidates existing sections or tables
+
+L1 and L2 treat core mutation as an approval boundary unless the current contract explicitly allows it.
+
+L3 may perform core mutation inside the approved campaign envelope. It must not hide the change as ordinary writing or routine repair.
+
+When L3 changes a core item, write or update `.lab/writing/core-mutation-ledger.md` from `.lab/.managed/templates/core-mutation-ledger.md` before claiming the issue is resolved.
+
+## Core Mutation Ledger
+
+The ledger must record:
+
+- mutation trigger: internal reviewer panel, external rebuttal, failed gate, anomaly, or user request
+- changed core item
+- previous state
+- new state
+- why the change is necessary
+- invalidated prior claims, sections, tables, figures, reports, or results
+- new evidence required
+- rerun, rewrite, or validation command
+- paper-wide impact audit
+- rollback condition
+
+If old evidence remains usable under a narrower interpretation, say exactly where it remains valid. If it does not remain valid, mark it superseded.
+
+## Stage Integration
+
+`/lab:review` uses rebuttal mode as its reviewer-panel operating mode when the target is paper-facing or when external criticism is supplied.
+
+`/lab:write` uses rebuttal mode as an acceptance gate for nontrivial section or manuscript rounds. A write round may not proceed to prose polish while a fatal or major R1/R2/R3 issue remains unresolved.
+
+`/lab:auto` uses rebuttal mode as a promotion guard when the campaign includes paper-facing `report`, `write`, or external rebuttal repair. In L3, auto may execute core mutation after ledger entry and impact audit.
+
+## Stop Or Continue Decision
+
+- Continue when issues are actionable inside the approved envelope.
+- Rerun when the acceptance check requires new evidence.
+- Revise when the fix is manuscript-only.
+- Escalate when the issue requires a decision outside the current autonomy level.
+- Stop only when the remaining issue is terminal, already waived with evidence, or outside the campaign boundary.
+

package/package-assets/shared/skills/lab/stages/auto.md

@@ -125,6 +125,16 @@
 - Before each rung and before each success, stop, or promotion decision, re-check the generic academic-risk questions: setting semantics, visibility/leakage, anchor or label policy, scale comparability, metric validity, comparison validity, statistical validity, claim boundary, and integrity self-check.
 - Before each success, stop, or promotion decision, also re-check the anomaly policy: whether anomaly signals fired, whether simpler explanations were ruled out, whether a cross-check was performed, and whether the current interpretation is still the narrowest supported one.
 
+## Rebuttal Mode Promotion Guard
+
+- When an auto campaign includes paper-facing `report`, `write`, external rebuttal repair, or reviewer-driven paper revision, load the shared rebuttal procedure in `skills/lab/references/rebuttal-mode.md`.
+- Use `.lab/.managed/templates/rebuttal-panel.md` for the durable Reviewer Panel artifact instead of embedding a separate reviewer workflow in auto mode.
+- External rebuttal criticism must be converted into internal issues, routes, and acceptance checks before `run`, `iterate`, `report`, or `write` work starts.
+- In L1/L2, core mutation remains an approval boundary unless explicitly authorized by the auto contract.
+- In L3, auto may change paper-level claim, protocol, metric, threat model, reviewer profile, dataset scope, benchmark scope, or framing inside the approved campaign envelope. It must first write or update `.lab/writing/core-mutation-ledger.md` from `.lab/.managed/templates/core-mutation-ledger.md`.
+- A core mutation must trigger paper-wide impact audit before promotion: affected sections, tables, figures, reports, metric glossary, terminology glossary, and paper plan must be listed as updated, superseded, or still pending.
+- Do not stop after a recoverable reviewer issue when the current L3 envelope allows a repair route and budget remains. Continue through `write`, `iterate`, `report`, `framing`, or `spec` according to the issue route.
+
 ## Gate Miss And Repair Loop
 
 - A gate miss is not automatically a terminal stop for `L2` or `L3` when `iterate` is allowed and the loop budget remains.

package/package-assets/shared/skills/lab/stages/report.md

@@ -66,6 +66,12 @@
 - Keep insight interpretation in the reader summary, method overview, main result interpretation, ablations, and limitations. Do not hide it in a standalone inspirational paragraph.
 - When results are negative, mixed, or too strong, still write the insight honestly: what the result teaches about the mechanism, target, setup, metric, or boundary, and what action follows.
 - For technical or business reports, state the decision implication as an actionable rule, next experiment, system change, or stop boundary. Do not leave the insight as a theoretical phrase only.
+- Draft reports with three separated revision passes:
+  - Logic / evidence pass: check the bottom-line claim, evidence chain, table-to-claim mapping, failed-run handling, and whether conclusions follow from the approved protocol. Do not polish wording in this pass.
+  - Theory / metric pass: after logic is clean, check terminology, metric definitions, denominators, directionality, baseline meaning, comparison scope, and whether the chosen interpretation fits the field or report audience.
+  - Language / reader pass: only after logic and metric blockers are resolved, improve plain-language explanation, section flow, table-reading guidance, concision, and non-marketing tone.
+- Do not move to language cleanup when the logic / evidence pass or theory / metric pass still has an unresolved blocker; repair the blocker first or downgrade the report to artifact-anchored interim.
+- Default report execution may run the three passes without asking the user between them. Ask only when a failed pass would change the approved claim boundary, metric interpretation, or action recommendation.
 - When citing prior work or baselines in the method overview, include only the few anchor references a collaborator needs, and summarize their role and limitation in one short line each.
 - Report only the few references a collaborator needs to orient themselves quickly; do not turn `report.md` into a full bibliography dump.
 - In `Background Sources`, `Method and Baseline Sources`, and `Metric Sources`, every anchor must include a citation line, one short line about what it established or measures, and one limitation or caveat.

package/package-assets/shared/skills/lab/stages/review.md

@@ -41,6 +41,15 @@
 - unresolved alternative explanations
 - boundary risks that should narrow the claim even if the implementation is correct
 
+## Rebuttal Mode
+
+- When the target is a paper, paper section, table, figure, report, claim set, or external rebuttal criticism, run the shared reviewer-panel procedure in `skills/lab/references/rebuttal-mode.md`.
+- Do not duplicate the four-reviewer logic in this stage file. Use `.lab/.managed/templates/rebuttal-panel.md` for the durable critique artifact.
+- External rebuttal, AC, meta-review, colleague, or user criticism must be converted into internal actionable issues before any rewrite or response draft.
+- The Reviewer Panel must classify issues across R1 Significance / Originality / Insight, R2 Soundness / Technical Quality, R3 Evaluation / Analysis, and R4 Presentation / Clarity.
+- Each issue must include severity, affected artifact, required fix, route, acceptance check, and whether core mutation is required.
+- In L1/L2, core mutation remains an approval boundary unless explicitly authorized. In L3, route core mutation through the shared ledger policy instead of treating it as a reviewer-stage blocker.
+
 ## Output Style
 
 - concise summary first

package/package-assets/shared/skills/lab/stages/write.md

@@ -71,6 +71,15 @@ Run these on every round:
 - reviewer pass -> `skills/lab/references/paper-writing/paper-review.md`
 - section-specific style policy -> `skills/lab/references/paper-writing/section-style-policies.md` (load the block matching the current section)
 
+## Rebuttal Mode
+
+- When the user provides external reviewer, AC, meta-review, rebuttal, colleague, or user criticism, load `skills/lab/references/rebuttal-mode.md` before drafting.
+- For nontrivial paper-facing write rounds, use rebuttal mode as the reviewer acceptance gate and write the critique artifact from `.lab/.managed/templates/rebuttal-panel.md`.
+- Do not implement a separate write-only rebuttal workflow. The shared rebuttal-mode reference owns reviewer axes, external rebuttal intake, issue routing, and core mutation policy.
+- Fatal or major R1/R2/R3 issues block prose polish until they are repaired, routed to `iterate`/`report`/`framing`/`spec`, or explicitly waived with evidence.
+- In L3 or an explicitly core-authorized write campaign, paper-level claim, protocol, metric, threat model, dataset scope, benchmark scope, or framing changes are allowed only through the shared Core Mutation Ledger policy in `skills/lab/references/rebuttal-mode.md`.
+- Record the rebuttal panel path, any core mutation ledger path, and unresolved issue ids in the write-iteration artifact.
+
 ## Reference-Guided Deep Write
 
 Trigger this mode automatically when the user provides reference PDFs, paper URLs, local reference-paper paths, a template paper, or asks to "参考" papers while continuing `/lab:write`.
@@ -156,6 +165,13 @@ Do not enter prose polish until the current section has passed the reference-con
 - In Experiments, interpret results diagnostically: say which part of the insight each result, ablation, robustness check, or failure case supports, weakens, or bounds. Do not only read numbers from a table.
 - In Conclusion, state the broader principle or action implication implied by the evidence, then state the boundary. Do not introduce a new insight there.
 - Avoid paper-facing headings such as `Our Insights` or `核心洞见`; if a heading is needed, use normal section roles such as motivation, analysis, ablation, or discussion and let the insight appear in the prose.
+- Nontrivial section work must use three separated revision passes instead of one all-purpose rewrite:
+  - Logic pass: check the paragraph role, claim chain, premise-to-conclusion transition, evidence dependency, and whether the section naturally follows from adjacent sections. Do not polish wording in this pass.
+  - Theory / field pass: after the logic pass is clean, check concept use, field terminology, metric definitions, citation anchors, and whether the chosen framework actually fits the claim. Do not treat fluent language as proof that the theory is right.
+  - Language pass: only after logic and theory blockers are resolved, revise academic tone, sentence rhythm, transitions, concision, and local readability.
+- Do not continue into language polish when the logic pass or theory / field pass still has an unresolved blocker; repair the blocker first or route back to `review`, `iterate`, or `report` if the blocker is evidentiary.
+- Default automation should not require the user to approve every pass. Record the three pass outcomes in the write-iteration artifact and stop for one user question only when a failed pass would change paper-level framing, claims, protocol, or downstream section structure.
+- If the user explicitly asks for interactive or human-in-the-loop rewriting, show the result of each pass and wait before moving from logic -> theory -> language.
 - Before drafting or polishing, check the current section's block in `section-style-policies.md` and follow its encouraged, discouraged, and banned expression lists.
 - Before any additional tighten, compress, or polish pass on the same section, run a section-level acceptance gate first.
 - The section-level acceptance gate is passed only when canonical naming consistency, adjacent-section consistency, claim, metric, and ranking consistency with the current evidence, local clarity, local concision, and section-style compliance are all explicitly checked and no unresolved blocker remains.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "superlab",
-  "version": "0.1.72",
+  "version": "0.1.74",
   "description": "Strict /lab research workflow installer for Codex and Claude",
   "keywords": [
     "codex",