chore(beads): close satisfied merged implementation work - #3912
Conversation
|
Warning Review limit reached
Next review available in: 13 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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 (1)
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad90d6badc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {"_type":"issue","id":"polylogue-qhk8z","title":"PR #3574 duplicate-chain links trip the pre-existing ActiveByteRevisionChainError membership-census guard","description":"Discovered during polylogue-id4n's fresh triage pass. 2 tests fail:\n\n- tests/unit/sources/test_revision_backfill.py::test_backfill_content_cache_across_pages_reduces_parses_and_matches_uncached_archive\n- tests/unit/storage/test_rebuild_paging_content_order.py::test_rebuild_content_order_paging_dedups_first_time_classification_via_content_cache\n\nBoth fail with:\n\n polylogue.storage.sqlite.archive_tiers.revision_governance.ActiveByteRevisionChainError:\n an active byte-revision chain cannot move to membership governance\n\nRoot cause: a genuine cross-feature interaction between two independent,\nindividually-correct changes.\n\n1. PR #3574 (fix(storage): collapse byte-equal duplicates before revision-chain\n proof) added a \"duplicate\" relation to HistoricalRevisionDecision: two\n byte-identical raws (same content, different acquisition path -- the ordinary\n \"re-exported the same conversation\" shape both failing tests construct)\n now get one classified as representative and the other linked to it via\n predecessor_raw_id/baseline_raw_id, mirroring the representative's verdict.\n This is correct and intentional (fixes 50GB of over-quarantined content on\n the live archive).\n\n2. The pre-existing (#3406, long-standing) membership-census guard in\n revision_governance.py's _replace_full_revision_governance requires that a\n raw being promoted to membership governance have NO other raw pointing at\n it via predecessor_raw_id/baseline_raw_id (\"an active byte-revision chain\n cannot move to membership governance\") -- this guard was written assuming\n only genuine incremental append chains create such links.\n\n#3574 now also creates predecessor/baseline links for the DUPLICATE case, which\nthe membership-census guard was never designed to distinguish from a genuine\nin-progress append chain. A backfill that re-parses a raw touched by this\nguard after #3574's dedup linking now hits ActiveByteRevisionChainError where\nit previously succeeded.\n\nConfirmed via git log -S \"ActiveByteRevisionChainError\" that the guard's own\ncode is unchanged since #3406 -- the trigger is #3574's newly-created links,\nnot the guard itself. Confirmed via git show 31614661f that #3574's own\nverification section did not exercise this specific backfill-then-membership-\ncensus interaction (it ran tests/unit/storage/test_raw_revision_authority.py\nand a `-k \"raw_revision or revision_governance or raw_authority\"` selection,\nwhich apparently does not include these two files).\n\nNeeds design judgment: should the membership-census guard learn to\ndistinguish \"duplicate\" relation links (safe to promote past) from genuine\nincremental chain links (unsafe), or should #3574's duplicate-linking be\nscoped to skip cohorts that would trip this guard? Not attempted as a quick\nfix given the sensitivity of this subsystem (raw-authority correctness,\nquarantine-as-absorbing-state history) -- reproduction is solid, fix\ndirection needs an operator/maintainer decision.\n\nReproduction: devtools test tests/unit/sources/test_revision_backfill.py::test_backfill_content_cache_across_pages_reduces_parses_and_matches_uncached_archive tests/unit/storage/test_rebuild_paging_content_order.py::test_rebuild_content_order_paging_dedups_first_time_classification_via_content_cache","status":"closed","priority":1,"issue_type":"bug","owner":"ezo.dev@gmail.com","created_at":"2026-08-03T00:08:35Z","created_by":"Sinity","updated_at":"2026-08-03T10:30:25Z","closed_at":"2026-08-03T10:30:25Z","close_reason":"Fixed: PR #3616 (exclude byte-identical duplicates from revision baseline tie-break). Both named regression tests pass.","dependency_count":0,"dependent_count":1,"comment_count":0} | ||
| {"_type":"issue","id":"polylogue-t73c2","title":"Fix the dogfood loop: polylogue's own archive can't answer 'what did agents do' questions","description":"Polylogue's whole thesis is that the archive answers 'what did agents do'. The fanout-operations report (2026-08-02) had to grep 700MB of raw session/subagent JSONL by hand because polylogue itself could not answer these questions: live index.db is at schema v46 with v53 code deployed, recent days of sessions are not ingested, and the daemon has been deliberately held off mid-merge-train.\n\nThis is the SAME root cause as polylogue-9qnzy (P0, schema-currency gap blocking the planned reindex) -- not a separate bug, a direct consequence of it. This bead exists to make explicit the SECOND reason 9qnzy matters: it's not just blocking a planned reindex, it's actively preventing polylogue from dogfooding its own coordination data right now.\n\nOnce 9qnzy resolves and the reindex/daemon-restart sequence completes: make the coordinator dashboard (output-token ratio, dispatch counts, per-lane outcomes, model distribution) a standing polylogue query instead of a bespoke mining pass every time someone wants to know how a fanout session went. Depends on polylogue-9qnzy.","status":"open","priority":1,"issue_type":"task","owner":"ezo.dev@gmail.com","created_at":"2026-08-02T23:40:08Z","created_by":"Sinity","updated_at":"2026-08-02T23:40:08Z","dependencies":[{"issue_id":"polylogue-t73c2","depends_on_id":"polylogue-3bsrp","type":"relates-to","created_at":"2026-08-03T07:01:30Z","created_by":"Sinity","metadata":"{}"},{"issue_id":"polylogue-t73c2","depends_on_id":"polylogue-9qnzy","type":"blocks","created_at":"2026-08-03T01:40:20Z","created_by":"Sinity","metadata":"{}"},{"issue_id":"polylogue-t73c2","depends_on_id":"polylogue-ltfj9","type":"parent-child","created_at":"2026-08-03T01:40:09Z","created_by":"Sinity","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} | ||
| {"_type":"issue","id":"polylogue-tw4ar","title":"Raw-authority verdict: persist a cache table + wire daemon convergence (Phase 2 follow-up)","description":"Follow-up from polylogue-w6hql (PR #3593): project_raw_authority_verdicts (polylogue/storage/raw_authority_verdict_projection.py) currently recomputes verdicts on demand by re-running classify_historical_full_revision_streams against live blob storage every call -- correct but not cheap at scale (761K+ census_plans-era cohort sizes). This bead is to design and land a persisted raw_authority_verdicts cache table (additive migration, numbered under storage/sqlite/migrations/source/) plus wiring into DaemonConverger so the cache tracks new/reclassified cohorts without a full rescan each read. Needed before polylogue-ds4b4 item 4 (blob-GC invariant verification) can cheaply check verdicts at scale rather than via the on-demand read path.","design":"DESIGN (2026-08-03): remaining half only — the cache table + invalidation shipped in PR #3628 (migration 024). Build the DaemonConverger warm-keeping stage: a ConvergenceStage in daemon/convergence_stages.py with check (are there cohorts whose logical_source_key changed since their cached cohort_fingerprint, or never-cached cohorts?) and execute (recompute via project_raw_authority_verdicts and upsert the cache in bounded batches). Use false_means_pending to push remaining backlog into convergence_debt rather than blocking; main process is the sole writer — no worker-process computation of the byte-proof classifier. Invalidation is already content-keyed (cohort_fingerprint over (raw_id, revision_kind, blob_hash) rows, storage/raw_authority_verdict_cache.py) — the stage only needs to FIND stale/missing cohorts cheaply (e.g. join raw_sessions cohort fingerprints against cache rows), never trust elapsed time. Pitfall: append-kind cohorts raise NotImplementedError in the projection — the stage must skip them typed-visibly (count reported), not crash, until w6hql stage-3 extends coverage. Consumer readiness: ds4b4 item 4 reads through the cache once this stage keeps it warm.\n","acceptance_criteria":"1. A DaemonConverger stage exists (daemon/convergence_stages.py) that finds never-cached and fingerprint-stale cohorts and upserts raw_authority_verdicts in bounded batches, deferring backlog via false_means_pending; unit test through the real stage interface.\n2. Append-kind cohorts are skipped typed-visibly (reported count), not crashed on, until w6hql extends coverage.\n3. A repeated read (e.g. ds4b4-style GC invariant check) hits the cache (no classify_historical_full_revision_streams recompute) — proven by a test asserting call counts or receipts.\n4. Cache staleness is content-keyed only (cohort_fingerprint); no time-based trust. Verify: devtools test -k verdict_cache; devtools test -k convergence.","notes":"2026-08-03: PR #3628 shipped the persisted raw_authority_verdicts cache table + cohort-fingerprint invalidation (SOURCE_SCHEMA_VERSION 24, migration 024). Remaining scope: wiring a DaemonConverger stage to keep the cache warm proactively -- deliberately deferred per that PR's own body. Bead stays open for that remaining half.","status":"open","priority":1,"issue_type":"task","owner":"ezo.dev@gmail.com","created_at":"2026-08-02T22:08:58Z","created_by":"Sinity","updated_at":"2026-08-03T11:09:58Z","dependencies":[{"issue_id":"polylogue-tw4ar","depends_on_id":"polylogue-fbkr","type":"discovered-from","created_at":"2026-08-10T00:18:54Z","created_by":"Sinity","metadata":"{}"}],"dependency_count":0,"dependent_count":3,"comment_count":0} | ||
| {"_type":"issue","id":"polylogue-tw4ar","title":"Raw-authority verdict: persist a cache table + wire daemon convergence (Phase 2 follow-up)","description":"Follow-up from polylogue-w6hql (PR #3593): project_raw_authority_verdicts (polylogue/storage/raw_authority_verdict_projection.py) currently recomputes verdicts on demand by re-running classify_historical_full_revision_streams against live blob storage every call -- correct but not cheap at scale (761K+ census_plans-era cohort sizes). This bead is to design and land a persisted raw_authority_verdicts cache table (additive migration, numbered under storage/sqlite/migrations/source/) plus wiring into DaemonConverger so the cache tracks new/reclassified cohorts without a full rescan each read. Needed before polylogue-ds4b4 item 4 (blob-GC invariant verification) can cheaply check verdicts at scale rather than via the on-demand read path.","design":"DESIGN (2026-08-03): remaining half only — the cache table + invalidation shipped in PR #3628 (migration 024). Build the DaemonConverger warm-keeping stage: a ConvergenceStage in daemon/convergence_stages.py with check (are there cohorts whose logical_source_key changed since their cached cohort_fingerprint, or never-cached cohorts?) and execute (recompute via project_raw_authority_verdicts and upsert the cache in bounded batches). Use false_means_pending to push remaining backlog into convergence_debt rather than blocking; main process is the sole writer — no worker-process computation of the byte-proof classifier. Invalidation is already content-keyed (cohort_fingerprint over (raw_id, revision_kind, blob_hash) rows, storage/raw_authority_verdict_cache.py) — the stage only needs to FIND stale/missing cohorts cheaply (e.g. join raw_sessions cohort fingerprints against cache rows), never trust elapsed time. Pitfall: append-kind cohorts raise NotImplementedError in the projection — the stage must skip them typed-visibly (count reported), not crash, until w6hql stage-3 extends coverage. Consumer readiness: ds4b4 item 4 reads through the cache once this stage keeps it warm.\n","acceptance_criteria":"1. A DaemonConverger stage exists (daemon/convergence_stages.py) that finds never-cached and fingerprint-stale cohorts and upserts raw_authority_verdicts in bounded batches, deferring backlog via false_means_pending; unit test through the real stage interface.\n2. Append-kind cohorts are skipped typed-visibly (reported count), not crashed on, until w6hql extends coverage.\n3. A repeated read (e.g. ds4b4-style GC invariant check) hits the cache (no classify_historical_full_revision_streams recompute) — proven by a test asserting call counts or receipts.\n4. Cache staleness is content-keyed only (cohort_fingerprint); no time-based trust. Verify: devtools test -k verdict_cache; devtools test -k convergence.","notes":"2026-08-03: PR #3628 shipped the persisted raw_authority_verdicts cache table + cohort-fingerprint invalidation (SOURCE_SCHEMA_VERSION 24, migration 024). Remaining scope: wiring a DaemonConverger stage to keep the cache warm proactively -- deliberately deferred per that PR's own body. Bead stays open for that remaining half.","status":"open","priority":1,"issue_type":"task","owner":"ezo.dev@gmail.com","created_at":"2026-08-02T22:08:58Z","created_by":"Sinity","updated_at":"2026-08-03T11:09:58Z","dependency_count":0,"dependent_count":3,"comment_count":0} |
There was a problem hiding this comment.
Restore the successor's discovered-from edge
This unrelated export change removes polylogue-tw4ar's discovered-from:polylogue-fbkr relationship even though the immediately preceding #3908 commit explicitly records tw4ar as a remaining successor of the still-in-progress fbkr; when this JSONL becomes the tracker sync surface, that provenance is lost and future reconciliation can omit the outstanding follow-up. Preserve this dependency while closing the two unrelated beads.
AGENTS.md reference: AGENTS.md:L288-L299
Useful? React with 👍 / 👎.
Summary
Close two implementation Beads whose acceptance contracts are satisfied by merged PRs #3909 and #3911.
Problem
The tracker still reported completed implementation obligations as open, obscuring the remaining production and candidate-phase work.
Solution
Close
polylogue-mupq0with evidence from #3909 andpolylogue-1mfxhwith evidence from #3911. Downstream live-apply, canary, source-index, and production convergence successors remain open.Verification
bd show polylogue-mupq0 --jsonandbd show polylogue-1mfxh --jsonreportstatus=closedwith evidence-bearing reasons.bd export -o .beads/issues.jsonl