superlab 0.1.0 → 0.1.1

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

@@ -0,0 +1,408 @@
+# Introduction Writing Guide
+
+## Goal
+
+Write a strong introduction in three steps:
+
+1. Think through the introduction logic.
+2. Apply a suitable template below.
+3. Revise the introduction repeatedly.
+
+## Introduction Logic Map
+
+```mermaid
+graph LR
+  L1[What task are we solving]
+  L2[Which metrics should this task improve]
+  L3[SOTA methods fail to meet target metrics]
+  L4[Root technical issue behind this failure]
+  L5[Our technical solution and method pipeline]
+  L6[Why the solution works]
+  L7[Additional technical contributions]
+
+  R1[Part 1 Task applications and target metrics]
+  R2[Part 2 SOTA methods failure and root issue]
+  R3[Part 3 Proposed solution and why it works]
+  R4[Part 4 Additional contributions and impact]
+  R5[Part 5 Experiments]
+
+  L1 --> L2
+  L2 --> L3
+  L3 --> L4
+  L4 --> L5
+  L5 --> L6
+  L6 --> L7
+
+  R1 --> R2
+  R2 --> R3
+  R3 --> R4
+  R4 --> R5
+
+  L1 --> R1
+  L2 --> R1
+  L3 --> R2
+  L4 --> R2
+  L5 --> R3
+  L6 --> R3
+  L7 --> R4
+```
+
+## How to Think About Introduction: Backward First, Then Forward
+
+### Backward reasoning (answer these first)
+
+1. What technical problem do we solve, and why is there no well-established solution? (important)
+2. What are the contributions of our pipeline (e.g., a new valuable task, a new valuable metric, a new technical problem, or a new technique)?
+3. What are the benefits of our contributions, why can they solve this technical challenge, and what new insight do they bring? (important)
+4. How do we use prior methods to lead readers to our solved challenge and our new insight?
+
+### Forward story (write in this order)
+
+1. Introduce the paper's task.
+2. Use prior methods to lead to the technical challenge we solve.
+3. Present xx contributions to solve this technical challenge.
+4. Explain technical advantages of our contributions and explicitly express our new insight. (important)
+
+## Section Skeleton
+
+```latex
+\section{Introduction}
+% Task and application
+% Technical challenge for previous methods (discuss around the technical challenge that we solved. A technical challenge includes both limitation and technical reason)
+% Introduce our pipeline for solving the challenge
+% Experiment
+% Contributions
+```
+
+## Part A: Introduce Task and Application
+
+### Version 1
+
+`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`
+
+Writing structure:
+
+1. Define the task in one clear sentence (`what output` from `what input`).
+2. Briefly explain the task objective or scope (optional).
+3. Introduce application value with 2-3 representative scenarios.
+
+Sentence skeleton:
+
+1. `[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].`
+2. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
+
+Local cite:
+
+1. `references/examples/introduction/version-1-task-then-application.md`
+
+### Version 2
+
+`Version 2: If the task is already familiar to most readers, introduce applications directly.`
+
+Writing structure:
+
+1. Skip formal task definition.
+2. Open with application importance in one concise sentence.
+3. Optionally append target requirement (e.g., accuracy/efficiency/robustness).
+
+Sentence skeleton:
+
+1. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
+
+Local cite:
+
+1. `references/examples/introduction/version-2-application-first.md`
+
+### Version 3
+
+`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`
+
+Writing structure:
+
+1. Start from the general task and why it matters.
+2. Narrow down to the specific setting of this paper.
+3. Clarify exact input/output and boundary of the setting.
+
+Sentence skeleton:
+
+1. `[general task] has a variety of applications such as [xxx], [xxx], and [xxx].`
+2. `This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].`
+
+Local cite:
+
+1. `references/examples/introduction/version-3-general-to-specific-setting.md`
+
+### Version 4
+
+`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods (failure cases / target metric improvements).`
+
+Writing structure:
+
+1. Start with task/application importance.
+2. Immediately summarize how representative previous methods work.
+3. Immediately expose the unresolved failure case + technical reason.
+4. Use this opening as a bridge to the later prior-work paragraphs.
+
+Opening-paragraph skeleton:
+
+1. `[Task/application importance sentence].`
+2. `Given input ..., previous methods usually ...`
+3. `Although they work in many cases, they fail at ... because ...`
+
+Expert note:
+
+1. It is often good if the first paragraph already states what problem you want to solve, instead of requiring several paragraphs of prior work before the challenge appears.
+2. This style needs the right conditions and is less common.
+3. Typical Version 4 flow: Part 1 (task + application and directly expose challenge via previous methods 1) -> Part 2 (previous methods 2 try to solve it but still fail) -> Part 3 (our method).
+4. More common general flow: Part 1 (task + application) -> Part 2 (previous methods 1 + limitation) -> Part 3 (previous methods 2 + limitation; here the target challenge emerges) -> Part 4 (our method).
+
+Local cite:
+
+1. `references/examples/introduction/version-4-open-with-challenge.md`
+
+## Part B: Introduce Technical Challenge for Previous Methods (Very Important)
+
+Purpose:
+
+1. Discuss around the exact technical challenge we solved.
+2. Build reader curiosity about how to solve this challenge.
+3. Make motivation/benefit of our method clear.
+
+Key logic before writing (faithful translation):
+
+1. First make clear the logic for "leading to the technical challenge we solved".
+2. For existing tasks: identify which recent methods have this challenge, why those methods exist, and optionally what earlier challenge they were trying to solve.
+3. For novel tasks: at minimum, define the technical challenge solved by our pipeline.
+
+Important warning :
+
+1. Do not first present a naive solution and then describe our improvement over it.
+2. That writing makes the work look like a low-score incremental patch.
+3. Even if the work is actually incremental, do not write it this way.
+4. Why: this writing style can erase reader curiosity and make the idea look straightforward only because the writing hand-holds the reader.
+
+### Technical-Challenge Version 1 (existing task, with existing methods)
+
+`Version 1: For existing tasks, discuss the challenge chain from general challenge -> traditional methods -> recent methods -> remaining challenge that we solve.`
+
+Writing structure:
+
+1. Start with a general challenge statement for this task.
+2. Briefly summarize traditional methods and their limitation.
+3. Briefly summarize recent methods (1) and their limitation with technical reason.
+4. Briefly summarize recent methods (2) and their limitation with technical reason.
+5. Ensure the final limitation is exactly the challenge your method solves.
+
+Sentence skeleton:
+
+1. `This problem is particularly challenging due to ...`
+2. `To overcome these challenges, traditional methods ... However, they ...`
+3. `Recently, ... methods ... However, they ... because ...`
+4. `To overcome this challenge, ... methods ... However, they ... because ...`
+
+Local cite:
+
+1. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
+
+### Technical-Challenge Version 2 (existing task + our insight seen in traditional methods)
+
+`Version 2: For existing tasks, when our insight has historical roots in traditional methods, use that line as conceptual backing and then show why new methods still fail.`
+
+Writing structure:
+
+1. Start from mainstream methods and state their limitation.
+2. Introduce a classical/traditional line that already contains insight similar to yours.
+3. Explain why that classical line is still insufficient.
+4. Return to modern methods and show the unresolved technical reason.
+5. Bridge to your method naturally.
+
+Sentence skeleton:
+
+1. `Traditional/recent methods ... However, they ... because ...`
+2. `To overcome this problem, a typical approach is [insight], which has long been explored ...`
+3. `However, these methods still ... because ...`
+4. `To overcome this challenge, newer methods ... However, they ... because ...`
+
+Local cite:
+
+1. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
+
+### Technical-Challenge Version 3 (novel task, no direct methods)
+
+`Version 3: For novel tasks without direct prior methods, define the challenge directly and decompose it into several concrete challenge points.`
+
+Writing structure:
+
+1. State the goal and explain that the problem is challenging for N reasons.
+2. Use `First/Second/Finally` to separate independent challenge points.
+3. For each point, state the observable limitation and the technical reason.
+4. End with a transition to your pipeline.
+
+Sentence skeleton:
+
+1. `In this work, our goal is to ... This problem is challenging for three reasons.`
+2. `First, ...`
+3. `Second, ...`
+4. `Finally, ...`
+
+Local cite:
+
+1. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
+
+## Part C: Introduce Our Pipeline for Solving the Challenge
+
+Key questions before writing:
+
+### For existing tasks
+
+1. What technical challenge does our pipeline solve?
+2. What is our technical contribution?
+3. Why can our method work in essence?
+4. What benefits does our method have over previous methods?
+
+### For novel tasks
+
+1. What technical challenge does our pipeline solve?
+2. What is our technical contribution?
+3. Why can our method work in essence?
+
+### Pipeline Version 1
+
+`Version 1: One contribution with multiple advantages, and one teaser figure to present the basic idea.`
+
+Writing structure:
+
+1. Introduce one core framework/representation for the target task.
+2. Point to teaser figure for the basic idea.
+3. State key novelty in one sentence.
+4. Explain concrete implementation steps (`Specifically, ...`).
+5. State multiple advantages (`In contrast ...`, `Another advantage ...`).
+
+Sentence skeleton:
+
+1. `In this paper, we propose a novel framework/representation, named ..., for ...`
+2. `The basic idea is illustrated in Figure ...`
+3. `Our innovation is in ...`
+4. `Specifically, ...`
+5. `In contrast to previous methods, ...`
+6. `Another advantage of the proposed method is that ...`
+
+Local cite:
+
+1. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
+
+### Pipeline Version 2
+
+`Version 2: Two contributions, and one teaser figure to present the basic idea.`
+
+Writing structure:
+
+1. Introduce framework and key novelty sentence.
+2. Point to teaser figure.
+3. Explain contribution 1 and its advantage.
+4. Introduce a remaining challenge.
+5. Explain contribution 2 as the response to that challenge.
+
+Sentence skeleton:
+
+1. `In this paper, we propose ...`
+2. `Our innovation is in ...`
+3. `The basic idea is illustrated in Figure ...`
+4. `Specifically, ...` (contribution 1)
+5. `In contrast to previous methods, ...`
+6. `However, ...` (remaining challenge)
+7. `Specifically, ...` (contribution 2)
+
+Local cite:
+
+1. `references/examples/introduction/pipeline-version-2-two-contributions.md`
+
+### Pipeline Version 3
+
+`Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`
+
+Writing structure:
+
+1. Start from prior pipeline setup.
+2. Introduce one new module as key innovation.
+3. Provide an observation that motivates the module design.
+4. Explain the module mechanism.
+5. Compare against generic alternatives and state why it is better.
+
+Sentence skeleton:
+
+1. `Inspired by previous methods, ...`
+2. `Our innovation is introducing ...`
+3. `We observe that ...`
+4. `Considering that ..., we introduce ...`
+5. `In contrast to ..., our module ...`
+
+Local cite:
+
+1. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
+
+### Pipeline Version 4
+
+`Version 4: Contribution comes from one important observation. Introduce key innovation first, then a listener-friendly observation as motivation, then method details, then benefits.`
+
+Writing structure:
+
+1. State key innovation first.
+2. State one intuitive observation as motivation.
+3. Explain implementation details.
+4. Explain technical advantage and empirical gain.
+
+Sentence skeleton:
+
+1. `Our innovation is ...`
+2. `We observe that ...`
+3. `Considering that ..., we ...`
+4. `This leads to ... and achieves ...`
+
+Local cite:
+
+1. `references/examples/introduction/pipeline-version-4-observation-driven.md`
+
+### Not Recommended Writing
+
+`Not recommended: If the method is simple, do not hide concrete method design in Introduction and only describe abstract insights to make the work look novel.`
+
+Expert note:
+
+1. In this template, the writing craft is about making a simple pipeline sound novel.
+2. The key caution: people often make the pipeline steps sound novel, not the real insight.
+3. In most cases this is not recommended. The better target is to clearly explain core contribution implementation in Introduction.
+
+Why not recommended (writing structure warning):
+
+1. Presenting only abstract insight without concrete pipeline steps weakens technical clarity.
+2. Introducing many new terms without mechanism-level explanation creates a novelty illusion.
+3. Reviewers may interpret this as shallow or incremental work.
+
+Local cite:
+
+1. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
+
+## Example Bank
+
+1. `references/examples/introduction-examples.md`
+2. `references/examples/introduction/version-1-task-then-application.md`
+3. `references/examples/introduction/version-2-application-first.md`
+4. `references/examples/introduction/version-3-general-to-specific-setting.md`
+5. `references/examples/introduction/version-4-open-with-challenge.md`
+6. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
+7. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
+8. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
+9. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
+10. `references/examples/introduction/pipeline-version-2-two-contributions.md`
+11. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
+12. `references/examples/introduction/pipeline-version-4-observation-driven.md`
+13. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
+
+## Quick Quality Checklist
+
+1. Does the first sentence of each paragraph state its message?
+2. Does each paragraph carry one message only?
+3. Are technical challenge, technical reason, and solved mechanism all explicit?
+4. Are claims in Introduction aligned with experiment evidence?
+5. Is terminology stable across all sections?

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

