superlab 0.1.78 → 0.1.80

package/package-assets/shared/lab/.managed/scripts/validate_section_draft.py

@@ -43,6 +43,11 @@ def contains_any(text: str, needles: tuple[str, ...]) -> bool:
     return any(needle.lower() in lowered for needle in needles)
 
 
+def count_phrase_hits(text: str, needles: tuple[str, ...]) -> int:
+    lowered = text.lower()
+    return sum(lowered.count(needle.lower()) for needle in needles)
+
+
 def strip_latex_commands(text: str) -> str:
     text = re.sub(r"%.*", " ", text)
     text = re.sub(r"\\[A-Za-z@*]+(?:\[[^\]]*\])?", " ", text)
@@ -229,6 +234,51 @@ WORKFLOW_ONLY_MANUSCRIPT_PHRASES = (
     "工作流语言",
     "同步到",
 )
+OVER_DEFENSIVE_BOUNDARY_PHRASES = (
+    "not intended as",
+    "not intended to be",
+    "not meant as",
+    "not meant to be",
+    "not a general",
+    "not a deployable",
+    "not a production",
+    "should not be viewed as",
+    "should not be read as",
+    "only to show",
+    "only to illustrate",
+    "only to demonstrate",
+    "only used to show",
+    "serves only to show",
+    "仅用于说明",
+    "仅用于展示",
+    "仅用于证明",
+    "只是为了说明",
+    "不应被视为",
+    "不应视为",
+    "不是通用",
+    "不是可部署",
+    "不是真实场景",
+    "不作为",
+)
+RESULT_LOG_SIGNAL_PHRASES = (
+    "auuc",
+    "qini",
+    "auc",
+    "accuracy",
+    "f1",
+    "score",
+    "scores",
+    "point gain",
+    "point gains",
+    "points",
+    "baseline",
+    "baselines",
+    "提升",
+    "百分点",
+    "得分",
+    "分差",
+    "基线",
+)
 INTERNAL_EXPERIMENT_PROVENANCE_PHRASES = (
     "tuning run",
     "tuning runs",
@@ -351,6 +401,14 @@ def has_diagnostic_interpretation(text: str) -> bool:
     )
 
 
+def has_result_log_numeric_dump(text: str, min_numbers: int = 8, min_signal_hits: int = 2) -> bool:
+    prose_text = strip_latex_commands(text)
+    numbers = re.findall(r"\b\d+(?:\.\d+)?%?\b", prose_text)
+    if len(numbers) < min_numbers:
+        return False
+    return count_phrase_hits(prose_text, RESULT_LOG_SIGNAL_PHRASES) >= min_signal_hits
+
+
 def check_common_section_gate_risks(text: str, issues: list[str]):
     prose_text = strip_latex_commands(text)
     if ISOLATED_INSIGHT_HEADING_PATTERN.search(text):
@@ -435,6 +493,36 @@ def check_common_section_gate_risks(text: str, issues: list[str]):
         )
 
 
+def check_boundary_and_density_risks(section: str, text: str, issues: list[str]):
+    prose_text = strip_latex_commands(text)
+    boundary_hits = count_phrase_hits(prose_text, OVER_DEFENSIVE_BOUNDARY_PHRASES)
+    if section == "abstract" and boundary_hits >= 2:
+        issues.append(
+            "abstract section contains over-defensive boundary dumping; keep at most one brief boundary sentence and spend the abstract on problem, gap, method, and result"
+        )
+    elif section == "introduction" and boundary_hits >= 2:
+        issues.append(
+            "introduction section contains over-defensive boundary dumping; state the gap and mechanism first, then keep only one brief boundary if it is needed"
+        )
+    elif section == "method" and boundary_hits >= 2:
+        issues.append(
+            "method section contains over-defensive boundary dumping; explain what the method does and move repeated scaffold-defense language to one brief boundary sentence or the limitations section"
+        )
+    elif section == "experiments" and boundary_hits >= 2:
+        issues.append(
+            "experiments section contains over-defensive boundary dumping; report the attack or evaluation outcome directly and keep only the minimum boundary needed to scope the evidence"
+        )
+
+    if section == "introduction" and has_result_log_numeric_dump(text):
+        issues.append(
+            "introduction section contains result-log style numeric dumping; keep only the one or two numbers needed to motivate the contribution and move dense benchmark values to experiments"
+        )
+    elif section == "method" and has_result_log_numeric_dump(text, min_numbers=6, min_signal_hits=2):
+        issues.append(
+            "method section contains result-log style numeric dumping; keep method on mechanism and move dense numeric comparisons to experiments"
+        )
+
+
 def check_section_style_policy(text: str, section: str, issues: list[str]):
     prose_text = strip_latex_commands(text)
     for message, needles in SECTION_STYLE_WARNINGS.get(section, []):
