External/roboco
1
0
Fork 0
mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: reflow hard-wrapped prose to one line per paragraph

Browse Source 
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
2026-06-16 23:18:55 +02:00
parent 640a964b88
commit f48106cbb6
67 changed files with 504 additions and 1593 deletions
Download Patch File Download Diff File Expand all files Collapse all files
usage.md
+8 -28
View File
@@ -96,12 +96,7 @@ docker ps --filter "name=roboco-agent" -q | xargs docker stop
## Creating Tasks
`POST /api/tasks` has no silent defaults — `title`, `description` (min 20
chars), `acceptance_criteria` (at least one), `team`, `task_type`, `nature`,
and `estimated_complexity` are all required, plus exactly one of `project_id`
(the repo this task targets) or `product_id` (a cell→project map for a fan-out
task). See the `TaskCreate` schema in `roboco/models/task.py` (or the Swagger
UI at `/docs`) for the full field list and enum values.
`POST /api/tasks` has no silent defaults — `title`, `description` (min 20 chars), `acceptance_criteria` (at least one), `team`, `task_type`, `nature`, and `estimated_complexity` are all required, plus exactly one of `project_id` (the repo this task targets) or `product_id` (a cell→project map for a fan-out task). See the `TaskCreate` schema in `roboco/models/task.py` (or the Swagger UI at [docs](./docs)) for the full field list and enum values.
```bash
curl -X POST http://localhost:8000/api/tasks \
@@ -122,9 +117,7 @@ curl -X POST http://localhost:8000/api/tasks \
}'
```
Enum values: `task_type` ∈ {`code`, `documentation`, `research`, `planning`,
`design`, `administrative`}; `nature` ∈ {`technical`, `non_technical`};
`estimated_complexity` ∈ {`low`, `medium`, `high`}.
Enum values: `task_type` ∈ {`code`, `documentation`, `research`, `planning`, `design`, `administrative`}; `nature` ∈ {`technical`, `non_technical`}; `estimated_complexity` ∈ {`low`, `medium`, `high`}.
## Task Lifecycle
@@ -235,14 +228,9 @@ docker logs -f roboco-agent-be-dev-1
### Resource Usage
RAM is modest. Agent containers are spawned on demand and torn down when
their work is done, so you rarely have more than a handful live at once — and
the on-demand Intake and Secretary only run while you're interacting with them.
Steady-state memory is dominated by the standing services (Postgres, Redis,
and especially Ollama with its models loaded), not by the agents.
RAM is modest. Agent containers are spawned on demand and torn down when their work is done, so you rarely have more than a handful live at once — and the on-demand Intake and Secretary only run while you're interacting with them. Steady-state memory is dominated by the standing services (Postgres, Redis, and especially Ollama with its models loaded), not by the agents.
Measured at idle on the reference NAS (full stack up, no task running), the
standing services use roughly:
Measured at idle on the reference NAS (full stack up, no task running), the standing services use roughly:
| Service | RAM (idle) |
|---------|------------|
@@ -253,19 +241,11 @@ standing services use roughly:
| Redis | ~15 MB |
| nginx | ~10 MB |
So the whole standing stack idles around ~2.5 GB, almost all of it Ollama;
the application itself is a few hundred MB. (These are idle figures — peak
memory while agents are actively working will be higher, and is best read
live with `docker stats` while a task is in flight.)
So the whole standing stack idles around ~2.5 GB, almost all of it Ollama; the application itself is a few hundred MB.
Storage is the larger footprint: the image set. The agent images all build
`FROM` a shared base layer, so on disk they cost far less than their nominal
sizes added together. For reference, the panel image is ~230 MB, the
orchestrator ~0.9 GB, the agent base ~1.1 GB, and each agent image ~1.1 GB
(the frontend dev/QA images are larger, ~1.9 GB, for their browser/Node
toolchain) — but the shared base means the real on-disk total is well below
their sum. `docker system prune` reclaims old image versions, stopped agent
containers, and build cache (typically a few GB).
Under load it stays light. Measured with five agents working concurrently (two cells' developers plus a cell PM), each agent container used ~0.5–0.65 GB, and the whole stack — agents plus services — peaked around ~6.6 GB, roughly 5% of a 128 GB box. The orchestrator itself grows with concurrency (~150 MB idle → ~1 GB while managing several live agent sessions and their streams), and a developer briefly spikes to a few CPU cores while it is actively generating. Even at full-fleet peak you stay well under ~10 GB — RAM is not the constraint; storage is.
Storage is the larger footprint: the image set. The agent images all build `FROM` a shared base layer, so on disk they cost far less than their nominal sizes added together. For reference, the panel image is ~230 MB, the orchestrator ~0.9 GB, the agent base ~1.1 GB, and each agent image ~1.1 GB (the frontend dev/QA images are larger, ~1.9 GB, for their browser/Node toolchain) — but the shared base means the real on-disk total is well below their sum. `docker system prune` reclaims old image versions, stopped agent containers, and build cache (typically a few GB).
Monitor with:
```bash