ProjexCloud — API QA Test Plan
Dependency-ordered execution plan for the full API surface. Each wave lists its prerequisites, the SDKs it covers and the expected-output contract QA asserts. Per-API request/response examples live in the API Reference.
681 APIs · 691 test cases · 9 waves
sdk-identity (POST /api/auth/register → login). It is the dependency root — 49 downstream APIs consume the principal token / tenant id it mints ({{cache:...}} references). Run it, cache the token, then proceed wave by wave. A wave only begins once the prior wave is green.Test environment setup
Bring up the full stack, then exercise the layers in order. The api-gateway auto-runs every SDK migration on first boot — no manual SQL. Only the analytics path (Kafka + ClickHouse) needs --full; the SDK-discovery embedding model runs in-process (no container).
# 1. Full stack up (Postgres + Redis + Kafka + ClickHouse) + seed ./scripts/setup/dev-setup.sh --full --seed # Windows: ./scripts/setup/dev-setup.ps1 -Full -Seed # 2. Run all services (gateway, projectors, collectors, discovery, apps) pnpm dev # 3. Unit / integration suites (separate terminal) — 97 vitest packages pnpm test # 4. API contract tests (gateway must be up) — 691 tests/api_definitions/*.json # driven by the ProjexLight runner, wave by wave (W0 -> W8): # projexlight_start_api_tests / projexlight_run_api_tests / projexlight_get_api_test_status # 5. Smoke: every service health endpoint curl http://localhost:3500/health # api-gateway curl http://localhost:3600/healthz # registry-mcp (discovery) curl http://localhost:8081/health # lineage-projector curl http://localhost:8082/health # semantic-service curl http://localhost:8083/health # pool-federation-runtime
Testing layers: (1) unit/integration pnpm test · (2) service smoke/health · (3) API contract tests over the 691 api_definitions in the wave order below · (4) path checks — discovery, and usage event → ClickHouse rollup + Postgres ledger (needs --full) · (5) deploy artifacts helm lint/template, terraform fmt.
Expected-output contract (all APIs)
Every endpoint returns the standard envelope. QA asserts on this shape plus the HTTP status documented per API:
Success: { "success": true, "data": { ... } | [ ... ] }
Error: { "success": false, "error": "<human-readable reason>" }| Method | Status | data shape |
|---|---|---|
| POST (create) | 201 | created resource: {<resource>_id, …payload, status, created_at, updated_at} |
| POST (action) | 200 | action outcome: {status:"completed", …} |
| GET (one) | 200 | single resource object |
| GET (list) | 200 | data:[ … ] (often with total) |
| PUT/PATCH | 200 | updated resource |
| DELETE | 200/204 | {success:true} |
| async | 202 | {status:"accepted", job_id} |
Wave order at a glance
| # | Wave | SDKs | APIs | Test cases |
|---|---|---|---|---|
| 0 | Foundation Spine (auth, tenant, routing, events) | 5 | 97 | 97 |
| 1 | Secrets, Audit & Telemetry (cross-cutting infra) | 6 | 24 | 24 |
| 2 | Identity Triad (MDM + ABAC + Consent) | 6 | 36 | 36 |
| 3 | Canonical Entities + Privacy | 6 | 33 | 33 |
| 4 | Operational Core + Billing | 2 | 27 | 27 |
| 5 | Engagement (Domain Layer) | 19 | 225 | 225 |
| 6 | Knowledge, Semantic & Agent Runtime | 29 | 201 | 211 |
| 7 | Field, Evidence & Hyperscale (P7) | 10 | 28 | 28 |
| 8 | Governance & Authorization (P10) | 2 | 10 | 10 |
0Foundation Spine (auth, tenant, routing, events)5 SDKs · 97 APIs · 97 cases
Stand up the spine first — nothing else can be exercised without a tenant, an authenticated principal and the pool router. Start here: sdk-identity (auth/register); 49 downstream APIs cache its token/ids. Gate the whole suite on W0 going green.
Prerequisites: none — this is the root wave.
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| api-gateway | 57 | 57 | 2 | open ↗ |
| pool-federation-runtime | 3 | 3 | 1 | open ↗ |
| sdk-identity | 22 | 22 | 11 | open ↗ |
| sdk-tenant | 10 | 10 | 9 | open ↗ |
| sdk-tenant-lifecycle | 5 | 5 | 5 | open ↗ |
1Secrets, Audit & Telemetry (cross-cutting infra)6 SDKs · 24 APIs · 24 cases
Cross-cutting infrastructure every later wave emits into: secret storage, audit log, metering and telemetry/trace. Verify writes are persisted and readable before relying on them as assertions in later waves.
Prerequisites (must be green): sdk-device sdk-identity sdk-persona sdk-tenant semantic-service
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| hdk-diagnostic | 2 | 2 | 2 | open ↗ |
| sdk-audit | 3 | 3 | 3 | open ↗ |
| sdk-diagnostic-telemetry | 6 | 6 | 4 | open ↗ |
| sdk-secrets | 3 | 3 | 3 | open ↗ |
| sdk-trace | 4 | 4 | 3 | open ↗ |
| sdk-vault | 6 | 6 | 5 | open ↗ |
2Identity Triad (MDM + ABAC + Consent)6 SDKs · 36 APIs · 36 cases
The identity triad — master-data / ABAC policy / consent — plus API keys, MFA and federation (SAML/SCIM). These gate authorization decisions used from W3 onward.
Prerequisites (must be green): sdk-identity sdk-persona
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| sdk-api-keys | 13 | 13 | 12 | open ↗ |
| sdk-consent | 8 | 8 | 8 | open ↗ |
| sdk-policy | 3 | 3 | 3 | open ↗ |
| sdk-principal-token | 1 | 1 | 1 | open ↗ |
| sdk-rebac | 8 | 8 | 8 | open ↗ |
| sdk-resource-registry | 3 | 3 | 3 | open ↗ |
3Canonical Entities + Privacy6 SDKs · 33 APIs · 33 cases
Canonical business entities (persons, personas, profiles, memberships, devices) and privacy/data-rights. Depend on W0 auth + W2 policy/consent.
Prerequisites (must be green): sdk-identity
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| hdk-idp | 3 | 3 | 3 | open ↗ |
| hdk-permissions | 2 | 2 | 2 | open ↗ |
| hdk-sync | 8 | 8 | 8 | open ↗ |
| sdk-parsing | 3 | 3 | 3 | open ↗ |
| sdk-projection | 4 | 4 | 4 | open ↗ |
| sdk-source-record | 13 | 13 | 13 | open ↗ |
4Operational Core + Billing2 SDKs · 27 APIs · 27 cases
Operational core: billing, payments, approvals, connectors, media, notifications, search, webhooks, workflows. Depend on entities from W3.
Prerequisites (must be green): sdk-identity sdk-persona
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| sdk-data-credits | 13 | 13 | 13 | open ↗ |
| sdk-import | 14 | 14 | 14 | open ↗ |
5Engagement (Domain Layer)19 SDKs · 225 APIs · 225 cases
Engagement domain layer (CRM, campaigns, lead-scoring, content, service-requests). Depends on canonical entities + operational core.
Prerequisites (must be green): sdk-feature-flags sdk-identity sdk-persona sdk-vault
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| connector-twilio-voice | 8 | 8 | 6 | open ↗ |
| sdk-approval | 11 | 11 | 11 | open ↗ |
| sdk-campaign | 6 | 6 | 6 | open ↗ |
| sdk-content | 7 | 7 | 7 | open ↗ |
| sdk-conversation | 5 | 5 | 5 | open ↗ |
| sdk-coverage | 11 | 11 | 11 | open ↗ |
| sdk-crm | 28 | 28 | 28 | open ↗ |
| sdk-deliverability | 17 | 17 | 16 | open ↗ |
| sdk-engagement | 10 | 10 | 10 | open ↗ |
| sdk-event | 6 | 6 | 5 | open ↗ |
| sdk-handoff | 9 | 9 | 9 | open ↗ |
| sdk-incident | 8 | 8 | 8 | open ↗ |
| sdk-lead-scoring | 9 | 9 | 9 | open ↗ |
| sdk-offer-catalog | 10 | 10 | 10 | open ↗ |
| sdk-scheduling | 30 | 30 | 25 | open ↗ |
| sdk-sequence | 11 | 11 | 11 | open ↗ |
| sdk-service-request | 5 | 5 | 5 | open ↗ |
| sdk-sla | 30 | 30 | 30 | open ↗ |
| sdk-social | 4 | 4 | 3 | open ↗ |
6Knowledge, Semantic & Agent Runtime29 SDKs · 201 APIs · 211 cases
Knowledge & semantic layer, agent runtime, AI gateway, MCP bridge, taxonomy/ingest. Depends on identity, policy and the connector/operational layers.
Prerequisites (must be green): api-gateway sdk-identity sdk-rebac sdk-tenant
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| registry-mcp | 1 | 1 | 1 | open ↗ |
| sdk-agent-runtime | 12 | 12 | 12 | open ↗ |
| sdk-ai-gateway | 10 | 13 | 6 | open ↗ |
| sdk-analytics | 6 | 6 | 6 | open ↗ |
| sdk-asset | 5 | 5 | 5 | open ↗ |
| sdk-assignment | 14 | 14 | 14 | open ↗ |
| sdk-billing | 4 | 4 | 4 | open ↗ |
| sdk-command | 5 | 5 | 4 | open ↗ |
| sdk-config | 6 | 6 | 6 | open ↗ |
| sdk-connectors | 22 | 22 | 18 | open ↗ |
| sdk-data-rights | 9 | 9 | 9 | open ↗ |
| sdk-device | 6 | 6 | 6 | open ↗ |
| sdk-dispatch | 2 | 2 | 1 | open ↗ |
| sdk-feature-flags | 6 | 6 | 6 | open ↗ |
| sdk-geo | 6 | 6 | 6 | open ↗ |
| sdk-ingest | 3 | 4 | 4 | open ↗ |
| sdk-mcp-bridge | 6 | 6 | 5 | open ↗ |
| sdk-meter | 2 | 2 | 1 | open ↗ |
| sdk-notification | 20 | 20 | 16 | open ↗ |
| sdk-payment | 5 | 5 | 5 | open ↗ |
| sdk-persona | 16 | 16 | 16 | open ↗ |
| sdk-pool-router | 1 | 1 | 1 | open ↗ |
| sdk-profile | 6 | 6 | 6 | open ↗ |
| sdk-search | 5 | 5 | 5 | open ↗ |
| sdk-storm | 1 | 3 | 0 | open ↗ |
| sdk-taxonomy | 4 | 6 | 5 | open ↗ |
| sdk-workflow | 4 | 4 | 4 | open ↗ |
| semantic-service | 13 | 15 | 15 | open ↗ |
| telemetry | 1 | 1 | 0 | open ↗ |
7Field, Evidence & Hyperscale (P7)10 SDKs · 28 APIs · 28 cases
Field + Evidence + Hyperscale (current P7 branch): evidence capture, HDK device surfaces, pool federation. Depends on media, identity and sync.
Prerequisites (must be green): sdk-consent sdk-device sdk-engagement sdk-identity sdk-persona
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| hdk-camera | 2 | 2 | 2 | open ↗ |
| hdk-image-editor | 1 | 1 | 1 | open ↗ |
| hdk-map | 2 | 2 | 2 | open ↗ |
| hdk-measure | 3 | 3 | 3 | open ↗ |
| hdk-scanner | 1 | 1 | 1 | open ↗ |
| hdk-video-editor | 1 | 1 | 1 | open ↗ |
| hdk-watermark | 3 | 3 | 3 | open ↗ |
| sdk-evidence | 3 | 3 | 3 | open ↗ |
| sdk-media | 5 | 5 | 5 | open ↗ |
| sdk-webhook | 7 | 7 | 7 | open ↗ |
8Governance & Authorization (P10)2 SDKs · 10 APIs · 10 cases
Governance & authorization (P10): obligation-based PDP, principal token enrichment, consent-gated access, EMPI, resource ownership. Exercised last — asserts the policy decisions woven through every earlier wave.
Prerequisites (must be green): sdk-approval sdk-identity
| SDK / service | APIs | Cases | Auth-gated | Detail |
|---|---|---|---|---|
| contracts | 2 | 2 | 0 | open ↗ |
| sdk-identity-resolver | 8 | 8 | 8 | open ↗ |
Regenerate: python scripts/qa-matrix/enrich_qa_apis.py && python scripts/qa-matrix/build_test_plan.py && python scripts/qa-matrix/build_api_docs.py