Module source_record 

PM.8a: the .source marker — where an installed plugin came from, remembered on disk beside its artifact.

Design: plugin-manager.md §4, §8.

Why this is persisted rather than derived

The obvious cheaper thing is to remember a plugin’s source in memory for the boot that installed it. That fails on the two cases that matter:

• The next boot. A plugin cached in the user root loads from the on-disk scan. Nothing in that path has ever seen a require, so a derived source column would read local for a plugin that came from git — confidently wrong, which is worse than blank.
• The rebuild chord (PM.8b). You cannot re-clone a git plugin without its URL and rev. A chord that only worked for plugins required earlier in this session would be a chord that mostly does not work.

So the source travels with the artifact, next to the .build-stamp that already records what the artifact was built from. Together they answer the two questions the view asks: where did this come from, and is it current.

Format

A tiny hand-rolled key = value file rather than serde. The record is four optional scalars and this crate does not otherwise depend on a TOML deserializer; a malformed or absent file degrades to “unknown source”, never an error — a plugin whose marker got corrupted must still load.

Enums

SourceRecord

Where a plugin on disk came from.

Functions

read

Read plugin_dir’s source marker, or SourceRecord::Unknown.

write

Write plugin_dir’s source marker. Best-effort: a failure is logged and the install still counts — losing the marker costs a column cell and a rebuild, not the plugin.