Problem
Bubo turns human replies to its findings into outcome flags, then discards the reason in the reply. It can count rejected findings, but it cannot retain or use the maintainer reasoning behind a decision.
This loses useful repository knowledge. A finding may be rejected because of a deliberate design choice, a local constraint, an accepted exception, duplicate work, or a real false positive. Without that reason and its scope, future behavior is based only on rejection rates for a whole category. A category can then be treated as unreliable everywhere in the repository even when earlier feedback applied only to one area. There is also no clear record of why Bubo changed its behavior.
Bubo should keep a durable, reviewable feedback record for every resolved, disputed, or rejected finding. It should include the human response, responder identity and maintainer status when available, the classified outcome and its explanation, and the relevant scope: repository, rule or category, pull request or merge request, commit, and affected area.
New human replies should be able to update that record. Any learning or suppression decision should use the recorded, scoped feedback and make the reason behind the decision visible.
Reproduction
- Let Bubo create a finding on a pull request or merge request.
- Reply with a natural-language explanation for why the finding is wrong, intentionally accepted, duplicated, or only applicable in that area.
- Let Bubo process the reply.
- Check the stored outcome and a later decision for the same category.
The outcome is retained, but the explanation and its scope cannot be recovered or used.
Version
No response
Review backend
None
Logs
Problem
Bubo turns human replies to its findings into outcome flags, then discards the reason in the reply. It can count rejected findings, but it cannot retain or use the maintainer reasoning behind a decision.
This loses useful repository knowledge. A finding may be rejected because of a deliberate design choice, a local constraint, an accepted exception, duplicate work, or a real false positive. Without that reason and its scope, future behavior is based only on rejection rates for a whole category. A category can then be treated as unreliable everywhere in the repository even when earlier feedback applied only to one area. There is also no clear record of why Bubo changed its behavior.
Bubo should keep a durable, reviewable feedback record for every resolved, disputed, or rejected finding. It should include the human response, responder identity and maintainer status when available, the classified outcome and its explanation, and the relevant scope: repository, rule or category, pull request or merge request, commit, and affected area.
New human replies should be able to update that record. Any learning or suppression decision should use the recorded, scoped feedback and make the reason behind the decision visible.
Reproduction
The outcome is retained, but the explanation and its scope cannot be recovered or used.
Version
No response
Review backend
None
Logs