12 posts tagged with "Operations"

Every team that works with coding agents eventually invents a small library of "the way we do things here." A release has a shape. A code-map task has a shape. A review response has a shape. Someone writes a prompt, someone else copies it, and a month later nobody knows which version is the real one.

Recipes are Agentplane's answer to that drift.

They are not meant to replace the project policy. They are not a second agent framework hiding next to the repo. A useful recipe is narrower than that: a reusable behavior package that can be installed, inspected, checked, and kept inside the same task lifecycle as normal work.

Coding agents are already good enough to change real repositories.

The weak part is not always the code they write. The weak part is the trail around the code: why the task existed, which plan constrained it, who owned the execution, which checks ran, and what made the work safe to close.

Agentplane 0.3 ended up being less of a feature line and more of a discipline line.

It started with a policy gateway and stricter release records. It ended with branch PR closure evidence, publish hygiene, recipe groundwork, and the first real modular prompt assembly layer. That is a lot for a 0.3.x series, but the pattern is easier to see in hindsight: every patch made the system less dependent on implicit agent judgment.

The final published 0.3 release is v0.3.29. A maintenance branch now preserves that line as 0.3. The next release is being prepared as 0.4.0 because prompt modules are not just another patch. They introduce a new mental model for how Agentplane builds agent instructions.

Agentplane 0.4.0 is published.

The headline is modular prompt assembly: agent instructions, policy gateway material, generated agent profiles, and runner prompt inputs now move through a shared module graph instead of being treated as large prompt files copied from place to place.

That sounds internal, but it changes the shape of the product. It gives Agentplane a stable layer where future recipes can patch, bind, disable, or validate named behavior without rewriting an entire prompt surface.

Agentplane 0.3.8 and 0.3.9 make more sense as one release story than as two separate announcements.

0.3.8 was the preparation patch. It split oversized modules, collapsed duplicated execution paths, and pushed the CLI, task lifecycle, backends, and runner toward shared contracts that 0.4 and 0.5 will need anyway.

Then the release itself exposed a hole in the publish contract. The npm artifact for 0.3.8 shipped with a workspace: dependency on @agentplane/recipes, so plain npm install agentplane failed with EUNSUPPORTEDPROTOCOL before the CLI could even start.

0.3.9 is the corrective half of that same work. It removes the leaked workspace dependency, adds a release parity guard that fails publishable manifests containing workspace: references, and tightens the hook-runner fallback used by release and upgrade flows.

That is why this is one release story. 0.3.8 showed where the codebase was going. 0.3.9 fixed the part that proved the release process was not strict enough yet.

Agentplane 0.3.4 is the version where the product finally stops assuming that users live inside the framework repository.

That sounds obvious, but it matters. The main distribution path is npm i -g agentplane, not “clone the framework repo and learn its internal file layout.” Once that becomes the real product lens, a few behaviors that looked acceptable from inside the framework stop being acceptable at all.

0.3.4 fixes that.

Agentplane 0.3.3 is the release where a lot of framework-internal friction finally turned into explicit product behavior.

Before this version, several important things still worked more by convention than by contract. Runtime selection inside the framework repo could be confusing. Task docs carried too much historical baggage. Local CI was correct but expensive. Release recovery was real, but not fully codified.

0.3.3 tightens all of that.

Agentplane 0.3.2 is a cleanup release, but in the good sense. A bunch of things that had been treated like “yeah, that’s annoying, we know” finally got fixed properly.

The biggest wins landed in upgrades, direct-mode task closure, and framework development inside the Agentplane repo itself.

Agentplane 0.3.0 is where the policy layer stopped feeling like scaffolding and started acting like product surface. Before that, the rules could work and still be hard to follow. This release cleaned that up.

Agentplane 0.3.1 is a recovery release in the most literal sense. It exists because the 0.3.0 npm path was already burned, and pretending otherwise would have made the release story worse, not better.

Agentplane 0.2.25 was the sort of release that looks small until you have to trust it. No shiny headline feature. Just a stricter workflow, fewer accidental commits, and a cleaner release path.

Agentplane started as a CLI that keeps repository work honest. The roadmap to 0.5 is not about turning it into a vague “AI platform.” It is about adding explicit execution-route contracts and a cloud backend option without losing the audit trail or the policy boundaries that make the tool usable in a real repo.