Glidepath · Spec · Production roadmap

Glidepath, from the lab to production

The SDLC review told me where Glidepath falls short. Reading it back, I realized some of those gaps were my lab, not the design. So this sorts every weakness the review found by cause, then orders the work in three lanes, so a production install is never blocked on a feature it doesn't need.

Spec October 12, 2026Companion Glidepath SDLC reviewEffort single-engineer estimates: S is days, M is one to three weeks, L is one to two months

Nine items · three lanes · now, next, later

Some gaps are the lab, not the design. Finish the architecture first, then build what it lacks.

T1 is the only item that blocks a production install, and it is small.
T1, P1 and P2 complete the architecture that already exists. The other six are new design.
Each lane can move on its own. Within a lane, order matters.

Correction to the review

Approvals and change management: Partial, not Not enforced.

The review rated approvals and change management as not enforced. That was the lab, not the architecture. Glidepath's install requires a GitHub ruleset on every gitops repo, generated from releaseGuardrails, with two approvals and every gate as a required check. In an organization, one ruleset covers gitops-*. The lab runs on GitHub Free, where private-repo rulesets exist but are not applied.

Revised rating: Partial. The ruleset would block, but three of its required checks always pass, and the September 27, 2026 audit found that non-release PRs and bot commits would be stuck the day it is switched on. Item T1 fixes that.

Three kinds of gap

Each weakness from the review falls into one of three groups, and each group needs different work.

5 weaknesses

Lab-bound

Specified in the architecture; the lab substitutes something weaker. The work is to write it down and verify it.

4 weaknesses

Fix before enforcing

In the architecture, but would break the day the ruleset is enforced.

18 weaknesses

Design gap

Missing whatever the environment. Needs new design.

Weakness from the review	Kind	Roadmap item
Approvals and required checks don't block a merge	Lab-bound	P1 · T1
NetworkPolicy is a no-op on the dev CNI	Lab-bound	P1
Prod reads secrets from a dev-hosted store over a NodePort	Lab-bound	P1 · P2
Webhook arrives through a tunnel and port-forward	Lab-bound	P1
No Prometheus on the upper cluster	Lab-bound	P1 · T3
Required checks never report on non-release PRs	Fix before enforcing	T1
Bot bootstrap commits would be refused by the ruleset	Fix before enforcing	T1
`/retest <gate>` re-runs nothing	Fix before enforcing	T1
Bypass alert not yet proven against a real bypass	Fix before enforcing	T1
ITSM, QA and policy gates always pass	Design gap	T2
A scan that never ran counts as a pass	Design gap	T2
No signature check at admission	Design gap	T2
No secret, dependency or license scanning	Design gap	T2
Test secrets copied into the shared Testkube namespace	Design gap	T2
Extra `.tekton` files run unchecked	Design gap	T2
Inert canary; analysis passes on no data	Design gap	T3
Next environment starts when the PR opens	Design gap	T3
DORA has no environment, skips Ground and cloud	Design gap	T3
Chained stages never report to the PR; no test reports	Design gap	D1
Missing test file reports success	Design gap	D1
Push branch globs never match; no cron or manual runs	Design gap	D2
No build secrets or build args; cache misses Python and Go	Design gap	D2
Closed stage graph, fixed agents, no monorepo	Design gap	D3
Control plane shares a cluster with Ground	Design gap	P2
Kaniko archived; amd64 Go builds crash under QEMU	Design gap	P3
Hardcoded to GHCR and GitHub; cloud targets unverified	Design gap	P3
No migration or feature-flag story	Design gap	P3

The roadmap at a glance

Three lanes that can move independently, each with three horizons. Within a lane, order matters: T2 adds required checks, so T1 must first make sure every check reports. Across lanes, P1 writes down the profile that T1 and P2 verify against.

Figure 1Nine items in three lanes. Effort is a rough single-engineer estimate: S is days, M is one to three weeks, L is one to two months.

The work, item by item

Each item names the review findings it closes and a test that says when it is done.

Trust · governance that blocks

T1 · Now · effort S

Ready the ruleset to enforce

Fix before enforcing

Run every gate on every PR to main, passing at once when the head is not a release-* branch.
Make the Crossplane GitHub App a bypass actor, scoped to the bootstrap files it writes.
Match the retest comment event in each gate's CEL.
Prove detect-bypass-merge against a real bypass merge in the lab.
Already built: hack/apply-guardrail-ruleset.sh generates the ruleset from releaseGuardrails.

Done whenOn an org with rulesets enforced, a release PR merges green, a resync PR and a Tower Config PR merge with no bypass, a bot bootstrap commit lands, and a failing gate blocks.

github-ruleset.md audit 1 to 3 · gaps 15, 16, 20

T2 · Next · effort M–L

Make every gate real

Design gap

ITSM: open a change from change.created and pass on approval. QA: read the test stage's recorded outcome for the digest. Policy: Conforma or Kyverno CLI over the rendered manifests.
For any production: true environment, a missing scan fails instead of passing.
Verify signatures at admission on upper clusters against the cluster's own Fulcio root.
Add secret, dependency and license scanning to the build.
Stop copying app secrets into the shared Testkube namespace; run tests where the secret already lives.
Reject .tekton files the platform did not generate.

