docs: event vocabulary freeze + operator runbook + simulate happy-path - #195
Conversation
Closes the three remaining docs deliverables from the operator workload:
- docs/events.md — the frozen event vocabulary: all 7 coarse-feed kinds
with required fields (incl. the reorg enrichment and shadowDivergence),
the WS channel table (live vs channel_unavailable, terminal tx:/box:
semantics), seq/resume/backfill semantics (8192 window, 1024 resume
cap, truncated => resync, exactly-once seam), and transport limits.
Additions stay backward-compatible; renames/removals are breaking.
- operating.md runbook — symptom → decisive-metrics table ("it looks
stuck": apply-phase gauges, rejection loop vs download starvation,
isolation, shadow, wedge, mempool), the B5 "no false stall signal
without a companion gauge" promise made queryable.
- operating.md dry-run section — transactions/simulate is THE path for
whole-tx validation; script/* is the contract-dev playground (E:
discoverability, not new surface).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BUh2DBnAPqThdYFZW5D8wx
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds documentation for operator event APIs and WebSocket delivery semantics, plus runbook guidance for transaction simulation and diagnosing stalled or divergent operation. ChangesOperator documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/events.md`:
- Around line 69-73: Update the heartbeat description in the events
documentation to specify the exact client response frame required by the
protocol, and state that the client must send it within the server’s idle window
of roughly two heartbeat intervals (about 30 seconds) to keep the socket open.
- Around line 10-15: Clarify the sentence beginning “Both derive from the same
snapshot differ” to explicitly identify the REST ring and WebSocket bus as
deriving from the same snapshot-diff producer chain, preserving the existing
statement that consumers can poll to catch up and subscribe to stay current
without contradictory histories.
In `@docs/operating.md`:
- Around line 432-445: The runbook introduction incorrectly limits all decisive
signals to GET /metrics. Update the introductory description above the symptom
table to state that operators should use both Prometheus metrics and JSON status
endpoints, while preserving the existing metric and endpoint references in the
table.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 5ed1d9f1-97cd-426f-a33f-886d57bf4ee2
📒 Files selected for processing (2)
docs/events.mddocs/operating.md
…ain wording, runbook signal sources
- events.md states the precise keepalive contract from the code: server
heartbeat every 15 s, client must produce some inbound within the 2x
idle window (~30 s) — protocol {"op":"ping"} or WS-level ping/pong
both count — else idle_timeout close.
- The REST-ring/WS-bus relationship names the shared snapshot-diff
producer chain explicitly.
- Runbook intro says metrics AND JSON status endpoints (the table
already referenced both).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BUh2DBnAPqThdYFZW5D8wx
Bump workspace version to 0.5.2 and promote the changelog: the complete v1 product API (#168-#185, #188), shadow validation as a production mode (#193-#195), the operator observability wave (#187, #190, #192, #194), two live accept-invalid consensus fixes (#176, #179), ErgoScript compiler byte-parity completion (#165-#167, #175), and the #160-#163 sync/recovery fixes. Full workspace gate run on the merge result. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BUh2DBnAPqThdYFZW5D8wx
What
The three remaining documentation deliverables from the operator workload (A2-freeze, B5, E):
docs/events.md— the event vocabulary, frozen. Every coarse-feed kind (blockApplied→shadowDivergence) with its fields, the WS channel table (live vschannel_unavailable, terminaltx:/box:semantics), seq/resume/backfill semantics (8192-event window, 1024 resume cap, truncated ⇒resync, exactly-once across the replay/live seam), and transport limits. Compatibility contract stated: additive changes only.operating.md): a symptom → decisive-metrics table for "it looks stuck" — apply-in-progress vs rejection-loop vs download-starvation vs isolation vs shadow-divergence vs wedge, each resolvable from/metrics+ one status field. This makes the B-workstream promise ("no false stall signal without a companion gauge") operationally queryable.operating.md):transactions/simulateis THE whole-tx validation path;script/*is the contract-developer playground. Discoverability fix only — no new surface.Docs-only PR; facts cross-checked against the code (channel liveness from
RealtimeBus::blocks_and_mempool, caps fromRESUME_WINDOW/RESUME_MAX/MAX_MESSAGE_BYTES, event names from the model builders).🤖 Generated with Claude Code
https://claude.ai/code/session_01BUh2DBnAPqThdYFZW5D8wx
Summary by CodeRabbit