Show HN: MaruCheck – Independent QA for AI-generated code

Show HN: MaruCheck – Independent QA for AI-generated code(github.com)

3 points by KidusMT 1 day ago | 2 comments

Hi HN,

I've been building MaruCheck, an independent, open-source QA verification tool aimed to solve the issues that arise when coding agents like codex, claude, cursor make semantic issues that has heavy ramifications.

Take the example where the requirements says a free user gets 5 uploads. The code changes this behavior to 10. Test generated from the implementation may simply start expecting 10. But Marucheck treats the existing approved requirements as a separate evidence and flags the behavior change.

Some of the things implemented currently are Quality contracts, repository and stack scanning, Git diff/change- impact analysis, risk based analysis, semantic drift detection, QA memory for previous bugs/regression, CLI workflows, integration for coding agents, Github/CI verification etc etc..

Another area I’m experimenting with is QA Memory.

If six months ago a bug existed because users could access another customer’s invoice by changing an invoice ID, MaruCheck can associate that regression with the relevant files/contracts. If those areas change again later, that previous failure becomes part of the new verification plan.

The project is local-first and I’m trying not to reinvent existing testing infrastructure unnecessarily. The idea is to orchestrate tools like Playwright/Vitest/security/Jest tooling rather than build another browser automation framework from scratch.

Currently it's on NPM and you can runit using npx or npm by writiing npx --yes marucheck@0.3.0 init and all the information and docs are available on the site marucheck.dev.

I have decided to build it in the open and I'm especially interested in feedback on all aspects. Contributors are very welcome as well - issues, adapters, testing, docs, bug reports, architecture criticisms, all of it.

Thanks

surajsuradkar23 8 hours ago |

The QA Memory idea is interesting. I wonder how you distinguish “this area previously failed” from “the old failure is still relevant to the current architecture.” Otherwise historical evidence can become another form of stale context.

KidusMT 2 hours ago | |

That's exactly what are the risks I'm definitely trying to avoid the idea isn't that like historical bugs permanently increase the risk in the same area or that QA memory stores just something more than this file failed before when it comes to changes the goal is to match against the context rather than the file history which basically helps in terms of when the architecture has changed enough would causes and requirements no longer applies the memory should lose relevance rather than keep influencing the verification and quality assurance forever the distinction between the useful historical context and stale context is definitely something I want to get right.