Why does the deployment manifest carry component `language`? (enum also omits Go/C)

Question / design discussion

Adopting Shipwright for Osprey (a compiler whose CLI binary is written in Go, with a C runtime) surfaced a question about the component.language field in shipwright.json.

What I found

language is referenced in:

• schemas/shipwright.schema.json — component.language enum is rust | dotnet | dart | typescript | kotlin | javascript. It is optional.
• docs/specs/binary-version-contract.md → [SWR-VERSION-BINDINGS] — uses language to pick the per-language version binding library (shipwright for Rust, Shipwright for .NET, @nimblesite/shipwright-mcp for Node, …). This is a build-time concern, not a deployment/resolution one.
• docs/specs/ide-extension-deployment.md:137 and docs/specs/vsix-platform-bundling.md:283 — components with "language": "dotnet" must acquire the runtime via Microsoft's .NET Install Tool.

The concern

The deployment contract itself is language-agnostic: the host resolves a binary, runs --version, and compares against expectedVersion. The implementation language is irrelevant to that.

For anything that compiles to native machine code (Go, Rust, C, C++), language carries zero deployment-relevant information — there's no language-specific runtime to fetch and nothing for the host to do differently. Osprey compiles Go → a native binary with a static C runtime; the host launches it and checks --version exactly like it would a Rust binary. The field is pure noise here.

The two places language is used don't justify it living in the deployment manifest:

1. Binding selection (SWR-VERSION-BINDINGS) is a build-time property — which library a binary was compiled with — not something a host needs at resolution time.
2. The .NET-runtime-acquisition rule is a single narrow special case (framework-dependent .NET sidecars). The deployment-relevant fact there is "needs a managed runtime acquired," not "is written in C#."

The enum is the wrong shape regardless

Even setting the above aside, a single language value per component doesn't model reality: one VSIX can bundle several sidecars written in different languages (say a Rust LSP + a .NET formatter + a Node MCP server) in a single artifact. There is no single "the language" for such a product, and the runtime-acquisition decision is per-sidecar and host-level, not a property you can read off one enum. A closed per-component language enum:

• can't express native-compiled components at all (no go/c/cpp), and
• pretends "language" is the axis that matters for deployment when the actual axis is "does this component need a managed runtime fetched, and how."

Proposal (for discussion)

• Drop language from the deployment manifest (move binding-selection to build-time config where it belongs), or
• If the .NET case needs modelling, model the deployment-relevant fact directly per-component — e.g. runtimeAcquisition: dotnet-install-tool (or a small managedRuntime block) — rather than inferring it from language == "dotnet". That composes correctly for multi-sidecar VSIXs and keeps the niche runtime handling out of the common path.

Happy to send a PR once there's a direction. Filed while wiring Osprey's shipwright.json, where I'm omitting language on the Go CLI component.

Start with schemas/shipwright.schema.json and the [SWR-VERSION-BINDINGS] section of docs/specs/binary-version-contract.md, then review the deployment rules in docs/specs/ide-extension-deployment.md and docs/specs/vsix-platform-bundling.md. Compare removing language with modelling runtime acquisition directly; done means the maintainers choose a direction and the schema and affected specifications agree.