Extract Ability_Manager as a WP7 ability registration utility

[MathieuLamiot]

Description

Extracts the WordPress 7 Ability API wiring out of class-sybgo.php into a dedicated Ability_Manager class. Ability_Manager is a pure registration utility: callers declare abilities via register(), and init() handles the WP7 API wiring. Wiring declarations (callbacks, labels, permissions) live in a new Sybgo::init_abilities() private sub-method, which acts as the composition root for WP7 abilities.

Closes #88

Type of change

• Enhancement (non-breaking change which improves an existing functionality).
• Sub-task of EPIC: Refactor class-sybgo into focused OOP classes #86
• Chore

Detailed scenario

What was tested

No manual testing required — this is a pure internal refactor with no user-visible behaviour change. The plugin initialises identically on WP < 7 (no abilities registered) and on WP 7+ (both abilities wired on wp_abilities_api_init). Verified by running the unit test suite: all 42 tests pass.

How to test

1. Activate the sybgo plugin on a WordPress install.
2. Confirm the dashboard widget, reports page, and settings page all load normally — no regressions in admin UI.
3. On WP < 7: verify no JS errors or PHP notices related to abilities.
4. On WP 7+ (or with a stub defining wp_register_ability): confirm sybgo/generate-summary and sybgo/track-events are registered on the wp_abilities_api_init action.
5. Run vendor/bin/phpunit --testsuite Unit — all tests pass.

Affected Features & Quality Assurance Scope

• Plugin initialisation flow (class-sybgo.php)
• WordPress 7 Ability API integration (WP 7+ only)
• Public extensibility API initialisation (sybgo_init_api)

Technical description

Documentation

Ability_Manager (wp-plugin root) accumulates ability definitions in a private $abilities array via register(string $name, array $args). When init() is called, it checks for wp_register_ability via function_exists and, if present, hooks a closure on wp_abilities_api_init that loops over $abilities and calls wp_register_ability() for each.

The public extensibility API (sybgo_init_api) and ability registration are both handled by Sybgo::init_abilities(), a new private sub-method of Sybgo::init(). This follows the same pattern as init_event_tracking() — Sybgo::init() remains a thin orchestrator that delegates to private sub-methods.

Architecture notes in lib/docs/ai-transport.md updated to reference Ability_Manager instead of the removed Sybgo::register_abilities(). Project structure in wp-plugin/docs/development.md updated.

Class responsibilities

Class	Responsibility
Ability_Manager	Accumulates ability definitions; wires them into WP7 on init()
Sybgo::init_abilities()	Composition root: calls sybgo_init_api(), declares both abilities with closures, calls Ability_Manager::init()

New dependencies

None.

Risks

None identified. This is a pure internal refactor — no public API, hook names, or user-visible behaviour changes.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionable.

Unticked items justification

N/A — all items applicable and ticked.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

Observability and error handling are not applicable: Ability_Manager is a registration utility with no I/O operations.