@@ -484,6 +572,11 @@ def check_neighbor_asset_files(section: str, section_path: Path, issues: list[st
             issues.append(
                 f"{asset_path.as_posix()} contains workflow-only placeholder language; move authoring notes out of captions and paper-facing asset text"
             )
+        boundary_hits = count_phrase_hits(asset_text, OVER_DEFENSIVE_BOUNDARY_PHRASES)
+        if boundary_hits >= 2:
+            issues.append(
+                f"{asset_path.as_posix()} contains over-defensive boundary dumping in a paper-facing asset; keep captions and local notes focused on what the figure or table shows"
+            )
 
 
 def check_paper_topology_targeting(section_path: Path, issues: list[str]):
@@ -774,6 +867,7 @@ def main():
     check_paper_topology_targeting(section_path, blocking_issues)
     check_workflow_language_targeting(section_path, blocking_issues)
     check_common_section_gate_risks(text, warning_issues)
+    check_boundary_and_density_risks(args.section, text, warning_issues)
     check_section_style_policy(text, args.section, warning_issues)
     SECTION_CHECKS[args.section](text, warning_issues)
     check_neighbor_asset_files(args.section, section_path, warning_issues)

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

@@ -22,9 +22,15 @@
 
 ## External Rebuttal Intake
 
-| Source | Raw criticism summary | Affected unit | Reviewer axis | Severity | Route | Acceptance check |
-| --- | --- | --- | --- | --- | --- | --- |
-|  |  |  |  |  |  |  |
+| Source | Raw criticism summary | Affected unit | Reviewer axis | Severity | Why it matters | Route | Acceptance check |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |  |
+
+## Revision Traceability
+
+| Author claim or revised statement | Claimed artifact location | Independently verified | Remaining gap |
+| --- | --- | --- | --- |
+|  |  |  |  |
 
 ## Reviewer Panel Findings
 
@@ -70,9 +76,15 @@
 
 ## Actionable Issue Register
 
-| ID | Axis | Severity | Affected artifact | Finding | Required fix | Route | Acceptance check | Core mutation required |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-|  |  |  |  |  |  |  |  |  |
+| ID | Axis | Severity | Affected artifact | Finding | Why it matters | Required fix | Route | Acceptance check | Core mutation required |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+|  |  |  |  |  |  |  |  |  |  |
+
+## Consensus / Disagreement / Resolution
+
+- Consensus:
+- Disagreement:
+- Resolution:
 
 ## Core Mutation Check
 

package/package-assets/shared/skills/lab/references/paper-writing/argument-stress-test.md

@@ -0,0 +1,34 @@
+# Argument Stress Test
+
+Run this after the logic pass and before language polish. The goal is to break weak argument chains early.
+
+## Required Checks
+
+1. **Weakest-link test**  
+   Which paragraph carries the most unsupported inference? Rewrite or narrow it first.
+
+2. **Reverse-claim test**  
+   If the main claim were false, which sentence in this section would fail first? That sentence usually reveals the overclaim.
+
+3. **Alternative-explanation test**  
+   What simpler explanation could produce the same pattern? State it explicitly and check whether the section already weakens it.
+
+4. **Boundary test**  
+   What does the current evidence still not justify? Add that limit before polishing.
+
+5. **Evidence-trace test**  
+   Can every major claim be traced to a figure, table, protocol statement, citation, or definition already present?
+
+## Section-Specific Triggers
+
+- **Introduction**: would the paper still look necessary if the claimed challenge were softened?
+- **Method**: could a reviewer say the module is an arbitrary stack choice?
+- **Experiments**: does the prose explain what the result teaches, not only what number is larger?
+- **Conclusion**: does any sentence exceed what the experiments actually support?
+
+## Repair Moves
+
+1. Replace vague claims with a narrower mechanism claim.
+2. Add one explicit bridge sentence from evidence to interpretation.
+3. Move unsupported motivation out of results and back into hypothesis language.
+4. State the remaining alternative explanation if it is not fully ruled out.

package/package-assets/shared/skills/lab/references/paper-writing/section-question-bank.md

@@ -0,0 +1,59 @@
+# Section Question Bank
+
+Use this file before drafting or revising a paper section. The goal is to force one pass on section purpose before wording.
+
+## Global Questions
+
+1. What single job must this section do for the paper?
+2. What must the reader understand after this section that they did not understand before?
+3. Which claim, protocol, metric, or boundary does this section depend on?
+4. Which paragraph is most likely to confuse a skeptical reviewer?
+5. Which sentence would become false if one supporting result disappeared?
+
+## Abstract
+
+1. Is the task clear in one pass?
+2. Is the gap tied to prior work rather than hype?
+3. Is the mechanism-level insight visible?
+4. Is the main result bounded by scope?
+5. Is the main boundary stated?
+
+## Introduction
+
+1. What common assumption or prior explanation is being challenged?
+2. What failure, anomaly, or unmet need forces the paper to exist?
+3. What is the core insight anchor?
+4. Why does the proposed direction follow from that insight?
+5. Which contribution is truly central, and which are supporting?
+
+## Related Work
+
+1. What are the 2-4 actual research clusters readers need?
+2. Which paper is the closest prior work?
+3. What exact capability remains unresolved in each cluster?
+4. Does each cluster end with a gap statement?
+5. Did any paragraph become a citation list instead of a comparison?
+
+## Method
+
+1. Which design choice would a reviewer call arbitrary?
+2. What problem forces each module, loss, or representation?
+3. Is the information flow described in executable order?
+4. What technical effect is expected from each major design?
+5. Which term or label still lacks a first-mention explanation?
+
+## Experiments
+
+1. Are dataset scope, split protocol, and baseline setup separately visible?
+2. Is each metric defined once in reader-facing language?
+3. Which table answers the main effectiveness question?
+4. Which ablation rules out the strongest simpler explanation?
+5. What boundary or failure mode remains after the main result?
+
+## Conclusion
+
+1. What is the strongest supported takeaway?
+2. What broader principle follows from that takeaway?
+3. What boundary prevents overclaiming?
+4. What next step follows from the boundary instead of from habit?
+5. Did the section introduce any new evidence or claim?

package/package-assets/shared/skills/lab/references/paper-writing/section-style-policies.md

@@ -26,11 +26,14 @@ These are paper-facing defaults. They are not project-specific branding rules.
 - Long setup of benchmark details.
 - Contribution lists that read like the introduction.
 - Excessive future-work framing.
+- More than one defensive boundary sentence.
+- Internal scaffold names before the reader-facing concept is clear.
 
 **Banned expressions / moves**
 - Roadmap prose such as "In this paper, we first..., then..., finally...".
 - Reviewer-facing instructions such as "the reader can see" or "as shown clearly below".
 - Unbounded superiority claims such as "universally", "always", or "in every setting".
+- Over-defensive boundary dumping that keeps explaining what the paper is not instead of what it shows.
 - Service-style or AI-assistant meta language such as "用户说", "按你的要求", "我来解释", "let me explain", or "as requested by the user".
 - Workflow-only placeholder language such as "图的意图", "资产意图", "占位符", "workflow-language", or "sync this wording".
 - Standalone insight headings such as "Our Insights" when the insight is not woven into the abstract's challenge and contribution arc.
@@ -51,12 +54,15 @@ These are paper-facing defaults. They are not project-specific branding rules.
 - Repeating "important" or "significant" without a concrete consequence.
 - Opening with generic field hype.
 - Listing contributions before the gap is clear.
+- Result-log introductions that dump many benchmark values before the gap is clear.
+- Repeating the same boundary defense that will already appear in Method, Experiments, or Limitations.
 
 **Banned expressions / moves**
 - Empty macro-importance claims such as "this problem is increasingly critical" with no concrete consequence.
 - Marketing-style first-claim language such as "revolutionary", "game-changing", or "unprecedented" without evidence.
 - Paragraphs that only praise the paper instead of stating the research gap.
 - Standalone "Our Insights" sections; the insight should be part of the motivation and gap logic.
+- Over-defensive boundary dumping that explains what the system is not before the reader understands the problem, gap, and contribution.
 - Service-style or AI-assistant meta language such as "用户说", "按你的要求", "我来解释", "let me explain", or "as requested by the user".
 - Workflow-only placeholder language such as "图的意图", "资产意图", "占位符", "workflow-language", or "sync this wording".
 
@@ -98,12 +104,15 @@ These are paper-facing defaults. They are not project-specific branding rules.
 - Long implementation detail lists that belong in appendix or setup.
 - Repeating model names without explaining their role.
 - Overusing novelty language instead of mechanism explanation.
+- Defensive paragraphs that keep explaining what the method is not instead of what mechanism it implements.
+- Dense result numbers that belong in Experiments rather than Method.
 
 **Banned expressions / moves**
 - Marketing-style or self-promotional wording such as "elegant", "powerful", "dramatically stronger", or "significantly outperforms prior methods" when used as prose decoration rather than evidence-backed result reporting.
 - Explaining the method by saying it is "better", "stronger", or "more advanced" without saying how it works.
 - Method subsections that read like API documentation without explaining which mechanism or insight requires the design.
 - Introducing new narrative aliases for canonical model or ablation labels after they have already been locked.
+- Over-defensive boundary dumping that keeps justifying what the method is not or where it is not deployable instead of explaining how the mechanism works.
 - Service-style or AI-assistant meta language such as "用户说", "按你的要求", "我来解释", "let me explain", or "as requested by the user".
 - Workflow-only placeholder language such as "图的意图", "资产意图", "占位符", "workflow-language", or "sync this wording".
 
@@ -124,6 +133,8 @@ These are paper-facing defaults. They are not project-specific branding rules.
 - Re-explaining the same metric in every paragraph.
 - Paragraphs that only restate the table without synthesis.
 - Result paragraphs that say only "higher/lower/better" without explaining what the pattern teaches.
+- Repeating the same boundary defense after every table or figure.
+- Captions or table notes that carry more defense than result interpretation.
 
 **Banned expressions / moves**
 - Meta-reader guidance such as "这样读者可以……", "the reader can first...", or "this table lets the reader...".
@@ -131,6 +142,7 @@ These are paper-facing defaults. They are not project-specific branding rules.
 - Layout-process commentary in scientific prose, such as "由于表列较多，这里采用页宽自适应排版" or "we use page-width adaptive layout here".
 - Claims that a table "proves" something when the evidence only supports a bounded empirical result.
 - Internal experiment-planning prose, such as "还需要新增 holdout", "小批量门控", "冻结 payload", "不能边跑边调", "API 规模估计", or "if all scores are 1.0000, treat it as overfitting".
+- Over-defensive boundary dumping that spends more sentences disclaiming the setup than reporting what was attacked, measured, recovered, or bounded.
 - Service-style or AI-assistant meta language such as "用户说", "按你的要求", "我来解释", "let me explain", or "as requested by the user".
 - Workflow-only placeholder language such as "图的意图", "资产意图", "占位符", "workflow-language", or "sync this wording".
 

package/package-assets/shared/skills/lab/references/paper-writing/writing-anti-patterns.md

@@ -0,0 +1,33 @@
+# Writing Anti-Patterns
+
+Run this only after logic and theory blockers are cleared. The goal is to remove common low-quality prose habits without inventing new content.
+
+## Common Anti-Patterns
+
+1. **Throat-clearing openings**  
+   Paragraphs that spend one or two sentences warming up before making the point. Move the point to the first sentence.
+
+2. **Uniform paragraph length**  
+   Every paragraph having the same size often signals template writing rather than argument structure. Split or merge by idea, not by rhythm.
+
+3. **Synonym cycling**  
+   Switching among multiple names for the same concept creates false variety and weakens terminology control. Keep one canonical paper-facing name.
+
+4. **Generic evaluative vocabulary**  
+   Words such as `important`, `significant`, `effective`, `clear`, or `promising` without concrete content. Replace with the specific consequence, metric, or boundary.
+
+5. **List-shaped filler**  
+   Sentences that pile up three or more loosely related claims to sound complete. Split them into one claim per sentence when the logic differs.
+
+6. **Overconnected transitions**  
+   Repeated `therefore`, `moreover`, `furthermore`, or similar connectors can hide weak logic. Keep the connective only when the relation is explicit.
+
+7. **Meta-writer commentary**  
+   Phrases about what the paper is doing rather than the research itself, unless the sentence is a legitimate roadmap or scope statement.
+
+## Quick Repair Questions
+
+1. Can the first sentence of each paragraph state the paragraph's job directly?
+2. Did any concept get renamed just to avoid repetition?
+3. Can a vague adjective be replaced by a metric, mechanism, or constraint?
+4. Did any sentence become longer because two different ideas were forced together?

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

@@ -56,11 +56,23 @@ For each external comment, record:
 - affected paper unit: claim, section, table, figure, protocol, metric, threat model, experiment, or wording
 - reviewer axis: R1, R2, R3, R4, or R5
 - severity: fatal, major, minor, or clarification
+- why it matters: what acceptance risk or scientific risk it creates
 - 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.
 
+## Revision Traceability
+
+When the paper already contains a claimed repair, rebuttal response, or revised section, record:
+
+- author claim: what the current draft or response says was fixed
+- claimed artifact location: where the claimed fix lives
+- independently verified: yes / no / partial
+- remaining gap: what still fails the acceptance check
+
+Do not mark an issue resolved only because the manuscript says it was resolved. The pass must independently verify the fix or keep the remaining gap open.
+
 ## Reviewer Panel
 
 Run five independent review lenses. Each lens must produce actionable issues, not vague advice.
@@ -112,6 +124,16 @@ Every issue must include:
 
 Prioritize fatal and major issues before language polish. Minor presentation fixes may be batched.
 
+## Consensus / Disagreement / Resolution
+
+At the end of the panel, summarize:
+
+- consensus: what multiple review lenses agree is the main blocking problem
+- disagreement: what remains contested across lenses or between criticism and evidence
+- resolution: what concrete route, evidence, or rewrite will settle the disagreement
+
+Use this summary to keep rebuttal mode actionable instead of devolving into parallel opinions.
+
 ## Core Mutation Policy
 
 Core mutation means changing any of:

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

@@ -5,9 +5,11 @@
 1. Give a concise summary of the artifact or result under review.
 2. State the top review question or risk focus.
 3. Audit in reviewer mode.
-4. Output fatal flaws first when present.
-5. Rank the fix priority.
-6. End with residual risks and a clear next action.
+4. Convert findings into structured issues: problem, why it matters, required fix, severity, route, and acceptance check.
+5. When the target already has claimed fixes or rebuttal responses, add revision traceability: author claim, claimed artifact location, independently verified or not, and remaining gap.
+6. Output fatal flaws first when present.
+7. Rank the fix priority.
+8. End with consensus, disagreement, resolution, residual risks, and a clear next action.
 
 ## Context Read Set
 
@@ -48,7 +50,8 @@
 - For quick prompts such as "rebuttal一下看有什么缺点", start with the rebuttal Light Read Set only: active LaTeX, result summaries, managed indices, and supplied criticism. Do not run a whole-repository scan unless the panel records a specific escalation reason.
 - 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, R4 Results / Tables / Numeric Evidence, and R5 Presentation / Clarity.
-- Each issue must include severity, affected artifact, required fix, route, acceptance check, and whether core mutation is required.
+- Each issue must include problem, why it matters, severity, affected artifact, required fix, route, acceptance check, and whether core mutation is required.
+- For re-review or rebuttal-repair passes, record author claim, claimed location, independently verified status, and remaining gap before marking an issue resolved.
 - 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
@@ -57,6 +60,7 @@
 - findings first
 - fatal flaws called out explicitly
 - fix priority stated clearly
+- consensus / disagreement / resolution stated clearly
 - evidence-linked critique
 - explicit residual risks
 - explicit alternative explanations and boundary risks

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

@@ -70,6 +70,9 @@ Run these on every round:
 - section flow check -> `skills/lab/references/paper-writing/does-my-writing-flow-source.md`
 - 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)
+- section question bank -> `skills/lab/references/paper-writing/section-question-bank.md`
+- argument stress test -> `skills/lab/references/paper-writing/argument-stress-test.md`
+- language anti-pattern sweep -> `skills/lab/references/paper-writing/writing-anti-patterns.md`
 
 ## Rebuttal Mode
 
@@ -151,6 +154,7 @@ Do not enter prose polish until the current section has passed the reference-con
 - Build a compact mini-outline before prose.
 - When reference-guided deep-write is triggered, build the reference consumption plan before the mini-outline so the outline is based on mapped section slots rather than generic prose flow.
 - Academic readability standards are the same in `workflow_language` and `paper_language`; changing languages must not lower external-reader clarity.
+- Prefer concept first, implementation label second. If an internal scaffold, expert, oracle, parser, or module nickname is not central to the reader's understanding, state the reader-facing concept first and introduce the implementation label only if later reuse justifies it.
 - If the current round introduces or revises key terms, abbreviations, metric names, mechanism names, or system labels, explain them at first mention by briefly stating what they are and why they matter here.
 - First mention should use the full form. If a short form or acronym will be reused later, define it at first mention as `Full Form (Short Form)` before switching to the short form.
 - Apply the same first-mention rule to table headers, table captions, table notes, and figure captions or labels; if a term or abbreviation first appears in a table, expand it locally in that table.
@@ -166,10 +170,12 @@ 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.
+- Keep boundary statements sparse. One brief boundary sentence in Abstract, one brief scope sentence in Experiments, and one fuller limitation in Conclusion is the default pattern; do not repeat the same defense across sections unless the evidence scope genuinely changes.
+- If a paragraph outside Experiments reads like a result log, cut it back to the one or two numbers needed for motivation and move the dense benchmark values to Experiments or tables.
 - 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.
+  - Logic pass: check the paragraph role, claim chain, premise-to-conclusion transition, evidence dependency, and whether the section naturally follows from adjacent sections. Use `section-question-bank.md` to force explicit answers about section purpose. 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. Run `argument-stress-test.md` here, including the weakest-link test, reverse-claim test, and strongest alternative explanation check. 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. Run `writing-anti-patterns.md` here and remove throat-clearing openings, uniform paragraph patterns, synonym cycling, and generic evaluative filler before accepting the pass.
 - 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.
@@ -195,6 +201,7 @@ Do not enter prose polish until the current section has passed the reference-con
 - Keep run provenance such as tuning-run labels, probe names, internal config strings, rerun ids, and package labels out of reader-facing prose. If the evidence is useful, rewrite it as a bounded paper-facing diagnostic or move the raw provenance to workflow notes or appendix metadata.
 - Keep internal experiment planning out of reader-facing prose. Do not write paper sentences that explain future holdout expansion, small-batch gates, payload freezing, API budget, "if all scores are 1.0000 then treat as overfitting", or why a next automation round is needed.
 - When an experiment boundary matters, report only the scientific scope already supported by the evidence. Put the operational plan for collecting new attacks, new papers, new markers, or additional holdout cases into `.lab/changes/`, `.lab/iterations/`, or report artifacts, not into manuscript sections.
+- Do not let Method or Experiments be dominated by negative-definition prose such as what the system is not, what it is not meant to replace, or where it is not deployable. After one clear scope sentence, return to mechanism or evidence.
 - Do not use unexplained terminology density as a substitute for academic tone.
 - Keep service-style or AI-assistant meta language out of manuscript prose. Phrases such as "用户说", "按你的要求", "我来解释", "下面我", "this version", or "as requested by the user" belong in workflow notes, not in paper-facing sections, captions, table notes, or analysis assets.
 - Keep workflow-only placeholder language out of manuscript prose. Phrases such as "图的意图", "资产意图", "占位符", "workflow-language", "translation layer", or "sync this wording" belong in authoring artifacts, not in reader-facing LaTeX.
@@ -254,6 +261,7 @@ Do not enter prose polish until the current section has passed the reference-con
 - Table assets must use paper-facing LaTeX structure with `booktabs`, caption, label, and consistent precision.
 - Table assets must also include a local table note that explains row meaning, column meaning, metric definitions, comparison scope, and any important caveat.
 - The local table note must contain real reader-facing explanations, not the default template phrases such as "explain what each row represents" or "expand local abbreviations".
+- Captions and table notes should explain what the asset shows, not defend the workflow. Do not use captions to carry repeated boundary disclaimers that belong in section prose or Limitations.
 - Table assets must not rely on aggressive width hacks by default; if width control is still needed after table redesign, document it locally and keep it readable.
 - Table assets with seven or more columns should be split, moved partly to appendix, or written with width-aware columns such as `tabularx` or `p{...}` instead of a plain `tabular` layout.
 - Figure placeholders may record what the final figure should show and why the reader needs it in authoring comments, the paper plan, or the write-iteration artifact, but the caption itself must remain paper-facing and must not contain "Figure intent", "图的意图", "asset intent", "占位符", or similar workflow language.

package/package.json

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