@researai/deepscientist 1.5.16 → 1.6.0

package/src/skills/idea/references/current-board-packet-template.md

@@ -0,0 +1,61 @@
+# Current Board Packet Template
+
+Use this reference before widening the idea frontier.
+
+The goal is to compress all currently relevant durable state into one board surface so ideation does not continue from stale branches, stale narratives, or stale blockers.
+
+## Minimal fields
+
+- `incumbent`
+  - the current strongest line
+- `current_mainline`
+  - the route that should be treated as active now
+- `latest_decisive_result`
+  - the most recent result that actually changed route quality
+- `strongest_negative_evidence`
+  - the clearest recent reason the current line may be wrong or incomplete
+- `active_blocker`
+  - the current gating problem
+- `stale_routes_to_ignore`
+  - routes that should not be reopened by default
+- `next_decision_scope`
+  - what kind of choice ideation is actually making now
+- `budget_class`
+  - cheap-to-check vs expensive-to-check route class
+
+## Questions to answer
+
+1. What is the current mainline, really?
+2. Which result changed the route most recently?
+3. What is the strongest reason to distrust the current mainline?
+4. Which old routes should not be reopened unless new evidence appears?
+5. Is the next step about mechanism choice, objective correction, evaluator repair, or infrastructure?
+6. Is this a cheap-falsification pass or an expensive-validation pass?
+
+## Example shape
+
+```md
+# Current Board Packet
+
+- incumbent:
+  - current best durable line
+- current_mainline:
+  - the route that new candidates should be compared against
+- latest_decisive_result:
+  - the last result that changed route quality materially
+- strongest_negative_evidence:
+  - the strongest observed reason the current line may still be wrong
+- active_blocker:
+  - the specific thing preventing clean progress now
+- stale_routes_to_ignore:
+  - old routes that should not be reopened by default
+- next_decision_scope:
+  - mechanism / objective / measurement / infrastructure
+- budget_class:
+  - fast-check or slow-check
+```
+
+## Exit rule
+
+If this packet cannot be made coherent, do not widen the frontier yet.
+Route through `decision` or `intake-audit` first.

package/src/skills/idea/references/high-value-idea-sourcing.md

