superlab 0.1.72 → 0.1.73

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:
@@ -2259,6 +2283,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）。

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/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/write.md

@@ -156,6 +156,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.73",
   "description": "Strict /lab research workflow installer for Codex and Claude",
   "keywords": [
     "codex",