Omar Sobh
3465bb7a6d
This is the minimum viable version of the "agents actually work on
a repo" architecture. Full vision (isolated ZeroClaw container per
topic, dynamic agent provisioning inside, pause/resume, commit
gate) is real weeks of work — this closes the first, most-visible
gap so the ClawHDF5 topic can actually run against its codebase.
Backend
- Migration 0037: research_topics gets repo_id UUID (nullable, FK
to repos ON DELETE SET NULL) and repo_workspace_path TEXT for
the on-disk checkout location. Index on repo_id when set.
- research_topics::create takes repo_id: Option<Uuid>. get + list
select it and repo_workspace_path. set_repo_workspace_path
persists the path once the first clone lands.
- CreateTopicRequest accepts `repo: Option<TopicRepoRef>` — the
same denormalized shape the wizard already sends. Only repo_id
is authoritative; other fields are ignored (dead_code-allowed
so serde still deserializes the full body).
- start_topic branches on topic.repo_id. When set, it calls
ensure_repo_workspace:
· resolves repo.clone_url + repo.default_branch
· target path = CLAWMATES_RESEARCH_WORKSPACE_ROOT
// <topic_id> // repo (defaults under $TMPDIR)
· runs `git clone --depth 1 --single-branch --branch <b>` via
tokio::process. Reuses the checkout if .git already exists.
· persists the path so re-starts skip the clone
· runs `git ls-files` to sample the tree (first 60 entries,
total count reported honestly so the prompt doesn't lie
about coverage)
All best-effort — a clone failure logs but still starts the run
without repo context rather than aborting.
- build_coordinator_task takes Option<&RepoContext>. When present,
the framing gets a REPO block (slug / path / branch / file
sample) and a USING THE REPO section instructing the coordinator
to ground every recommendation in a concrete file reference and
never fabricate paths. The per-topology bodies are unchanged —
the repo guidance sits above them so it applies to every shape.
What this unblocks / doesn't unblock
Unblocks: The coordinator prompt now knows the repo exists, where
it lives on disk, and what's in it. Even without file-editing
tools wired to the checkout, the coordinator can point spokes at
concrete modules and the final artifact can reference real files.
For a spec-shaped outcome like ClawHDF5's, that's the difference
between abstract advice and a spec grounded in the actual crates.
Does NOT unblock: The agents themselves editing files, running
tests, or committing. That requires either mounting the checkout
into the ZeroClaw sandbox or exposing a new MCP tool for
repo-scoped file ops — separate follow-up.
20 lines
880 B
SQL
20 lines
880 B
SQL
-- Bind a research topic to a workspace repo + the on-disk path where
|
|
-- `start_topic` clones a working copy. Both nullable so pre-existing
|
|
-- topics don't need backfill and topics without a repo still work.
|
|
--
|
|
-- repo_id — the repo the user picked in the wizard. ON DELETE SET
|
|
-- NULL so removing the connection doesn't cascade-nuke the topic.
|
|
--
|
|
-- repo_workspace_path — absolute path on the API host where
|
|
-- `start_topic` executed `git clone --depth 1`. Set once when the
|
|
-- clone succeeds; a subsequent start can reuse it (skip re-clone).
|
|
-- Feeds the coordinator prompt so agents know where the files live.
|
|
|
|
ALTER TABLE research_topics
|
|
ADD COLUMN repo_id UUID REFERENCES repos (id) ON DELETE SET NULL,
|
|
ADD COLUMN repo_workspace_path TEXT;
|
|
|
|
CREATE INDEX research_topics_repo_idx
|
|
ON research_topics (repo_id)
|
|
WHERE repo_id IS NOT NULL;
|