# PHASE 00: PROJECT BOOTSTRAP AND LOCAL ENVIRONMENT

Read `CLAUDE.md` first, then `docs/05-TECHNICAL-ARCHITECTURE.md` sections 1 and 2.

## Scope

Get a working local WordPress with WooCommerce, the empty theme and plugin skeletons in place, the build pipeline running, and linting passing. No features yet.

## Build

1. A local WordPress environment. Use `wp-env` (Docker) if Docker is available, otherwise document the LocalWP steps in `deploy/deploy-notes.md`. PHP 8.2, MySQL 8, WordPress latest, WooCommerce latest.
2. `git init`, first commit with the docs, `CLAUDE.md`, `.gitignore`, `.editorconfig`, `phpcs.xml`, `package.json`.
3. `composer.json` with `dealerdirect/phpcodesniffer-composer-installer`, `wp-coding-standards/wpcs` and `woocommerce/woocommerce-sniffs` as dev dependencies, plus a `lint` and `lint:fix` script.
4. The theme skeleton exactly as the file tree in the technical architecture: `style.css` header only, `functions.php` that loads `inc/*` and nothing else, empty `inc/` files, empty `template-parts/` directories, `assets/src/` structure. It must activate without a fatal and render a bare page.
5. The plugin skeleton: main file with the header docblock, guards (bail if WooCommerce is not active, with an admin notice), a simple autoloader that maps `BC_Class_Name` to `includes/**/class-class-name.php`, and `class-plugin.php` as the container. It must activate without a fatal.
6. The HPOS and blocks-incompatibility declaration on `before_woocommerce_init`, exactly as written in `docs/05-TECHNICAL-ARCHITECTURE.md` section 3.
7. `tools/hash-assets.js` that content-hashes the built CSS and JS and writes `assets/dist/asset-manifest.json`.
8. `tools/check-budget.js` that reads the dist files and fails with a non-zero exit if CSS is over 45 KB or JS over 25 KB minified.
9. `bc_asset()` in `inc/enqueue.php`: reads the manifest once into a static, returns the hashed URL, falls back to `filemtime()` if the manifest is absent, and passes `null` as the enqueue version.
10. `deploy/.cpanel.yml` that copies only the theme and plugin directories into `wp-content`.
11. **Set the database table prefix now, at install, to a random four-character string, not `wp_`.** Changing it later means renaming `wc_orders`, `wc_orders_meta`, `wc_order_addresses`, Action Scheduler's tables, and rewriting the `{prefix}capabilities`, `{prefix}user_level` user meta and the `{prefix}user_roles` option, or every admin silently loses their role. Do it here or never.
12. **Provision the staging subdomain on the Namecheap account now** (decision D-24). Own database, `WP_ENVIRONMENT_TYPE = 'staging'`, forced `noindex`, cPanel password protection, gateways in test mode. Phases 12, 13 and 14 need a real LiteSpeed host and cannot be verified against a Docker container. Local stays for fast iteration; anything touching caching, URLs, email or backups is verified on staging.
13. `docs/PROGRESS.md` from the template, with the phase 00 entry filled in.

## Acceptance criteria

- [ ] `wp-env start` (or the documented equivalent) brings up a site with WooCommerce active
- [ ] The theme activates and the homepage renders without a PHP notice
- [ ] The plugin activates without a fatal, and shows a clear admin notice when WooCommerce is deactivated
- [ ] WooCommerce Settings, Advanced, Features shows HPOS as available and enabled, with no incompatibility warning from our plugin
- [ ] `npm run build` produces hashed files and a valid `asset-manifest.json`
- [ ] `npm run size` passes
- [ ] `composer run lint` passes on both directories with zero errors
- [ ] The table prefix is random, not `wp_`, verified in the database
- [ ] The staging subdomain resolves, is password protected, and is `noindex`
- [ ] `docs/PROGRESS.md` exists with a phase 00 entry
- [ ] `git log` shows one clean initial commit

## Stop

Do not write any feature code. Do not create templates beyond what is needed to render a bare page. Do not add a plugin that is not on the approved list. Report what you built and stop.