@@ -0,0 +1,196 @@
+# Method Writing Guide
+
+## Goal
+
+Write the Method section clearly by following this sequence:
+
+1. Answer key method-design questions.
+2. Draw a pipeline figure sketch.
+3. Write the method section step by step.
+
+## Pre-Writing Questions
+
+`Before writing Method, first answer: (1) what modules exist in the method, and (2) for each module, what is the workflow, why this module is needed, and why this module works.`
+
+Recommended organization:
+
+1. List all modules in the pipeline.
+2. For each module, answer three questions:
+
+- How does the module run?
+- Why do we need this module?
+- Why does this module work?
+
+3. Organize answers as a mind map or a table for clarity.
+
+## Method Writing Steps
+
+`Method writing steps: (1) draw pipeline figure sketch, (2) map subsections from the sketch, (3) plan each subsection with motivation/design/advantages, (4) write module design first, (5) then add motivation and technical advantages.`
+
+Step-by-step workflow:
+
+1. Draw the pipeline figure sketch.
+2. Use the sketch to organize Method subsection structure.
+3. For each subsection, plan three parts: motivation, module design, and technical advantages.
+4. Write module design first to build a concrete backbone.
+5. Add motivation and technical advantages afterward.
+
+## Three Elements of a Pipeline Module
+
+`A pipeline module has three elements: Module design, Motivation of this module, and Technical advantages of this module.`
+
+### 1) Module Design
+
+Definition:
+
+1. Describe representation/network/data-structure details.
+2. Describe the forward process clearly: given input -> step 1 -> step 2 -> step 3 -> output.
+
+### 2) Motivation of This Module
+
+Definition:
+
+1. Explain why this module is needed.
+2. Use problem-driven logic: because problem X exists, we design module Y.
+
+### 3) Technical Advantages of This Module
+
+Definition:
+
+1. Explain why this module has technical advantage over alternatives.
+2. Tie advantage to measurable behavior when possible.
+
+### Example of the Three Elements
+
+Local cite:
+
+1. `references/examples/method/example-of-the-three-elements.md`
+
+## Method Content Decomposition
+
+```mermaid
+flowchart LR
+    A["Draw the technical pipeline figure"] --> B["Decompose Method content"]
+    B --> C1["Subsection 1 (Technical Module 1)"]
+    B --> C2["Subsection 2 (Technical Module 2)"]
+    B --> C3["Subsection 3 (Technical Module 3)"]
+    C1 --> D1["Motivation"]
+    C1 --> D2["Detailed design"]
+    C1 --> D3["Technical advantage"]
+```
+
+## How to Write Module Design
+
+`Module design usually has two parts: (1) describe specific data/network structures, and (2) describe forward process as input -> steps -> output.`
+
+Writing structure:
+
+1. Define key structures first (representation, network, data structure).
+2. Write forward process in strict execution order.
+3. End with output interpretation or purpose.
+
+Sentence skeleton:
+
+1. `We represent ... with ...`
+2. `Given [input], we first ... then ... finally ...`
+3. `This produces [output], which is used for ...`
+
+Local cite:
+
+1. `references/examples/method/module-design-instant-ngp.md`
+
+## How to Write Module Motivation
+
+`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`
+
+Typical opening sentences:
+
+1. `A remaining problem/challenge is ...`
+2. `However, we ...`
+3. `Previous methods have difficulty in ...`
+
+Local cite:
+
+1. `references/examples/method/module-motivation-patterns.md`
+
+## How to Check Whether Method is Easy to Understand
+
+`Check method clarity from three levels: writing logic, paragraph writing, and sentence writing.`
+
+### 1) Logic-level check
+
+1. After finishing the paper, summarize the Method writing logic again.
+2. Check whether this summarized logic is smooth and easy to follow.
+
+### 2) Paragraph-level check
+
+1. The first sentence of each paragraph should make readers immediately understand what this paragraph is about.
+2. One paragraph should clearly deliver one message.
+
+### 3) Sentence-level check
+
+1. Carefully check whether the **motivation** of each sentence is explicit. Keep one thing clear to readers at all times: **why this sentence content is needed**.
+2. Carefully check sentence-to-sentence flow.
+3. Carefully check term consistency and avoid changing key terms back and forth.
+
+## Method Section Skeleton
+
+```latex
+\section{Method}
+% Overview
+% Section 3.1
+% Section 3.2
+% Section 3.3
+```
+
+Local cite:
+
+1. `references/examples/method/section-skeleton.md`
+
+## Overview Subsection
+
+`Overview should usually include: setting, core contribution, optional pipeline figure pointer, and a map of what each subsection contains.`
+
+Writing structure:
+
+1. One to two sentences for task setting.
+2. One to two sentences for core contribution.
+3. If pipeline/framework is novel, point to overview figure.
+4. Tell readers what Section 3.1/3.2/3.3 covers.
+
+Local cite:
+
+1. `references/examples/method/overview-template.md`
+
+## Section 3.1 and Other Module Subsections
+
+`Basic subsection logic: (1) motivation of this module, (2) module forward process/module design, (3) technical advantages of this module.`
+
+Local cite:
+
+1. `references/examples/method/example-of-the-three-elements.md`
+
+## Module Writing Pattern (Mermaid)
+
+```mermaid
+flowchart TB
+    M1["State module motivation (challenge)"] --> M2["Define module design (representation/network)"]
+    M2 --> M3["Describe forward process (input -> steps -> output)"]
+    M3 --> M4["Explain technical advantages and verifiable gains"]
+```
+
+## Implementation Details
+
+`Implementation details include hyperparameters (e.g., layer count, feature dimensions), coordinate transforms/normalization, and other practical details. Put them near the end of Method or in a dedicated Implementation Details section.`
+
+## Example Bank
+
+1. `references/examples/method-examples.md`
+2. `references/examples/method/pre-writing-questions.md`
+3. `references/examples/method/module-triad-neural-body.md`
+4. `references/examples/method/module-design-instant-ngp.md`
+5. `references/examples/method/module-motivation-patterns.md`
+6. `references/examples/method/section-skeleton.md`
+7. `references/examples/method/overview-template.md`
+8. `references/examples/method/example-of-the-three-elements.md`
+9. `references/examples/method/method-writing-common-issues-note.md`

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

