Expose opaque plugin identities and ownership references on discovered contributions
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- backend-api-design
Direzione di ricerca
Start by locating the plugin inventory and discovery APIs for agents, skills, instructions, hooks, and MCP servers across the supported language SDKs, then read their existing provenance fields and tests. Define and document a consistent ownership reference that resolves in the matching global or session context, including ID lifetime and same-named plugins from different sources. Done means every contribution type and supported SDK follows the contract, with tests covering resolution and global/session behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
VS Code needs to group SDK-discovered contributions under their owning plugins while leaving discovery and plugin lifecycle management to the SDK.
Please expose a common opaque plugin ID on plugin inventory entries and an owning-plugin reference on every plugin contribution: agents, skills, instructions, hooks, and MCP servers.
Without a shared ownership contract, consumers must infer relationships from names, parse contribution IDs, match filesystem paths, or scan plugin directories. Those approaches duplicate SDK responsibilities and can misattribute contributions when different plugins have the same name.
Proposed contract
- Each plugin inventory entry exposes an opaque
id. - Each plugin-owned contribution exposes an optional owning-plugin reference, for example
pluginId, whose value matches an inventory entry'sid. - Non-plugin contributions omit the reference.
- Use the same identity contract across global discovery and session-scoped APIs wherever they refer to the same plugin instance.
- Document the identity's scope and stability, including restarts, updates, and reinstallations. Distinguish same-named plugins from different marketplaces/direct sources and session-specific instances where necessary.
- Document how contributions resolve to inventory entries in the corresponding context, including session-only, built-in, and managed plugins. Consumers should not need to reconstruct an identity from installation metadata.
- Reuse or align existing provenance fields rather than introduce competing ownership identifiers.
Illustrative field names, not a required API shape:
const inventory = {
plugins: [{ id: "opaque-plugin-id", name: "review-tools", enabled: true }]
};
const discovery = {
agents: [{
id: "opaque-agent-selection-id",
name: "reviewer",
pluginId: "opaque-plugin-id"
}]
};
The agent's selection ID and the owning plugin's ID serve different purposes; callers must not parse either.
Expected consumer behavior
VS Code can join contribution results to inventory entries by the opaque plugin ID, present SDK-owned plugin groups, and use SDK-reported enablement. It does not scan plugin directories, parse manifests, match file paths, or implement another discovery mechanism.
Acceptance criteria
- Ownership attribution is available consistently for agents, skills, instructions, hooks, and MCP servers.
- Every returned plugin reference can be resolved using the documented inventory API/context.
- Same-named plugins from different sources remain distinguishable.
- Global/session behavior and ID lifetime are documented and covered by tests.
- All supported language SDKs expose the contract.
Scope
This requests ownership attribution, not filesystem roots, enablement migration, or a change to policy precedence.
Whether APIs should also enumerate contributions of disabled plugins is a separate capability question. This issue does not require scanning those contributions on the client or assume active discovery returns them.
Related VS Code work: https://github.com/microsoft/vscode/issues/343342
- Lingua principale
- Java
- Stelle
- 10.7k
- Fork
- 1.5k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/copilot-sdk
-
Rust: ElicitationRequest drops the tool call id from elicitation.requestedForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
github/copilot-sdk#2900 ·
-
Bump zod version to 4.6.6.Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
github/copilot-sdk#2876 · 1 commento · 1 reazione ·
-
Python ModelLimits drops max_output_tokens from model metadataForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
github/copilot-sdk#2798 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
github/copilot-sdk#2759 ·
-
docs/AGENTS.md is repo authoring guidance, but everything in docs/ gets publishedForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertadocumentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
github/copilot-sdk#2758 ·
Tutte le issue di github/copilot-sdk
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
ls1intum/thesis-management#1473 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
LunaDeerMC/Dominion#301 · 1 commento ·
-
[FEATURE] Expose external refresh, node-level translog and warmer statsForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertauntriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
opensearch-project/opensearch-prometheus-exporter#680 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 2 giorni