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.