superlab 0.1.26 → 0.1.28

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

@@ -12,7 +12,7 @@ locally organized cite targets.
 5. Introduction technical-challenge files: `references/examples/introduction/technical-challenge-version-1-existing-task.md`, `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`, `references/examples/introduction/technical-challenge-version-3-novel-task.md`, `references/examples/introduction/novel-task-challenge-decomposition.md`
 6. Introduction pipeline files: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`, `references/examples/introduction/pipeline-version-2-two-contributions.md`, `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`, `references/examples/introduction/pipeline-version-4-observation-driven.md`, `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
 7. Method examples index: `references/examples/method-examples.md`
-8. Method detail files: `references/examples/method/pre-writing-questions.md`, `references/examples/method/module-triad-neural-body.md`, `references/examples/method/neural-body-annotated-figure-text.md`, `references/examples/method/module-design-instant-ngp.md`, `references/examples/method/module-motivation-patterns.md`, `references/examples/method/section-skeleton.md`, `references/examples/method/overview-template.md`, `references/examples/method/example-of-the-three-elements.md`, `references/examples/method/method-writing-common-issues-note.md`
+8. Method detail files: `references/examples/method/pre-writing-questions.md`, `references/examples/method/module-triad-anchored-representation.md`, `references/examples/method/annotated-figure-to-text.md`, `references/examples/method/module-design-multiresolution-encoding.md`, `references/examples/method/module-motivation-patterns.md`, `references/examples/method/section-skeleton.md`, `references/examples/method/overview-template.md`, `references/examples/method/example-of-the-three-elements.md`, `references/examples/method/method-writing-common-issues-note.md`
 9. Related work examples index: `references/examples/related-work-examples.md`
 10. Related work files: `references/examples/related-work/closest-prior-gap-template.md`, `references/examples/related-work/topic-comparison-template.md`
 11. Experiments examples index: `references/examples/experiments-examples.md`

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md

@@ -5,7 +5,7 @@
 
 ```latex
 % In this paper, we propose a novel framework …
-%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
+%% Example: In this paper, we introduce a structured anchor-based representation, named AnchorField, to solve the challenge of reconstructing a changing target from sparse observations.
 In this paper, we propose a novel framework/representation, named [method name] for [xxx task].
 
 % Teaser for basic idea
@@ -13,11 +13,11 @@ In this paper, we propose a novel framework/representation, named [method name]
 The basic idea is illustrated in [xxx Figure].
 
 % One-sentence key novelty/contribution (very important ability)
-%% Example: For the implicit fields at different frames, instead of learning them separately, Neural Body generates them from the same set of latent codes.
+%% Example: Instead of learning each observation-specific field separately, AnchorField generates them from the same set of anchor codes.
 Our innovation is in [one sentence for key novelty].
 
 % Method details
-%% Example: Specifically, we anchor a set of latent codes to the vertices of a deformable human model (SMPL in this work), namely that their spatial locations vary with the human pose. To obtain the 3D representation at a frame, we first transform the code locations based on the human pose, which can be reliably estimated from sparse camera views. Then, a network is designed to regress the density and color for any 3D point based on these latent codes. Both the latent codes and the network are jointly learned from images of all video frames during the reconstruction.
+%% Example: Specifically, we anchor a set of latent codes to a reference support structure so that their spatial locations follow the current observation. To obtain the target representation for one condition, we first transform the code locations using the available alignment signal. Then, a prediction network estimates the required outputs at each query point from these codes. Both the anchor codes and the prediction network are jointly learned from all observations.
 Specifically, [how it works in detail].
 
 % Advantage 1

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/pipeline-version-2-two-contributions.md

@@ -5,7 +5,7 @@
 
 ```latex
 % In this paper, we propose a novel framework …
-%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
+%% Example: In this paper, we introduce a structured anchor-based representation, named AnchorField, to solve the challenge of reconstructing a changing target from sparse observations.
 In this paper, we propose a novel framework/representation, named [method name] for [xxx task].
 
 % One-sentence key novelty

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/annotated-figure-to-text.md

