2026-01-03 05:07:45 +01:00
# Escalation Workflow
## Escalation Chain
```
Developer/QA/Documenter
↓
Cell PM
↓
Main PM
↓
2026-06-05 17:20:36 +02:00
Product Owner / Head of Marketing (Board)
2026-01-03 05:07:45 +01:00
↓
CEO
```
2026-06-16 23:18:55 +02:00
`escalate_up` walks this chain **one rung at a time** — it auto-routes to your immediate escalation target; you cannot choose a higher level or skip a rung.
2026-01-03 05:07:45 +01:00
2026-06-16 23:18:55 +02:00
The one exception is `escalate_to_ceo` : it is a **separate** verb, available only to Main PM and the Board (Product Owner / Head of Marketing), that goes straight to the CEO for final approval of a major task. It is not part of the `escalate_up` chain.
2026-06-05 17:20:36 +02:00
## How to Escalate (up one rung)
2026-01-03 05:07:45 +01:00
```python
2026-06-05 17:20:36 +02:00
escalate_up (
task_id = "<task>" ,
reason = "Need clarification on the API contract" ,
2026-01-03 05:07:45 +01:00
)
```
2026-06-05 17:20:36 +02:00
Auto-routes to your escalation target (you cannot choose it).
2026-01-03 05:07:45 +01:00
2026-06-29 05:38:21 +02:00
`escalate_up` is refused on a **terminal** task (`completed` / `cancelled` ) — it returns `invalid_state` rather than resurrecting a finished task. Escalate live work only.
2026-01-03 05:07:45 +01:00
## When to Escalate
| Situation | Escalate To |
|-----------|-------------|
| Unclear requirements | Cell PM |
| Blocked by external factor | Cell PM |
| Blocked by another task | Cell PM |
| Cross-cell coordination | Main PM (via Cell PM) |
2026-06-05 17:20:36 +02:00
| Major feature ready for CEO sign-off | CEO (via `escalate_to_ceo` , PM/Board only) |
2026-01-03 05:07:45 +01:00
2026-06-05 17:20:36 +02:00
## Escalate vs Block
2026-01-03 05:07:45 +01:00
2026-06-05 17:20:36 +02:00
| Action | When | Verb |
2026-01-03 05:07:45 +01:00
|--------|------|------|
2026-06-05 17:20:36 +02:00
| **Escalate** | Need a decision / help from above | `escalate_up` |
| **Block** | Can't proceed on an external dependency | `i_am_blocked` |
2026-06-16 23:18:55 +02:00
There is no agent-facing "pause" verb. If you need to step off a task you claimed but haven't progressed, use `unclaim(task_id)` to return it to the pool.
2026-01-03 05:07:45 +01:00
## Blocking a Task
```python
2026-06-05 17:20:36 +02:00
i_am_blocked (
task_id = "<task>" ,
reason = "Waiting for the auth service to land" ,
blocker_type = "external" ,
what_needed = "auth-service /token endpoint deployed" ,
2026-01-03 05:07:45 +01:00
)
```
2026-06-05 17:20:36 +02:00
Your Cell PM is notified and is the one who can `unblock` it.
2026-01-03 05:07:45 +01:00
2026-06-05 17:20:36 +02:00
## CEO Escalation (Main PM / Board Only)
2026-01-03 05:07:45 +01:00
For major tasks requiring CEO approval:
```python
2026-06-05 17:20:36 +02:00
escalate_to_ceo (
task_id = "<task>" ,
reason = "Major feature ready for final review" ,
2026-01-03 05:07:45 +01:00
)
```
Requirements:
- Task must be in `awaiting_pm_review`
2026-04-19 16:13:42 +02:00
- PR must exist
2026-06-05 17:20:36 +02:00
- Only Main PM, Product Owner, or Head of Marketing can call it
- **PARENT TASKS ONLY** — subtasks cannot be escalated to CEO
2026-01-03 23:10:31 +01:00
2026-06-16 23:18:55 +02:00
If you need to escalate a subtask, escalate the parent task instead. The CEO reviews the complete feature, not individual components.
2026-01-03 05:07:45 +01:00
## Good Escalation Format
Include:
- What's the issue
- What context you have
- Specific question
- What you already tried
- How it's affecting work
## Handling Escalations (PM)
2026-06-05 17:20:36 +02:00
1. ACK the notification: `notify_ack(notification_id)`
2026-07-04 03:10:33 +02:00
2. Investigate: read the task and journals
2026-06-05 17:20:36 +02:00
3. Decide, or escalate further with `escalate_up`
2026-07-04 03:10:33 +02:00
4. Communicate the decision (`dm` / `notify` )
2026-06-25 01:07:05 +02:00
5. Unblock if needed: `unblock(task_id, reason)`
2026-01-03 05:07:45 +01:00
2026-06-25 01:07:05 +02:00
CRITICAL: Verbal resolution is NOT enough. To clear a block you MUST call `unblock(task_id, reason)` . The `reason` (why you are clearing the block) is recorded as your `journal:decision` — no separate `note(scope='decision')` call is required.