Skip the Claude review on fork PRs, and correct three stale CLAUDE.md notes

[wormeyman]

What

Two independent housekeeping changes, both docs-or-CI only. No source files change, so the editor's behaviour is untouched.

1. A job-level if in .github/workflows/claude-code-review.yml so the Claude review skips on pull requests from forks.
2. Four corrections to CLAUDE.md, each re-measured rather than edited by inspection.

---

1. Skip the Claude review on fork PRs

GitHub withholds repository secrets from a pull_request event raised by a fork, so secrets.CLAUDE_CODE_OAUTH_TOKEN resolves to an empty string and the action fails every time.

Measured over every run of this workflow rather than assumed. Tallying all 30
runs recorded before the fix, by whether the head was a fork:

Origin	claude-review	Runs
fork	failure	17
in-repo	success	13

That is the whole pattern - no exceptions in either direction. It is not a
misconfiguration the workflow can fix - it is what the event is for.

Correction. This table originally listed six named PRs and gave #227 as a
fork failure. #227 never had a claude-review run at all: its branch
book-dialog-v2 appears nowhere in the workflow's history, which starts
2026-08-20, while #227 was opened 2026-08-13 and last touched 2026-08-17. The
row was wrong. The tally above is what the run history actually supports, and
it makes the same point on more evidence.

Why it is worth fixing. The failure blocks nothing, which is exactly the problem. Every fork PR opens with a red X, and a check that is always red is a check nobody reads, so a real failure in it gets missed.

Why not pull_request_target. That would get fork PRs actually reviewed, but it runs with base-repo secrets against a fork's code - the documented path to secret exfiltration from an untrusted contributor. Every outside contribution to this repo arrives from a fork, so the trade is not available. There is a comment at the guard saying so, because the next person to notice the skipped runs will reach for it.

The commented-out author filter it replaces was a footgun. Uncommenting it would have added a second if: to the same mapping, and with duplicate keys the last one wins - verified, a two-if job resolves to the second. It would have silently overridden this guard.

Control: claude-review still ran and passed on this branch, which is in-repo. The guard does not break the in-repo path.

---

2. CLAUDE.md corrections

The documented install command never set the version

It read:

VP_VERSION=0.2.8 VP_NODE_MANAGER=yes curl -fsSL https://vite.plus | bash

An assignment ahead of a command applies to that command alone, so curl got the variables and the bash on the far side of the pipe read an empty string. Measured against a stub script:

--- form used in CLAUDE.md:106 (vars before curl, piped to bash) ---
script sees VP_VERSION=[]
--- form used in setup-vp/action.yml (vars before bash) ---
script sees VP_VERSION=[0.2.9]

The installer then falls back to VP_VERSION="${VP_VERSION:-latest}" (line 26 of the script, with default: latest in its own header). So anyone following that line installed latest, not the pin - the same "green, and wrong" split the file warns about one section down, where the local vp is a different toolchain from the lockfile's and CI's and nothing says so.

The replacement downloads the script and runs it with the variables ahead of bash, matching setup-vp/action.yml, and sets VP_HOME for the layout reason #260 established. Syntax-checked with fish -n, since it is a fish block.

The pin is 0.2.9, and the file said 0.2.8

Measured at all five sites:

Site	Actual
package.json:30	0.2.9
package.json:40 (overrides alias)	@voidzero-dev/vite-plus-core@0.2.9
packages/editor/package.json:33	0.2.9
packages/website/package.json:22	0.2.9
setup-vp/action.yml:64	VP_VERSION=0.2.9

The file also said 0.2.8 was latest as of 2026-08-11. npm view vite-plus dist-tags gives 0.3.0 today. The entry has now gone stale twice - it said 0.2.6 while 0.2.8 shipped, then 0.2.8 while the repo moved to 0.2.9 - which is its own best argument, so it now says so and points at the command to re-measure with. No version bump here; Renovate tracks vite-plus on a 24-hour cooldown and 0.3.0 is a day old.

The checksum note reassured you about the thing that took CI down

It said the hash did not move across 0.2.6 -> 0.2.8, so a bump usually leaves it alone. True when written, and that is what made 2026-08-24 expensive: the script rotated with VP_VERSION untouched and every job on every branch failed at Set up Vite+. The note now records that the rule runs both ways - a hash can move with no bump at all.

Re-fetched today: the current installer sha256 is 3dd88ced…, which still matches the pin. Nothing in CI needs changing.

The ajv entry named two deleted classes

It described ModdedBlueprintError and TrainBlueprintError as declared, exported, handled and never thrown. #262 deleted both. The point it was making survives - ajv is ~100 kB and nothing branches on its result - so it keeps that and records what went, since the names are still findable in the history.

---

Verification

• vp check - 230 files formatted, 0 warnings, lint errors or type errors
• vp test - 187/187 across 15 files
• Workflow YAML re-parsed after the edit: if is a real key on the job, and the only one
• Full CI green on the first commit, including claude-review as the in-repo control

🤖 Generated with Claude Code

https://claude.ai/code/session_018N3pm7fQQDv6HTVz1TEpmE