Overviewالعربية
INTEGRATION CONTRACT

One API under /api and /api/v1

Send Authorization: Bearer TOKEN. /api/v1 rewrites to the same implementation, preventing two divergent contracts.

01

Identity and capabilities

The token determines project and capability; hiding a UI control is never authorization.

  • project:owner — full project control
  • srs:edit — permitted SRS edits, validation, and impact
  • widget:write — issue/evidence and run-state submission
  • agent:execute — commands, credential lease, test results
  • read:demo — only when the demo is explicitly enabled
02

Project and SRS

Project sources, canonical graph, and overlays.

  • GET/POST /api/projects
  • GET /api/srs-graph and /api/srs-source-audit
  • GET /api/srs-story/:id and /api/srs-workflow/:id
  • POST/PATCH /api/story-edits
  • POST/DELETE /api/story-additions
  • GET/POST /api/project-traceability and /api/validation-transfer
03

Quality and execution

Test planning, state, and results.

  • GET/POST/PATCH /api/test-commands
  • GET/POST /api/test-runs
  • GET/POST /api/run-state
  • POST /api/agent/plan and /api/agent/suite
  • GET/POST /api/project-scenarios
  • GET /api/route-catalog and /api/route-candidates
04

Issues, evidence, and health

Every issue remains project-scoped.

  • GET/POST /api/issues and PATCH /api/issues/:id
  • POST /api/issues/:id/attachments
  • GET /api/files/:key through a signed path
  • GET/POST/PATCH /api/system-logs
  • GET /api/health and GET /api/ready
  • GET /api/project-handoff for machine-readable handoff