docs: fix convergence-simplification-inventory drift and conflict marker - #3578
Conversation
|
Warning Review limit reached
Next review available in: 57 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: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ 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 |
Both beads were doc-accuracy findings against docs/design/convergence-simplification-inventory.md: btv32 (unresolved diff3 conflict marker) and gzyqk (items 1 and 3 no longer accurately described as deletable). PR #3578 fixes both; close reasons record the exact status notes added and the verification run. Co-Authored-By: Claude <noreply@anthropic.com>
Problem: two doc-accuracy bugs found in docs/design/convergence-simplification-inventory.md during the polylogue-iiu6r "automatic path already covers this" audit. 1. A literal unresolved diff3 merge-conflict marker (`||||||| b64a074`) landed via the 268-commit squash merge 5e23e6a (#3390), sitting between two duplicate "What it is" paragraphs in item 5's history section (the newer paragraph restates the same finding with current line numbers, the marker-adjacent one is the stale ancestor text). 2. Items 1 and 3 described process-pool machinery and the daemon's 64 MiB blob-limit constant as "deletable once X lands," and X (the 3.14t free-threaded deploy, and daemon_parse_stage_split's removal) has now landed -- but re-checking the current tree shows both items remain load-bearing for reasons the doc's original text didn't anticipate. What changed: - Removed the conflict marker and the duplicate stale-ancestor paragraph in item 5, keeping the more detailed, currently-accurate text. - Item 1: added a status note recording that only the one call site the row names (_parse_unique_retained_raws in revision_backfill.py) was retired. Three other unconditional call sites remain -- ingest_batch/_core.py:1053, validation_flow.py:185 (measured Threads(24)=160MB/s vs Process(8)=605MB/s, a 3.7x win independent of the GIL/free-threaded argument), and archive_ingest.py:279 -- none gated on parallel_threads_effective(), so the free-threaded deploy does not collapse them. - Item 3: added a status note recording that raw_materialization_whale_pass_candidate (polylogue-t93b, added after this row was written) now threads _RAW_MATERIALIZATION_DAEMON_BLOB_LIMIT_BYTES through as ordinary_max_payload_bytes, the boundary distinguishing the daemon's ordinary trickle envelope from its escalation-tier whale pass -- a capability unrelated to DaemonParseStage's in-flight budget. The original design-time reasoning under each item is kept for history, with the new status notes marking it as superseded rather than deleting it, matching item 5's existing convention for documenting a failed or outdated deletion attempt in place. Verification: devtools render all --check (exit 0, no "out of sync" lines); devtools verify --quick (exit 0, all steps pass). Ref polylogue-gzyqk, polylogue-btv32 Co-Authored-By: Claude <noreply@anthropic.com>
Both beads were doc-accuracy findings against docs/design/convergence-simplification-inventory.md: btv32 (unresolved diff3 conflict marker) and gzyqk (items 1 and 3 no longer accurately described as deletable). PR #3578 fixes both; close reasons record the exact status notes added and the verification run. Co-Authored-By: Claude <noreply@anthropic.com>
fe6631d to
76e3ddc
Compare
Summary
Two doc-accuracy fixes to
docs/design/convergence-simplification-inventory.md, both surfaced by the polylogue-iiu6r "automatic path already covers this, manual surface never deleted" audit.Problem
||||||| b64a074e5) landed in item 5's history section via the 268-commit squash merge 5e23e6a (feat(archive): index v46 wire-evidence batch, free-threaded-only runtime, parse-failure recovery #3390) -- a duplicate, stale-ancestor "What it is" paragraph sat between the marker and the rest of the section.daemon_parse_stage_split's removal), but re-checking the current tree shows both items remain load-bearing for reasons the original text didn't anticipate.Solution
_parse_unique_retained_rawsinrevision_backfill.py) was retired. Three other unconditional call sites remain --pipeline/services/ingest_batch/_core.py:1053,pipeline/services/validation_flow.py:185(measuredThreads(24)=160MB/svsProcess(8)=605MB/s, a 3.7x win independent of the GIL/free-threaded argument), andpipeline/services/archive_ingest.py:279-- none gated onparallel_threads_effective(), so the free-threaded deploy does not collapse them.raw_materialization_whale_pass_candidate(polylogue-t93b, added after this row was written) now threads_RAW_MATERIALIZATION_DAEMON_BLOB_LIMIT_BYTESthrough asordinary_max_payload_bytes, the boundary distinguishing the daemon's ordinary trickle envelope from its escalation-tier whale pass -- a capability unrelated toDaemonParseStage's in-flight budget.The original design-time reasoning under each item is kept for history (matching item 5's existing convention for documenting a superseded/failed deletion attempt in place), with new status notes marking it stale rather than deleting it.
Verification
devtools render all --check-- exit 0, no "out of sync" lines.devtools verify --quick-- exit 0, all 19 steps pass (also ran automatically via the pre-push hook).Ref polylogue-gzyqk, polylogue-btv32