parity-check

Parity-Check Protocol

Answers one question: did the framework produce the same shape of work on this runtime as it does on the reference one?

Not "is the output identical" — it never is. Two agents word an artifact differently, and so does the same agent twice. What must match is the shape: the artifact exists, carries its sections, registers its row, offers its gate.

When to invoke

• After installing an adapter on a new runtime, to see whether anything works at all
• After changing a protocol, to see whether the change holds on both runtimes
• Before claiming a runtime is supported

Input

A fixture directory under fixtures/{skill}/{case}/ and a runtime to test.

Output

A per-assertion report from bin/parity-run, plus a plain reading of what a failure means — a broken framework, a fixture that expects the wrong thing, or a genuine divergence between runtimes.

Hands off to

— (terminal). A failure is a finding, not a next step: it goes to the person running the check, who decides whether to fix the framework or the fixture.

---

Step 0 — Locate the workspace root

test -d fixtures && test -d bin && echo "root ok" || echo "not the workspace root"

Not the root → walk up until fixtures/ and bin/ sit side by side. Nothing found → stop and say so. Everything below assumes paths relative to that root.

---

Step 1 — Choose the fixture

List what exists:

find fixtures -mindepth 2 -maxdepth 2 -type d | sort

Show the list numbered. Accept either a number or a path.

No fixtures at all → say so and point at /fixture-new. Do not invent one on the spot: a fixture written to be passed is worth nothing.

---

Step 2 — Hand the task to the agent, then stop

Read {fixture}/input.md and show it in full, not summarised. It is the exact statement the agent under test must receive; paraphrasing it changes the test.

Then stop:

Hand the statement above to the agent you are testing, let the chain run to the
end, and come back when it has finished. Say "done" and I will pick it up.