Skip to content

docs: fix convergence-simplification-inventory drift and conflict marker - #3578

Merged
Sinity merged 2 commits into
masterfrom
feature/docs/convergence-inventory-drift-fix
Aug 2, 2026
Merged

docs: fix convergence-simplification-inventory drift and conflict marker#3578
Sinity merged 2 commits into
masterfrom
feature/docs/convergence-inventory-drift-fix

Conversation

@Sinity

@Sinity Sinity commented Aug 2, 2026

Copy link
Copy Markdown
Owner

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

  1. A literal unresolved diff3 merge-conflict marker (||||||| 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.
  2. Items 1 and 3 described process-pool machinery and the daemon's 64 MiB blob-limit constant as "deletable once X lands." X has now landed (the 3.14t free-threaded deploy; 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

  • Removed the conflict marker and the duplicate stale paragraph in item 5, keeping the more detailed, currently-line-numbered text that follows it.
  • Item 1 (process-pool machinery): added a status note. Only the one call site the row names (_parse_unique_retained_raws in revision_backfill.py) was retired. Three other unconditional call sites remain -- pipeline/services/ingest_batch/_core.py:1053, pipeline/services/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 pipeline/services/archive_ingest.py:279 -- none gated on parallel_threads_effective(), so the free-threaded deploy does not collapse them.
  • Item 3 (64 MiB daemon blob-limit constant): added a status note. 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 (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

@coderabbitai

coderabbitai Bot commented Aug 2, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@Sinity, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 57 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4fdcb74f-f033-4c29-873b-639c75543955

📥 Commits

Reviewing files that changed from the base of the PR and between e98811a and 76e3ddc.

📒 Files selected for processing (2)
  • .beads/issues.jsonl
  • docs/design/convergence-simplification-inventory.md
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/docs/convergence-inventory-drift-fix

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sinity added a commit that referenced this pull request Aug 2, 2026
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>
Sinity and others added 2 commits August 2, 2026 21:31
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>
@Sinity
Sinity force-pushed the feature/docs/convergence-inventory-drift-fix branch from fe6631d to 76e3ddc Compare August 2, 2026 19:31
@Sinity
Sinity merged commit b914b3d into master Aug 2, 2026
3 checks passed
@Sinity
Sinity deleted the feature/docs/convergence-inventory-drift-fix branch August 2, 2026 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant