epic(scanner): publish agents and MCP servers through the self-managed scanner (GA-gated) #1102

Summary

Make donkey a first-class Anypoint self-managed scanner: build a service bundle per agent / MCP server from code, push it to a scanner configuration, and commit the run. This is BG §2.5's "the Agent Scanner for your git repo" on the platform's own ingestion path. It is a parallel publish target to #218 (direct Exchange publish), not a replacement.

⛔ GA gate — do not start

The self-managed scanner is not GA. No child of this epic may be picked up, branched, or implemented until #1101 is closed (GA confirmed and contract verified live). Every child is structurally blocked-by #1101 and carries blocked-on-verification.

Motivation

• Integrates with, rather than duplicates, the platform's scanner (the Phase 2 standing constraint in epic: Phase 2 — Differentiate, go beyond #260; BG do-not-build list: no Agent Scanner re-implementation).
• commit {complete:true} reconciles the full service set, so services deleted from code disappear from the registry. This is scanner: donkey publish registers the manifest with Exchange / Agent Registry #218's "stale tool list" problem.
• The ZIP directory name is the stable service ID, which gives a natural, code-owned identity.
• Needs no Maven/JVM, unlike the Exchange publish path (ledger §7, §12.7).

Scope

Agents (A2A card) and MCP servers. REST APIs (OpenAPI/RAML) are deferred to #1110 (Phase 3).

Note: today only the Agent push instructions are published. MCP Server push instructions are not yet available in the product, so #1105 cannot be specified until they are (tracked in #1101 item 6).

Children

• verify: self-managed scanner is GA, and its push/commit/unstage contract #1101 — verify: GA + push/commit/unstage contract (gate, Verification)
• scanner: self-managed scanner client — push, commit, unstage #1103 — scanner client: push, commit, unstage
• scanner: build the agent service bundle (config.json + a2a-card.json ZIP) #1104 — agent service bundle (config.json + a2a-card.json)
• scanner: build the MCP server service bundle #1105 — MCP server service bundle
• cli: donkey publish --target self-managed-scanner #1106 — donkey publish --target self-managed-scanner
• scanner: refuse to register the same service via Exchange and the self-managed scanner #1107 — duplicate guard across Exchange and the scanner
• simulator: emulate the self-managed scanner push/commit/unstage endpoints #1108 — simulator emulation of the scanner endpoints
• docs: document publishing via the self-managed scanner #1109 — docs
• scanner: publish REST APIs (OpenAPI / RAML) through the self-managed scanner #1110 — REST APIs (deferred, Phase 3)

Out of scope (tracked elsewhere)

• Direct Exchange publish: scanner: donkey publish registers the manifest with Exchange / Agent Registry #218. Scan/discovery: scanner: donkey scan derives a deterministic scan model of agents, tools and MCP servers #217. GitHub Action: scanner: the scan-and-publish GitHub Action #219 (gains a target input once cli: donkey publish --target self-managed-scanner #1106 lands). Tool→asset attribution: scanner: define how a @donkey.tool is attributed to an MCP server / Exchange asset #503.
• Creating/administering scanner configurations, unless verify: self-managed scanner is GA, and its push/commit/unstage contract #1101 shows an API exists. Default assumption: the config ID is supplied by the user.

Related

• epic: Phase 2 — Differentiate, go beyond #260 — Phase 2 epic. scanner: donkey publish registers the manifest with Exchange / Agent Registry #218, scanner: donkey scan derives a deterministic scan model of agents, tools and MCP servers #217, scanner: the scan-and-publish GitHub Action #219, scanner: define how a @donkey.tool is attributed to an MCP server / Exchange asset #503.

Done when

• donkey publish --target self-managed-scanner publishes ≥1 agent and ≥1 MCP server from a sample repo to a sandbox scanner configuration, and they appear as discovered services.
• Re-running with no code change is a no-op (digest). Removing a service and committing with complete:true removes it.
• Publishing a service already registered via the other target fails loudly (scanner: refuse to register the same service via Exchange and the self-managed scanner #1107).
• §13 of docs/verified-apis.md is VERIFIED. The docs site documents the flow. The simulator covers it in CI.