// Blog / inspector

Visual dashboard for coding-agent context and review

A trust layer is only useful if people can see what is verified, outdated, uncertain, and waiting for review.

technical blog Inspector workflow and trust visibility Published May 25, 2026 Updated May 25, 2026

// direct answer

Short answer

A visual inspector turns .knowledge files into a dashboard: repository health, confidence levels, freshness, items to re-check, relationships between repository areas, and high-impact files. It does not replace the files; it makes them easier to review before agents act.

Understand what a visual inspector adds on top of repo-local knowledge files.

// the problem

Important repository warnings are buried in files

A repository can contain trust reports and stale markers, but the team may never inspect them because they are buried in JSON.

The agent might know a module is suspect while the human reviewer sees only a clean-looking PR.

Without a visual surface, trust debt stays invisible until a wrong-file edit or stale-summary failure reaches review.

// visual review

Bring repository status into one dashboard

The Inspector renders the trust layer as a dashboard: repository health, relationships between areas, confidence status, items to re-check, and policy warnings.

It lets a reviewer see what the agent should recheck before code changes, especially around outdated modules and high-impact files.

The static local Inspector is included in the free core. Inspector Pro adds interactive team review.

// concrete example

When a module looks safe but is not

A PR modifies runtime execution. The code diff is small, but the module summary is stale and linked evidence is incomplete.

The Inspector surfaces the stale module, the missing evidence, and the repair item before review handoff.

The reviewer can ask the agent to re-read source and tests instead of approving a change against stale context.

// files you can inspect

Files behind the Inspector view

Some repository-specific files appear only after setup or a health check. Run the documented setup workflow to create routing, confidence, freshness, search, metrics, and PR summary outputs.

Static Inspector CREATED AFTER A HEALTH CHECK

`.knowledge/inspector/index.html`

The local dashboard is generated from repository files and can be opened without a cloud service.

Use it for

Visual confidence review
Checking follow-up work

Do not use it for

Editing source files
Replacing code review

Inspector data payload CREATED AFTER A HEALTH CHECK

`.knowledge/inspector/data.json`

The visual view should be backed by a generated data payload the team can inspect.

Use it for

Inspecting dashboard input
Debugging stale visual state

Do not use it for

Replacing source or tests

Inspector status payload CREATED AFTER A HEALTH CHECK

`.knowledge/inspector/status.json`

Status output makes health and generation state explicit instead of implicit in the UI.

Use it for

Checking generation health
Inspector QA

Do not use it for

Approving risky changes

Trust report CREATED AFTER A HEALTH CHECK

`.knowledge/maintenance/trust_report.json`

The Inspector view should reflect the current trusted, suspect, stale, and low-confidence buckets.

Use it for

Trust bucket display
Review readiness checks

Do not use it for

Claiming product behavior without source

Freshness map CREATED AFTER A HEALTH CHECK

`.knowledge/freshness.json`

Freshness shows which repository context files may need recheck after source changes.

Use it for

Stale module warnings
Post-commit maintenance

Do not use it for

Ignoring current git changes

Items to re-check CREATED AFTER A HEALTH CHECK

`.knowledge/maintenance/repair_queue.json`

Repair items convert uncertainty into visible work the team can assign.

Use it for

Prioritizing rechecks
Team review conversations

Do not use it for

Blocking every small edit

// commands to try

Commands and expected checks

node .knowledge/tools/build-visual-inspector.js

what it does: The static Inspector is regenerated from current .knowledge files.
where to look: .knowledge/inspector/index.html

node .knowledge/tools/serve-inspector.js

what it does: The generated Inspector can be served locally for review.
where to look: Browser preview of the local Inspector

node .knowledge/tools/doctor.js

what it does: The health status feeding the visual layer is checked.
where to look: .knowledge/maintenance/quality_report.json

Inspector surface files and checks

What the human should see

01 Health: is the repository context ready to use or does it need attention?

02 Relationships: which repository areas are verified, outdated, uncertain, or secondary?

03 Selected area: what should the agent re-read before acting?

04 Follow-up work: what outdated or unverified context needs an owner?

// practical reference

Inspector signals

A visual layer should make hidden agent risk reviewable.
Signal	Question it answers	Reviewer action
Health	Is the knowledge layer usable today?	Run doctor or refresh before handoff.
Trust	Can the agent use this summary for planning?	Re-read source when trust is weak.
Freshness	Did code move after the summary?	Refresh outdated repository context.
Follow-up work	What should not stay implicit?	Assign or close the item.

// quick FAQ

FAQ

Does the Inspector require cloud sync?

The static local Inspector can be generated from repository files. Inspector Pro adds interactive team review and coordination.

What is the most important Inspector signal?

Trust state. If a module is stale, suspect, or low-confidence, the agent should re-read current source and tests before behavior claims.

// next step

Use this page when trust needs to become visible

Generate the static Inspector from the repo-local files, then use it to decide what an agent must re-read before acting.

View Inspector Read audit checklist Read Inspector docs