feat: point agents to pollora/debugbar for debugging

CHANGELOG.md

@@ -7,6 +7,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Added
+
+- **Core guidelines**: debugging with `pollora/debugbar` — what its tabs show, preferred over Query Monitor, and how plugins (`pollora/debugbar/register`) and packages (`Pollora\Debugbar\Collector`) add their own data
+
 ### Changed
 - `pollora-modules` skill rewritten for the modules work of the next framework release: `pollora:make:module` and its opt-in layers, `--module` generators, `@pollora/vite-config` and the `module.<name>` asset container, `pollora:module:frontend`, Plugins › Modules, activation connectors and `config/modules.php`, locked modules, Composer modules and `pollora:module:outdated`. Its post type example used `Pollora\Attributes\PostType\PostType`, which does not exist: it is `Pollora\Attributes\PostType`
 - Core guidelines list `pollora:make:module`, `pollora:module:connector|frontend|outdated` and `--module` on `pollora:make:block`

resources/boost/guidelines/core.blade.php

@@ -132,6 +132,7 @@ class InternalHelper {}
 - **Translations**: `__('Text', 'my-domain')` goes to WordPress's catalogues; `__('key', ['name' => $x])` goes to Laravel; `__('Text')` tries Laravel, then WordPress's `default` domain
 - **Blocks**: live in `resources/views/blocks/{slug}`, render with `render.blade.php` by default, and are registered by Pollora — never write a `BlocksServiceProvider`; `<InnerBlocks />` in `render.blade.php` marks where inner blocks go, edited in place in the editor (see the `pollora-blocks` skill)
 - **Which template answered?** With `WP_DEBUG` on, every page carries `<!-- pollora:template="single" path="themes/x/resources/views/single.blade.php" -->` (hierarchy responses only, not `Route::wp()` or Laravel routes)
+- **Debugging**: `composer require --dev pollora/debugbar` adds Pollora's and WordPress's tabs to Laravel Debugbar — what answered the request (route, or hierarchy view and condition), `$wpdb` queries, hooks, WordPress phases, and REST/admin-ajax calls in the bar's request list. Prefer it to Query Monitor. Plugins add data with the `pollora/debugbar/register` action (no dependency), packages by extending `Pollora\Debugbar\Collector`; `wp_*` and `pollora*` tab names are reserved
 - **Meta, roles, bindings**: declare a meta with `#[Meta]` on a typed property rather than calling `register_meta()` and casting `get_post_meta()` by hand (`pollora-typed-meta` skill); declare roles with `#[Role]` / `#[ModifyRole]` rather than `add_role()`, and check a capability (`can:`, `@can`) rather than a role (`pollora-roles` skill); bind core blocks to a `#[BlockBinding]` source or `pollora/post-meta` before writing a custom block (`pollora-block-bindings` skill)
 - **CSRF**: WordPress endpoints are excluded from Laravel CSRF — WordPress uses its own nonce system
 - **Modules**: Use `nwidart/laravel-modules` for large projects — `pollora:make:module` creates a lean module (no provider: discovery works inside modules), built with `@pollora/vite-config`; switch modules with `module:enable|disable` or Plugins › Modules (see the `pollora-modules` skill)