add availability list to CLAUDE.md and implement-plan-00.md

studiou-wc-mail-queue/CLAUDE.md

@@ -176,17 +176,31 @@ Caveat specific to this shop: **studiou.cz strips the `?ver=` query string**, so
 
 ## Translations
 
-Czech (`cs_CZ`) and English. Edit the `.po` files, then compile:
+Czech (`cs_CZ`) and English.
 
-```
-wp i18n make-mo languages/
-```
+### This machine has no PHP toolchain — do not try to compile `.mo`
+
+Verified absent on this dev box: **`php`, `wp` (WP-CLI), `msgfmt`, and a working `python`** (the `python`/`python3` on `PATH` are Windows Store alias stubs that print an install prompt and exit, so they are not interpreters). Only `perl` and `git` are real.
+
+That rules out every compilation route the sibling plugins document:
+
+- `wp i18n make-mo languages/` — no WP-CLI, and it needs PHP anyway
+- `php languages/generate-mo.php` (the fallback in `studiou-wc-free-photo-product`) — no PHP
+- `msgfmt` — not installed
 
-`studiou-wc-free-photo-product/languages/generate-mo.php` is a dependency-free PHP fallback (`php generate-mo.php`) if WP-CLI is unavailable. Poedit or `msgfmt` also work. The `.mo` must be regenerated by hand — nothing does it automatically.
+**So: edit the `.po` files only, and leave `.mo` compilation to the user.** They compile manually (Poedit, or `msgfmt` on the server). When a change touches translatable strings, update the `.po`, say so explicitly, and tell the user the `.mo` still needs regenerating — do not claim the translation is live, and do not hand-craft a `.mo` binary.
+
+Nothing regenerates `.mo` automatically. A stale `.mo` silently serves the old strings, so an un-flagged `.po` edit looks like a translation that simply did not work.
+
+The same constraint applies to **any PHP verification**: this box cannot lint, parse, or run a line of this plugin. `php -l` is unavailable. Syntax errors will surface only in the user's WordPress install.
 
 ## Verification
 
-There are no automated tests. Verify in a WordPress install:
+There are no automated tests, **and nothing about this plugin can be executed on this machine** — no PHP, so no `php -l` syntax check, no unit runner, no `.mo` compile (see § Translations). Every claim about runtime behaviour has to be verified by the user in a real WordPress install, or not claimed at all.
+
+Report edits as "written, not yet run." Do not describe untested code as working.
+
+Verify in a WordPress install:
 
 1. Enable `WP_DEBUG` and `WP_DEBUG_LOG`; watch `wp-content/debug.log`.
 2. Inspect the queue at **WooCommerce → Status → Scheduled Actions**, filtered to the plugin's action group — check pending/complete/failed and the spacing between scheduled times.

studiou-wc-mail-queue/docs/plans/implement-plan-00.md

@@ -957,7 +957,11 @@ AJAX handlers: verify nonce, check `manage_woocommerce`, clean the output buffer
 *Accepts when:* every destructive action is nonce-guarded and confirmed; a user without `manage_woocommerce` gets nothing from any endpoint; counts match direct SQL.
 
 ### Phase 9 — i18n
-Wrap every user-facing string. Generate the `.pot`, translate `cs_CZ` in full, compile with `wp i18n make-mo languages/`.
+Wrap every user-facing string. Generate the `.pot` and translate `cs_CZ` in full.
+
+**Compiling `.mo` is a hand-off, not a build step.** The dev box has no `php`, no WP-CLI, and no `msgfmt` (see CLAUDE.md § Translations), so neither `wp i18n make-mo languages/` nor the sibling plugins' `php generate-mo.php` fallback can run here. Deliver updated `.po` files and ask the user to compile — Poedit locally, or `msgfmt` on the server. Never hand-craft the binary.
+
+A stale `.mo` serves the old strings silently, so an un-flagged `.po` edit presents as a translation that simply did not take effect.
 
 *Accepts when:* `WPLANG=cs_CZ` renders the whole admin page in Czech with no untranslated fragments, and the version bump has landed in the `.po` `Project-Id-Version` header.