[chubes4]

Related issues

• Builds on Studio Code: Flag block attributes the block type does not declare #5300 (attribute check) and Studio Code: State the active site's WordPress version, block types, and Site Editor copies as facts #5301 (Active site facts). Found while evaluating Studio Code: State the active site's WordPress version, block types, and Site Editor copies as facts #5301.

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) read the failing eval transcripts, wrote the change and its tests, and ran the evals below. I reviewed the code and the transcripts.

Proposed Changes

When a tool result shows block markup, Studio Code adds one line for each core block type in it, listing the settings that block type declares in the site's own wp-includes/blocks/<block>/block.json. For example:

core/navigation settings, declared in …/wp-includes/blocks/navigation/block.json: ref (number), …, showSubmenuIcon (boolean, default true), submenuVisibility ("hover"|"click"|"always", default "hover"), overlayMenu (string, default "mobile"), …

• Each block type is described once per turn. Attributes read from the block's HTML (source) are content, so they are left out, along with internal __unstable/__experimental ones.
• It applies to every Studio tool result, so wp_cli post get, Read and Bash cat all get it.
• It reads files on disk only. Plugin blocks, remote sites and blocks without a block.json are skipped.

Why. In the template-part eval ("Make the header navigation open its submenus on click instead of on hover"), the failing runs reason "there's no built-in 'open on click' toggle … this requires custom JavaScript", then write a script and CSS into the theme, at 1–1.7M tokens per run. The navigation block declares submenuVisibility: "click". The model doesn't remember it and has no reason to open block.json. Stating the declared settings where the block appears means the model reads them while it is looking at the block.

Testing Instructions

• npx vitest run apps/cli/ai/tests/block-settings.test.ts: describes the core blocks in a header from their block.json, describes each one once, and leaves out content attributes, closing comments and blocks without a block.json.
• Eval: template-part-db-override, 6 runs per arm, run against this branch and current trunk (09253bcef) at the same time:

	Pass	JS workaround	Mean tokens	Mean tool calls	Mean time
This branch	6/6	0	223k	17	53s
Trunk	4/5	1	675k	32	94s

One trunk run stalled at the 420s timeout after 91k tokens without reaching an answer. It is left out above as an infrastructure stall. Counted as a failure, trunk is 4/6.

• Every branch run's session shows the core/navigation settings line in the post get 5 or Read parts/header.html result, and every branch run set submenuVisibility in the saved header. No branch run wrote JavaScript or read core's navigation/view.js. On trunk, one run wrote a script and another read view.js three times before finding the setting.
• Regression check: the three other cases that start on a local site, 6 runs per arm:

Case	This branch	Trunk
global-styles-db-override	6/6, 189k tokens	5/6, 187k tokens
design-system-annotation	6/6, 260k tokens	5/6, 289k tokens
active-site-reused	6/6, 68k tokens	6/6, 66k tokens

Both trunk failures are unrelated to this change: one is a port collision during inspection, the other discarded the saved styles. The settings line appeared in only 1 of these 18 runs (it passed), because these tasks rarely read block markup, so this check shows no harm rather than a gain.

• Size: replaying 263 earlier sessions that read block markup, the added lines come to a median of ~240 tokens per session (p90 ~460, max ~1.8k).
• Six runs per arm can't establish a pass-rate gain, so the claim is parity or better on accuracy. The fall in tokens and tool calls is large and consistent across runs.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing daa71b2 vs trunk

app-size

Metric	trunk	daa71b2	Diff	Change
App Size (Mac)	940.68 MB	940.68 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	daa71b2	Diff	Change
load	1217 ms	1209 ms	8 ms	⚪ 0.0%

site-startup

Metric	trunk	daa71b2	Diff	Change
siteCreation	7536 ms	7512 ms	24 ms	⚪ 0.0%
siteStartup	4377 ms	4378 ms	+1 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[youknowriad]

• studio mcp doesn't get this. The hook is in the pi runtime's toToolDefinition, so Claude Code and Codex agents never see these lines. Can we move it somewhere studio mcp tool results also pass through? It's important that all fixes we do for Studio Code support all of our surfaces (including CLI, app, the AI plugins and MCP)
• It's once per session, not once per turn. The tracker is created in createStudioAgentSession, so after a compaction the model may have lost the line and never gets it again. That's probably fine, but the description should say so.

It would also help to know how often the "rebuild a built-in block setting in JS/CSS" pattern shows up in real sessions beyond this eval. That would tell us how much this is worth beyond the one case.