Introduce Knowledge custom post type

[gziolo]

Summary

Introduce the Knowledge concept: a wp_knowledge custom post type with a type taxonomy, a capability namespace, and a REST surface, providing a canonical store for author-facing and agent-facing site knowledge. Guidelines is the first feature built on it, giving site owners a place to capture content standards such as voice, tone, image guidance, and per-block rules.

This has been developed as an experiment in the Gutenberg plugin and is about to be proposed for merge in WordPress 7.1. More details coming up soon.

Motivation

Sites accumulate standards and context that today live outside WordPress in documents, wikis, and institutional knowledge. As plugins and integrations need persistent, structured knowledge about a site, each one tends to ship its own storage, permissions model, and REST surface. A shared core primitive prevents that fragmentation, the same way wp_template, wp_block, and nav_menu_item did in their domains.

The feature ships storage and access only. It includes no AI provider, model, retrieval algorithm, or memory architecture.

Scope

Proposed for this ticket:

• wp_knowledge post type, registered as internal (public => false, publicly_queryable => false), with revision support
• wp_knowledge_type taxonomy and a wp_knowledge_types registration filter
• Built-in types:
  • guideline – a standard such as voice, tone, or per-block rules, applied directly or loaded in the matching context
  • memory – durable context a user explicitly saved, such as preferences or stable facts
  • note – private freeform working text such as drafts and synced notes
• *_knowledge capability namespace and access policy (private, author-owned by default; administrators manage site-wide records)
• /wp/v2/knowledge REST routes

Out of scope for this ticket:

• Further built-in types, deferred and registerable by plugins in the meantime:
  • skill – a procedure that can load and apply a guideline, planned for 7.2 pending settled loading and discovery semantics
  • plan – task-scoped working state, pending a side-effect and lifecycle model
  • artifact – a reference to a versioned work product distinct from the freeform text covered by note, explored separately
• The knowledge management ability (Abilities API), proposed for a later release
• Decay, consolidation, retrieval, and encryption at rest

Access model

Records are not exposed as a public index. Collection reads require authentication, per-item reads are capability-checked through read_post, and non-publishers may only create private records.

Role	Site-wide guideline records	Own private records	Others' private records	Manage global records
Subscriber	No	No	No	No
Contributor	Read where caps allow	CRUD	No	No
Author / Editor	Read where caps allow	CRUD	No	No
Administrator	Manage	Yes	Yes	Yes

Type and scope registration are code-level extension points. User roles control access to records, not the registration of types or scopes.

Related

• Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/75171
• Type model discussion: ​https://github.com/WordPress/gutenberg/issues/77230
• Rename PR (Gutenberg): ​https://github.com/WordPress/gutenberg/pull/79149

## Summary

Introduces wp_knowledge, a private-by-default custom post type that acts as a storage primitive for structured site knowledge (guidelines, memories, notes), along with its wp_knowledge_type taxonomy and a dedicated REST controller.

This is the WordPress core counterpart to the Knowledge storage primitive being explored in Gutenberg (WordPress/gutenberg#79149). It deliberately lands the storage primitive only — the Guidelines admin UI and the content-guidelines singleton remain consumer-side concerns and are out of scope here.

## Details

• Post type & taxonomy: wp_knowledge and wp_knowledge_type are registered as built-ins in create_initial_post_types() / create_initial_taxonomies(). Both are non-public and headless (show_ui => false); rows are managed via the REST API rather than a wp-admin screen.
• REST API: WP_REST_Knowledge_Controller serves /wp/v2/knowledge. Reads require an authenticated user with the read capability, collection queries are scoped to rows the current user can read (so totals/pagination respect per-user visibility), callers without the publish capability are limited to the private status, and new rows default to private. Revision history uses the default revisions controller; autosave endpoints are disabled (following the wp_global_styles precedent), since knowledge has no editor session.
• Capabilities: a graded model is synthesized through the user_has_cap filter (wp_maybe_grant_knowledge_caps()), matching the existing wp_maybe_grant_* pattern. Administrators manage all knowledge; contributors and above may create and fully manage their own private rows. Subscribers and anonymous users are blocked at the post-type door.
• Type registry: wp_knowledge_types() exposes a filterable set of types (guideline, memory, note); rows saved without a type fall back to the note term.

## Testing

New unit tests cover registration, the capability matrix across all roles, the REST controller (CRUD, permission gating, private-by-default), and the type registry. The REST route snapshot in tests/phpunit/tests/rest-api/rest-schema-setup.php is updated accordingly.

npm run test:php -- --group knowledge

[!NOTE]
tests/qunit/fixtures/wp-api-generated.js is intentionally not regenerated here. Regenerating it currently also pulls in unrelated route drift already present on trunk, so it should be regenerated in a dedicated step to keep this diff focused on the primitive.

🤖 Generated with ​Claude Code

Knowledge, is something done mostly though for LLMS, similar to abilities, I wonder if for knowledge we avoid a specific REST endpoint and we just use abilities as the interface to manage the knowledge everywhere? Instead of calling REST we would always call the abilities.

Great work here, things look, just left some comments for considering but it seems to be on a good shape.