Cover unsupported platform targets on the Marketplace

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.

[jack-champagne]

The bug

Installing Amicode from the Marketplace on Windows reports v0.0.2 as the latest version. It isn't a mac/windows vsix split — there has never been a Windows vsix. The listing today:

version	targets
0.1.1	linux-x64, darwin-arm64
0.1.0	linux-x64, darwin-arm64
0.0.3	linux-x64, darwin-arm64
0.0.2	(universal)

A missing target platform is not neutral. VS Code resolves a client whose target has no entry down to the newest universal version on the listing and installs it silently — no "unavailable for your platform". So every win32-* and darwin-x64 install since 0.0.3 has landed on 0.0.2, which predates #233 and points at the old solve/telemetry endpoints.

Intel Macs hit this too, not just Windows.

The fix

Publish binary-less cover packages for win32-x64, win32-arm64, darwin-x64. 2.47 MB each (verified locally) against ~100 MB for the universal fat vsix. They carry no vendored opencode, so they cannot run — that is the point. They occupy the platform matrix so those clients resolve to the current version, land in unsupportedHostAdvice(), and get told where Amicode does run. On Windows that's WSL, with a Reopen in WSL action offered only when remote-wsl.reopenInWSL actually exists (gated on getCommands), so there's no dead button.

A version's target set is fixed at publish time — you can't add a target to a published version — so the cover has to ride along with every release. All five platform vsixes publish in one vsce publish call. A packaging step fails the build if a cover package smuggled a binary in.

WSL is served by amicode-linux-x64.vsix installed into the WSL host, never by win32-*. That artifact already existed and was already correct; what was broken is the Marketplace lookup the Windows client performs. extensionKind: ["workspace"] is declared so placement is explicit rather than inferred (it matches VS Code's inferred default for a main extension — belt and braces, not the fix).

README gains an Install section, which it did not have at all.

Verification

• 809 tests pass; tsc --noEmit clean.
• Dry-ran the new packaging step locally: all three cover packages build, TargetPlatform is stamped correctly in each extension.vsixmanifest, and the fail-closed vendor/opencode check passes.
• Confirmed extensionKind survives vsce package into the shipped manifest.

Notes for the reviewer

• Conflicts with in-flight feat/linux-arm64 (uncommitted, local only) which rewrites the same release.yml packaging block into a platform loop. That branch is blocked on the fork shipping opencode-linux-arm64.tar.gz — v1.17.3-amicode.12 has no such asset and its lock entry is a zero-sha placeholder — so this ships first and that branch rebases onto the loop-friendly shape. When linux-arm64 lands it becomes a real target and drops out of the cover set.
• 0.0.2 stays on the listing. Per-version deletion isn't available; vsce unpublish is whole-extension and would break every existing install's update path. Shadowing it is the fix.
• Version bumped to 0.1.2 — release.yml's version guard requires manifest == tag base, and a clean v0.1.2 tag is what unlocks the publish job.