# Solvix Core Continuous Judgment Roadmap

Solvix Core is not only an outreach helper. Its real job is to help developers and maintainers understand a codebase continuously: what changed, what matters, why Solvix believes it matters, and what should be watched next.

## Product Direction

Solvix Core should become a living judgment layer for repositories.

It should answer:

- What kind of project is this?
- Which parts are runtime core, support code, tooling, tests, examples, or noise?
- Which files and functions deserve attention now?
- Which findings are not worth maintainer attention?
- What evidence led to the judgment?
- What changed since the last run?
- What benchmark or test would confirm the claim?
- What should not be touched?

## Upgrade 1: Trace Ledger

Status: implemented as the first foundation.

Every project report now includes a trace ledger with:

- Stable finding IDs.
- Stable target keys.
- Baseline continuity state.
- Trace steps from inventory, identity, graph, lens, judgment, evidence, and verification.
- Source references that point back to report sections.
- No-send findings, so suppressed targets can still be tracked.

This makes Solvix explainable. A maintainer can ask why a target appeared and trace the answer back through deterministic evidence.

## Upgrade 2: Run History

Next planned step.

Solvix should save a lightweight local history file per repo. Future runs should compare against the previous trace ledger and mark each finding as:

- New.
- Repeated.
- Improved.
- Worsened.
- Resolved.
- Suppressed by calibration.

This is what turns Solvix from one-time analysis into continuous judgment.

## Upgrade 3: Change-Aware Mode

After history exists, Solvix should support a mode focused on changed files.

It should answer:

- Did this pull request touch a high-relevance file?
- Did it add a new hotspot?
- Did it move code into a runtime path?
- Did it touch something Solvix previously said not to touch?
- Does the change need a benchmark, test, or source review?

This is the bridge toward Solvix Build.

## Upgrade 4: Maintainer Documentation

The public documentation should be rewritten around plain questions:

- What does Solvix do?
- Why should I trust it?
- What does it not claim?
- How do I read a report?
- What is a trace ledger?
- How do I use Solvix weekly on my repo?
- How do I use it before opening a PR?

The language should be beginner-readable but professionally precise.

## Upgrade 5: Website Rebuild

The GitHub Pages site should stop sounding like a tool pitch and become a clear product explanation.

Suggested first screen:

> Solvix helps developers understand where a codebase needs attention, why it matters, and what evidence supports that judgment.

Main sections:

- Continuous codebase judgment.
- Traceable findings.
- Benchmark-first recommendations.
- No-send decisions that protect maintainer attention.
- Solvix Core today.
- Solvix Build direction.

## Outreach Direction

Do not lead with "I found a bug."

Lead with:

- Solvix is a traceable codebase judgment tool.
- It produces bounded findings with evidence.
- It records no-send decisions.
- It can support maintainers over time, not just generate one report.
- The specific repo note is an example of the workflow.

Outreach should happen after the docs and trace examples are clear enough that someone can understand Solvix without us explaining it in private.