[tylercschneider]

The bug

Running event_engine:catalog broke emit.

The task scaffolds a rules file listing every catalogued event with no value:

events:
  lead_created:
  lead_converted:

Those keys made @events non-empty, so ProcessingRules#any? returned true and ProcessorResolver#routes? decided routing was active. Resolution then returned nil, and every emit raised:

EventEngine::UnroutableEventError: no processing rule for event :lead_created (pack :marketing)

So building your catalog broke your app until you filled in every rule. Worse for an app that uses only handlers and needs no processors at all — event_engine-store records every event via register_handler, and such an app could not emit anything after running the catalog task.

Introduced in #245, where the rules file was added, and missed because the tests only exercised rules with values.

The fix

any? now counts declared processor names rather than hash keys, so a key with no value is what it looks like: undecided.

Resulting semantics

rules file	emit
no file, or {}	emits; no processor invoked
every event listed, none decided	emits; no processor invoked
some decided, some not	raises on the undecided ones

"I have not wired processing yet" works. "I wired some of it and forgot one" is an error. event_engine:rules:check still reports the all-undecided case, so it stays visible without being fatal.

Verification

Suite green: 135 runs, 175 assertions, 0 failures.

Verified in the example app across both states:

all unset (fresh scaffold)  → emitted, no processor invoked
one decided, one not        → EventEngine::UnroutableEventError
rules:check (all unset)     → no processing rule routes :lead_created, :lead_converted

Note

This is a second open PR in this repo alongside #255 (a README link). Raised separately because it blocks migrating an existing app onto these gems, and #255 is documentation only.

🤖 Generated with Claude Code