fix(brains): sync the generated capability catalog to production and bump to 2.9.4 [BRNS-DIST-017]

[olegshmuelov]

What

Syncs the two stale generated artifacts to what production serves — ssvlabs/brains @ 96e3f1dbc, the stage → main promotion that merged today — and bumps the plugin to 2.9.4 on both manifests. plugins/brains/skills/brains-automation/SKILL.md and plugins/brains/generated/capability-catalog.json are byte-identical to the monorepo generator's output at that commit (--plugin-root run from a detached worktree, --source-commit stamped; no hand edits). The other four published skills were already fresh at that commit.

Why

The published skill currently teaches an integration read shape that silently ingests nothing: brains.fetch({source, input}). An explicit input is forwarded verbatim to the source's fetch action, so without write_pages: true the call reaches Google, writes zero pages, returns ingested_count: 0, and discards what it fetched. Only the request arm sets the flag for you. Every automation an agent authors from the current copy inherits that bug. The regenerated copy teaches brains.fetch({source, input: {…, write_pages: true}}).

Two smaller corrections ride along, both about what a mandated Step 8.5 smoke test proves. The verify_mode documentation now states that http_fetch (any method) and adapter_query are suppressed — previously unstated, so an author could believe a verify run had exercised an external call. And the succeeded row no longer implies a green run proves one.

Contract-test changes

tests/plugin-contract/run.ts pins several regions of the generated skill verbatim, because keyword checks are defeated by paraphrase — a sentence added beside a rule can reverse it while every substring check stays green. Three pins break against the new bytes and are re-pinned:

• AUTOMATION_SMOKE_TEST_REGION — the verify_mode bullet changed, and the region's exclusive end-anchor The tool enqueues no longer exists; the polling paragraph now opens The tool polls until. The anchor moved with it and the region covers the same span.
• AUTOMATION_SUCCEEDED_RESULT_ROW — re-pinned to the new row.

No existing pin was widened or weakened; AUTOMATION_VERIFY_CARVE_OUT is unchanged and its placement check is exactly as strong as before.

This change also introduces three rails that nothing here reached, so they are pinned alongside — the same reason Rule 2b was added last sync. All three are bounded-region equality rather than substring containment, because containment proves adjacency, not exclusivity: a contradicting sentence added beside a pinned string leaves every includes green while the surrounding text says the opposite.

• Rule 2c — the whole partial row, matching how its sibling succeeded row is already pinned; and the failed/killed row from its opener through its cause list. The update_agent full-replacement mechanics after the Patch the source via hand-off stay outside the pin deliberately, since they drift for unrelated reasons; the comment says so.
• Rule 4 — the complete Reads/refresh cell, plus a shape check that extracts every brains.fetch(...) call and requires each to carry write_pages: true. Calls whose parentheses never close are refused outright rather than assumed correct, so an unbalanced paren inside a query string cannot produce a runaway slice that inherits a flag from elsewhere in the file.

These are pinned here rather than left to upstream on purpose. Upstream pins catch an upstream regression; they say nothing about a coordinated edit in this repo — artifact plus refreshed digest plus version bump clears both the digest loop and generated-artifact-guard.sh, which names that hole in its own LIMIT section. Every pin is mutation-tested with the digest refreshed: reverting a rail, appending a contradiction beside one, and every flag-less call spelling tried — including one that smuggles the flag’s text inside a quoted argument — fail on their own named assertion, while an edit to unpinned prose still passes. The fetch check does not search for the flag at all: the skill must contain exactly one brains.fetch call and it must sit inside the equality-pinned cell, so the flag is pinned transitively and a second call of any shape reds the build.

Worth a careful look: these are sentences authoring agents execute on user machines, so what matters is whether each is true of the server at 96e3f1dbc, not whether the suite goes green. Each was checked against the verify-mode gate, the http_fetch short-circuit and the open-world read dispositions.

Known residuals (upstream generator copy — deliberately not edited here)

• The verify_mode bullet names http_fetch and adapter_query as suppressed, which reads as exhaustive. fetch_from_integration is suppressed and unvalidated too, while the same skill files brains.fetch under "Reads/refresh".
• The succeeded row's "nothing was written or sent" understates external compute — automation_llm_complete and recommend_recipes stay live and reach a model provider — and its "the validated writes really ran" overstates a status that means only exit 0 with empty stderr.
• The suppression case the rows call expected has no terminating path: "no fix spent", but Step 9 stays barred until succeeded, and a rerun is deterministic.
• "Board rows and board metadata … stay fully validated" holds for the nine named board tools; dashboards, comments, forms, ACLs, uploads, links and board skills are suppressed unvalidated. Step 5.5 still says egress happens from the "stage VPC".

All need catalog fixes in ssvlabs/brains and are tracked there. Note the constraint on any of them: the injected automation block is 13,993 tokens against a 14,000 budget, so naming another tool costs a cut elsewhere.

Ticket: BRNS-DIST-017

[sebastian-ssvlabs]

Reviewed-at: 076a949

[sebastian-ssvlabs]

Reviewed-at: a299bb9