porting-agent-to-hub

Follow the seven phases in order: decide whether it should ship, audit manifest claims against code, generalize and harden, write behavioral tests that invoke every tool, build an eval corpus and scorecard, generate the parity kit from the email agent template, then set up independent versioning and CI.

Check that every advertised capability has a reachable tool, every conversation starter maps to a real tool, tools_count matches in both gaia-agent.yaml and build_registration(), and declared interfaces like api_server have the required amd-gaia[api] dependency declared.

Skip porting when a more general agent already covers the use case, the agent is marked category examples or security_tier experimental, it lacks a gaia.agent entry point, or a named successor is already in flight. Duplicating capability into the catalog is worse than not shipping.

Most fleet tests only construct the agent and assert a tool name exists in the registry without invoking it. Every @tool needs a test that actually calls it over a fixture harness with registry isolation, covering cold-start states like empty indexes and first runs.

The full chain must work scripted with no human step: catalog index, install, daemon spawning the sidecar, /health passing, /query returning a rendered SSE stream in the UI, and the playground URL loading. Any manual step means it is not day-one usable.