@@ -0,0 +1,119 @@
+# High-Value Idea Sourcing
+
+Use this reference when the ideation pass is in danger of starting from a clever technique rather than an important contradiction.
+
+The goal is to find a route that is both worth doing and realistically testable, not just to swap one module for another.
+
+## 1. Start from the important contradiction
+
+Before asking "what mechanism should we add?", ask:
+
+- what core problem in this area is still unresolved?
+- why do existing methods still fail to solve it cleanly?
+- which observation, conflict, or failure case does the mainline still not explain?
+
+Prefer starting from one of these contradiction sources:
+
+- unexplained phenomenon
+  - a stylized fact, anomaly, or recurring pattern the current explanation does not fit
+- failure region
+  - a task, subgroup, regime, or deployment condition where the mainline reliably breaks
+- evaluation distortion
+  - benchmark scores look strong but real-world use or stronger diagnostics disagree
+- theoretical rupture
+  - the method works empirically, but the mechanism or theory remains weak or conflicting
+- neglected problem slice
+  - an important cross-domain, subgroup, condition, or setting is still thinly studied
+
+If the pass cannot name one important contradiction or bottleneck, do not start from a model swap.
+
+## 2. Decompose novelty
+
+Do not treat novelty as "never seen before".
+A serious idea may be novel because it offers:
+
+- a new problem definition
+- a new perspective or framing
+- a new mechanism
+- a new method
+- a new dataset or setting
+- a new evaluation lens
+- a new boundary condition
+
+When scoring candidates, explicitly label the dominant novelty source.
+If the novelty source cannot be named, the idea is usually weak or too vague.
+
+## 3. Use multiple idea-source methods
+
+Good candidate routes often come from one or more of these search lenses:
+
+- gap-driven
+  - what important thing is still uncovered or weakly evidenced?
+- anomaly-driven
+  - what keeps happening that the current explanation does not fit?
+- bottleneck-driven
+  - what single bottleneck most limits useful progress?
+- assumption-reversal
+  - which default field assumption might be wrong or too narrow?
+- cross-domain transfer
+  - what neighboring field solves the same structural problem differently?
+- writing-to-think
+  - what becomes obvious only after forcing a one-page problem definition and claim sketch?
+
+Do not rely on only one source lens, especially if it produces several same-family ideas.
+
+## 4. Ask mechanism questions early
+
+Depth usually comes from mechanism, not only effect size.
+Before promotion, force the candidate to answer:
+
+- why should this work?
+- for whom or under what condition should it work?
+- under what condition should it fail?
+- what mechanism is changing, rather than which surface metric is moving?
+
+Every serious candidate should make explicit:
+
+- core hypothesis
+- mechanism sketch
+- strongest falsification experiment
+
+If these remain fuzzy, the idea is not yet strong enough for promotion.
+
+## 5. Prefer ideas with failure value
+
+A strong idea is not only promising when positive.
+It should also still teach something if it fails.
+
+Ask:
+
+- if the route fails, will that eliminate a tempting but weak line?
+- will the failure teach us something about the bottleneck, mechanism, or evaluation?
+- is the failure interpretable, or would it only create noise?
+
+Low-information failure routes should be filtered out early.
+
+## 6. Use this as a pre-brainstorming check
+
+Before widening the frontier, make sure the active pass can answer:
+
+1. What is the important contradiction or bottleneck?
+2. Why is it important to the real objective?
+3. What kind of novelty is plausible here?
+4. What mechanism-level explanation is being proposed?
+5. What is the strongest falsification path?
+
+If these answers are weak, stay in problem definition and history search rather than generating a larger idea slate.
+
+## 7. Local-optimum lock-in check
+
+Before promotion, ask whether the pass is only polishing the current line because it is familiar, cheap, or already half-implemented.
+
+Challenge the hidden assumptions behind the incumbent explicitly:
+
+- what assumption about the bottleneck, data, objective, evaluator, or system boundary are we currently treating as fixed?
+- which of those assumptions might be wrong, too narrow, or inherited from convenience rather than evidence?
+- if that assumption were false, would the current candidate family still be the right place to search?
+- what non-local alternative or assumption-reversal route should remain alive long enough to avoid local-optimum lock-in?
+
+If the current frontier cannot answer these questions, do not treat the easiest continuation of the mainline as the best idea by default.

package/src/skills/idea/references/idea-generation-playbook.md

@@ -5,6 +5,18 @@ Use this reference when the `idea` stage needs a concrete creation flow for prod
 The goal is not a bag of clever mechanisms.
 The goal is one clear next research object plus a durable record of what was deferred or rejected.
 
+## 0. Finish a real literature pass before ideation
+
+Do not start serious ideation from taste alone.
+Before generating a candidate slate, the current pass should already have:
+
+- a durable survey refresh
+- direct-field frontier coverage
+- strongest nearby prior-work coverage
+- at least one adjacent-domain mechanism pass when the bottleneck may transfer
+
+If this gate is not met, stay in literature work rather than pretending the idea phase has started.
+
 ## 1. Start from one limitation card
 
 Write one limitation card before generating ideas:
@@ -60,6 +72,8 @@ Default target:
 
 Prefer family-level differences over small parameter or implementation variations.
 If several candidates are really the same family with minor tweaks, merge them.
+Bias toward routes that could materially change the capability boundary, claim boundary, or paper value.
+Do not keep an obvious small tweak in the serious slate unless it remains competitive after the literature pass.
 
 For each serious candidate, record:
 
@@ -69,9 +83,13 @@ For each serious candidate, record:
 - strongest prior-work overlap
 - expected evidence burden
 - likely falsification path
+- why this is more than a cosmetic delta from the baseline or closest prior work
 
 ## 6. Select one and ledger the rest
 
+Before formal promotion, write a compact pre-idea draft for each serious surviving candidate.
+Use `pre-idea-draft-template.md`.
+
 At the end of the pass, produce three durable buckets:
 
 - selected
@@ -86,6 +104,7 @@ For rejected ideas, write one-line rejection reasons such as:
 - weak value if positive
 - too broad for current compute or codebase
 - lower priority than the selected route
