superlab 0.1.73 → 0.1.75

package/lib/i18n.cjs

@@ -1972,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/\` 作为持久研究工作流根目录。
@@ -2472,6 +2703,8 @@ const zhAutoPriorityCodexLine =
   "显式的 `/lab:auto` 或 `/lab-auto` 请求，其优先级高于 brainstorming、spec review 这类更宽的创作或审阅技能路径。";
 const zhAutoPriorityClaudeLine =
   "显式的 `/lab auto` 或 `/lab-auto` 请求，其优先级高于 brainstorming、spec review 这类更宽的创作或审阅技能路径。";
+const zhAutoVisibleCloseoutLine =
+  "最终可见收尾必须直接消费已通过校验的 stage report：展示请求交付物或目标的状态、核心说明表的关键行、证据路径、验证命令和验证结果、已知缺口，以及下一步动作和原因。不能只用“已完成”“已推送”或流水账命令日志结束。";
 
 ZH_CONTENT[path.join(".codex", "prompts", "lab.md")] = ZH_CONTENT[
   path.join(".codex", "prompts", "lab.md")
@@ -2485,6 +2718,9 @@ ZH_CONTENT[path.join(".codex", "prompts", "lab-auto.md")] = ZH_CONTENT[
 ].replace(
   "已批准的 `L2` 和 `L3` 执行 campaign 默认进入执行模式。",
   `${zhAutoPriorityCodexLine}\n已批准的 \`L2\` 和 \`L3\` 执行 campaign 默认进入执行模式。`
