@goldencomm/create-baseline 0.0.1 → 0.1.0

package/templates/wordpress/.claude/skills/wp-rest-api/SKILL.md

@@ -1,114 +0,0 @@
----
-name: wp-rest-api
-description: "Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest."
-compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node. Some workflows require WP-CLI."
----
-
-# WP REST API
-
-## When to use
-
-Use this skill when you need to:
-
-- create or update REST routes/endpoints
-- debug 401/403/404 errors or permission/nonce issues
-- add custom fields/meta to REST responses
-- expose custom post types or taxonomies via REST
-- implement schema + argument validation
-- adjust response links/embedding/pagination
-
-## Inputs required
-
-- Repo root + target plugin/theme/mu-plugin (path to entrypoint).
-- Desired namespace + version (e.g. `my-plugin/v1`) and routes.
-- Authentication mode (cookie + nonce vs application passwords vs auth plugin).
-- Target WordPress version constraints (if below 6.9, call out).
-
-## Procedure
-
-### 0) Triage and locate REST usage
-
-1. Run triage:
-   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
-2. Search for existing REST usage:
-   - `register_rest_route`
-   - `WP_REST_Controller`
-   - `rest_api_init`
-   - `show_in_rest`, `rest_base`, `rest_controller_class`
-
-If this is a full site repo, pick the specific plugin/theme before changing code.
-
-### 1) Choose the right approach
-
-- **Expose CPT/taxonomy in `wp/v2`:**
-  - Use `show_in_rest => true` + `rest_base` if needed.
-  - Optionally provide `rest_controller_class`.
-  - Read `references/custom-content-types.md`.
-- **Custom endpoints:**
-  - Use `register_rest_route()` on `rest_api_init`.
-  - Prefer a controller class (`WP_REST_Controller` subclass) for anything non-trivial.
-  - Read `references/routes-and-endpoints.md` and `references/schema.md`.
-
-### 2) Register routes safely (namespaces, methods, permissions)
-
-- Use a unique namespace `vendor/v1`; avoid `wp/*` unless core.
-- Always provide `permission_callback` (use `__return_true` for public endpoints).
-- Use `WP_REST_Server::READABLE/CREATABLE/EDITABLE/DELETABLE` constants.
-- Return data via `rest_ensure_response()` or `WP_REST_Response`.
-- Return errors via `WP_Error` with an explicit `status`.
-
-Read `references/routes-and-endpoints.md`.
-
-### 3) Validate/sanitize request args
-
-- Define `args` with `type`, `default`, `required`, `validate_callback`, `sanitize_callback`.
-- Prefer JSON Schema validation with `rest_validate_value_from_schema` then `rest_sanitize_value_from_schema`.
-- Never read `$_GET`/`$_POST` directly inside endpoints; use `WP_REST_Request`.
-
-Read `references/schema.md`.
-
-### 4) Responses, fields, and links
-
-- Do **not** remove core fields from default endpoints; add fields instead.
-- Use `register_rest_field` for computed fields; `register_meta` with `show_in_rest` for meta.
-- For `object`/`array` meta, define schema in `show_in_rest.schema`.
-- If you need unfiltered post content (e.g., ToC plugins injecting HTML), request `?context=edit` to access `content.raw` (auth required). Pair with `_fields=content.raw` to keep responses small.
-- Add related resource links via `WP_REST_Response::add_link()`.
-
-Read `references/responses-and-fields.md`.
-
-### 5) Authentication and authorization
-
-- For wp-admin/JS: cookie auth + `X-WP-Nonce` (action `wp_rest`).
-- For external clients: application passwords (basic auth) or an auth plugin.
-- Use capability checks in `permission_callback` (authorization), not just “logged in”.
-
-Read `references/authentication.md`.
-
-### 6) Client-facing behavior (discovery, pagination, embeds)
-
-- Ensure discovery works (`Link` header or `<link rel="https://api.w.org/">`).
-- Support `_fields`, `_embed`, `_method`, `_envelope`, pagination headers.
-- Remember `per_page` is capped at 100.
-
-Read `references/discovery-and-params.md`.
-
-## Verification
-
-- `/wp-json/` index includes your namespace.
-- `OPTIONS` on your route returns schema (when provided).
-- Endpoint returns expected data; permission failures return 401/403 as appropriate.
-- CPT/taxonomy routes appear under `wp/v2` when `show_in_rest` is true.
-- Run repo lint/tests and any PHP/JS build steps.
-
-## Failure modes / debugging
-
-- 404: `rest_api_init` not firing, route typo, or permalinks off (use `?rest_route=`).
-- 401/403: missing nonce/auth, or `permission_callback` too strict.
-- `_doing_it_wrong` for missing `permission_callback`: add it (use `__return_true` if public).
-- Invalid params: missing/incorrect `args` schema or validation callbacks.
-- Fields missing: `show_in_rest` false, meta not registered, or CPT lacks `custom-fields` support.
-
-## Escalation
-
-If version support or behavior is unclear, consult the REST API Handbook and core docs before inventing patterns.

