meta: verified-apis.md as the living source of truth, and the _verify.blocked discipline #101

Summary

Working instruction #1 is the project's core discipline:

"Verify before building. Every endpoint, header name, class name and policy
asset id in this document is a hypothesis until confirmed against a live org or
official docs. Nothing ships on an unverified assumption. Where verification
is pending, the code raises a clear NotImplementedError with a message naming
what needs confirming — it does not guess."

docs/verified-apis.md is where that discipline lives, and
donkey_kit.core._verify.blocked() is how it is enforced in code.

Why this works

A stub that raises with a specific message is honest and greppable. A stub that
guesses produces a plausible-looking call that fails in a customer's org, weeks
later, with no indication that it was never verified.

from donkey_kit.core import _verify

async def build_plan(spec: DonkeySpec, donkey: Donkey) -> Plan:
    _verify.blocked("MCP Bridge provisioning endpoints (§5, §0.3)")

NotImplementedError: blocked on verification: MCP Bridge provisioning endpoints
  (§5, §0.3). See docs/verified-apis.md.

Current state

docs/verified-apis.md exists with sections §1–§12 and a mix of VERIFIED,
VERIFIED (plugin) and UNVERIFIED rows. The wins so far are substantial:

• LLM proxy route, auth (client_id/client_secret headers, not Bearer), and
  the four rejection shapes
• Gateway is Flex Gateway v1.13.2, flexGateway API type
• The six real policies on a governed LLM proxy, with exact versions
• Exchange first-class MCP-server and AI-agent asset types; GAV publication
• The agent-network CLI provisioning surface, and the REST endpoints behind it

The highest-priority remaining unknowns

Acceptance criteria

• docs/verified-apis.md exists with per-row status
• _verify.blocked() used throughout instead of guessed implementations
• Every row carries a date and a source — a VERIFIED with no date decays
  into an assumption
• VERIFIED (plugin) distinguished from VERIFIED (documented) everywhere, and
  cross-referenced into docs/unsupported-boundary.md
• A CI check failing if any _verify.blocked() message cites a section that no
  longer has an UNVERIFIED row — so stubs cannot outlive their verification
• A CI check failing if a new outbound host or header appears in code without a
  corresponding row
• Each open unknown has a GitHub issue, labelled blocked-on-verification,
  linked from the row
• Re-verification cadence documented, since platform APIs move

References

• docs/verified-apis.md, python/src/donkey_kit/core/_verify.py
• Build plan §0, §11 working instructions 1–2, §12