qwen-sci 0.2.2__py3-none-any.whl

src/agents/idea_agent/agent/prompts/idea_fusion.py

@@ -0,0 +1,295 @@
+IDEA_FUSION_PROMPT = """
+You are a scientific idea fusion agent for LigAgent-Pro.
+
+== Topic == 
+{topic}
+
+== Current mature idea ==
+{mature_idea}
+
+== Refinement scope (optional) ==
+{refinement_scope}
+
+== Shared root domains ==
+{root_domains}
+
+== Fixed scientific intervention profile ==
+{scientific_intervention_profile}
+
+== Native scientific object schema ==
+{scientific_object_schema}
+
+== Analysis summary ==
+{analysis}
+
+You are given {mode_count} candidate ideas produced from different idea taste modes, all starting from the same prepared root context.
+
+== Candidate ideas (compact JSON) == 
+{candidate_ideas_json}
+
+Return STRICT JSON only:
+{{
+  "fused_idea": {{
+    "title": "string",
+    "abstract": "string",
+    "core_contribution": "string",
+    "method": "string",
+    "risks": "string",
+    "tags": ["string"],
+    "operator": "fusion_agent",
+    "target_defects": ["string"],
+    "rationale": "string",
+  "components": ["profile-native scientific object or relation"],
+    "component_explanations": {{
+      "component_name": "string"
+    }},
+    "root_domains": ["string"],
+    "paper_graph_context": "string",
+    "edit_plan": null,
+    "skill_metrics": {{}}
+  }},
+  "fusion_metadata": {{
+    "host_idea_mode": "string",
+    "selected_components": [
+      {{
+        "source_mode": "string",
+        "component": "string",
+        "role": "core_mechanism|supporting_object|evidence|boundary",
+        "why_selected": "string"
+      }}
+    ],
+    "rejected_components": [
+      {{
+        "source_mode": "string",
+        "component": "string",
+        "why_rejected": "string"
+      }}
+    ],
+    "conflicts_and_resolutions": [
+      {{
+        "conflict": "string",
+        "resolution": "string"
+      }}
+    ],
+    "fused_core_thesis": "string",
+    "why_stronger_than_each_input": "string",
+    "minimal_validation_plan": "string"
+  }}
+}}
+
+== Fusion rules ==
+- The top-level JSON value MUST be an object with exactly two keys: `fused_idea` and `fusion_metadata`.
+- `fused_idea` MUST appear first.
+- Build `fused_idea` first, then fill `fusion_metadata`.
+- Do NOT return a raw array.
+- Do NOT return a single selected component object as the top-level JSON.
+- Do NOT union all ideas together.
+- Select exactly one dominant core mechanism or scientific relation.
+- Other kept components must be supporting objects, not a second competing core mechanism.
+- When you reuse a component, copy its name exactly from `components`.
+- Protocol, guardrail, evaluator, or audit components cannot be the main novelty.
+- Generic wrapper or decision-layer components should almost never be the dominant core mechanism. Prefer the underlying scientific mechanism, object relation, process rule, or transferred principle instead.
+- If the current mature idea is not centered on a decision boundary, preserve that character in fusion. Do not elevate a wrapper into the fused thesis just because it is easy to combine.
+- If a generic decision layer mainly patches complexity created by another weak choice, reject it instead of carrying that patch into the fused idea.
+- If refinement_scope is provided, keep the fused novelty inside that scope. Reject candidates that look strong only because they move the contribution to a different subsystem.
+- Remove components that are redundant, conflicting, or only exist to patch complexity created by another weak choice.
+- Prefer components that strengthen novelty and impact while keeping the causal story coherent.
+- The final fused idea must read like one scientific claim with one clear explanatory chain.
+"""
+
+
+def render_idea_fusion_prompt(prompt: str, profile_id: str | None = None) -> str:
+    """Remove software-architecture priors from fusion prompts for non-CS profiles."""
+
+    if str(profile_id or "").strip().lower() == "computational_algorithmic":
+        return prompt
+    replacements = {
+        "component-level": "object-level",
+        "component edits": "object or relation edits",
+        "component names": "scientific object names",
+        "support modules": "supporting objects",
+        "support module": "supporting object",
+        "task-solving mechanism, representation, or update rule": "scientific mechanism, object relation, or process rule",
+        "task-solving mechanism, representation, update rule, or transferred principle": "scientific mechanism, object relation, process rule, or transferred principle",
+        "task-solving mechanism": "scientific mechanism",
+        "representation": "object description",
+        "update rule": "process rule",
+        "gate/router/controller/threshold-style": "generic wrapper or decision-layer",
+        "gate/router/controller/threshold": "generic wrapper or decision-layer",
+        "gate/router/controller": "generic decision layer",
+        "architecture": "scientific structure",
+        "one method with one clear causal chain": "one scientific claim with one clear explanatory chain",
+        "Specific computational role": "Specific profile-native role",
+    }
+    for source, target in replacements.items():
+        prompt = prompt.replace(source, target)
+    return prompt
+
+
+FUSION_REPAIR_INSTANTIATION_PROMPT = """
+You are materializing a local repair plan into a revised fused research idea.
+
+== Context ==
+Topic: {topic}
+Fixed root domains: {root_domains}
+Fixed scientific intervention profile:
+{scientific_intervention_profile}
+Refinement scope: {refinement_scope}
+Current fused idea: {parent_summary}
+Current fused components: {parent_components}
+Literature context: {paper_context}
+Memory bundle: {memory_bundle}
+{additional_retrieval_context}
+
+== Local Repair Plan ==
+Objective: {plan_objective}
+Target defects: {target_defects}
+Component edits:
+{component_edits}
+Validation protocols:
+{validation_protocols}
+Guardrails: {guardrails}
+
+== Your Task ==
+1. Keep the same overall thesis as the current fused idea.
+2. Realize only the local repair encoded by the component edits above.
+3. Treat component names in the repair plan as exact symbols. Do not rename or paraphrase them.
+4. Do not introduce extra structural components beyond what is already in the fused idea plus the explicit repair edits.
+5. Write a concrete title, abstract, core contribution, method, risks, and rationale for the repaired idea.
+6. Use the profile-native scientific object schema above; do not recast a non-computational intervention as software architecture.
+7. Avoid centering the repaired idea on a gate/router/controller/threshold component unless the current fused idea already depends on that mechanism as its core thesis.
+8. If `refinement_scope` is provided and not equal to `None`, keep the repaired novelty inside that scope.
+9. Provide a `component_mapping` only for names that literally appear in the repair plan. Since these names are already concrete, use identity mappings such as `"memory_updater": "memory_updater"`.
+10. Provide `component_role_explanations` only for concrete names that appear in `component_mapping`.
+
+Return STRICT JSON (no Markdown wrapping):
+{{
+  "title": "concise repaired idea title",
+  "abstract": "≤150 words abstract describing the repaired fused idea",
+  "core_contribution": "one focused statement of the repaired mechanism",
+  "method": "concrete methodology for the repaired fused idea using the exact component names from the repair plan",
+  "risks": "concrete failure modes and mitigation strategies",
+  "rationale": "2-3 sentences on how the local repair improves the fused idea",
+  "component_mapping": {{
+      "exact_component_name_1": "exact_component_name_1",
+      "exact_component_name_2": "exact_component_name_2"
+    }},
+  "component_role_explanations": {{
+      "exact_component_name_1": "Specific computational role in the repaired idea...",
+      "exact_component_name_2": "Specific computational role in the repaired idea..."
+    }},
+  "edit_reasons": [
+      "Reason 1: Why this local edit improves the fused idea...",
+      "Reason 2: Why this local edit resolves the target defect..."
+    ]
+}}
+"""
+
+
+FUSION_REPAIR_PROMPT = """
+You are repairing a fused research idea after referee evaluation.
+
+== Topic == 
+{topic}
+
+== Fixed root domains == 
+{root_domains}
+
+== Fixed scientific intervention profile ==
+{scientific_intervention_profile}
+
+== Current fused idea (JSON) == 
+{current_idea_json}
+
+== Current evaluation (JSON) == 
+{current_evaluation_json}
+
+== Source mode candidates (JSON) ==
+{candidate_ideas_json}
+
+== Available atomic edit operations == 
+{atomic_op_reference}
+
+Return STRICT JSON only:
+{{
+  "stop": false,
+  "stop_reason": "",
+  "target_defects": ["string"],
+  "guardrails": ["string"],
+  "component_edits": [
+    {{
+      "op": "REMOVE_COMPONENT|REPLACE_COMPONENT|REWIRE",
+      "component": "string",
+      "target": "string",
+      "condition": "string",
+      "details": "string",
+      "reason": "string"
+    }}
+  ]
+}}
+
+== Repair rules == 
+- Use ONLY these operations: REMOVE_COMPONENT, REPLACE_COMPONENT, REWIRE.
+- Do NOT use ADD_COMPONENT or ADD_PROTOCOL.
+- Do NOT increase the number of structural components.
+- Prefer one small local repair, not a rewrite of the whole idea.
+- At least one structural edit must be present unless you choose to stop.
+- Replacements should come from source-mode components or be tighter versions of the current role.
+- Prefer removing or replacing gate/router/controller/threshold-style components when they are auxiliary scaffolding rather than the true core mechanism.
+- If a gate/router/controller/threshold component is only patching complexity created elsewhere, treat that as evidence to simplify the architecture rather than preserve the patch.
+- If no likely-improving local repair exists, set stop=true.
+- Treat component names as STRICT symbols, not paraphrases.
+- When you mention an existing component from the current fused idea, copy its name exactly, character-for-character.
+- When you mention a component from a source-mode candidate, copy its name exactly, character-for-character.
+- Do NOT rename, summarize, translate, normalize, or slightly rewrite component names.
+- If you are not confident that an edit can be expressed with exact component names, set stop=true.
+
+== Field semantics ==
+- REMOVE_COMPONENT:
+  - "component" = the existing component to delete from the current fused idea.
+  - "target" should be "".
+- REPLACE_COMPONENT:
+  - "target" = the existing component in the current fused idea that will be replaced.
+  - "component" = the replacement component name.
+  - The replacement component may be copied from a source-mode candidate or be a tighter variant, but must still be written as one concrete component name.
+- REWIRE:
+  - "component" = the source or upstream component whose connection is being changed.
+  - "target" = the destination or downstream component / interface it should connect to.
+  - REWIRE changes topology only; it does not add a new component.
+
+== Valid examples ==
+- Valid REPLACE_COMPONENT:
+  {{
+    "op": "REPLACE_COMPONENT",
+    "component": "retrieval-grounded verifier",
+    "target": "static verifier",
+    "condition": "",
+    "details": "Replace static verifier with retrieval-grounded verifier",
+    "reason": "Improves mechanism grounding without expanding the architecture"
+  }}
+- Valid REMOVE_COMPONENT:
+  {{
+    "op": "REMOVE_COMPONENT",
+    "component": "redundant audit head",
+    "target": "",
+    "condition": "",
+    "details": "Remove redundant audit head",
+    "reason": "Reduces complexity caused by overlapping functionality"
+  }}
+- Valid REWIRE:
+  {{
+    "op": "REWIRE",
+    "component": "uncertainty estimator",
+    "target": "memory_updater",
+    "condition": "",
+    "details": "Rewire uncertainty estimator -> memory_updater",
+    "reason": "Lets the update rule react directly to uncertainty"
+  }}
+
+== Invalid patterns ==
+- Invalid: using ADD_COMPONENT or ADD_PROTOCOL.
+- Invalid: setting REPLACE_COMPONENT with "component" as the old name and "target" as the new name.
+- Invalid: inventing a near-match such as "dynamic uncertainty-aware updater" when the listed component is "uncertainty-aware updater".
+- Invalid: producing a plan that effectively adds a new structural component instead of locally repairing the existing fused idea.
+- Invalid: preserving a gate/router/controller/threshold component as the repaired core mechanism when it only acts as auxiliary scaffolding.
+"""

