`templates/teams/continuous_research.toml` has existed with three well-written roles since it was authored, but no workflow recipe pointed at it — every recipe in templates/workflows/ defaults `default_team_template = "rust_sdlc"`. So the only way to reach it was as a checkbox under Advanced. It is now a Step-1 card: the registry loads it at boot and `GET /api/workflows` serves it, with no frontend change (MissionWizard renders whatever the endpoint returns). Both phases are kind `research`, deliberately, rather than new `read`/`script` kinds. An unrecognised kind falls through `purposes_for`'s `_ => ["mission"]` and is absent from `PRODUCING_KINDS`, so it would get the generic directive AND be exempt from the empty-delivery rule — a phase that produces nothing and still passes. That is the shape this codebase keeps paying for; two `research` phases differentiated by `task` keep both guards. `commit_policy = "always"`, not `on_green_tests`: the vault is prose with no suite, so a test gate would find nothing to run and land every branch `-wip`. The harvest is NOT an agent phase. `continuous_research.rs` calls the existing `library::run_to_vault` — arXiv search, seen-set check, PDF shelf, vault note, attributed by `mission_id` — because that path is deterministic, takes seconds, and owns the `corpus_items` seen-set that is the whole reason a recurring mission knows what it already covered. An agent redoing it would be slower and would lose that. The manifest path is not invented either: the team template has told `signal_harvester` to write `ContinuousResearch/<date>/harvest.jsonl` all along. This makes the code produce what the prompt already promised, and a test pins the path and every documented key so the two cannot drift into an agent reading a file nothing writes. DEFAULT_CORPUS / DEFAULT_VAULT_URL exported rather than duplicated, so the route and the launch hook cannot disagree about which vault. 344 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]>
94 lines
4.6 KiB
TOML
94 lines
4.6 KiB
TOML
key = "continuous_research"
|
|
title = "Continuous Research"
|
|
blurb = "Harvest new arXiv papers, read them against your projects, and write a two-host podcast script for the morning."
|
|
requires_repo = true
|
|
|
|
# The vault, not `rust_sdlc`. Every other recipe defaults to the Rust SDLC team,
|
|
# which is why `continuous_research` has only ever been reachable as a checkbox
|
|
# in Advanced rather than as a mission type.
|
|
default_team_template = "continuous_research"
|
|
|
|
# ── How the papers arrive ────────────────────────────────────────────
|
|
#
|
|
# The harvest is NOT an agent phase. `library::run_to_vault` already does
|
|
# arXiv search → seen-set check → PDF fetch → blob shelf → vault note, and it
|
|
# takes a `mission_id` so the run is attributed. Asking an agent to redo that
|
|
# would be slower, non-deterministic, and would lose the `corpus_items`
|
|
# seen-set that is the entire reason a recurring mission knows what it already
|
|
# covered. `mission_orchestrator::on_launch` runs it before the phases start
|
|
# and drops a manifest at `ContinuousResearch/<date>/harvest.jsonl` — the path
|
|
# `templates/teams/continuous_research.toml` already tells the harvester role to
|
|
# write, now produced by the code that actually does the harvesting.
|
|
#
|
|
# The mission binds the VAULT repo, so `/mission/repo` is the card catalogue:
|
|
# the agents read the notes the harvest just wrote and commit their analysis and
|
|
# script back onto the run's own branch, never `main`.
|
|
|
|
[[phases]]
|
|
kind = "research"
|
|
order_idx = 0
|
|
[phases.config]
|
|
produces = ["md"]
|
|
default_topology = "hub_spoke"
|
|
# `research`, not a new `read` kind. An unrecognised kind falls through to
|
|
# `purposes_for`'s `_ => ["mission"]` and is absent from `PRODUCING_KINDS`
|
|
# (phase_runner.rs), so it would get a generic directive AND be exempt from the
|
|
# empty-delivery rule — a phase that could produce nothing and still pass. Two
|
|
# `research` phases differentiated by `task` keeps both guards.
|
|
task = """
|
|
Read today's harvested papers and judge them against the projects listed below.
|
|
|
|
Start from ContinuousResearch/<today>/harvest.jsonl — that is the list of papers \
|
|
that are NEW since the last run. Papers already covered are not in it, and you \
|
|
should not go looking for them.
|
|
|
|
For each paper write an entry in ContinuousResearch/<today>/analysis.md \
|
|
containing: what it actually does (not what its abstract claims), whether the \
|
|
evidence supports it, and — the part that matters — WHICH of the projects below \
|
|
it bears on and what concrete change it would imply. Name a file, a module or a \
|
|
roadmap item wherever you can.
|
|
|
|
Depth comes from the paper itself: the note carries the abstract, and `curl` on \
|
|
the arXiv abstract page gets you the rest. Do not review a paper from its title.
|
|
|
|
A paper with no bearing on any project is a real and useful finding — say so in \
|
|
one line and move on. Do not manufacture relevance.
|
|
|
|
PROJECTS THIS RESEARCH SERVES — replace this block when creating the mission:
|
|
(none configured yet)
|
|
"""
|
|
done_when = "ContinuousResearch/<today>/analysis.md exists and contains, for every paper in that day's harvest.jsonl, a judgement of the work and a statement of which project it bears on or that it bears on none"
|
|
max_iterations = 2
|
|
# Nothing here is compiled, so `on_green_tests` would gate on a suite that does
|
|
# not exist and land every branch `-wip`. The vault is prose.
|
|
commit_policy = "always"
|
|
|
|
[[phases]]
|
|
kind = "research"
|
|
order_idx = 1
|
|
[phases.config]
|
|
produces = ["md"]
|
|
default_topology = "hub_spoke"
|
|
task = """
|
|
Turn today's analysis into a podcast script for two hosts.
|
|
|
|
Read ContinuousResearch/<today>/analysis.md and write \
|
|
ContinuousResearch/<today>/script.md as a conversation between HOST and GUEST. \
|
|
Lead with what changed for our projects, not with a list of papers — the \
|
|
listener is on a treadmill, not at a desk.
|
|
|
|
Also write ContinuousResearch/<today>/episode.json:
|
|
{ "title": "<one line, under 80 chars>",
|
|
"highlights": ["<10-70 chars each, at most 5>"] }
|
|
Those bounds are the podcast API's, not a style preference — a highlight \
|
|
outside them is rejected.
|
|
|
|
Target seven minutes of speech, roughly 1,000 words. Say the specific thing: \
|
|
"this changes how we prune the HNSW graph in clawhdf5" beats "researchers \
|
|
propose a novel method". Skip a paper entirely rather than pad the episode \
|
|
with one that does not matter.
|
|
"""
|
|
done_when = "ContinuousResearch/<today>/script.md contains a two-host dialogue covering the analysis, and episode.json contains a title and a highlights array whose entries are each between 10 and 70 characters"
|
|
max_iterations = 2
|
|
commit_policy = "always"
|