docs: v0.2.2 overhaul — refresh every stale doc and provenance artifact#147
Conversation
Full staleness audit of every prose doc against current main. The anchors were frozen at v0.2.1 / 263 tests / "no active milestone" while 12 PRs (#135-#146) had merged and are unreleased. - Resume anchors (PROGRESS.md, HANDOFF.md): Current state / Last action / Next action / test count (263->270) brought current; the two duplicate frozen anchors and the stale macOS benchmark numbers fixed; a dated v0.2.2 log entry. - CLAUDE.md + AGENTS.md: the post-M35 roadmap-memory section now records the post-v0.2.1 hardening + perf wave (identical edit in both). - CHANGELOG.md: new [0.2.2] section (decoder enum rejection #136, network/CLI hardening #137/#140/#141/#143, real UBSan abort gate #142, ocaml diff_report #144, try_emplace ~+5% #138, index load-factor ~+18.6% #145). CMakeLists version 0.2.1 -> 0.2.2. - README: benchmark/flamegraph/limitations sections reflect the engine wins (measured on the profile workload, not the micro-bench table) and the gateway hardening; release_readiness 270/270 + UBSan gate + v0.2.2 scope. - Networking docs (socket_gateway, socket_hardening): connection cap, EINTR retry, transient-accept survival, fd-exhaustion handling, UDP send-error counting. replay_and_recovery: decode_command now rejects out-of-domain enums. binary_protocol/differential_testing/fix_protocol/SECURITY/recruiting_notes/ CONTRIBUTING: smaller accuracy updates. results/README: add the three socket artifacts. make check 270/270. Stale results/*.txt provenance digests regenerated separately. pool_backed_storage.md table follows its artifact regeneration. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The post-v0.2.1 source changes (#135-#146) left 14 results/*.txt with stale Source digests (the authoritative staleness signal per the provenance rules, not commit-hash drift). Regenerated via their make targets so each declares Dirty inputs: no against current HEAD: differential, pool_backed_storage, allocator_experiment, recovery_benchmarks, false_sharing_study, perf_stat_linux (partial PMU, QSL_PERF_ALLOW_PARTIAL), perf_report_linux, numa_affinity_study (linux-constrained), socket_load_summary, socket_profile_loopback, socket_stress_summary, dpdk_environment, nic_offload_environment. docs/pool_backed_storage.md: refreshed the median table, digest reference, and qualitative ordering from the regenerated artifact (contiguous fastest on four of five workloads; intrusive leads dense). The baseline rows now include the try_emplace (#138) and index load-factor (#145) wins. Honesty notes: these were measured on a thermally-warmed M2 from a long session, so absolute values run higher than a cool-host snapshot — the relative orderings and provenance digests are the load-bearing content, and every artifact carries a hardware/build-dependence caveat. latest.txt is regenerated separately on a cooled host to keep its headline micro-benchmark numbers representative. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…umbers latest.txt regenerated on a thermally-recovered host so the headline micro-bench numbers are representative (protocol canary 16.1 ns/op), with a fresh Source digest (Dirty inputs: no) matching current source. The README benchmark table and the PROGRESS measured-results section are aligned to it: order_book ~90, protocol ~16, gateway ~102, matching ~91, replay ~101 ns. The matching/replay rows are slightly faster than the prior committed run (the v0.2.2 engine wins showing on the resting-order paths); the order_book micro-bench is unchanged (near-empty index, so it does not exercise the load-factor win). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dpdk_environment.txt and nic_offload_environment.txt include README.md (and CLAUDE.md/AGENTS.md/results/README.md) in their digest scope, so the README number-sync re-staled them. Regenerated against the final committed docs; Dirty inputs: no. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 15 minutes and 57 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (33)
✨ 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 |
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
There was a problem hiding this comment.
No application code in the PR — skipped Code Health checks.
See analysis details in CodeScene
Quality Gate Profile: Pay Down Tech Debt
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.
* chore(release): cut v0.2.2 Finalize the v0.2.2 changelog entry to include this session's documentation overhaul (#147), performance-evidence report (#148), README rebuild (#149), and the bug/style/mermaid sweep (#150) on top of the post-v0.2.1 hardening + perf wave (#135-#146). Fix the test count (272/272) and flip the v0.2.2 resume/release anchors (PROGRESS.md, release_readiness.md) from "in preparation" to released. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs: reconcile test count to 272/272 across release records (CodeRabbit) CodeRabbit flagged docs/release_readiness.md still showing 270/270 while CHANGELOG/PROGRESS said 272/272. The two perfeval tests added this session took the count 270 -> 272, so the current-state and verification claims were stale. Updated all current-state references (release_readiness verification table, PROGRESS.md status + both summary blocks, the CLAUDE.md/AGENTS.md roadmap memory kept in sync, HANDOFF.md), and flipped the v0.2.2 "being cut / next action" phrasing to released. The one remaining 270/270 is a dated entry under PROGRESS.md "Decision log additions" (a correct historical snapshot). All em-dash-free. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
Summary
A complete staleness overhaul. Every
.md/.txtwas audited against currentmain(via a multi-agent doc audit). The resume anchors and most docs were frozen at v0.2.1 / 263 tests / "no active milestone" while 12 PRs (#135–#146) had merged and were unreleased, and 14results/*.txtprovenance artifacts had staleSource digestsafter the post-v0.2.1 source changes. This brings everything current and prepares v0.2.2.Docs
PROGRESS.md,HANDOFF.md): Current state / Last action / Next action / test count (263→270) brought current; the two duplicate frozen anchors and the stale macOS benchmark numbers fixed; a dated v0.2.2 progress entry.CLAUDE.md+AGENTS.md(verified byte-identical): the post-M35 roadmap-memory section now records the post-v0.2.1 hardening + perf wave.CHANGELOG.md: new[0.2.2]section;CMakeLists.txt0.2.1 → 0.2.2.README.md: benchmark table synced to the regeneratedlatest.txt(~90/16/102/91/101 ns); flamegraph + limitations reflect the engine wins and gateway hardening;release_readiness.md→ 270/270, UBSan gate, v0.2.2 scope.socket_gateway/socket_hardeningdocument the connection cap, EINTR retry, transient-accept survival, fd-exhaustion handling, and UDP send-error counting;replay_and_recoverynotesdecode_commandnow rejects out-of-domain enums;pool_backed_storagetable + ordering refreshed from its regenerated artifact; plusbinary_protocol,differential_testing,fix_protocol,SECURITY,recruiting_notes,CONTRIBUTING,results/README(added the three socket artifacts).Provenance artifacts
All 14
results/*.txtwith staleSource digestsregenerated via their make targets — each now declaresDirty inputs: noagainst HEAD (digest mismatch is the authoritative staleness signal, not commit-hash drift).crash_recovery_validation.txtandflamegraph.txtwere already current.latest.txtwas regenerated on a thermally-recovered host (protocol canary 16.1 ns/op) so its headline numbers stay representative; the study artifacts' load-bearing content (relative orderings + digests) holds regardless of absolute thermal state, and each carries a hardware-dependence caveat.Verification
make check270/270; all 16results/*.txtreportDirty inputs: no.CLAUDE.mdandAGENTS.mdroadmap sections byte-identical; no broken internal doc links.🤖 Generated with Claude Code