+).replace(
+  "不要用 `sleep 30`、单次 `pgrep` 或一次性的 `metrics.json` 探针来代替真实长任务命令；当真实实验进程还活着时，只允许在出现有意义变化时发进度更新，并继续等待。没有新变化时，也只按保活节奏汇报，不要让用户触发下一次轮询。",
+  "不要用 `sleep 30`、单次 `pgrep` 或一次性的 `metrics.json` 探针来代替真实长任务命令；当真实实验进程还活着时，只允许在出现有意义变化时发进度更新，并继续等待。没有新变化时，也只按保活节奏汇报，不要让用户触发下一次轮询。\n\n" + zhAutoVisibleCloseoutLine
 );
 
 ZH_CONTENT[path.join(".claude", "commands", "lab.md")] = ZH_CONTENT[
@@ -2499,6 +2735,9 @@ ZH_CONTENT[path.join(".claude", "commands", "lab-auto.md")] = ZH_CONTENT[
 ].replace(
   "已批准的 `L2` 和 `L3` 执行 campaign 默认进入执行模式。",
   `${zhAutoPriorityClaudeLine}\n已批准的 \`L2\` 和 \`L3\` 执行 campaign 默认进入执行模式。`
+).replace(
+  "不要用 `sleep 30`、单次 `pgrep` 或一次性的 `metrics.json` 探针来代替真实长任务命令；当真实实验进程还活着时，只允许在出现有意义变化时发进度更新，并继续等待。没有新变化时，也只按保活节奏汇报，不要让用户触发下一次轮询。",
+  "不要用 `sleep 30`、单次 `pgrep` 或一次性的 `metrics.json` 探针来代替真实长任务命令；当真实实验进程还活着时，只允许在出现有意义变化时发进度更新，并继续等待。没有新变化时，也只按保活节奏汇报，不要让用户触发下一次轮询。\n\n" + zhAutoVisibleCloseoutLine
 );
 
 const zhRecipeQuickPathLine =
@@ -2530,6 +2769,12 @@ ZH_CONTENT[path.join(".claude", "commands", "lab.md")] = ZH_CONTENT[
   "- 用户只要显式调用某个 stage，无论写成 `/lab:<stage>`、`/lab: <stage>`、`/lab <stage>`、`/lab-<stage>` 还是 `/lab：<stage>`，都要立刻执行该 stage，而不是只推荐别的阶段。\n- 如果输入看起来像 stage 请求，但又不属于上述受支持写法，就必须停下并要求用户用精确的 stage 名重述，而不是自己猜。\n"
 );
 
+for (const rootPromptKey of [path.join(".codex", "prompts", "lab.md"), path.join(".claude", "commands", "lab.md")]) {
+  if (ZH_CONTENT[rootPromptKey] && !ZH_CONTENT[rootPromptKey].includes("最终可见收尾")) {
+    ZH_CONTENT[rootPromptKey] += `\n\n${zhAutoVisibleCloseoutLine}\n`;
+  }
+}
+
 ZH_CONTENT[path.join(".codex", "skills", "lab", "SKILL.md")] = `---
 name: lab
 description: 严格研究工作流，覆盖 idea、data、auto、framing、spec、run、iterate、review、report 和 paper-writing。
@@ -3174,11 +3419,38 @@ ZH_CONTENT[path.join(".codex", "skills", "lab", "stages", "auto.md")] = ZH_CONTE
   "- 只有当级别本身真的有歧义时，才停下来追问，例如 \\`第三层\\`、\\`phase 3\\`、\\`table 3\\`。",
   "- 只有当级别本身真的有歧义时，才停下来追问，例如 \\`第三层\\`、\\`phase 3\\`、\\`table 3\\`。\n- 如果用户显式调用 \\`/lab:auto\\` 或 \\`/lab-auto\\`，就保持在 auto 执行路径里；只要请求仍在已批准 execution envelope 内，即使目标听起来像 feature selection、baseline selection、离散化或 candidate sweep，也不要重新路由到 brainstorming 或 spec review。"
 );
+const zhAutoStageVisibleCloseout = `
+
+## 最终可见收尾
+
+- 最终可见收尾必须在 stage report 校验通过后给出，不能只写“已完成”“已推送”或命令流水账。
+- 最终可见收尾必须直接来自已校验的阶段报告，而不是另起一套临场叙述。
+- 最终可见收尾至少包含：请求交付物或目标及状态、核心说明表关键行、证据路径、验证命令和验证结果、已知缺口、下一步动作和为什么这样做。
+- 如果说“已完成”，也必须同时写明仍然存在的 handoff 边界，例如 PDF 编译、版面检查、外部审批、预算耗尽、冻结核心风险或环境缺失。
+`;
+if (!ZH_CONTENT[path.join(".codex", "skills", "lab", "stages", "auto.md")].includes("最终可见收尾")) {
+  ZH_CONTENT[path.join(".codex", "skills", "lab", "stages", "auto.md")] += zhAutoStageVisibleCloseout;
+}
 ZH_CONTENT[path.join(".claude", "skills", "lab", "stages", "auto.md")] =
   ZH_CONTENT[path.join(".codex", "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/claude/commands/lab.md

@@ -100,6 +100,7 @@ Treat all of these as equivalent stage requests:
 - While the loop is alive, `/lab auto` should keep `.lab/context/auto-ledger.md` updated with the active owner, observed state, and resume boundary.
 - Separate internal polling from user-facing progress reports.
 - While the loop is healthy, `/lab auto` should report to the user only on a meaningful change or at the keepalive cadence recorded in the current contract or runtime state, and it should not ask the user to trigger the next poll.
+- Final visible closeout must consume the validated stage report: show requested deliverable statuses, Core Explanation Table rows, evidence paths, validation/verification commands and results, known gaps, and the next action. Do not end with only "done", "pushed", or a chronological command log.
 
 - Treat `Autonomy level L1/L2/L3` as the execution privilege level, not as a paper layer, phase, or table number.
 - Treat `paper layer`, `phase`, and `table` as experiment targets. For example, `paper layer 3` or `Phase 1` should not be interpreted as `Autonomy level L3`.

package/package-assets/codex/prompts/lab/auto.md

@@ -27,3 +27,4 @@ If the preflight block cannot be completed because any required field is missing
 When the repository workflow language is Chinese, summaries, checklist items, task labels, and progress updates should be written in Chinese unless a literal identifier must stay unchanged.
 Treat `Layer 3`, `Phase 1`, or `Table 2` as paper-scope targets. Treat `Autonomy level L3` as the execution permission level.
 Do not replace the real long-running experiment command with a short watcher such as `sleep 30`, `pgrep`, or a one-shot `metrics.json` probe. While the real experiment process is still alive, emit only a progress update and keep waiting.
+Final visible closeout is mandatory when `/lab:auto` reaches stop, failure, escalation, or handoff. After validating the stage report, the final answer must consume that report directly: list the requested deliverables or objectives with status, summarize the Core Explanation Table rows, provide evidence paths, show validation/verification commands and validation results, name known gaps or commands that could not run, and state the next action plus why it is appropriate. Do not end with only `done`, `pushed`, `completed`, or a chronological command log.

package/package-assets/codex/prompts/lab-auto.md

@@ -27,3 +27,4 @@ If the preflight block cannot be completed because any required field is missing
 When the repository workflow language is Chinese, summaries, checklist items, task labels, and progress updates should be written in Chinese unless a literal identifier must stay unchanged.
 Treat `Layer 3`, `Phase 1`, or `Table 2` as paper-scope targets. Treat `Autonomy level L3` as the execution permission level.
 Do not replace the real long-running experiment command with a short watcher such as `sleep 30`, `pgrep`, or a one-shot `metrics.json` probe. While the real experiment process is still alive, emit only a progress update and keep waiting.
+Final visible closeout is mandatory when `/lab:auto` reaches stop, failure, escalation, or handoff. After validating the stage report, the final answer must consume that report directly: list the requested deliverables or objectives with status, summarize the Core Explanation Table rows, provide evidence paths, show validation/verification commands and validation results, name known gaps or commands that could not run, and state the next action plus why it is appropriate. Do not end with only `done`, `pushed`, `completed`, or a chronological command log.

package/package-assets/codex/prompts/lab.md

@@ -94,6 +94,7 @@ Treat all of these as equivalent stage requests:
 - While the loop is alive, `/lab:auto` should keep `.lab/context/auto-ledger.md` updated with the active owner, observed state, and resume boundary.
 - Separate internal polling from user-facing progress reports.
 - While the loop is healthy, `/lab:auto` should report to the user only on a meaningful change or at the keepalive cadence recorded in the current contract or runtime state, and it should not ask the user to trigger the next poll.
+- Final visible closeout must consume the validated stage report: show requested deliverable statuses, Core Explanation Table rows, evidence paths, validation/verification commands and results, known gaps, and the next action. Do not end with only "done", "pushed", or a chronological command log.
 
 - Treat `Autonomy level L1/L2/L3` as the execution privilege level, not as a paper layer, phase, or table number.
 - Treat `paper layer`, `phase`, and `table` as experiment targets. For example, `paper layer 3` or `Phase 1` should not be interpreted as `Autonomy level L3`.

package/package-assets/codex/prompts/lab:auto.md

@@ -27,3 +27,4 @@ If the preflight block cannot be completed because any required field is missing
 When the repository workflow language is Chinese, summaries, checklist items, task labels, and progress updates should be written in Chinese unless a literal identifier must stay unchanged.
 Treat `Layer 3`, `Phase 1`, or `Table 2` as paper-scope targets. Treat `Autonomy level L3` as the execution permission level.
 Do not replace the real long-running experiment command with a short watcher such as `sleep 30`, `pgrep`, or a one-shot `metrics.json` probe. While the real experiment process is still alive, emit only a progress update and keep waiting.
+Final visible closeout is mandatory when `/lab:auto` reaches stop, failure, escalation, or handoff. After validating the stage report, the final answer must consume that report directly: list the requested deliverables or objectives with status, summarize the Core Explanation Table rows, provide evidence paths, show validation/verification commands and validation results, name known gaps or commands that could not run, and state the next action plus why it is appropriate. Do not end with only `done`, `pushed`, `completed`, or a chronological command log.

package/package-assets/codex/prompts/lab/357/274/232auto.md

@@ -27,3 +27,4 @@ If the preflight block cannot be completed because any required field is missing
 When the repository workflow language is Chinese, summaries, checklist items, task labels, and progress updates should be written in Chinese unless a literal identifier must stay unchanged.
 Treat `Layer 3`, `Phase 1`, or `Table 2` as paper-scope targets. Treat `Autonomy level L3` as the execution permission level.
 Do not replace the real long-running experiment command with a short watcher such as `sleep 30`, `pgrep`, or a one-shot `metrics.json` probe. While the real experiment process is still alive, emit only a progress update and keep waiting.
+Final visible closeout is mandatory when `/lab:auto` reaches stop, failure, escalation, or handoff. After validating the stage report, the final answer must consume that report directly: list the requested deliverables or objectives with status, summarize the Core Explanation Table rows, provide evidence paths, show validation/verification commands and validation results, name known gaps or commands that could not run, and state the next action plus why it is appropriate. Do not end with only `done`, `pushed`, `completed`, or a chronological command log.

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/skills/lab/SKILL.md

@@ -49,10 +49,12 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - If the stage says improvement is needed, do not choose `stop` unless the next action states a concrete terminal boundary such as budget exhaustion, frozen-core risk, safety or integrity failure, impossible target, or a required approval boundary. Otherwise choose `continue`, `revise`, `rerun`, or `escalate`.
 - Stage reports are closeout and handoff artifacts, not a new user command and not a replacement for stage-specific artifacts such as idea memos, iteration reports, final reports, or write-iteration records.
 - Run `.lab/.managed/scripts/validate_stage_report.py --stage-report <stage-report> --stage <stage>` before claiming the stage is complete, and include the stage-report path plus validation result in the final user-facing summary.
+- For `/lab:auto`, the final user-facing answer must visibly consume the validated stage report: summarize requested deliverable statuses, Core Explanation Table rows, evidence paths, validation/verification commands and results, known gaps, and the next action. A chat-only chronological result list is not a valid closeout.
 - Final paper output should default to LaTeX, and its manuscript language should be decided separately from the workflow language.
 - 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 +222,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 +351,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.
@@ -220,3 +230,13 @@
 - Fill the `Core Explanation Table` in plain language: background, why now, what ran, how the loop ran, what worked, what did not work, what was verified, what remains unverified, what needs improvement and why, how to improve and why, key evidence, and the continue/stop/revise/rerun/escalate/handoff decision.
 - If the table says improvement is needed, the next action may be `stop` only when a terminal boundary is explicitly named; otherwise choose `continue`, `revise`, `rerun`, or `escalate`.
 - Run `.lab/.managed/scripts/validate_stage_report.py --stage-report <stage-report> --stage auto` and include the report path plus validation result in the final user-facing summary.
+- Final visible closeout is mandatory after validation. Do not end `/lab:auto` with only "done", "pushed", "completed", or a chronological command log.
+- The final visible closeout must be derived from the validated stage report, not from a separate improvised narrative.
+- The final visible closeout must include:
+  - the user's requested deliverables or objectives and their status: completed, repaired, failed-gate, not promoted, blocked, or handoff
+  - the key Core Explanation Table rows: what was done, how it was done, what worked, what did not work, what was verified, what remains unverified, whether improvement is needed and why, how to improve and why
+  - evidence paths and primary artifacts
+  - validation/verification commands and validation result, including commands that could not run
+  - known gaps or compile/runtime limitations
+  - next action and why that action is appropriate
+- If the final answer says the work is "completed", it must still name any remaining handoff boundary such as PDF compile, layout check, external approval, budget exhaustion, frozen-core risk, or missing environment.

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`.

package/package.json

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