TL;DR for whoever picks this up
Catalog drift is ALREADY enforced in CI — do not add new enforcement. This is a pure developer-experience polish: make the existing drift failure tell you what to do instead of dumping an opaque object diff.
Background
The known-trigger catalog (packages/core/src/triggers/catalog.generated.{ts,json} + adapters-without-known-triggers.generated.json) is a committed, hand-regenerated artifact. You update it by running:
adapter-core triggers generate
There is no GitHub Action that auto-generates or commits it (verified: ci.yml is just npm ci → turbo build → turbo typecheck → npm test; the only git commit/push in workflows is the release bump in publish.yml).
Drift is nonetheless caught today, because packages/core/tests/triggers/catalog-generator.test.ts re-derives the catalog from the live adapters and asserts the committed files match:
test("generated trigger catalog is in sync with adapter supportedEvents", …)
const generation = await generateTriggerCatalog(repoRoot);
assert.deepEqual(catalogJson, generation.catalog);
assert.equal(catalogTs, renderTriggerCatalogModule(generation));
That test runs in CI via npm test (Build & Test). So if someone changes an adapter's supportedEvents()/mapping.yaml and forgets to regenerate, the build is already red and the PR can't merge. The CLI also has adapter-core triggers check (packages/core/src/cli.ts, case "check") which does the same comparison.
The actual problem (the only thing to fix)
When the catalog is stale, the failure surfaces as a raw assert.deepEqual mismatch — a wall of object diff that doesn't tell a contributor the fix is to run adapter-core triggers generate and commit. New contributors waste time on it.
Proposed solution (pick one)
- Preferred: improve
catalog-generator.test.ts so a mismatch throws a message like: Trigger catalog is out of date. Run \adapter-core triggers generate` and commit the updated catalog.generated.{ts,json}.` (keep the deep-equal as the check, just wrap the assertion with an actionable message.)
- Or: add an explicit
- run: npx adapter-core triggers check step to ci.yml before the test step — the check subcommand already prints a structured summary and can be given a clear failure message.
Either is fine; do not add both, and do not introduce a second source of truth or auto-commit bot.
Acceptance criteria
- Intentionally make an adapter's events drift locally (or add a fake event), run the relevant check, and confirm the failure message names the exact remedy command and files.
npm test / Build & Test still green when the catalog is in sync.
- No new redundant enforcement layer; no auto-generation/commit-back added.
Files
packages/core/tests/triggers/catalog-generator.test.ts (the existing drift assertion)
packages/core/src/triggers/catalog-generator.ts (generateTriggerCatalog, renderTriggerCatalogModule, writeTriggerCatalog({check}))
packages/core/src/cli.ts (triggers generate / triggers check)
.github/workflows/ci.yml
Related: #115 (missing adapter event coverage).
🤖 Generated with Claude Code
TL;DR for whoever picks this up
Catalog drift is ALREADY enforced in CI — do not add new enforcement. This is a pure developer-experience polish: make the existing drift failure tell you what to do instead of dumping an opaque object diff.
Background
The known-trigger catalog (
packages/core/src/triggers/catalog.generated.{ts,json}+adapters-without-known-triggers.generated.json) is a committed, hand-regenerated artifact. You update it by running:There is no GitHub Action that auto-generates or commits it (verified:
ci.ymlis justnpm ci→turbo build→turbo typecheck→npm test; the onlygit commit/pushin workflows is the release bump inpublish.yml).Drift is nonetheless caught today, because
packages/core/tests/triggers/catalog-generator.test.tsre-derives the catalog from the live adapters and asserts the committed files match:That test runs in CI via
npm test(Build & Test). So if someone changes an adapter'ssupportedEvents()/mapping.yamland forgets to regenerate, the build is already red and the PR can't merge. The CLI also hasadapter-core triggers check(packages/core/src/cli.ts,case "check") which does the same comparison.The actual problem (the only thing to fix)
When the catalog is stale, the failure surfaces as a raw
assert.deepEqualmismatch — a wall of object diff that doesn't tell a contributor the fix is to runadapter-core triggers generateand commit. New contributors waste time on it.Proposed solution (pick one)
catalog-generator.test.tsso a mismatch throws a message like:Trigger catalog is out of date. Run \adapter-core triggers generate` and commit the updated catalog.generated.{ts,json}.` (keep the deep-equal as the check, just wrap the assertion with an actionable message.)- run: npx adapter-core triggers checkstep toci.ymlbefore the test step — thechecksubcommand already prints a structured summary and can be given a clear failure message.Either is fine; do not add both, and do not introduce a second source of truth or auto-commit bot.
Acceptance criteria
npm test/Build & Teststill green when the catalog is in sync.Files
packages/core/tests/triggers/catalog-generator.test.ts(the existing drift assertion)packages/core/src/triggers/catalog-generator.ts(generateTriggerCatalog,renderTriggerCatalogModule,writeTriggerCatalog({check}))packages/core/src/cli.ts(triggers generate/triggers check).github/workflows/ci.ymlRelated: #115 (missing adapter event coverage).
🤖 Generated with Claude Code