Skip to main content

​
KAHN northstar delivery — what shipped, why it shipped fast

​
What landed

Phase 0–5 of the KAHN agent-fleet delivery, plus a SPA cloud-tenant redesign, closed across 35 PRs in one operator-paced session. The agent-fleet observability surface is dogfood-ready: 44 real agent runs from the audit-runner fleet, the M3.5 soak gate-met against kahn-internal, rollback rehearsed in staging, retention verified, the full operator-facing SPA showing the right tenant’s data via an admin selector. What made it fast wasn’t autonomy. It was the operator-paced cadence: every prod-write decision sat behind an explicit GO, every cross-repo ask got drafted-not-pushed, every milestone was either closeable at HEAD or got a documented re-scope.

​
Three patterns that earned their keep

​
1. Pre-flight inventory before implementation

Phase 1 began with a planner re-grade after sub-agent inventory: M1.3, M1.4, M1.5 all had pre-existing scaffolding. The “5 TASKSETs of fresh code” reframed to “1 TASKSET of new code + 4 of audit-and-test.” Total Phase 1 PR count dropped from a projected 8 to 4. Reviewer footprint per PR dropped accordingly. The same shape recurred in Phases 2 and 3: M2.1, M2.2, M2.4, M3.1 all turned out to be partially in tree from prior TASKSETs. The sub-agents that started with read-only inventory delivered tighter diffs than the ones that started writing code.

​
2. Calendar-bound milestone re-scope

Three milestones (≥7 distinct UTC dates, ≥7 days no-5xx, ≥2 mixed-outcome checkpoints) cannot be observed within a session without faking events — and faking violates the project’s hard rules. The pattern that closed the delivery: status: complete-with-deferred-observation. The threshold values stay unchanged. The verification queries are documented in the evidence files. The operator re-runs the queries post-window and flips the status to plain complete. The Phase gate behind them doesn’t block. This is the procedural primitive that lets a v0.1 delivery declare “shipped” without lying about evidence.

​
3. Three-PR sequential redesign

The SPA’s cross-tenant gap (operator session resolves to wrong tenant) had three reviewable shapes:
  • PR 1: immediate fixes (truthful empty-state copy, /#/self cloud-mode merge). No backend touch. Ships first.
  • PR 2: backend admin tenant override + GET /api/admin/tenants. Application-layer gate. Read-only. Mutations explicitly out.
  • PR 3: frontend selector dropdown + X-KAHN-Tenant header injection. Depends on PR 2 in staging.
Each PR ships independently. Each gets its own reviewer focus. The total surface (10 files, 1100+ LOC) would have been unreviewable as a single PR; split, each is ~400 LOC and one auth seam.

​
What this means for the next delivery

KAHN demonstrated three shipping patterns that generalise:
  • Sub-agent inventory before code — adopt as a brief requirement in every implementation TASKSET.
  • Deferred-observation status — name the calendar-bound reality in the milestone tracker; don’t let it bottleneck the gate.
  • Sequential PR splits — when a gap has a small / medium / large piece, ship the small piece first; the medium piece unblocks the operator faster than waiting for a perfect bundle.
These patterns ship the next delivery (KAHN external pilot, or the next SaaS in the devarno-cloud constellation) ~3-4× faster than a single-monolithic-PR cadence would.

​
Cross-references

  • Full delivery doc: kahn-hq/docs/decisions/2026-04-27-northstar- delivery-complete.md.
  • Re-scope precedent: kahn-hq/docs/findings/20260427-phase-3-4- imminent-closure-rescope.md.
  • Doctrines emitted from this delivery: atlas/doctrines/pre-flight-inventory-before-implementation, calendar-bound-milestone-rescope, operator-mediated-prod- write-cadence, admin-tenant-override-without-jwt-update, gha-conditional-repository-name-footgun.