chore: write each package's changelog section into its NuGet release notes

AGENTS.md

@@ -26,10 +26,10 @@ so moving a project cannot silently retarget a test.
 - `test/CodoMetis.ValueRanges.EFCore.PostgreSQL.IntegrationTests/` — Live PostgreSQL via Testcontainers (needs Docker; Inconclusive without, but hard failure under CI=true). The shared container runs `VALUERANGES_POSTGRES_IMAGE`, default `postgres:16-alpine` (the 10.x floor); CI runs both integration projects on 16 and 18, and a server below 16 fails every test (`PostgresServer.cs`). Covers BCL and NodaTime types. Authority on PostgreSQL semantics — run when changing translations or range algebra. `CapturedCollectionProbeTests` sends every discovered range and set type as a captured collection (`Contains`, `Any`, `Count`); it links `RangeProbes` and `SetProbes` from the conventions project rather than copying them. `ComplexIndexesCrossTests` holds this package's columns under `EFCore.ComplexIndexes.PostgreSQL`'s temporal and exclusion constraints and GiST indexes on PostgreSQL 16 and 18 (containers of its own) through a test-only reference; neither shipping package references the other. Off on the 11 line (the reference and the file are conditioned on `net10.0`) until ComplexIndexes ships its own 11 preview, CaffeinatedCoder/EFCore.ComplexIndexes#38; its #42 turns them back on
 - `test/CodoMetis.ValueRanges.EFCore.PostgreSQL.InfinityDisabled.IntegrationTests/` — The same live layer for configuration that is per process: its runtimeconfig sets `Npgsql.DisableDateTimeInfinityConversions`, which Npgsql and the plugin each read once, so it cannot be flipped inside the other project's run. Holds the temporal store rule at the extremes with the conversion off. Own container; CI's integration job runs every `test/*IntegrationTests/`
 - `test/CodoMetis.ValueRanges.AspNetCore.Tests/` — Host-level behaviour with no ValueRanges registration: configuration binding (`TypeConverter`), MVC and minimal-API binding and JSON bodies via `TestServer`, and the documented OpenAPI schema transformer (`ValueRangesSchemaTransformer.cs`), which `docs/serialization.md` must carry verbatim — edit the test copy, then the doc. `HostCultureProbeTests` binds every discovered type (core and NodaTime) through both hosts under four request cultures; it links `RangeProbes`, `SetProbes`, `WrapperElements` and `Reflect` from the conventions project rather than copying them
