Repository navigation
Epic: M0 — verify every endpoint, header and class name before building on it #1
Description
Summary
Build plan §0.3 is the gate on everything else: never code against a described
API — verify it, record the verified signature in docs/verified-apis.md with a
date and source URL, and only then implement. Working instruction #2 says a
stub that raises NotImplementedError("blocked on verification: …") is honest,
and a guess that 404s in a customer sandbox destroys trust in the whole package.
This epic tracks the rows in docs/verified-apis.md that are still
UNVERIFIED. Each one gates named feature issues; a feature issue cannot be
closed while its gate row is open.
What is already verified (2026-08-28)
The LLM data plane is live-verified against a real Anypoint sandbox, which is
why Pillar 1 is buildable today:
| Fact | Verified value |
|---|---|
| Ingress base URL | https://<ingress-gw-host>/<instance-path>/ — no /v1 |
| Auth model | client_id + client_secret request headers, not bearer |
| Model routing | model-based-routing 1.0.3 reads model from the body |
| Streaming | "stream": true → text/event-stream, chunked SSE |
/models |
does not exist → 404 |
| Rejections | 401 client-id, 403 PII, 429 token budget, upstream passthrough |
| Token accounting | usage.{input,output,total}_tokens on the response |
Still open, grouped by what it gates
Control plane (§1)
- Region host variants for EU / CA / JP Hyperforce — gates
regioninDonkeyConfig - Connected-app scopes for Exchange read, API Manager write, policy management
- Which operations need an admin connected app with user context
Attribution (§3)
- The business-group attribution header name. This is the single most important
unknown — without it, per-agent cost attribution does not work.
Rejections (§4)
- Prompt-injection and content-safety rejection bodies (policies exist; not yet
triggered against a live instance)
Governance / local mode (§6.7)
- Can Local Mode run the LLM Proxy? Can it run MCP Bridge?
- Does Local Mode need a control-plane licence/registration artifact? Can CI run it?
- Which policies are Connected-Mode-only (the portability table)?
- Can applied policies be fetched in bulk per environment, or only per instance?
Publication (§7.9)
- Can arbitrary metadata/tags be attached, for the content digest?
- Are asset lifecycle states exposed via API?
- Can documentation pages be published programmatically, and in what markup?
Frameworks (§8)
- All eight constructor signatures are still
UNVERIFIEDin the table. See
Verify the eight framework constructor signatures against installed packages.
Acceptance criteria
- Every row in
docs/verified-apis.mdcarries a status, a date and a source - No row is
UNVERIFIEDwithout a linked open issue naming what it gates -
scripts/probe.pyre-run monthly; a fixture diff opens an issue automatically - Each verification flip removes the matching
_verify.blocked(...)guard
References
docs/verified-apis.md- Build plan §0.3, §6.7, §7.9, §11 working instructions 1–2
Activity
amirkhan-ak-sf commentedon Sep 4, 2026
Scope change from the phase-based backlog rebuild — the body below predates it and needs rewriting.
Was 'Epic: M0'. Rebuild as the standing Verification epic — the §0.3 discipline is cross-phase now, not a milestone that completes.
feat(skeleton): define the last-call record once at donkey.last_call (#…