fix: pick up @alcops/core 0.2.0 (AL 18 flat VSIX layout); correct version docs

.github/ARCHITECTURE.md

@@ -230,7 +230,13 @@ for f in tasks/*/task.json; do
 done
 ```
 
-GitVersion provides `minor` and `patch` as separate outputs. Task `Major` is preserved (only bumped for breaking YAML contract changes). Consumers reference tasks as `TaskName@1`.
+GitVersion provides `minor` and `patch` as separate outputs. Task `Major` is deliberately preserved: it
+is the `@N` consumers reference in YAML (`TaskName@1`), so raising it breaks every pipeline pinned to the
+old major. It is only bumped for breaking YAML contract changes, and then a copy of the previous major
+has to keep shipping alongside it.
+
+As a result the task version in the pipeline log header (`Version: 1.x.y`) is intentionally independent
+of the extension version on the Marketplace (`2.x.y`); only `Minor` and `Patch` track GitVersion.
 
 ### CI Pipeline Flow
 

CONTRIBUTING.md

@@ -126,7 +126,7 @@ The [CI workflow](.github/workflows/ci.yml) runs on every PR touching `azure-dev
 Every push to `main` automatically publishes the **dev extension** (`alcops-ado-dev`):
 
 1. GitVersion calculates the next version (e.g., `0.1.3`)
-2. Inline `jq` in the workflow stamps all `task.json` version fields (Minor + Patch)
+2. Inline `jq` in the workflow stamps all `task.json` version fields (Minor + Patch; `Major` is pinned)
 3. `tfx extension publish` pushes to the Marketplace as a private extension
 4. The extension is shared with the configured Azure DevOps org
 

README.md

@@ -51,6 +51,11 @@ steps:
       detectFrom: "marketplace"
 ```
 
+> **Note:** Both VSIX layouts of the AL Language extension are supported from `@alcops/core` 0.2.0:
+> the flat `extension/bin/` layout used by AL 18+ (BC 29) and the legacy `extension/bin/Analyzers/` layout.
+> Compiling with AL 18 additionally requires a .NET 10 runtime on the agent, since its binaries are
+> framework-dependent `net10.0`. Installing that runtime is outside the scope of this task.
+
 ### Auto-detect from Compiler Path
 
 ```yaml
@@ -101,7 +106,7 @@ Download ALCops code analyzers with automatic TFM detection.
 | `detectUsing` | — | Input for TFM detection: BC artifact URL, local compiler path, NuGet DevTools version/channel, or VS Marketplace version. Smart routing determines the source. |
 | `detectFrom` | *(auto)* | Force a detection source: `bc-artifact`, `marketplace`, `nuget-devtools`, `compiler-path` |
 | `tfm` | — | Explicit target framework: `net8.0`, `netstandard2.1`, `net10.0`. Skips detection. |
-| `version` | `latest` | ALCops version: `latest`, `preview`, or specific (e.g., `1.2.3`) |
+| `version` | `latest` | ALCops version: `latest`, `prerelease`, or specific (e.g., `1.2.3`) |
 | `outputPath` | `$(Build.SourcesDirectory)/.alcops` | Where to place extracted analyzer DLLs |
 
 > **Note:** Either `detectUsing` or `tfm` must be provided.
@@ -115,6 +120,15 @@ Download ALCops code analyzers with automatic TFM detection.
 | `outputDir` | Full path to extracted analyzer DLLs directory |
 | `files` | Semicolon-separated list of analyzer DLL paths |
 
+#### Versioning
+
+The `@1` in `ALCopsDownloadAnalyzers@1` is the **task** major version, and the pipeline log header
+shows the task's own version (`Version: 1.x.y`). That is intentionally independent of the extension
+version on the Marketplace (`2.x.y`): every release stamps the task `Minor` and `Patch`, while `Major`
+stays at `1` because it is the number your YAML pins. It only changes on a breaking task contract
+change, which would mean updating your pipelines to `@2`. So a `Version: 1.x.y` header on a 2.x
+extension is expected, not a mismatch.
+
 ## Troubleshooting
 
 ### "A supported task execution handler was not found ... not compatible with your current operating system"

overview.md

@@ -19,6 +19,9 @@ steps:
       outputPath: "$(Build.SourcesDirectory)/.alcops"
 ```
 
+> **Note:** The `@1` is the task major version and is independent of the extension version shown above;
+> the `Version: 1.x.y` line in the pipeline log is the task's own version, not the extension's.
+
 ## Usage Examples
 
 ### Auto-detect from BC Artifact URL
@@ -44,6 +47,11 @@ steps:
       detectFrom: "nuget-devtools" # Optional: Defaults to BC DevTools from NuGet, set to 'marketplace' for AL Language extension from VS Code Marketplace
 ```
 
+> **Note:** With `detectFrom: marketplace`, both VSIX layouts of the AL Language extension are supported
+> from `@alcops/core` 0.2.0: the flat `extension/bin/` layout used by AL 18+ (BC 29) and the legacy
+> `extension/bin/Analyzers/` layout. Compiling with AL 18 additionally requires a .NET 10 runtime on the
+> agent, since its binaries are framework-dependent `net10.0`.
+
 ## Links
 
 - [Full documentation on GitHub](https://github.com/ALCops/azure-devops-extension)

package.json

@@ -35,7 +35,7 @@
     "vitest": "^4.1.11"
   },
   "dependencies": {
-    "@alcops/core": "^0.1.2",
+    "@alcops/core": "^0.2.0",
     "azure-pipelines-task-lib": "^5.279.0"
   },
   "engines": {