3.2.x Executive Overview

Point-in-time stakeholder synthesis, 2026-07-30. Covers everything since the 3.2.4 release (2026-07-05): the shipped 3.2.5 release and the in-flight 3.2.6 cycle. Reads the milestone from a PO / C-suite / customer point of view; the durable goal declaration is release-goals/3.2.x, the operator execution detail is the milestone roadmap, the delivery strategy is the open-core delivery plan, and what actually shipped is the changelog. Status was verified by two read-only audits on 2026-07-30; the delivery plan carries the evidence and the unverified-item flags.

Bottom line

3.2.x is our stabilization-and-foundations cycle — no flashy new surface, by design. Since 3.2.4 we shipped one full release (3.2.5) and have a rich sixth (3.2.6) in flight. The hard structural work this cycle exists to do is largely done — our core data now has single sources of truth, our governance layer now genuinely drives the product, and our doctrine is becoming independently shippable. Two honest caveats: 3.2.6 is not yet releasable (our release gate is red by policy — see Risk), and the remaining work is small and well-understood rather than open-ended.

What 3.2.x is for (in business terms)

Three goals, each a customer outcome:

  • G1 — Governance drives the product. Our "doctrine" (the configurable rules for how missions, docs, and workflows behave) now actually controls runtime behavior instead of being documentation. This is the foundation of our open-core model: customers can tailor governance without forking our source.
  • G2 — One source of truth for core data. We have been consolidating the places that decide where mission data lives and how identity/state are derived down to single authorities — the root cause of a whole class of reliability bugs.
  • G3 — Faster, more honest engineering. CI and quality gates that make G1/G2 safe to keep changing.

Progress since 3.2.4 — what it means for customers

Customization & open-core (the strategic thread). Doctrine is now shippable and forkable: organizations can ship their own governance, docs standards, and supporting files to their repos without patching our code. Pack locations are now portable across machines and CI (no more hardcoded paths breaking teammates). This is the groundwork for selling and supporting a customizable product on a stable public core.

Reliability (the bulk of the work). The changes customers will feel:

  • Quality gates stopped emitting confident-but-wrong verdicts, and approved review evidence now survives a merge instead of being silently discarded.
  • Work-package state now has one authoritative record, closing a class of "the tool says X but reality is Y" bugs.
  • Upgrades no longer strand or dirty parallel work areas; the dashboard now correctly shows in-flight work that used to silently disappear.
  • Connections to our hosted service fail safely instead of silently pointing at the wrong server.

Robustness & automation. Agent-driven and scripted/CI runs no longer hang waiting for input — increasingly important as customers automate on top of us.

Velocity & honesty. CI is meaningfully faster, and regressions are now caught at review time rather than at merge, shrinking the feedback loop.

One breaking change customers must action: very old (pre-3.2.x) missions need a one-command migration to keep working. This was a deliberate trade — retiring a dual-support path that was itself a persistent bug source.

Strategic position: the open-core pivot is closer than the roadmap showed

A verified re-audit this week found our internal roadmap had understated our progress. The core-data-consolidation work (G2) is substantially delivered — it was simply tracked under the wrong labels. The governance layer (G1) is already live in the product (three mission types run entirely off configurable doctrine today). The remaining work to reach a clean open-core boundary is bounded: the doctrine module is ~90% ready to stand alone as an independent package, and the last real gap is making our governance layer the single, stable entry point that external adopters build against.

Release readiness & risk (candid)

  • 3.2.6 is not tag-ready. Our mainline CI has been red for 10+ consecutive runs. This is partly by design — our policy is that mainline honestly reflects known release-blocking bugs rather than hiding them, and CI (not opinion) is the release authority. It is a discipline, not a fire.
  • The one open question: whether all of the red reduces to those known, tracked blockers, or whether a recent change introduced something new. Resolving that classification is the single gating item before any release conversation — an hours-not-weeks task.

What's next & the strategic call for the PO

The plan (see the open-core delivery plan) is an open-core breaking-change window: get the remaining breaking/design changes out as fast as possible to our small set of consenting early-adopter customers, without ever stalling bug fixes for them, and make each change cheap to absorb (automated migrations

  • backward-compatible shims + advance notice). After this window, the external surface stabilizes and stops disrupting customers.

Decisions that need product ownership:

  1. How to sequence the remaining breaking changes into releases (the "3.2.6 / 3.2.7" numbers are urgency signals, not commitments).
  2. Whether to hold the honest-red mainline through the window, or stabilize the baseline first.
  3. Confirming the named early-adopter customers who receive pre-releases and migration notes.

In one sentence for the board: the risky structural rework of 3.2.x is largely behind us and has de-risked our open-core direction; what remains is a bounded, well-understood push to lock a stable customer-facing contract — the main open question is release timing, not whether the foundation holds.

Edit this page