cy0307/awesome-loop-engineering

1# Bug Hunting Loop2 3## Objective4 5Find, validate, and report likely bugs with reproducible evidence instead of filing speculative agent-generated issues.6 7## Trigger8 9- Schedule: weekly on active modules.10- Event: error logs spike, flaky tests cluster, user reports mention the same behavior, or a release branch opens.11- Manual bootstrap/debug command: "hunt for reproducible bugs in this module."12 13## Intake14 15- Recent errors, flaky tests, issue labels, support snippets, changed files, code ownership, logs, traces, and module documentation.16- Existing bug reports and duplicate issue search.17- Safe reproduction commands and test fixtures.18 19## Agents20 21- Scout: discovers suspicious signals and likely affected code paths.22- Reproducer: attempts minimal reproduction in a safe environment.23- Minimizer: reduces the reproduction to the smallest failing case.24- Fix suggester: proposes a patch only when the cause is clear.25- Reporter: files evidence-backed issues or PRs.26 27## Workspace And Permissions28 29- Use a branch, worktree, sandbox, or read-only mode depending on the target.30- Allow tests, local fixtures, logs, static search, and non-production reproduction.31- Disallow production data access, destructive fuzzing, speculative mass issue creation, or broad refactors.32 33## Durable State34 35- Checked modules, signals inspected, duplicate issue search, reproduction steps, commands, expected/actual behavior, traces, screenshots, and final disposition.36 37## Loop Steps38 391. Discover candidate bug signals from tests, logs, issues, traces, or recent diffs.401. Load ownership docs, existing issues, and prior bug-hunt state.411. Delegate signal discovery, reproduction, minimization, patch proposal, and reporting.421. Search for duplicates before filing anything.431. Reproduce in the smallest safe environment.441. If root cause is obvious and patch is small, propose a PR with tests.451. Otherwise file a precise issue with evidence and stop.461. Persist false positives and checked areas.47 48## Verification Gates49 50- A bug report includes reproducible steps or a clear trace/log link.51- A patch includes a failing test or deterministic reproduction when feasible.52- Duplicate issue search is recorded.53- Expected vs actual behavior is grounded in docs, tests, or product requirements.54 55## Budget And Exit56 57- Max retries: 3 reproduction attempts per candidate.58- Max runtime: 90 minutes per module or signal cluster.59- Stop when a bug is reproduced and reported, a small verified patch is opened, the signal is classified as non-bug, or owner judgment is needed.60 61## Escalation62 63Escalate for production-only bugs, privacy-sensitive logs, ambiguous product behavior, security-sensitive findings, data loss, or broad architectural fixes.64 65## Loop Instruction66 67```text68Hunt for reproducible bugs in <module, release, or signal cluster>.69Start from concrete signals: failing tests, logs, traces, issues, or recent changes.70Search for duplicates before filing.71Reproduce safely, minimize the case, and report expected vs actual behavior.72Open a patch only when the cause is clear and verification is available.73```74 75Example automation: run weekly against modules with recent churn, flaky tests, or repeated user reports.76 77## Failure Modes78 79- Filing issues from code smell without reproduction.80- Creating duplicate bug reports.81- Using private logs or customer data as public evidence.82- Patching symptoms while leaving the reproduced cause unexplained.83 84## References85 86- [Run long horizon tasks with Codex](https://developers.openai.com/blog/run-long-horizon-tasks-with-codex) - Practical plan-edit-test-observe-repair-document-repeat runbook.87- [SWE-bench](https://www.swebench.com/) - Benchmark framing around real repository issues and tests.88- [Terminal-Bench](https://www.tbench.ai/) - Evaluation context for hard terminal tasks and reproducibility.89