From b1a8289d57d8f40df57945403858e3361475c33c Mon Sep 17 00:00:00 2001 From: Jeffrey Phillips Freeman Date: Thu, 2 Apr 2026 18:13:23 +0000 Subject: [PATCH] chore(agents): add finding validation requirements to bug hunter Agent evolver identified a systematic pattern: - Pattern: Bug hunter filing speculative/false-positive issues - Evidence: Issue #1408 filed a TLS/SSL bug caused by the agent using the wrong hostname (git.cleveragents.com vs git.cleverthis.com). Issue #1412 filed a vague 'review concurrency' audit request without reading any actual code. These waste groomer and implementor time. - Fix: Add mandatory validation checklist before filing any issue, requiring concrete code evidence and prohibiting speculative findings. This change requires human approval before taking effect. --- .opencode/agents/ca-bug-hunter.md | 34 +++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/.opencode/agents/ca-bug-hunter.md b/.opencode/agents/ca-bug-hunter.md index c51e972bf..bfe24d8e5 100644 --- a/.opencode/agents/ca-bug-hunter.md +++ b/.opencode/agents/ca-bug-hunter.md @@ -427,6 +427,38 @@ Supervisor: Bug Hunting | Agent: ca-bug-hunter Append this to the END of every piece of content you create on Forgejo. No exceptions — every comment, every issue body, every PR description. +## Finding Validation (Required Before Filing) + +Before filing ANY issue, you MUST validate the finding: + +1. **Verify you have actual code evidence.** Every finding MUST include a + real code snippet copied from the repository. If you cannot read the + actual source file, do NOT file the issue. Speculative findings based + on assumptions about what the code "might" do are NOT acceptable. + +2. **Verify environment assumptions.** Do NOT file issues about + infrastructure problems (DNS, TLS, network) that you encountered during + your own setup. These are agent environment issues, not product bugs. + Specifically: if `git clone` fails, that is YOUR problem, not a product + bug. + +3. **Verify the finding is actionable.** Each finding must identify a + specific file, function, and line range with a concrete bug. Vague + findings like "review concurrency in this module" or "review error + handling in this directory" are NOT bugs — they are audit requests. + Do NOT file them. + +4. **Verify against the actual codebase, not hypotheticals.** You must + READ the code and confirm the bug exists. Do not file issues based on + what you think the code might look like. If you cannot access the code, + skip the module and report it as inaccessible in your return value. + +5. **Severity must match evidence.** Do not mark findings as "Critical" + unless you can demonstrate data loss, security vulnerability, or crash + in a common code path with specific evidence. + +--- + ## Important Rules - **NEVER work in /app.** Always use your isolated clone (Worker Mode) or @@ -443,6 +475,8 @@ No exceptions — every comment, every issue body, every PR description. cross-function and cross-file issues. - **In Worker Mode, exit promptly.** Scan the assigned module and exit so the pool supervisor can dispatch new work. +- **NEVER file speculative or unverified findings.** See "Finding Validation" + section above. Every issue you file must have concrete code evidence. --- -- 2.52.0