src/agents/idea_agent/agent/prompts/idea_introduction.py

@@ -0,0 +1,30 @@
+IDEA_INTRODUCTION_PROMPT = """
+You are an expert academic writer drafting the introduction section of a research paper for the following idea.
+
+== Topic == 
+{topic}
+
+== Mature idea anchor (optional; if empty, ignore) ==
+{mature_idea}
+
+== Idea payload (JSON) ==
+{idea}
+
+== Grounding papers (summaries extracted from our knowledge acquisition stage) ==
+{papers}
+
+Requirements & Constraints:
+- NARRATIVE FLOW: Follow a logical progression (e.g., Broad context -> Specific limitations/Gap -> Core proposed mechanism -> Hypotheses & Evaluation plan).
+- ANCHORING: If a mature idea anchor is provided, explicitly explain that the proposal is a refinement of that idea and identify the specific limitation being repaired.
+- GROUNDING: Explicitly reference at least two provided papers when motivating the gap. Highlight how your idea inherits or contrasts with their specific insights. (Use standard academic phrasing, e.g., "Building on the insights of [Paper Title]...").
+- COMPARISON BOUNDARY: If you compare against prior methods, only use the provided papers or the mature idea anchor. Never compare against internal MCTS intermediate artifacts, parent nodes, or temporary aliases.
+- STANCE: Treat the idea as a PROPOSAL. Emphasize methodological detail, target failure modes, and expected benefits.
+- ANTI-HALLUCINATION (CRITICAL): Do NOT invent or summarize experimental results unless explicitly present in the idea payload. Absolutely NO phrases claiming the idea "achieves", "outperforms", "improves by X", or "demonstrates superior performance". 
+- LENGTH: Return one focused paragraph of approximately 180-300 words and never exceed 500 words.
+- FORMATTING: Return the introduction as a single JSON string. Escape embedded quotes and newlines so the object remains valid JSON.
+
+Return STRICT JSON ONLY matching this schema:
+{{
+  "introduction": ""
+}}
+"""

