superlab 0.1.70 → 0.1.72

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

@@ -148,6 +148,14 @@ Do not enter prose polish until the current section has passed the reference-con
 - If a section must use canonical short names, model labels, or ablation labels before the section that formally introduces them has been drafted, add a local naming bridge in that section that briefly maps the descriptive phrase to the canonical paper-facing labels and then reuse those labels consistently.
 - Keep one canonical natural-language paper-facing name per concept. Do not let one concept drift across paper-facing names, experiment labels, and internal identifiers.
 - Once a paper-facing model or ablation label is chosen, reuse the canonical label in later prose, tables, captions, and ranking summaries instead of replacing it with a narrative alias.
+- Treat the paper's core insight as an anchor that must be woven through section logic, not as an isolated `Our Insights` subsection.
+- Before drafting, recover the current core insight anchor from `.lab/writing/idea.md`, `.lab/writing/framing.md`, `.lab/writing/plan.md`, or the collaborator report. If no reliable anchor exists, write the best supported one in the write-iteration artifact and mark it as provisional instead of inventing a new paper claim.
+- Use the same insight anchor across Abstract, Introduction, Method, Experiments, and Conclusion unless the evidence changed and the framing artifact is revised.
+- In Introduction, create cognitive contrast: common assumption or prior explanation -> observed failure or anomaly -> root mechanism or insight -> contribution.
+- In Method, make design choices consequences of the insight: why the mechanism requires this decomposition, module, representation, loss, or protocol before explaining how it runs.
+- 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.
 - Before drafting or polishing, check the current section's block in `section-style-policies.md` and follow its encouraged, discouraged, and banned expression lists.
 - Before any additional tighten, compress, or polish pass on the same section, run a section-level acceptance gate first.
 - The section-level acceptance gate is passed only when canonical naming consistency, adjacent-section consistency, claim, metric, and ranking consistency with the current evidence, local clarity, local concision, and section-style compliance are all explicitly checked and no unresolved blocker remains.
@@ -246,6 +254,7 @@ Do not enter prose polish until the current section has passed the reference-con
 - When a round introduces or revises metrics, include a compact metric-glossary note in the user-facing round summary and record the metric-glossary validation in the write-iteration artifact.
 - Record the section-level acceptance gate in the write-iteration artifact before recommending further tightening on the same section.
 - Record section-style policy compliance, any retained discouraged move, and any banned move found in the write-iteration artifact.
+- Record the insight integration audit in the write-iteration artifact: core insight anchor, section role in the insight chain, challenged assumption, mechanism explanation, diagnostic evidence, and whether the prose avoided an isolated insight section.
 - Record the round target layer in the write-iteration artifact as `canonical manuscript`, `workflow-language paper layer`, or `both`.
 - If workflow-language was active and the round still targeted the canonical manuscript, record why canonical-only writing was acceptable in the write-iteration artifact.
 - If both layers were edited, record why the cross-language sync was required and whether it was explicitly requested by the user or required by final-draft/export finalization.
@@ -303,3 +312,12 @@ Do not enter prose polish until the current section has passed the reference-con
 - If the user asks to continue tightening the same section, default to a section-level acceptance review first instead of another immediate prose-polish pass.
 - Only recommend another tighten/compress/polish pass after the current section has passed the section-level acceptance gate.
 - If the round introduces or revises key terms, abbreviations, metrics, or mechanism names, include a short terminology note in the final user-facing response that says the full form, approved short form if any, what each term is, and why it matters here, and point to `.lab/writing/terminology-glossary.md` plus the write iteration artifact for the full terminology audit.
+
+## Stage Report Closeout
+
+- Before final handoff, write or update `.lab/stage-reports/<date>--write--<target>.md` from `.lab/.managed/templates/stage-report.md`.
+- Fill `Requested Outcome Mapping` before the core table so the final answer can be checked against the user's original request rather than only against internal stage state.
+- Fill `Repair Control`; if no repair loop ran, mark it as not applicable and state that ordinary drafting or evidence fixes remain allowed inside the stage contract.
+- Fill the `Core Explanation Table` in plain language: background, why now, what section or asset changed, how evidence and writing rules were applied, what worked, what did not work, what was verified, what remains unverified, what needs improvement and why, how to improve and why, key evidence, and the continue/stop/revise/rerun/escalate/handoff decision.
+- If the table says improvement is needed, the next action may be `stop` only when a terminal boundary is explicitly named; otherwise choose `continue`, `revise`, `rerun`, or `escalate`.
+- Run `.lab/.managed/scripts/validate_stage_report.py --stage-report <stage-report> --stage write` and include the report path plus validation result in the final user-facing summary.

package/package.json

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