coulomb/state-hub
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Cleanup of documentation

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-02 00:46:07 +02:00
parent a00f1b615b
commit e521f267ca
9 changed files with 113 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
dashboard/src/docs/capabilities.md
View File

@@ -96,7 +96,7 @@ This means the requester never needs to know which domain owns a capability.
---
## Request lifecycle
## Request flow
```
requested → accepted → in_progress → ready_for_review → completed
@@ -105,7 +105,7 @@ requested → accepted → in_progress → ready_for_review → completed
withdrawn
```
| Status | Meaning |
| Workstation | Meaning |
|--------|---------|
| **requested** | Need declared; routed (or broadcast) to provider |
| **accepted** | Provider acknowledged and claimed the request |
@@ -115,14 +115,17 @@ requested → accepted → in_progress → ready_for_review → completed
| **rejected** | Provider cannot or will not fulfil the request |
| **withdrawn** | Requester cancelled the request |
Transitions are enforced by the API — you cannot skip stages. Terminal states
(`completed`, `rejected`, `withdrawn`) allow no further transitions.
Request movement is flow-aware. The API evaluates the target workstation's
entry assertions and rejects unreachable movement with machine-readable
blocking assertions. Terminal workstations (`completed`, `rejected`,
`withdrawn`) have no reachable outgoing path in the current flow definition.
---
## Auto-notifications
Every lifecycle transition creates an **AgentMessage** atomically:
Every request movement handled by the capability request API creates an
**AgentMessage** atomically:
| Transition | Notification to |
|------------|----------------|
@@ -182,17 +185,17 @@ accept_capability_request(
)
```
Then advances through the lifecycle:
Then advances through the flow:
```
update_capability_request_status(request_id, "in_progress")
update_capability_request_status(request_id, "ready_for_review", note="Instance up at 10.0.1.42")
advance_workstation(entity_type="capability_request", entity_id=request_id, target_workstation="in_progress")
advance_workstation(entity_type="capability_request", entity_id=request_id, target_workstation="ready_for_review")
```
The requester reviews and completes:
```
update_capability_request_status(request_id, "completed", note="Verified, looks good")
advance_workstation(entity_type="capability_request", entity_id=request_id, target_workstation="completed")
```
---
@@ -203,7 +206,7 @@ The Capabilities page shows:
- **KPI sidebar** — open count, average fulfillment time, high/critical count
- **Summary cards** — requested, in progress, ready for review, completed
- **Kanban board** — cards grouped by status column
- **Kanban board** — cards grouped by workstation/status column
- **Table** — all requests with filters by type, status, and domain
Each card shows the capability type, priority, requester → provider domains,