src/agents/idea_agent/agent/prompts/idea_result_alignment.py

@@ -0,0 +1,39 @@
+IDEA_RESULT_ALIGNMENT_PROMPT = """
+You are the final public-facing alignment editor for a research idea before it is written to idea_result.json.
+
+== Topic ==
+{topic}
+
+== Mature idea anchor (optional; if empty, ignore) ==
+{mature_idea}
+
+== Refinement scope (optional; if empty, ignore) ==
+{refinement_scope}
+
+== Candidate idea payload (JSON) ==
+{idea}
+
+== Grounding papers ==
+{papers}
+
+Your job is to rewrite the candidate into a final public-facing idea description.
+
+Rules:
+- If a mature idea anchor is provided, present the candidate as a direct refinement of that anchor. The public narrative should make the relationship to the mature idea explicit.
+- Do NOT present internal MCTS intermediate artifacts, temporary aliases, or parent-node names as if they were user-facing baselines or prior methods.
+- If the candidate currently describes itself mainly as a repair of an intermediate node, rewrite it so it reads as a refinement of the mature idea instead.
+- Keep temporary internal names only if they remain essential to the final public method. Otherwise, fold them into a final name that is anchored in the mature idea and the actual mechanism.
+- In `abstract` and `method`, explicitly state what limitation of the mature idea is being repaired and how.
+- If contrasting with other methods, only contrast against the provided papers. Do NOT compare against internal search artifacts, parent nodes, or MCTS intermediate candidates.
+- Stay faithful to the actual mechanism in the candidate. Do not invent a different method.
+- Keep the method concrete and implementation-ready, but remove internal-search framing.
+
+Return STRICT JSON only:
+{{
+  "title": "public-facing paper title",
+  "abstract": "public-facing abstract aligned to the mature idea when present",
+  "core_contribution": "public-facing main mechanism claim",
+  "method": "public-facing method description aligned to the mature idea when present",
+  "risks": "public-facing risks"
+}}
+"""

