API Domain Authoring designed

GPUaaS is moving from a broad v1 surface toward domain-owned API routes. The portal should teach the rule, while the OpenAPI fragments and manifest remain the contract source of truth.

Operating Model

Area	Direction
v1 routes	Frozen for demo/internal continuity; avoid adding new product surface
Domain routes	Durable home for production routes and v3 ownership
Authoring manifest	Maps OpenAPI fragments to owning domains
cmd/api	Wires dependencies and starts as handler shell; business logic moves into packages
Contracts	OpenAPI changes first, code follows

Route Flow

Reader Rules

• Do not treat /api/v1 as the long-term public product contract while migration work is active.
• Prefer domain route files for durable production routes.
• Keep /api/v1/v3/* read models isolated until their target domain route is clear.
• Keep BFF wiring in cmd/api; move domain behavior into owned packages over time.
• Add or change API fields in contracts before implementation.

Canonical sources

• doc/architecture/API_Domain_Authoring_Model_v1.mdraw
• doc/architecture/API_Route_Modularization_and_V1_Freeze_v1.mdraw
• doc/architecture/AI_Factory_Team_Domain_Operating_Model_v1.mdraw
• doc/api/openapi/manifest.yamlraw
• doc/api/openapi.draft.yamlraw