investigate · diff
git:20260502.5bc84e8 to git:20260912.5e86435
129 added, 216 removed. Audit A to A.
---
name: investigate
- description: "Run investigation cycles that test hypotheses through proof verification, counterexample search, or security analysis, with keep-or-discard discipline. Use when asked to investigate, verify, prove, or disprove claims."
+ description: "This skill tests hypotheses with proofs, counterexamples, and analysis. You use it to verify, prove, or refute research claims."
user-invocable: true
argument-hint: "[number-of-cycles]"
license: Apache-2.0
- compatibility: "Best on hosts with parallel-subagent primitives (e.g. Claude Code's Agent tool); falls back to sequential execution otherwise."
+ compatibility: "The host should support parallel subagents. This skill uses sequential execution when the host cannot run subagents."
---
# Investigate
- The core research loop. Run N investigation cycles, each testing a hypothesis and applying keep-or-discard discipline.
+ You must read and apply the [language rules](../reaper/references/language.md) before you write any output.
+ Each cycle tests one hypothesis and returns a keep or discard verdict.
+
## Usage
- Invoke this skill by name with an optional cycle count. On slash-command hosts, prefix with `/` (e.g. `/investigate 10`).
+ You invoke this skill by name with an optional cycle count. The default count is 5. Slash-command hosts use `/investigate 10`.
```
- # Run 10 investigation cycles
investigate 10
-
- # Default: 5 cycles
investigate
```
- Default: 5 cycles if no argument given.
-
## Inputs
- **Always read** before starting:
- - `reaper-workspace/notes/problem-statement.md` — model assumptions and property definitions
- - `reaper-workspace/notes/ideas.md` — the ideas to investigate
- - `reaper-workspace/notes/current-understanding.md` — the "branch tip" of accumulated knowledge
- - `reaper-workspace/notes/results.md` — what's been tried and what happened
-
- **Lazy-load only when needed** (do not read upfront — load only if a cycle's hypothesis requires it or the "when stuck" protocol calls for it):
- - `reaper-workspace/notes/paper-summary.md` — the source paper (if provided)
- - `reaper-workspace/notes/literature.md` — known prior work (organized by same-goal and same-approach)
- - `reaper-workspace/papers/` — downloaded PDFs and per-paper notes (`<id>-notes.md`) from the literature review
- - `../reaper/references/methodology.md` — proof/analysis patterns
-
-
- ## The Batch Loop
-
- Investigation runs in **batches**, not sequential cycles. Independent hypotheses are investigated in parallel by default; sequential execution is the fallback when dependencies exist.
-
- ### Overview: Plan → Dispatch → Merge → Repeat
-
- ```
- while cycles_remaining > 0 and not converged:
- Plan: read ideas.md + notes/results.md → dependency graph → batch of independent hypotheses
- Dispatch: spawn one subagent per hypothesis (parallel, in one message)
- Merge: collect results → update notes/results.md → integrate "keep" insights into current-understanding.md
- ```
-
- ### Plan Batch
-
- 1. Read `ideas.md` and `notes/results.md`
- 2. Identify all **unresolved** hypotheses. Check `notes/results.md` to avoid repeating failed approaches.
- 3. Build a dependency graph: does resolving H2 require knowing the outcome of H1? If so, H2 depends on H1.
- 4. Select the largest set of **independent** hypotheses that can run concurrently. Cap the batch size at `cycles_remaining`.
- 5. Allocate cycle numbers: pre-assign a contiguous range per subagent (e.g., batch 1 gets 001-003, batch 2 gets 004-006). Each subagent gets one or more consecutive numbers from its range.
- 6. If all remaining hypotheses form a dependency chain, the batch size is 1 — this is the **sequential fallback** (see below).
- 7. If all hypotheses are resolved, **stop and return control** to the orchestrator. The orchestrator will call `/brainstorm` to generate new ideas if needed.
-
- ### Dispatch Batch
-
- Spawn one subagent per hypothesis in the batch using your host's parallel-subagent mechanism (e.g. Claude Code's `Agent` tool, or the equivalent task/spawn primitive on other hosts; if the host has no parallel primitive, fall back to sequential execution). **Launch all subagents in a single message** for true parallelism. Each subagent receives:
-
- - Its assigned cycle number(s)
- - The hypothesis to investigate
- - A **hypothesis-relevant excerpt** of `current-understanding.md` (read-only for the duration of the batch) — extract only the 2-3 findings most relevant to this subagent's hypothesis, not the full file. This keeps subagent context lean. Include a note: "For additional context, see current-understanding.md."
- - The full single-cycle protocol (Steps A–E below)
- - Instructions to return: cycle rows for `notes/results.md`, keep/discard verdict, and if keep: the insight to merge
-
- **Context efficiency**: Do NOT send the full `current-understanding.md` to every subagent. Instead, read it once in the main agent, identify which findings are relevant to each hypothesis, and send only those. A typical excerpt is 200-500 words vs 2000-5000 for the full file.
-
- Each subagent runs the single-cycle protocol independently:
-
- #### Step A: Create Investigation Directory
-
- If this cycle revisits a hypothesis that already has an investigation directory, **reuse that directory** — update its `analysis.md` and `proof.md` inline rather than creating a new directory. The cycle number in the directory name stays the same (the original); the `notes/results.md` row will be updated with the new cycle number.
-
- For a new hypothesis, create `reaper-workspace/investigations/NNN-<slug>/` where:
- - `NNN` is the assigned zero-padded cycle number (001, 002, ...)
- - `<slug>` is a short descriptor (e.g., `proof-lemma3`, `counterex-2party`, `alt-reduction`)
+ You always read these files:
- #### Step B: Investigate
+ - `reaper-workspace/notes/problem-statement.md`
+ - `reaper-workspace/notes/ideas.md`
+ - `reaper-workspace/notes/current-understanding.md`
+ - `reaper-workspace/notes/results.md`
- Do the actual research. This is the core intellectual work. Depending on the hypothesis:
+ You read these sources only when a hypothesis needs them or progress stops:
- - **Proof verification**: Check each step of an existing proof. Look for gaps, implicit assumptions, boundary cases. Consult `../reaper/references/methodology.md` for patterns.
- - **Proof attempt**: Try to prove the claim. Start with the simplest approach. If it works, check if a simpler proof exists. All proofs must follow the formal proof structure below.
- - **Counterexample search**: Try to disprove the claim. Start small (2 parties, 1 round). Construct a specific adversary strategy and execution trace.
- - **Security analysis**: Enumerate threat models, check if reductions go through, verify simulator constructions. Security proofs must follow the formal proof structure below.
- - **Comparison**: Compare approaches along specific dimensions (complexity, assumptions, properties).
- - **Performance analysis**: Prove complexity bounds, communication costs, round complexity, or other quantitative metrics. All performance claims must follow the formal proof structure below.
+ - `reaper-workspace/notes/paper-summary.md`, if it exists.
+ - `reaper-workspace/notes/literature.md`
+ - `reaper-workspace/papers/`, including `<id>-notes.md` files.
+ - `../reaper/references/methodology.md`
- Write all work — reasoning, attempts, dead ends, insights — to `reaper-workspace/investigations/NNN-<slug>/analysis.md`. If revisiting, **edit the existing `analysis.md` inline** — update conclusions, revise reasoning, and integrate new findings into the existing structure rather than appending a new section. The file should always reflect the current best understanding of this hypothesis.
+ ## Batch Loop
- ##### Intra-Cycle Parallelism
+ You test independent hypotheses in parallel batches when the host supports subagents. You use sequential execution for dependent hypotheses or hosts without subagents. Each batch has three stages: plan, dispatch, and merge. You repeat batches while cycles remain and unresolved hypotheses exist.
- Within a single cycle, subagents MAY spawn sub-subagents for concurrent attack:
+ ### Plan
- - **Proof + counterexample race**: When a hypothesis could go either way, run proof-attempt and counterexample-search as parallel sub-subagents. The first to reach a definitive result wins; the other's partial work is logged in the investigation directory.
- - **Parallel literature search**: When stuck and searching for related work, run IACR + arXiv + WebSearch as parallel sub-subagents, then merge results.
+ 1. You read `ideas.md` and `notes/results.md`.
+ 2. You identify unresolved hypotheses. You check previous results to avoid repeated failed approaches.
+ 3. You map dependencies between hypotheses.
+ 4. You select the largest independent set that fits the remaining cycle count.
+ 5. You assign consecutive cycle numbers to each subagent without overlap.
+ 6. You use a batch of one if all remaining hypotheses form a dependency chain.
+ 7. If all hypotheses are resolved, you return to the orchestrator. It can invoke `brainstorm` for more ideas.
- Use intra-cycle parallelism when the hypothesis is genuinely uncertain. If prior cycles strongly suggest the claim is true (or false), prefer the targeted approach.
+ ### Dispatch
- ##### Formal Proof Structure
+ You start one subagent per hypothesis with the host's parallel tool. You start the batch in one message when the host permits this. You give each subagent these inputs:
- For theoretical research (proving properties, security guarantees, or performance metrics), every claim must be stated and proved formally. Write proofs in `reaper-workspace/investigations/NNN-<slug>/proof.md` using this structure:
+ - Its cycle numbers and hypothesis.
+ - Two or three relevant findings from `current-understanding.md`, usually 200-500 words.
+ - A pointer to `current-understanding.md` for additional context.
+ - The single-cycle procedure in Steps A-E.
+ - A request for result rows, a verdict, and any keep finding to merge.
- ```markdown
- ## Theorem/Lemma/Proposition N: <name>
+ You do not send the full current-understanding file to every subagent. Subagents read shared notes without changing them during the batch.
- **Statement.** <precise mathematical statement of the claim>
+ ### Step A: Create the Investigation Directory
- **Assumptions.**
- - <each assumption listed explicitly, e.g., threat model, computational hardness, network model>
+ For a new hypothesis, you create `reaper-workspace/investigations/NNN-<slug>/`. `NNN` is the assigned cycle number with leading zeros, such as `001`. `<slug>` is a short description, such as `proof-lemma3`.
- **Proof.**
- <the proof body — each logical step explicit and justified>
+ For a repeated hypothesis, you reuse its existing directory. You keep the original directory number. You edit `analysis.md` and `proof.md` in place. The result row uses the new cycle number.
- 1. <step> *(by <justification: definition / assumption / prior lemma / cited result>)*
- 2. <step> *(by ...)*
- ...
+ ### Step B: Investigate
- ∎
+ You select the method for the hypothesis's immediate task:
- **Proof technique:** <e.g., reduction, induction, simulation, hybrid argument, game hopping>
- ```
+ - **Proof verification:** You check an existing proof for missing steps, hidden assumptions, and boundary errors.
+ - **Counterexample search:** You construct an execution that violates a claim. You start with small cases.
+ - **Comparison:** You compare approaches under the same specified conditions.
+ - **New proof:** You construct an argument for a claim without an existing proof to check or a counterexample to build.
- Consult `../reaper/references/methodology.md` for the proof techniques catalog, reduction quality gate, and performance sanity checks. State the chosen proof technique in the proof header. If it doesn't work after a genuine attempt, log which technique failed and why, then try an alternative in the next cycle.
+ For a new proof, you use `security-analysis` for security claims and `performance-analysis` for cost claims.
+ You use `proof-attempt` for other claims. You check whether the proof can use fewer steps or assumptions.
- Requirements for formal proofs:
+ You write reasoning, attempts, failed approaches, and findings to the investigation's `analysis.md`. On a revisit, you revise the existing text to show the current understanding.
- - **Properties**: State as a formal predicate. Prove under stated assumptions.
- - **Performance metrics**: State as a formal claim. Prove by construction or reduction. Distinguish worst/average/amortized.
- - **Security properties**: State the definition, construct the reduction, prove the bound. Make it tight or state the gap.
- - **Impossibility results**: State what's impossible, under which model. Prove by contradiction or reduction.
+ #### Parallel Work Within a Cycle
- If a proof attempt fails or has gaps:
- - Document exactly where the proof breaks down
- - State what additional assumption would close the gap
- - Log the cycle as `inconclusive` with the gap described
+ If the result is uncertain, you can start separate proof and counterexample subagents. The first complete result determines the outcome. You record the other subagent's partial work in the investigation directory. You can also search IACR, arXiv, and the web in parallel when progress stops.
+ If evidence already strongly favors one outcome, you use the corresponding method.
- Do not claim a property or metric holds without a proof. Conjectures must be clearly labeled as such.
+ #### Formal Proof Structure
- <!-- TODO: Add Lean-based formal verification step. When proofs are complete, translate them into Lean 4 and machine-check them. This would replace confidence levels with verified/unverified status and catch subtle gaps that manual proofs miss. Requires: Lean 4 toolchain, a library of common crypto/protocol primitives in Lean, and a skill or subscript to invoke the Lean checker. -->
+ You write formal claims and proofs in `reaper-workspace/investigations/NNN-<slug>/proof.md`.
+ Each entry uses `## Theorem/Lemma/Proposition N: <name>` and these fields:
- #### Step C: Evaluate
+ - **Statement:** You give the exact mathematical claim.
+ - **Assumptions:** You list every model, hardness, and network assumption.
+ - **Proof:** You number logical steps and justify each with a definition, assumption, lemma, or source. You end with ∎.
+ - **Proof technique:** You name the method, such as reduction, induction, simulation, or hybrid argument.
- Did this cycle produce **genuine progress**? A cycle counts as progress if it:
+ You use the proof methods, Reduction Quality Gate, and performance checks in `../reaper/references/methodology.md`. You state the selected method in the proof header. If an attempt fails, you record the method and cause. You try another method in the next cycle.
- - Confirms or refutes a hypothesis (fully or partially)
- - Narrows the search space on an important question
- - Identifies a new important question not previously considered
- - Simplifies an existing argument (fewer assumptions, shorter proof)
- - Corrects a prior error in understanding
+ All properties need formal predicates. You specify model assumptions for every proof.
+ Security proofs need definitions, reductions, bounds, and explicit reduction loss.
+ Performance proofs distinguish worst-case, average, and amortized costs.
+ Impossibility proofs specify the excluded behavior and use contradiction or reduction.
- **Simplicity criterion**: A proof that achieves the same result with fewer assumptions is better. Replacing a 3-page case analysis with a one-paragraph reduction is progress even if the "result" is unchanged. Don't accumulate tangential findings that don't serve the research goal.
+ If a proof has a gap, you identify the exact step. You state any additional assumption that closes the gap. You log an incomplete proof attempt as `inconclusive`. You label unproven claims as conjectures.
- **One "ping" per cycle**: The cycle's outcome should be statable in a single sentence. If it can't be, the cycle tried to do too much — note this and decompose in the next cycle.
+ ### Step C: Evaluate
- ##### Classify Proof Issues Precisely
+ A cycle makes progress through a changed answer, a new question, a simpler argument, or an error correction.
+ A changed answer can confirm, refute, or narrow a hypothesis.
+ You describe each finding once, even when it has multiple effects.
- When a proof issue is found, do not just say "found a gap." Classify it:
+ You prefer a proof with fewer assumptions or fewer steps for the same result. You exclude findings that do not support the research goal. You state the cycle outcome in one sentence.
+ If the outcome needs multiple claims, you record that issue for the next cycle.
- - **Gap (fillable)**: A step is missing but the overall approach is sound. The gap can likely be closed with additional argument. Log as `partially-confirmed`.
- - **Gap (structural)**: The proof strategy fundamentally cannot work as written — e.g., the simulator doesn't handle a class of adversary behaviors, the reduction has exponential loss, the induction hypothesis is too weak. Log as `inconclusive` and pivot to whether the theorem itself is true via an alternative proof.
- - **Error (theorem likely false)**: The proof fails because the claimed property actually doesn't hold — you can construct a concrete counterexample or execution trace that violates it. Log as `refuted`.
- - **Overclaim**: The proof is correct but proves something strictly weaker than what's claimed — e.g., the paper claims adaptive security but the proof only handles static corruption, or claims async but requires partial synchrony. Log as `partially-confirmed` with the precise weakening stated.
+ #### Classify Proof Issues
- ##### Composition Awareness
+ | Issue | Meaning | Outcome |
+ |---|---|---|
+ | Gap (fillable) | The proof lacks a step, but its approach remains valid. | `partially-confirmed` |
+ | Gap (structural) | The proof method cannot establish the claim as written. You test an alternative proof. | `inconclusive` |
+ | Error (theorem likely false) | A concrete counterexample or execution trace violates the claim. | `refuted` |
+ | Overclaim | The proof establishes a weaker claim. You state the exact weaker result. | `partially-confirmed` |
- When a core property is confirmed, note the composition implications. Consult `../reaper/references/definitional-standards.md` for domain-specific composition considerations (e.g., rewinding, shared setup, standalone vs compositional security).
+ #### Check Composition
- Log composition limitations in the investigation's `analysis.md` even if the original hypothesis didn't ask about composition — this is critical context for the final report.
+ When you confirm a core property, you check its effect on composition. You use `../reaper/references/definitional-standards.md` for relevant conditions, such as rewinding or shared setup. You record composition limits in `analysis.md`, even if the hypothesis did not request this check.
- #### Step D: Log
+ ### Step D: Log
- Prepare a row for `reaper-workspace/notes/results.md`:
+ You prepare a row for `reaper-workspace/notes/results.md`:
```
| NNN | H# | action-type | outcome | confidence | status | one-sentence description |
```
- Where:
- - **action-type**: proof-verification, proof-attempt, counterexample-search, security-analysis, performance-analysis, comparison, literature-search, reformulation
- - **outcome**: confirmed, refuted, partially-confirmed, inconclusive, new-hypothesis, reformulate
- - **confidence**: high, medium, low (see calibration below)
- - **status**: keep or discard
-
- **Update-in-place rule**: If this cycle revisits a hypothesis that already has a row in `notes/results.md`, the subagent should flag this as an update (not a new row). The main agent will update the existing row inline during the merge phase rather than appending a duplicate. The cycle number, outcome, confidence, and description should all reflect the latest result. The previous investigation directory remains in `investigations/` for the audit trail.
-
- Subagents return this row to the main agent rather than appending directly.
-
- **Cycle log**: After preparing the results row, write a cycle log to `reaper-workspace/logs/cycle-NNN-<slug>.md` (using the same NNN and slug as the investigation directory). This is an append-only snapshot — never modify it after creation. Include:
-
- ```markdown
- # Cycle NNN: <hypothesis title>
-
- - **Hypothesis**: H# — <statement>
- - **Action**: <action-type>
- - **Outcome**: <outcome> (confidence: <confidence>)
- - **Verdict**: keep / discard
-
- ## Summary
- <1-3 paragraph narrative: what was attempted, what was found, why the verdict>
- ```
+ The fields use these values:
- When revisiting a hypothesis, create a new log file with the new cycle number (e.g., `cycle-005-proof-lemma3.md` even if `cycle-001-proof-lemma3.md` already exists). The slug may differ if the approach changed.
+ - **action-type:** `proof-verification`, `proof-attempt`, `counterexample-search`, `security-analysis`, `performance-analysis`, `comparison`, `literature-search`, `reformulation`.
+ - **outcome:** `confirmed`, `refuted`, `partially-confirmed`, `inconclusive`, `new-hypothesis`, `reformulate`.
+ - **confidence:** `high`, `medium`, `low`.
+ - **status:** `keep`, `discard`.
- ##### Confidence Calibration
+ Subagents return rows to the main agent without editing `results.md`. They mark revisits as updates with the latest cycle number, outcome, confidence, and description.
- Default to one level LOWER than your instinct. If you think "high," write "medium" unless every single step is airtight.
+ You create `reaper-workspace/logs/cycle-NNN-<slug>.md` for every cycle. You use the current cycle number, including on revisits. You never change this log after creation.
- - **High**: The argument is complete, every step is justified by definition / assumption / prior lemma / cited result, and you can see no way it could be wrong. You could present this at a seminar and defend every step under questioning. For reductions: the Reduction Quality Gate is fully passed.
- - **Medium**: The argument is plausible and mostly complete, but at least one step relies on intuition rather than rigorous justification, or there is a step you believe is correct but haven't fully verified. A careful reviewer might find an issue.
- - **Low**: The argument has significant gaps, relies on unverified assumptions, or is based on analogy/heuristic rather than proof. This is a conjecture with supporting evidence, not a result.
+ The log uses title `# Cycle NNN: <hypothesis title>`.
+ It records Hypothesis, Action, Outcome, confidence, and Verdict.
+ Its `## Summary` explains the attempt, evidence, and verdict in 1-3 short paragraphs.
- #### Step E: Keep or Discard
+ #### Set Confidence
- Determine the verdict:
+ You start one level below your initial confidence estimate. You use high confidence only after you check every proof step.
- **keep** — The cycle produced genuine progress. Return the insight to merge into `current-understanding.md`.
+ | Confidence | Required evidence |
+ |---|---|
+ | `high` | The argument is complete. Every step has a justification. Reductions pass the Reduction Quality Gate. |
+ | `medium` | The argument seems correct, but at least one step lacks full verification or formal justification. |
+ | `low` | The argument has large gaps or unchecked assumptions. It supports a conjecture rather than a proven result. |
- **discard** — The cycle was a dead end. The investigation directory stays for the audit trail.
+ ### Step E: Keep or Discard
- Subagents do NOT write to `current-understanding.md` directly — they return their verdict and insight to the main agent.
+ You return `keep` and the finding when Step C shows progress. Otherwise, you return `discard`. You retain every investigation directory for the audit record. Subagents do not write to `current-understanding.md`.
### Merge
- After all subagents in a batch complete:
-
- 1. **Update or append rows** in `reaper-workspace/notes/results.md`. If a cycle revisits a hypothesis that already has a row, **update the existing row inline** with the new cycle number, outcome, confidence, and description — do not append a duplicate. Only append a new row for hypotheses appearing in the table for the first time. Keep rows ordered by hypothesis number.
- 2. **Integrate "keep" insights** into `reaper-workspace/notes/current-understanding.md` — the main agent writes this, preserving the single-writer constraint. Write as if explaining at a whiteboard — crystallize understanding, don't just append notes. The file should be coherent end-to-end, not a chronological log.
- 3. **Check for new hypotheses** generated by the batch (subagents may propose them). Add to `ideas.md`. If a hypothesis's status changed (resolved, deprioritized, subsumed), **update it inline** in `ideas.md`.
- 4. **Write batch summary** to `reaper-workspace/notes/results.md` after the row table:
- ```markdown
- ## Batch Summary (Cycles NNN-MMM)
- Keep findings:
- - [1 sentence per keep cycle: what was found and why it matters]
- Discard patterns:
- - [1 sentence summarizing why cycles were discarded, if any pattern emerges]
- ```
- These summaries serve two purposes: (a) `/brainstorm` can read summaries instead of full investigation directories, and (b) `/synthesize` can read summaries instead of loading all `analysis.md` files.
- 5. **Re-read updated state** and plan the next batch.
-
- ### Sequential Fallback
+ The main agent waits for all subagents in the batch. It performs these actions:
- When all remaining hypotheses form a dependency chain (H2 requires H1's result, H3 requires H2's, ...), the batch size is 1. This is equivalent to the traditional sequential loop — no subagents needed, the main agent runs Steps A–E directly and writes to `current-understanding.md` immediately on keep.
+ 1. It updates existing hypothesis rows in `notes/results.md`.
+ 2. It adds rows only for new hypotheses. It orders rows by hypothesis number.
+ 3. It merges keep findings into `notes/current-understanding.md` as a coherent explanation.
+ 4. It adds new hypotheses from the batch to `ideas.md`.
+ 5. It updates resolved, lower-priority, or covered ideas in place.
+ 6. It adds a batch summary after the results table.
+ 7. It reads the updated state before it plans another batch.
- ### Repeat
+ The summary uses `## Batch Summary (Cycles NNN-MMM)`.
+ It lists Keep findings and Discard patterns with one sentence per finding or pattern.
- Plan the next batch. Do not pause, do not ask if you should continue.
+ Only the main agent writes shared notes during merge. The `brainstorm` and `synthesize` skills use batch summaries to reduce file reading. For a batch of one, the main agent can run Steps A-E directly.
- ## Never-Stop Policy
+ ## Completion
- Run all N cycles. The only valid early stop is **genuine convergence**: all hypotheses resolved with high confidence, and no new hypotheses worth pursuing. Uncertainty about whether the human wants you to continue is NEVER a reason to stop.
+ You run all N cycles unless all hypotheses reach high-confidence resolution and no useful new hypotheses remain. You do not ask whether the user wants you to continue. You also return early for the reformulation condition below.
- ## When Stuck
+ ## When Progress Stops
- If a cycle is going nowhere, follow the escalation protocol in `../reaper/references/methodology.md` (section "When Stuck: 8-Step Escalation"). The steps progress from re-reading existing materials, through searching for new literature (see `../reaper/references/search-tools.md` for search commands, which use the `arxiv.py` and `iacr.py` scripts in the `/search-paper` skill), to trying radically different approaches.
+ You follow "When Stuck: 8-Step Escalation" in `../reaper/references/methodology.md`. You use `../reaper/references/search-tools.md` for search commands. Those commands use `arxiv.py` and `iacr.py` from the `/search-paper` skill.
- When searching for new literature mid-investigation, download relevant papers to `reaper-workspace/papers/`, write per-paper notes (`<id>-notes.md`), and **integrate findings into `reaper-workspace/notes/literature.md` inline** — add new entries to the appropriate existing sections rather than appending a separate "Mid-Investigation Additions" section. Log the search as a cycle with action-type `literature-search` in `notes/results.md`.
+ You download relevant new papers to `reaper-workspace/papers/`. You write `<id>-notes.md` for each paper. You integrate findings into the existing sections of `notes/literature.md`. You do not create a separate section for additions during investigation. You log the search with action-type `literature-search`.
- If all escalation tactics are exhausted and the hypothesis remains stuck, log the cycle as `inconclusive` and continue to the next hypothesis. The orchestrator will call `/brainstorm` after the batch to generate new ideas based on the pattern of failures.
+ If all eight steps fail, you log `inconclusive` and continue to the next hypothesis. The orchestrator can invoke `brainstorm` after the batch.
- ## Negative Result Protocol
+ ## Negative Results
- If after 3 cycles a hypothesis trends toward refutation (counterexample attempts partially succeed, proof attempts consistently fail at the same point, or you keep hitting the same structural gap):
+ After three cycles with the same proof failure or evidence of refutation, you change direction.
- 1. **Pivot explicitly** to proving the negative. Construct the strongest possible negative result — a concrete attack, execution trace, or reduction to a known impossibility. A clean impossibility result is more valuable than a vague "we couldn't prove it."
- 2. **Identify the minimal fix.** What is the weakest additional assumption that would make the positive result hold? (e.g., "Safety holds if we additionally assume synchronous message delivery in the view-change sub-protocol.")
- 3. **A clean negative result is a KEEP, not a failure.** It resolves the hypothesis (by refutation) and advances understanding. Log it with outcome `refuted` and status `keep`.
- 4. **Signal for new ideas.** Note in the cycle's result description that the hypothesis was refuted and what was learned. The orchestrator will call `/brainstorm` to generate follow-up hypotheses (e.g., proving the impossibility formally, exploring the minimal fix).
+ 1. You attempt a concrete attack, execution trace, or reduction to a known impossibility.
+ 2. You identify the weakest additional assumption that restores the positive claim.
+ 3. You record a supported negative result as outcome `refuted` and status `keep`.
+ 4. You state the result and its implications in the cycle description for later brainstorming.
- Do not spend 10 cycles attempting minor variations of the same failed proof strategy. Three failures at the same point is a signal to change direction.
+ You do not repeat minor changes to the same failed proof method.
## Re-Formalization Protocol
- If an investigation cycle reveals that the problem formulation itself is wrong (not just that a hypothesis failed, but that the model assumptions, core question, or property definitions are mis-specified), trigger re-formalization:
-
- 1. Log the cycle with outcome `reformulate` and status `keep`.
- 2. In the cycle's `analysis.md`, write a section `## Re-Formalization Signal` containing:
- - What is wrong with the current formulation
- - What evidence from this cycle demonstrates the problem
- - What the corrected formulation should look like (proposed changes to model assumptions, core question, or properties)
- 3. Write `REFORMULATE` as the first line of the cycle description in `notes/results.md`, followed by a one-sentence summary.
- 4. **Stop the current investigation batch** and return control to the orchestrator. Do not continue investigating hypotheses based on a known-incorrect formulation.
-
- The orchestrator will re-invoke the `/formalize-problem` skill incorporating the re-formalization signal before resuming investigation.
-
- If any cycle in a batch returns outcome `reformulate`, stop dispatching further batches and return control to the orchestrator with a re-formulation signal.
+ If a cycle finds incorrect model assumptions, a wrong core question, or incorrect property definitions, you request reformulation.
- ## Quality Criteria
+ 1. You log outcome `reformulate` and status `keep`.
+ 2. You add `## Re-Formalization Signal` to the cycle's `analysis.md`.
+ 3. That section states the error, evidence, and proposed correction.
+ 4. You start the result description with `REFORMULATE`, followed by a one-sentence explanation.
+ 5. You stop further batches and return the signal to the orchestrator.
- - Every hypothesis has exactly one row in `notes/results.md` reflecting its latest state — revisits update inline, not append
- - `current-understanding.md` only changes on keep cycles
- - Each investigation directory has an `analysis.md` reflecting the current best understanding (edited inline on revisit)
- - The "one ping" test: every cycle's outcome can be stated in one sentence
- - No cycles wasted on tangential exploration that doesn't serve the research goal
- - When stuck, the 8-step protocol is followed before giving up on a hypothesis
- - Independent hypotheses are batched in parallel by default; sequential only when dependencies exist
- - `current-understanding.md` is written only by the main agent during the merge phase, never by subagents
+ The orchestrator invokes `formalize-problem` with this evidence before investigation resumes.