docs: two wrong/incomplete notes about `wrangler types --check` and the Renovate regen ordering

[wormeyman]

Two documentation defects found while diagnosing why #97 is red. Both are actively misleading, and both will bite on every future wrangler bump.

1. CLAUDE.md understates what wrangler types --check compares

The Preview service section currently says:

Limitation: --check compares the config against the hash recorded in the generated file's header. It catches a changed wrangler.jsonc, but it does not notice hand-edits to the generated file itself.

That is incomplete in a way that leads to the wrong conclusion. --check also compares the workerd version stamped on line 3 of worker-configuration.d.ts:

// Generated by Wrangler by running `wrangler types` (hash: d5c32104cadf4e922330480e9d78b1fa)
// Runtime types generated with workerd@1.20260722.1 2026-07-01 nodejs_compat

Both halves of this were observed directly:

• Editing wrangler.jsonc did not change the hash. Changing the containers block (instance_type, max_instances) regenerated the file with the hash identical at d5c32104… and --check passing. So the containers block is not in the hash at all.
• A wrangler-only bump invalidates the file with the hash unchanged. On chore(deps): update cloudflare worker toolchain #97, wrangler 4.115.0 → 4.118.0 drags workerd 1.20260722.1 → 1.20260730.1. The hash is unchanged and every type body is byte-identical; the only differing line is the workerd stamp, and --check fails on it.

Anyone reading the current note would rule out a wrangler bump as the cause, because no binding moved and no config changed. That is exactly the wrong call - it is the whole reason #97's verify is red.

Suggested fix: state that --check compares both the config hash and the workerd version, and that a wrangler bump moving workerd invalidates the file on its own.

2. .github/renovate.json5 has the regen ordering backwards

The prBodyNotes on the grouped wrangler + @cloudflare/vitest-pool-workers rule tells the reader to regenerate the worker types after merging.

It has to happen before. verify is a required status check, preview:test is its last phase, and that phase runs pnpm run types:check && vitest run - so a stale stamp fails verify and the PR cannot merge at all. The regen is a precondition, not a follow-up.

This is not hypothetical: it is why #97 has been sitting red.

Suggested fix: reword to say the types must be regenerated on the PR branch before it can go green, with the command:

pnpm --filter @fmw/preview-worker exec wrangler types && pnpm vp check --fix

The formatter pass is not optional - wrangler emits tabs and unwrapped types, so a raw regen produces a whole-file whitespace diff that hides the real one-line change.

Why file this rather than just fix it

Both edits are small, but CLAUDE.md is load-bearing for how this repo is worked on and the note being wrong cost real time on #97. Recording the evidence matters as much as the wording, so the next person does not re-derive it.

🤖 Generated with Claude Code

https://claude.ai/code/session_018AB7J1qK6kSBnJJmgDqMst