mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
docs: reflow hard-wrapped prose to one line per paragraph
Markdown and editors soft-wrap on their own, so the manual ~75-char line breaks across the docs added nothing but noise. Join wrapped prose, list items, and paragraphs into single lines across 67 docs — README, CLAUDE.md, deployment, usage, the RAG knowledge base, and the agent role prompts. Whitespace-only: code fences, tables, and blockquote alerts are byte-identical and the change is token-verified (no content altered). Applied with a deterministic reflow tool (committed separately). Also lands two doc edits that were awaiting commit: the measured under-load resource numbers in usage.md and the pr_reviewer additions to the org-structure RAG doc.
This commit is contained in:
Renn F
@@ -73,8 +73,7 @@ delegate(assigned_to="00000000-0000-0000-0001-000000000001", ...)
|
||||
|
||||
## Usage
|
||||
|
||||
Verbs take the `task_id` UUID directly (returned by `give_me_work()` /
|
||||
`triage()`); recipient/assignee arguments accept either a slug or a UUID:
|
||||
Verbs take the `task_id` UUID directly (returned by `give_me_work()` / `triage()`); recipient/assignee arguments accept either a slug or a UUID:
|
||||
```python
|
||||
i_will_work_on(task_id) # task_id is a UUID
|
||||
dm(recipient="be-qa", text="...", task_id="...") # slug recipient
|
||||
|
||||
@@ -44,18 +44,13 @@ Auditor has silent read access (in these channels' `silent_roles`) to:
|
||||
- `pm-all`
|
||||
- `doc-all`
|
||||
|
||||
Auditor does NOT appear in member lists but CAN read. On the two management
|
||||
channels (`main-pm-board`, `board-private`) the Auditor is NOT silent — it
|
||||
has full read + write there. (Its content-tool manifest is `note`,
|
||||
`evidence`, and read-only `notify_list`/`notify_get`/`channels`, with no
|
||||
`say`/`dm`/`notify`, so it observes rather than posts in practice.)
|
||||
Auditor does NOT appear in member lists but CAN read. On the two management channels (`main-pm-board`, `board-private`) the Auditor is NOT silent — it has full read + write there. (Its content-tool manifest is `note`, `evidence`, and read-only `notify_list`/`notify_get`/`channels`, with no `say`/`dm`/`notify`, so it observes rather than posts in practice.)
|
||||
|
||||
## Privileged Access
|
||||
|
||||
These roles bypass normal membership checks:
|
||||
- **CEO**: Full access everywhere
|
||||
- **Auditor**: Silent read on cell + cross-cell channels; read/write on the
|
||||
management channels
|
||||
- **Auditor**: Silent read on cell + cross-cell channels; read/write on the management channels
|
||||
- **Main PM**: Read access to all cell channels
|
||||
|
||||
## Using Channels
|
||||
|
||||
@@ -33,9 +33,7 @@
|
||||
| #main-pm-board | Main PM, Product Owner, Head Marketing, Auditor |
|
||||
| #board-private | Product Owner, Head Marketing, Auditor, CEO, Main PM |
|
||||
|
||||
In both management channels the Auditor has read **and** write (it is NOT
|
||||
silent here — that downgrade applies only to the cell and cross-cell
|
||||
channels). In #board-private the Main PM can read but cannot write.
|
||||
In both management channels the Auditor has read **and** write (it is NOT silent here — that downgrade applies only to the cell and cross-cell channels). In #board-private the Main PM can read but cannot write.
|
||||
|
||||
## Special Channels
|
||||
|
||||
@@ -51,12 +49,7 @@ Auditor has **silent read access** to the cell and cross-cell channels:
|
||||
- Cannot send messages there
|
||||
- Observes all activity
|
||||
|
||||
The Auditor is silent only on cell + cross-cell channels (it is in those
|
||||
channels' `silent_roles`). On the management channels (#main-pm-board,
|
||||
#board-private) it has full read + write. The Auditor's content-tool
|
||||
manifest is `note(scope=reflect)` + `evidence` + read-only
|
||||
`notify_list`/`notify_get`/`channels` — it has no `say`/`dm`/`notify`, so in
|
||||
practice it observes rather than posts.
|
||||
The Auditor is silent only on cell + cross-cell channels (it is in those channels' `silent_roles`). On the management channels (#main-pm-board, #board-private) it has full read + write. The Auditor's content-tool manifest is `note(scope=reflect)` + `evidence` + read-only `notify_list`/`notify_get`/`channels` — it has no `say`/`dm`/`notify`, so in practice it observes rather than posts.
|
||||
|
||||
## Channel Access Rules
|
||||
|
||||
@@ -72,8 +65,7 @@ practice it observes rather than posts.
|
||||
|
||||
## Messaging
|
||||
|
||||
Agents post to channels with the `say` content tool (there is no
|
||||
`roboco_message_send` tool):
|
||||
Agents post to channels with the `say` content tool (there is no `roboco_message_send` tool):
|
||||
|
||||
```python
|
||||
say(
|
||||
@@ -83,7 +75,4 @@ say(
|
||||
)
|
||||
```
|
||||
|
||||
For direct agent-to-agent messages, use `dm(recipient, text)` (same-cell
|
||||
only; cross-cell is denied — escalate via your Cell PM instead). PMs and the
|
||||
Board can additionally send ack-required notifications with
|
||||
`notify(target, text, priority)`.
|
||||
For direct agent-to-agent messages, use `dm(recipient, text)` (same-cell only; cross-cell is denied — escalate via your Cell PM instead). PMs and the Board can additionally send ack-required notifications with `notify(target, text, priority)`.
|
||||
|
||||
@@ -1,9 +1,6 @@
|
||||
# Company Layer (Goals, Pitches, Strategy)
|
||||
|
||||
The **company layer** sits above day-to-day delivery: the CEO's charter, the
|
||||
pitch pipeline, and a background strategy watcher. The charter is always
|
||||
available (empty until set); the research, provisioning, and strategy-engine
|
||||
pieces are **opt-in and default-off** — the org runs fine without any of them.
|
||||
The **company layer** sits above day-to-day delivery: the CEO's charter, the pitch pipeline, and a background strategy watcher. The charter is always available (empty until set); the research, provisioning, and strategy-engine pieces are **opt-in and default-off** — the org runs fine without any of them.
|
||||
|
||||
## The Charter (Company Goals)
|
||||
|
||||
@@ -16,14 +13,12 @@ A single, CEO-owned charter is the company's north star. It has four parts:
|
||||
| `constraints` | Hard limits the company must respect |
|
||||
| `operating_policy` | Operating rules (e.g. a monthly budget cap) |
|
||||
|
||||
The charter is a **singleton**, and it is injected — compactly — into **every
|
||||
agent's briefing**, so all work is goal-aware without anyone fetching it.
|
||||
The charter is a **singleton**, and it is injected — compactly — into **every agent's briefing**, so all work is goal-aware without anyone fetching it.
|
||||
|
||||
- `GET /api/company-goals` — read (any agent)
|
||||
- `PUT /api/company-goals` — write (CEO only)
|
||||
|
||||
It is empty until the CEO sets it; an empty charter simply contributes nothing
|
||||
to briefings.
|
||||
It is empty until the CEO sets it; an empty charter simply contributes nothing to briefings.
|
||||
|
||||
## Pitches
|
||||
|
||||
@@ -35,30 +30,17 @@ A **pitch** is a proposal for new product work. Its lifecycle is small:
|
||||
| `provisioned` | Approved — turned into a product / project(s) |
|
||||
| `rejected` | Declined |
|
||||
|
||||
When a pitch is approved and **provisioning is enabled**
|
||||
(`ROBOCO_PROVISIONING_ENABLED` plus a GitHub token and org), it can auto-create
|
||||
the product and its repositories (recorded in `provisioned_product_id` /
|
||||
`provisioned_project_ids`). With provisioning off, approval just records the
|
||||
decision.
|
||||
When a pitch is approved and **provisioning is enabled** (`ROBOCO_PROVISIONING_ENABLED` plus a GitHub token and org), it can auto-create the product and its repositories (recorded in `provisioned_product_id` / `provisioned_project_ids`). With provisioning off, approval just records the decision.
|
||||
|
||||
## Strategy Engine
|
||||
|
||||
The Strategy Engine is a **notify-only** background watcher
|
||||
(`ROBOCO_STRATEGY_ENGINE_ENABLED`, default off). Each cycle it `assess()`es the
|
||||
company against its standing goals and emits `StrategyObservation`s — each a
|
||||
`kind`, a `summary`, and a `detail` — for example `idle` (capacity sitting
|
||||
unused) or `stranded_blocked` (work stuck in `blocked`). It only **observes and
|
||||
surfaces**; it never acts on its own.
|
||||
The Strategy Engine is a **notify-only** background watcher (`ROBOCO_STRATEGY_ENGINE_ENABLED`, default off). Each cycle it `assess()`es the company against its standing goals and emits `StrategyObservation`s — each a `kind`, a `summary`, and a `detail` — for example `idle` (capacity sitting unused) or `stranded_blocked` (work stuck in `blocked`). It only **observes and surfaces**; it never acts on its own.
|
||||
|
||||
Those observations are the "needs your attention" signals shown on the
|
||||
Dashboard, served by `GET /api/cockpit/signals`.
|
||||
Those observations are the "needs your attention" signals shown on the Dashboard, served by `GET /api/cockpit/signals`.
|
||||
|
||||
## The Secretary
|
||||
|
||||
The CEO's chief-of-staff reads this layer (`read_company_state` returns the
|
||||
charter, task counts, pending pitches, and any directives awaiting
|
||||
confirmation) and acts on it via gated directives. See
|
||||
`docs/rag/roles/secretary.md`.
|
||||
The CEO's chief-of-staff reads this layer (`read_company_state` returns the charter, task counts, pending pitches, and any directives awaiting confirmation) and acts on it via gated directives. See `docs/rag/roles/secretary.md`.
|
||||
|
||||
## Feature Toggles
|
||||
|
||||
@@ -68,5 +50,4 @@ confirmation) and acts on it via gated directives. See
|
||||
| `ROBOCO_STRATEGY_ENGINE_ENABLED` | off | The strategy watcher loop |
|
||||
| `ROBOCO_PROVISIONING_ENABLED` | off | Pitch → auto-provisioned repos |
|
||||
|
||||
All are additive: with every toggle off, the company layer is just the charter
|
||||
plus the pitch record.
|
||||
All are additive: with every toggle off, the company layer is just the charter plus the pitch record.
|
||||
|
||||
@@ -49,10 +49,7 @@ escalate_up(
|
||||
)
|
||||
```
|
||||
|
||||
Auto-routes to your escalation target. You CANNOT choose a different
|
||||
target. `escalate_up` is a PM verb (Cell PM / Main PM); cell members
|
||||
(devs, QA, documenters) signal blockers with `i_am_blocked(task_id,
|
||||
reason)`, which their Cell PM resolves.
|
||||
Auto-routes to your escalation target. You CANNOT choose a different target. `escalate_up` is a PM verb (Cell PM / Main PM); cell members (devs, QA, documenters) signal blockers with `i_am_blocked(task_id, reason)`, which their Cell PM resolves.
|
||||
|
||||
## CEO Escalation (Main PM / Board Only)
|
||||
|
||||
@@ -66,8 +63,7 @@ escalate_to_ceo(
|
||||
Requirements:
|
||||
- Task in `awaiting_pm_review`
|
||||
- PR exists
|
||||
- Only Main PM, Product Owner, or Head of Marketing can call this
|
||||
(Cell PMs cannot — they `escalate_up` to Main PM first)
|
||||
- Only Main PM, Product Owner, or Head of Marketing can call this (Cell PMs cannot — they `escalate_up` to Main PM first)
|
||||
|
||||
## Cannot Skip Levels
|
||||
|
||||
|
||||
@@ -38,18 +38,14 @@ CEO (Renzo - Human)
|
||||
|
||||
## On-Demand Roles (Human-Facing)
|
||||
|
||||
Two of the 22 — the Prompter (Intake) and the Secretary — sit outside the
|
||||
standing delivery org above. They are **human-only** and **spawned on demand**
|
||||
as live chat sessions; they are counted among the 22, but unlike the standing
|
||||
org they have no lifecycle verbs and no outward agent comms:
|
||||
Two of the 22 — the Prompter (Intake) and the Secretary — sit outside the standing delivery org above. They are **human-only** and **spawned on demand** as live chat sessions; they are counted among the 22, but unlike the standing org they have no lifecycle verbs and no outward agent comms:
|
||||
|
||||
| Role | Purpose |
|
||||
|------|---------|
|
||||
| Prompter (Intake) | Interviews the CEO and drafts a board-ready task |
|
||||
| Secretary | The CEO's chief-of-staff; reads company state and runs gated CEO directives |
|
||||
|
||||
Neither has lifecycle verbs or outward agent comms. See
|
||||
`docs/rag/roles/prompter.md` and `docs/rag/roles/secretary.md`.
|
||||
Neither has lifecycle verbs or outward agent comms. See [Prompter](../roles/prompter.md) and [Secretary](../roles/secretary.md).
|
||||
|
||||
## Cells
|
||||
|
||||
|
||||
@@ -29,16 +29,10 @@ What each role can do in the system.
|
||||
| Docs Complete (`i_documented`) | - | - | - | - | - | - | - | Yes |
|
||||
|
||||
Notes (verified against `roboco/foundation/policy/lifecycle.py`):
|
||||
- **Create / Assign** (`create_subtask`, `delegate`) are PM-only: `cell_pm`
|
||||
and `main_pm`. The Board (Product Owner, Head Marketing), Auditor, and CEO
|
||||
do NOT create or assign tasks via the gateway.
|
||||
- **Cancel** is allowed to PM roles + CEO (`cell_pm`, `main_pm`, `ceo`). The
|
||||
Board and Auditor CANNOT cancel.
|
||||
- **Complete** (final approve/merge) is PM-only (`cell_pm`, `main_pm`). The
|
||||
CEO acts only on tasks escalated to `awaiting_ceo_approval`.
|
||||
- **Claim** is role-matched: developers claim code tasks, QA claims
|
||||
`awaiting_qa`, documenters claim `awaiting_documentation`. PMs can claim
|
||||
the planning/coordination work assigned to them.
|
||||
- **Create / Assign** (`create_subtask`, `delegate`) are PM-only: `cell_pm` and `main_pm`. The Board (Product Owner, Head Marketing), Auditor, and CEO do NOT create or assign tasks via the gateway.
|
||||
- **Cancel** is allowed to PM roles + CEO (`cell_pm`, `main_pm`, `ceo`). The Board and Auditor CANNOT cancel.
|
||||
- **Complete** (final approve/merge) is PM-only (`cell_pm`, `main_pm`). The CEO acts only on tasks escalated to `awaiting_ceo_approval`.
|
||||
- **Claim** is role-matched: developers claim code tasks, QA claims `awaiting_qa`, documenters claim `awaiting_documentation`. PMs can claim the planning/coordination work assigned to them.
|
||||
|
||||
## Index Permissions
|
||||
|
||||
@@ -55,9 +49,7 @@ Note: Board (Product Owner, Head Marketing) can only index docs, not code.
|
||||
|
||||
## Notification Permissions
|
||||
|
||||
Sending notifications means calling the `notify(target, text, priority)`
|
||||
content tool. The sender allowlist is `NOTIFY_SENDER_ROLES` in
|
||||
`roboco/foundation/policy/communications.py`.
|
||||
Sending notifications means calling the `notify(target, text, priority)` content tool. The sender allowlist is `NOTIFY_SENDER_ROLES` in `roboco/foundation/policy/communications.py`.
|
||||
|
||||
| Role | Can Send (`notify`) | Scope |
|
||||
|------|---------------------|-------|
|
||||
@@ -71,26 +63,19 @@ content tool. The sender allowlist is `NOTIFY_SENDER_ROLES` in
|
||||
| qa | No | - |
|
||||
| documenter | No | - |
|
||||
|
||||
Non-senders (developer, qa, documenter, auditor) still communicate via
|
||||
`say(channel, text)` for channel posts and `dm(recipient, text)` for direct
|
||||
agent-to-agent messages — those are not ack-required notifications. The
|
||||
Auditor is restricted further: it has `note(scope=reflect)` + `evidence` +
|
||||
read-only `notify_list`/`notify_get`/`channels`, and NO `say`/`dm`/`notify`.
|
||||
Non-senders (developer, qa, documenter, auditor) still communicate via `say(channel, text)` for channel posts and `dm(recipient, text)` for direct agent-to-agent messages — those are not ack-required notifications. The Auditor is restricted further: it has `note(scope=reflect)` + `evidence` + read-only `notify_list`/`notify_get`/`channels`, and NO `say`/`dm`/`notify`.
|
||||
|
||||
## Task-Creator Roles
|
||||
|
||||
These roles can create/assign tasks (`create_subtask`, `delegate` — PM-only
|
||||
per `lifecycle.py`):
|
||||
These roles can create/assign tasks (`create_subtask`, `delegate` — PM-only per `lifecycle.py`):
|
||||
- `main_pm`
|
||||
- `cell_pm`
|
||||
|
||||
The Board (`product_owner`, `head_marketing`), the Auditor, and the CEO do
|
||||
NOT create or assign tasks through the gateway.
|
||||
The Board (`product_owner`, `head_marketing`), the Auditor, and the CEO do NOT create or assign tasks through the gateway.
|
||||
|
||||
## Cancellation Roles
|
||||
|
||||
These roles can cancel tasks (the `cancel` action's `allowed_roles` in
|
||||
`lifecycle.py` = PM roles + CEO):
|
||||
These roles can cancel tasks (the `cancel` action's `allowed_roles` in `lifecycle.py` = PM roles + CEO):
|
||||
- `cell_pm`
|
||||
- `main_pm`
|
||||
- `ceo`
|
||||
|
||||
@@ -16,17 +16,9 @@
|
||||
|
||||
## Acceptance-Criteria Tracking
|
||||
|
||||
Every task's `acceptance_criteria` get a parallel list of stable
|
||||
`acceptance_criteria_ids` — one id per criterion, generated automatically when a
|
||||
task is created. The ids are stable across edits, so other tasks can reference a
|
||||
specific criterion.
|
||||
Every task's `acceptance_criteria` get a parallel list of stable `acceptance_criteria_ids` — one id per criterion, generated automatically when a task is created. The ids are stable across edits, so other tasks can reference a specific criterion.
|
||||
|
||||
When a parent task is decomposed, each subtask declares which parent criteria it
|
||||
covers in `parent_ac_refs` (set from the `covers_parent_criteria` argument to
|
||||
`delegate`). That child→parent link is what lets the org guarantee a
|
||||
decomposition actually covers the parent's full intent. See
|
||||
`docs/rag/workflows/task-planning.md` for the coverage gates and the PM's
|
||||
coverage briefing.
|
||||
When a parent task is decomposed, each subtask declares which parent criteria it covers in `parent_ac_refs` (set from the `covers_parent_criteria` argument to `delegate`). That child→parent link is what lets the org guarantee a decomposition actually covers the parent's full intent. See `docs/rag/workflows/task-planning.md` for the coverage gates and the PM's coverage briefing.
|
||||
|
||||
## Task Types
|
||||
|
||||
|
||||
@@ -10,37 +10,25 @@ Agents call gateway verbs through three MCP servers, scoped per role:
|
||||
| `roboco-do` | Content/write verbs (commit, note, say, dm, notify, evidence) |
|
||||
| `roboco-git-readonly` | Read-only git inspection (status, log, diff, branch_list) |
|
||||
|
||||
Native shell git is blocked by the bash-guard hook for everyone. There is
|
||||
**no** `roboco_git_commit / _push / _create_pr / _merge_pr / _checkout`
|
||||
tool — write operations happen through the lifecycle verbs and the
|
||||
choreographer handles git as a side-effect.
|
||||
Native shell git is blocked by the bash-guard hook for everyone. There is **no** `roboco_git_commit / _push / _create_pr / _merge_pr / _checkout` tool — write operations happen through the lifecycle verbs and the choreographer handles git as a side-effect.
|
||||
|
||||
The canonical source of role → verb mapping is
|
||||
`roboco/services/gateway/role_config.py`. The tables below summarise it.
|
||||
The canonical source of role → verb mapping is `roboco/services/gateway/role_config.py`. The tables below summarise it.
|
||||
|
||||
## Developer
|
||||
|
||||
**Flow verbs (roboco-flow):**
|
||||
`give_me_work`, `i_will_work_on`, `open_pr`, `i_am_done`,
|
||||
`i_am_blocked`, `unclaim`, `resume`, `i_am_idle`
|
||||
**Flow verbs (roboco-flow):** `give_me_work`, `i_will_work_on`, `open_pr`, `i_am_done`, `i_am_blocked`, `unclaim`, `resume`, `i_am_idle`
|
||||
|
||||
**Content verbs (roboco-do):**
|
||||
`commit`, `note`, `say`, `dm`, `evidence`
|
||||
**Content verbs (roboco-do):** `commit`, `note`, `say`, `dm`, `evidence`
|
||||
|
||||
**Read-only git (roboco-git-readonly):** all 4 (`status`, `log`, `diff`,
|
||||
`branch_list`)
|
||||
**Read-only git (roboco-git-readonly):** all 4 (`status`, `log`, `diff`, `branch_list`)
|
||||
|
||||
**Workspace writes:** `Write` / `Edit` in
|
||||
`/data/workspaces/{project}/{team}/{agent-id}/` only.
|
||||
**Workspace writes:** `Write` / `Edit` in `/data/workspaces/{project}/{team}/{agent-id}/` only.
|
||||
|
||||
## QA
|
||||
|
||||
**Flow verbs:**
|
||||
`give_me_work`, `claim_review`, `pass`, `fail`, `unclaim`, `resume`,
|
||||
`i_am_idle`
|
||||
**Flow verbs:** `give_me_work`, `claim_review`, `pass`, `fail`, `unclaim`, `resume`, `i_am_idle`
|
||||
|
||||
**Content verbs:**
|
||||
`note`, `say`, `dm`, `evidence` (no `commit` — QA does not write code)
|
||||
**Content verbs:** `note`, `say`, `dm`, `evidence` (no `commit` — QA does not write code)
|
||||
|
||||
**Read-only git:** all 4
|
||||
|
||||
@@ -48,27 +36,19 @@ The canonical source of role → verb mapping is
|
||||
|
||||
## Documenter
|
||||
|
||||
**Flow verbs:**
|
||||
`give_me_work`, `claim_doc_task`, `i_documented`, `unclaim`, `resume`,
|
||||
`i_am_idle`
|
||||
**Flow verbs:** `give_me_work`, `claim_doc_task`, `i_documented`, `unclaim`, `resume`, `i_am_idle`
|
||||
|
||||
**Content verbs:**
|
||||
`commit`, `note`, `say`, `dm`, `evidence`
|
||||
**Content verbs:** `commit`, `note`, `say`, `dm`, `evidence`
|
||||
|
||||
**Read-only git:** all 4
|
||||
|
||||
**Workspace writes:** docs files inside the agent's own workspace
|
||||
(`/data/workspaces/{project}/{team}/{agent-id}/`).
|
||||
**Workspace writes:** docs files inside the agent's own workspace (`/data/workspaces/{project}/{team}/{agent-id}/`).
|
||||
|
||||
## Cell PM
|
||||
|
||||
**Flow verbs:**
|
||||
`give_me_work`, `i_will_plan`, `delegate`, `submit_up`, `triage`,
|
||||
`unblock`, `complete`, `escalate_up`, `unclaim`, `resume`, `i_am_idle`
|
||||
**Flow verbs:** `give_me_work`, `i_will_plan`, `delegate`, `submit_up`, `triage`, `unblock`, `complete`, `escalate_up`, `unclaim`, `resume`, `i_am_idle`
|
||||
|
||||
**Content verbs:**
|
||||
`note`, `say`, `dm`, `notify`, `evidence` (no `commit` — PMs delegate
|
||||
code; merging the leaf PR happens automatically inside `complete`)
|
||||
**Content verbs:** `note`, `say`, `dm`, `notify`, `evidence` (no `commit` — PMs delegate code; merging the leaf PR happens automatically inside `complete`)
|
||||
|
||||
**Read-only git:** all 4
|
||||
|
||||
@@ -76,18 +56,13 @@ code; merging the leaf PR happens automatically inside `complete`)
|
||||
|
||||
## Main PM
|
||||
|
||||
**Flow verbs:**
|
||||
`give_me_work`, `i_will_plan`, `delegate`, `triage_all`, `unblock`,
|
||||
`complete`, `escalate_up`, `escalate_to_ceo`, `unclaim`, `resume`,
|
||||
`i_am_idle`
|
||||
**Flow verbs:** `give_me_work`, `i_will_plan`, `delegate`, `triage_all`, `unblock`, `complete`, `escalate_up`, `escalate_to_ceo`, `unclaim`, `resume`, `i_am_idle`
|
||||
|
||||
**Content verbs:**
|
||||
`note`, `say`, `dm`, `notify`, `evidence`
|
||||
**Content verbs:** `note`, `say`, `dm`, `notify`, `evidence`
|
||||
|
||||
**Read-only git:** all 4
|
||||
|
||||
**Workspace writes:** none. `complete` on a root parent task opens the
|
||||
master PR via the choreographer and escalates to CEO.
|
||||
**Workspace writes:** none. `complete` on a root parent task opens the master PR via the choreographer and escalates to CEO.
|
||||
|
||||
## Board (Product Owner, Head of Marketing)
|
||||
|
||||
@@ -101,8 +76,7 @@ master PR via the choreographer and escalates to CEO.
|
||||
|
||||
**Flow verbs:** `triage`, `i_am_idle` (read-only)
|
||||
|
||||
**Content verbs:** `note` (scope=reflect), `evidence` (no `say` / `dm`
|
||||
— Auditor observes silently)
|
||||
**Content verbs:** `note` (scope=reflect), `evidence` (no `say` / `dm` — Auditor observes silently)
|
||||
|
||||
**Read-only git:** none.
|
||||
|
||||
@@ -123,5 +97,4 @@ master PR via the choreographer and escalates to CEO.
|
||||
| `roboco_git_*` (read-only) | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
|
||||
| `Write` / `Edit` (own workspace) | ✓ | ✓ | — | — | — | — | — |
|
||||
|
||||
**CEO** is human and never inside an agent container; the panel runs as
|
||||
the CEO via `X-Agent-Role: ceo` against the orchestrator API directly.
|
||||
**CEO** is human and never inside an agent container; the panel runs as the CEO via `X-Agent-Role: ceo` against the orchestrator API directly.
|
||||
|
||||
@@ -57,11 +57,7 @@ ROBOCO_WORKSPACE_CLONE_TIMEOUT=300
|
||||
|
||||
## No Workspace Tools — It's Automatic
|
||||
|
||||
There are **no** agent-facing workspace tools. Workspaces are created and
|
||||
cloned for you by the orchestrator (`WorkspaceService`) before your
|
||||
container starts. You never `ensure`, `clone`, or `checkout` a workspace
|
||||
by hand — your repo is already on disk at the path below, and the gateway
|
||||
verbs (`i_will_work_on`, `claim_review`, ...) check out the right branch.
|
||||
There are **no** agent-facing workspace tools. Workspaces are created and cloned for you by the orchestrator (`WorkspaceService`) before your container starts. You never `ensure`, `clone`, or `checkout` a workspace by hand — your repo is already on disk at the path below, and the gateway verbs (`i_will_work_on`, `claim_review`, ...) check out the right branch.
|
||||
|
||||
## Workspace Resolution
|
||||
|
||||
@@ -76,7 +72,4 @@ HTTPS repositories require a GitHub PAT configured on the project:
|
||||
- **Token configured**: Auto-clone works, git operations succeed
|
||||
- **Token missing**: Error "Project requires a git token for HTTPS repositories"
|
||||
|
||||
**If you see this error**: Contact your PM. The project's git token is
|
||||
configured by a human in the control panel (project settings) — it is not
|
||||
an agent tool. The token is encrypted at rest and never exposed to your
|
||||
container; the orchestrator injects it into git operations for you.
|
||||
**If you see this error**: Contact your PM. The project's git token is configured by a human in the control panel (project settings) — it is not an agent tool. The token is encrypted at rest and never exposed to your container; the orchestrator injects it into git operations for you.
|
||||
|
||||
Reference in New Issue
Block a user