@@ -0,0 +1,86 @@
+# Paper Review (Paper Rview)
+
+## Goal
+
+Use an adversarial, reviewer-style checklist to detect reject risks early and revise the paper before submission.
+
+## Core Principle
+
+Pursue perfectionism in paper quality: assume reviewers will probe every weak point and proactively fix them.
+
+## Critical Rule (Do Not Violate)
+
+Every major claim, especially in Abstract and Introduction, must be:
+
+1. technically correct, and
+2. explicitly supported by experimental evidence.
+
+If a claim is not supported, either add evidence or weaken/remove the claim.
+
+## What Usually Gets a Paper Accepted
+
+1. Sufficient contribution (for example: novel task, novel pipeline, novel module, novel design choices, new experimental findings, or new insight).
+2. Better empirical performance than prior methods under fair comparisons.
+3. Sufficient comparison experiments and ablation studies.
+
+## Common Rejection Dimensions
+
+| Rejection Dimension          | Typical Failure Signals                                                                                                                                                                                                                                                                    |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1. Insufficient contribution | 1.1 Targeted failure cases are too common.<br /> 1.2 Proposed technique is already well explored; expected gains are predictable/well-known.                                                                                                                                               |
+| 2. Unclear writing           | 2.1 Missing technical details; work is not reproducible.<br />2.2 A method module lacks clear motivation.                                                                                                                                                                                  |
+| 3. Weak empirical effect     | 3.1 Improvement over prior methods is only marginal.<br /> 3.2 Even if better than previous methods, absolute performance is still not strong enough.                                                                                                                                      |
+| 4. Incomplete evaluation     | 4.1 Missing ablation studies.<br />4.2 Missing important baselines or important evaluation metrics.<br /> 4.3 Datasets are too simple to prove the method truly works.                                                                                                                    |
+| 5. Problematic method design | 5.1 Experimental setting is unrealistic.<br />5.2 Method has technical flaws and appears unreasonable.<br />5.3 Method is not robust and needs per-scenario hyperparameter tuning. <br /> 5.4 New design introduces stronger limitations than its benefits, leading to negative net value. |
+
+## End-of-Paper Self-Review Question List
+
+Add this checklist near the end of the draft while revising.
+Use each question to trigger concrete edits before submission.
+
+### 1. Contribution
+
+1. What new knowledge does this paper give to readers?
+2. Are we solving a truly meaningful failure case, not a trivial/common one?
+3. Is the technical idea genuinely non-obvious beyond well-explored practice?
+4. Is our gain surprising or insightful rather than a predictable improvement?
+5. Is there at least one clear novelty type (task/pipeline/module/design finding/insight)?
+
+### 2. Writing Clarity
+
+1. Can a knowledgeable reader reproduce the method from the paper?
+2. Did we provide enough technical detail for each key module?
+3. Is the motivation of every module explicit and logically connected to a challenge?
+4. Are terms and notation consistent across sections?
+5. Does each paragraph carry one clear message with smooth transitions?
+
+### 3. Experimental Strength
+
+1. Are improvements over strong baselines meaningful, not just statistically tiny?
+2. Is absolute performance competitive enough for the target venue?
+3. Are gains consistent across multiple datasets/settings/metrics?
+4. Do we report both strengths and failure cases honestly?
+
+### 4. Evaluation Completeness
+
+1. Do we include ablations for all key design choices?
+2. Are all strong/recent baselines included under fair settings?
+3. Are evaluation metrics standard and sufficient for this task?
+4. Are datasets/scenarios challenging enough to validate real effectiveness?
+5. Are comparison and ablation protocols clearly documented?
+
+### 5. Method Design Soundness
+
+1. Is the experimental setting realistic for practical use?
+2. Does the method have hidden technical defects or unreasonable assumptions?
+3. Is the method robust without heavy per-case hyperparameter retuning?
+4. Do benefits outweigh added complexity and new limitations?
+5. Could reviewers reasonably argue that the net benefit is negative?
+
+## Adversarial Writing Workflow
+
+1. Read the paper as a skeptical reviewer.
+2. Answer every question above with explicit evidence from the paper.
+3. Mark each item as `pass`, `needs revision`, or `needs new experiment`.
+4. Revise claims, writing, experiments, or method scope accordingly.
+5. Repeat until no major rejection risk remains.