Explore event-first Resource profiles as the canonical update model

[schickling-assistant]

Problem

The current Resource Profile contract resolves a Resource URI to a local carrier. Resync then emits an invalidation when that carrier changes. This state-first model is practical for the current smart-Resource design, but an event-first model may be the more principled long-term foundation.

Current st2 streams do not yet provide the guarantees needed for a canonical Resource event log: complete catch-up, durable cursors, explicit ordering, retention, gap detection and repair, and deduplication beyond the bounded receipt horizon. GitHub webhook delivery also requires an explicit recovery model.

Explore

• Define when a Resource event log, rather than a current-state projection, is canonical.
• Prototype ordering, replay, durable cursor, retention, deduplication, and gap-repair semantics.
• Compare event-first with state-first and hybrid snapshot-plus-semantic-stream models.
• Measure notification volume and agent wake/token cost under CI, review, and lifecycle event bursts.
• Determine how this composes with Resource Profiles, declared streams, resync, and supervisor lifecycle.

This issue is exploratory. The current smart-Resource design proceeds state-first until evidence supports changing the authority model.

Posted on behalf of @schickling

field	value
agent_identity	dev3.direct.omp.2cshu64q
session	dev3.2cshu64q
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.0.9
agent_runtime	OMP 18.0.9
tooling_profile	dotfiles@b607597