# Prompt: Update Component Playground

Update the component playground from the supplied source.

## Input

The source will be one of:

- A commit SHA
- A base-to-head branch diff
- A concrete page, HTML fragment, or component example

Use only the supplied source plus the playground references below. Do not analyze unrelated application areas.

## Required References

- `Docs/api/playground.md`
- `Docs/api/template-components.md`
- `Docs/api/form-components.md`
- `src/pages/routes.php`
- `src/pages/public/playground/playground.controller.php`
- `src/pages/public/playground/playground.view.php`
- `src/pages/public/playground/playground.js`
- `src/core/templates/components-base.template.php`
- `src/core/templates/components-form-base.template.php`
- `Docs/knowledge/05-content-management.md`
- `src/core/modules/Content/Content.php`
- `src/core/modules/Content/templates/news-content.php`
- `src/core/modules/Content/templates/news-category-description.php`
- `src/core/modules/Content/templates/news-category-children.php`
- `src/core/modules/Content/templates/news-category-dropdown.php`
- `src/settings/helpers.php`

Use these page examples only when the supplied source requires comparison:

- `src/pages/public/register/register.view.php`
- `src/pages/public/profile/profile.view.php`
- `src/pages/public/ranking/ranking.view.php`
- `src/pages/public/events/events.view.php`
- `src/pages/public/store/store.view.php`
- `src/pages/private/cart/cart.view.php`
- `src/pages/private/cart/cart-items.view.php`
- `Docs/knowledge/20-cart-orders.md`
- `Docs/knowledge/21-payment-discounts.md`
- `src/pages/private/recover-character/recover-character.view.php`
- `src/pages/private/notifications/notifications.view.php`
- `src/pages/admin/manual-sell/manual-sell.view.php`

## Rules

1. Inspect the supplied commit, branch diff, or concrete HTML first.
2. Identify new, changed, or removed visible components and page markup patterns.
3. Update the smallest relevant playground category and component fixture.
4. Preserve the `category` and `component` URL parameters.
5. Preserve `history.replaceState()` and refresh restoration behavior.
6. Keep `All` selected by default unless the URL specifies another valid value.
7. Keep examples static and side-effect free.
8. Do not submit real forms, create orders, query live product data, or duplicate footer-mounted helpers.
9. Keep examples compatible with theme overrides.
10. Update `Docs/api/playground.md` when the inventory or filter contract changes.
11. Do not modify unrelated pages or bundled assets.
12. Do not add a full-page or standalone page-wrapper example; `StartPage` and `EndPage` are implicit in the playground page.
13. Keep paired lifecycle methods in one example; do not add separate `endForm`, `endEmptyRow`, `EndBlock`, or similar end-method cards when the paired start example already renders them.
14. Remove obsolete component-tab metadata when removing an example so no empty filters remain.
15. For content-management changes, add or update complete category/node sections, not independent cards for helpers such as titles, breadcrumbs, images, or descriptions.
16. Copy the classes and div structure from the content templates manually; never include a content template or call the content renderer from the playground.
17. Never load `Content.php`, `ContentModel`, or CMS data for playground examples; use static fixtures only.
18. Add every new content template as a complete `content` subcategory while preserving the existing cases.
19. Keep `ranking/generic-ranking` as one generic ranking example; do not add ranking tabs for individual ranking types.
20. Keep `profiles/user-details`, `profiles/guild-members`, and `profiles/class-icons` as separate cases.
21. Keep `commerce/store-cart` as one combined Store and full-cart case.
22. Until these requested placeholders are explicitly populated, keep their sections empty and define only their category/component button metadata in `playground.view.php`.
23. Do not add custom data-config arrays for placeholders; future content must use plain HTML or existing component methods unless explicitly approved.
24. Do not invent rows, labels, products, profile data, member data, cart items, payment methods, or other placeholder content.
25. Keep `forms/full-form` as the first forms example and update it when a form-rendering method is added or changed.
26. The full form must remain non-submitting and use static values; keep its JavaScript submission guard intact.
27. Keep `forms/plain-form` immediately after `forms/full-form`; use only plain-capable controls, pass `$plain=true` to every control, and separate controls only with individual `<div>` elements.

## Mounting Contract

- Add route entries only in `src/pages/routes.php` when required.
- Enqueue page JavaScript from the controller with `loadPageJS('public', 'playground')`.
- Do not add a manual script tag to the view.
- Keep component filter metadata on `data-playground-category` and `data-playground-component`.

## Source Commands

For a commit, inspect `git show --stat <commit>` and `git show <commit> -- <relevant paths>`.

For a branch diff, inspect `git diff --stat <base>...<head>` and `git diff <base>...<head> -- <relevant paths>`.

For supplied HTML, classify the markup against the documented component categories before editing.

## Verification

- Check the generated PHP syntax.
- Check that `/playground` loads.
- Check category and component filters.
- Refresh filtered URLs and confirm state restoration.
- Check `git diff --check`.