build fixes

Author: houstonhaynes

.github/workflows/publish.yml

@@ -63,6 +63,7 @@ jobs:
             artifacts/nuget-release/0.1.0/manifest.json
             artifacts/nuget-release/0.1.0/consumers-candidate/results.json
             artifacts/nuget-release/0.1.0/consumers-candidate/logs/
+            artifacts/nuget-release/0.1.0/consumers-candidate/resolved-packages/
             artifacts/nuget-release/0.1.0/pack-logs/
 
   publish:

docs/nuget-release.md

@@ -16,7 +16,9 @@ dotnet run --project tools/NuGetRelease -- support
 
 The probe uses `tests/SupportPackage/Smoke.fs` and `UpstreamHelpers.fs`. Its staged project, isolated package cache, and logs are under `artifacts/nuget-release/0.1.0/public-support/`. The release workflow requires this check to pass before publishing.
 
-The upstream maintainer needs to publish corrected support packages containing the project and source assets required by [Fable library packaging](https://fable.io/docs/your-fable-project/author-a-fable-library.html). Once available, update `publicDependencies` in `config/nuget-release.json` to those versions and rerun all candidate checks. Existing NuGet versions cannot be replaced. CloudEdge's intended first release remains 0.1.0.
+The upstream packaging correction includes the project and source assets required by [Fable library packaging](https://fable.io/docs/your-fable-project/author-a-fable-library.html). `publicDependencies` in `config/nuget-release.json` now selects **0.1.1** for both support packages. Locally packed corrected packages pass the helper compilation probe; the upstream maintainer still needs to publish them before the public check can pass. Existing NuGet versions cannot be replaced. CloudEdge's intended first release remains 0.1.0.
+
+To test an upstream packaging fix before publication, pass `--support-feed /absolute/path/to/packages` to `support`, `pack`, and `examples --fable`. These commands map the two Xantham package IDs to that explicit local feed and use isolated caches. This is local evidence only: the GitHub workflow uses public support packages, and `examples --public` rejects a local support feed.
 
 ## Restore account access
 
@@ -70,6 +72,8 @@ The F# release tool reads the selected solution, orders packages by dependency,
 
 `config/nuget-release.json` pins the release and public support dependency versions. Release consumers must not restore `0.1.0-local.*` dependencies. Candidate packages contain license and README metadata; Fable packages also contain their project and source files under `fable/`.
 
+Sample projects use `0.1.*` so they can adopt stable patches. Published CloudEdge dependencies permit `[0.1.0,0.2.0)`; Xantham support dependencies permit `[0.1.1,0.2.0)`. Release validation replaces sample floats with exact candidate references and pins both support packages to the configured versions. Each consumer's `resolved-packages/*.json` report records the actual dependency versions and is retained in the workflow artifact.
+
 From the repository root:
 
 ```bash
@@ -92,6 +96,8 @@ Inspect the README, license, dependency versions, source assets, and emitted imp
 
 Run the **NuGet** workflow on `main` with **publish disabled** first. It builds candidates, checks consumers, and uploads the packages and verification evidence as an artifact. Fix failures before requesting the actual release.
 
+After committing and merging fixes into `main`, use **Actions → NuGet → Run workflow**, choose `main`, and leave **publish** unchecked. The equivalent command is `gh workflow run publish.yml --ref main -f publish=false`. Here `publish.yml` is the workflow filename and `-f publish=false` supplies its boolean input. Rerunning the old tag's job uses the old commit; dispatching on `main` picks up the merged fixes without changing the package version or moving the tag. Enable **publish** only when ready to upload.
+
 GitHub runs the public support-helper probe in a separate job alongside package validation, so upstream failures appear early. The publication job requires both jobs to succeed. Package compilation uses two MSBuild processes on the standard runner; uploads remain ordered by dependency.
 
 When account ownership, the Trusted Publishing policy, and candidate checks are complete, push the release tag **`v0.1.0`**, or run the workflow manually with **publish enabled**. GitHub repeats validation, obtains temporary credentials, then uploads packages in the manifest's dependency order. A partial upload is possible: NuGet publication is not a transaction across 47 packages. The workflow stops on an upload error rather than silently skipping an existing version. Inspect ownership, versions, and package contents before deciding how to resume.

site/content/guide/first-deploy.md

@@ -15,7 +15,7 @@ order: 5
 
 ## Project Folder
 
-The upload program is a .NET console project in a `deploy` folder inside hello-worker. It references two NuGet packages at version `0.1.0`: `Core.Api` for the request and response types, and `Management.Compute` for `ComputeClient`.
+The upload program is a .NET console project in a `deploy` folder inside hello-worker. It references two NuGet packages from the `0.1.*` patch series: `Core.Api` for the request and response types, and `Management.Compute` for `ComputeClient`.
 
 1. From your hello-worker folder, create `deploy`.
 
@@ -44,8 +44,8 @@ The upload program is a .NET console project in a `deploy` folder inside hello-w
      </ItemGroup>
 
      <ItemGroup>
-       <PackageReference Include="FSharp.CloudEdge.Core.Api" Version="0.1.0" />
-       <PackageReference Include="FSharp.CloudEdge.Management.Compute" Version="0.1.0" />
+       <PackageReference Include="FSharp.CloudEdge.Core.Api" Version="0.1.*" />
+       <PackageReference Include="FSharp.CloudEdge.Management.Compute" Version="0.1.*" />
      </ItemGroup>
 
    </Project>

site/content/guide/first-worker.md

@@ -14,7 +14,7 @@ order: 4
 
 ## Project Folder
 
-Create the application anywhere convenient. It restores `FSharp.CloudEdge.Runtime.Workers` version `0.1.0` from NuGet; no sibling library checkout is required. See [Packages](packages.md) for release availability and candidate-feed testing.
+Create the application anywhere convenient. It restores `FSharp.CloudEdge.Runtime.Workers` from the `0.1.*` patch series on NuGet; no sibling library checkout is required. See [Packages](packages.md) for release availability and candidate-feed testing.
 
 1. Open a terminal in the folder where you keep your projects.
 2. Create `hello-worker` and enter it.
@@ -28,7 +28,7 @@ Stay in `hello-worker` for the remaining commands.
 
 ## Project File
 
-Save this as `hello-worker.fsproj`. It declares `Worker.fs`, Fable.Core, and the Workers package at version `0.1.0`.
+Save this as `hello-worker.fsproj`. It declares `Worker.fs`, Fable.Core, and the Workers package from the `0.1.*` patch series.
 
 ```xml
 <Project Sdk="Microsoft.NET.Sdk">
@@ -42,7 +42,7 @@ Save this as `hello-worker.fsproj`. It declares `Worker.fs`, Fable.Core, and the
     <PackageReference Include="Fable.Core" Version="5.2.0" />
   </ItemGroup>
   <ItemGroup>
-    <PackageReference Include="FSharp.CloudEdge.Runtime.Workers" Version="0.1.0" />
+    <PackageReference Include="FSharp.CloudEdge.Runtime.Workers" Version="0.1.*" />
   </ItemGroup>
 </Project>
 ```

site/content/guide/packages.md

@@ -8,7 +8,7 @@ Application projects reference the FSharp.CloudEdge libraries by NuGet package I
 
 ## Release availability
 
-The first `0.1.0` release is being prepared. Package links and examples name the intended public versions; they do not assert that publication has completed. Public Xantham support packages currently need a packaging correction for Fable inline helpers; see the [release blocker and reproduction](https://github.com/fsprojects/FSharp.CloudEdge/blob/main/docs/nuget-release.md#current-release-blocker). Until that is resolved, use the [contributor source build](local-build.md). Locally packed candidates are for release testing and share this upstream limitation.
+The first `0.1.0` release is being prepared. Package links and examples name the intended public versions; they do not assert that publication has completed. The release requires corrected Xantham support packages at `0.1.1` containing Fable source assets; see the [release blocker and reproduction](https://github.com/fsprojects/FSharp.CloudEdge/blob/main/docs/nuget-release.md#current-release-blocker). Until those dependencies are published and public validation passes, use the [contributor source build](local-build.md).
 
 The release order is: validate candidate packages and consumers, publish dependencies before their consumers, confirm every `0.1.0` package restores from nuget.org, then announce availability. A package page appearing in search is separate from a clean restore succeeding.
 
@@ -17,17 +17,19 @@ The release order is: validate candidate packages and consumers, publish depende
 For a Worker:
 
 ```bash
-dotnet add package FSharp.CloudEdge.Runtime.Workers --version 0.1.0
+dotnet add package FSharp.CloudEdge.Runtime.Workers --version '0.1.*'
 ```
 
 For a .NET program that manages Workers:
 
 ```bash
-dotnet add package FSharp.CloudEdge.Management.Compute --version 0.1.0
+dotnet add package FSharp.CloudEdge.Management.Compute --version '0.1.*'
 ```
 
 The latter brings in `FSharp.CloudEdge.Core.Api` transitively. You can list it explicitly when your project uses its types. [First Worker](first-worker.md) and [First Deploy](first-deploy.md) show complete project files.
 
+Samples use `0.1.*` to accept stable patches in the `0.1` series without moving to `0.2`. Catalog links identify the concrete `0.1.0` release. For repeatable application builds, commit a NuGet lock file and use locked restore in CI; deliberately refresh it when adopting a patch. Release validation pins the candidate and support versions exactly and records every resolved package.
+
 The NuGet feed is `https://api.nuget.org/v3/index.json`. A package page such as `https://www.nuget.org/packages/FSharp.CloudEdge.Runtime.Workers/0.1.0` is for browsing; it is not a package source URL.
 
 ## Fable and npm dependencies

site/content/guide/verify-bindings.md

@@ -32,7 +32,7 @@ dotnet build site/examples/Compute/Compute.fsproj --nologo
 dotnet build site/examples/Services/Services.fsproj --nologo
 ```
 
-Run these builds sequentially. They restore `0.1.0` packages by default; they do not deploy a Worker or prove that a service call succeeds. For contributor source builds, add `-c Release -p:CloudEdgeUseSource=true`. Before publication, use the candidate checks described on [Packages](packages.md). Agents contains the SDK and tool examples, Compute contains workspace and Sandbox examples, and Services contains the Containers consumer.
+Run these builds sequentially. They restore `0.1.*` packages by default; they do not deploy a Worker or prove that a service call succeeds. For contributor source builds, add `-c Release -p:CloudEdgeUseSource=true`. Before publication, use the candidate checks described on [Packages](packages.md). Agents contains the SDK and tool examples, Compute contains workspace and Sandbox examples, and Services contains the Containers consumer.
 
 The documentation excerpt check is separate:
 

site/examples/Examples.props

@@ -1,7 +1,7 @@
 <Project>
   <!--
     Shared settings for the site's example projects. Every F# block on the site is an excerpt of a file
-    compiled here, and the F# NuGetRelease tool verifies that. Examples consume NuGet 0.1.0 by default.
+    compiled here, and the F# NuGetRelease tool verifies that. Examples consume NuGet 0.1.* by default.
     Before publication, use the candidate feed produced by tools/NuGetRelease.
     Contributors may set CloudEdgeUseSource=true after building the bindings from source.
   -->