to-conformance

Take a specification — a file, a linked doc, or the design in this conversation — and produce a conformance suite: the tests any implementation MUST pass to be considered compliant. Do NOT interview the user — synthesize from the spec and what you already know.

The unit of work is the chain normative requirement → conformance assertion → test case. Each requirement gets a stable ID and a black-box test that exercises it through the public interface or wire format, so the same suite can judge any implementation, not just this one. A requirement you cannot test is a spec bug — surface it rather than skipping it.

Process

1. Locate the spec

Use the spec-path argument if given; otherwise the spec under discussion, or the relevant SPEC/docs/ file in the repo. If the "spec" is only an informal design in the conversation, treat the design decisions as the normative source and say so.

2. Extract normative requirements

Pull out every requirement and classify its level (RFC 2119):

• MUST / MUST NOT / REQUIRED / SHALL — mandatory. A non-conforming implementation fails these.
• SHOULD / RECOMMENDED — expected unless there's a stated reason not to.
• MAY / OPTIONAL — permitted behavior; test that doing it and not doing it both stay conformant.

Catch the implicit requirements too — the ones the prose implies but never keywords: wire/encoding formats, error conditions, ordering guarantees, idempotence, boundary values, versioning/compatibility rules, canonicalization. Give each a stable ID (CONF-1, CONF-2, …) and cite its spec section.