@researai/deepscientist 1.5.11 → 1.5.13

package/src/skills/review/SKILL.md

@@ -17,7 +17,7 @@ It is also not the same as `rebuttal`.
 ## Interaction discipline
 
 - Follow the shared interaction contract injected by the system prompt.
-- For ordinary active work, prefer a concise progress update once work has crossed roughly 10 tool calls with a human-meaningful delta, and do not drift beyond roughly 20 tool calls or about 15 minutes without a user-visible update.
+- For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
 - When the review report, revision plan, or follow-up experiment TODO list becomes durable, send a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what the main risks are, what should be fixed next, and whether the next route is writing, experiment, or claim downgrade.
 
 ## Purpose
@@ -63,6 +63,16 @@ Do not treat “looks polished” as “is defensible”.
 - Do not recommend rhetoric when the real problem is missing evidence.
 - If novelty or positioning is uncertain, treat that as a literature-audit question first, not an automatic experiment request.
 - If a claim is too broad for the evidence, prefer narrowing or downgrading the claim over defending it with style.
+- If `startup_contract.review_followup_policy` is present, honor it:
+  - `audit_only`
+    - stop after durable review artifacts and a clear route recommendation
+  - `auto_execute_followups`
+    - do not stop at the audit if the next route is already clear; continue into the required experiments and manuscript deltas
+  - `user_gated_followups`
+    - finish the audit first, then package the next expensive follow-up step into one structured decision
+- If `startup_contract.manuscript_edit_mode = latex_required`, treat the provided LaTeX tree or `paper/latex/` as the writing surface when manuscript revision is needed.
+- If LaTeX source is unavailable while `latex_required` is requested, do not pretend the manuscript was edited; produce LaTeX-ready replacement text and an explicit blocker note instead.
+- Accept manuscript and review inputs from URLs, local file paths, local directories, or current-turn attachments; do not assume the draft is already perfectly normalized.
 
 ## Primary inputs
 
@@ -74,11 +84,13 @@ Use, in roughly this order:
 - the six-field `evaluation_summary` blocks from recent main experiments and analysis slices
 - recent main and analysis experiment results
 - figures, tables, and captions
+- current-turn attachments and user-provided local paths / directories / URLs for the manuscript bundle or review packet
 - prior self-review or reviewer-first notes as low-trust auxiliary input
 - nearby papers when novelty or comparison is unclear
 
 If the draft/result state is still unclear, open `intake-audit` first before continuing the review workflow.
 Before proposing extra experiments, read those structured `evaluation_summary` blocks first so you do not request work that the recorded evidence already resolved.
+If the user provided draft files or manuscript bundles directly, first normalize them into durable quest-visible paths before planning experiments or section-level revisions.
 
 ## Core outputs
 
@@ -87,6 +99,8 @@ The review pass should usually leave behind:
 - `paper/review/review.md`
 - `paper/review/revision_log.md`
 - `paper/review/experiment_todo.md`
+- `paper/paper_experiment_matrix.md` when more evidence is still needed
+- `paper/paper_experiment_matrix.json` when more evidence is still needed
 
 Use the templates in `references/` when needed:
 
@@ -175,14 +189,25 @@ For each serious issue, record:
 - what should change
 - whether the fix is writing-only, evidence-only, or experiment-dependent
 - whether the issue blocks `finalize`
+- one copy-ready replacement sentence / paragraph when feasible
+- one LaTeX-ready replacement block when `startup_contract.manuscript_edit_mode = latex_required`
 
 ### 5. Produce the follow-up experiment TODO list
 
 Only if more evidence is truly needed, write `paper/review/experiment_todo.md` using `references/experiment-todo-template.md`.
 
+When the paper still lacks experimental support, also create or revise:
+
+- `paper/paper_experiment_matrix.md`
+- `paper/paper_experiment_matrix.json`
+
+Treat the matrix as the paper-facing master plan and `paper/review/experiment_todo.md` as only the current execution frontier or review-facing subset.
+
 Each TODO item should include:
 
 - the review issue it answers
+- the matrix exp id
+- the corresponding `exp_id` in the paper experiment matrix
 - why existing evidence is still insufficient
 - the minimum experiment or analysis needed
 - required metric(s)
