Clouseau

01 / Context

The problem behind the project

Automated review needs to assess the purpose and evidence for a change, not just produce comments or approve a green build.

I extracted repeated verification/review logic into Clouseau because code coverage alone cannot decide whether a change belongs in a product. A change may pass every test while weakening the contract, testing a fake implementation, or implementing a feature no one authorized.

The project investigates how AI-assisted change review can work with explicit evidence and narrow authority. It is engineering automation research with concrete GitHub integrations, not a claim that a model can independently decide product intent.

02 / Implementation

Design and implementation

I research and implement reusable review gates, evidence collection, evaluation fixtures, and controlled approval workflows.

I built shared coverage gates, the composite action, trusted configuration handling, model assessment, revision-bound approval control, bounded repair paths, and coordinated documentation maintenance. Consumers retain their own build/test commands and product contracts.

The review path separates untrusted contributor execution from privileged assessment and gating. The reviewer reads protected-base configuration and treats patches, commit messages, tickets, and source as evidence rather than instructions. Model-provider access and GitHub write authority live in separate jobs.

The coverage checker verifies exact, nonempty application line and branch counts rather than rounded percentages. The acceptance protocol additionally evaluates necessity, proportionality, technical findings, test integrity, independent investigation, and unresolved authority questions.

03 / Architecture

Architecture and workflow

1. 01

   Run untrusted verification

   Contributor code executes on a disposable read-only runner without privileged review secrets.

2. 02

   Assess against trusted contracts

   A protected-base reviewer compares intent, source evidence, and technical results at a specific revision.

3. 03

   Investigate uncertainty

   Technical uncertainty is recorded and investigated; a human intent comment cannot waive a factual or integrity failure.

4. 04

   Apply a narrow gate

   A separate controller validates native protection and exact evidence before approving or arming protected auto-merge.

5. 05

   Keep documentation coupled to evidence

   Wiki generation checks source-line support; a separate publication job verifies deployment and protects concurrent human edits.

04 / Approach

Engineering decisions

05 / Evidence

Evidence and outcomes

The repository provides fixed evaluation fixtures for maintenance, product drift, test fakery, and change acceptance. Read-only evaluation modes retain evidence without writing to a pull request.

The documentation path challenges both supported and deliberately false claims, validates complete page batches, and refuses invented source references or incomplete evidence. Model confidence is not an approval credential.

Source and technical notes