862c0b27cd
Seventeen-page sweep of the agent-facing KB against shipped behavior: required covers_parent_criteria and per-AC criteria_verified reach the QA/PM/task-tools pages (the QA docs also named non-callable pass_review/ fail_review — the MCP tools are pass/fail); collision_context lands in the QA/gate/planning evidence docs; the possibilities matrix gets its own architecture page + config entry; the auditor page gains its missing waive_finding and playbook-curation verbs; git-pr-types.md is rewritten off the long-dead is_root_pr model; PR/workspace/git-error pages stop assuming GitHub (forge-agnostic + env-ladder semantics). Co-authored-by: Renn F <rennf93@users.noreply.github.com>
8.1 KiB
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. A "unit of work" is the LARGEST coherent piece one dev can own end-to-end, not the smallest step you can name (CEO doctrine: never over-separate). Single-concern work — a dependency bump, a config change, one component — is one subtask covering the change, its verification, and the PR. Sequenced same-branch steps are one subtask, not siblings; split only for genuine parallelism across devs or different owners. The sub_tasks checklist above may hold more steps than you delegate — several checklist steps usually collapse into one delegated task:
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"],
covers_parent_criteria=["<parent-ac-id>"],
)
Acceptance-Criteria Coverage
When you decompose a parent task, declare which parent criteria each subtask is responsible for with covers_parent_criteria (a list of the parent's acceptance_criteria_ids, or the criterion's exact text). This is what lets the org prove a decomposition covers the parent's full intent — and it drives two gates and your coverage briefing.
covers_parent_criteria is required, not optional, whenever the parent has any acceptance criteria. delegate refuses a child with no covers_parent_criteria declared — "'