SDLC · Stage 02 of 07
Onboard and code
A developer's first push should just work, and they should only ever have to look after one file.
Principles: The platform is a product, Paved roads, with security built in
The first hour with a platform decides how people feel about it for a long time. I want that hour to feel like being welcomed, not like being handed a checklist.
Onboarding is where a platform shows whether it is a product or a set of instructions. In Hangar, a developer picks an app stack in Tower (Node.js, Spring Boot, Go or Python). Airframe scaffolds the source repo, the Dockerfile and a real, build-only cicd.yaml, and the platform provisions namespaces, identity and delivery behind it. Nothing is created by an API call from the portal: Backstage holds no Kubernetes credentials at all, and every request becomes a git commit.
The one file a developer maintains is cicd.yaml. It is read fresh from the triggering commit and validated against a JSON Schema, so a mistake fails fast with a readable error instead of halfway through a pipeline.
Where Hangar does this
And for AI agents
From one sentence to a reviewed change set
The test I hold it to is the parachute sentence, typed into an agent session: "provision a new python application named parachute. give it a dev and test ground environment. a staging and prod flight environment. and configure it with 1 100% weight canary step, an URL=http://myendpoint.io env var."
The AppSpec planner compiles a plain-language request into the exact change set a human would have written, checked against the real XRD schemas, Glidepath's schema and a real helm template. The agent proposes a pull request; onboarding is still a reviewed commit.