package/templates/wordpress/.claude/skills/wp-rest-api/references/authentication.md

@@ -1,18 +0,0 @@
-# Authentication (summary)
-
-## Cookie authentication (in-dashboard / same-site)
-
-- Standard for wp-admin and theme/plugin JS.
-- Requires a REST nonce (`wp_rest`) sent as `X-WP-Nonce` header or `_wpnonce` param.
-- If the nonce is missing, the request is treated as unauthenticated even if cookies exist.
-
-## Application Passwords (external clients)
-
-- Available in WordPress 5.6+.
-- Use HTTPS + Basic Auth with the application password.
-- Recommended over the legacy Basic Auth plugin.
-
-## Auth plugins
-
-- OAuth 1.0a or JWT plugins are common for external apps.
-- Use only if required; follow plugin docs and security guidance.

package/templates/wordpress/.claude/skills/wp-rest-api/references/custom-content-types.md

@@ -1,20 +0,0 @@
-# Custom Content Types (summary)
-
-## Custom post types
-
-- Set `show_in_rest => true` in `register_post_type()` to expose in `wp/v2`.
-- Use `rest_base` to change the route slug.
-- Optionally set `rest_controller_class` (must extend `WP_REST_Controller`).
-
-## Custom taxonomies
-
-- Set `show_in_rest => true` in `register_taxonomy()`.
-- Use `rest_base` and optional `rest_controller_class` (default `WP_REST_Terms_Controller`).
-
-## Adding REST support to existing types
-
-- Use `register_post_type_args` or `register_taxonomy_args` filters to enable `show_in_rest` for types you do not control.
-
-## Discovery links for custom controllers
-
-- If you use a custom controller class, use `rest_route_for_post` or `rest_route_for_term` filters to map objects to routes.

package/templates/wordpress/.claude/skills/wp-rest-api/references/discovery-and-params.md

@@ -1,20 +0,0 @@
-# Discovery and Global Parameters (summary)
-
-## API discovery
-
-- REST API root is discovered via the `Link` header: `rel="https://api.w.org/"`.
-- HTML pages also include a `<link rel="https://api.w.org/" href="...">` element.
-- For non-pretty permalinks, use `?rest_route=/`.
-
-## Global parameters
-
-- `_fields` limits response fields (supports nested meta keys).
-- `_embed` includes linked resources in `_embedded`.
-- `_method` or `X-HTTP-Method-Override` allows POST to simulate PUT/DELETE.
-- `_envelope` puts headers/status in the response body.
-- `_jsonp` enables JSONP for legacy clients.
-
-## Pagination
-
-- Collections accept `page`, `per_page` (1-100), and `offset`.
-- Pagination headers: `X-WP-Total` and `X-WP-TotalPages`.

package/templates/wordpress/.claude/skills/wp-rest-api/references/responses-and-fields.md

@@ -1,30 +0,0 @@
-# Responses and Fields (summary)
-
-## Do not remove core fields
-
-- Removing or changing core fields breaks clients (including wp-admin).
-- Prefer adding new fields or using `_fields` to limit response size.
-
-## register_rest_field
-
-- Use for computed or custom fields.
-- Provide `get_callback`, optional `update_callback`, and `schema`.
-- Register on `rest_api_init`.
-
-## Raw vs rendered content
-
-- For posts, `content.rendered` reflects filters (plugins like ToC inject HTML).
-- Use `?context=edit` (authenticated) to access `content.raw`.
-- Combine with `_fields=content.raw` when you only need the editable body.
-
-## register_meta / register_post_meta / register_term_meta
-
-- Use when the data is stored as meta.
-- Set `show_in_rest => true` to expose under `.meta`.
-- For `object` or `array` types, provide a JSON schema in `show_in_rest.schema`.
-
-## Links and embedding
-
-- Add links with `WP_REST_Response::add_link( $rel, $href, $attrs )`.
-- Use `embeddable => true` to allow `_embed`.
-- Use IANA rels or a custom URI relation; CURIEs can be registered via `rest_response_link_curies`.

