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.0 KiB

Raw Blame History

Task Planning Workflow

Overview

Planning is a PM activity. When a PM (Cell PM or Main PM) picks up a coordination or parent task, they record a plan with i_will_plan and then fan the work out into subtasks with delegate.

triage / give_me_work → i_will_plan → delegate (one per subtask) → i_am_idle

Developers do not have a separate planning verb — they pass a short plan argument directly to i_will_work_on(task_id, plan="...") when they claim a coding task.

Submitting a Plan (PM)

i_will_plan(
    task_id="<task>",
    plan="One-paragraph summary of how this work will be broken down",
    approach="High-level implementation strategy",
    sub_tasks=[
        "UX/UI: design the settings panel",
        "Frontend: wire the panel to the API",
        "Backend: add the settings endpoint",
    ],
    technical_considerations=["Reuse the existing config service"],
    risks=["Frontend depends on the UX design landing first"],
    open_questions=["Confirm the default toggle state with the CEO"],
)

After i_will_plan, the envelope's next field points you at delegate — create one subtask per unit of work:

delegate(
    parent_task_id="<task>",
    title="Add the settings endpoint",
    description="...",
    assigned_to="be-dev-1",
    team="backend",
    task_type="code",
    nature="feature",
    estimated_complexity="medium",
    acceptance_criteria=["Endpoint returns 200 with the saved settings"],
)

Git Workflow

All code tasks follow the git workflow:

Branches are auto-created when a developer claims the task via i_will_work_on — no manual branch creation
Root tasks: branch created from the default branch (main/master)
Subtasks: branch forked from the parent's branch

Coordination/parent tasks that only plan and delegate (no code) do not need a branch of their own.

Hierarchical branch naming uses -- between task IDs to avoid git ref conflicts: feature/{team}/{ROOT}--{SUB}--{SUBSUB}.

2.0 KiB Raw Blame History

Task Planning Workflow

Overview

Submitting a Plan (PM)

Git Workflow

2.0 KiB

Raw Blame History