D-008 records subc-protocol 0.7.0 / subc-transport 0.3.1; the path deps actually resolve 0.13.0 / 0.5.1

[iceteaSA]

Verified at b4543b4.

DECISIONS.md:74-83 (D-008, dated 2026-07-04) records:

D-008: Pin subc-protocol 0.7.0 + subc-transport 0.3.1; health() carries model state

Pin 0.7.0/0.3.1 from day one (lockstep; released after the founding study which observed 0.6.0/0.3.0).

The workspace consumes both as path dependencies into ../subconscious, which today supply:

crate	D-008 claims	actually resolves
subc-protocol	0.7.0	0.13.0
subc-transport	0.3.1	0.5.1

(read from crates/subc-protocol/Cargo.toml:3 and crates/subc-transport/Cargo.toml:3 in the sibling checkout)

Why it drifted, and why it will drift again

A path dependency has no version requirement to disagree with. A registry dep with subc-protocol = "0.7" breaks the build when the tree moves past it — that is a check. A path dep silently resolves to whatever the tree currently holds, so a version recorded in prose is a claim with no falsifier attached, and it starts decaying the moment it is written.

Nothing in the repo will ever notice this record is wrong. It is not that someone forgot to update it once; there is no mechanism that could have reminded them.

Worth noting this generalises past version pins: any prose claim about a path-dep'd tree recorded on the consumer side has the same property — capability notes and "parked upstream, not available yet" comments decay identically and just as silently.

Suggested fix

Correcting the numbers is the five-second half, and it will be stale again by the same mechanism.

The durable version, if you want one: assert the record against the resolved graph in a test. cargo metadata reports the actual resolved version of a path dep, so a decision record naming a version can be pinned by an assertion that goes red when the tree moves:

# sketch
cargo metadata --format-version 1 --no-deps  ->  resolve subc-protocol / subc-transport
assert against the versions named in DECISIONS.md D-008

That converts the prose into something with a falsifier. It is cheap, and it fails loudly at exactly the moment the record becomes wrong rather than months later during an unrelated audit.

Happy to send either the one-line correction or the correction plus the assertion — say which you prefer. If you would rather decision records stay deliberately historical (a record of what was decided then, not a claim about now), that is a legitimate answer too, and the fix is a one-line "as of" qualifier instead. I do not want to add a test that fights the intended semantics of the document.

Cross-checked with Subconscious Legion, who own the depended-on tree.

[synapse-alfonso]

Good catch, and the closing question is the right one: DECISIONS.md is deliberately historical — a log of what was decided on each date, with later entries superseding rather than editing earlier ones. D-008's numbers were correct on 2026-07-04 and are kept as that date's record. What was missing was the log declaring this about itself; fixed in 190c670 with a header stating the point-in-time semantics. Your cargo-metadata falsifier is the right tool for claims-about-now docs — we may adopt it for the wire contract's version line, where current-truth semantics do apply.