package/templates/wordpress/.claude/skills/wp-rest-api/references/routes-and-endpoints.md

@@ -1,36 +0,0 @@
-# Routes and Endpoints (summary)
-
-## Registering routes
-
-- Register routes on the `rest_api_init` hook with `register_rest_route( $namespace, $route, $args )`.
-- A **route** is the URL pattern; an **endpoint** is the method + callback bound to that route.
-- For non-pretty permalinks, the route is accessed via `?rest_route=/namespace/route`.
-
-## Namespacing
-
-- Always namespace routes (`vendor/v1`).
-- **Do not** use the `wp/*` namespace unless you are targeting core.
-
-## Methods
-
-- Use `WP_REST_Server::READABLE` (GET), `CREATABLE` (POST), `EDITABLE` (PUT/PATCH), `DELETABLE` (DELETE).
-- Multiple endpoints can share a route, one per method.
-
-## permission_callback (required)
-
-- Always provide `permission_callback`.
-- Public endpoints should use `__return_true`.
-- For restricted endpoints, use capability checks (`current_user_can`) or object-level authorization.
-- Missing `permission_callback` emits a `_doing_it_wrong` notice in modern WP.
-
-## Arguments
-
-- Register `args` to validate and sanitize inputs.
-- Use `type`, `required`, `default`, `validate_callback`, `sanitize_callback`.
-- Access params via the `WP_REST_Request` object, not `$_GET`/`$_POST`.
-
-## Return values
-
-- Return data via `rest_ensure_response()` or a `WP_REST_Response`.
-- Return `WP_Error` with a `status` in `data` for error responses.
-- Do not call `wp_send_json()` in REST callbacks.

package/templates/wordpress/.claude/skills/wp-rest-api/references/schema.md

@@ -1,22 +0,0 @@
-# Schema and Argument Validation (summary)
-
-## JSON Schema in WordPress
-
-- REST API uses JSON Schema (draft 4 subset) for resource and argument definitions.
-- Provide schema via `get_item_schema()` on controllers or `schema` callbacks on routes.
-- Schema enables discovery (`OPTIONS`) and validation.
-
-## Validation + sanitization
-
-- Use `rest_validate_value_from_schema( $value, $schema )` then `rest_sanitize_value_from_schema( $value, $schema )`.
-- If you override `sanitize_callback`, built-in schema validation will not run; use `rest_validate_request_arg` to keep it.
-- `WP_REST_Controller::get_endpoint_args_for_item_schema()` wires validation automatically.
-
-## Schema caching
-
-- Cache the generated schema on the controller instance (`$this->schema`) to avoid recomputation.
-
-## Formats and types
-
-- Common formats: `date-time`, `uri`, `email`, `ip`, `uuid`, `hex-color`.
-- For `array` and `object` types, you must define `items` or `properties` schemas.

package/templates/wordpress/.ddev/docker-compose.packages.yaml

@@ -1,14 +0,0 @@
-# Monorepo-only: bind-mount the Baseline theme + blocks plugin from packages/
-# straight into wp-content (live — edit in packages/, refresh the site).
-#
-# DDEV only mounts this project dir, so the sibling packages/ aren't reachable by
-# Composer in-container. This mounts them directly instead. ${DDEV_APPROOT} is the
-# absolute host path to baselines/wordpress; ../../packages → repo/packages.
-#
-# In a standalone CLIENT repo (no monorepo), delete this file and instead
-# `composer require goldencomm/wp-theme goldencomm/wp-blocks-plugin` from Bitbucket VCS.
-services:
-  web:
-    volumes:
-      - "${DDEV_APPROOT}/../../packages/wp-theme:/var/www/html/wp-content/themes/baseline"
-      - "${DDEV_APPROOT}/../../packages/wp-blocks-plugin:/var/www/html/wp-content/plugins/baseline-blocks"

package/templates/wordpress/.ddev/docker-compose.redis.yaml

@@ -1,11 +0,0 @@
-# Redis service for the redis-cache plugin (WP_REDIS_HOST=redis).
-services:
-  redis:
-    container_name: ddev-${DDEV_SITENAME}-redis
-    image: redis:7-alpine
-    restart: "no"
-    labels:
-      com.ddev.site-name: ${DDEV_SITENAME}
-      com.ddev.approot: $DDEV_APPROOT
-    expose:
-      - "6379"

