Spike: can skill-emitted events drive a trustworthy live fleet view?

[williamthorsen]

Question

Are skill-emitted lifecycle events dense and reliable enough to drive a live, trustworthy fleet view across concurrent sessions under both harnesses? Skill-side emission is proven at artifact granularity, but live status needs mid-flow events, and a fleet view that shows stale or wrong status gets abandoned. This is the one bet in #984 that reading cannot settle.

Context

#984 has settled the design this spike exercises: workstream lanes keyed by repo × branch ref with session sub-attribution; a self-identifying event envelope with a session-lifecycle payload family; filesystem-first storage (append-only JSONL per session under a per-lane directory) with a watch-fold-SSE server. The Rovo leg matters most: skill emission is the only compliant event channel there, with no fallback.

Scope

Explore: a first-cut envelope (fixed envelope fields, nested per-family payload) and session-lifecycle vocabulary; an emit helper accepting --session (env var under Claude; under Rovo, fetched once per skill run via the get_session_metadata built-in and reused in-context); three instrumented high-traffic skills (review-branch, respond-to-review, create-pr); the events root; a minimal watch-fold-SSE server with a crude lane view; then an observation window of normal multi-session work, including two sessions in one worktree and a mixed-harness lane.

The emit helper and skill instrumentation are production-track and merge to main, so the observation window rides normal installs on both machines. The server and lane view are throwaway, and the lane view must be usable from the first day of observation.

Not: any pane (artifacts, findings, prompts), git/forge adapters, transcript readers, proposal/selection events, or UI polish. Throwaway code is acceptable for the server and lane view; findings are the deliverable.

Timebox

Build ≤ 2 days; observation ≈ 1 week of normal multi-session work.

Acceptance criteria

Questions to answer

• Do emission points occur densely enough that each lane's derived status tracks reality closely enough to trust during normal concurrent work?
• Does session stamping hold under both harnesses, including two concurrent sessions in one worktree and a mixed-harness lane?
• Does append-JSONL → fs-notify → incremental fold → SSE stay live and low-latency with 3–6 concurrent sessions?
• What can a Rovo skill actually emit in practice, and do the get_session_metadata fetch-once relay and in-context reuse hold up?
• Where are the status gaps that require new emission points rather than polling?

Decisions to enable

• Go/no-go on building the Build a harness-agnostic app for cross-session visibility into the ticket lifecycle #984 app on the skill-event channel as designed.
• Confirm or revise the envelope and session-lifecycle vocabulary before the production schema is written.
• Choose which skills are instrumented first in the production rollout.

Deliverable: a findings & recommendation artifact.

[williamthorsen]

Deployment edge for emit-event (from #986)

The emit-event helper is now built and installable, but it will not deploy to a machine on the strength of the Bash invocation alone.

Deployment membership is computed from two edge sources: {skill:<slug>} invocation tokens in a skill's body, and an explicit dependencies: frontmatter block. An instrumented skill calls the helper through a raw node {harness_home_dir}/skills/emit-event/emit-event.mjs line, which is neither — so it produces no edge, the helper is left out of the resolved closure, and every emission silently no-ops against a missing bundle.

Each instrumented skill must therefore declare the dependency explicitly:

dependencies:
  skills:
    - emit-event

This is the same shape capture-feedback gets for free, because its body carries a {skill:capture-event} token; a helper invoked only by path gets nothing. No change to the recommended collection is needed — the transitive closure pulls emit-event in as soon as one skill inside it declares the dependency.

[williamthorsen]

Step 1 findings: Rovo session-id relay

Verdict: the relay holds as designed. Verified with the re-runnable diagnostic kit (diagnostics/rovo-session-identity/): headless, interactive, and embedded-in-real-work runs all pass, including on-demand checkpoint probes late in a real session.

• Shape: get_session_metadata returns { session_id, title, workspace_path, fork }; the id is read from session_id.
• Stability: the id is constant for the session's lifetime, and a late re-fetch returns the same id — so "re-fetch when uncertain" is a safe repair strategy layered on fetch-once.
• Reuse: the agent restated the fetched id verbatim in shell commands across interleaved real work.
• Distinctness: concurrent sessions receive unique ids; no collisions across interleaved runs.
• Fork: fork was null in observed responses; forked-session id semantics remain unprobed (the kit's fork variant covers this if forking becomes relevant).

Two operational findings beyond the relay itself:

• Permission gate: get_session_metadata is permission-gated. A headless run without the tool allowlisted (or a --yolo-style flag) hard-fails (Tool 'get_session_metadata' exceeded max retries count of 1) rather than degrading. The emit helper's never-block contract cannot cover harness-level tool denial, so the allowlist/flag is part of the Rovo-side install story.
• Emission discipline depends on instruction placement: under ad-hoc conversational instructions, the agent twice skipped an emit placed after presenting a prompt (end of turn) and self-corrected to start-of-turn emission; under the diagnostic's located, ordered instructions, pre-ask emission passed consistently. The shipped instrumentation already places input.requested at or before the ask, which these results support. Watch skill.completed during observation for the same end-of-turn exposure.

Consequence for the observation window: the Rovo leg enters it with no unresolved platform unknowns; remaining questions (density, latency, gaps, Claude-side stamping) are what the week itself measures.