Engineering outcomes, not feature counts
Anyone can count agents. The ledger an engineering manager actually reads is outcomes — issues detected and fixed, PR issues caught, build failures resolved, hours saved. This example is derived from committed demo report.json files. The analysis capability is experimental and does not promise these outcomes for a customer repository.
Your ledger, from your repo
real reports, not estimatesvc outcomes reads the committed reports under docs/vectalon/ and .vectalon/upgrades/ and counts each outcome from real artifacts — then multiplies the hours by a blended rate ($75/hr by default, override with --rate). Nothing is estimated from thin air; if no reports exist yet, the ledger says so.
every metro/gradle/xcode log you hand it → root cause + fix plan, counted per report
reports with applied:true mean the fix actually touched the tree
every error/warning finding in a review report, before the PR merges
the performance dimension findings, and new problems caught on the latest run
error+warning findings from every committed scan — and approved scans count as prevented
one provenance dir (with UPGRADE.md) per completed upgrade run
test files written by every workflow run, counted recursively
See your own ledger — it takes as long as the agents you've already run: