spec(envelope): forbid task_status/response_status at schema level

[bokelley]

Closes #3041

Summary

PR #3021 added normative MUST NOT prose against v3 agents dual-emitting task_status or response_status alongside status. Reviewer flagged on #3021 that the rule was only human-discoverable — worth a machine-checkable assertion.

This lifts the prohibition into the envelope JSON Schema itself, using the existing not: { anyOf: [{ required: [...] }] } idiom (the same pattern core/catchment.json uses for its mutually-exclusive field groups):

"not": {
  "anyOf": [
    { "required": ["task_status"] },
    { "required": ["response_status"] }
  ]
}

Any envelope containing either legacy field now fails draft-07 validation against /schemas/core/protocol-envelope.json. No runner-specific primitive, no storyboard changes, no client code required — every JSON Schema validator in the ecosystem enforces it.

Verification

Ajv-compiled protocol-envelope.json against five cases:

Envelope	Result
{ status, payload } (clean)	✅ valid
{ status, payload, task_status: "completed" }	❌ invalid
{ status, payload, response_status: "ok" }	❌ invalid
{ status, payload, task_status, response_status }	❌ invalid
{ status, payload, custom_field } (unrelated extra)	✅ valid

additionalProperties: true is unchanged — buyers and sellers can still add non-protocol fields; the constraint is narrow to the two named legacy names.

Non-breaking

Targets behavior that was already non-conformant per #3021 / the normative prose added to the status description. No conformant v3 agent emits these fields. No existing example envelope in the schema is affected.

Out of scope

Runtime storyboard enforcement — a new storyboard primitive (field_absent) plus the @adcp/client implementation needed to evaluate it would duplicate what schema validation already catches. If a compliance-runner-level hook is still wanted after this ships, I'll file a follow-up on @adcp/client to wire the envelope schema into every storyboard's response_schema pass — which is where envelope validation naturally belongs.

Pre-PR checks

• npm run build:schemas — clean
• npx changeset status — adcontextprotocol: patch
• npm run build — clean (all 10 universal / 6 protocols / 20 specialisms compliance bundles build; latest protocol tarball builds)
• npx vitest run — 820/820 passing
• ajv test vectors above — all pass

🤖 Generated with Claude Code