Developer Portal, Service Catalog, and Golden Paths
Treat the software factory as an internal product that developers and agents can discover, understand, and use safely.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Design the portal journey for onboarding a repository and running its first low-risk workflow. Map every page action to an authoritative API, state, permission, evidence requirement, owner, and recovery path.
4. Tradeoffs and alternatives
Strong standardization improves reliability and can constrain legitimate domain needs. Build a small set of well-supported paths and measure where users exit them. A single portal improves discovery but must not become a second control plane. Generate views from authoritative services and keep write actions on governed APIs.
5. Current Mission Control Implementation
The current site and case-study implementation provide operator surfaces for intent, plans, workflows, evidence, approvals, runtime state, and review. The curriculum defines a capability map and authorized action parity.
It does not yet teach or demonstrate a complete internal developer portal, service catalog, self-service repository onboarding, golden-path ownership model, extension marketplace, or adoption analytics. These are product responsibilities around the architecture, not optional polish.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence