A diff shows what changed. It rarely shows why the code was shaped the way it was. That knowledge usually lives in a module README or a decision record that the change never touches, so a reviewer who reads only the diff cannot tell when a change quietly breaks an agreement.

The diff first, then the documents behind it

Lightfactory starts with the diff of the pull request. It then reads the README of each module the change touches and the decision records those READMEs link to. A finding cites the document it relies on, for example:

docs/decisions/0007-webhook-delivery.md says retries wait with jitter.
backoff(attempt) gives every delivery the same delay.

The reviewer does not guess at intent. If no document states a rule, it does not invent one.

A second pass for security

Changes beyond documentation and tests get a separate pass that looks only for security defects. Keeping it separate means an ordinary finding never crowds out a security one.

Saying what it could not check

Every review ends with the parts of the change it could not inspect, and why, such as how code in another repository handles what this change sends it. A review that claims to have checked everything is harder to trust than one that names its limits.

What it cannot do

  • Reach the network: each review runs in a container with networking off and no credentials inside.
  • Change your code: it works on a read-only copy and returns only its report.
  • Read repositories you did not opt in.

The home page shows a full example review, including both findings above.