cameleer/cameleer-server
1
0
Fork 0
Code Issues 41 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: define v1 requirements (32 requirements, 6 categories)

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
hsiegeln
2026-03-11 11:15:04 +01:00
parent 6f39e29707
commit e11496242f
1 changed files with 105 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

105
.planning/REQUIREMENTS.md Normal file
View File

@@ -0,0 +1,105 @@
# Requirements: Cameleer3 Server
**Defined:** 2026-03-11
**Core Value:** Users can reliably search and find any transaction across all connected Camel instances — by any combination of state, time, duration, or content — even at millions of transactions per day with 30-day retention.
## v1 Requirements
Requirements for initial release. Each maps to roadmap phases. Tracked as Gitea issues.
### Data Ingestion
- [ ] **INGST-01**: Server accepts `RouteExecution` (single or array) via `POST /api/v1/data/executions` and returns `202 Accepted` (#1)
- [ ] **INGST-02**: Server accepts `RouteGraph` (single or array) via `POST /api/v1/data/diagrams` and returns `202 Accepted` (#2)
- [ ] **INGST-03**: Server accepts metrics snapshots via `POST /api/v1/data/metrics` and returns `202 Accepted` (#3)
- [ ] **INGST-04**: Ingestion uses in-memory batch buffer with configurable flush interval/size for ClickHouse writes (#4)
- [ ] **INGST-05**: Server returns `503 Service Unavailable` when write buffer is full (backpressure) (#5)
- [ ] **INGST-06**: ClickHouse TTL automatically expires data after 30 days (configurable) (#6)
### Transaction Search
- [ ] **SRCH-01**: User can search transactions by execution status (COMPLETED, FAILED, RUNNING) (#7)
- [ ] **SRCH-02**: User can search transactions by date/time range (startTime, endTime) (#8)
- [ ] **SRCH-03**: User can search transactions by duration range (min/max milliseconds) (#9)
- [ ] **SRCH-04**: User can search transactions by correlationId to find all related executions across instances (#10)
- [ ] **SRCH-05**: User can full-text search across message bodies, headers, error messages, and stack traces (#11)
- [ ] **SRCH-06**: User can view transaction detail with nested processor execution tree (#12)
### Agent Management
- [ ] **AGNT-01**: Agent registers via `POST /api/v1/agents/register` with bootstrap token, receives JWT + server public key (#13)
- [ ] **AGNT-02**: Server maintains agent registry with LIVE/STALE/DEAD lifecycle based on heartbeat timing (#14)
- [ ] **AGNT-03**: Agent sends heartbeat via `POST /api/v1/agents/{id}/heartbeat` every 30s (#15)
- [ ] **AGNT-04**: Server pushes `config-update` events to agents via SSE with Ed25519 signature (#16)
- [ ] **AGNT-05**: Server pushes `deep-trace` commands to agents via SSE for specific correlationIds (#17)
- [ ] **AGNT-06**: Server pushes `replay` commands to agents via SSE with signed replay tokens (#18)
- [ ] **AGNT-07**: SSE connection includes `ping` keepalive and supports `Last-Event-ID` reconnection (#19)
### Route Diagrams
- [ ] **DIAG-01**: Server stores `RouteGraph` definitions with content-addressable versioning (hash-based dedup) (#20)
- [ ] **DIAG-02**: Each transaction links to the `RouteGraph` version that was active at execution time (#21)
- [ ] **DIAG-03**: Server renders route diagrams from stored `RouteGraph` definitions (nodes, edges, EIP patterns) (#22)
### Security
- [ ] **SECU-01**: All API endpoints (except health and register) require valid JWT Bearer token (#23)
- [ ] **SECU-02**: JWT refresh flow via `POST /api/v1/agents/{id}/refresh` (#24)
- [ ] **SECU-03**: Server generates Ed25519 keypair; public key delivered at registration (#25)
- [ ] **SECU-04**: All config-update and replay SSE payloads are signed with server's Ed25519 private key (#26)
- [ ] **SECU-05**: Bootstrap token from `CAMELEER_AUTH_TOKEN` env var validates initial agent registration (#27)
### REST API
- [ ] **API-01**: All endpoints follow the protocol v1 path structure (`/api/v1/...`) (#28)
- [ ] **API-02**: API documented via OpenAPI/Swagger (springdoc-openapi) (#29)
- [ ] **API-03**: Server includes `GET /api/v1/health` endpoint (#30)
- [ ] **API-04**: All requests validated for `X-Cameleer-Protocol-Version: 1` header (#31)
- [ ] **API-05**: Server accepts unknown JSON fields for forward compatibility (#32)
## v2 Requirements
Deferred to future release. Tracked but not in current roadmap.
### Web UI
- **UI-01**: Transaction search form and result list view
- **UI-02**: Transaction detail view with activity drill-down
- **UI-03**: Route diagram visualization with execution overlay
- **UI-04**: Agent status overview dashboard
- **UI-05**: Dashboard with volume/error trend charts
### Advanced Search
- **ASRCH-01**: Cursor-based pagination for large result sets
- **ASRCH-02**: Saved search queries
## Out of Scope
| Feature | Reason |
|---------|--------|
| Mobile app | Web UI sufficient for ops/dev users |
| Log aggregation | Transaction-level observability, not a log collector |
| APM/metrics dashboards | Focused on Camel route transactions, not general application metrics |
| Multi-tenancy | Single-tenant deployment per environment |
| Kafka transport | HTTP POST ingestion is the primary path; Kafka is agent-side concern |
| Custom dashboards | Fixed dashboard views; no user-configurable widgets |
| Real-time firehose | Not a streaming platform; query-based access |
| AI root cause analysis | Out of scope for v1; focus on search and visualization |
## Traceability
Which phases cover which requirements. Updated during roadmap creation.
| Requirement | Phase | Status |
|-------------|-------|--------|
| (populated by roadmapper) | | |
**Coverage:**
- v1 requirements: 32 total
- Mapped to phases: 0
- Unmapped: 32
---
*Requirements defined: 2026-03-11*
*Last updated: 2026-03-11 after initial definition*