superlab 0.1.78 → 0.1.79

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/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
 
@@ -167,9 +170,9 @@ Do not enter prose polish until the current section has passed the reference-con
 - 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.
+  - 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.

package/package.json

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