+- decorative tweak with weak research value relative to broader surviving routes
 
 ## 7. Exit criterion
 
@@ -96,5 +115,7 @@ The pass is complete only when the output contains:
 - one minimal experiment concept
 - one abandonment condition
 - deferred and rejected rationale recorded durably
+- explicit evidence that the selected route survived literature-based novelty checking rather than only internal brainstorming
+- a pre-idea draft or equivalent challenge memo for the serious surviving candidates before final submission
 
 If the result is still a bag of possibilities, stay in `idea`.

package/src/skills/idea/references/idea-thinking-flow.md

@@ -113,6 +113,12 @@ Before promotion, challenge the idea:
 
 This check is especially important for attractive cross-domain ideas.
 
+Also ask:
+
+- are we staying near the current line only because it is familiar or already partially built?
+- what hidden assumption has gone unchallenged in the current frontier?
+- what assumption-reversal or outside-family route would break a local-optimum lock if the current framing is wrong?
+
 ## 10. End with one clear research object
 
 The selected output should be one clear research object:

package/src/skills/idea/references/literature-survey-template.md

@@ -15,6 +15,7 @@ The purpose is to make related-work coverage durable, searchable, and reusable s
   - related and usable papers found so far
   - how many are direct task-modeling papers
   - how many are adjacent but translatable papers
+  - how many are cross-domain mechanism papers
   - whether the hard floor of at least `5` and usually `5-10` usable papers has been satisfied
 - why the survey is being run now
   - first idea build
@@ -63,6 +64,7 @@ Split the papers into:
 - core papers
 - closest competitors
 - adjacent inspirations
+- cross-domain transferable mechanisms
 - watchlist / uncertain relevance
 
 For each paper, include:
@@ -136,6 +138,7 @@ Close with:
 - the best surviving candidate ideas
 - the rejected ideas and why
 - what still needs more search before selection
+- whether the remaining serious ideas are breakthrough-seeking, clearly differentiated, or merely incremental
 - whether the stage is ready for `idea` selection, more `scout`, or a user decision
 
 ## 10. Citation-ready shortlist for the selected idea

package/src/skills/idea/references/objective-contract-template.md

@@ -0,0 +1,54 @@
+# Objective Contract Template
+
+Use this reference at the start of an `idea` pass whenever the real target might differ from the easiest available surrogate.
+
+The goal is to prevent ideation from drifting into "optimize what is measurable" when the real objective is narrower, more fragile, or more deployment-constrained.
+
+## Minimal fields
+
+- `primary_objective`
+  - the real target the next route should improve
+- `scoreboard_metric`
+  - the single metric or ranking surface the quest is actually judged by
+- `trusted_proxy_metrics`
+  - the proxies that are allowed to influence direction choice
+- `false_progress_signals`
+  - local improvements that must not be mistaken for route health
+- `hard_constraints`
+  - constraints that invalidate a route even if metrics improve
+
+## Questions to answer
+
+1. What metric or region of behavior actually matters most?
+2. Which proxies are trustworthy, and why?
+3. Which proxies are only convenience signals rather than real progress?
+4. What kind of apparent improvement would still count as failure?
+5. Which leakage, deployment, submission-time, or comparability constraints must remain inviolable?
+
+## Example shape
+
+```md
+# Objective Contract
+
+- primary_objective:
+  - Improve the real target metric, not just the easiest averaged surrogate.
+- scoreboard_metric:
+  - The metric or ranking surface that actually decides whether the route is better.
+- trusted_proxy_metrics:
+  - Proxy A because it tracks the head of the decision surface.
+  - Proxy B because it reflects the main deployment tradeoff.
+- false_progress_signals:
+  - Lower average loss without improvement on the real decision region.
+  - Better offline score using a feature that will not exist at deployment time.
+- hard_constraints:
+  - No submit-time unavailable features.
+  - No leakage-prone labels or post-hoc ranking information in training.
+```
+
+## Exit rule
+
+Do not widen the frontier until this contract is explicit enough to distinguish:
+
+- true progress
+- false progress
+- invalid routes

package/src/skills/idea/references/outline-seeding-example.md

