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.

The cache is not the memory​

The tempting version of context management is to add a vector store and call the problem solved. Search gets better, at least for a while. Then somebody asks why the model trusts an old note, which source backed it, whether the note was superseded, or why two tasks disagree. The cache has no good answer because it was never meant to be the record.

Agentplane puts the record somewhere boring on purpose:

context/raw/**              raw source material
context/wiki/**             maintained markdown pages
context/facts/**/*.jsonl    sourced facts
context/graph/**/*.jsonl    entities and relationships
.agentplane/tasks/**        task intent, plan, checks, and ACR evidence

The SQLite projection and generated context output are still useful. They make search fast. They help agents retrieve the right material. But they are rebuildable. The durable memory is the repository content that a reviewer can open, diff, and challenge.

This is the part of Karpathy's note that feels most important for engineering teams. The wiki is not just a prettier answer format. It is a place where a project can accumulate synthesis without hiding the raw evidence.

Why agents need this more than humans do​

Humans carry messy background context in their heads. They remember that a release failed because a generated file drifted, or that a policy rule exists because a branch-pr close once went sideways. They also forget, but they forget slowly.

Agents forget immediately. Every session starts with a retrieval problem. If the only durable trail is a diff and a few scattered docs, the agent has to infer the operating model again. That is how the same mistake comes back wearing a different branch name.

Local context gives the agent a repo-owned place to learn from previous work. A completed task can become source material. A release lesson can become a wiki page. A repeated failure can become a sourced fact with a task reference. A relationship between policy, command behavior, and verification can become a graph edge instead of a paragraph buried in a chat transcript.

The result is not magic memory. It is a more honest kind of memory: files, refs, provenance, and checks.

What Agentplane adds to the LLM Wiki idea​

Karpathy's version is personal and exploratory. Obsidian is the workspace. The LLM is the wiki gardener. The schema file tells it how to behave.

Agentplane changes the setting. The workspace is a software repository. AGENTS.md is the policy gateway. Task records and Agent Change Records are part of the evidence. Context changes can move through the same lifecycle as code: task, plan, execution, verification, close.

That lifecycle matters because context can be wrong in ways that look confident. A bad wiki update is not harmless if future agents use it to choose a migration path or skip a check. So Agentplane keeps the context workflow conservative. It prefers source refs over memory vibes. It can write proposals before promoting canon. It checks context-bearing tasks with context verify-task so wiki pages, facts, graph edges, and capability notes do not quietly lose their sources.

The command surface is intentionally ordinary:

agentplane context init
agentplane context learn changes
agentplane context learn files ./notes.md --run
agentplane context learn tasks --tag release --limit 20 --dry-run
agentplane context search "release checklist"
agentplane context check

The interesting part is not the commands themselves. It is the boundary they create. Search is a tool. Context is an artifact. Verification is the guard that keeps the artifact useful.

Completed work is raw material​

One of the better sources of project knowledge is the work you already finished. Task READMEs know what was asked. Plans know what was approved. Verification notes know what actually passed. ACRs know which commits and checks were tied to the change.

Before 0.6, much of that history was evidence for review and closure. Now it can also become input for future context. That does not mean every closed task should automatically rewrite the wiki. Automatic promotion is how memory systems rot. It means completed work can be harvested, batched, reviewed, and turned into sourced updates.

This is where Agentplane's version of the LLM Wiki becomes less like a notes app and more like workflow infrastructure. The wiki is still readable markdown, but it is connected to task evidence, fact rows, graph relationships, and verification gates.

The practical shift​

The practical shift is simple: the next agent should not start from zero.

It should be able to search the local context, open the wiki page that explains the release path, see which task created the claim, inspect the source ref, and decide whether the claim still applies. If the answer is stale, that should become a context update with its own evidence.

That is slower than pretending the model remembers everything. It is also much safer.

Agentplane 0.6 is the point where context becomes part of the repository workflow. Not a side cache, not a private note pile, not another dashboard. A reviewed memory layer, kept close to the code it is supposed to explain.

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.

The problem with copied prompts​

Copied prompts feel cheap at the start. They are easy to paste into an agent session and easy to tweak when something feels off. The cost shows up later.

The prompt gets out of sync with the repository. It names files that moved. It describes checks that no longer exist. It contains a good recovery rule, but only in the private notebook of the person who wrote it. Another agent gets a slightly different version and behaves differently on the same kind of task.

That is not a tooling problem in the abstract. It is a review problem. If behavior changes because a prompt was copied badly, the repository has no good record of what changed.

Recipes make reusable behavior part of the repository story.

Why modular prompts changed the recipe story​

Agentplane's recipe work became much more useful once prompt material stopped being one large text surface. With modular prompt assembly, behavior can be named, compiled, and checked as smaller parts. A recipe can target a module instead of replacing an entire instruction file.

That changes the risk profile. Installing a recipe should not feel like letting an unknown prompt rewrite the whole operating model. It should feel closer to adding a reviewed capability: here is the behavior, here is where it binds, here is the policy it depends on, here is how to verify that it landed cleanly.

The early recipe system is still intentionally conservative. That is fine. Extensibility is only useful if teams can understand what they extended.

What recipes make better​

Recipes make repeated work less dependent on memory.

A code-map recipe can give agents a repeatable way to inspect a repository before changing it. A release-oriented recipe can preserve the evidence habit that keeps publication safe. A future review recipe can encode what kind of comments should become code changes, task findings, or follow-up issues.

The important part is not that a recipe saves a few commands. The important part is that the behavior becomes reviewable. It can be versioned. It can be discussed. It can be removed. It can be checked against the project instead of living as a private prompt.

This is why recipes fit Agentplane's larger model. Agentplane is not trying to make agents more mysterious. It is trying to make their work easier to inspect after the session is gone.

Recipes and policy have different jobs​

Policy says what must be true in this repository. Recipes add reusable ways to do work within those constraints.

That distinction matters. If a rule is mandatory for every agent, it belongs in the gateway or a canonical policy module. If a behavior is useful for a class of tasks, but optional or replaceable, it belongs in recipe space.

Keeping that boundary clean prevents recipes from becoming a second policy system. It also keeps projects honest about what they are installing. The recipe can help, but the repository still owns the final rules.

The practical shift​

The practical shift is from prompt reuse to behavior reuse.

Prompt reuse is fragile because it depends on text staying correct outside the system that uses it. Behavior reuse is stronger because it has a place in the repository, a version, and a verification path.

That is what recipes add to Agentplane. They let teams build on repeated agent workflows without turning those workflows into folklore. Less paste. Less guessing. More inspectable behavior close to the code it affects.

That sounds mundane until a task gets large. A release includes commits, but it also includes publication evidence. A migration includes file edits, but it also includes compatibility and rollback. A branch-pr close includes a merge, but the handoff matters just as much. Each of those jobs has a shape: the sources to inspect, the evidence to record, the checks that matter, and the point where the agent should stop instead of guessing.

Blueprints are Agentplane's way of making that shape explicit.

The route matters before the code changes​

Without blueprints, a repository can have good policy and still leave too much room for improvising. The agent sees a user request, loads some docs, picks a plan, and starts moving. If the task is small, this can be fine. If the task touches release, workflow, policy, or integration, the first wrong turn usually happens before the first code edit.

The wrong turn is subtle. The agent chooses a verification route that is too light. It treats a docs-only task like a runtime change, or the other way around. It forgets that branch-pr integration has a base-checkout phase. It records a plan, but not the evidence a reviewer will need later.

A blueprint gives the task a route before execution starts. It says what kind of work this is, which surfaces are in scope, what evidence belongs to the task, and which checks are expected. It does not remove judgment. It narrows the place where judgment is allowed to happen.

Why this made Agentplane better​

Agentplane already had a task lifecycle: create a task, approve a plan, execute, verify, finish. Blueprints made that lifecycle less generic.

That is the real improvement. A lifecycle without task shape can become ceremony. A task record says that work happened, but it may not say whether the work followed the right path. Blueprints connect the task type to a route that can be inspected.

For a docs change, that route is light. For a release, it is strict. For branch-pr work, it includes separate implementation and integration phases. For runner or workflow changes, it needs stronger evidence because a small mistake can change how future agents mutate the repo.

The value is not that Agentplane can print a nicer plan. The value is that repeated work stops being reinvented in every session.

A blueprint is not a checklist​

A checklist is easy to satisfy mechanically. Blueprints are more useful because they describe the operating model around the task.

They carry assumptions about ownership, mutation scope, policy modules, evidence, and recovery. They also make mismatches visible. If a task starts as "just docs" and then begins changing runtime code, that is not a tiny detail. It is a route change. The task should stop, get re-approved, and use a different verification contract.

This is exactly the kind of guardrail agents need. They are good at continuing. They are less good at noticing that continuation has changed the category of work.

What reviewers get​

Reviewers get a better question to ask.

Instead of asking only "is this diff correct?", they can ask "did this task follow the route that matches its risk?" That question is much easier to answer when the route is recorded in the task artifact and reflected in the checks.

This matters for long-running branches. It matters when several agents are working at once. It matters when a task closes days after the original prompt is gone. The blueprint gives the reviewer something more stable than memory and more specific than general policy.

What agents get​

Agents get less freedom in the places where freedom is expensive.

That is a good trade. The agent still chooses how to solve the task inside the approved scope. But the route tells it what not to skip: which docs are canonical, which verification gates matter, which handoff belongs to the workflow, and where to record evidence.

The result is calmer work. Fewer surprise scope jumps. Fewer "green but not actually ready" endings. Fewer clean-looking diffs that leave reviewers reconstructing intent from branch names.

Blueprints made Agentplane better because they moved process knowledge out of individual sessions and into repository-owned routes. That is where it belongs.

Agent Change Record v0.1 is that artifact.

An ACR is a deterministic JSON projection of one Agentplane task. It records the task intent, the accepted plan, the agent and toolchain context, policy decisions, changed files, verification results, approvals, evidence pointers, and closure state. It is generated from the same task lifecycle that Agentplane already writes into .agentplane/tasks/<task-id>/.

The point of naming it is practical. Review tools, CI gates, security scanners, and future agent runners need a stable thing to parse. "The agent said it ran tests" is not stable. A repo-local acr.json validated against an open schema is.

Generate one:

agentplane acr generate <task-id> --work-commit HEAD --write

Validate it:

agentplane acr validate .agentplane/tasks/<task-id>/acr.json

Use it as a merge gate:

agentplane acr check <task-id> --require-plan-approved --require-verification

ACR v0.1 is intentionally narrow. It does not store prompts, transcripts, private tool output, or model internals. It stores evidence pointers and hashes: enough for review, audit, and handoff without turning agent context into a second source of truth.

The trust model stays local-first. The repository remains the record. Agentplane derives the ACR from task files, policy state, verification evidence, and Git revisions, then validates the result against @agentplane/spec.

The schema is public:

https://agentplane.org/schemas/acr-v0.1.schema.json

In 0.5, the runner work can build on this artifact instead of inventing a separate reporting layer. Runner execution should produce the same kind of durable evidence that human-supervised agent work does today. ACR is the shared record that makes that possible.

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.

That is the product boundary Agentplane is built around. It is not another coding agent. It is the audit layer around coding-agent work.

The diff is too small a record​

A pull request can show the final files. It usually cannot show the agent's full operating context.

That context matters when work is bigger than a one-line edit:

• a task needs a durable ID,
• a plan needs approval before mutation,
• an agent needs role-specific constraints,
• verification needs evidence,
• integration needs a clear handoff,
• closure needs to say what actually passed.

Without that trail, reviewers end up reconstructing intent from a diff, a branch name, and whatever still exists in a chat window.

Agentplane makes the trail a repository artifact.

What changed in 0.4​

The 0.4 line moved Agentplane toward a more explicit recipe and prompt-module system.

The important part is not the internal architecture by itself. The important part is what it enables: narrow behavior modules that can be inspected, validated, and composed without replacing an entire instruction surface.

That matters for recipes because useful recipes should be specific.

A recipe should be able to add a code-map workflow, constrain a role, bind a policy module, or validate a prompt graph without asking the project to trust an opaque blob of instructions.

Recipes are audit behavior​

Recipes are easy to describe as automation. That is incomplete.

In Agentplane, a useful recipe is repeatable audit behavior:

• it declares what behavior it adds,
• it can be installed into a repository,
• it can be checked against local policy,
• it can produce reviewable task artifacts,
• it can stay inside the same Git-based lifecycle as normal work.

That is different from a script pile. The recipe is not only "run these commands." It is "add this repeatable behavior to the agent workflow and keep it inspectable."

Why this belongs in the repository​

Agent workflows become harder to trust when the durable record lives outside the repo.

Agentplane keeps the important parts close to the code:

• AGENTS.md is the policy gateway,
• .agentplane/policy/ holds canonical rules,
• .agentplane/tasks/<task-id>/ records task state and evidence,
• branch and pull request artifacts connect work to Git review,
• generated references and discovery files help humans and agents find the right path.

The repository remains the source of truth. Hosted tools can still help, but the audit record does not depend on them.

Where this fits with coding agents​

Claude Code, Codex, Cursor, and Aider are execution surfaces. They help generate, edit, and explain code.

Agentplane gives those agents an operating contract:

1. load the right policy,
2. create or use a task,
3. approve the plan,
4. execute inside scope,
5. record verification,
6. hand off integration cleanly.

That contract is intentionally boring. Boring is useful when an agent can mutate a repository.

What to read next​

Start with the short product framing:

• Why Agentplane exists
• How Agentplane compares
• Recipes overview
• Agentplane 0.4.0 release notes

The practical test is simple: after the agent finishes, can another human or agent understand why the change happened and why it was closed?

If the answer is no, the workflow is missing an audit layer.

The branch_pr workflow already separates implementation work from base-branch integration. 0.4.1 tightened the hosted-close path so protected main repositories can hand off to GitHub PR merges without pretending that a local integrate command mutated the base branch.

The release also improved the evidence trail around publishing. Release tasks now preserve clearer notes about what was checked, which artifact or channel was prepared, and what still requires a hosted action. That matters because release failures are rarely one command. They are a chain of version parity, generated assets, package metadata, remote checks, and final publication.

For users, the visible effect is quieter: fewer ambiguous close states, better release notes, and a workflow that treats protected branches as a real boundary instead of a nuisance.

That is the direction of the 0.4 line: keep Agentplane local-first, but make every important state transition explain itself.

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.

The first half of 0.3 was about making rules executable​

0.3.0 moved the project from large, fuzzy instruction files toward a policy gateway with routed modules. That mattered because agents do not fail only when they lack rules. They also fail when the rule graph is too vague to load deterministically.

The early 0.3 releases tightened that surface:

• AGENTS.md became a compact gateway instead of the place where every procedure accumulates.
• Policy modules became the canonical place for workflow, release, security, and DoD rules.
• Routing checks started treating policy shape as something testable.
• Release notes became real traceability records instead of generic summaries.

The point was not documentation polish. It was execution control. If an agent can mutate a repository, it needs a small, checkable path from request to policy to task state to verification.

The middle of 0.3 was about removing release optimism​

Several 0.3 patches were boring in the best possible way: they turned release assumptions into release gates.

The clearest example was the 0.3.8 and 0.3.9 installability incident. A package with a leaked workspace: dependency made it to npm, and a fresh install failed before the CLI could start. The fix was not only to remove the bad dependency. The release process had to reject that class of package before publish.

That theme repeated through the line:

• package parity checks got stricter,
• install smoke tests became more important,
• publish recovery became less ad hoc,
• generated references and task artifacts were checked more aggressively,
• branch PR closure evidence had to reconcile with task state instead of relying on operator memory.

This is why 0.3 has so many small releases. The product was not just gaining commands. It was learning which mistakes deserved a hard gate.

Branch PR became the default shape of serious work​

The later 0.3 work made branch_pr feel less like a workflow option and more like the right default for non-trivial changes.

That required a surprising amount of plumbing. PR artifact state had to be typed. PR opening had to become transactional. Integration needed to preserve branch history by default. Hosted close flows needed better reconciliation. Task branches and close branches needed clearer cleanup rules.

The result is not glamorous, but it is important: a task can move from plan to branch to PR to merge to closure with more of its evidence still attached.

That is the core operational idea in Agentplane. The repository should not have to trust that an agent remembers what happened. The evidence should be in the task, the PR artifacts, the branch history, and the release record.

Recipes pushed the system toward modular prompts​

Recipes were the pressure test.

As long as prompts are just large text files, a recipe can only do coarse things: replace a whole file, append a large instruction block, or hope that a textual patch lands in the right place. That is not a good substrate for agent-specific behavior.

The 0.3 line added enough recipe and prompt groundwork to make the next step obvious:

• recipe manifests gained prompt mutation concepts,
• prompt fragments gained names and selectors,
• prompt graphs gained diagnostics,
• init and runner paths began compiling prompt material instead of copying it blindly.

At that point, the old patch-release framing stopped fitting the change. A modular prompt layer is a platform boundary. It changes what recipes can target and how future agents can be assembled.

Why 0.4 starts at prompt modules​

0.4 is the right boundary because it names the new abstraction.

The work now moves from "make the old instruction surface safer" to "treat prompts as compiled, addressable modules." That unlocks a different kind of recipe: one that can patch a named behavior, bind a module, disable a specific fragment, or validate that a graph still contains the right policy pieces.

That does not make prompts magic. It makes them less opaque.

The practical target for 0.4 is simple:

• agent instructions should be assembled from named modules,
• generated project files should come from the same module graph,
• recipes should be able to target modules rather than whole prompt files,
• diagnostics should explain graph drift before it becomes runtime confusion.

That is enough of a conceptual shift to stop calling it another 0.3.x patch.

What 0.3 leaves behind​

The useful lesson from 0.3 is that agent infrastructure improves when weak assumptions become executable checks.

The line started by making policy routing explicit. It then made releases, installability, task closure, PR artifacts, and recipe prompt behavior more testable. By the end, the remaining problem was no longer "where do we put the instructions?" It was "how do we let agents and recipes change the right part of the instruction graph without rewriting the whole thing?"

That is the road to 0.4.

The formal source records remain the release notes under /docs/releases, with v0.3.29 as the final published 0.3 release.

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.

Why this is a 0.4 release​

The final 0.3 line made the old workflow safer. It tightened policy routing, task closure, release evidence, package checks, and branch PR discipline.

0.4 starts because the core abstraction changed.

Before this release, a prompt was mostly a file boundary. If a recipe needed to adjust one behavior, it had to work against a broad text surface. That made small changes feel larger than they were and made diagnostics harder to trust.

In 0.4.0, prompt material is organized as named fragments and compiled modules. The important boundary is no longer "which file contains this instruction?" It is "which module owns this behavior, and what is allowed to change it?"

What changed​

This release adds the first production version of the modular prompt layer:

• prompt fragments have parser contracts and names,
• prompt modules compile into deterministic generated assets,
• the framework prompt registry is built from fragmented source material,
• init compiles gateway policy and agent profiles from the same graph model,
• runner prompt assembly can use module-aware prompt material,
• recipe manifests can express prompt module declarations and mutations,
• diagnostics can detect prompt graph drift before it becomes runtime confusion.

The immediate user-facing result is quieter consistency. Generated AGENTS.md, policy modules, agent profiles, and runner prompt behavior now have one source model instead of several related but fragile surfaces.

Why recipes needed this​

Recipes are the reason this release matters.

A useful recipe should be able to say something precise: change this behavior, add this policy module, bind this agent-specific instruction, or validate that this prompt graph still contains a required safety rule.

That is hard if the only target is a whole prompt file.

With module-level prompt assembly, recipes can move toward narrower and more reviewable changes. The recipe layer is still being built out, but 0.4.0 gives it the substrate it needed: named modules, mutation boundaries, selectors, and graph diagnostics.

Upgrade notes​

Existing 0.3.29 projects do not need a manual migration.

Projects that regenerate Agentplane assets through init or upgrade paths will receive prompt assets compiled from the modular prompt graph. Recipe authors can begin designing against prompt modules and selectors, while still following the documented recipe manifest contract.

The 0.3 maintenance branch remains pinned to v0.3.29. The modular prompt architecture starts in the 0.4 line.

Release evidence​

The release was published through the hosted branch PR route:

• agentplane, @agentplaneorg/core, and @agentplaneorg/recipes are all published as 0.4.0 on npm,
• the remote tag v0.4.0 resolves to 060b70ca465b780337c2ec9da035fc66e615803f,
• the GitHub Release v0.4.0 is published.

The formal release notes are available at /docs/releases/v0.4.0.

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.

0.3.8 was mostly about clearing the codebase for what comes next​

There was no single marquee feature in 0.3.8, and that was the point.

Most of the patch was internal convergence work:

• shared task-mutation and doc-mutation paths,
• shared workflow-transition executors,
• shared CLI emitters and output contracts,
• smaller backend, upgrade, and runner modules,
• less duplicated test scaffolding around those same seams.

This kind of release is easy to undersell because the visible CLI surface barely moves. But it matters. 0.4 and 0.5 were going to land on a codebase that still had too many parallel paths for the same behavior, and that gets expensive fast once you start shipping larger features.

So 0.3.8 spent its budget where it would compound: fewer duplicated branches, narrower files, clearer contracts.

The important failure in 0.3.8 was not in the code logic​

The code in the repository was cleaner. The shipped package was not.

What escaped into npm was a publishable manifest that still referenced a private workspace package:

• @agentplane/recipes=workspace:packages/recipes

That is enough for npm to refuse the install entirely. No task flow was required to trigger it. No edge-case backend was involved. A fresh global install failed before users even reached agentplane --help.

That kind of failure changes the meaning of a patch release. Once installability is broken, the rest of the improvements do not matter until the package is valid again.

0.3.9 turns installability into part of the release contract​

0.3.9 fixes the broken package, but the more important part is what changed around the fix.

This patch does three concrete things:

• removes the leaked workspace dependency from the published CLI package,
• adds a release parity guard that rejects publishable manifests containing workspace: dependencies,
• hardens hook-runner fallback behavior so release and upgrade smoke paths do not quietly depend on whatever global agentplane version happens to be on the machine.

That last part matters more than it sounds. A release pipeline becomes fragile when local hooks, smoke tests, or upgrade checks accidentally borrow behavior from an unrelated globally installed binary. 0.3.9 reduces that ambiguity.

Read 0.3.8 and 0.3.9 together​

Taken separately, 0.3.8 looks like an internal prep patch and 0.3.9 looks like a narrow packaging fix.

Taken together, they say something more useful:

1. the project is actively reducing internal duplication before the 0.4 and 0.5 line,
2. the release process is getting less forgiving about publish-time mistakes,
3. installability is now treated as a release invariant, not as a hopeful side effect of passing tests.

That is the real outcome of this patch line.

Upgrade note​

If you are on 0.3.7, skip 0.3.8 and move straight to 0.3.9.

If you already tried 0.3.8 and hit the EUNSUPPORTEDPROTOCOL install failure, 0.3.9 is the corrective release. There is no intended workflow migration in this patch line. The user-facing point is simple: the package installs again, and the release path that produced the broken artifact is stricter than it was before.

The formal source records remain the release notes at /docs/releases/v0.3.8 and /docs/releases/v0.3.9.

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.

Legacy recovery is closer to a real operator path now​

The most practical change in 0.3.7 is that older initialized repositories are no longer left in a fuzzy “upgrade mostly worked” state without a clear handoff.

The release tightens the supported recovery path for repositories that still carry legacy README v2 task docs or partial managed-tree drift:

• agentplane doctor reports the state more explicitly,
• agentplane upgrade --migrate-task-docs --yes can bridge more of the recovery in one run,
• and upgrade output now makes it clearer when task migrate-doc is still the next action.

That is the right direction for a workflow tool. Recovery should be diagnosable and operational, not folklore.

Redmine gets closer to canonical task state​

0.3.7 also pushes Redmine-backed repositories closer to the same canonical task-state model that local repositories already expect.

This release adds more of the missing plumbing around canonical state, revision-aware round trips, lifecycle metadata preservation, readiness checks, and live sync/conflict coverage. In plain language, that means Redmine-backed state is less dependent on lossy projections and better aligned with the same sections-and-revision model the local task system now treats as real state.

That matters because backend integration gets dangerous when users cannot tell whether the system owns a canonical record or merely a cached rendering of one.

README v3 stops feeling like a migration tail​

Another smaller but important shift in 0.3.7 is that README v3 stops behaving like the “newer format that still leaks old edge-cases.”

Two visible fixes matter here:

• task derive can now carry --verify and seed implementation Verify Steps more like task new,
• verification details keep multiline formatting instead of collapsing into literal escaped newlines.

This is not a redesign. It is cleanup of the task surfaces people actually touch while working.

The release line itself is stricter now​

The release machinery also got tighter in 0.3.7.

This patch adds stronger release-ready and publish-result artifact use, exact-SHA recovery flows, and better parity between the local prepublish gate and the GitHub publish path. The result is a release process that is harder to fake, easier to recover, and less dependent on mutable assumptions about “the latest successful run.”

That is especially important for patch releases. The release system itself should not be the least trustworthy part of the release.

The practical shift​

0.3.7 is a convergence release, but in a different way from 0.3.5.

It makes three things truer than they were before:

• older repositories have a clearer supported recovery path,
• Redmine-backed state is less projection-fragile,
• release publication is stricter from local verification through GitHub and npm.

That is exactly the kind of patch-line work that compounds well.

Upgrade note​

There is no new breaking workflow-mode change in 0.3.7.

If your repository is already on README v3 and current framework assets, the visible changes are mostly in recovery behavior, backend modeling, and release/runtime strictness.

If your repository is older, the practical path is now clearer:

1. Run agentplane doctor.
2. If diagnostics call for it, run agentplane upgrade --migrate-task-docs --yes.
3. If legacy task docs still remain, follow the explicit handoff to agentplane task migrate-doc --all.

The formal source record remains the release notes at /docs/releases/v0.3.7.

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.

README v3 is no longer “the new shape.” It is the shape.​

The first practical change in 0.3.5 is that README v3 stops being one task-document format among several partially live ones.

The repository config, schema defaults, templates, migration tooling, and task-facing docs now point at the same active structure:

• Summary
• Scope
• Plan
• Verify Steps
• Verification
• Rollback Plan
• Findings

That sounds procedural. It is also important operational cleanup. A workflow tool should not make users guess which task-document contract is current.

0.3.5 closes the last mixed-contract gaps and makes migration behave more predictably for repositories that still carry legacy README v2 task records.

The docs shell stops fighting the page​

Another visible improvement in 0.3.5 is the documentation frame itself.

This release hardens the docs shell so it depends on repo-owned hooks and stable wrappers instead of brittle theme-generated selectors. That sounds technical, but it shows up in user-facing ways:

• wider reading gutters on large layouts,
• less decorative chrome around the docs frame,
• no right-side subsection map competing for attention,
• a sidebar that stays aligned under the navbar instead of drifting underneath it.

This is the right kind of docs work for a patch release. Not a redesign. Just fewer layout oddities and less theme-fragile CSS.

Projection-first backends become real product behavior​

The backend story also gets noticeably cleaner in 0.3.5.

Before this release, external backends were still too easy to think about as “network-backed task commands with some local caching around them.” That is the wrong model for an install-first tool.

0.3.5 makes the intended contract more explicit:

• the backend owns a canonical source,
• the repo keeps a local projection,
• ordinary task reads happen from that projection,
• explicit sync is the network boundary,
• .agentplane/tasks.json is an export snapshot, not the canonical task source.

In practical terms, Redmine-backed repos stop performing hidden refreshes during ordinary task list, task show, and doctor flows. Reads stay local until the operator explicitly runs a backend sync.

That is calmer, cheaper, and easier to reason about.

Doctor and migration are less misleading now​

Two smaller fixes in this release matter more than they sound.

First, doctor now evaluates migration state from the right backend-aware projection path instead of trusting a possibly stale export snapshot.

Second, task migrate-doc now keeps the exported task snapshot synchronized through the active backend flow instead of depending on a local-only special case.

Together, those changes reduce a class of “everything looks clean, but the repo is actually out of sync” problems that are disproportionately annoying in patch-level workflow tooling.

The practical shift​

0.3.5 is not a feature-spike release. It is a convergence release.

It makes three things truer than they were before:

• README v3 is the actual active contract,
• docs pages are less fragile and easier to read,
• external backends behave like projection-first runtime surfaces instead of implicit network clients.

That is exactly the kind of tightening a patch line should deliver.

Upgrade note​

There is no breaking workflow-mode change in 0.3.5.

Repositories already on README v3 do not need a new manual migration step. Repositories that still carry legacy README v2 task docs can continue to use agentplane task migrate-doc --all, and the migration flow now keeps the projection snapshot synchronized through the active backend path.

If you use Redmine, the intended boundary is now sharper: ordinary reads stay local, while agentplane backend sync redmine --direction pull remains the explicit refresh path.

The formal source record remains the release notes at /docs/releases/v0.3.5.

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.

The startup path is self-contained now​

The most important repair in 0.3.4 is simple: installed runtime guidance no longer points users at repo-only docs artifacts.

That bug was subtle in one sense and obvious in another. The startup flow worked fine as long as you were standing inside the framework repo, where generated docs files already existed. But for a normal npm-installed user, a startup surface that points to a non-installed local docs file is just broken.

0.3.4 cleans this up by making the startup path self-contained again:

• AGENTS.md,
• agentplane quickstart,
• agentplane role <ROLE>,
• and the installed runtime guidance all line up around files and commands that actually exist in the user repo.

That is the right direction. Public product behavior should not depend on framework-internal artifacts.

Upgrade finally restores the workflow shell​

The second big fix is in upgrade.

Older initialized repositories could update managed files and still miss workflow runtime artifacts such as:

• .agentplane/WORKFLOW.md
• .agentplane/workflows/last-known-good.md

That meant the repo was “upgraded” in one sense but still incomplete in another.

0.3.4 closes that gap. If the repository is initialized enough to own the workflow surface, agentplane upgrade --yes now restores those runtime artifacts as part of the normal upgrade path.

This is exactly the kind of thing users should not have to discover manually after the fact.

Role help and installed prompts now describe the same world​

Another good repair in 0.3.4 is the alignment between installed prompts and CLI role help.

Earlier in the 0.3.x line, these surfaces were both improving, but they were still not the same surface. That leaves room for drift: the installed agent profile says one thing, while agentplane role CODER explains the same role a little differently.

0.3.4 tightens that by making installed profiles the primary surface for role help, with CLI-specific notes layered on top instead of a separate competing guide.

That sounds like polish. It is also operational clarity.

The practical shift​

This is not a flashy release. It is a product-boundary release.

It makes three things truer than they were before:

• the installed startup path is self-contained,
• upgrade can bring an older initialized repo back to a complete workflow state,
• installed prompts and role help describe one coherent operating model.

That is exactly the kind of patch release you want in a tool like this. Less accidental framework leakage. Fewer half-upgraded states. Less drift between what the tool says and what it actually installs.

Upgrade note​

There are no breaking workflow-mode changes in 0.3.4.

If you maintain older initialized repositories, agentplane upgrade --yes is now more complete than it was in earlier 0.3.x builds because it restores required workflow runtime artifacts when the repository already owns the managed workflow tree.

The formal source record remains the release notes at /docs/releases/v0.3.4.

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.

The runtime got easier to trust​

The biggest shift in 0.3.3 is runtime visibility.

This release adds agentplane runtime explain, which sounds small until you hit the class of failure it removes. When a repo expects one CLI version and the machine is running another, or when a framework checkout is quietly using the wrong binary from PATH, a lot of confusion follows from that single mismatch.

0.3.3 makes that state explicit:

• which binary is actually running,
• which framework source it resolves to,
• which version the repository expects,
• and what to do if those things do not line up.

That is less glamorous than new commands usually sound, but more valuable. Good tooling should tell you which reality you are in before it asks you to debug anything else.

README v3 became the real task-doc contract​

This release also completes the task README transition in a serious way.

Older task docs were still readable, but the system needed a cleaner target format. README v3 becomes that target in 0.3.3, with a better split between plan, verification, rollback, and local findings.

The important part is not just the new layout. The important part is that migration is now treated as a real path:

• legacy README v2 tasks still read correctly,
• new tasks default to README v3,
• agentplane task migrate-doc exists as a normal upgrade step,
• docs and diagnostics explain the recovery flow instead of assuming a pristine repo.

That matters because task docs are not decorative. They are part of the operational state of the repository.

Release and recovery got stricter in the right places​

0.3.3 also hardens the release path itself.

This release closes a few annoying but expensive failure classes:

• release apply recursing into local pre-push,
• generated docs drifting during release mutation,
• the repository silently expecting a newer CLI than the one the user is running,
• partial publish states without a clear recovery path.

The pattern underneath all of these fixes is the same: release behavior should be explicit before things go wrong, not only diagnosable afterward.

Local feedback got lighter​

Another practical gain in 0.3.3 is the local developer loop.

The repo now does a better job of routing smaller changes through narrower validation buckets. That does not remove the heavy path for broad changes, but it does stop every narrow docs or CLI-help edit from paying the same price as a release-sensitive code change.

doctor also became less noisy and faster on large historical archives, which matters more than it sounds once a repository has accumulated real history.

Practical outcome​

For everyday use, 0.3.3 means:

• runtime state is easier to inspect,
• older repositories have a real task-doc migration path,
• releases and recoveries are harder to fake and easier to reason about,
• local feedback loops waste less time on obviously narrow changes.

That is a broad release, but it is not unfocused. The thread is consistent: make hidden operational state visible, then make the normal path shorter.

Upgrade note​

There are no breaking workflow-mode changes in 0.3.3.

If your repository still contains legacy task docs, run agentplane doctor and follow the recovery path it gives you. In practice that usually means upgrading the framework and then migrating task docs to README v3 where needed.

The formal source record remains the release notes at /docs/releases/v0.3.3.

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

Upgrades became more direct​

Before 0.3.2, upgrade behavior still carried older assumptions from an earlier model. By that point the framework already owned the managed files, but the UX had not fully caught up.

0.3.2 shifts the default in a more practical direction:

• managed framework files now apply by default,
• doctor gives better guidance when a repository is only partially upgraded,
• docs explain more clearly which files belong to the framework and which local file is still meant for local incidents and overrides.

The practical result is simple: fewer half-upgraded states, less guessing, less “why is this repo in a weird hybrid mode?” energy.

Finishing a task no longer dirties the tree by default​

This release also tightens the direct workflow.

In normal direct-mode use, finish now records task metadata and creates the close commit automatically unless you opt out. That removes a long-running annoyance where the task looked done but the repo still had a dirty README sitting there.

This is a small change, but I would not call it minor. A task marked done should leave the repo looking done.

Framework development got less misleading​

One of the most practical changes in 0.3.2 is for people working on Agentplane itself.

If agentplane from PATH is launched inside the framework repository, it now hands off to the repo-local binary by default instead of quietly using an older global install. There is still an opt-out, but the default is finally closer to what a developer expects.

That matters because mixed runtime sources create very confusing failures:

• the docs in the checkout say one thing,
• the code in the checkout says the same thing,
• but the executed binary still behaves like an older version.

0.3.2 does not erase that class of confusion completely, but it cuts out the worst trap.

Release and docs discipline also improved​

The same release also cleaned up the release path and the agent-facing docs layer.

It fixed a case where release apply --push --yes could hang after creating the commit and tag, improved the test coverage around that path, and aligned the main bootstrap surfaces so agents see one clearer startup path instead of several competing ones.

That may sound internal, but users feel it anyway. A tool is easier to trust when its docs, startup help, and release behavior stop drifting apart.

Practical outcome​

For most users, 0.3.2 means:

• upgrading older or partially patched repositories is easier to recover,
• finishing work in direct mode leaves fewer cleanup surprises,
• framework contributors are less likely to accidentally run the wrong binary,
• startup guidance across CLI and docs is more consistent.

This is not a flashy release. Fine. It removes real friction from the actual workflow, which is more valuable.

Upgrade note​

There are no breaking API or workflow-mode changes in 0.3.2.

Framework developers should update their installed CLI if they want the new repo-local handoff behavior inside the framework checkout. Older initialized repositories should run agentplane doctor after upgrade and follow the suggested recovery command if the managed policy tree is incomplete.

The formal source record remains the release notes at /docs/releases/v0.3.2.

What actually changed​

Earlier releases mostly tightened specific commands. 0.3.0 went one level up and tightened the layer that tells agents which rules to load, when to load them, and how those rules connect to task state and verification.

That was overdue. Policy sprawl creates a very annoying failure mode: a repo looks governed, but agents still load the wrong docs or skip the right ones.

0.3.0 cuts a lot of that ambiguity out.

What became explicit​

The headline change is the policy-gateway refactor.

Before 0.3.0, it was too easy for the policy surface to get fuzzy over time. One repo might load too many rules. Another might skip the important ones. A third might keep a huge AGENTS.md that looked authoritative while the real logic had already drifted somewhere else.

0.3.0 makes that structure more explicit.

The AGENTS.md gateway was rebuilt around clearer routing into dedicated policy modules, with stronger rules for conditional loading and stricter checks that the routed policy graph actually matches the repository rules.

In practice, this release pushes three things into the open:

• the gateway is treated as real product surface, not throwaway scaffolding,
• routing checks are tied more directly to task-document quality gates,
• incident logging now has one canonical place instead of several half-official ones.

This is not about prettier docs. It is about making execution rules easier to reason about.

Release notes had to get better too​

0.3.0 also tightened the release path itself. Release-note validation now expects real coverage instead of vague summaries that technically pass but tell you almost nothing.

That change is less glamorous than it sounds, but it matters. Weak release notes are not just boring. They break traceability. If a release changes routing, startup defaults, or publish behavior, the written record has to say so plainly.

Setup and startup got cleaner​

There were also a few practical ergonomics fixes underneath the bigger policy work.

Light-profile users now get simpler startup behavior, with hooks disabled by default and a less noisy initial experience. Linked global CLI usage was also relaxed by reducing stale-dist friction outside the framework checkout.

That combination matters. The workflow got stricter, but the common setup path got less annoying.

Publishing is more rerunnable​

The release also made publish reruns less brittle.

Two related problems were addressed:

• publish reruns should not fail only because a release tag already exists on origin,
• release continuation should remain possible when tags were created earlier in the flow.

That is a small operational fix, but a good one. Automation should be able to tell the difference between a real integrity problem and a safe retry.

Practical outcome​

For users, the net effect is pretty clear: governance became easier to read and easier to trust.

After this release, the workflow should be easier to reason about because:

• policy loading is more explicit,
• gateway structure is easier to verify,
• release records are expected to be more concrete,
• install and startup behavior are less brittle for common setups,
• publish flows are more tolerant of safe reruns.

That is the thread running through the whole release. Fewer fuzzy edges. Fewer hidden rules.

Upgrade note​

There are no breaking API changes called out for 0.3.0, but repositories using policy modules should still run routing checks after upgrade to make sure local customizations did not drift.

The formal source record remains the release notes at /docs/releases/v0.3.0.

Why 0.3.1 had to happen​

The problem was not subtle. 0.3.0 had already been burned in npm history, so trying to ram the same version through again would have been the wrong fix.

0.3.1 takes the practical path instead:

• move the release line forward to the next valid version,
• repair the publish and release notes flow,
• clean up the public docs and website surfaces around that release.

That is what release discipline looks like in real life. Not just writing better code, but refusing to fake a clean publish path when the registry has already said no.

The release pipeline was recovered, not papered over​

The best thing about 0.3.1 is that it stays honest.

Instead of trying to reuse 0.3.0, the release process moved to 0.3.1 and documented the situation clearly. That is a better model for teams because it preserves traceability:

• which version was attempted,
• which one actually shipped,
• which recovery steps were required to get back to a clean release path.

This sounds procedural until you are the person debugging upgrades later. Clean release metadata saves a lot of guesswork.

Task-doc updates became less awkward​

0.3.1 also cleaned up a smaller but real annoyance: batched task-doc updates.

The written guidance now explicitly allows agents to update task-doc sections in one grouped turn before approval starts. The sequencing rule still stays strict where it matters: approval and start-ready must still happen in order.

So the guidance got easier to use without turning the lifecycle into mush.

The website got quieter again​

Part of 0.3.1 was also admitting that the website had drifted in a bad direction.

The release tightened the docs shell, improved spacing and left-aligned reading flow, simplified the blog index, and then intentionally restored the homepage to a quieter placeholder-style landing.

I think that was the right decision. This product does not need a loud marketing front page if the real value is operational clarity.

Practical outcome​

For users, 0.3.1 means three things:

• the 0.3.x line is publishable again on a clean version path,
• task-doc guidance is clearer for normal use,
• the docs and blog surfaces are less noisy and easier to scan.

It is not a big release. It is a useful one. It removes confusion in exactly the places where confusion tends to multiply.

Upgrade note​

There are no breaking API or workflow-mode changes in 0.3.1.

If your repository consumes framework policy templates, it is still worth syncing or upgrading them so the clarified batched task-doc guidance lands locally as well.

The formal source record remains the release notes at /docs/releases/v0.3.1.

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.

Why this one mattered​

The underlying problem was simple: agents could still do more than the task really allowed.

In practice that risk shows up in three places:

• commit scope expands beyond the files a task should touch,
• release operations run with weak pre-publish validation,
• documentation drifts away from the actual CLI and process rules.

0.2.25 tightened all three at once.

Safer commit boundaries​

The main change was stricter commit behavior. The workflow moved toward explicit allowlists, so unrelated files are much less likely to get staged by accident.

That sounds mechanical, but it changes the social side too. Once a team thinks the agent might quietly scoop up unrelated files, every automated step starts to feel suspicious.

The release pushes the tool toward a cleaner rule: touch only what the task allows, and make that boundary visible.

Cleaner release flow​

The release path got stricter too. Pre-publish validation and CI gates were tightened so a version is less likely to ship from partial or drifting state.

Operationally, this reduces two classes of failure:

• publishing before the expected checks have actually passed,
• shipping a version whose notes, docs, or package state do not match.

That is the right tradeoff here. A slower release is fine. A blurry one is not.

Documentation parity​

The release also tightened docs and website consistency checks. That sounds secondary until you trip over bad guidance in a real repo.

For a policy-heavy workflow tool, docs drift is not an editorial blemish. It is a contract bug. If help text and real behavior split apart, people will do the wrong thing very confidently.

So 0.2.25 treated documentation quality as part of runtime reliability, not as bonus polish.

Practical outcome​

If you run Agentplane in a policy-sensitive repo, this release mostly improves one thing: trust.

The intended workflow after 0.2.25 is more constrained:

• commits should stay closer to approved task scope,
• releases should be blocked earlier when validation is incomplete,
• docs should reflect the system that users actually execute.

It is a narrower system. Good. Narrow beats fuzzy when a tool can mutate your repo.

Next path​

If you want the formal version record, the release notes are at /docs/releases/v0.2.25. The broader direction is in the roadmap entry.

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.

Why this roadmap exists​

Three pressures keep showing up:

• teams want more automation, but they do not want agents freelancing in the repo;
• task state needs to move between local repositories and external planning surfaces without making every integration a core backend;
• prompt quality and execution quality have to be treated like product design, not prompt tinkering;
• extension points need to be explicit, otherwise every serious team ends up forking the framework.

So the order matters. Foundation first. Then contracts. Then extension. Then a blueprint layer that can explain the route a task is taking. Only after that does it make sense to talk about more autonomous execution.

Version-by-Version Roadmap​

0.1 Foundation and Baseline Workflow​

• Establish the initial Agentplane CLI baseline and project structure.
• Define the first end-to-end task lifecycle for local execution.
• Introduce core task tracking, verification logging, and export conventions.

What that means in practice:

• a team can run a local workflow with explicit task state and an audit trail that actually survives inspection.

0.2 Architecture and Codebase Formalization​

• Formalize architecture boundaries and core codebase contracts.
• Modularize subsystems to keep scaling simple and predictable.
• Formalize operational processes at the CLI level.

What that means in practice:

• less hidden coupling and fewer “why does this command know about that file?” moments.

0.3 Prompt System Improvements​

• Improve agent prompts for better determinism and execution quality.
• Formalize process contracts at the agent-prompt level.
• Deliver a dedicated Claude Code-compatible version.

What that means in practice:

• agents behave more predictably under real repo constraints, not just in clean demos.

0.4 Recipes and Plugin Extension Model​

• Support custom agents, tools/SKILLS, and scenarios through recipes.
• Define recipe packaging, versioning, and compatibility rules.
• Add recipe discovery, installation, and validation flows in CLI.

What that means in practice:

• teams can add domain-specific behavior without patching core every time they need one more tool or scenario.

0.5 Blueprints and Cloud Backend​

• Add typed blueprint contracts for task execution routes.
• Ship built-in blueprint definitions, validation, resolver output, and explanation surfaces.
• Make selected routes visible in task evidence before repository mutation.
• Allow projects to choose a cloud backend during initialization or configuration.
• Keep external platform sync behind the cloud backend boundary so GitHub Projects, Redmine, or other planning systems can evolve outside the repo-local task store.

What that means in practice:

• task routing becomes explicit before runner autonomy increases, and cloud-backed projects get one stable Agentplane backend surface for external platform synchronization.

0.6 Agentplane Runner​

• Build Agentplane Runner on top of resolved blueprints.
• Enable coordinated multi-agent execution through blueprint-aware task routes.
• Provide orchestration primitives for reliable autonomous runs without weakening repo-local policy gates.

What that means in practice:

• autonomous execution starts from a route contract the agent can explain, verify, and record.

0.7 Evaluation and Recursive Improvement​

• Define repeatable evaluations for agents, recipes, prompt modules, blueprint resolution, runner behavior, and lifecycle flows.
• Run scenario-based evaluations with reproducible inputs, structured evidence, deterministic gates, and baseline-vs-candidate comparison.
• Support recursive prompt and recipe improvement only when quality improves without critical regressions.

What that means in practice:

• evals become a release-quality system after the execution route and runner layers are stable enough to measure.

What changes for users​

If the roadmap lands the way it should, users get:

• Faster execution loops with clearer policy boundaries.
• Clearer task route explanations before mutation.
• A cloud backend option for teams that want external platform synchronization without replacing repo-local policy.
• Better reproducibility for planning, implementation, and verification paths.
• Lower overhead when introducing custom automation patterns.
• Stronger traceability from intent to repository mutation.

That is the optimistic version. The harder part is making sure the system stays legible while it grows.

Risks and open questions​

The main risks are not mysterious:

• Over-complex extension surfaces can reduce adoption if plugin contracts are not strict enough.
• Cloud sync can create conflicting sources of truth if the managed backend does not preserve canonical task state and sync timestamps.
• Autonomous execution can increase failure blast radius if guardrails are not enforced at runtime and tied to the resolved blueprint.
• Prompt formalization must remain aligned with real execution constraints, not only prompt style.

There are also a few design questions we have not earned the right to hand-wave away:

• Blueprint resolver behavior when task intent, workflow mode, and available backend capabilities point to different routes.
• Cloud backend connection and sync semantics under intermittent network or external platform changes.
• Runner execution model under mixed local/remote tool constraints.
• Cross-recipe compatibility guarantees and version pinning strategy.
• Default observability contract for multi-agent runs and external sync decisions.

What comes next​

The near-term work is more grounded than a runner-first roadmap would suggest:

• finish the contract surfaces,
• ship the blueprint layer,
• expose the cloud backend choice cleanly,
• ship the milestones one by one,
• keep the release notes honest as each part lands.

The direction is simple enough. More automation, yes. Sloppier governance, no.