[Catalog] Fix description-vs-capability integrity + add a claims lint
Several published agents advertise capabilities their capabilities block does not have — the catalog makes promises the code can't keep. For a store this is an integrity issue, not polish.
Confirmed mismatches (live 2026-08-01)
- Creator OS — desc: "publishing through your own logged-in browser sessions via the local runner" — but
runtime:null, workflow:null (no browser runtime).
- QA Automation — desc: "runs them headlessly after every deploy … observable runner" — but
runtime:null, workflow:null.
- Job Application Assistant — desc references "approved local browser runner task
job.apply_basic" — verify that task type actually exists in the runner (runner declares job.apply_agent, not job.apply_basic).
Do
- For each: either wire the capability or rewrite the description to match reality. (Given the focus posture, rewriting is likely right for the aspirational ones.)
- Add a publish-time / CI lint that flags catalog copy claiming a runtime capability (browser/posting/headless/local runner/cron) when
capabilities.runtime/workflow don't back it. Keep it heuristic + overridable, but loud.
Acceptance
Part of the catalog audit.
[Catalog] Fix description-vs-capability integrity + add a claims lint
Several published agents advertise capabilities their
capabilitiesblock does not have — the catalog makes promises the code can't keep. For a store this is an integrity issue, not polish.Confirmed mismatches (live 2026-08-01)
runtime:null, workflow:null(no browser runtime).runtime:null, workflow:null.job.apply_basic" — verify that task type actually exists in the runner (runner declaresjob.apply_agent, notjob.apply_basic).Do
capabilities.runtime/workflowdon't back it. Keep it heuristic + overridable, but loud.Acceptance
Part of the catalog audit.