mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00

Files

T

Renn F ecea593a51 docs(rag): rewrite the KB docs to the real gateway verb surface

The RAG knowledge base (indexed and queried by agents at runtime)
described entire fictional MCP tool surfaces — roboco_task_*,
roboco_journal_*, roboco_message_send, roboco_notify_send, roboco_agent_*,
roboco_session_*, roboco_workspace_*, roboco_project_* — that don't exist,
so agents searching the KB were handed invented tool names.

Rewrite every affected doc (tools, roles, workflows, troubleshooting, and
the stale architecture snippets) to the real surface: the gateway intent
verbs (give_me_work, i_will_work_on, open_pr, i_am_done, claim_review,
pass, fail, claim_doc_task, i_documented, triage, delegate, i_will_plan,
unblock, complete, escalate_up, escalate_to_ceo, ...) and content tools
(commit, note(scope=...), say, dm, evidence, notify*, open_session,
channels). Also reconcile the access-control docs to code: CEO can cancel
(Board/Auditor cannot); the management-channel membership and the
Auditor's silent-but-present status now match communications.py.

2026-06-05 17:20:36 +02:00

2.3 KiB

Raw Blame History

Project & Workspace Tools

Overview

There is no roboco_project_* or roboco_workspace_* agent tool. Agents do not create projects, manage git tokens, or ensure workspaces. Those are handled for you:

Workspaces are auto-cloned by the orchestrator (WorkspaceService). Your per-agent clone of the project repo is created the first time you claim work on it — you never call a workspace tool. Branches are auto-created on i_will_work_on() / claim_review(); you don't run git checkout either.
Project registration and git-token management are operator actions done through the control panel / HTTP API, not from inside an agent container. Tokens are encrypted at rest; the agent container never sees the PAT (it is injected into git operations server-side and scrubbed from URLs).

What a task already tells you

A task carries its project linkage; you don't look it up with a tool. The task object you receive from give_me_work() / triage() includes the project_id (and the branch the flow verbs check out). Acceptance criteria and the project context come back inline on the Envelope.

Inspecting the repo

Read-only git inspection is available through the roboco-git-readonly MCP server (developers and QA):

roboco_git_status(project_slug="roboco")
roboco_git_log(project_slug="roboco")
roboco_git_diff(project_slug="roboco")
roboco_git_branch_list(project_slug="roboco")

There is no roboco_git_commit / _push / _checkout / _create_pr / _merge_pr tool. Commits go through the commit content tool (auto- prefixed with [task-id], auto-pushed by the choreographer); PRs open at open_pr time; merges are a PM complete operation.

Finding project knowledge

To learn how a project's codebase is laid out or how a subsystem works, query the knowledge base rather than a project tool:

roboco_kb_search(query="rate limiting redis", project="roboco",
                 index_types=["code", "documentation"])
roboco_ask_mentor(question="How is auth wired up in this project?")

PM note: creating work

PMs create work with the delegate flow verb (a subtask under the current parent task), not a project/task-create tool. delegate takes an optional project_id; the parent task's project is inherited when you omit it. There is no agent-facing standalone project- or task-create tool.

2.3 KiB Raw Blame History