@@ -195,6 +220,50 @@ Each TODO item should include:
 
 Do not write a vague “run more ablations” list.
 Each TODO item should be concrete enough to turn into `analysis-campaign` slices or a `baseline` recovery task.
+The matrix should be broader than the TODO list and should classify the full paper-facing experiment space, not just analysis work.
+When building or revising that matrix, explicitly consider:
+
+- main comparison packaging or extension
+- component ablations
+- sensitivity / hyperparameter checks
+- robustness checks
+- efficiency / cost / latency / token-overhead checks when relevant
+- highlight-validation experiments that test the likely strengths of the method
+- limitation-boundary analyses
+- case study rows as optional rather than mandatory evidence
+
+Do not assume the paper only needs “analysis experiments”.
+Do not assume case studies belong in the required set.
+If efficiency or cost could become a reviewer-facing strength or concern, put that into the matrix explicitly.
+
+For the matrix, each row should usually record:
+
+- `exp_id`
+- `tier`
+- `experiment_type`
+- `status`
+- `feasibility_now`
+- `claim_ids`
+- `highlight_ids`
+- `research_question`
+- `hypothesis`
+- `comparators`
+- `metrics`
+- `minimal_success_criterion`
+- `paper_placement`
+- `promotion_rule`
+- `next_action`
+
+The matrix should also keep a short `highlight hypotheses` block.
+Do not rely on prose intuition for the method's best selling point; if a likely highlight matters, it should have a corresponding validation row in the matrix.
+
+Before treating the experiments section as stable, require that every currently feasible matrix row that is not merely `optional` or `dropped` is either:
+
+- completed
+- analyzed
+- excluded with a real reason
+- or blocked with a real reason
+
 When extra evidence is truly needed, use the shared supplementary-experiment protocol:
 
 - recover ids / refs first if needed
@@ -216,6 +285,54 @@ After the review artifacts are durable:
 
 Do not stop immediately after writing the review if the next route is already clear.
 
+### 7. Auto follow-up execution contract
+
+When `startup_contract.review_followup_policy = auto_execute_followups`:
+
+- treat the review as a gate, not as the endpoint
+- immediately turn the accepted follow-up route into action:
+  - `analysis-campaign`
+    - when new evidence is truly required
+  - `baseline`
+    - when a missing comparator baseline blocks fair review
+  - `write`
+    - when the issues are mostly text, outline, claim-scope, figure, or framing revisions
+- after each completed follow-up step, update:
+  - `paper/review/revision_log.md`
+  - `paper/review/experiment_todo.md`
+  - the draft or manuscript-facing revision package
+- only treat the review line as truly closed after the follow-up route has either completed or been downgraded / blocked explicitly
+
+When `startup_contract.review_followup_policy = user_gated_followups`:
+
+- stop after the durable audit artifacts
+- turn the next expensive follow-up package into one structured decision instead of continuing silently
+
+When `startup_contract.review_followup_policy = audit_only`:
+
+- stop after the durable audit artifacts and route recommendation
+
+### 8. Manuscript revision delivery contract
+
+If manuscript revision is required, make the delta explicit:
+
+- section
+- old claim / weakness
+- new wording
+- evidence basis
+- remaining limitation
+
+If `startup_contract.manuscript_edit_mode = copy_ready_text`:
+
+- provide copy-ready replacement wording in `paper/review/revision_log.md` or a nearby revision note
+- keep the wording directly usable by the user or downstream `write`
+
+If `startup_contract.manuscript_edit_mode = latex_required`:
+
+- prefer editing the actual LaTeX sources when they are available
+- otherwise provide LaTeX-ready replacement text blocks with explicit insertion targets
+- preserve labels, citations, figure/table refs, and section structure in the suggested replacements
+
 ## Companion skill routing
 
 Open additional skills only when the review workflow requires them:

package/src/skills/review/references/experiment-todo-template.md

@@ -5,25 +5,48 @@
 ### TODO EXP-001
 
 - source review issue:
+- matrix exp id:
 - why current evidence is insufficient:
 - route type:
   - existing-result analysis
   - comparator baseline
   - supplementary experiment
   - figure / table regeneration
+- experiment type:
+  - component_ablation
+  - sensitivity
+  - robustness
+  - efficiency_cost
+  - highlight_validation
+  - failure_boundary
+  - case_study_optional
+- tier:
+  - main_required
+  - main_optional
+  - appendix
+  - optional
 - minimum task:
 - required metric(s):
 - minimal success criterion:
