fix(admin): make governance capabilities readable on the user profile

[dknauss]

Summary

• What changed? WP Sudo grants its four governance capabilities (manage_wp_sudo, view_wp_sudo_activity, export_wp_sudo_activity, revoke_wp_sudo_sessions) directly to users via WP_User::add_cap(). WordPress core's profile screen (wp-admin/user-edit.php) rendered those per-user caps as a run-on list of raw slugs under the generic "Additional Capabilities" heading. This adds two profile-screen callbacks in Admin::register():
  • suppress_governance_capabilities_display() on the core additional_capabilities_display filter — hides the raw section only when every non-role capability the profile user holds is a truthy governance cap. Any foreign additional cap → returns the incoming value unchanged (never hides other plugins' caps, never overrides an already-hidden section); a denied governance cap stays visible as core's "Denied: …". Non-role classification uses wp_roles()->is_role() to mirror core, so additional custom roles aren't mistaken for stray caps.
  • render_governance_capabilities_profile_note() on show_user_profile + edit_user_profile — renders a readable "Sudo capabilities" block listing each directly granted capability by its get_cap_label() label, reading raw stored grants (not effective checks) so a multisite super admin isn't misreported. The Access-tab link is shown only to a viewer who can reach it (wp_sudo_can('manage_wp_sudo')); others see plain text.
• Why was this change needed? The raw slug list was unattractive and not self-explanatory to site admins — the sibling to the 4.5.0 Access-tab readability fix (fix(admin): make Access-tab capability table readable and slug-free #144), now applied to the profile page. Display-only: capability enforcement is untouched.

Validation

• composer test — 1,040 unit tests / 3,129 assertions pass (12 new tests covering the hide / pass-through / denied / custom-role / no-cap suppression branches and the render branches with/without the manager link and partial grants)
• composer lint (PHPCS) clean on production; composer analyse (PHPStan + Psalm) clean
• Manual checks described: a live profile.php render was not exercised — an integration/browser stack (MySQL) isn't provisioned in this environment, and the change is display-only with full unit coverage of both callbacks. The WordPress core filter and its count(caps) > count(roles) && true === $display render condition were verified against wp-admin/user-edit.php on WordPress trunk.

Checklist

• Linked issue or explained why none was needed — no tracked issue; surfaced from maintainer feedback that the profile "Additional Capabilities" section is unattractive/hard to understand
• Updated docs, tests, or manual testing guidance if behavior changed — added a 4.8.0 CHANGELOG entry and refreshed unit-test/size counts in docs/current-metrics.md
• No sensitive details disclosed publicly

---

Generated by Claude Code

[github-actions]

🎮 Try in WordPress Playground

Open this PR in Playground →

Preview is pinned to WordPress 7.0.

Uses the checked-in blueprint.json from this PR, with the plugin install pinned to commit 4dce3046f78b2f5e555fb8ca34a6cd624056a927 via a GitHub archive .zip (resource: url, fetched through the WordPress Playground CORS proxy).

Logs in as admin / password; use password again for the WP Sudo reauthentication challenge.

✅ What you can test

Feature	Notes
Plugin activation & settings page	✅
Gate fires on dangerous actions (plugin activate/delete, user delete, etc.)	✅
Challenge / reauthentication page	✅
Password verification & session cookie	✅
Admin bar countdown timer	✅
Request stash & replay after auth	✅
Rate limiting / 5-attempt lockout	✅ within session
Session expiry by time	✅ wait out the configured duration (1–15 min)
Two Factor plugin (TOTP)	✅ installed automatically via blueprint
unfiltered_html removed from Editor role	✅

❌ What won't work

Feature	Why
WP-CLI / Cron entry point policies	No CLI in browser
REST / XML-RPC entry point policies	Network disabled in Playground
Two Factor email / magic-link providers	PHP outbound network is off
Multisite behaviour	Single-site only
State after refreshing Playground	Full reset on page reload

Transients and user meta persist across normal WP navigation within
a session, but are wiped if you reload the Playground page itself.
Use the integration test suite to verify
transient TTL, real bcrypt, and multisite isolation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (389d899) to head (4dce304).

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #205      +/-   ##
============================================
+ Coverage     90.07%   90.14%   +0.07%     
- Complexity     1540     1554      +14     
============================================
  Files            20       20              
  Lines          5856     5898      +42     
============================================
+ Hits           5275     5317      +42     
  Misses          581      581              

Flag	Coverage Δ
unit	90.14% <100.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
includes/class-admin.php	88.82% <100.00%> (+0.34%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c22acb33aa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".