marketplace entry for external plugin "ape-context": no ref/sha pin, stale path, version mismatch — extend version-check CI to external sources

[alencheung]

Summary

The ape-context entry in .github/plugin/marketplace.json is the one externally-sourced plugin in the marketplace (source repo suuus/ape-context). Three entry-hygiene defects, all verified against both repos today (git-ape @ c58302b):

1. No revision pin. The entry's source object carries repo and path but neither ref nor sha. VS Code's plugin acquisition path (pluginSources.ts, _checkoutRevision) explicitly skips checkout when both are unset, so an install resolves to the payload repo's default-branch HEAD, and periodic update checks re-pull the repo — the installed bytes float indefinitely and are never bound to what the listing reviewed. Pinning is documented as best practice for cross-repo plugin sources.

2. Stale path. The entry declares path: .github/plugins/ape-context. That path does not exist in the payload repo — it 404s. The payload's plugin manifest lives at the repo root (plugin.json, content under .github/skills/), and the payload's own .github/plugin/marketplace.json declares source: ".". As declared, the entry resolves to nothing at that subpath today.

3. Version mismatch. The entry declares version: 1.0.0; the payload's plugin.json says 0.0.1. Nothing anywhere compares the two, so the declared version is display metadata only. The mismatch itself is evidence that no verification ran when the entry was merged (PR feat(plugin): add ape-context plugin for enhanced context management #50).

Repro

Public metadata reads, no install needed:

$ gh api repos/Azure/git-ape/contents/.github/plugin/marketplace.json --jq '.plugins[1].source'
{
  "source": "github",
  "repo": "suuus/ape-context",
  "path": ".github/plugins/ape-context"
}

$ gh api repos/suuus/ape-context/contents/.github/plugins/ape-context
{"message":"Not Found","documentation_url":"https://docs.github.com/rest/repos/contents#get-repository-content","status":404}

$ gh api repos/suuus/ape-context/contents/plugin.json --jq .version
"0.0.1"

Suggested fix

1. Pin the entry — sha (full 40-character commit), or at minimum a tagged ref — so installs and update re-pulls bind the bytes that were reviewed.
2. Fix the path to match the payload layout (. / repo root, per the payload's own marketplace manifest) or remove the dead subpath.
3. Sync the declared version with the payload's plugin.json.
4. Extend git-ape-plugin-version-check.yml to validate external-source entries against their payload manifests: fetch the declared path + version from the pinned revision and fail the PR on mismatch or missing path. The workflow already does exactly this for the first-party plugin.json ↔ marketplace pair; external entries currently bypass it, which is how all three defects above landed unnoticed.

Impact framing

Manifest hygiene on an externally-sourced listing. The external repo is disclosed in the entry itself (author, homepage, repository all point at suuus/ape-context), so this is not about provenance display — it is about binding what gets installed to what was reviewed, keeping the declared metadata true, and letting CI catch drift instead of a person.