src/agents/idea_agent/agent/prompts/input_interpreter.py

@@ -0,0 +1,52 @@
+INPUT_INTERPRETER_PROMPT = """
+You are the front-door interpreter for LigAgent.
+
+The user gives a single raw input string. Your job is to extract the research topic,
+zero or more mature idea records, and an optional refinement boundary:
+1. `topic` (required)
+2. `mature_ideas` (optional collection)
+3. `refinement_scope` (optional)
+
+Interpretation rules:
+- `topic` is the research problem or direction being studied. It must always be present in the output.
+- `mature_ideas` contains one record per independently stated, reasonably specific method anchor or mature seed idea. Do not split a single idea into cosmetic variants.
+- Keep the legacy `mature_idea` field as the first idea's short text when at least one record is present.
+- `refinement_scope` is a boundary on what part of the system may be changed. Only return it if the input clearly constrains the edit surface.
+- Prefer leaving `mature_idea` or `refinement_scope` empty over hallucinating them.
+- Distinguish user-explicit content from your own inference:
+  - `explicit` = the user clearly stated it.
+  - `inferred` = you can only reconstruct it approximately from hints.
+  - `empty` = not present.
+- Set `needs_grounding=true` whenever `mature_idea` or `refinement_scope` is missing or inferred and should later be grounded by survey/paper evidence.
+
+Raw input:
+{input_text}
+
+Return STRICT JSON only:
+{{
+  "topic": "required non-empty string",
+  "topic_source": "explicit|inferred",
+  "mature_ideas": [
+    {{
+      "idea_id": "stable short identifier",
+      "title": "short title",
+      "hypothesis": "central hypothesis",
+      "scientific_object": "object or process being studied",
+      "mechanism": "causal or formal mechanism",
+      "assumptions": ["..."],
+      "evidence_basis": ["..."],
+      "target_gap_ids": ["..."],
+      "refinement_scope": "allowed edit boundary",
+      "falsifier": "observation or result that would refute it",
+      "maturity_status": "mature|provisional",
+      "idea_source": "explicit|inferred",
+      "lineage": "survey|user_input|history|generated"
+    }}
+  ],
+  "mature_idea": "legacy first-idea text, may be empty",
+  "mature_idea_source": "explicit|inferred|empty",
+  "refinement_scope": "string, may be empty",
+  "refinement_scope_source": "explicit|inferred|empty",
+  "needs_grounding": true
+}}
+"""

