[FEATURE] Support marketplace notation (name@marketplace) in apm uninstall

[sergio-sisternes-epam]

Is your feature request related to a problem? Please describe.

apm install accepts marketplace notation (apm install my-plugin@official), but apm uninstall does not -- it rejects any package whose name does not contain /:

$ apm uninstall my-plugin@official
[x] Invalid package format: my-plugin@official. Use 'owner/repo' format.

The rejection happens in _validate_uninstall_packages (src/apm_cli/commands/uninstall/engine.py:48), before any resolution is attempted. To remove a plugin that was installed via a marketplace, users have to open apm.yml (or apm.lock.yaml) to look up the canonical owner/repo form -- a clear install/uninstall asymmetry that breaks the "remove what you installed, the way you installed it" expectation set by npm/pip/cargo.

Describe the solution you'd like

Make apm uninstall accept the same NAME@MARKETPLACE[#REF] grammar that apm install accepts (defined by _MARKETPLACE_RE in src/apm_cli/marketplace/resolver.py:41). Resolve the marketplace ref to its canonical identity, then run the existing identity-match logic against apm.yml.

Resolution strategy (lockfile-first, registry fallback):

1. Lockfile lookup (offline, cheap): scan LockFile.dependencies for entries whose discovered_via == <marketplace> and marketplace_plugin_name == <name> -- this provenance is already written at install time (src/apm_cli/deps/lockfile.py:43-44).
2. Marketplace-registry fallback (silent, mirrors install): when the lockfile does not carry the provenance, call parse_marketplace_ref() + resolve_marketplace_plugin() to obtain the canonical owner/repo and match by identity.
3. Clear failure: if both fail, surface plugin '<name>@<marketplace>' is not installed (marketplace-specific wording, distinct from the generic "not found in apm.yml" used for canonical refs).

Expected behaviour after the change:

$ apm uninstall my-plugin@official
[+] my-plugin@official - found in apm.yml (as acme/my-plugin)
[+] Removed acme/my-plugin from apm.yml
[+] Uninstall complete: Removed 1 package(s) from apm.yml, Removed 1 package(s) from apm_modules/

apm uninstall my-plugin@official --dry-run, -g, and batch mixes (canonical + marketplace refs that point at the same dep) should all work without extra flags.

Describe alternatives you've considered

• Require an explicit opt-in flag (--resolve-marketplace) for the registry fallback. Rejected: install is silent, and the lockfile-first path covers the common case with zero network calls, so requiring a flag would just add friction without protecting against anything.
• Lockfile-only resolution (no registry fallback). Rejected: would fail for users whose lockfile has been deleted/regenerated without the provenance fields, even though the canonical owner/repo is in apm.yml and reachable.
• Document the asymmetry and leave it. Rejected: the install/uninstall symmetry is a core npm-style ergonomic the project already commits to, and the cost to fix is small.

Additional context

• Validator gate to relax: src/apm_cli/commands/uninstall/engine.py:48.
• Marketplace grammar: _MARKETPLACE_RE in src/apm_cli/marketplace/resolver.py:41.
• Provenance written by install: discovered_via, marketplace_plugin_name in src/apm_cli/deps/lockfile.py:43-44, populated in src/apm_cli/commands/install.py:400-405.
• Out of scope: no change to apm.yml storage format (marketplace refs continue to be resolved to canonical form before being persisted); no change to install; no new flags.

[github-actions]

Triage decision

accept

Proposed labels

theme/portability
area/marketplace
area/cli
area/docs-site
type/feature
status/accepted
priority/high

Milestone

null -- latest release is v0.13.0; maintainers should assign to the next open minor (0.14.0 or equivalent) if one exists.

Suggested next action

Implement marketplace-notation resolution in _validate_uninstall_packages (engine.py:48) using lockfile-first lookup and registry fallback, matching the install-side _MARKETPLACE_RE grammar, and update docs/src/content/docs/reference/cli-commands.md and packages/apm-guide/.apm/skills/apm-usage/commands.md in the same PR.

Suggested issue comment

Thanks for the detailed write-up -- the install/uninstall symmetry gap is real and the implementation map you've provided is clear.

This is accepted. The lockfile-first resolution strategy (reading `discovered_via` + `marketplace_plugin_name` provenance) is the right approach: it covers the common case with zero network calls, and the registry fallback mirrors what `apm install` already does, so no new trust surface is introduced.

A few notes for the implementing PR:

- The validator gate relaxation in `_validate_uninstall_packages` (engine.py:48) must keep canonical `owner/repo` identity validation *downstream* of resolution, not remove it -- the existing identity-match logic runs after resolution, which is the correct order.
- The batch-mix case (canonical + marketplace refs pointing at the same dep in one command) should deduplicate by resolved canonical identity to avoid a double-remove attempt.
- `apm uninstall my-plugin@official --dry-run` and `-g` should work without extra flags (as you noted) -- a test covering each variant would be a strong addition.
- The CLI reference (`docs/src/content/docs/reference/cli-commands.md`) and the apm-guide skill resource (`packages/apm-guide/.apm/skills/apm-usage/commands.md`) must be updated in the same PR to show the new accepted syntax and a usage example.

If you'd like to take this on, the implementation scope looks well-contained: engine.py (relax validator + add resolution chain), resolver.py imports in the engine, and the two doc files. Happy to review a draft PR.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The request maps directly to the install/uninstall symmetry that npm, pip, and cargo all preserve -- users expect to uninstall using the same identifier they used to install, with no lookup step. The current rejection at _validate_uninstall_packages before any resolution is attempted is a clear ergonomic regression relative to the install side. The proposed failure message (plugin 'X@Y' is not installed) is correctly marketplace-specific and distinct from the generic "not found in apm.yml" wording, so error ergonomics are preserved. The dry-run, -g, and batch-mix requirements are correct parity checks. No UX concerns; this is a well-scoped fix for a real user-facing asymmetry.

Supply Chain Security Expert -- Risk-Surface Reviewer

The lockfile-first resolution path reads already-recorded discovered_via and marketplace_plugin_name provenance without network calls, grounding identity in the lockfile (the source of truth per lockfile-spec.md). The registry-fallback path reuses parse_marketplace_ref() + resolve_marketplace_plugin(), which install already calls under the same trust boundary -- no new attack surface is opened. The canonical owner/repo identity check in apm.yml must remain downstream of resolution (the issue text confirms this). The clear-failure path (plugin 'X@Y' is not installed) is fail-closed. area/marketplace is the correct label; no theme/security or theme/governance flag is warranted -- this is a UX parity fix within an existing trust boundary.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- author is a COLLABORATOR with a detailed, technically precise feature request that needs no first-contributor onboarding tone.

Python Architect -- Architecture Reviewer

The proposed resolution chain (lockfile lookup -> registry fallback -> clear failure) is a natural Chain-of-Responsibility pattern and maps onto existing functions without requiring new abstractions. The affected files are engine.py (validator relaxation + resolution dispatch), resolver.py (existing parse_marketplace_ref + resolve_marketplace_plugin already there), and lockfile.py (existing provenance fields). Estimated scope: 2-3 files, ~60-100 net new lines. No new module, no interface change, no migration boundary. The feature can land as status/accepted without a design phase. One implementation-level note for the implementing PR: the batch-mix case (canonical + marketplace refs for the same dep in one invocation) must deduplicate by resolved canonical identity to avoid a double-remove attempt -- this is a coding concern, not a design-phase blocker.

Doc Writer -- Documentation Reviewer

This feature changes the accepted syntax of apm uninstall, so docs/src/content/docs/reference/cli-commands.md must be updated to show the new NAME@MARKETPLACE[#REF] form alongside the existing owner/repo form, with a usage example showing the resolution output. Per Rule 4, packages/apm-guide/.apm/skills/apm-usage/commands.md must also be updated in the same PR. area/docs-site rides as a secondary area/* to remind the implementing PR author. The suggested comment wording above is developer-focused and references concrete file locations, which is consistent with APM's doc voice.

APM CEO -- Triage Arbiter

Clear accept. Install/uninstall symmetry is a core APM commitment (the npm/pip/cargo mental model), and this gap is immediately user-visible. The security lens confirms no new trust surface; the architecture lens confirms no design phase is needed. Priority is high because the fix scope is small relative to the ergonomic cost of the current behavior. Theme is theme/portability -- same identifier across the full package lifecycle is a portability-of-workflow guarantee. Milestone is null pending maintainer confirmation of open minor milestone; if 0.14.0 is open, this belongs there as a type/feature with priority/high.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/portability",
  "areas": ["area/marketplace", "area/cli", "area/docs-site"],
  "type": "type/feature",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Implement marketplace-notation resolution in _validate_uninstall_packages (engine.py:48) using lockfile-first lookup and registry fallback, matching the install-side _MARKETPLACE_RE grammar, and update cli-commands.md and commands.md in the same PR.",
  "comment_markdown": "Thanks for the detailed write-up -- the install/uninstall symmetry gap is real and the implementation map you've provided is clear.\n\nThis is accepted. The lockfile-first resolution strategy (reading `discovered_via` + `marketplace_plugin_name` provenance) is the right approach: it covers the common case with zero network calls, and the registry fallback mirrors what `apm install` already does, so no new trust surface is introduced.\n\nA few notes for the implementing PR:\n\n- The validator gate relaxation in `_validate_uninstall_packages` (engine.py:48) must keep canonical `owner/repo` identity validation *downstream* of resolution, not remove it -- the existing identity-match logic runs after resolution, which is the correct order.\n- The batch-mix case (canonical + marketplace refs pointing at the same dep in one command) should deduplicate by resolved canonical identity to avoid a double-remove attempt.\n- `apm uninstall my-plugin@official --dry-run` and `-g` should work without extra flags (as you noted) -- a test covering each variant would be a strong addition.\n- The CLI reference (`docs/src/content/docs/reference/cli-commands.md`) and the apm-guide skill resource (`packages/apm-guide/.apm/skills/apm-usage/commands.md`) must be updated in the same PR to show the new accepted syntax and a usage example.\n\nIf you'd like to take this on, the implementation scope looks well-contained: engine.py (relax validator + add resolution chain), resolver.py imports in the engine, and the two doc files. Happy to review a draft PR."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• [BUG] Cross-repo bare repo on *.ghe.com marketplace silently resolves at github.com on validation success (dependency-confusion vector) #1326 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1326 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Triage Panel for issue #1323 · ● 1.3M · ◷