Docs · Hangar

Hangar roadmap: Airframe A+, Autopilot, and the Skyport AI workloads

This is the unified plan. It replaces the “next” section of the 2026-09-25 Skyport handoff and folds in three streams that used to be separate: Skyport’s remaining phases, the Airframe A+ program, and Autopilot. All durations are estimates for one person; ordering matters more than the numbers.

Diagrams: diagrams/plan/01-hangar-family.html, 02-roadmap.html, 03-dependencies.html, 04-scorecard.html.

1. The shape of the plan

   Skyport (demo + quickstarts) ──────────────┐   builds new components → born A+
   Airframe A+ (AF-1 … AF-10) ─────────────────┼── contract first, so nothing is retrofitted
   Autopilot (Clearance, AgentRun, tools) ────┤   depends on the contract and ownership split
   Skyport AI workloads (parts 6-11) ─────────┘   depends on Autopilot phases A and B

Why this order. Three reasons, each of which would cost weeks if ignored:

1. Build the contract before the next components. MongoDB and OAuth are next in Skyport. If they ship before the contract exists, each needs a retrofit for outputs, verify checks and schema strictness. Ship the contract foundation first and they are born A+.
2. Ownership before agents. An agent that can edit a file mixing human and machine-owned keys is a risk that path-level scope cannot contain. Split the files (AF-5) before granting Clearance write tools.
3. The planner is the acceptance test. The parachute sentence needs AF-1 to AF-6 and the Autopilot core. Everything before it is a prerequisite; everything after it (Skyport AI) is a consumer.

What changed from the 2026-09-25 plan:

2. Milestones

Score targets are the scorecard’s overall (baseline 27/100, A+ needs 97 and 14 of 14 checks).

M0 Stabilize and baseline (weeks 1-2), scorecard target 35

Exit: the guard is live on dev; airframe validate catches an injected typo on a real PR; baggage-api runs on dev; every item in section 5 has an answer.

M0 status (2026-09-26): mostly done; scorecard 27.3 -> 40.2 (target 35).

• Done: AF-10a guard (Airframe v0.3.91, pinned on the dev and prod clusters; all 7 live env files render byte-identically before and after); AF-10b chart tests and CI (the scorecard job needs a FLEET_READ_TOKEN secret); AF-1a AGENTS.md; AF-4a airframe validate v0; DX-0 autopilot repo (public, github.com/jfillman/autopilot); planner flipped (Features.rollout_guard defaults to True, the canary test retired); D7 decided (Preflight); D6 and D10 briefed (briefings-d6-d10.md); release-file split designed and proven on the dev cluster (release-file-split.md).
• U1, U5, U6, U7, U11, U12 answered and U3 partly (section 5). Still open: U2 (function TTL re-invoke), U4 (Tower write actions need a human click on a stuck app), U8 (needs the AgentRun composition applied via a copy), U9 (only if a vector store is wanted), U10 (M5 trial).
• baggage-api: created, code and dev env pushed, broker allows its dev namespace; see the Skyport handoff for whether the dev walkthrough has passed. The first two image scans failed (Debian base: 44 unfixed HIGH CVEs; then a stale setuptools), which is a scorecard item for the Python scaffold.

M1 Contract (weeks 3-6), target 60

Exit: typo acceptance is 0% across every live file; the Mongo component ships with its contract; validate is a required, green check on three repos.

M2 Safe write (weeks 7-10), target 75

Exit: no live file mixes owners; a release PR and a config PR never conflict (property test); part 1 replays green from a walkthrough.

M3 Autopilot core (weeks 11-18), target 88

Exit: the parachute sentence works end to end on dev (a human merges the flight PRs); killing Clearance mid-run still ends every run on time; the seeded bad run scores as failed.

M4 Skyport AI workloads (weeks 19-24), target 93

Parts 6 to 11, in shape order: task, session, service, scheduled, event, team. Each is walked live, has a Preflight case with a seeded bad run, and updates its quickstart’s verified-state note.

Exit: six Preflight cases pass and their seeded bad runs fail; one task_id traces a disruption from broker message to final artifact.

M5 Evidence and widen (weeks 25-28), target 97 and 14 of 14

• Preflight as a regression gate on the Autopilot repo: profile, model and policy changes are PRs that must pass.
• Autonomy tracker for one alert class (shadow, then approve, then auto), with the breaker.
• Modelplane hub trial on a dedicated kind cluster, behind the OpenAI-compatible contract.
• AP-D1 opt-in persistent, resumable state for session and team shapes: size cap, retention TTL, scan before restore (needs U12; design in design.md 3.1).
• Part 12: the nginx edge (optional), born A+.
• Conformance on prod: upper clusters get no runs, and a run cannot be created there.
• The A+ run: scorecard 14 of 14 and overall at least 97, recorded.

3. Critical path

chart guard → validate → contract → ownership split → Autopilot core → planner (parachute) → Skyport AI. Parallel and safe to interleave: Skyport components (born A+), docs and walkthroughs, the Autopilot repo setup, Modelplane reading. Do not parallelize the ownership split with Clearance write tools.

4. Decisions

5. Unverified: answer these in M0

All U-experiments run on the dev cluster (decision 2026-09-26).

Answers (2026-09-26)

6. Risks

• One person, many repos. airframe, glidepath, backstage, apron, the tenants repos and a new repo all change. Keep every change small, behind a gate, and reversible. Use worktrees.
• Retrofit cost if the contract slips behind the next components. Hence the ordering.
• The dev cluster does not enforce NetworkPolicy. autopilotReady is gated on a canary, and runs are never trusted on a claim.
• The prod cluster is resource-limited (observability scaled to 0). Runs are dev-only; prod gets none.
• Hosted model cost. Token budgets and the breaker; two on-demand or scheduled spenders in the demo.
• Upstream churn. Modelplane is v0.1 and the mcp SDK is v2; both sit behind contracts and pins.
• Strictness breaks an environment. Warn first, sweep the fleet, then enforce.

7. First ten actions

1. Read HANDOFF-hangar-autopilot-airframe-a-plus.md and check each repo’s branch and status.
2. Decide D8 (the autopilot repo) and D7 (Preflight’s name).
3. Answer U1, U5, U6 and U7 (quick, no cluster changes).
4. Write the chart guard in an Airframe worktree with a fixture test; run it through a scratch app.
5. Wire the scorecard and chart tests into CI.
6. Commit AGENTS.md for Airframe.
7. Build airframe validate v0 (schema plus helm template).
8. Provision baggage-api through the current flow and log each stumble.
9. Put airframe validate on baggage-api’s PRs.
10. Re-run the scorecard and update this file’s status.