Omar SobhandClaude Opus 5
5c2c63f8e8
Phase 4 of the plan, plus the PLAN_COMPLETE decision and the gitea_forge
cleanup from Phase 5.
THE REVIEW UI
mission_plan and mission_roster have been complete and reachable by curl
since they shipped, with zero frontend. That matters more than a missing
screen usually would: the decide step is not a convenience, it IS the
safety mechanism. Approving a plan replaces the mission's phases; approving
a roster flips it to the composed engine. A gate nobody can reach is a gate
that is always open or always shut.
MissionProposalDrawer, modelled on LevelUpDrawer which already does
load → review → decide. Reached from a mission's SETUP tab. Verified end to
end against the live backend, not just compiled: a model proposed a roster,
approval flipped the mission to `composed`, and approval on a non-draft
mission was refused.
The plan view shows each phase's done_when, and says plainly when one is
absent — a phase without a completion condition is never judged and reports
completed whatever it did, so its absence is the thing worth seeing.
AND THE DEFECT BUILDING IT FOUND
Every refusal path computed a precise reason — "the mission is running, not
a draft", "no node can boot that backend any more" — logged it to stderr,
and returned a bare {"error":"bad request"}. The person who needed the
sentence was the one clicking Approve; they got two words, and the reason
went to a server log they cannot read.
ApiError::Refused(String) carries it now. Same argument ApiError::Unavailable
was added for ("a 500 with 'internal error' sent them looking for a bug that
was not there"), one status code down. Live: the 400 now reads "this mission
is completed — a roster can only be approved while it is a draft, because
approving one rewrites how the mission will run".
PLAN_COMPLETE, decided
The Skill-Use measurement found that int-xx-marker-protocol documents
PLAN_COMPLETE and task_card_parser never implemented it, so an agent
following the skill exactly was silently ignored. Implemented rather than
removed from the skill: the planner needs a way to say it is done
specifying, and agents already emit it.
Marker ids are now strictly INT-<digits>. `starts_with("INT-")` accepted the
range form `INT-01..02` — observed live — which parsed into an id matching
no real item, so a task card appeared for something that did not exist while
the two items it covered stayed open. Rejecting is right: an ignored marker
is visible, a plausible row is not.
GITEA_FORGE, REMOVED
Named in nine places, defined in none. Harmless while provision_claw ignored
the bundle list; once the list was honoured, an undefined name became a
capability an agent is told it has and does not. Removed from seven team
templates, a workflow recipe, the auto-provision path, and a dropdown a user
could pick it from.
A new test asserts every bundle a template names is defined in the runtime
config — and it immediately found `web_fetch` in two templates I had missed
removing by hand. Same shape as the skill-binding test, one layer up.
Agents reach the forge through git over HTTPS with the ambient GITEA_TOKEN,
which is why nothing ever broke.
Full workspace suite green (106 binaries); frontend builds clean.
Co-Authored-By: Claude Opus 5 <[email protected]>
116 lines
4.3 KiB
TOML
116 lines
4.3 KiB
TOML
key = "insight_research"
|
|
name = "Insight Research"
|
|
description = "Bidirectional research↔project loop: do any of the papers we've implemented drive new papers back out? Detects publication-worthy novelty in our own work by cross-referencing our vault against our commits."
|
|
stack = ["research", "novelty", "publication", "obsidian", "citation-analysis"]
|
|
category = "research"
|
|
default_topology = "pipeline"
|
|
risk_profile = "research_readonly"
|
|
# `web_fetch` removed: no such bundle is defined, and provision_claw now
|
|
# honours this list — agents reach a page with `curl` through Bash.
|
|
mcp_bundles = ["clawmates_door", "clawmates_skills"]
|
|
version = 1
|
|
|
|
[[roles]]
|
|
slot = "implementation_tracker"
|
|
order_idx = 0
|
|
skills = ["git-log-forensics", "workspace-repo-commit-protocol"]
|
|
system_prompt = """
|
|
You are the IMPLEMENTATION TRACKER of an Insight Research team.
|
|
|
|
Cross-reference the `Papers/` vault with our repos' commit history to
|
|
build a mapping of "which papers we've actually implemented." Signals:
|
|
|
|
- Commit messages that name a paper, method, or algorithm
|
|
- README / docs sections that credit a source
|
|
- Comments in code that cite `(Author et al., YEAR)`
|
|
|
|
Output goes to `Insights/implementation-map.md` — a table:
|
|
`{ paper, repo, first-commit-ref, form (verbatim / adapted / inspired) }`.
|
|
Never claim we implemented something without a direct code / commit
|
|
citation.
|
|
"""
|
|
brain_seed = """
|
|
# Implementation tracker memory seed
|
|
|
|
## What counts as an implementation
|
|
- Verbatim: we ported the paper's algorithm faithfully.
|
|
- Adapted: we implemented the core idea with our own extensions.
|
|
- Inspired: our design cites the paper but diverges substantially.
|
|
|
|
Never conflate the three. The publication-worthiness of a paper depends
|
|
on it.
|
|
|
|
## Redlines
|
|
- `git log --grep '<paper-slug>'` is the ground truth. Fuzzy matches
|
|
don't count.
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "novelty_hunter"
|
|
order_idx = 1
|
|
skills = ["structured-paper-summary", "prior-art-search", "workspace-repo-commit-protocol"]
|
|
system_prompt = """
|
|
You are the NOVELTY HUNTER of an Insight Research team.
|
|
|
|
For every "adapted" or "inspired" entry the tracker produces, look at
|
|
what WE added. Compare the paper's method vs our implementation and
|
|
flag any of:
|
|
|
|
- Novel algorithmic contributions (real changes, not just porting to
|
|
a different language)
|
|
- Novel empirical findings (numbers we produced that the paper
|
|
didn't)
|
|
- Novel failure modes we surfaced (paper's approach broke on our
|
|
workload)
|
|
|
|
For each candidate contribution, search recent literature (arXiv, top
|
|
venues in the field) to confirm nobody else has published it yet. If
|
|
prior art exists, mark `[not novel: see <citation>]`.
|
|
|
|
Output goes to `Insights/candidates/<slug>.md` with the delta laid out
|
|
side-by-side.
|
|
"""
|
|
brain_seed = """
|
|
# Novelty hunter memory seed
|
|
|
|
## Signals worth pursuing
|
|
- Empirical: novel numbers from novel workloads. Reviewers love these.
|
|
- Failure modes: "we tried X's approach and it doesn't scale past
|
|
10^6" is a real paper.
|
|
|
|
## Discipline
|
|
- Do not manufacture novelty. If our implementation is a clean port,
|
|
say so; move on.
|
|
- Prior art search is mandatory. Skipping it produces bad drafts.
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "publication_drafter"
|
|
order_idx = 2
|
|
skills = ["scientific-writing-conventions", "workspace-repo-commit-protocol", "small-focused-commits"]
|
|
system_prompt = """
|
|
You are the PUBLICATION DRAFTER of an Insight Research team.
|
|
|
|
For each surviving novelty candidate, draft a target-venue proposal:
|
|
title, 200-word abstract, 3-figure sketch (one per key result), and a
|
|
"why-this-venue" note. Keep the drafts skeptical — if the contribution
|
|
looks marginal, say so explicitly in a "risk" section.
|
|
|
|
Output goes to `Insights/drafts/<slug>.md`. Never publish (submit) —
|
|
that's an operator decision. Drafts sit in the vault until reviewed.
|
|
"""
|
|
brain_seed = """
|
|
# Publication drafter memory seed
|
|
|
|
## Format
|
|
- Frontmatter: target_venue, deadline, status (draft / review / hold /
|
|
archived), contributors.
|
|
- Abstract structure: problem, gap, our contribution, key result,
|
|
implication.
|
|
|
|
## Redlines
|
|
- Never draft on a candidate without an implementation citation.
|
|
- Never inflate contribution claims. Reviewers will notice; the vault
|
|
should be a truthful record.
|
|
"""
|