refactor(ci): validate every bundled template.yaml declares only what it ships

[obasilakis]

Summary

There is no CI validation of template.yaml anywhere (grep over .github/workflows/*.yml for template.yaml / template_service / compatibility returns zero hits). The only declaration-vs-file cross-checks that exist — compatibility checks X-003 (skills) and X-004 (mcp_servers) — run against a live agent's workspace at runtime and are advisory/non-blocking, so they cannot fail a build.

That gap is the root cause of #1646: the bundled Cornelius template was a vendored snapshot of Abilityai/cornelius that took template.yaml + CLAUDE.md + .gitignore but not .claude/ or resources/local-brain-search/. It advertised ~24 skills, 9 sub-agents and a FAISS semantic tier the bundle could not serve, and shipped through a release (v0.8.0) with nobody noticing — on the agent that is auto-seeded for every fresh install (trinity-enterprise#107).

#1646 fixes that one instance and regression-tests it. This issue guards the class.

Context

tests/unit/test_1646_cornelius_template_claims.py (from #1646) already encodes the rules, deliberately written as "every declaration resolves to a file" rather than pinning a list. It is scoped to the Cornelius bundle only. The work here is to generalize it across config/agent-templates/*/ and wire it to a workflow.

Worth knowing: skills, sub_agents and capabilities have no functional effect at creation — crud.py:566-609 reads only type, resources, tools, credentials.mcp_servers, runtime, shared_folders. They are display metadata (rendered by InfoPanel.vue from /api/agents/{name}/info, which echoes template.yaml verbatim and unvalidated), which is exactly why drift is invisible until a user clicks something.

Suggested approach

A CI job over every config/agent-templates/*/template.yaml asserting:

• skills: → .claude/skills/<name>/SKILL.md exists in that bundle (the X-003 rule, moved pre-merge)
• sub_agents: → .claude/agents/<name>.md exists — no check exists for this today, at runtime or otherwise, and InfoPanel.vue:131-160,383-391 renders sub_agents as a clickable delegation prompt, so a phantom entry is a button that resolves to nothing
• mcp_servers: ≡ .mcp.json.template keys (the X-004 rule). Note trinity is injected into .mcp.json by the platform at start and is legitimately absent from the template file
• CLAUDE.md @-imports resolve inside the bundle (the vendored file carried @.claude/settings.md and @knowledge-base-analysis.md; neither shipped, so both resolved to nothing on every fresh install)

Open design question (decide in the issue, not in review)

Should the check also validate capability tokens? Today capabilities: is a free-form string list with no registry, and brain-orb is the only token anything reads (src/frontend/src/router/index.js:82 gates the Brain tab on it). Everything else is a display chip behind a <details>. Making it a validated enum is a bigger question — it would need a token registry and a decision about whether third-party templates may invent tokens — and may belong in its own issue.

Acceptance Criteria

• A CI job fails when any bundled template declares a skill / sub-agent / MCP server it does not ship
• The job covers all of config/agent-templates/*/, not just Cornelius
• Verified against the pre-bug: Cornelius template advertises semantic_search and skills the bundled template doesn't ship (search falls back to substring scan) #1646 Cornelius bundle: the job must fail on it (a guard that has never been shown to fail is not a guard)
• Green on the current tree
• Path-filtered so it only runs when a template or the checker changes

Related

• bug: Cornelius template advertises semantic_search and skills the bundled template doesn't ship (search falls back to substring scan) #1646 (the instance this generalizes — its unit tests are the starting point)
• trinity-enterprise#107 (auto-seeded Cornelius — why a template bug is a first-impression bug)
• trinity-enterprise#173 (Layer 0 ships the semantic stack; this check must pass unchanged when the declarations return with their files)
• services/compatibility/static_checks.py (c_x003, c_x004 — the runtime rules to lift)