Merged public fixes

Inspect accepted public contributions

For the complete curated showcase, use the searchable public results page. It provides per-PR links, scoped counts, languages, and a downloadable JSON snapshot. The examples below explain three of those contributions in more detail.

Prilog's website links to public bug-fix contributions that upstream maintainers merged. The PRs below let you inspect the original issue, code changes, review, and recorded checks. They are concrete contribution examples, not a production success-rate estimate or an endorsement of Prilog by the projects.

The public records establish the code and merge outcome. They do not independently establish how much work Prilog performed, how much a person edited, or elapsed generation time. No per-case automation or timing claim is made here beyond the linked evidence.

Keycloak: realm migration cache state

Keycloak PR #51945 addresses upgrade failures involving models tied to a cleared persistence context. The change clears managed realm-cache models when the migration clears its persistence context. The public PR is recorded as merged on September 9, 2026.

Inspect the linked issue, patch, and review to understand the failure and the scope of the change. This is an example of a repository-specific state-lifecycle fix.

Prefect: Microsoft Teams webhook URLs

Prefect PR #22908 raises the Apprise dependency floor to support newer Microsoft Teams Power Automate webhook URLs and adds regression coverage for the URL variants. The public PR is recorded as merged on August 26, 2026.

This illustrates a dependency compatibility fix with an explicit behavior to test. A dependency change still needs review of the affected integration and repository checks.

Newt: per-connection health-check state

Newt PR #462 addresses connection payload handling so health-check state does not carry across targets. The public PR is recorded as merged on October 12, 2026. Inspect the final diff and maintainer conversation for the precise behavior.

What should your own evaluation record?

• The original report, affected revision, and available reproduction.
• Diagnostic evidence and repository access supplied to the tool.
• The generated patch and any subsequent human changes.
• Tests actually run, observed failures, and review time.
• Final acceptance, merge, and any observed recurrence after deployment.

Use the same criteria for every tool being compared. Count unsuccessful investigations and unsupported cases, rather than selecting only merged examples.

Start from an issue or production error

Follow GitHub issue to pull request for the public-issue import workflow or automatic bug fixing for runtime evidence. For the separate reported benchmark, read the SWE-bench Verified evaluation.