Independent review findings on update-disabled plugins:
- Recorded plugins are tried only after the enabled plugins have built, one
at a time on top of them; an update that has to disable an enabled plugin
re-enables nothing, so a download failure can never swap two plugins.
- A resolver or build verdict records a fingerprint of what was tried (core's
dependency inputs plus the plugin's) and is not built again until one side
changes; a download failure is retried by the next update, and those go
first because they fitted beside the rest before.
- The update publishes against the config snapshot it decided from, and a
rejoin needs the record to still be there, so a user's mid-update choice
stands.
- Recorded reasons keep their readable start, not the tail of a uv error.
- An installed provider that fails to import is reported as such instead of
running recovery, and the startup notices dedupe per kind.
- A provider-only record is retried only while memory.provider still names
it, so a rejoin never installs a provider the user switched away from.
- An installed provider that still fails to load after startup recovery is
reported even when recovery printed an install notice.
- One spelling reader: plugin_spellings uses the shared native manifest
reader (plugin.yaml or plugin.yml), and the memory loader uses it too.
Agent init resolves the configured provider in one sibling: a parked
provider gets its notice and is never re-installed, an installed provider
that fails to import (a broken install, missing packages) now tells the user
external memory is off instead of only logging, and the unavailable warning
keeps its once-per-home dedup.
Co-authored-by: AIalliAI <285906080+AIalliAI@users.noreply.github.com>
Co-authored-by: Mani Saint-Victor, MD <drmani215@gmail.com>
Teknium