@@ -0,0 +1,66 @@
+# Annotated Figure (Text Conversion)
+
+This file converts an annotated method figure into reusable writing notes.
+
+## Purpose
+
+Use this mapping to understand how one Method section can explicitly separate:
+
+1. Module motivation
+2. Module design (data structure)
+3. Module design (forward process)
+4. Technical advantages
+
+## Block-by-Block Mapping
+
+### Section 3.1: Structured Anchor Codes
+
+1. **Module design (data structure)**
+- The paragraph defines structured codes anchored to a reference support structure.
+- It explains what is constructed: latent codes, anchor positions, and the condition-dependent transformation that keeps them aligned with the current instance.
+
+2. **Technical advantages**
+- The paragraph explains why this design works better: it preserves correspondence across observations and keeps the representation aligned with changing geometry.
+- It highlights why anchoring codes to a structured support is beneficial.
+
+### Section 3.2: Code Diffusion
+
+1. **Motivation of this module**
+- The paragraph states the remaining problem: direct interpolation of sparse anchor codes leaves many query locations weakly represented.
+- This motivates propagation from anchor locations to nearby continuous space.
+
+2. **Module design (forward process)**
+- The paragraph explains the execution pipeline: build sparse feature volumes, run sparse convolutions, interpolate codes at query points, and feed those codes to prediction networks.
+- This is a canonical input -> steps -> output module description.
+
+### Section 3.3: Field Regression
+
+1. **Module design (forward process) for the first prediction head**
+- The first paragraph defines how one target quantity is regressed from the latent code and condition inputs.
+
+2. **Module design (data structure) for the second prediction head**
+- The next paragraph introduces required inputs or embeddings such as latent code, query direction, spatial location, or condition tokens.
+
+3. **Module design (forward process) for the second prediction head**
+- The following paragraph describes how those inputs are encoded and passed into the second prediction network for the final estimate.
+
+### Section 3.4: Output Aggregation
+
+1. **Module design (forward process)**
+- The paragraph describes the final aggregation process that converts pointwise predictions into the output seen by the reader or evaluator.
+
+## Reusable Writing Pattern from This Figure
+
+For each module subsection, follow this order:
+
+1. `Motivation`: state unresolved challenge and technical reason.
+2. `Design-1`: define structure/representation/network.
+3. `Design-2`: describe forward process in execution order.
+4. `Advantage`: explain why this module improves over alternatives.
+
+## Suggested Paragraph Starters
+
+1. Motivation: `A remaining challenge is ...`
+2. Data structure design: `We represent ... with ...`
+3. Forward process: `Given [input], we first ... then ... finally ...`
+4. Technical advantage: `Compared with previous methods, this design ... because ...`

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/example-of-the-three-elements.md

@@ -18,27 +18,27 @@ Each `% ...` annotation explains the paragraph(s) immediately below it.
 \subsection{3.1. Structured latent codes}
 
 % Module design: introduce the module's data structure
-To control the spatial locations of latent codes with the human pose, we anchor these latent codes to a deformable human body model (SMPL) [38]. SMPL is a skinned vertex-based model, which is defined as a function of shape parameters, pose parameters, and a rigid transformation relative to the SMPL coordinate system. The function outputs a posed 3D mesh with 6890 vertices. Specifically, we define a set of latent codes \( Z = \{z_1, z_2, ..., z_{6890}\} \) on vertices of the SMPL model. For the frame \( t \), SMPL parameters \( S_t \) are estimated from the multi-view images \( \{I_t^c \mid c = 1, ..., N_c\} \) using [26]. The spatial locations of the latent codes are then transformed based on the human pose \( S_t \) for the density and color regression. Figure 3 shows an example. The dimension of latent code \( z \) is set to 16 in our experiments.
+To keep latent codes aligned with the current instance, we anchor them to a deformable reference structure [38]. This structure is parameterized by shape variables, condition variables, and a rigid transformation relative to its own coordinate system, and outputs a posed mesh or support geometry. Specifically, we define a set of latent codes \( Z = \{z_1, z_2, ..., z_M\} \) on the support points of that reference structure. For one observation \( t \), the condition parameters \( S_t \) are estimated from the available inputs \( \{I_t^c \mid c = 1, ..., N_c\} \) using an external alignment procedure [26]. The spatial locations of the latent codes are then transformed according to \( S_t \) before the downstream prediction heads consume them. Figure 3 shows an example. The latent-code dimension is set to 16 in this example.
 
 % Technical advantages of this module
-Similar to the local implicit representations [25, 5, 18], the latent codes are used with a neural network to represent the local geometry and appearance of a human. Anchoring these codes to a deformable model enables us to represent a dynamic human. With the dynamic human representation, we establish a latent variable model that maps the same set of latent codes to the implicit fields of density and color at different frames, which naturally integrates observations at different frames.
+Similar to local implicit representations [25, 5, 18], the latent codes are used with a neural network to represent local structure and attributes. Anchoring these codes to a deformable support lets the model stay aligned with changing geometry instead of relearning a separate representation for every condition. This yields a latent-variable view in which the same anchor codes can explain multiple observations while sharing information across them.
 
 \subsection{3.2. Code diffusion}
 
 % Motivation of this module
-Figure 3(a) shows the process of code diffusion. The implicit fields assign the density and color to each point in the 3D space, which requires us to query the latent codes at continuous 3D locations. This can be achieved with the trilinear interpolation. However, since the structured latent codes are relatively sparse in the 3D space, directly interpolating the latent codes leads to zero vectors at most 3D points. To solve this problem, we diffuse the latent codes defined on the surface to nearby 3D space.
+Figure 3(a) shows the process of code propagation. The target fields assign outputs to each point in the domain, which requires querying the latent codes at continuous locations. This can be achieved with trilinear interpolation. However, because the structured anchor codes are sparse, directly interpolating them leaves many query points weakly represented. To solve this problem, we propagate the codes defined on the support structure to nearby space.
 
 % Module design: introduce module design by describing the module forward process
