Say what the field-test harness establishes, and what it does not

[patchstackdave]

Docs only. Three files, no behaviour change.

What changed

field-test/README.md opens with what the harness is: structural regression coverage for the install prompt. A green run means the prompt still survives pressures that once broke it — and the value in that is real, because every pressure encoded there produced an actual refusal, and every clause in the prompt exists because a run like it failed without one.

What a green run is not is evidence that a live platform accepts the prompt. The personas are synthetic, written from our own analysis rather than from any platform's policy text, and a hosted product is (prompt × model × runtime × UI) — this reproduces one of the four. The README said as much already; the two documents that tell a contributor to rely on the gate did not, so MAINTAINING.md and CONTRIBUTING.md now say it in the same terms.

The pointer to a future private evaluation repository is gone. High-fidelity evaluation against real policy text would need one, nobody has a standing need for it, and an unbuilt plan referenced in shipped docs reads as a commitment.

Why bother

The harness is a merge gate for prompt changes, so how strong it is taken to be decides how much weight a green run carries. A gate described as validating the prompt against platforms invites treating a field refusal as surprising, when the correct response is to add coverage — which is what the docs now say to do.

[coderbuds]

Documentation clarifies the field-test harness’s scope and limitations precisely.

🎯 Quality: 97% Elite · 📦 Size: Small

📈 This month: Your 150th PR — above team average · Averaging Elite

_{See how your team is trending →}

[patchstackdave]

/review