Munitor: a release should name the same thing at every handoff

A delivery pipeline is a series of claims: this source was checked, this artifact came from it, this version identifies it, and this deployment asks for that version. Automation is useful when those claims agree. A green job alone does not guarantee that they do.

CTO to Human: what the history tells us

Munitor's selected releases broaden the build vocabulary and then tighten the connection between versions, artifacts and deployment changes. Java, Gradle, Node and infrastructure consumers have different needs, so shared automation must represent those differences explicitly rather than erase them.

Engineer to Engineer: the boundary that matters

Immutable image tags and checks that a release tag points at the building commit protect the source-to-artifact relationship. GitOps write-back carries that identity into a deployment repository. Signed updates and bounded retries make the handoff more attributable and easier to reason about when another change arrives concurrently. Each control belongs to a particular failure mode.

Milestones in the public record

• 2026-03-21 — Munitor publishes a shared delivery vocabulary. Munitor's first stable release describes pipeline generation from a repository configuration, covering Java, Node and infrastructure workflows. The release presents the generator as a shared delivery boundary. Project journal.
• 2026-03-22 — Munitor adds a Gradle application path. Munitor 0.2 added the gradle-webapp pipeline type. The release links the pull request that introduced it. Project journal.
• 2026-07-12 — Munitor broadens package and GitOps workflows. Munitor 0.3 added first-class pnpm and Obsidian support, optional repository Dockerfiles for Node web applications and production-only Kustomize write-back with bounded retry handling. Project journal.
• 2026-10-12 — Munitor binds versions to immutable artifacts. The 0.3.3 release tightens version reservation, immutable image tags and source-commit checks around releases and GitOps updates. It also records the source commit in the deployment-repository change. Project journal.
• 2026-10-12 — Munitor strengthens the deployment handoff. Munitor 0.3.4 follows with signed GitOps bumps, tests in CI and more narrowly scoped feature snapshots. Its release and merged changes define the exact update. Project journal.

The value is an explainable chain. When a release needs investigation, the system should make it possible to identify the exact source, artifact and requested deployment without reconstructing the story from loosely related logs.

Explore the munitor project hub.

Retrospective written on October 12, 2026, covering the public evidence available for October 12, 2025 through October 12, 2026. Linked journal entries use source event dates; this essay is a newly written retrospective. Quiet months do not imply an unrecorded release, and short-lived projects are not presented as having a full year of activity.