LW Site Manager: overview and consumer reference

For developers and AI agents calling the LW Site Manager plugin's abilities — a curated, security-checked exposure of 120+ WordPress operations through the WP 6.9+ Abilities API. The plugin's positioning is "AI-ready alternative to MainWP" — but the surface and the security model differ, and that distinction matters for both consumers and reviewers.

Misconception this skill corrects

"It's just MainWP with a different name — point a token at it and run remote management."

It isn't. MainWP-class tools use a single privileged dashboard token to do almost-anything against the target install; LW Site Manager exposes per-operation abilities, each gated by a specific WP capability check through a centralized PermissionManager. Verified at src/Abilities/PermissionManager.php — can_manage_updates requires both update_plugins AND update_themes; can_install_plugins requires install_plugins; can_view_health requires view_site_health_checks; can_manage_backups / can_manage_database / can_manage_cache / can_manage_options all require manage_options. There is no "admin override" or single-token bypass.

The practical difference for an integrator:

• A user with WP role editor (no install_plugins) can call site-manager/list-plugins (read) but NOT site-manager/install-plugin — gracefully gets 403 from the WP layer, not from a custom ACL.
• A user without view_site_health_checks can't call site-manager/health-check even if their Application Password is valid.
• A compromised Application Password is bounded by THAT user's WP capabilities, not by a global token.

Other AI-prone misconceptions: