CommonPatch

One shared fix, three different needs—all in one review workspace.
Inspect the source before deciding what belongs in the shared library.
Similar code, different expectations. Each consumer’s behavior gets an explicit approval.
A plausible patch fails. The counterexample shows exactly why.
One exact wheel passes 297 bounded checks, with the earlier failure preserved.
Recorded GitLab Duo findings informed concrete fixes and stronger validation.
Real CI execution: regression tests, frontend build, and evidence replay passed.
GitLab reports 11 passing tests, zero failures, and zero errors.

Inspiration

A small workaround rarely stays small. One project adds a wrapper around a library. Another copies it and changes a rule. A third fixes an edge case. Eventually, several maintainers are solving almost the same problem—but moving that behavior into the library could break the projects that depend on it.

I built CommonPatch around that difficult handoff: how do we turn repeated workarounds into a shared improvement without losing the reasons those workarounds exist?

What it does

CommonPatch gives maintainers a review workflow for shared library changes. It brings together source evidence, consumer expectations, proposed patches, and executable validation so reviewers can understand what a change preserves before approving it.

The current demonstration follows three CSV importers. They all normalize column names, but their requirements differ:

Donation rejects duplicate names.
Inventory preserves capitalization and adds suffixes to duplicates.
Survey lowercases names and adds suffixes.

CommonPatch makes those differences explicit. Reviewers inspect the evidence, approve each consumer’s behavior contract, review an additive library design, and validate proposed migrations against one exact library wheel.

The most revealing example is ["Name", "Name", "Name_2"]. A seemingly reasonable implementation can assign Name_2 to the duplicate and then rename the original column. CommonPatch includes this deliberately defective candidate so reviewers can watch it fail, inspect the counterexample, and compare it with the corrected implementation.

The failed attempt remains in the history. Reviewers can export the patches, results, recorded Duo review, and artifact hashes.

How I built it

The interface uses React and TypeScript, with a FastAPI backend enforcing review stages, approvals, campaign ownership, and revision checks. Campaigns persist in SQLite locally and Firestore on the public Google Cloud Run deployment.

GitLab Duo Agent Platform provides a custom, two-stage review flow. The first component examines source evidence; the second reviews contracts and migration considerations. Both run with read-only repository tools, and their final answers are available for inspection.

That review produced useful findings. It identified migration imports that displaced module docstrings and an exception-precedence difference that class-only tests missed. I used those findings to correct the implementation and strengthen validation.

GitLab CI runs regression tests, builds the frontend, and replays the candidate workflow. The evaluator imports the exact candidate wheel in a fresh Python process and checks behavior against independent expectations.

Challenges

The hardest part was deciding what “the same behavior” actually means.

Matching successful outputs was not enough. Exception messages, the order of validation, input mutation, and existing suffixes could all affect a consumer. Input limits also needed to be stated before approval rather than quietly introduced during migration.

Another challenge was keeping evidence current. An approval should not authorize a different source revision, and an old passing result should not appear valid after the evaluator changes. CommonPatch fingerprints the relevant inputs and checks their freshness before proceeding.

I also kept authorization outside the shared patch. Similar-looking code is not automatically safe to consolidate.

What I’m proud of

The workflow makes a failed proposal useful. Instead of hiding the failure behind a green result, it preserves the counterexample and shows what changed in the corrected attempt.

The current implementation has 11 passing regression tests, and the corrected candidate passes 297 bounded evaluator checks. A real GitLab Duo review informed fixes that are visible in the implementation and evidence.

Most importantly, a reviewer can inspect the reasoning and reproduce the validation rather than relying on a summary alone.

What I learned

Repeated code is a starting point for investigation, not proof that consumers want the same API.

AI review was most useful when its findings could be checked against source and turned into concrete regression cases. Likewise, a passing test result became more meaningful when it was tied to an exact artifact, explicit contracts, and a clear input domain.

What’s next

The current release demonstrates the workflow with authored CSV consumers and one operator representing the maintainer roles. Its patch generation uses deterministic templates; the recorded Duo review runs separately from browser campaigns.

The next steps are authenticated GitLab repository connections, independent maintainer approvals, agent-generated patch ingestion, isolated execution for untrusted repositories, and coordinated library and consumer merge requests.

The goal is to make contributing a shared fix less uncertain—for the maintainer accepting it and for every project that will depend on it.