Omar SobhandClaude Opus 5
a02e0cba69
The card shipped in e20b321 could not actually be used. Three things were
missing, each of which failed at a different distance from its cause.
**1. `default_team_template` was parsed and never read.** Every recipe declares
one; `WorkflowRecipe` carries the field; nothing consumed it. A mission created
from a card with no explicitly chosen team was rejected at LAUNCH with "no
team_id, no team_template_id, no config.phase_teams" — one step removed from the
real cause, which is that creation ignored the recipe. Create now resolves it
via `team_templates::get_by_key`, only when the caller named no team of any
kind, so an explicit choice still wins. A test asserts every shipped recipe
names a template that has a `templates/teams/<key>.toml`, because a mismatch
there produces an unlaunchable card.
**2. The harvest ran nowhere.** `harvest_for_mission` existed and nothing called
it. `on_launch` now runs it for `continuous_research` missions, before the
phases start, and threads the blob store through from `main` (the route already
had it on `AppState`; the scheduler needed it). Deliberately non-fatal: a
harvest that fails still starts the phases, because the phase is what reports
whether today was quiet or broken and those must stay distinguishable — but
never silent, so both outcomes log their counts.
**3. Nothing wrote the manifest.** `templates/teams/continuous_research.toml`
has pointed its reader role at `ContinuousResearch/<date>/harvest.jsonl` since it
was authored, and the file did not exist — agents aimed at a path nothing
produced. `run_to_vault` now writes it beside the notes and stages it, but only
for a mission-attributed run. `Harvest` carries the shelved `Paper`s to build
it; re-parsing the notes we had just written would have been a parse of our own
output and one more place for the two to drift.
Also: the blob root. `storage.data_dir` defaults to "./data" and the container's
cwd is `/`, so the server tried to create `/data` as uid 65532 and EVERY shelve
failed with "storage io: Permission denied". The image now creates
/var/lib/clawmates-blobs owned by 65532 so a mounted volume inherits it rather
than arriving root:root. Kept off /var/lib/clawmates-missions on purpose: that
tree is swept, and a paper shelved there would be deleted out from under its own
catalogue note.
Proven end to end on a real mission: 15 candidates, 2 already held, 13 shelved,
0 failed; branch auto-merged as additive-only; manifest on vault `main` with
every documented key. The "already held" counts are the seen-set deduping across
topics within a single run, which is the behaviour the whole design exists for.
The project brief now comes from the mission description — `phase_task_text`
already places it under BRIEF verbatim, so no new field was needed.
346 tests pass.
Co-Authored-By: Claude Opus 5 <[email protected]>
98 lines
4.9 KiB
TOML
98 lines
4.9 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 operator's projects.
|
|
|
|
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 operator's \
|
|
projects 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.
|
|
|
|
THE PROJECTS THIS SERVES ARE IN THE BRIEF ABOVE. `phase_task_text` puts the \
|
|
mission's description there verbatim, so that is where the operator names what \
|
|
they are working on and what each project needs. If the brief names no \
|
|
projects, say so plainly in analysis.md rather than inventing a target — a \
|
|
digest that guesses at relevance is worse than one that admits it has no \
|
|
context.
|
|
"""
|
|
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"
|