The Telegram bot and CLI self-status are now fully pmv2-native: the v1 “consensus alignment” view per operator position was replaced with a pmv2 cohort-overlap view, and the LAST v1 consensus code was deleted from the codebase. Shipped 2026-06-03 on main as commit ec75491 (net −156 lines). This is the final code-side step of the v1 decommission.
For Agents
- Old behavior:
/wallets(bot) + CLIself-statusshowed per-position v1 consensus alignment, reading frozen v1 tablespm_selected_wallets/pm_safe_bets/pm_trader_metrics.- New behavior: per position, how many edge-cohort traders hold the same
(condition_id, outcome_index)plus the conviction-weightedbet_score, reusing the bet-link scoring path.- New type
CohortOverlap+overlap_by_position()inpmv2/scoring.rs;cohort_holders_for_conditions()inpmv2/repo.rs(mirrorsload_bet_holders, batchedWHERE condition_id = ANY($1)).- Shared helper
fetch_self_overlap_sectionsfeeds BOTH bot and CLI (DRY). Best-effort: a lookup error degrades to “no overlap”, never fails the command.- Render:
render_overlap_cell(Telegram) + a plain-text CLI cell.- v1 prod tables left DORMANT in DB (not dropped) per standing “don’t drop pm_* prod tables” rule.
What Changed (commit ec75491)
Replaced — v1 consensus view → pmv2 cohort overlap
/wallets(bot) and CLIself-statuspreviously rendered a v1 “consensus alignment” per operator position, reading the frozen v1 tables.- Now they render a pmv2 cohort-overlap view: for each operator position, how many edge-cohort traders hold the same
(condition_id, outcome_index), weighted by the convictionbet_score(reuses the existing bet-link scoring path — no parallel scoring logic).
Added
CohortOverlaptype +overlap_by_position()inpmv2/scoring.rs.cohort_holders_for_conditions()inpmv2/repo.rs— mirrorsload_bet_holders, batched viaWHERE condition_id = ANY($1).fetch_self_overlap_sections— single shared helper feeding bot and CLI (DRY). Best-effort by design: a lookup error degrades gracefully to “no overlap” and never fails the command.render_overlap_cell(Telegram) + a plain-text CLI cell.
Deleted — the entire v1 consensus chain (−156 net lines)
ConsensusAlignmentfetch_consensus_alignmentclassify_consensusfetch_safe_bets_by_marketfetch_raw_watched_consensus- the alignment render helpers
grep confirms zero live consensus references remain.
Code-only, DB untouched
pm_selected_wallets/pm_safe_bets/pm_trader_metricsleft dormant (not dropped), per the standing rule.
v1 Decommission — Overall State
With ec75491, v1 is fully removed from CODE. The removal happened in three stages:
- Earlier hard-cut — removed the pipeline / pm-arb / consensus engine.
- first-mover-overlap-watcher (commit
4794a76) — removedchange_detection/participant_changes. - This commit (
ec75491) — removed the last consensus DISPLAY.
Only dormant pm_* tables remain in the DB.
Related OPS INCIDENT — Zombie Bot Container (2026-06-03)
Zombie container — two bots running concurrently
Two
polymarket-fetchbot containers were found running at once on the GCP VM:
- one on NEW code (overlap_watcher cursor advancing), and
- one on OLD pre-
4794a76code (participant_changescursor STILL advancing every minute — a detector that was DELETED in4794a76).The old container was spamming the operator with a v1 “watched wallets position dump”.
Diagnosis
Via pm_detection_cursors: a detector that only exists in old code was still advancing → an old container is still live. Same root cause class as the Round-50 Telegram 409 getUpdates conflict (two pollers sharing one bot token).
Fix
VM-side: kill the stale container, leave exactly one on HEAD. Escalated to @deploy via AGENT_HANDOFF Round 52 / 52b.
GOTCHA for future deploys
After a bot deploy, verify only ONE container runs AND check that old-code-only detector cursors FREEZE. A still-advancing cursor for a deleted detector is the signature of a zombie container.
Deploy / Verification
- Deploy target is now
ec75491(Round 52b). - 135 tests pass.
- clippy clean (3 pre-existing warnings only).
- fmt clean.