Activity log tracking for AI-initiated changes

[claytoncollie]

Problem

When AI assistants modify settings via abilities, those changes are indistinguishable from manual admin changes in the activity log. There is no way to audit which changes were made by AI vs. a human.

Dependencies

• Add WordPress MCP Adapter package #213 (Add WordPress MCP Adapter package) must be completed first
• Register Abilities API for plugin settings management #214 (Settings abilities) should be completed first so there are write abilities to track

Proposal

Extend the existing activity log to capture AI-initiated changes with source metadata.

Implementation

• Hook into wp_after_execute_ability to log all ability executions
• Record: ability name, input values, output values, timestamp, authenticated user
• Add source field to activity log entries: "manual" (default) vs "abilities-api"
• New ability: tenup/get-ai-activity — readonly, returns only AI-initiated log entries

Leverages existing code

• SupportMonitor/ActivityLog.php already handles option change logging via updated_option hook
• Existing get_logs() method at line 277 already supports filtering
• Activity log cap of 500 entries already in place

Files

• Modified: includes/classes/SupportMonitor/ActivityLog.php (add source tracking)
• New: includes/classes/Abilities/ActivityTracking.php (ability execution listener)
• Modified: 10up-experience.php (instantiate new class)

Verification

1. Make a setting change via an AI assistant (e.g., "Enable strong passwords")
2. Confirm the activity log entry includes source: abilities-api
3. Make the same change manually in wp-admin
4. Confirm that entry has source: manual
5. Test tenup/get-ai-activity ability returns only AI-initiated entries
6. Confirm existing activity log functionality is unaffected

[claytoncollie]

This gets more important once action / remediation abilities (#223) exist, not just settings writes. When an agent self-heals — flushes a cache, deactivates a fataling plugin, runs a scheduled event — the audit trail should capture:

• the action taken and its parameters,
• before/after state where meaningful (e.g. plugin was active → now inactive), and
• source: abilities-api plus the authenticated user.

That makes "what did the agent change, and can I undo it?" answerable from the activity log alone — which is the safety net that makes auto-remediation acceptable on higher environments.

Suggest scoping this issue to explicitly include action abilities, not only settings writes. See #225 for the broader self-healing context.