Local marketplace keyed by directory basename, not `marketplace.json` name; error message misdirects

[Roderick-Clemente]

Summary

When a local-path marketplace is added, it is registered under the directory basename, not the name field from marketplace.json. Installing with the documented pluginName@marketplaceName form (using the JSON name) then fails, and the error message misdirects to a cause that is not the problem.

Environment

• droid 0.186.0, macOS (darwin 24.6.0)

Reproduction

marketplace.json has "name": "probe-mkt". Directory is /tmp/probe-6/mkt.

droid plugin marketplace add /tmp/probe-6/mkt
# registered, but keyed as "mkt" (dir basename), not "probe-mkt"

droid plugin install probe-guard@probe-mkt
# FAILS: Marketplace "probe-mkt" not found. Run /marketplace add first.

droid plugin install probe-guard@mkt --scope project
# succeeds

marketplace list shows the mismatch: mkt (1 plugin) local:/tmp/probe-6/mkt "probe-mkt".

Expected

Either the marketplace is keyed by marketplace.json's name (as docs describe pluginName@marketplaceName), or the error names the actual key to use.

Actual

Keyed by directory basename; the docs' name-based install form fails; the error advises Run /marketplace add first for a marketplace that was just added successfully. Low severity, but costs a debugging cycle and contradicts the docs' local-testing snippet.

[Roderick-Clemente]

Adding cross-version evidence for issue #6.
REPRODUCES at droid 0.180.0 — six patch releases prior
to the Phase 0 baseline at 0.186.0. The defect has been live in
the field for at least 0.180.0. The basename-vs-name mismatch
is unchanged; only the contents of the error message are
identical to the captured Phase 0 wording.

---

Probe harness

• Local marketplace at /tmp/.../mkt-A-basename/
• marketplace.json declares "name": "alpha-mkt" —
  deliberately different from the directory's basename
  mkt-A-basename
• One trivial sub-plugin (probe-guard)
• All steps: add, list, install probe-guard@alpha-mkt,
  install probe-guard@mkt-A-basename, cleanup
• All changes observed through ~/.factory/settings.json diff
  against a pre-test backup, not through exit code alone

---

Verbatim captured sequence

$ droid plugin marketplace add /tmp/.../mkt-A-basename
Successfully added marketplace: mkt-A-basename   <-- basename, not "alpha-mkt"
exit 0

$ droid plugin marketplace list
Registered marketplaces:
  factory-plugins  ...
  canary-marketplace  ...
  mkt-A-basename  (1 plugins)  local:/tmp/.../mkt-A-basename  "alpha-mkt"

$ droid plugin install probe-guard@alpha-mkt       <-- the bug surface
Error: Marketplace "alpha-mkt" not found. Run /marketplace add first.
exit 1

$ droid plugin install probe-guard@mkt-A-basename  <-- the workaround
Successfully installed probe-guard@mkt-A-basename (msdv3c3)
exit 0

---

The bug, in two observable carriers

1. After marketplace add, the registry key in
   ~/.factory/settings.json's extraKnownMarketplaces is the
   basename of the directory, not the name field in
   marketplace.json.
2. The error message returned by install probe-guard@alpha-mkt
   — Marketplace "alpha-mkt" not found. Run /marketplace add first —
   is misdirecting: the marketplace was just added. The
   correct cause is "the registry keys by basename, so the
   manifest name wasn't the identifier."

---

Diff of ~/.factory/settings.json after add (vs pre-test backup)

+ "mkt-A-basename": {
+   "source": {
+     "source": "local",
+     "path": "/tmp/canary-bugs/bug-06-marketplace-name/mkt-A-basename"
+   }
+ }

The diff shows the registry key is mkt-A-basename, with
the directory path as value. The manifest name field
(alpha-mkt) is not used.

---

Residue observation (separate but adjacent to issue #6)

After plugin uninstall + marketplace remove, the diff of
~/.factory/settings.json against the pre-test backup shows
one residue which matches Phase 0 defect #6:

<   }
---
>   },
>   "enabledPlugins": {}

enabledPlugins: {} survives plugin uninstall as an empty
object. The extraKnownMarketplaces entry was correctly
removed by marketplace remove (no residue on this run).
Worth checking: whether marketplace remove is symmetric in
all cases — i.e., whether extraKnownMarketplaces: {}
residue can be induced.

---

Scope of this evidence

• Single sample per step (not multi-run statistical).
• Single local-path marketplace; remote git-marketplace
  install not tested (out of scope, opens a different
  surface that Phase 0 marked open).
• Single model behaviour is not asserted (no droid exec
  was run on this marketplace's droid contents — only
  install/uninstall was exercised).
• Cleanup restores user-level settings to a state differing
  from pre-test by only the enabledPlugins: {} residue
  documented above. No persistent mutation beyond that.