v1.1.0

Added

• status now resolves the effective version a session would load, per scope, instead of echoing the manifest version. For each scope it reports the config file holding the registration, the raw entry as written (name@latest, a pinned spec, a { package } object, or a path/file:// form), and the resolved source on disk — an npm spec to OpenCode's package cache ($XDG_CACHE_HOME/opencode/npm, falling back to ~/.cache/opencode/npm) with the version read from that copy's package.json and the copy's age as a staleness hint, a path entry to the package checkout via PluginEntryResolver.packageRoot — and closes with an effective verdict that annotates a double-scope registration (should load: 1.0.0 (cache copy, local + global; both scopes register — double-load)) plus warnings for that double-load, a manifest/resolved version mismatch, a missing or incomplete cached copy, and an unparseable config. The verdict answers from the strongest source available: a resolved copy on disk, else the registration spec (a pinned exact version answers directly; @latest answers with the published version under --online; ranges stay unresolved), else the manifest version. A manifest without a live registration reports unregistered: the report answers what would load, not what was once installed. New --online queries the npm registry for every registered package — the name comes from the entry, or from the checkout's package.json for path-form registrations — and prints the published latest per scope (npm-latest=<version>, also , latest <version> on the verdict), flagging staleness with warn-and-continue on network failure. New --path <dir> resolves against another project directory; both flags are status-only and rejected elsewhere. status remains read-only. Resolution lives in the new StatusReporter (src/status-reporter.ts) over src/loaded-version.ts, src/config-entries.ts, and src/registry-version-checker.ts, with entry classification unified in src/entry-spec.ts; Installer is install/uninstall/cache only and exposes manifestAt() in place of the retired status()/StatusOutcome. The generated-package templates (registration, plugin-entry, installer, cli) gain the same resolution so packaged extensions inherit it.

• Path-form plugin-entry recognition (the aurelia-expert@db0736e lesson, issue #3): the new src/plugin-entry.ts and templates/plugin-entry.template.txt resolve a file:// URL or filesystem config entry to a package by package.json name. Registration-scope detection (templates/registration.template.txt) and the surgical config editor (src/plugin-config.ts, templates/plugin-config.template.txt) now count a live path-form entry as registered, so installation never adds a duplicate name@latest entry beside it. The packager and publisher template maps gained src/plugin-entry.ts, and conformance-checklist items B2 and C1 gained the rule.

Changed

• Path-form resolution refinements from the code review: relative path entries resolve against the config file's directory (facts §7) instead of the process working directory; package.json name matching is case-insensitive on Windows in code, as the docs already claimed; resolution memoization is an unbounded map keyed by resolved path; src/plugin-entry.ts is byte-identical to its template again, and the suite gains src/plugin-name.ts (byte-identical to templates/plugin-name.template.txt), both enforced by a new byte-sync test. The registration/config-editor "name match, then path resolve" shape is deduplicated into one shared predicate per file, and the four array fields collapse into keyed records.

Fixed

• agents/opencode-plugin-engineer.md referenced a nonexistent filterOurEntries; it now names the real de-dup path (PluginConfigEditor.ensurePluginEntry's zero-write no-op). Historical note: commit 6308389 was labeled docs: but also flipped test expectations (the v2 fixture dropped its plugins key).