Skip to content

Findings and analysis

A finding is something Jensen noticed about the project. It comes from a deterministic detection over the live map, not a model’s opinion.

Attribute Values
Category security, quality, regression, ownership, infra
Severity info, low, medium, high, critical
Status active, superseded, expired
Kind detection, fix, warning, improvement

Findings have no pane of their own. They surface where you already work.

  • Your assistant lists them with list_findings, filtered by category, severity or status. Assistants are told to check existing findings before bug or regression work, which is the difference between investigating and re-investigating.
  • A review reports what a change reaches. jensen review names who calls the changed symbols, what tests cover them, and whether the change crosses a boundary your team confirmed. It is advisory and says nothing where the graph does not reach.
  • The commit box shows secret and junk findings for staged changes. See The git guard.
  • A hook can review proactive findings when a file saves. See Agent hooks.

--publish needs the Comment on merge requests permission, and --dry-run checks it and prints without posting.

A finding becomes tracked work as an issue. Use Create issue from a pipeline, or Create issue from selection and Create issue from this TODO in the editor. See Notes.

Before a review, an assistant can ask for a structural read of the map: over connected hubs, low cohesion components, dependency cycles, oversized files and likely copy and paste clones.

That read is evidence, not a verdict. The same holds when Jensen localizes a bug from a report or a failing job log. It ranks the likely places to look and says the ranking is a lead.

Settings, System, Health reports what is not working in this project’s setup: trust, the tools its languages need, whether it is indexed, and whether an assistant can see it. See Troubleshooting.