Owned mode has no return path from CI: agents cannot learn their work failed

[chubes4]

The gap

In owned mode the agent edits wp-content in place on the live server. Its code reaches version control through harvest, and CI runs whatever suites the repo has.

That flow is one-directional:

agent edits wp-content on the live box
        |
     harvest                        code flows UP
        v
   git + CI  ──> verify runs the suites
        |
        X                           nothing flows BACK

Nothing carries a CI result back to the agent or its operator. The agent cannot learn that the change it made last night broke the build, because no channel exists to tell it.

What that costs in practice

Observed on a production owned-mode site (h44lacrosse.com):

• The agent changed a REST contract on the live site: added two meta keys to an event resolver, turned a free-text field into an enum, and made another field required.
• Harvest captured the code. The repo's e2e fixtures still described the previous contract, because nothing updates fixtures alongside a live edit.
• verify went red and stayed red for twelve consecutive nightly runs (2026-08-22 → 2026-09-03).
• Nobody noticed, because a permanently-red job is indistinguishable from a broken one.

The compounding failure is the real point. During those same twelve days the site's Kimaki service was hard-down for five days across ~29,900 failed restarts, and that went unnoticed too — partly because the one nightly signal anyone might have looked at was already red for unrelated reasons.

A signal nobody trusts is not a signal. Owned mode currently guarantees one.

Why "ship the tests to the box" is the wrong fix

Measured on that site:

	size
contract source (assert-*.php + recipes, 10 files)	80K
build artifacts	3.3M
the runner (wp-codebox + Playground, pre-npm ci)	1.4G
box memory available, serving live traffic	2.1Gi

The tests are not heavy. Running them is. Executing a Playground-based suite on a 3.7Gi production VPS is not a tuning problem, it is off the table. Any proposal that puts the runner on the box should be rejected on these numbers.

CI already runs the suite, on free compute, correctly. Nothing about detection is broken.

Proposed shape: send results, not runners

The mechanism already ships. Every wp-coding-agents install has:

wp-content/mu-plugins/wp-coding-agents-inbound-events.php

a generic, HMAC-signed inbound event bridge that dispatches external events to the agent. The pipe exists and nothing is connected to it. A CI job that posts its failure summary to that bridge closes the loop for well under 1KB per event — the [FAIL] lines from a full red run are a few hundred bytes.

Rough shape:

1. CI job fails.
2. It POSTs a signed summary (job, conclusion, failing assertions) to the site's inbound event endpoint.
3. The bridge surfaces it on the agent's normal coordination surface, so a human sees it the same day rather than a fortnight later.

Deliberate non-goal: the agent must not fix its own tests

An owned-mode agent has no repo checkout and therefore cannot edit fixtures. That limitation should be kept, not engineered around. An agent that edits the suite grading its own work is marking its own homework, and a green suite it rewrote is worth less than a red one it reported.

The correct outcome of a red verify is: tell a human, and fix the live code if the failure is real. Results-only feedback supports exactly that and nothing more.

Scope

• Not site-specific. Any owned-mode install with CI has this gap; h44 is only where it was observed.
• Detection already works. This is purely the missing return edge.
• The transport already exists and is installed everywhere. This is wiring plus a documented contract for the payload, not new infrastructure.