package/templates/wordpress/.env.example

@@ -1,33 +0,0 @@
-# Copy to .env and fill in. Locally, DDEV injects DB_* and IS_DDEV_PROJECT;
-# other environments set these explicitly (AWS task env, WP Engine, etc.).
-
-WP_ENV=development
-WP_HOME=https://baseline-wordpress.ddev.site
-WP_SITEURL="${WP_HOME}"
-
-# Database (DDEV provides db/db/db/db locally)
-DB_NAME=db
-DB_USER=db
-DB_PASSWORD=db
-DB_HOST=db
-DB_PREFIX=wp_
-
-# Salts — generate with `wp config shuffle-salts` or https://roots.io/salts.html
-AUTH_KEY=
-SECURE_AUTH_KEY=
-LOGGED_IN_KEY=
-NONCE_KEY=
-AUTH_SALT=
-SECURE_AUTH_SALT=
-LOGGED_IN_SALT=
-NONCE_SALT=
-
-# Redis object cache (DDEV provides a redis service)
-WP_REDIS_HOST=redis
-WP_REDIS_PORT=6379
-
-# S3 media offload (production) — humanmade/s3-uploads
-S3_UPLOADS_BUCKET=
-S3_UPLOADS_REGION=
-S3_UPLOADS_KEY=
-S3_UPLOADS_SECRET=

package/templates/wordpress/CLAUDE.md

@@ -1,34 +0,0 @@
-# CLAUDE.md — Baseline WordPress site
-
-The DDEV WordPress baseline for the Baseline design system (theme in
-`packages/wp-theme`, custom blocks in `packages/wp-blocks-plugin`). See the repo-root
-`CLAUDE.md` for design-system non-negotiables; component work follows the
-`gc-wp-block` skill (core-blocks-first decision tree, gcds namespace rules).
-
-## Conventions
-- Local dev: `pnpm dev:wp` / `pnpm dev:wp:down` (DDEV; ports may conflict with
-  other local sites).
-  - **On Windows, run these from inside a WSL2 shell — not from PowerShell.** DDEV
-    is a WSL2-native tool and this project lives on the Windows drive (`/mnt/c/…`).
-    Driving it from a Windows-spawned `wsl.exe` fails three ways: `ddev` isn't on
-    the Windows PATH; a name-based `ddev start <project>` computes an empty TLD
-    (invalid hostname `<project>.`); and `cd /mnt/c/… && ddev …` (even with
-    `wsl.exe --cd`) hits `stat .: input/output error` on the DrvFs mount. Inside an
-    interactive WSL2 shell the `cd baselines/wordpress && ddev start` script works
-    cleanly. So keep the scripts `cd`-based (no `wsl.exe` wrapper — it breaks both
-    sides). Contrast `dev:shopify`/`dev:next`/`dev:docs`, which run from Windows.
-- Keep WP auto-updates ON — never disable the self-updater.
-- No WP validator in the agent environment (no wp-cli) — changes are verified
-  visually by the developer via `pnpm dev:wp`; flag unverified work.
-
-## Skills upkeep
-`.claude/skills/` vendors the official WordPress skills (`wp-block-development`,
-`wp-block-themes`, `wp-plugin-development`, `wp-rest-api`, `wp-performance`),
-tracked by this directory's `skills-lock.json`. Refresh from upstream with:
-
-```
-npx skills update -p -y
-```
-
-(Inside the design-system monorepo, run `pnpm skills:update` at the repo root
-instead.) Review the diff before committing.

package/templates/wordpress/_gitignore

@@ -1,33 +0,0 @@
-# WordPress core — pinned + downloaded via wp-cli, not committed
-/wp-admin/
-/wp-includes/
-/wp-*.php
-!/wp-config.php
-/index.php
-/xmlrpc.php
-/license.txt
-/readme.html
-
-# Composer
-/vendor/
-
-# Composer-managed themes & plugins
-/wp-content/themes/
-/wp-content/plugins/
-
-# mu-plugins: keep the ones we author, ignore composer-installed
-/wp-content/mu-plugins/*
-!/wp-content/mu-plugins/baseline-bootstrap.php
-
-# Generated / runtime
-/.maintenance
-/wp-content/uploads/
-/wp-content/cache/
-/wp-content/upgrade/
-/wp-content/object-cache.php
-/wp-content/advanced-cache.php
-
-# Secrets & local
-/.env
-/auth.json
-/wp-config-ddev.php