-- `test/CodoMetis.ValueRanges.Conventions.Tests/` — Repo-level conventions: changelog consistency and form, packaging metadata, release wiring, the SECURITY.md supported-versions table, value set contract compliance, EF mapping parity, translator dispatch (`TranslatorDispatchSweepTests`: every public query member over every type, each operand mapped as its declared type), the default JSON contract. Everything is discovered (projects by globbing `src/`, types by reflection), so adding a package or a type needs no edit here
+- `test/CodoMetis.ValueRanges.Conventions.Tests/` — Repo-level conventions: changelog consistency and form, packaging metadata (each package's nuspec, generated by NuGet's own pack task, carries its version's changelog section as release notes), release wiring, the SECURITY.md supported-versions table, value set contract compliance, EF mapping parity, translator dispatch (`TranslatorDispatchSweepTests`: every public query member over every type, each operand mapped as its declared type), the default JSON contract. Everything is discovered (projects by globbing `src/`, types by reflection), so adding a package or a type needs no edit here
 - `test/oracles/` — The bug-finding system (`docs/oracles.md`): `claims.json` quotes every promise the consumer-facing docs make and names the test that holds it (empty `heldBy` is the worklist); `oracles.json` registers the sweep classes; `seeds/*.patch` plant one defect each in `src/` that the named oracles were shown to catch; `surface-waivers.json` names the public members no claim covers, with the reason; `candidates.json` holds disagreements found but not fixed, keyed to issues; `compiled-out.json` records a test class a project compiles out on this line (a `heldBy` must be compiled, so its claims count as unheld) with the issue that compiles it back; `postgres-surface.json` holds every PostgreSQL range, multirange and array operator and function (one entry per row of `postgres-surface.catalog.txt`, the raw `pg_operator`/`pg_proc` listing) with the member that mirrors it, the translation a test asserts, or a waiver or issue; `translation-support.json` is the other direction: every public query member (`QueryMembers`, discovered from the public API, one key per overload) classified as running as SQL, in memory only (with the reason) or planned (with the issue), which `TranslationSupportInventoryTests` holds complete and `TranslationSupportProbeTests` (integration) holds true against EF Core over every closed type; `CloneSweep.cs` is the clone-divergence sweep over the hand-copied type families (sets, arities, ranges, EF registrations), and `clone-waivers.json` explains every divergence it finds between siblings that is right as it is. `Oracle*Tests` and `CloneDivergenceTests` in the conventions project hold all of it consistent in CI without building; `dotnet run tools/oracles.cs seeds` re-proves locally that every seed is caught, `… status` prints the worklist, `… pg-surface` regenerates the listing from a container, `… clones` prints the sibling divergences with their waiver status
 - `tools/oracles.cs` — The local prover and status report for `test/oracles/`; file-based app, never run in CI
-- `test/consumer-smoke-test.sh` — The only check of *delivery* rather than code: packs the four packages, restores them into throwaway projects created outside the repository (inside it, `Directory.Build.props` would apply), compiles and runs real code against them, and asserts on printed output and translated SQL — never on the exit code alone. Five consumers: core only; a Native AOT publish of core + NodaTime, run as a native binary (extra linker paths via `SMOKE_AOT_LINKER_ARGS`, e.g. for Homebrew's dotnet); the NodaTime EF satellite, which pulls in all four through the nuspec chain; `samples/Bookings` run as a web app against its own PostgreSQL container (`VALUERANGES_POSTGRES_IMAGE`; skipped without Docker, a failure under `CI=true`), asserting every response, SQL line and stored row `docs/walkthrough.md` shows; and the EF package beside `EFCore.ComplexIndexes.PostgreSQL` from nuget.org, asserting its exclusion and temporal constraints over this package's columns in the create script (skipped on the 11 line until CaffeinatedCoder/EFCore.ComplexIndexes#38, like `ComplexIndexesCrossTests`). `NUGET_PACKAGES` is redirected to a private folder because NuGet resolves id+version from the global cache before any source, so a locally built package is otherwise shadowed by whatever build of that version was restored before; the generated `nuget.config` uses package source mapping so this repo's ids come from the local feed only and everything else from nuget.org. Runs on every PR in both modes (own feed; the pre-built `dist` the release workflow passes). Everything is discovered (projects by globbing `src/`, types by reflection), so adding a package or a type needs no edit here
+- `test/consumer-smoke-test.sh` — The only check of *delivery* rather than code: packs the four packages, restores them into throwaway projects created outside the repository (inside it, `Directory.Build.props` would apply), compiles and runs real code against them, and asserts on printed output and translated SQL — never on the exit code alone. Before the consumers it reads each `.nupkg`'s nuspec: the release notes open with the version's changelog section in plain text and end with the changelog at the version's tag. Five consumers: core only; a Native AOT publish of core + NodaTime, run as a native binary (extra linker paths via `SMOKE_AOT_LINKER_ARGS`, e.g. for Homebrew's dotnet); the NodaTime EF satellite, which pulls in all four through the nuspec chain; `samples/Bookings` run as a web app against its own PostgreSQL container (`VALUERANGES_POSTGRES_IMAGE`; skipped without Docker, a failure under `CI=true`), asserting every response, SQL line and stored row `docs/walkthrough.md` shows; and the EF package beside `EFCore.ComplexIndexes.PostgreSQL` from nuget.org, asserting its exclusion and temporal constraints over this package's columns in the create script (skipped on the 11 line until CaffeinatedCoder/EFCore.ComplexIndexes#38, like `ComplexIndexesCrossTests`). `NUGET_PACKAGES` is redirected to a private folder because NuGet resolves id+version from the global cache before any source, so a locally built package is otherwise shadowed by whatever build of that version was restored before; the generated `nuget.config` uses package source mapping so this repo's ids come from the local feed only and everything else from nuget.org. Runs on every PR in both modes (own feed; the pre-built `dist` the release workflow passes). Everything is discovered (projects by globbing `src/`, types by reflection), so adding a package or a type needs no edit here
 - `samples/Bookings/` — The minimal-API booking service `docs/walkthrough.md` walks through. Not in the solution: `samples/Directory.Build.props` stops the repo's props, the smoke test runs it against the packed packages, and `WalkthroughSampleTests` (integration) links its source to hold the page's claims. `WalkthroughSampleConventionTests` fails when a C# block on the page is not a contiguous run of the file its `<!-- sample: … -->` marker names, when an output block on the page is not asserted by the smoke test, or when `Bookings.csproj` names another package version than the newest release on nuget.org (`PackageValidationBaselineVersion`) or another framework than that release's. GitHub's dependency submission restores every project from nuget.org, so an unreleased version fails it; move the sample with the baseline after each release, and regenerate its migration with that release's EF Core tools when the major changes (an EF Core 11 snapshot does not compile against EF Core 10). The smoke test moves the copy to `Version` and this line's framework
 - `docs/` — Agent docs (read relevant doc before starting work)
 - `site/` — The documentation site (DocFX, `.github/workflows/docs.yml`): builds both lines from `main`'s config into `/10.x/` and `/11.x/` on GitHub Pages, from the Markdown as it is. Lives on `main` only and is never cherry-picked. Broken links fail the build; a new page goes into `site/toc.yml` (CONTRIBUTING.md#the-documentation-site)
@@ -48,6 +48,14 @@ surface of the shipping projects — the shipped `.xml` is what IntelliSense sho
 internal-API usage (EF1001) is acknowledged with a file-level pragma next to the reason, never
 repo-wide.
 
+Pack writes each package's release notes (nuget.org's Release Notes tab, Visual Studio's Updates
+tab) from the `## [$(Version)]` section of its own `src/<package>/CHANGELOG.md`, through the target
+in `Directory.Build.targets`. They are plain text, because nuget.org shows release notes as typed
+and links only bare URLs: a link becomes `text (url)`, and backticks, bold and `###` are dropped.
+Pack fails, naming the file, when the section is missing, empty, doubled or over nuget.org's
+35,000 characters, so a version bump needs its section in all four package changelogs before
+`dotnet pack` runs. Never set `PackageReleaseNotes` anywhere else.
+
 ## Workflow
 1. Read `docs/architecture.md` before modifying range types or interfaces
 2. Explore the codebase — range operations are per-shape (Finite, UnboundedStart, etc.)

CHANGELOG.md

@@ -53,6 +53,7 @@ The first preview of the 11 line: the same public API as 10.0.0, on .NET 11. Not
 - EF Core: an empty captured list of ranges or sets reads no rows through EF Core 11's own `SELECT … WHERE FALSE`; the SQL differs from 10.x, the answers do not ([Captured lists](https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/docs/efcore.md#match-a-column-against-a-list-of-sets)).
 - Docs: each package's Project website link on NuGet opens the [documentation site](https://caffeinatedcoder.github.io/CodoMetis.ValueRanges/), and its README links the site and the [walkthrough](https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/docs/walkthrough.md).
 - Docs: a value set over your own element type, other than `StringSet<TElement>`, needs a `CompareTo` that orders values as the underlying type does, because the database sorts the underlying values ([Value sets](https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/docs/value-sets.md#how-your-element-types-sort-and-serialize)).
+- Packaging: a package's release notes on nuget.org and in Visual Studio are its version's section of its changelog, in plain text, ending with a link to the changelog at the version's tag, where they were a link to the latest changelog ([Changelog](https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/CHANGELOG.md)).
 
 ### Fixed
 

CONTRIBUTING.md

@@ -223,7 +223,9 @@ fails outright.
 
 A version's section of the root `CHANGELOG.md` is the GitHub release's notes, word for word, so it
 is written for someone deciding what to change before they upgrade. The package changelogs use the
-same form, with the entries that affect that package.
+same form, with the entries that affect that package, and a package's section is its release notes
+on nuget.org and in Visual Studio: pack writes it into the nuspec in plain text, because nuget.org
+shows no Markdown, and fails when the section is missing or empty (`Directory.Build.targets`).
 
 - **The heading** is `## [x.y.z] — yyyy-mm-dd`. Write entries under the version being prepared,
   never under `Unreleased`. The date is the tag's: set it in all five changelogs in the commit that
@@ -242,7 +244,7 @@ same form, with the entries that affect that package.
   where it helps a reader skim (`JSON:`, `Literals:`, `EF Core:`, `NodaTime:`). In `Added`, lead
   with the new member in bold.
 - **Keep each section in area order:** `Ranges`, `Value sets`, `Literals`, `JSON`, `ASP.NET Core`,
-  `EF Core`, `NodaTime`, `Docs`, so a reader finds an area's lines together. In `Added`, the core
+  `EF Core`, `NodaTime`, `Docs`, `Packaging`, so a reader finds an area's lines together. In `Added`, the core
   members come first, then `EF Core:`, then `Docs:`. Use no headings below the three sections.
 - **End with a link** to the guide that explains it. Links are absolute
   (`https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/docs/…`), because the

Directory.Build.props

@@ -8,10 +8,8 @@
         <PackageProjectUrl>https://caffeinatedcoder.github.io/CodoMetis.ValueRanges/</PackageProjectUrl>
         <RepositoryUrl>https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges</RepositoryUrl>
         <RepositoryType>git</RepositoryType>
-        <!-- Each package's own changelog, which is short enough to read on the NuGet page's link.
-             The project directory is named after the project, so this resolves for every package
-             under src/; PackagingConventionTests checks that it does. -->
-        <PackageReleaseNotes>https://github.com/CaffeinatedCoder/CodoMetis.ValueRanges/blob/main/src/$(MSBuildProjectName)/CHANGELOG.md</PackageReleaseNotes>
+        <!-- PackageReleaseNotes is set at pack time from the version's section of the package's own
+             CHANGELOG.md, by the target in Directory.Build.targets. Nothing sets it here. -->
     </PropertyGroup>
 
     <!--