HarnX / MIQ Radar Auto-Review System

TL;DR

• Built HarnX dashboard called MIQ radar with CLI and API to visualize MR workload status
• GitLab-specific HarnX plugin runs debate-style auto-review, posting findings with bot attribution on MRs I’m assigned to review
• Added auto-implement feature (VM-based via Google Cloud and a local GDG version) that generates MRs from issues automatically
• Created a review checklist overlay (control-command R) and a ‘recall dojo’ voice Q&A tool to reinforce and prune memory learnings
• Next steps: measure quality of merged code via the debate process, and incorporate my manual review comments into the auto-reviewer

Building the dashboard and auto-review plugin

I’ve been building out HarnX along with a dashboard interface, plus a GitLab-specific HarnX plugin that handles a debate-style review process and custom implementations, using the memory module and graph DB to walk the codebase. The dashboard, called MIQ radar, has a CLI interface and an API, and lets me visualize workload statuses across various dimensions. I added auto-review functionality via the GitLab plugin’s debate-driven auto-review behavior - it automatically posts findings with bot attribution, but under my name, on any MR where I’m assigned as reviewer. This was inspired by GL’s review skill repository. The auto-review kicks in automatically whenever I’m assigned as reviewer on an MR, and on the radar I can see which MRs are underway, completed, or failed.

Auto-implement and review checklist

I implemented an auto-implement feature with two versions: one spins up VMs in Google Cloud, letting me click through several issues and launch multiple VMs that each generate an implementation and MR, assign it to me, label it, and notify me when done - about all I have to do afterward is kill the VMs. There’s also a non-VM version that runs locally against a separate GDG work track. I also created a review checklist that branches depending on whether there are UI changes; hitting control-command R brings it up as an overlay, and I check off items and clear it once done. The goal is to automate the mechanical, procedural parts of review while still doing spot checks for QA and product intent - trusting the agents while keeping quality consistent.

Debate-based learning and the recall dojo

Quality gets measured by comparing the MR author’s computations against my feedback as reviewer. The automated review system checks the author’s responses to posted comments, running debates between de-correlated agents using different reasoning models. If the reviewer’s comment wins the debate, it gets recorded in memory as a learning point. A dedicated UI for the GL auto-review plugin lists currently-reviewed and recently unmerged MRs, with learnings listed underneath - I can dig into the agent’s reasoning via the agent log, refute or correct it, save it to the memory database, and close out issues. I also built the ‘recall dojo,’ which turns a project’s memory imprints into a questionnaire: it presents the scenario a rule was extracted from and asks what I’d do; I answer by voice, and the LLM judges the response as right, partially right, or wrong, with any challenges triggering a debate that’s weighted toward human input. This reinforces memory and improves system quality over time, and lets me prune memories as I go. Next, I need to work on measuring the quality of merged code using this same debate process, and figure out how to get the auto-reviewer to account for cases where I start comments or review manually without being the assigned reviewer. The broader goal is to widen the surface the system crawls, mapping it into a GraphDB and installing memories from code concerns, comments, and issue threads during MR review.