dependable check and the HTML report both stopped claiming "0 dependencies" for a manifest whose dependency list went unread — a SwiftPM Package.swift with no readable Package.resolved beside it. They now say the list went unread. dependable list still counts zero.
The inconsistency
$ dependable check <swift project with no Package.resolved>
Package.swift — Swift (dependency list unread)
$ dependable list <the same project>
Package.swift — Swift (0 dependencies)
The warning still reaches stderr from list, so the fact is not lost — but the heading states the precise claim the rest of that work exists to disclaim, and it is the line a reader skims.
Why it was left
ManifestReport and ManifestResults both carry dependencies_unread; ProjectReport (crates/dependable/src/output/list.rs) does not. Plumbing it there adds a field to the dependable.list/v1 document, which is a wider change than the wording fix — so it was scoped out rather than made in passing.
Direction
The change is additive, and check --format json already set the precedent by gaining manifests_unread the same way: a consumer pinned to the documented shape is unaffected, and one that wants the distinction gates on the new field. Carry dependencies_unread into ProjectReport, use it for the heading exactly as check and the HTML report now do, and expose it in list --format json so the machine-readable surface can tell an unread list from an empty one — which today it cannot, since both render as zero dependencies with no other field separating them.
dependable checkand the HTML report both stopped claiming "0 dependencies" for a manifest whose dependency list went unread — a SwiftPMPackage.swiftwith no readablePackage.resolvedbeside it. They now say the list went unread.dependable liststill counts zero.The inconsistency
The warning still reaches stderr from
list, so the fact is not lost — but the heading states the precise claim the rest of that work exists to disclaim, and it is the line a reader skims.Why it was left
ManifestReportandManifestResultsboth carrydependencies_unread;ProjectReport(crates/dependable/src/output/list.rs) does not. Plumbing it there adds a field to thedependable.list/v1document, which is a wider change than the wording fix — so it was scoped out rather than made in passing.Direction
The change is additive, and
check --format jsonalready set the precedent by gainingmanifests_unreadthe same way: a consumer pinned to the documented shape is unaffected, and one that wants the distinction gates on the new field. Carrydependencies_unreadintoProjectReport, use it for the heading exactly ascheckand the HTML report now do, and expose it inlist --format jsonso the machine-readable surface can tell an unread list from an empty one — which today it cannot, since both render as zero dependencies with no other field separating them.