Done whenNo entry in releaseGuardrails is a stub, and an unsigned image is refused by the upper cluster.

governance-gate-stub.yaml · verify-sast-attestation.yaml · run-testworkflow.yaml

T3 · Later · effort L

Release on health

Design gap

Scrape ingress metrics wherever canaries run, and make an analysis with no data fail.
Ship a default multi-step canary with an error-rate analysis.
Start the next environment from the release record's Healthy fact instead of change.created.
On a failed analysis, abort and open the rollback PR automatically. It stays gated.
Label DORA by environment, count Ground and cloud deploys, and start lead time at the first commit.

Done whenA bad image in staging aborts itself and the prod release PR never opens.

airframe/analysis · rollout.yaml · dora-exporter

Developer · the inner loop

D1 · Now · effort M

Feedback on the PR

Design gap

Post every chained stage as a check run on the app commit, using the broker's per-repo token.
Parse JUnit and coverage from unit tests and Testkube into the check summary.
A test step with no test file fails, or reports neutral, instead of passing.
Run PR pipelines on opened when the label is already there, and give each preview an ingress URL.

Done whenA PR shows build, test and preview checks with test counts and a link to the running preview.

gap 7 · run-tests.yaml · ephemeral-envs.yaml

D2 · Next · effort M

Triggers and build inputs

Design gap

Glob matching for push branches, reusing the regex builder branch.created already has.
Cron and manual runs: a PaC incoming webhook, and a Run button in Tower.
Path filters on PR and tag events.
Build secrets and build args from the app's own secrets.
Dependency cache for Python and Go; pin agent images by digest.

Done whenA release/* branch flow, a nightly job and a build against a private package registry all work from cicd.yaml.

deliver-onboarding-files.yaml:498 · build-source.yaml

D3 · Later · effort L

An extensible pipeline

Design gap

Named extension points (pre-build, post-test, pre-release) that run a team's container under a fixed contract and the stage's identity.
Bring-your-own agent image from an allow-listed, signed registry.
Monorepo support: app path, build context and image per app.
Matrix test runs and a retry budget.

Done whenA team adds a custom step with no platform change, and two apps build from one repo.

ADR-0017 · stage-preflight.yaml

Platform · the production profile

P1 · Now · effort S

Write the production profile

Lab-bound

An ADR naming each lab substitution and what production requires: an enforced org ruleset with two approvals, an enforcing CNI, a routable secret store per zone, TLS ingress for the relay and webhooks, Prometheus on upper clusters.
An alert when no PaC event has arrived in N hours.
A conformance check, as a script or a Tower page, that reports which profile a cluster meets.

Done whenAn installer can tell a lab install from a production one by running one check.

security.md "Known, accepted gaps" · infisical-nodeport.yaml · gap 8

P2 · Next · effort L

Separate the control plane

Lab-bound

Ground environments on a lower workloads cluster, so the control-plane cluster runs no apps.
Upper clusters read secrets from a store in their own zone, never from dev.
Back up release records, or move them off 14-day ConfigMaps.

Done whenLosing the dev workloads cluster leaves pipelines, release records and prod secrets untouched.

ADR-0024 "Future" · gap 39

P3 · Later · effort L

Portable builds and targets

Design gap

Replace kaniko with rootless BuildKit or Buildah, and cross-compile natively instead of under QEMU.
Take the registry and git host from config, not from ghcr.io and api.github.com in Task scripts.
Verify ECS, Lambda and Container Apps live, with OIDC federation instead of static keys, and give them release records.
Document expand/contract migrations as a gated Job, and add an OpenFeature integration.

Done whenThe same app builds to a non-GHCR registry and releases to ECS with a release record.

gaps 33, 36 to 38 · build-image.yaml

Where it lands

The production profile keeps what the review found sound, Argo CD on each upper cluster pulling merged commits, and replaces each lab shortcut with a real endpoint.

Figure 2The target topology. Blue outlines are proposed by this roadmap; solid outlines exist in the architecture today. Grey notes under each zone say what the lab uses instead.

What to defer

Hangar's own cost essay warns that operating 47 tools is the platform's real limit. For one engineer, these can wait until a second team asks:

D3 extension points and monorepo support. They widen the contract every future change has to keep. Build them for a real team's need, not ahead of it.
A second git host. Take the registry from config in P3, but keep GitHub until there is a reason to leave it.
Azure Container Apps. Verify ECS first. A second cloud target doubles the untested surface.
A real ITSM integration beyond a thin adapter, until a team's change process needs one. Until then, mark the gate optional instead of always-pass.

Sources: the Glidepath SDLC review, glidepath/docs/admin/github-ruleset.md (the September 27, 2026 audit), the security.md known gaps, known-gaps.md, ADR-0024, and Apron's Infisical NodePort notes. Effort estimates are judgement, not measurement. The lab-bound items come from what the architecture already specifies; nothing here was verified on an enforcing GitHub plan.