3 files changed
src/api/invoices/[id]/route.tssrc/services/invoices.tstests/invoices.test.tsPRODUCT / SYSTEM From changed line to release decision
Software changed.Prove the promise didn’t.
MaruCheck connects approved behavior, the real Git diff, historical failures, targeted checks, and reproducible evidence in one accountable chain.
INPUTgit diff→OUTPUTship / block
ACT 01 — DEFINE
First, make the promise executable.
Quality Contracts preserve the behavior that must remain true—even when an agent rewrites both code and tests.
feature: subscription-management
criticality: high
owners: [product, engineering]
requirements:
- id: SUB-004
statement: Cancellation keeps Pro active
until the current billing period ends.
evidence_policy:
blocking: [SUB-004]SUB-004
Protected behavior
- Approved by an accountable owner
- Mapped to Vitest, Jest + Playwright
- Versioned when intent changes
ACT 02 — CHALLENGE
Then, spend proof where the change can hurt.
Risk is deterministic. Changed paths, critical contracts, coverage gaps, and QA Memory each explain their contribution.
MEM-0143 recalled
A previous invoice-ownership bypass touched the same authorization boundary.
+25 RISKCritical
Security, API, contract regression, and the recorded cross-account test enter the plan.
ACT 03 — DECIDE
A gate you can argue with.
Every result resolves to expected behavior, observed behavior, reproduction, and the evidence that supports the decision.
Requirementinvoice-access#INV-001
ExpectedUsers only read invoices owned by their account.
ObservedCross-account invoice payload returned.
Reproduce
npx vitest run tests/regressions/cross-account.test.tsOPERATING RULES
The author does not grade the work.
Independent by design
The coding agent can request verification. It cannot approve product intent.
Inconclusive stays visible
A missing tool, test, or requirement never gets rewritten into a pass.
Source stays local
Execution happens in the repository or CI; teams choose which evidence becomes shared proof.
COMMON QUESTIONS
Common questions
- How does MaruCheck decide what to test?
- MaruCheck spends verification effort where a change can actually hurt. Risk scoring is deterministic and explainable: changed file paths, the criticality of the contracts they touch, existing coverage gaps, and matching QA Memory entries each contribute a stated amount to a 0-100 score you can audit.
- What is QA Memory?
- QA Memory is MaruCheck's record of confirmed past failures. When code related to an earlier bug changes again, MaruCheck recalls that failure and forces its regression test back into the verification plan, so a bug diagnosed once cannot silently return in a later AI-authored change.
- How does MaruCheck check whether the tests are real?
- Mutation checking tests the tests. MaruCheck introduces isolated changes into the code a test claims to protect and confirms the test actually fails. A test that still passes against a mutated implementation is not protecting the requirement it is mapped to, and MaruCheck reports it.
- What does MaruCheck produce at the end of a run?
- MaruCheck produces an inspectable release decision, not a score. Every block cites the requirement ID it protects, the contract that requirement belongs to, the evidence collected during the run, and the commands needed to reproduce it, so a reviewer can audit the decision instead of taking it on trust.