+- likely paper placement:
+  - main_text
+  - appendix
+  - maybe
+  - omit
 - expected manuscript impact:
 - owner / next step:
 
 ### TODO EXP-002
 
 - source review issue:
+- matrix exp id:
 - why current evidence is insufficient:
 - route type:
+- experiment type:
+- tier:
 - minimum task:
 - required metric(s):
 - minimal success criterion:
+- likely paper placement:
 - expected manuscript impact:
 - owner / next step:

package/src/skills/review/references/review-report-template.md

@@ -1,5 +1,11 @@
 # Review Report Template
 
+## Review mode
+
+- review_followup_policy:
+- manuscript_edit_mode:
+- manuscript_source_status:
+
 ## Summary
 
 - paper / draft:
@@ -36,6 +42,8 @@
 - cause:
 - actionable fix:
 - acceptance criterion:
+- copy-ready revision text:
+- latex-ready revision text:
 
 ## Storyline Options + Writing Outlines
 
@@ -49,6 +57,14 @@
 2. 
 3. 
 
+## Manuscript Revision Package
+
+- section:
+- old wording / weakness:
+- new wording:
+- evidence basis:
+- latex-ready replacement block:
+
 ## Experiment Inventory & Research Experiment Plan
 
 - what existing experiments already cover:

package/src/skills/review/references/revision-log-template.md

@@ -3,6 +3,8 @@
 ## Revision Summary
 
 - current draft state:
+- review_followup_policy:
+- manuscript_edit_mode:
 - highest-priority fixes:
 - blockers:
 
@@ -20,6 +22,8 @@
   - supplementary experiment
   - claim downgrade
 - concrete change:
+- copy-ready revision text:
+- latex-ready revision text:
 - status:
 - blocks finalize:
 

package/src/skills/scout/SKILL.md

@@ -10,7 +10,7 @@ Use this skill when the quest does not yet have a stable research frame.
 ## Interaction discipline
 
 - Follow the shared interaction contract injected by the system prompt.
-- For ordinary active work, prefer a concise progress update once work has crossed roughly 10 tool calls with a human-meaningful delta, and do not drift beyond roughly 20 tool calls or about 15 minutes without a user-visible update.
+- For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
 - Message templates are references only. Adapt to the actual context and vary wording so updates feel natural and non-robotic.
 - If a threaded user reply arrives, interpret it relative to the latest scout progress update before assuming the task changed completely.
 - When scouting actually resolves the framing ambiguity, locks the evaluation contract, or makes the next anchor obvious, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what is now clear, why it matters, and which stage should come next.

package/src/skills/write/SKILL.md

@@ -20,7 +20,7 @@ This skill intentionally absorbs the strongest old DeepScientist writing discipl
 ## Interaction discipline
 
 - Follow the shared interaction contract injected by the system prompt.
