wp-graphql/wp-graphql

The WPGraphQL schema should be self-describing and backend-agnostic: a developer introspecting it should be able to understand it with no prior WordPress knowledge. The backend could be WordPress, Supabase, or a spreadsheet, and the schema shouldn't assume the reader knows which. This is the same instinct behind naming a ContentNode rather than a "post" and a ContentType rather than a "post type." Several field, argument, and type description strings currently fall short, either leaking backend plumbing or leaning on WordPress-specific vocabulary that assumes prior knowledge. Two levels to audit 1. Implementation plumbing (hard rule, never in descriptions). Reword any description that leaks: WordPress class properties (WP_Post->guid, WP_Term->…) database table / column names (the "post_objects" table, the post_mime_type column) post meta keys (_wp_page_template, _thumbnail_id) WP function names (wp_*, get_post_meta, WP_Query) and query-var names A recurring templated phrasing names

Context WPGraphQL core defines roughly 219 public hooks (apply_filters / do_action). These are public API, extensions and sites build on them, but most have no test coverage at all. A scan of the codebase (method below) found: Bucket Count Hooks defined in core 219 Hook name referenced somewhere in tests/ 59 No test references at all 154 Dynamic hook names (need manual verification) 6 The caveat on the 59: "referenced in tests" only means the hook name appears somewhere in the suite, sometimes that is a real contract test, sometimes it is incidental usage in another test. The 154 are definitive, nothing in the suite touches them. This matters more with a 3.0 on the horizon. Hooks are where breaking changes hide. A contract test per hook means CI tells us when a filter or action changes behavior, signature, or timing, so we can document it properly instead of finding out from extension authors after release. This consolidates #330 and #331 (both from 2017). Since those w