src/agents/idea_agent/agent/prompts/keynote_ops.py

@@ -0,0 +1,78 @@
+KEYNOTE_SCORING_PROMPT = """
+You are scoring one survey-cited paper keynote for LigAgent.
+
+== Topic ==
+{topic}
+
+== Retrieval Query ==
+{rag_query}
+
+== Paper Title ==
+{title}
+
+== Keynote ==
+{keynote}
+
+Return STRICT JSON ONLY:
+{{
+  "score": 0
+}}
+
+Scoring rule:
+- integer only, 0 to 100
+- higher means more relevant and more important for grounding idea generation under the given topic/query
+- score based only on this keynote
+"""
+
+
+KEYNOTE_SINGLE_COMPRESSION_PROMPT = """
+You are compressing one survey-cited paper keynote for LigAgent.
+
+== Topic ==
+{topic}
+
+== Retrieval Query ==
+{rag_query}
+
+== Paper Title ==
+{title}
+
+== Keynote ==
+{keynote}
+
+Return STRICT JSON ONLY:
+{{
+  "summary": "",
+  "insight": ""
+}}
+
+Requirements:
+- `summary`: 1-2 factual sentences
+- `insight`: 1-3 concise sentence capturing the most decision-useful mechanism, limitation, or evaluation takeaway
+- use only the keynote
+"""
+
+
+KEYNOTE_GROUP_SUMMARY_PROMPT = """
+You are summarizing the lower-priority survey-cited paper keynotes for LigAgent.
+
+== Topic ==
+{topic}
+
+== Retrieval Query ==
+{rag_query}
+
+== Papers ==
+{papers}
+
+Return STRICT JSON ONLY:
+{{
+  "summary": ""
+}}
+
+Requirements:
+- produce one concise synthesis summary for the whole set
+- emphasize recurring mechanisms, limitations, and evaluation signals
+- do not enumerate every paper
+- use only the provided keynotes
+"""