-- For ordinary active work, prefer a concise progress update once work has crossed roughly 10 tool calls with a human-meaningful delta, and do not drift beyond roughly 20 tool calls or about 15 minutes without a user-visible update.
+- For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
 - Prefer `bash_exec` for durable document-build commands such as LaTeX compilation, figure regeneration, and scripted export steps so logs remain quest-local and reviewable.
 - Keep ordinary subtask completions concise. When a paper/draft milestone is actually completed, upgrade to a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` report instead of another short progress update.
 - That richer writing-stage milestone report should normally cover: which draft, section, or outline milestone finished, what is now supportable, what is still missing, and the exact recommended next revision or route decision.
@@ -146,6 +146,8 @@ The write stage should usually produce most of the following:
 
 - `paper/outline.md` or equivalent outline
 - `paper/selected_outline.json`
+- `paper/paper_experiment_matrix.md`
+- `paper/paper_experiment_matrix.json`
 - `paper/outline_selection.md`
 - `paper/reviewer_first_pass.md`
 - `paper/section_contracts.md`
@@ -202,6 +204,144 @@ At minimum, repeatedly verify:
 - figure and table provenance
 - file inclusion integrity for the draft or bundle
 
+## Paper experiment matrix contract
+
+For any paper-like writing line that has more than a trivial single-result story, create and maintain:
+
+- `paper/paper_experiment_matrix.md`
+- `paper/paper_experiment_matrix.json`
+
+Use `references/paper-experiment-matrix-template.md` when helpful.
+
+The paper experiment matrix is the durable experiment-control surface for the paper line.
+It exists to prevent two common failures:
+
+- an outline that overweights post-hoc analysis and under-specifies paper-typical experiments
+- a drifting supplementary-experiment queue where runs are launched ad hoc without a full paper-facing plan
+
+The matrix is not just an “analysis list”.
+It should cover the full paper-facing experiment program beyond the already-finished main run, including:
+
+- main comparison surfaces that still need packaging or extension
+- component ablations
+- sensitivity / hyperparameter checks
+- robustness or stress checks
+- efficiency / cost / latency / token-overhead checks when the method may have a strong deployment or efficiency story
+- highlight-validation experiments that test the method's most likely reader-facing strengths rather than merely assuming those strengths
+- failure-boundary or limitation-surface analyses
+- case study or trace walkthrough rows as optional supporting material rather than mandatory core evidence
+
+Case study is usually optional.
+Do not let it displace stronger quantitative evidence.
+Efficiency or cost experiments are not mandatory in every paper, but they should be added whenever:
+
+- the method may be attractive partly because it is lightweight or prompt-level
+- the overhead skepticism from reviewers is easy to anticipate
+- a performance-over-cost tradeoff could become part of the paper's practical contribution
+
+Highlight-validation rule:
+
+- do not assume the method's strongest selling point is already obvious from the aggregate metric
+- explicitly write down `highlight hypotheses`
+- plan at least one experiment that could confirm or falsify each serious highlight hypothesis
+
+Typical highlight hypotheses include:
+
+- the method is more selective rather than merely more conservative
+- the gain comes from a named mechanism rather than from generic stubbornness or scale
+- the improvement concentrates on the intended failure regime
+- the method keeps a strong performance / overhead tradeoff
+
+Each matrix row should normally record at least:
+
+- `exp_id`
+- `title`
+- `tier`
+  - `main_required`
+  - `main_optional`
+  - `appendix`
+  - `optional`
+  - `dropped`
+- `experiment_type`
+  - `main_comparison`
+  - `component_ablation`
+  - `sensitivity`
+  - `robustness`
+  - `efficiency_cost`
+  - `highlight_validation`
+  - `failure_boundary`
+  - `case_study_optional`
+- `status`
+  - `proposed`
+  - `planned`
+  - `ready`
+  - `running`
+  - `completed`
+  - `analyzed`
+  - `written`
+  - `excluded`
+  - `blocked`
+- `feasibility_now`
+  - whether the row is runnable with current assets or still blocked
+- `claim_ids`
+- `highlight_ids`
+- `research_question`
+- `hypothesis`
+- `why_this_matters`
+- `comparators`
+- `fixed_conditions`
+- `changed_variables`
+- `metrics`
+- `cost_budget`
+- `minimal_success_criterion`
+- `promotion_rule`
+  - what result would move the row into main text
+  - what result keeps it appendix-only
+  - what result should exclude it
+- `paper_placement`
+  - `main_text`
+  - `appendix`
+  - `maybe`
+  - `omit`
+- `result_artifacts`
+- `next_action`
+
+The matrix should also contain:
+
+- core paper claims
+- highlight hypotheses
+- a short experiment taxonomy summary
+- the current execution frontier
+- an explicit main-text gate
+- a refresh log that records how priorities changed after new evidence arrived
+
+Main-text drafting gate:
+
+- do not treat the main experiments section as stable while any row that is both:
+  - currently feasible
+  - and not marked `optional` or `dropped`
+  remains unaddressed
+- before the experiments section becomes stable, every currently feasible row should be:
+  - `completed`
+  - `analyzed`
+  - `excluded` with a real reason
+  - or `blocked` with a real reason
+
+This does not forbid drafting the introduction, method, or placeholders early.
+It does forbid pretending the paper's experimental story is settled while the feasible experiment frontier is still open.
+
+After every meaningful experiment outcome, even a null result or exclusion:
+
+- reopen the matrix first
+- update the row status and feasibility
+- update `paper_placement`
+- update the claim and highlight impact
+- update the priority order of the remaining rows
+- then decide the next experiment or writing move
+
+Do not decide the next supplementary experiment from memory alone when the matrix exists.
+The matrix should be the authoritative experiment-routing surface for the paper line, and the selected outline's `experimental_designs` should stay consistent with that matrix rather than drifting away from it.
+
 ## Venue template selection
 
 For paper-like writing, use a real venue template rather than improvising a blank LaTeX tree.
@@ -246,18 +386,20 @@ For paper-like deliverables, the safest default order is:
 3. choose the venue template from `templates/`, copy it into `paper/latex/`, and default general ML work to `templates/iclr2026/` unless a stronger venue target exists
 4. if the line benefits from an explicit outline contract, record one or more outline candidates with `artifact.submit_paper_outline(mode='candidate', ...)`
 5. if one outline should become the durable paper contract, select or revise it with `artifact.submit_paper_outline(mode='select'|'revise', ...)`
-6. if the selected outline still exposes evidence gaps, launch an outline-bound `artifact.create_analysis_campaign(...)` before drafting
-7. plan and generate decisive figures or tables
-8. draft sections directly from the evidence and the current working outline; do not force extra outline rounds when direct drafting is clearer and safer
-9. run harsh review and revision cycles
-10. proof, package, submit `artifact.submit_paper_bundle(...)` when the bundle is ready, and then pass to `finalize`
-11. if the final paper PDF exists and QQ milestone media is enabled in config, the bundle-ready milestone may attach that PDF once
+6. create or refresh `paper/paper_experiment_matrix.md` and `paper/paper_experiment_matrix.json` before stabilizing the experiments section
+7. if the selected outline or matrix still exposes evidence gaps, launch an outline-bound and matrix-bound `artifact.create_analysis_campaign(...)` before drafting the experiments section as if it were settled
+8. plan and generate decisive figures or tables
+9. draft sections directly from the evidence and the current working outline; do not force extra outline rounds when direct drafting is clearer and safer
+10. run harsh review and revision cycles
+11. proof, package, submit `artifact.submit_paper_bundle(...)` when the bundle is ready, and then pass to `finalize`
+12. if the final paper PDF exists and QQ milestone media is enabled in config, the bundle-ready milestone may attach that PDF once
 
 Before real drafting, force one explicit planning pass that stabilizes at least:
 
 - the current claim inventory
 - the claim-evidence map skeleton
 - the outline or outline candidates
+- the paper experiment matrix
 - the figure/table plan
 - the main evidence gaps
 
@@ -273,6 +415,7 @@ For substantial paper-like writing, the durable writing plan should usually incl
 
 - section goals
 - paragraph or subsection intent when it materially affects correctness
+- paper experiment matrix status and execution frontier
 - experiment-to-section mapping
 - figure/table-to-data-source mapping
 - citation/search plan
@@ -284,6 +427,7 @@ Do not let drafting quietly outrun the current evidence inventory.
 
 For reviewer-facing structure and section-level drafting contracts, read these references when the line needs sharper paper craft:
 
+- `references/paper-experiment-matrix-template.md`
 - `references/reviewer-first-writing.md`
 - `references/section-contracts.md`
 - `references/sentence-level-proofing.md`
@@ -306,6 +450,21 @@ Also build an experiment inventory before outlining:
   - appendix-only evidence
   - unusable or too-weak evidence
 - verify that each planned main claim has at least one durable evidence path
+- convert that inventory into the paper experiment matrix instead of leaving it as loose notes
+
+When building the matrix, do not reduce the candidate pool to “analysis experiments”.
+The inventory should explicitly consider:
+
+- ablations
+- robustness checks
+- sensitivity or hyperparameter checks
+- efficiency / cost / latency / token-overhead checks
+- experiments aimed at validating likely highlights
+- limitation-boundary analyses
+- optional case studies
+
+If the method appears to have a likely practical or deployment-facing strength, test it directly instead of burying that possibility in prose.
+If the method appears to have a likely conceptual highlight, write the corresponding `highlight hypothesis` and treat it as something that still needs evidence rather than something to assume.
 
 If an experiment is too weak, too tiny, or poorly comparable, do not let it silently anchor a main claim.
 As a strong default, experiments with very small evaluation support, such as `<=10` effective examples or similarly fragile sample counts, should not carry a main-text claim unless the user explicitly accepts that limitation and the caveat is written next to the claim.
@@ -1083,3 +1242,5 @@ Exit the write stage only when one of the following is durably true:
 - the current draft is evidence-complete enough for `finalize`, including a selected outline and a durable paper bundle manifest when the deliverable is paper-like
 - a clear evidence gap has been recorded and the quest is routed backward
 - a packaging or proofing blocker has been recorded and the next action is explicit
+
+For paper-like writing, do not treat the draft as evidence-complete enough for `finalize` while `paper/paper_experiment_matrix.*` still contains currently feasible non-optional rows that remain unresolved.

package/src/skills/write/references/paper-experiment-matrix-template.md

@@ -0,0 +1,131 @@
+# Paper Experiment Matrix Template
+
+Use this template when a paper-like line needs a durable experiment-control surface beyond the selected outline.
+
+Create and maintain both:
+
+- `paper/paper_experiment_matrix.md`
+- `paper/paper_experiment_matrix.json`
+
+The Markdown file is the human-facing control surface.
+The JSON file is the machine-facing mirror.
+
+## 1. Current Judgment
+
+- current judgment:
+- why the matrix is needed now:
+- what would make the experiments section stable:
+- what still blocks stable paper writing:
+
+## 2. Core Claims
+
+- `C1`:
+  - one-line claim:
+  - current support status:
+  - strongest current evidence:
+  - still-missing evidence:
+
+- `C2`:
+  - one-line claim:
+  - current support status:
+  - strongest current evidence:
+  - still-missing evidence:
+
+- `C3`:
+  - one-line claim:
+  - current support status:
+  - strongest current evidence:
+  - still-missing evidence:
+
+## 3. Highlight Hypotheses
+
+Write only serious hypotheses that could matter to the paper's reader-facing value.
+Do not assume the highlight is already true just because it sounds attractive.
+
+- `H1`:
+  - one-line highlight:
+  - why it is plausible:
+  - validation rows:
+  - fallback if unsupported:
+
+- `H2`:
+  - one-line highlight:
+  - why it is plausible:
+  - validation rows:
+  - fallback if unsupported:
+
+## 4. Taxonomy Summary
+
+Check every category deliberately.
+Do not collapse the matrix into “analysis only”.
+
+- main comparison:
+- component ablation:
+- sensitivity:
+- robustness:
+- efficiency / cost:
+- highlight validation:
+- failure boundary:
+- case study optional:
+
+## 5. Matrix Table
+
+| Exp id | Title | Tier | Experiment type | Status | Feasibility now | Claim ids | Highlight ids | Research question | Metrics | Paper placement | Next action |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| | | main_required / main_optional / appendix / optional / dropped | main_comparison / component_ablation / sensitivity / robustness / efficiency_cost / highlight_validation / failure_boundary / case_study_optional | proposed / planned / ready / running / completed / analyzed / written / excluded / blocked | feasible_now / light_setup / blocked / uncertain | | | | | main_text / appendix / maybe / omit | |
+
+## 6. Detail Cards
+
+Repeat one card per meaningful row.
+
+### EXP-001
+
+- title:
+- tier:
+- experiment type:
+- current status:
+- feasibility now:
+- why this row exists:
+- research question:
+- hypothesis:
+- comparators:
+- fixed conditions:
+- changed variables:
+- required metric(s):
+- minimal success criterion:
+- cost / runtime budget:
+- promotion rule:
+  - main text if:
+  - appendix if:
+  - omit if:
+- expected figure or table:
+- result artifact paths:
+- dependencies:
+- next action:
+
+## 7. Execution Frontier
+
+- rows ready now:
+- rows blocked now:
+- rows that must finish before the experiments section is stable:
+- rows that are appendix-only and can wait:
+- rows that are optional and should not block:
+
+## 8. Main-Text Gate
+
+Do not treat the experiments section as stable while any currently feasible row that is not merely `optional` or `dropped` remains unresolved.
+
+Every currently feasible non-optional row should be one of:
+
+- completed
+- analyzed
+- excluded with reason
+- blocked with reason
+
+## 9. Refresh Log
+
+After every completed, excluded, or blocked slice, reopen the matrix first and update it before selecting the next run.
+
+| Time | Exp id | What changed | Claim/highlight impact | Priority change | New next action |
+|---|---|---|---|---|---|
+| | | | | | |