Files
roboco/docs/rag/workflows/megatask.md
T
Renn F 3441e37120 [sweep] strip Fxxx audit-ID tokens + trim bloated comments/docstrings + add behavior-change docs
Post-audit sweep over the 135 audit-fix commits since 19a474d3:

1. Stripped every # Fxxx: audit-ID token from comments AND every Fxxx token
   from docstring openings across 211 blocks / ~626 lines. The CEO flagged
   these twice: audit-issue IDs in code confuse future devs/agents. The
   descriptive text is preserved; only the Fxxx token is removed (and bloated
   narrative blocks trimmed to 1-3 lines keeping the one non-obvious invariant).
2. Trimmed bloated comments/docstrings to the concise standard (1-3 lines).
3. Added missing behavior-change docs for the audit-fix batch: prompts/roles
   (documenter, pr_reviewer, qa), user-facing docs (api auth, websockets,
   agent-gateway, megatask, merge-model, task-lifecycle, grok, resilience,
   conventions, panel, security, troubleshooting), and the RAG corpus (cell-pm,
   main-pm, pr-reviewer, qa roles; conventions; messaging-tools; escalation;
   megatask; task-claiming workflows).

Comment/docstring/prose ONLY — zero code-line edits (verified: the diff
contains no def/class/return/if/for/await/assignment/call lines). Gates green:
ruff format + ruff check clean, mypy clean on roboco/. The only pytest failures
are the pre-existing sync_branch tracing-decision gap (B1, 250be5c2) — not
sweep-caused and tracked separately.
2026-06-29 01:25:40 +02:00

2.2 KiB

MegaTask (Sequenced Batch) Reference

A MegaTask is several tasks the CEO described in one intake chat, shipped as one collision-sequenced batch — often across projects that do not share a codebase.

Structure

  • Umbrella task — groups the batch. It carries a batch_id and has no parent_task_id. It is branchless: no project, no branch, no PR of its own. It is the single board-review / CEO-approve / Main-PM-coordinate unit.
  • Root-subtasks — one per piece of work. Each has the umbrella as its parent_task_id, shares the batch_id, and is a real coordination root with its own project, branch, and PR. They are sequenced into waves by cross-task dependencies.

Hierarchy: Umbrella (Main PM) → Root-subtasks (Main PM) → Cell tasks (cell PMs) → Dev subtasks. One extra Main-PM layer above the normal model.

Rules an agent must know

  • The umbrella does no git. It is exempt from the branch gate (it reaches in_progress with no branch) and you must not call submit_root on it — it assembles no PR. Each root-subtask opens and is reviewed on its own PR.
  • The umbrella completes only when every root-subtask is terminal; then it escalates to the CEO (PR requirement waived).
  • The root-subtasks are sequenced: a wave's tasks dispatch only once the previous wave's tasks reach a terminal state (ordinary dependency-gating). You do not reorder them — the analyzer set the order at create time.
  • On the Board route the root-subtasks are held in backlog until the CEO approves the umbrella, then released to pending. On the Approve & Start route they start immediately. On Board-route activation a code-typed root-subtask is retyped to planning — a Main PM never owns a code task (the main_pm + code combo is the 2026-06-27 meltdown trigger).

For the Main PM

You coordinate the umbrella exactly like a product coordination root: plan, delegate each root-subtask to its cell, and complete the umbrella once all root-subtasks finish. You do not branch or PR the umbrella itself. Because you may hold many roots in parallel, the single-task claim guards do not apply to you — only a genuine sequence dependency holds a task back.