mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
e125ef08aa
The header chip and the Settings User Info card rendered a literal 'Renzo'. The name now lives in the system_settings store under ceo_name (validated: trimmed, non-empty, max 60 chars) with the same client-served default the transcript-retention card uses, editable inline from the User Info card. Agent prompts already refer to 'the CEO' generically, so no prompt rewiring; the two agent-facing RAG docs drop the name too. License/CLA copyright is untouched. Co-authored-by: Renn F <rennf93@users.noreply.github.com>
62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# CEO Role
|
|
|
|
## Identity
|
|
|
|
- **Agent**: ceo (Human)
|
|
- **Role**: `ceo`
|
|
- **Team**: board
|
|
- **Reports to**: N/A (top of hierarchy)
|
|
|
|
## Core Responsibilities
|
|
|
|
1. Final authority on major decisions
|
|
2. Approve major task completions
|
|
3. Set strategic direction
|
|
4. 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` (lifecycle `ceo_approve`)
|
|
- **Request changes** — task → `needs_revision` (lifecycle `ceo_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 via `GET/POST /api/x/credentials` (write-only — the API only ever returns `has_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.
|