Skip to content

docs: add Bugbot resolve-and-reply team norm to .cursor/BUGBOT.md #421

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
LukasWodka merged 2 commits into from
Jul 29, 2026
Merged

docs: add Bugbot resolve-and-reply team norm to .cursor/BUGBOT.md #421

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2dbe349
docs: add Bugbot resolve-and-reply team norm to .cursor/BUGBOT.md
LukasWodka Jul 29, 2026
15d2c38
docs: point CONTRIBUTING.md at the Bugbot findings norm
LukasWodka Jul 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions .cursor/BUGBOT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,3 +125,11 @@ consequence — what they see, and which exit code they get — not just the cod

This repo is **public**: never put a customer name, internal hostname, or internal-only ticket
detail in a finding. A bare `tracebloc/backend#NNNN` reference is fine.

## Working with Bugbot findings (team norm)

Every Bugbot review thread gets a reply, then gets resolved:
- **Fixed**: say what changed and in which commit.
- **False positive**: say why, with evidence (file/line, measured behavior).
Unresolved cursor threads HOLD release-train promotions (soft gate) — an
unaddressed finding blocks the fleet, not just this PR.
4 changes: 4 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,3 +105,7 @@ Coverage says a line *ran*; mutation testing says a test would *fail* if the lin
4. File one issue per real gap, titled `test(<pkg>): pin <behavior> (mutation survivor)`, quoting the gremlins line (mutant type + file:line) and what behavior the missing test must pin. That issue then flows through the kanban like any other test ticket — #262, #263, #264 are the pattern.

Survivors are *findings to triage*, not build failures — the workflow stays green even when mutants live, on purpose.

## Bugbot findings

See `.cursor/BUGBOT.md` — every thread gets a reply (fixed / false-positive-with-evidence), then resolved.
Loading