Reverse-engineer existing codebases into structured spec documents. The output feeds oc-app-architect as a Phase 2 baseline so the oc-orchestrator never starts from a cold context. Optional — greenfield projects skip this band entirely.

oc-app-architect anchors the spine, auto-invoking oc-stack-forge for platform decisions, taking advisory input from oc-scale-ops on capacity, and routing oc-migration-ops when a live system needs a schema, framework, or platform change. The plan checkpoint is the master record downstream skills consume. v1.7 adds oc-modularize-ops here — it decides whether to split a live monolith, captures golden fixtures from real data, proves zero functionality/data loss, then hands the bulk move to oc-migration-ops (the Seams chain → oc-fleet-ops).

v1.5 adds an AI-native phase. When /oc-discover detects an AI app, oc-app-architect routes to four new skills: oc-claude-api (model routing, prompt caching, tool use, version migration), the tri-agent pair oc-rag-forge (vector-DB choice, embeddings, hybrid search, retrieval eval) and oc-agent-forge (Agent SDK, subagent topology, tool budgets, agent eval), and oc-prompt-ops (prompts as versioned, eval-gated artifacts). All four ship gated behind skills.registry.<id>.enabled and feed checkpoints back to oc-app-architect; oc-rag-forge consumes the vector-db packs.

Three tri-agent loops (oc-ux-engineer · oc-api-dev · oc-integrations-engineer) plus the dense-UI specialist (oc-dash-forge) work in parallel. oc-ux-engineer hands data-heavy screens to oc-dash-forge; oc-api-dev produces an OpenAPI/GraphQL contract that the deploy-time drift gate later enforces. All four feed checkpoints back to oc-app-architect. v1.7 adds oc-signal-forge — auto-invoked from oc-app-architect's 08-analytics plan, it builds and adversarially proves a metric answers its question before wiring it to oc-dash-forge (render) and a freshness SLA in oc-monitoring-ops (the Signals chain).

Three audit gates (oc-bug-check pre-commit, oc-code-auditor for code-level findings, oc-security-auditor for STRIDE/OWASP/infra) all must pass before oc-deploy-ops will run the production sequence. At release boundaries the spine threads oc-git-ops → oc-release-ops → oc-deploy-ops; oc-release-ops produces changelog · version bump · release ticket · announcement, then hands off (it is not itself a deployer). The gate cluster sits below and writes blocker status into shared checkpoints. v1.5 taught oc-code-auditor prompt-injection and tool-use safety rules for AI apps. v1.7 adds oc-fleet-ops as oc-deploy-ops' peer: managed PaaS → oc-deploy-ops; self-managed multi-container fleets (k8s/Nomad/Compose/VMs, IaC) → oc-fleet-ops, which lands the modules oc-modularize-ops carves out and reports fleet health to oc-monitoring-ops.

oc-deploy-ops hands off to oc-monitoring-ops once production is green. oc-monitoring-ops also receives oc-api-dev's SLO + drift manifest so contract violations alert the same way uptime errors do. Incident response runbooks and postmortems live here.