Gap
@dsh-std/session already states that durable SessionEvent declarations are not a global event bus and that runtime observation/interception belongs to @dsh-std/events, but there is currently no packages/events implementation or adapter mapping.
That blocks a common class of otherwise-portable observer plugins: failure aggregation, deterministic postmortems, verification receipts, passive telemetry/redaction, and similar components that react to already-recorded runtime/session events without owning the producer.
Minimal first scope
A first version only needs read-only observation; interception/mutation can stay out of scope until there is a concrete use case.
Useful properties:
- a versioned EventObserver protocol coordinate;
- explicit subscription scope / event-type filtering rather than a global catch-all;
- validated immutable event envelopes with source/provenance and sequence/correlation fields;
- an explicit permission for observation;
- activation-instance ownership and automatic unsubscribe on unload;
- no assumption that observing an event grants permission to append or mutate durable session history;
- no requirement to expose raw prompts/tool payloads when a host policy only permits redacted/projected events.
DSH adapter use case
For @dsh-std/adapter-dsh, the adapter could project selected existing DSH Session/tool lifecycle events into this observer surface while keeping DSH's native event log as the source of truth.
This would allow plugins such as recurring-failure collectors or deterministic postmortem analyzers to stop importing Cordis / @deepseek-ai/dsh-session solely to subscribe to events. Components that need to declare their own durable event types would continue to use @dsh-std/session; observation and event-type ownership remain separate concerns.
Gap
@dsh-std/sessionalready states that durableSessionEventdeclarations are not a global event bus and that runtime observation/interception belongs to@dsh-std/events, but there is currently nopackages/eventsimplementation or adapter mapping.That blocks a common class of otherwise-portable observer plugins: failure aggregation, deterministic postmortems, verification receipts, passive telemetry/redaction, and similar components that react to already-recorded runtime/session events without owning the producer.
Minimal first scope
A first version only needs read-only observation; interception/mutation can stay out of scope until there is a concrete use case.
Useful properties:
DSH adapter use case
For
@dsh-std/adapter-dsh, the adapter could project selected existing DSH Session/tool lifecycle events into this observer surface while keeping DSH's native event log as the source of truth.This would allow plugins such as recurring-failure collectors or deterministic postmortem analyzers to stop importing Cordis /
@deepseek-ai/dsh-sessionsolely to subscribe to events. Components that need to declare their own durable event types would continue to use@dsh-std/session; observation and event-type ownership remain separate concerns.