NoteGate — a repair a maintainer can inspect

A supervised GitLab Duo flow that verifies the exact files behind an agent-generated repair.

Comment

Trust the repair at the handoff

An agent says the repair is ready. A maintainer still needs to know what GitLab actually stored. During our recorded operator transfer, a wrong encoding produced a successful commit containing Base64 text instead of the approved file contents. NoteGate refused that result before preparing a merge request. The corrected transfer then matched the approved bytes.

For maintainers and platform teams accepting changes from GitLab Duo agents. NoteGate brings the approved patch, the stored files and the remaining review questions into one inspectable handoff.

How it works

  1. Repair. GitLab Duo repairs a bounded issue and runs the supplied tests. In the recorded retry defect, a fictional reminder batch created two pending jobs after a restart; the repair keeps one, while preserving distinct schedules and channels.
  2. Review. A reviewer with read-only tools examines the candidate. The approved snapshot fixes the files and their test evidence.
  3. Verify. The operator handoff derives complete file contents from that snapshot, commits them to a branch, then reads them back from GitLab. The expected parent, complete changed paths, file modes and exact bytes must match before an MR request can be prepared.
  4. Hand off. The maintainer receives the draft MR and its evidence. The maintainer still inspects applicable CI, obtains any required approval and decides whether to merge.

The browser review client extends that inspection to a public GitLab.com MR: paste its URL to see which earlier claims still match the observed files, what conflicts and which proof is missing. Public reads need no sign-in. A dated local dossier can be downloaded and reopened as a reference. The client sends no message and performs no approval or merge.

Proof you can inspect

  • A real bad transfer, then its correction: verify the two existing commits. The first stored encoded text; its receipt was refused before an MR request. The corrected transfer contains the approved file bytes. This was an operator encoding error, not an established GitLab API defect.
  • A native repair: NG-002, MR !3 went from three failing cases to nineteen passing cases, with read-only review and a received remote handoff. Its original CI failure is preserved; later integration checks are linked to their own versions.
  • An exit-code failure: a completed tool call could report generic success despite a nonzero process exit. Critical flow steps therefore compare the exact exit response.

The native repair and later operator/browser improvements have separate records. Their failed attempts remain visible; they are not presented as one fresh native run.

DevSecOps stages covered

Bounded issue intake → agent repair → tests and read-only review → provenance verification → draft MR preparation → CI inspection before the maintainer's decision. The seeded issue is supervised; no autonomous production intake or merge is claimed.

Try it in two minutes — no sign-in

Choose a starting point:

Next steps and current limits

Reduce the operator commands, qualify automatic retrieval of newly approved snapshots, and measure maintainer interventions on real projects. In the controlled comparison, a competent pre-MR script achieved the same exercised safeguards. NoteGate's integrated handoff and re-examination are the product approach; less human time or superior verification has not yet been demonstrated.

Verification and branch-based MR creation are separate operations, so later branch movement can invalidate an observation. A local declaration is not authenticated Review authority. This supervised Start Fresh entry uses fictional fixtures; the maintainer keeps the merge decision.

Built With

Share this project:

Updates

Submission history