@@ -11,6 +11,62 @@ Before analysis begins, seed one lightweight but structured outline candidate so
 ```json
 {
   "title": "Evidence-First Outline Seed",
+  "paper_view": {
+    "paper_type": "full_empirical",
+    "outline_maturity": "idea_seed",
+    "working_title": "Evidence-First Outline Seed",
+    "narrative_strategy": {
+      "central_thesis": "The method should improve the target setting by repairing a specific evidence gap.",
+      "central_insight": "The reusable lesson is still tentative and must be tested by the main result and follow-up analyses.",
+      "reader_takeaway": "If the idea works, readers should learn when the repair is useful and where it fails."
+    },
+    "story_spine": {
+      "problem": "The current baseline fails in a diagnosable regime.",
+      "gap": "Existing evidence is not enough to explain or repair that regime.",
+      "method": "A targeted repair is added.",
+      "main_result": "To be filled by the main benchmark comparison.",
+      "scope_limit": "The claim is limited until ablation and boundary checks are complete."
+    },
+    "core_claims": [
+      {
+        "claim_id": "C1",
+        "claim": "The method improves the accepted target metric under the planned evaluation.",
+        "scope": "Current benchmark, model, and baseline setting.",
+        "evidence_needed": ["run-main-001"],
+        "what_would_falsify_it": "No gain or a gain that disappears under the accepted comparison contract."
+      }
+    ],
+    "method_abstraction": {
+      "intuition": "The method should help because it targets the missing evidence rather than changing unrelated parts of the system.",
+      "mechanism_steps": ["Identify the weak regime", "Apply the targeted repair", "Compare under the accepted metric contract"]
+    },
+    "evaluation_plan": {
+      "setting": "Accepted benchmark and baseline comparison",
+      "datasets_or_benchmarks": [],
+      "baselines": [],
+      "metrics": [],
+      "controlled_factors": ["same data split", "same metric contract"]
+    },
+    "analysis_plan": [
+      {
+        "analysis_id": "A1",
+        "title": "Component ablation",
+        "analysis_role": "component ablation",
+        "reviewer_question": "Is the gain caused by the proposed component?",
+        "claim_links": ["C1"],
+        "target_display": "Ablation table",
+        "main_or_appendix": "main_text",
+        "failure_interpretation": "If the gain remains, weaken the mechanism claim."
+      }
+    ],
+    "evidence_grounding": {
+      "observed_facts": [],
+      "allowed_interpretations": [],
+      "must_not_claim": ["Do not claim generality before robustness and boundary checks."],
+      "evidence_gaps": ["main benchmark result", "ablation", "boundary analysis"]
+    },
+    "analysis_budget_waiver": "Idea seed: full 4-8 analysis plan should be expanded after the main result."
+  },
   "research_questions": [
     "RQ1: Does the method outperform the accepted baseline?",
     "RQ2: Which component is responsible for the gain?",

package/src/skills/idea/references/pre-idea-draft-template.md

@@ -0,0 +1,105 @@
+# Pre-Idea Draft Template
+
+Use this reference after bounded brainstorming and before formal idea submission.
+
+Default durable path: `artifacts/idea/pre_idea_drafts/<candidate_id>.md`.
+
+The goal is to force each serious candidate through one compact written stress test before it can be promoted.
+This draft is not the final selected-idea submission.
+It is the last place to expose hidden assumptions, local-optimum lock-in, and the strongest rejection case while the route is still cheap to discard.
+
+## When to write it
+
+Write a pre-idea draft for each serious surviving candidate.
+Normally this means the top `1-3` candidates after the raw slate has been collapsed.
+
+Do not spend this draft effort on every raw idea.
+The purpose is to challenge the finalists, not to create paperwork for weak candidates that should already have been filtered out.
+If a candidate survives multiple revisions in the same pass, keep updating the same durable draft path instead of scattering ad hoc filenames.
+
+## Minimal fields
+
+- `candidate_id`
+- `candidate_family`
+- `one-sentence claim`
+- `targeted contradiction or bottleneck`
+- `why_now`
+- `dominant novelty type`
+- `closest prior work`
+- `hidden assumptions`
+- `local_optimum_lock_in_risk`
+- `outside_family_or_assumption_reversal_alternative`
+- `strongest rejection case`
+- `core hypothesis`
+- `strongest falsification path`
+- `minimal experiment`
+- `abandonment condition`
+- `promotion verdict`
+
+## Questions the draft must answer
+
+1. What exact contradiction, anomaly, or bottleneck is this candidate targeting?
+2. Why is this candidate more than a decorative tweak?
+3. What assumptions about the bottleneck, data, objective, evaluator, or systems boundary must hold for it to work?
+4. Which of those assumptions is most fragile or least justified?
+5. Are we favoring this candidate because it is actually best, or because it is familiar, already partially implemented, or easiest to ship?
+6. What outside-family or assumption-reversal route would still be plausible if the current framing is wrong?
+7. What is the strongest reason to reject this candidate right now?
+8. What is the cheapest falsification path?
+9. What result would immediately demote or kill this route?
+
+## Recommended shape
+
+```md
+# Pre-Idea Draft: <candidate_id>
+
+- candidate_family:
+- one-sentence claim:
+- targeted contradiction or bottleneck:
+- why_now:
+- dominant novelty type:
+
+## Literature grounding
+
+- closest prior work:
+- what remains unresolved:
+- why this is not just a local tweak:
+
+## Hidden assumptions
+
+- assumption 1:
+- assumption 2:
+- most fragile assumption:
+
+## Local-optimum lock-in check
+
+- why this route is currently attractive:
+- what part of that attraction may just be convenience or incumbent inertia:
+- outside-family or assumption-reversal alternative still worth keeping alive:
+
+## Rejection case
+
+- strongest reason to reject now:
+- strongest competing alternative:
+- what evidence would make that alternative preferable:
+
+## Testability
+
+- core hypothesis:
+- strongest falsification path:
+- minimal experiment:
+- abandonment condition:
+
+## Draft verdict
+
+- promote / defer / reject:
+- reason:
+```
+
+## Exit rule
+
+Do not promote a candidate into the formal selected-idea package until this draft makes the route look stronger than:
+
+- the incumbent continuation
+- the easiest small tweak
+- at least one outside-family or assumption-reversal alternative

package/src/skills/idea/references/related-work-playbook.md

@@ -2,6 +2,22 @@
 
 Use this reference during the `idea` stage when you need a deeper and more explicit process for literature scouting, novelty checking, and value judgment.
 
+For a broader history-aware search before final narrowing, also read `research-history-playbook.md`.
+
+## 0. Broad search policy
+
+Search should be broad enough to map the field and its history, not only to confirm the first attractive candidate.
+It should also be broad enough to surface cross-domain mechanisms that may transfer into the current task, evaluation setup, or systems bottleneck.
+
+If DeepXiv is available under the runtime contract, prefer it for broad paper-centric discovery, citation expansion, and shortlist triage.
+If DeepXiv is unavailable, use search engines directly and keep the same breadth target:
+
+- recent papers
+- foundational papers
+- turning-point papers
+- citation chaining
+- adjacent-domain mechanism search
+
 ## 1. Search objective
 
 The goal is not to collect random citations.
@@ -11,6 +27,7 @@ The goal is to answer:
 - what is the strongest nearby prior work?
 - what remains unresolved or weakly defended?
 - does the candidate still have novelty or at least research value?
+- are there adjacent-domain methods that solve a structurally similar limitation and could be translated here?
 
 ## 2. Query families
 
@@ -27,21 +44,56 @@ Use several query families and refine them iteratively:
 
 ## 2.1 Source order and de-dup protocol
 
-Before opening a fresh broad search, check durable memory first:
+Before opening a fresh broad search, check durable memory first. If the runtime prompt explicitly says `cross_quest_recall_enabled: true`, follow the injected cross-quest recall policy before going outside.
 
 1. recent quest `papers`, `ideas`, and `knowledge`
 2. recent global `papers`, `knowledge`, and `templates`
-3. `memory.search(...)` with the baseline name, task, dataset, mechanism, and current idea labels
+3. `memory.search(...)` with the baseline name, task, dataset, mechanism, and current idea labels — note this is substring match, so issue several single-keyword queries (`bc8`, `RAG`, `verifier`) instead of one long phrase
+4. when cross-quest recall is enabled, apply the exact sibling-quest and quirks-file paths from the runtime prompt
 
 Then search externally for the missing neighborhood:
 
 1. arXiv for direct paper discovery
 2. citation trails for nearest-neighbor expansion
 3. broader web or repo search for implementation overlap and follow-up work
+4. adjacent-domain mechanism search when the direct neighborhood looks saturated or overly incremental
 
 The goal is not to search the same cluster from zero every time.
 The goal is to reuse what the quest already knows and only spend new search budget on gaps, recency, or unresolved overlap.
 
+## 2.2 History-aware pass
+
+Before claiming novelty, identify:
+
+- seminal papers
+- paradigm-shift papers
+- current mainstream or SOTA papers
+
+Then use both:
+
+- backward citation chaining
+- forward citation chaining
+
+to reconstruct the problem lineage rather than only the current keyword cluster.
+
+## 2.3 Cross-domain translation pass
+
+Before you conclude that the best route is a small local tweak, search at least one adjacent domain that faces a structurally similar bottleneck.
+
+Useful prompts:
+
+- same failure mode in a different task family
+- same mechanism used under a different evaluator or deployment constraint
+- same resource or infrastructure bottleneck solved in another systems or modeling setting
+- a theory, optimization, or measurement idea that may be portable even if the task is different
+
+For each promising adjacent paper, record:
+
+- why the bottleneck is structurally similar
+- what part of the mechanism may transfer
+- what part probably does not transfer directly
+- whether the translation would still be non-trivial and worth testing here
+
 ## 3. Coverage targets
 
 Try to cover these buckets before final selection:
@@ -51,9 +103,12 @@ Try to cover these buckets before final selection:
 - nearest mechanism-level neighbors
 - papers focused on the same failure mode
 - papers with the same task but different mechanism families
+- adjacent-domain papers whose mechanism, objective, or analysis logic can plausibly transfer into the current task
 
 For a normal selected-idea decision, the survey should durably cover at least `5` and usually `5-10` related and usable papers.
 Prefer direct task-modeling papers first; if that pool is truly small, fill the rest with the closest adjacent and translatable work instead of pretending the literature is empty.
+Do not stop at the direct field if it only yields small variations of the same idea family.
+Run at least one deliberate cross-domain pass whenever the bottleneck might be shared with another domain.
 
 If the area is active, recent work matters a lot.
 If the area is stable, seminal work may matter more than recency.
@@ -89,6 +144,15 @@ Recommended columns:
 Before stopping, also leave behind a literature survey report.
 Prefer the structure in `literature-survey-template.md`.
 
+For harder cases, also keep a lineage-style table with:
+
+- research problem
+- core assumption or mechanism
+- method and data
+- main conclusion
+- explicit limitation
+- implicit limitation you detect
+
 ## 6. Novelty triage logic
 
 Ask these questions in order:
@@ -104,6 +168,11 @@ Possible verdicts:
 - `incremental but valuable`
 - `not sufficiently differentiated`
 
+Default preference:
+
+- first look for a route that is `novel` and still executable
+- accept `incremental but valuable` only when the value is concrete and larger routes were honestly ruled out
+
 ## 7. Research-value checks
 
 Even if novelty is limited, a direction may still be worth doing when it offers:
@@ -126,13 +195,17 @@ Watch for these traps:
 - declaring novelty from implementation detail rather than research claim
 - mistaking recency for relevance
 - importing a concept from another domain without proving the translation makes sense here
+- failing to look outside the immediate field and therefore rediscovering a nearby but more ambitious route too late
 - treating a paper title match as evidence without checking dataset and metric overlap
+- reading only the last few years and mistaking recency for centrality
+- skipping citation chaining and therefore missing the evolution of the question itself
 
 ## 9. Exit condition
 
 The related-work search is good enough to stop when:
 
 - the strongest obvious nearby papers are mapped
+- at least one explicit cross-domain or adjacent-domain translation pass has been completed when the bottleneck plausibly allows it
 - the closest-prior-work table is complete enough to compare seriously
 - each top candidate has an explicit novelty or value verdict
 - the usable-paper floor for the selected idea has been satisfied or the shortage is explicitly documented