Philip Guzman
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# Library Health Engine
|
|
|
|
## Problem
|
|
|
|
Raw missing-reference counts do not provide a compact view of library integrity,
|
|
but an opaque blended score would imply confidence the current data cannot support.
|
|
|
|
## Architecture
|
|
|
|
The health engine produces an immutable report from the core `Library`. Its score
|
|
is only the percentage of non-dynamic crate references resolved by exact filename.
|
|
Smart-crate references are counted but excluded because their contents are derived
|
|
from rules. The report also exposes missing references, unique missing filenames,
|
|
duplicate filename groups, extra duplicate files, unused tracks, and missing
|
|
references with matching candidates.
|
|
|
|
Duplicate, unused, and candidate counts are informational. They do not affect the
|
|
score until the project has a documented and validated weighting policy. An empty
|
|
library has no score rather than a misleading 0% or 100%.
|
|
|
|
## Edge Cases
|
|
|
|
- The same missing filename referenced by several crates.
|
|
- Several disk files sharing a filename.
|
|
- Conflict-suffixed files that are unused but may be match candidates.
|
|
- Libraries with no crate references.
|
|
- Tracks referenced by filename from more than one crate.
|
|
|
|
## Verification
|
|
|
|
Tests assert every metric, the disclosed score basis, candidate integration, and
|
|
empty-library behavior. Analysis remains entirely read-only.
|