-Inspired by [65, 56, 49], we choose the SparseConvNet [21] to efficiently process the structured latent codes, whose architecture is described in Table 1. Specifically, based on the SMPL parameters, we compute the 3D bounding box of the human and divide the box into small voxels with voxel size of \( 5mm \times 5mm \times 5mm \). The latent code of a non-empty voxel is the mean of latent codes of SMPL vertices inside this voxel. SparseConvNet utilizes 3D sparse convolutions to process the input volume and output latent code volumes with \( 2\times, 4\times, 8\times, 16\times \) downsampled sizes. With the convolution and downsampling, the input codes are diffused to nearby space. Following [56], for any point in 3D space, we interpolate the latent codes from multi-scale code volumes of network layers 5, 9, 13, 17, and concatenate them into the final latent code. Since the code diffusion should not be affected by the human position and orientation in the world coordinate system, we transform the code locations to the SMPL coordinate system.
+Inspired by [65, 56, 49], we choose a sparse convolutional backbone [21] to efficiently process the structured latent codes, whose architecture is described in Table 1. Specifically, based on the reference-structure parameters, we compute a 3D bounding box around the active support and divide that box into small voxels with voxel size \( 5mm \times 5mm \times 5mm \). The latent code of a non-empty voxel is the mean of the anchor codes that fall inside it. The sparse backbone applies 3D sparse convolutions to this input volume and outputs latent code volumes at \( 2\times, 4\times, 8\times, 16\times \) downsampled scales. With convolution and downsampling, the input codes are propagated to nearby space. Following [56], for any point in the domain, we interpolate the latent codes from multi-scale code volumes of network layers 5, 9, 13, and 17, and concatenate them into the final latent code. Since propagation should not be affected by global position and orientation, we transform code locations to the reference coordinate system.
 
-For any point \( \mathbf{x} \) in 3D space, we query its latent code from the latent code volume. Specifically, the point \( \mathbf{x} \) is first transformed to the SMPL coordinate system, which aligns the point and the latent code volume in 3D space. Then, the latent code is computed using the trilinear interpolation. For the SMPL parameters \( S_t \), we denote the latent code at point \( \mathbf{x} \) as \( \psi(\mathbf{x}, Z, S_t) \). The code vector is passed into MLP networks to predict the density and color for point \( \mathbf{x} \).
+For any query point \( \mathbf{x} \), we obtain its latent code from the propagated code volume. Specifically, the point \( \mathbf{x} \) is first transformed to the reference coordinate system so that the query and code volume are aligned. Then, the latent code is computed with trilinear interpolation. For condition parameters \( S_t \), we denote the latent code at point \( \mathbf{x} \) by \( \psi(\mathbf{x}, Z, S_t) \). The resulting code vector is passed to prediction networks that estimate the target outputs at \( \mathbf{x} \).
 
 \subsection{3.3. Density and color regression}
 
-Figure 3(b) overviews the regression of density and color for any point in 3D space. The density and color fields are represented by MLP networks. Details of network architectures are described in the supplementary material.
+Figure 3(b) overviews the regression of the target outputs for any query point. The corresponding fields are represented by MLP networks. Details of the network architectures are described in the supplementary material.
 
 % Module design: introduce module design by describing the module forward process
