mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
Renn F
ecea593a51
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.
65 lines
2.0 KiB
Markdown
65 lines
2.0 KiB
Markdown
# 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)
|
|
|
|
```python
|
|
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:
|
|
|
|
```python
|
|
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}`.
|