feat(spec,schemas): declare a publisher's event types in the manifest

[ucekmez]

Summary

PR 14 of a stacked series. Base is #105. Not for merge without review.

eep-manifest.json has 24 properties and none of them says what the publisher emits.

An agent could discover that a publisher speaks EEP and where its endpoints are, but not what it will send — so it had to read human documentation, or subscribe to a wildcard and find out empirically. For a protocol whose premise is autonomous agents following entities over time, that is the wrong shape.

Nothing existing filled the gap:

• §9's "standard event catalog" is a table in this document — not fetchable, not versioned per publisher, not machine-readable.
• capabilities_query_url (§12.4) covers gated capabilities, not event types.
• The envelope's eep_known_event_types puts a discovery concern on the per-event hot path — wrong layer.

What changed

{
  "event_types": [
    {
      "type": "com.example.entity.updated",
      "description": "A field on the entity profile changed.",
      "dataschema": "https://example.com/schemas/entity.updated/v2.json",
      "since": "0.1"
    },
    { "type": "com.example.trust.changed", "deprecated": true }
  ]
}

• event_types — type required (§8 reverse-DNS pattern), plus optional description, dataschema, since, deprecated.
• event_catalog_url for publishers whose catalog is too large or volatile to inline, paginated like §12.4.
• New §12.3.2 with a rule worth stating explicitly: declaring a type is not a promise to emit it, omitting one is not a promise never to, and subscribers MUST tolerate an undeclared type rather than rejecting the delivery. A catalog is discovery metadata, not a wire constraint — without that sentence, a strict implementer would reasonably start dropping valid events.
• dataschema here SHOULD match the dataschema attribute set on the events themselves (feat(spec,schemas): adopt the CloudEvents attributes EEP had skipped #100, §7.1), so the payload contract is both discoverable and carried with each event.
• @eep-dev/middleware publishes its configured eventTypes in the manifest.

Scope

• Spec / schema only
• TypeScript package(s)
• Python package(s)
• Tests / CI
• Docs / examples

Checklist

• I read CONTRIBUTING.md and CODE_OF_CONDUCT.md.
• Tests added or updated where appropriate.
• Breaking change? No. Both fields are optional; existing manifests stay valid.
• Documentation updated for user-visible behavior.

Verification

Suite	Result
@eep-dev/middleware	189 passed (was 186)
tests/	189 passed
compliance-cli --fixtures	24 vectors, 0 failed
tests/cross-impl/test_conformance_fixtures.py	26 passed
codegen-schema-types --check	no drift

Notes for reviewers

One test exists because the feature can backfire. The middleware maps its configured eventTypes straight into the manifest — so a publisher configured with an event type that violates §8's reverse-DNS pattern would emit a manifest that fails whole-document schema validation (added in #95). That is a worse outcome than having no catalog at all. There's a test pinning that emitted types match the pattern, and a negative conformance vector (Com.Example.Entity.Updated) pinning that the schema rejects a bad one.

eep_known_event_types is left in place. It is arguably now redundant with the manifest catalog, but removing an envelope attribute is a breaking change and belongs in its own discussion.

No Python middleware parity for the manifest change — flagging rather than skipping silently.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.