-\textbf{Density model.} For the frame \( t \), the volume density at point \( \mathbf{x} \) is predicted as a function of only the latent code \( \psi(\mathbf{x}, Z, S_t) \), which is defined as:
+\textbf{First prediction head.} For condition \( t \), the first target quantity at point \( \mathbf{x} \) is predicted as a function of only the latent code \( \psi(\mathbf{x}, Z, S_t) \), which is defined as:
 
 \[
 \sigma_t(\mathbf{x}) = M_{\sigma}(\psi(\mathbf{x}, Z, S_t)),
@@ -48,20 +48,20 @@ Figure 3(b) overviews the regression of density and color for any point in 3D sp
 where \( M_{\sigma} \) represents an MLP network with four layers.
 
 % Module design: introduce the module's data structure
-\textbf{Color model.} Similar to [37, 44], we take both the latent code \( \psi(\mathbf{x}, Z, S_t) \) and the viewing direction \( \mathbf{d} \) as input for the color regression. To model the location-dependent incident light, the color model also takes the spatial location \( \mathbf{x} \) as input. We observe that temporally-varying factors affect the human appearance, such as secondary lighting and self-shadowing. Inspired by the auto-decoder [48], we assign a latent embedding \( \ell_t \) for each video frame \( t \) to encode the temporally-varying factors.
+\textbf{Second prediction head.} Similar to [37, 44], we take both the latent code \( \psi(\mathbf{x}, Z, S_t) \) and an observation-dependent direction \( \mathbf{d} \) as input for the second target. To model location-dependent effects, this head also takes the spatial location \( \mathbf{x} \) as input. We further observe that condition-specific factors can change the target output. Inspired by the auto-decoder [48], we assign a latent embedding \( \ell_t \) for each condition \( t \) to encode those varying factors.
 
 % Module design: introduce module design by describing the module forward process
-Specifically, for the frame \( t \), the color at \( \mathbf{x} \) is predicted as a function of the latent code \( \psi(\mathbf{x}, Z, S_t) \), the viewing direction \( \mathbf{d} \), the spatial location \( \mathbf{x} \), and the latent embedding \( \ell_t \). Following [51, 44], we apply the positional encoding to both the viewing direction \( \mathbf{d} \) and the spatial location \( \mathbf{x} \), which enables better learning of high frequency functions. The color model at frame \( t \) is defined as:
+Specifically, for condition \( t \), the second target at \( \mathbf{x} \) is predicted as a function of the latent code \( \psi(\mathbf{x}, Z, S_t) \), the observation direction \( \mathbf{d} \), the spatial location \( \mathbf{x} \), and the latent embedding \( \ell_t \). Following [51, 44], we apply positional encoding to both \( \mathbf{d} \) and \( \mathbf{x} \), which enables better learning of high-frequency functions. The second prediction head at condition \( t \) is defined as:
 
 \[
 c_t(\mathbf{x}) = M_c(\psi(\mathbf{x}, Z, S_t), \gamma_d(\mathbf{d}), \gamma_x(\mathbf{x}), \ell_t),
 \tag{2}
 \]
 
-where \( M_c \) represents an MLP network with two layers, and \( \gamma_d \) and \( \gamma_x \) are positional encoding functions for viewing direction and spatial location, respectively. We set the dimension of \( \ell_t \) to 128 in experiments.
+where \( M_c \) represents an MLP network with two layers, and \( \gamma_d \) and \( \gamma_x \) are positional encoding functions for direction and spatial location, respectively. We set the dimension of \( \ell_t \) to 128 in this example.
 
 \subsection{3.4. Volume rendering}
 
 % Module design: introduce module design by describing the module forward process
-Given a viewpoint, we utilize the classical volume rendering techniques to render the Neural Body into a 2D image. The pixel colors are estimated via the volume rendering integral equation [27] that accumulates volume densities and colors along the corresponding camera ray. In practice, the integral is approximated using numerical quadrature [41, 44]. Given a pixel, we first compute its camera ray \( \mathbf{r} \) using the camera parameters and sample \( N_k \) points \( \{\mathbf{x}_k\}_{k=1}^{N_k} \) along camera ray \( \mathbf{r} \) between near and far bounds. The scene bounds are estimated based on the SMPL model. Then, Neural Body predicts volume densities and colors at these points. For the video frame \( t \), the rendered color \( \hat{C}_t(\mathbf{r}) \) ...
+Given an observation direction, we utilize a standard aggregation procedure to render the predicted field into a 2D output. Pixel values are estimated via a volume-integration equation [27] that accumulates the predicted quantities along the corresponding ray. In practice, the integral is approximated using numerical quadrature [41, 44]. Given a pixel, we first compute its ray \( \mathbf{r} \) using the camera parameters and sample \( N_k \) points \( \{\mathbf{x}_k\}_{k=1}^{N_k} \) along that ray between near and far bounds. The scene bounds are estimated from the reference structure. Then, the model predicts the target outputs at these points. For condition \( t \), the rendered value \( \hat{C}_t(\mathbf{r}) \) ...
 ```

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/{module-design-instant-ngp.md → module-design-multiresolution-encoding.md}

@@ -1,4 +1,4 @@
-# Module Design Example 
+# Module Design Example (Multiresolution Encoding)
 
 This example uses `%` comments as annotations.
 Each `% ...` annotation explains the paragraph(s) immediately below it.

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/{module-triad-neural-body.md → module-triad-anchored-representation.md}

@@ -1,11 +1,11 @@
-# Module Triad Example (Neural Body)
+# Module Triad Example (Anchored Representation)
 
-`Use Neural Body to understand the three elements of a module: design, motivation, and technical advantages.`
+`Use this anchored-representation example to understand the three elements of a module: design, motivation, and technical advantages.`
 
 Local source references:
 
 1. Annotated figure showing motivation/design/advantages split.
-3. Text-converted annotation notes: `references/examples/method/neural-body-annotated-figure-text.md`
+3. Text-converted annotation notes: `references/examples/method/annotated-figure-to-text.md`
 
 Triad mapping template:
 
@@ -15,5 +15,5 @@ Triad mapping template:
 
 Direct usage:
 
-1. Read `neural-body-annotated-figure-text.md` to map each paragraph to one triad element.
+1. Read `annotated-figure-to-text.md` to map each paragraph to one triad element.
 2. Rebuild your own Method subsection with the same triad order.

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

@@ -18,12 +18,12 @@
 %% Example: The overview of the proposed model is illustrated in Figure 3.
 
 % Explain what Section 3.1 covers
-%% Example 1: Neural Body starts from a set of structured latent codes attached to the surface of a deformable human model (Section 3.1).
-%% Example 2: In this section, we first describe how to model 3D scenes with MLP maps (Section 3.1).
+%% Example 1: The model starts from a set of structured anchor codes attached to a reference support structure (Section 3.1).
+%% Example 2: In this section, we first describe how to model the target space with learnable field maps (Section 3.1).
 
 % Explain what Section 3.2 covers
-%% Example 1: The latent code at any location around the surface can be obtained with a code diffusion process (Section 3.2) and then decoded to density and color values by neural networks (Section 3.3).
-%% Example 2: Then, Section 3.2 discusses how to represent volumetric videos with dynamic MLP maps.
+%% Example 1: The code at any nearby location is obtained with a propagation process (Section 3.2) and then decoded into the target outputs by prediction networks (Section 3.3).
+%% Example 2: Then, Section 3.2 discusses how to represent changing scenes with dynamic field maps.
 
 % Explain what Section 3.3 covers
 %% Example 3: Finally, we introduce some strategies to speed up the rendering process (Section 3.3).

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

@@ -1,13 +1,14 @@
 # Method Pre-Writing Questions
 
 
-`Before writing Method, answer: (1) what modules exist, and (2) for each module, what is its workflow, why is it needed, and why does it work.`
+`Before writing Method, answer: (1) what modules exist, and (2) for each module, what is its role, what flow does it participate in, why is it needed, and why does it work.`
 
 ```text
 Questions:
 (1) What modules are in the method?
-(2) For each module, answer three questions:
-    - What is this module's workflow?
+(2) For each module, answer four questions:
+    - What role does this module play?
+    - What flow or interface does this module participate in?
     - Why do we need this module?
     - Why does this module work?
 ```

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

@@ -2,15 +2,15 @@
 
 All method example cites should point to the local files below.
 
-## A. Planning and Writing Workflow
+## A. Planning and Writing Sequence
 
 1. Pre-writing questions: `references/examples/method/pre-writing-questions.md`
 
 ## B. Module Triad and Module-Level Writing
 
-1. Module triad (Neural Body): `references/examples/method/module-triad-neural-body.md`
-2. Neural Body figure text conversion: `references/examples/method/neural-body-annotated-figure-text.md`
-3. Module design (Instant-NGP): `references/examples/method/module-design-instant-ngp.md`
+1. Module triad (anchored representation): `references/examples/method/module-triad-anchored-representation.md`
+2. Annotated figure text conversion: `references/examples/method/annotated-figure-to-text.md`
+3. Module design (multiresolution encoding): `references/examples/method/module-design-multiresolution-encoding.md`
 4. Module motivation patterns: `references/examples/method/module-motivation-patterns.md`
 
 ## C. Section-Level Templates

package/package-assets/shared/skills/lab/references/paper-writing/examples/related-work/closest-prior-gap-template.md

@@ -5,16 +5,16 @@ the paragraph needs to explain the gap precisely.
 
 ```tex
 \paragraph{Closest prior work.}
-The closest prior line improves uplift ranking by sharpening the treatment-aware
-scoring objective rather than by changing the final decision rule
-itself~\cite{lee2021uplift,wang2022counterfactual}. These methods are strong
-references because they already optimize for ranking quality and outperform
-simple pointwise baselines on standard benchmarks. However, they still assume
-that the learned score can be used directly as the final ranking signal across
-datasets with different calibration behavior. That assumption is limiting in our
-setting, where the raw score often contains useful relative information but is
-not always aligned with the final protocol-level target. Our method keeps the
-ranking-focused backbone but changes the final stage by inserting a post-hoc
-calibration module, so the method can preserve the stronger internal signal
-while adapting the exposed score to the benchmark-specific decision scale.
+The closest prior line improves score quality by refining the intermediate
+representation rather than by changing the final prediction rule
+itself~\cite{closestprior2021,anchor2022}. These methods are strong references
+because they already improve ranking or ordering quality over simple pointwise
+baselines on standard benchmarks. However, they still assume that the learned
+score can be exposed directly as the final decision signal across settings with
+different calibration behavior. That assumption is limiting in our setting,
+where the internal score often carries useful relative information but is not
+always aligned with the final evaluation target. Our method keeps the stronger
+intermediate backbone but changes the last stage by inserting a lightweight
+adjustment module, so the method can preserve the better internal signal while
+adapting the exposed score to the evaluation scale used at test time.
 ```

package/package-assets/shared/skills/lab/references/paper-writing/examples/related-work/topic-comparison-template.md

@@ -12,8 +12,8 @@ known relationships among samples or treatment groups. However, they typically
 assume that the structured module alone is sufficient to produce well-calibrated
 scores at evaluation time. In our setting, that assumption is too strong: the
 raw ranking signal remains useful, but it is not always aligned with the final
-decision scale required by the frozen protocol. We therefore keep the
-structure-aware backbone but add a separate calibration stage, which lets us
+decision scale required by the fixed evaluation setup. We therefore keep the
+structure-aware backbone but add a separate adjustment stage, which lets us
 reuse the stronger signal while correcting its final score mapping.
 ```
 

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

@@ -56,7 +56,7 @@
 - Default allowed stages are `run`, `iterate`, `review`, and `report`. Only include `write` when framing is already approved and manuscript drafting is within scope.
 - Do not automatically change the research mission, paper-facing framing, or core claims.
 - You may add exploratory datasets, benchmarks, and comparison methods inside the exploration envelope.
-- You may promote exploratory additions to the primary package only when the contract's promotion policy is satisfied and the promotion is written back into `data-decisions.md`, `decisions.md`, `state.md`, and `session-brief.md`.
+- You may promote exploratory additions to the primary package only when the contract's promotion policy is satisfied and the promotion is written back into `data-decisions.md`, `decisions.md`, `state.md`, and `workflow-state.md`.
 - Poll long-running commands until they finish, hit a timeout, or hit a stop condition.
 - Keep a poll-based waiting loop instead of sleeping blindly.
 - Do not treat a short watcher such as `sleep 30`, a one-shot `pgrep`, or a single `metrics.json` probe as the rung command when the real experiment is still running.
@@ -74,7 +74,7 @@
   - `review` must update canonical review context
   - `report` must produce `<deliverables_root>/report.md` and `<deliverables_root>/main-tables.md`
   - `write` must produce LaTeX output under `<deliverables_root>/paper/`
-- Treat promotion as incomplete unless it writes back to `data-decisions.md`, `decisions.md`, `state.md`, and `session-brief.md`.
+- Treat promotion as incomplete unless it writes back to `data-decisions.md`, `decisions.md`, `state.md`, and `workflow-state.md`.
 - Do not stop or promote on the basis of a metric or comparison claim whose source-backed definition is missing from the approved evaluation protocol.
 - 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.
@@ -137,4 +137,8 @@
   - if the user chooses a template, stop the loop and route to `superlab paper attach-template --path <dir>`
   - if the current write target is a final manuscript export, `paper_template_decision` is `default-scaffold`, and `paper_template_final_reminder_acknowledged` is `false`, ask one final reminder question before finalizing
   - if the user confirms staying on the default scaffold at that final reminder, persist `paper_template_final_reminder_acknowledged: true`
+- During ordinary `write` drafting rounds, draft manuscript text in `workflow_language`.
+- If the current write target is a final manuscript export, `workflow_language` and `paper_language` differ, and `paper_language_finalization_decision` is `unconfirmed`, ask one explicit question before finalizing: keep the manuscript in `workflow_language`, or convert the final manuscript to `paper_language`
+- If the user chooses to keep the draft language, persist `paper_language_finalization_decision: keep-workflow-language`
+- If the user chooses to convert, persist `paper_language_finalization_decision: convert-to-paper-language`
 - While the real experiment process is still alive, emit only a progress update and keep waiting. Do not present a terminal summary for that rung until the process exits or the rung hits an explicit stop boundary.

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

@@ -27,7 +27,6 @@
 - `.lab/context/state.md`
 - `.lab/context/decisions.md`
 - `.lab/context/data-decisions.md`
-- `.lab/context/session-brief.md`
 
 ## Required Artifact
 

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

@@ -26,7 +26,6 @@
 - `.lab/context/state.md`
 - `.lab/context/decisions.md`
 - `.lab/context/terminology-lock.md`
-- `.lab/context/session-brief.md`
 
 ## Required Artifact
 

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

@@ -2,6 +2,7 @@
 
 ## Required Output
 
+- plain-language scenario description
 - one-sentence problem statement
 - why the problem matters in plain language
 - failure case
@@ -9,8 +10,11 @@
 - contribution category
 - breakthrough level
 - existing methods summary
+- closest-prior-work comparison
 - why the proposed idea is better than existing methods
+- rough plain-language approach description
 - three meaningful points
+- literature scoping bundle with a default target of 20 sources, or an explicit explanation for a smaller scoped field
 - literature-backed framing
 - sourced datasets and metrics
 - credible baseline shortlist
@@ -27,10 +31,14 @@
 - Mark generated hypotheses clearly.
 - Do not merge them into one undifferentiated summary.
 - Ask one clarifying question at a time when a missing assumption would materially change the proposal.
+- Build a source bundle before claiming novelty. The default target is 20 relevant sources split across closest prior work, recent strong papers, benchmark or evaluation papers, surveys or taxonomies, and adjacent-field work when useful.
+- If the field is genuinely too narrow to support that target, say so explicitly and justify the smaller literature bundle instead of silently skipping the search.
+- The idea artifact must follow the repository `workflow_language`, not whichever language is easiest locally.
 - Before writing the full artifact, give the user a short summary with the one-sentence problem, why current methods fail, and the three meaningful points.
 
 ## Context Read Set
 
+- `.lab/config/workflow.json`
 - `.lab/context/mission.md`
 - `.lab/context/open-questions.md`
 
@@ -42,24 +50,33 @@
 
 ## Recommended Structure
 
-1. One-sentence problem
-2. Failure of existing methods
-3. Idea classification, contribution category, and breakthrough level
-4. Existing methods and shared assumptions
-5. Why the proposed idea is better
-6. Three meaningful points
-7. Candidate approaches and recommendation
-8. Dataset and metric candidates
-9. Falsifiable hypothesis
-10. Expert critique
-11. Revised proposal
-12. Approval gate
-13. Minimum viable experiment
+1. Scenario
+2. One-sentence problem
+3. Why the problem matters
+4. Failure of existing methods
+5. Idea classification, contribution category, and breakthrough level
+6. Existing methods and shared assumptions
+7. Literature scoping bundle
+8. Closest-prior-work comparison
+9. Rough approach in plain language
+10. Why the proposed idea is better
+11. Three meaningful points
+12. Candidate approaches and recommendation
+13. Dataset, baseline, and metric candidates
+14. Falsifiable hypothesis
+15. Expert critique
+16. Revised proposal
+17. Approval gate
+18. Minimum viable experiment
 
 ## Writing Standard
 
 - Keep the problem statement short, concrete, and easy to scan.
+- Explain the scenario, target user or beneficiary, and why the problem matters before talking about novelty.
 - State why the target problem matters before talking about the method.
 - Compare against existing methods explicitly, not by vague novelty language.
+- Do not call something new without a literature-scoping bundle and a closest-prior comparison.
+- Explain what current methods do, why they fall short, and roughly how the proposed idea would work in plain language.
 - The three meaningful points should each fit in one direct sentence.
+- Before approval, run `.lab/.managed/scripts/validate_idea_artifact.py --idea <idea-artifact> --workflow-config .lab/config/workflow.json`.
 - Do not leave `.lab/context/mission.md` as an empty template after convergence; write the approved problem, why it matters, the current benchmark scope, and the approved direction back into canonical context.

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

@@ -12,9 +12,12 @@
 ## Config Read Set
 
 - `.lab/config/workflow.json`
+- `workflow_language` from `.lab/config/workflow.json`
+- `paper_language` from `.lab/config/workflow.json`
 - `paper_template_root` from `.lab/config/workflow.json`
 - `paper_template_decision` from `.lab/config/workflow.json`
 - `paper_template_final_reminder_acknowledged` from `.lab/config/workflow.json`
+- `paper_language_finalization_decision` from `.lab/config/workflow.json`
 
 ## Context Read Set
 
@@ -58,6 +61,7 @@ Run these on every round:
 
 - Change one section or one clearly bounded subsection per round.
 - LaTeX is the required manuscript output format.
+- Ordinary manuscript drafting rounds should follow `workflow_language`.
 - If `paper_template_root` is configured, inspect that template directory before drafting and align the manuscript structure to it.
 - Treat attached template directories as user-owned and potentially modified. Do not rewrite template files unless the user explicitly asks.
 - If no paper template is configured and `paper_template_decision` is `unconfirmed`, ask one explicit question before the first `.tex` drafting round: continue with the default LaTeX scaffold, or attach a template directory first.
@@ -72,14 +76,25 @@ Run these on every round:
   - `.lab/.managed/templates/paper-references.bib`
 - If the current round is a final manuscript export or final-draft pass, `paper_template_root` is still empty, `paper_template_decision` is `default-scaffold`, and `paper_template_final_reminder_acknowledged` is `false`, ask one final reminder question about switching to a template before finalizing.
 - If the user confirms staying on the default scaffold at that final reminder, persist `paper_template_final_reminder_acknowledged: true`.
+- If the current round is a final manuscript export or final-draft pass, `workflow_language` and `paper_language` differ, and `paper_language_finalization_decision` is `unconfirmed`, ask one explicit question before finalizing: keep the manuscript in `workflow_language`, or convert the final manuscript to `paper_language`.
+- If the user chooses to keep the draft language, persist `paper_language_finalization_decision: keep-workflow-language`.
+- If the user chooses to convert, persist `paper_language_finalization_decision: convert-to-paper-language`.
+- If `paper_language_finalization_decision` is `convert-to-paper-language`, the final manuscript output should be converted to `paper_language` before accepting the final round.
 - Load only the current section guide. Do not load every section guide at once.
 - Reuse example-bank structure, paragraph roles, sentence logic, and paper-facing LaTeX asset patterns when examples are bundled, but never copy wording verbatim.
 - Treat example cites and example file names as writing references, not as evidence for the current paper.
 - Build a compact mini-outline before prose.
-- Build the paper asset plan before prose when the section carries experimental or method claims:
-  - decide which tables the section needs
-  - decide which figure placeholders the section needs
-  - decide which citations must appear in the section
+- Build the paper asset plan before prose when the section carries introduction, experimental, method, related-work, or conclusion claims:
+  - record the asset coverage targets and gaps for the current paper
+  - record which table asset files the section needs, what each table should show, and which evidence supports it
+  - record which figure placeholder files the section needs, including the problem-setting or teaser figure when the paper needs reader-facing task setup
+  - record which analysis asset the paper needs beyond the main table and whether it will be a table or a figure
+  - record what each figure or analysis asset should show and why the reader needs it
+  - record which citation anchors must appear in the section and why each anchor matters
+- Before drafting `introduction`, `method`, `experiments`, `related work`, or `conclusion`, run `.lab/.managed/scripts/validate_paper_plan.py --paper-plan .lab/writing/plan.md`.
+- If the paper-plan validator fails, stop and fill `.lab/writing/plan.md` first instead of drafting prose.
+- During ordinary draft rounds, run `.lab/.managed/scripts/validate_section_draft.py --section <section> --section-file <section-file> --mode draft` and `.lab/.managed/scripts/validate_paper_claims.py --section-file <section-file> --mode draft` after revising the active section.
+- Treat draft-round output from the section and claim validators as warnings that must be recorded and addressed in the write-iteration artifact, not as immediate stop conditions.
 - For each subsection, explicitly include motivation, design, and technical advantage when applicable.
 - Avoid a writing style that reads like incremental patching of a naive baseline.
 - Keep terminology stable across the full paper.
@@ -93,10 +108,17 @@ Run these on every round:
   - `<deliverables_root>/paper/tables/main-results.tex`
   - `<deliverables_root>/paper/tables/ablations.tex`
 - If the current paper contains method or experiments claims, materialize figure placeholders with captions, labels, and explicit figure intent:
+  - `<deliverables_root>/paper/figures/problem-setting.tex`
   - `<deliverables_root>/paper/figures/method-overview.tex`
   - `<deliverables_root>/paper/figures/results-overview.tex`
+- If the current paper contains experimental claims, materialize one additional paper-facing analysis asset with caption, label, and explicit asset intent:
+  - `<deliverables_root>/paper/analysis/analysis-asset.tex`
 - Table assets must use paper-facing LaTeX structure with `booktabs`, caption, label, and consistent precision.
 - Figure placeholders must explain what the final figure should show and why the reader needs it.
+- Core asset coverage for a paper-facing final draft should include a problem-setting or teaser figure, a method overview figure, a results overview figure, a main-results table, an ablation table, and one additional analysis asset.
+- Keep `.lab/writing/plan.md` synchronized with the current table plan, figure plan, citation plan, and section-to-asset map whenever manuscript assets change.
+- For final-draft or export rounds, run `.lab/.managed/scripts/validate_section_draft.py --section <section> --section-file <section-file> --mode final` and `.lab/.managed/scripts/validate_paper_claims.py --section-file <section-file> --mode final` before accepting the round.
+- If the final-round section or claim validators fail, keep editing the affected section until it passes; do not stop at asset-complete but rhetorically weak or unsafe prose.
 - Run `.lab/.managed/scripts/validate_manuscript_delivery.py --paper-dir <deliverables_root>/paper` before accepting a final-draft or export round.
 - If the manuscript validator fails, keep editing and asset generation until it passes; do not stop at prose-only completion.
 - Run a LaTeX compile smoke test when a local LaTeX toolchain is available; if not available, record the missing verification in the write iteration artifact.
@@ -117,8 +139,10 @@ Run these on every round:
 - `<deliverables_root>/paper/sections/<section>.tex`
 - `<deliverables_root>/paper/tables/main-results.tex`
 - `<deliverables_root>/paper/tables/ablations.tex`
+- `<deliverables_root>/paper/figures/problem-setting.tex`
 - `<deliverables_root>/paper/figures/method-overview.tex`
 - `<deliverables_root>/paper/figures/results-overview.tex`
+- `<deliverables_root>/paper/analysis/analysis-asset.tex`
 
 ## Stop Conditions
 

package/package.json

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