cea3e56628
* feat(lifecycle): revision findings ledger — structured QA/PR/PM/CEO failure feedback, persisted and delivered down the chain Every bounce used to survive only as flattened prose: rounds overwrote each other in notes_structured, request_changes persisted nothing, two raw dev_notes appends were silently destroyed by the next handoff note, and the dev prompt pointed at fields (qa_notes via evidence(), pm_notes) the API never delivered. Agents re-interpreted and re-discovered every failure before they could start fixing it. - task_review_findings (migration 071, append-only): file/line/severity/ criterion(AC-id-validated)/expected/actual/fix/evidence per finding, with origin (qa|pr_gate|pm|ceo), round, and an open->addressed->verified lifecycle (waived reserved); new tasks.pm_notes + PmReviewContent give request_changes a structured home - producers: fail_review/pr_fail/request_changes take findings=[...] (prose issues shimmed+merged for one release, deprecation-logged); ceo_reject validates its reason (no 500), lands an origin=ceo finding, and bumps round+audit on branchless coordination roots; guardrails at the verb chokepoint (nudge >5, hard reject >10, field caps, traversal-safe file); the dev_notes data-loss appends are removed; new task.request_changes + task.ceo_reject audit events close rework attribution - delivery: qa_notes/pr_reviewer_notes/pm_notes carry the deterministic [F-id8] rendering; claim briefings, evidence(), the REVISION_REQUIRED spawn prompt, PM triage bounced-blocks, and A2A bodies deliver open findings; round-N+1 QA and gate reviewers get the full prior ledger; panel Findings tab + bounced-xN chip; metrics pm_rejects/ceo_rejects + findings counts; vault task notes render a Findings section (fail-open) - resolution closes for every origin: i_am_done and submit_up/submit_root take resolved_findings gated by FINDINGS_ADDRESSED (owner-gated so a stale non-owner PM can never mutate the ledger); pass_review/pr_pass/ complete verify-stamp same-transaction; ceo_approve stamps best-effort - 24 real-DB integration tests drive the full loop through the real choreographer; full suite 12856 green * docs: revision findings ledger sweep — CLAUDE.md, map, RAG corpus - CLAUDE.md: new ledger section + corrected request_changes row - docs/map/review-findings.md (new subsystem map) + surgical updates to task-service/pr-gate-review/metrics-observability/vault/panel maps - docs/rag: producers' findings contract across qa/pr-reviewer/developer/ cell-pm/main-pm/ceo role docs (the PM docs were missing request_changes entirely), verb references, and a new architecture/review-findings.md disambiguating ledger findings from convention findings * test(e2e): resubmit resolves the pr_fail finding per the ledger contract The scripted pr_fail revision loop resubmitted submit_up without resolved_findings — correctly rejected now that FINDINGS_ADDRESSED gates the PM resubmit verbs (green locally, red only in CI since the e2e suite skips without ROBOCO_E2E_SMOKE=1). The scripted PM now reads the open ledger row pr_fail persisted (new open_finding_ids arc helper) and resolves it on resubmit, asserting the open set drains — exercising the coordinator half of the new contract end to end. --------- Co-authored-by: Renn F <rennf93@users.noreply.github.com>
3.5 KiB
CEO Role
Identity
- Agent: ceo (Renzo - Human)
- Role:
ceo - Team: board
- Reports to: N/A (top of hierarchy)
Core Responsibilities
- Final authority on major decisions
- Approve major task completions
- Set strategic direction
- Oversee entire organization
How the CEO Acts
The CEO is a human and acts through the panel/UI, not through the agent gateway. There are no roboco_* MCP tools for the CEO — the lifecycle actions below (ceo_approve, ceo_reject) are buttons in the panel, backed by the HTTP API, not verbs an agent calls.
What the CEO CAN Do
- View ALL tasks organization-wide
- Approve or reject tasks in
awaiting_ceo_approval - Cancel tasks (CEO is one of the cancel-authorized roles)
- Set strategic direction
- Message any agent directly via A2A (
dm), unrestricted on the CEO's side
CEO Approval Workflow
When a Main PM or Board member escalates a major task via escalate_to_ceo, it lands in awaiting_ceo_approval. The CEO reviews in the panel and either:
- Approve — merges the PR, task →
completed(lifecycleceo_approve) - Request changes — task →
needs_revision(lifecycleceo_reject)
Both are panel actions; the agent that escalated simply idles until the CEO decides. Your rejection reason is no longer just a status note — it's persisted as one structured finding on the task's revision-findings ledger (visible in the task detail's Findings tab) and delivered to whoever reworks it via evidence(), exactly like a QA or PR-review bounce. An empty or placeholder reason is now rejected with a clear error instead of failing with a server error. See docs/rag/architecture/review-findings.md.
X posts and roadmap items (panel-only, not gateway verbs)
Two more CEO-only approval queues, both plain REST endpoints on the orchestrator (not lifecycle transitions, not agent-callable verbs):
- X (Twitter) posts —
GET/POST /api/x/posts{,/{id}/approve,/reject}. Every held release-announcement or mention-reply draft the X engine originates (ROBOCO_X_ENGINE_ENABLED) sits here; approve posts it to X (optionally with an edited body, up to 280 chars), reject cancels it with a reason. Credentials are set separately viaGET/POST /api/x/credentials(write-only — the API only ever returnshas_credentials). - Roadmap items —
GET /api/roadmap/cycles,POST /api/roadmap/cycles/{task_id}/items/{item_id}/{approve,reject}. Each weekly roadmap-engine cycle (ROBOCO_ROADMAP_ENGINE_ENABLED) the Product Owner authors 3-7 item drafts; approve materializes one as a BACKLOG task (source=roadmap), reject records your reason. Approval is per-item, not per-cycle — you can approve some and reject others from the same cycle.
Both are idempotent (re-approving an already-posted/already-materialized item is a no-op) and both are held artifacts — nothing here was ever dispatched to an agent before your decision.
Escalation
The CEO is the final escalation target:
Developer → Cell PM → Main PM → Product Owner → CEO
Only main_pm, product_owner, and head_marketing can escalate a task to the CEO (via escalate_to_ceo).
Communication
The CEO has no channels to monitor. Oversight is via task state (all tasks are visible in the panel), notifications, and direct A2A messages — the CEO can dm any agent at any time, unrestricted, while an agent may only reply inside a conversation the CEO opened.
The CEO communicates and decides through the panel/UI rather than calling the agent content tools (dm / notify) directly.