QuantumBFS / QuantumBFS/sci-brain

Support closing unresolved autoresearch campaigns

Open
#66 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
97
Forks
20
Avg merge
8h 10m
Merged PRs (30d)
19

Description

Background

autoresearch currently has a path for continuing experiments and a done state for a validated result. A user may instead decide to stop after many unsuccessful attempts. The current run-stage soft gate allows zero further attempts, but it does not give the user a clear way to close the campaign, preserve what was learned, and understand which experimental files are safely retained. This came up in a campaign with 40 local attempt branches, 12 cycle reports, no accepted result, and no Git remote. See skills/autoresearch/SKILL.md and skills/autoresearch/references/stages/run.md.

Request

Could sci-brain support an explicit closeout path or skill for an unresolved autoresearch campaign? The maintainer should choose the workflow, state model, report format, and storage strategy. The user-facing outcome should be a trustworthy record of the experiments and their limitations, together with practical guidance on preserving the underlying local evidence.

In particular, it would be useful if closeout could:

  • Say plainly that the goal was not met, without treating a restricted search failure as a general negative result.
  • Summarize what was tried, what failed or remains uncertain, any useful partial findings, and what a future researcher would need to resume.
  • Help the user see whether attempt logs, code, results, and other important local files are actually retained, especially when attempts live on separate branches or worktrees and no remote backup exists.
  • Avoid starting new attempts, querying holdout data, deleting artifacts, or claiming that local Git commits constitute an off-machine backup.

These are desired outcomes, not a prescribed manifest schema, status field, backup mechanism, or report template. For example, a branch inventory or export might help in some projects, but another design may be better; I would leave that decision to the repository maintainers.

Verification suggestion

Please include a small offline end-to-end test or documented example. For a fixture with two local attempt branches, one timeout, one restricted negative result, and no remote, closing the campaign should produce a human-readable record that identifies both attempts, distinguishes the two outcomes, states that the research question remains open, and warns that the evidence is only local. It should not create another attempt or mark the scientific goal as validated. A negative control with a missing attempt log or unsaved research file should surface the preservation gap rather than report a clean closeout. A project-standard test command such as python -m pytest tests -q should exercise both cases; the maintainers can choose the actual fixture and test layout.

Out of scope

Solving the research problem or requiring any particular Git, archive, or report implementation.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with skills/autoresearch/SKILL.md and skills/autoresearch/references/stages/run.md to understand the existing campaign lifecycle and soft gate. Use the suggested offline fixture with two local attempt branches, a timeout, a restricted negative result, and no remote, then run python -m pytest tests -q. Done should include a human-readable unresolved record, distinguish both outcomes, warn that evidence is local, expose missing preservation, and avoid new attempts or validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, python
Domain
machine-learning, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.