Library page — bulk Enable All / Disable All action buttons. A new right-aligned header row above the tab strip on ?page=acrossai-abilities-library renders two side-by-side buttons that toggle every ability category currently in view with a single click. Actions are scoped to the active tab: on the All tab they touch every registered category; on a specific tab (Core, Blocks, Themes, Users, Cache, File Manager, Cron, Database, Plugins) they only touch categories whose ability metadata declares that tab_group. Categories in other tabs pass through byte-for-byte unchanged. Each category’s mode (All / Specific) and per-slug selections are preserved on both actions — a Disable All → Enable All cycle is a lossless round-trip. Persisted via the existing POST /acrossai-abilities-library/v1/abilities/config REST route (manage_options + nonce, unchanged). See PR #68.
URL-synced tabs on the Library page. The active tab is now reflected in the browser URL as ?tab=<slug>. Deep-linkable, bookmarkable, and browser back / forward navigation re-syncs the visible tab. Direct-navigation to ?page=acrossai-abilities-library&tab=themes opens the Themes tab on first paint. Invalid tab values silently fall back to the default All view — no error, no console warning. The default All view keeps the canonical URL clean by removing the tab query arg entirely.
Disabled-card UI refresh on the Library page. Disabled category cards now show the master toggle + category label + chevron (visible whenever the category has at least one registered ability). Expanding the chevron on a disabled card reveals a readonly bullet-style preview of the abilities in that category (with descriptions). The All / Specific mode selector and interactive per-ability checkboxes remain hidden while the card is disabled — no interactive control can render on a disabled card even when the stored mode is Specific. The stored mode and per-slug selections are preserved so re-enabling restores the prior configuration exactly. Manual per-card disable and bulk Disable All produce identical card DOM.
0.0.6
BREAKING (downstream integrators) — 17 ability category slugs rebranded from acrossai-core-abilities-<domain> to acrossai-abilities-manager-<domain>, and 176 ability slugs rebranded from acrossai-core-abilities/<verb> to acrossai-abilities-manager/<verb>. The companion acrossai-core-abilities plugin’s entire 201-file runtime (17 Category_Registrars, 176 ability classes, 8 helper classes, plus the extra-MIME-types admin field) is absorbed into this plugin. Every category and ability slug is renamed uniformly; ability payload shapes and permission callbacks are preserved verbatim. Downstream code (MCP servers, REST/WP-CLI callers, integration tests) that referenced the legacy acrossai-core-abilities-* slugs by string must update on cutover. Ability payloads themselves are unchanged. See PR #65.
Absorbed extra-MIME-types Settings field lands under the Abilities tab. The companion plugin’s Core settings tab is retired; its “extra allowed upload MIME types” field now renders inside the shared Settings → Abilities tab. The companion’s separate uninstall opt-in is folded into the manager’s existing single acrossai_abilities_uninstall_delete_data opt-in — no second checkbox appears. Activation-time migration copies the legacy option (acrossai_core_abilities_extra_mimes → acrossai_abilities_manager_extra_mimes), OR-monotonically folds the legacy uninstall opt-in into the manager’s opt-in (never demotes a manager-true value), and deletes both legacy option rows. Existing admin configuration is preserved. See PR #65.
Retire the acrossai-core-abilities companion plugin. After upgrading to 0.0.6, deactivate and uninstall the standalone acrossai-core-abilities plugin — all 176 abilities are now provided by this manager plugin directly. Keeping both plugins active will emit duplicate-registration notices from the WP Abilities API on every request. Removal of the companion plugin folder from production sites is an operational task, separate from this release.
Library page — Themes / Blocks / Plugins / Users / Database / Cron / Cache / File Manager get their own tabs. The absorbed categories are promoted from the shared “Core” tab into their own top-level tabs on the Ability Library page (?page=acrossai-abilities-library). The “Core” tab stays pinned as the second option (immediately after “All”) regardless of alphabetical ordering. The “No abilities registered yet” empty-state copy is updated for the new bundled reality.
Dependencies: acrossai-co/main-menu bumped from 0.0.11 to 0.0.14. Adopts the Tabs base class extraction (0.0.14) and tab-scoped option_group (0.0.13) — the latter fixes the cross-tab option-clobber bug where saving one Settings tab silently wiped other tabs’ options. See PR #66.
Freemius product identifiers rotated — fs_product_id changed from 31230 to 34418, fs_public_key rotated to pk_d61a7ddb1a619f7697fbb4fc397b6. If you have a Freemius account tied to the previous product ID, reconnect on the Account submenu after upgrade.
0.0.5
Dependencies: acrossai-co/main-menu bumped to 0.0.11. Picks up the latest AcrossAI shared parent menu / dashboard / settings / add-ons page code from that package. No plugin-owned code changes in this release — the bump is the only functional delta vs 0.0.4.
0.0.4
BREAKING (add-on developers) — Library display fields moved from top-level $args into $args[‘meta’][‘acrossai’]. The three Library-only fields introduced by Features 033 and 037 — sub_group, sub_group_label, and tab_group — are no longer read from the top level of the $args array passed to wp_register_ability(). They must now be nested under $args[‘meta’][‘acrossai’], matching the existing meta.mcp (MCP integration) and meta.annotations (WP-core annotations) convention. This is a hard cut with no back-compat shim: any add-on that still passes the fields at the top level will silently render its Library card without a sub-group heading or custom tab placement. Migration: change ‘sub_group’ => ‘x’ to ‘meta’ => [ ‘acrossai’ => [ ‘sub_group’ => ‘x’ ] ] (same for sub_group_label and tab_group). Only affects add-ons that extend Ability_Definition and use these Library display fields; abilities without them are unaffected. No end-user data migration, no DB schema change, no REST API change.
Plugin icon replaced with a vector (SVG) asset. The WordPress.org plugin directory now serves .wordpress-org/icon.svg in place of the previous 128×128 / 256×256 JPG icons, so the icon renders sharp at any display density. Also removes the 772×250 and 1544×500 header banners from the directory listing — the plugin page will show the WordPress.org default header until banners are re-added. wp.org-assets-only change.
0.0.3
Fix: plugin now activates on installs from WordPress.org. The 0.0.2 release ZIP shipped without the Composer autoloader (vendor/autoload_packages.php) because the WordPress.org deploy workflow did not run composer install before uploading. Users installing 0.0.2 from the WordPress.org plugin directory saw the plugin activation guard trigger: “AcrossAI Abilities Manager cannot activate: the Composer autoloader is missing…”. The 0.0.3 release ZIP includes the full production autoloader; no other code changes. If you already installed 0.0.2 and hit the activation error, delete the plugin folder and reinstall 0.0.3.
0.0.2
Composer dependency refresh — wpb-access-control bumped to v2.0.0 (per-consumer database tables); acrossai-co/main-menu bumped to v0.0.10 (now bundles the Add-ons page and includes the JS-side rebrand-sync fix that restores Install / Activate / Deactivate button behavior). The standalone acrossai-co/addons-page package has been removed from direct dependencies; the same AcrossAI_AddonAddonsPage class now ships from the main-menu package.
Per-consumer access-control storage — this plugin now owns its own {prefix}abilities_access_control database table, keeping its rules fully isolated from any other plugin embedding the same access-control library. The dedicated table is created automatically on plugin activation.
Add-ons submenu URL changed — the Add-ons page slug is now acrossai-addons (was wpb-addons). Any bookmarks or external links pointing at wp-admin/admin.php?page=wpb-addons should be updated to wp-admin/admin.php?page=acrossai-addons. The submenu location and behavior are otherwise unchanged.
BREAKING — Access Control rules from earlier releases are NOT migrated. If you previously configured Access Control rules on any ability, those rules were stored in the shared {prefix}wpb_access_control table and are no longer read by this release. After upgrading, please audit every ability’s Access Control panel and reconfigure any rules that were previously in place. The legacy table is left on disk (in case you need to reference the prior configuration) and can be dropped manually by a database administrator if desired: DROP TABLE {prefix}wpb_access_control; and DELETE FROM {prefix}options WHERE option_name = ‘wpb_access_control_db_version’;.
BREAKING — Ability execution logging removed. The dedicated Logs admin page, the log-retention Settings field, the {prefix}acrossai_ability_logs database table, and the /wp-json/acrossai-abilities-log/v1/logger/logs REST endpoint are all removed. If you rely on ability-execution logging for security monitoring or auditing, install a compatible logging plugin or hook wp_after_execute_ability directly in your own consumer code — the upstream ability-execution events remain available. Bookmarks to wp-admin/admin.php?page=acrossai-abilities-logs receive the standard “page does not exist” response. External integrations polling the removed REST endpoint receive 404. On existing installs, the legacy logs table and its schema-version option are orphaned; opt into the “delete all data on uninstall” setting to drop them cleanly, or run manually: DROP TABLE {prefix}acrossai_ability_logs; and DELETE FROM {prefix}options WHERE option_name IN (‘acrossai_abilities_log_retention_days’, ‘acrossai_ability_logs_db_version’);.
