[Update] Bundle npm 11, the floor wordpress-develop and Gutenberg now set (#251) - #468

CodeRabbit's finding on #468: the message claimed a package.json and lockfile drift, but the test compares the npm in node_modules against package.json's range, and a local node_modules can differ from the lockfile without either file changing. The message now names the installed npm.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

## Why

This is the **stable 1.1.0**. `v1.1.0-beta.1` shipped on 12 September
and `v1.1.0-beta.2` on 14 September; between them they were downloaded
33 times across macOS, Windows and Linux, and no issue was filed against
either. The v1.1.0 milestone is closed, 21 of 21.

Shipping sooner rather than later is itself part of the reasoning: a
site created by 1.0 cannot be written to by 1.1, so every day 1.0.1
remains the stable release is another day of sites being created that
the next version can only read.

Four commits reach this tag that no beta carried: the Linux target list
narrowed to the one artifact that is actually published and probed
(#467), the apply panel moved above the site's other tickets (#472), the
applied-patch record now travelling with carried work (#473), and the
sidebar heading renamed (#482). Three of the four are visible on screen,
so the artifact gets a manual pass before the release is published
rather than the packaging check alone.

The version reaches two places a contributor sees, and both must carry
the real build: electron-builder embeds it in the artifact names
(`wordpress-contributor-toolkit-1.1.0-*`), and `src/logging.js` writes
`app <version>` as the log's first line, so a problem report names the
build it came from. That is why the bump merges before the tag.

## What changes

Only the version. All three package-version fields in `package.json` and
`package-lock.json` move together from `1.1.0-beta.2` to `1.1.0`. No
dependency versions change, and there is no application behaviour change
in this PR.

## How to test this

Platforms: any for the suite; macOS or Windows for the artifact check
that follows the merge.

In the repository root:

1. `npm run lint` is clean and `npm test` passes.
2. `node -e "console.log(require('./package.json').version)"` prints
`1.1.0`.
3. `python3 -c "import
json;d=json.load(open('package-lock.json'));print(d['version'],
d['packages']['']['version'])"` prints `1.1.0 1.1.0`.

**What must not have happened:** no dependency version may change. `git
diff trunk` shows exactly three changed lines, all of them the root
package version.

After merge, the release build must produce artifacts named
`wordpress-contributor-toolkit-1.1.0-*`, and the first line of a fresh
app log must read `app 1.1.0`.

## Risks and limitations

No UI change. The risk is a mis-scoped edit in `package-lock.json`,
where dependencies also carry version strings; the replacement was
confined to the first 2000 bytes of the file, which holds the two root
entries, and both files were re-parsed as JSON afterwards.

Unlike the betas, this tag becomes `releases/latest`, so it is what the
README badge and every "download the toolkit" link resolve to.

## Related

Same shape as #397 (v1.0.1), #457 (v1.1.0-beta.1) and #466
(v1.1.0-beta.2). The Gutenberg stack for v1.2.0 is held as a draft at
#468 until this tag is pushed, so it cannot reach trunk and ship inside
a release it has never been tested in; #479 waits for the same reason.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

Version-only change, three lines. Verified locally on this branch: `npm
run lint` clean, `npm test` 1454 pass, 0 fail, 2 expected skips; `git
diff --stat` shows two files, three insertions, three deletions; both
JSON files parse. Nothing to fix, nothing deferred.

</details>

<details>
<summary>Screenshots or recording</summary>

Nothing on screen changes.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_0121dia1RzfskutrzA8iSK1K

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

CodeRabbit's finding on #468: the message claimed a package.json and lockfile drift, but the test compares the npm in node_modules against package.json's range, and a local node_modules can differ from the lockfile without either file changing. The message now names the installed npm.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…uilt check (#251) (#469)

## Why

Every fact that makes a site a WordPress Core site is a constant next to
the code that uses it: the clone URL in `wordpress:setup`,
`build/wp-includes/js/dist` in `site:status`, `grunt -- _watch` in the
dev-server planner, the docroot mount in the Playground runner,
`core.trac.wordpress.org` in the ticket parser,
`WordPress/wordpress-develop` in the pull-request flow. #251 asks for a
second target, Gutenberg, and there is no seam to put it through. This
is the seam.

## What changes

A registry, `src/project-type.cjs`: pure data and pure functions, one
entry per target (`core`, `gutenberg`), each carrying what the app needs
to clone it, know whether it is built, build and watch it, serve it,
read its work items and open its pull requests. The invariant every
consumer relies on: an unknown or missing type resolves to Core, so a
site created before the field existed keeps Core behaviour with no
migration and no store write.

Two handlers consult it. `wordpress:setup` accepts a `projectType`,
normalises it at the write boundary (an unknown id is stored as `core`,
not as whatever the renderer sent), clones the type's repository and
branch, names the folder after the type when the name is left empty, and
records the id on the site. `site:status` reads the built marker from
the type and reports the id.

Deliberately not in this PR: the renderer. The create-site dialog does
not send a type yet, so every site created today is still Core. Offering
Gutenberg before build (next PR) and serve (the one after) work would
hand a first-time contributor a checkout the app then runs Core's grunt
and docroot mount on, a state the app must not produce; the choice
appears once those two land. The registry also carries fields no caller
reads yet (serve strategy, patch layout, work-item provider,
pull-request prefix and body line): they are the same module's data and
the next five PRs consume them in order, listed in #251.

Ported from the closed #255 with three changes from the 15 Sep spike
(recorded in #251): the clone entry no longer describes a shallow clone,
since `git-clone.cjs` owns the clone's shape; Gutenberg's built marker
follows today's build layout
(`build/scripts/block-library/index.min.js`, `build/block-library` no
longer exists); and the Gutenberg terminal scripts leave out the bare
`test`, which needs Docker.

## How to test this

Platforms: any. No user-visible surface: nothing on screen changes, and
no site's behaviour changes, because nothing sends a type.

From the repository root:

```
node --test tests/unit/project-type.test.cjs
node --test tests/unit/ipc-wiring.test.cjs
```

The wiring tests are the demonstration: `wordpress:setup` with
`projectType: 'gutenberg'` clones `WordPress/gutenberg` into
`gutenberg-trunk` and records the type; with `'plugin'` it clones
`wordpress-develop` and records `core`; with nothing it does exactly
what it did before. `site:status` on a tree holding
`build/scripts/block-library/index.min.js` reads as built for a
Gutenberg record and as unbuilt for a record without the field.

**What must not have happened:** an existing site's status changing.
`hasBuilt` for a record without `projectType` still reads
`build/wp-includes/js/dist`, and no record is rewritten to add the
field.

## Risks and limitations

- `sites:add` (adopting a folder) records no type, so an adopted
Gutenberg checkout is a Core site. Right for now, since the app cannot
do anything with a Gutenberg site yet; the PR that exposes the choice
decides whether adoption detects one.
- The registry fields with no caller are unexercised beyond their shape
test until their PRs land. One of them, `build.watch`, restates the
`grunt -- _watch` constants in `dev-server-command.cjs`; the next PR
removes one copy.
- `wordpress:setup` accepts a `gutenberg` type over IPC today. Nothing
in the window sends one, and a site made that way would clone the right
repository and then be built, served and diffed as if it were
`wordpress-develop`. Review outcome: 1 [fix here] fixed, 2 [follow-up].

## Related

Part of #251. Stacked on #468.

---

<details>
<summary>Design decisions and alternatives considered</summary>

- A registry keyed by id rather than a class per target: the facts are
data, and both processes load the module (the renderer bundle will, from
the PR that shows the picker).
- Storing the normalised id rather than leaving the field absent for
Core: a record that says `core` and a record that says nothing both read
as Core, but only one of them was written by a version that knew the
question.
- Not adding the picker here (see What changes).

</details>

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

1 [fix here] · 2 [follow-up] — the [fix here] fixed in `85f8047`, plus
one style note taken.

- 🔵 Security [fix here] `src/project-type.cjs`: `getProjectType` indexed
the registry directly, so `'__proto__'`, `'constructor'` or `'toString'`
resolved to something truthy that was not a project type and the Core
fallback never fired (verified by running the module). Fixed: it goes
through the own-property check; the fallback test now tries those keys
and fails on the old module.
- 🔵 Architecture [follow-up] `src/project-type.cjs` vs
`src/renderer/dev-server-command.cjs`: `build.watch` restates the `grunt
-- _watch` constants that planner owns. Deferred to the next PR, which
teaches the planner about the type and deletes one copy.
- 🔵 Architecture [follow-up] `src/main.js` `wordpress:setup`: the
handler accepts `gutenberg` over IPC while the rest of the app is
Core-shaped. Unreachable from the window; recorded in the handler's
comment and under Risks. `sites:add` recording no type is the deliberate
answer for now.
- Style, taken: `findAvailableDirName`'s `'wordpress-develop-trunk'`
fallback became unreachable; deleted so the default lives in the
registry only.

Verified clean by the reviewer: store migration (every writer spreads
the existing record; nothing rewrites a record to add the field),
`site:status` keeps Core semantics on every failure path, cross-platform
path handling, and the wiring tests fail when the handler stops reading
the registry.

- **Review:** completed — fresh Explore subagent context (local
`/self-review`); reviewed head `9c28408` / base `458fa34`; deterministic
layer (lint, `npm test`) run by the author; outcome above
- **Since review:** `9c28408 → 85f8047` checked: only the fixes above;
lint and `npm test` re-run green (1467 pass, 2 pre-existing skips)

</details>

<details>
<summary>Screenshots or recording</summary>

Nothing on screen changes.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>