14 posts tagged with "Release"

Andrej Karpathy's LLM Wiki is a small idea with an annoying amount of truth in it. Plain RAG is good at finding passages. It is much worse at keeping the synthesis alive after the answer is done.

That hurts in software work. A coding agent can read the release docs, scan the task history, find a half-forgotten migration note, and still leave the next agent to repeat the same archaeology next week. The useful part of the work was the cleaned-up map of what the project knows. The final answer was just one expression of that map.

That is what the LLM Wiki pattern is really about: raw sources stay raw, and the model maintains a wiki that gets better over time. Agentplane 0.6 takes that idea and makes it fit a Git repository.

Coding agents can now produce large, plausible diffs faster than reviewers can reconstruct the work behind them. The missing object is not another dashboard. It is a durable artifact that travels with the repository.

Agent Change Record v0.1 is that artifact.

Agentplane 0.4.1 was a small release with one important theme: make closure easier to prove.

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.7 is a patch release about making the product behave more honestly when the repository is old, the backend is external, or the release path is under stress.

That sounds broad, but the theme is consistent. 0.3.7 removes a set of half-implicit transitions that were still too easy to treat as “probably fine”:

• legacy task docs that upgraded in two separate mental steps,
• Redmine state that still behaved too much like a projection-only shadow,
• release publication that needed stronger exact-SHA and artifact-backed recovery rules.

0.3.7 makes those boundaries much sharper.

Agentplane 0.3.5 is the release where a few important surfaces stop behaving like half-finished transitions.

That matters because 0.3.x has been doing two kinds of work at once: tightening the repository workflow contract, and making the public product behave like an installed tool instead of a framework-internal script bundle. In 0.3.5, several of those moving parts finally line up.

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.