grp06 Find The Most Impactful Bug in tail-bot
Mindset
You are hunting for ONE real bug that is most likely causing user-visible damage: wrong trades, lost money, silent failures, corrupted state, or incorrect calculations. Not style issues. Not hypothetical risks. Real defects with evidence.
Be decisive. Do not ask clarifying questions. Read the code. State assumptions and proceed.
What tail-bot Is
A Rust trading bot for 5-minute Polymarket Up/Down markets. It ingests Chainlink price feeds and market websocket order books, evaluates a cheap-tail strategy, and either skips, simulates (shadow mode), or submits live orders. Key modules: chainlink_ws.rs (price feed), market_ws.rs (order book), tail_strategy.rs (decision engine), trader.rs (order submission), runtime.rs (orchestration), shadow_report.rs / shadow_eval.rs (PnL scoring).
Bug Patterns to Prioritize
In a trading bot, these are the bugs that cost real money:
- Stale data used for decisions — websocket cache serving old prices/quotes past staleness thresholds, EWMA sigma computed from stale ticks, window-start price lookup returning wrong values
- Edge/PnL calculation errors — wrong fee/slippage math, inverted cheap-side selection (buying the wrong leg), off-by-one in time window boundaries, incorrect fill probability modeling
- Race conditions in async flows — websocket ingestion vs. strategy evaluation reading inconsistent state, discovery refresh clobbering in-flight evaluations
- Silent swallowed errors — API failures that return defaults instead of propagating, websocket disconnects that aren't detected, settlement status misclassification
- Order submission bugs — submitting with wrong price/size/side, dedupe file corruption, collateral check using stale balance
- Shadow simulation divergence — shadow fills computed differently than live would execute, making shadow PnL misleading for strategy tuning
Workflow
Step 1: Read the Codebase
Start with ARCHITECTURE.md and README.md, then trace the core decision pipeline through runtime.rs → tail_strategy.rs → trader.rs. Read the websocket ingestion paths (chainlink_ws.rs, market_ws.rs), the config/validation layer, and the shadow reporting pipeline.
Step 2: Find Candidate Bugs
Look for real defects — not style issues. For each candidate, note the file, line range, and what goes wrong.
Step 3: Score and Pick ONE
| Criteria | Weight |
|---|---|
| Severity (money lost, wrong trades, corrupted data) | 30% |
| Likelihood (how often real usage triggers it) | 25% |
| Blast radius (how many markets/flows affected) | 20% |
| Detectability (silent = worse) | 15% |
| Fix complexity (easy fix + high impact = prioritize) | 10% |
Present the single highest-scoring bug with: location, what goes wrong, what happens when it fires, and why it scored highest.
Step 4: Write the ExecPlan
Read PLANS.md in ~/tail-bot. If missing, read $CODEX_HOME/skills/execplan-create/PLANS.md. Follow that format exactly.
Choose a short descriptive kebab-case filename (e.g. fix-stale-sigma-in-tail-entry.md, fix-inverted-cheap-side-selection.md).
Write to /Users/georgepickett/tail-bot/.agent/potential-bugs/<chosen-name>.md.
The plan must be self-contained per PLANS.md — a novice with only this file can fix the bug. Include a regression test that fails before and passes after the fix.
Tell the user the path when done.
Anti-Patterns
- Asking clarifying questions — read the code, make assumptions, state them.
- Multiple bugs without picking one — pick one, justify it, move on.
- Style issues or hypothetical risks — only real defects with evidence.
- Symptom fixes — fix root causes, not band-aids.
- Vague acceptance criteria — every criterion must be verifiable with a command.