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.
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.