Changelog
Review changes before diagnosing new behaviour.
Every released version of RuleFence, what changed in it, and what that change means for a site already in production. If behaviour shifted after an update, start here.
- Current release 1.0.0
- Semantic versioning
- Security notes called out
Current release
- Version
- 1.0.0
- Requires WordPress
- 7.1 or later
- Requires PHP
- 8.0 or later
- Licence
- GPL-2.0-or-later
Release history
-
1.0.0 Current First public release
The complete control loop — identify, authorize, approve, execute, audit, control — in one local-first plugin.
- Every agent is a managed identity with its own credential, mapped to a least-privilege WordPress user.
- A permission matrix over every registered Ability: allow, require approval, or block. An Ability nobody granted is refused.
- Approvals are one-time and bound to the exact input they were granted for, so one cannot be reused for a different request.
- A contextual risk engine that reads the request itself and can only make a decision stricter, never weaker.
- Previews of what a write would do, before it happens.
- Every decision recorded with its reason in a hash-chained audit trail that can prove it has not been edited.
- Emergency controls that stop every agent, or drop the site to read-only, immediately.
- Readiness scoring and 31 runtime verification checks that re-test the governance controls on the installed site rather than assuming them.
- Guided setup that ends with the readiness score for the agent it just created.
Before 1.0.0
Development before this release was internal. No build older than 1.0.0 was ever distributed, there are no earlier tags, and there is nothing to upgrade from.
The internal history is kept in the repository’s development log rather than here, because a public changelog is read by people deciding whether to install the plugin — not by people working on it.
1.0.0 — first public release. Nothing to upgrade from.
Versioning policy
- Major
- A change to the governance model or the request contract that needs a decision from you before upgrading.
- Minor
- New capabilities and screens. Existing permissions, approvals, and evidence keep their meaning.
- Patch
- Fixes and hardening. Safe to apply on a production site.
What a release will never do quietly
- Widen an existing permission. A decision you made stays the decision you made.
- Shorten audit retention. Shortening always requires explicit confirmation from an administrator.
- Move a security control behind a paid plan. Every security control is identical in every edition.
Database schema
The domain model uses versioned custom tables. Schema upgrades run on activation and on update, and a schema that cannot be read or migrated fails closed — governance refuses requests rather than evaluating them against a broken schema.
Open Readiness and run verification. It re-tests the controls on the installed site instead of assuming the update landed correctly.
Stay current
Run the release you can verify.
Download the current build, then confirm the controls on your own site.
