One plugin's entry in plugin.exs (SDD 8.2): what it is, which version
of it was applied, where that version came from, when it was applied, and
every file it owns or contributes to.
origin is {:hex, name, version}, {:path, relative}, or
{:registry, filename}. An ABSOLUTE path is rejected: a manifest naming one
machine's checkout is not portable to another machine or to CI, which is
SDD 4.1 defect 13. {:registry, filename} names the packaged archive a
plugin was extracted from — recorded verbatim by whichever caller supplies
it, rather than derived here, since the extraction directory it came from
is a temporary one already gone by the time anything reads this field.
deps, aliases and project record what the plugin changed in the
TARGET's mix.exs. They are what lets an update flow attribute a dependency
to the plugin that installed it, and notice that a user has since
hand-edited it — without them, apply wrote into mix.exs and nothing said
who had. All three default to [] and are OMITTED from the encoded entry
when empty, so a manifest written before they existed still decodes and a
plugin that changes nothing gains no keys.
There is no cross-plugin conflict check here — two plugins claiming the same file is SDD 7.3 policy, not this file's format, and the MVP produces no plugin for it to be wrong about.
Summary
Types
Where an applied plugin's archive came from: a hex package and version, a local path relative to the checkout, or the filename of a registry archive.