Directory.Build.props

<Project>

  <!-- ════════════════════════════════════════════════════════════════════════════
       .github CONSUMES THE ORG-SHARED BUILD CONFIG IT AUTHORS (.github#609).

       This repo is the SOURCE OF TRUTH for dist/dotnet/Directory.Build.props — the file
       scripts/sync-build-config.sh distributes to sdd / rendering / governance / templates /
       game / audio. Until this file existed, .github was the one repo NOT covered by the thing
       it wrote: none of its own .NET projects consumed it, so ADR-0032's
       DisableImplicitLibraryPacksFolder never applied here and the F# SDK's library-packs copy
       of FSharp.Core kept leaking into restores. That is not theoretical — it red CI with
       NU1403 on the coordination engine's first push (#608), and each of those projects then
       had to set the property BY HAND to get itself green. Those hand-set copies are gone now:
       the config is inherited, from one place, exactly as it is in every receiver.

       WHY THIS IMPORTS THE ORG FILE RATHER THAN MIRRORING IT.

       Every other repo receives a byte-identical COPY, kept honest by the drift check
       (sync-build-config.sh in check mode), which is a required gate there. .github cannot be a
       plain receiver of that check, because the check covers all three managed files and one of
       them, .config/dotnet-tools.json, pins fs.gg.coord.cli FROM THE FEED. .github builds that
       tool from source and deliberately does NOT depend on the feed that ships it (see
       src/FS.GG.Coord.Cli/FS.GG.Coord.Cli.fsproj): a broken feed must never be able to stop the
       coordination tool being fixed. Adopting the manifest here would trade that property away.

       So a mirrored copy would have no gate keeping it fresh — and a STALE copy of a build
       config is worse than no copy at all, because it looks adopted. An import cannot drift by
       construction: it reads the live source of truth, in the repo that owns it. That is the
       stronger form of the same guarantee, and the honest meaning of "the authority repo is a
       consumer of its own contract".

       REPO-SPECIFIC OVERRIDES GO BELOW THE IMPORT, in this file. The org file's own
       Directory.Build.local.props hook resolves against ITS OWN directory
       ($(MSBuildThisFileDirectory) there is dist/dotnet/), so it is not the hook to reach for
       from here. MSBuild is last-definition-wins, so a property set after the import overrides
       the org default — which is the same escape hatch a receiver gets, just spelled locally.

       (Note for editors, inherited from the org file: an XML comment may not contain a double
       hyphen, so CLI flags are named above without their leading dashes.)
       ════════════════════════════════════════════════════════════════════════════ -->
  <Import Project="$(MSBuildThisFileDirectory)dist/dotnet/Directory.Build.props" />

  <!-- ════════════════════════════════════════════════════════════════════════════
       FS.GG.Kit, FS.GG.Drivers AND coord-engine (FS.GG.Coord.Cli) ARE A COHERENT SET (.github#2402).

       Three packages that ship from this repo used to carry three independent, hand-advanced
       <Version> literals — one per .csproj/.fsproj. They frequently ship the same behaviour change
       (.github#2135 landed as two separate hand bumps twenty minutes apart: commits f26da6ed /
       d48e1ec2) and nothing compared the three literals to each other, so a bump to one and not the
       others was representable and, twice, happened. This property is the fix: ONE scalar, declared
       once, that all three project files resolve their own <Version> from
       ($(FsggCoherentSetVersion) below), so the three cannot diverge from EACH OTHER by construction
       — a change to one moves this property, which moves all three.

       THIS DOES NOT MERGE THE THREE PACKAGES, their release cadence, or their publish workflows —
       that is a separate, larger, deliberately deferred change (see .github#2402's follow-up; a
       single shared release trigger is a maintainer sequencing decision on the fleet's sole
       coordination-engine distribution path, not a call made here). This property only removes the
       ability for their VERSION NUMBERS to drift from one another; each package still builds, packs
       and publishes through its own existing workflow, at whatever cadence that workflow runs, at
       this one shared version.

       STARTING VALUE. `0.50.0` — one MINOR above `max(FS.GG.Kit 0.49.0, FS.GG.Drivers 0.18.0,
       FS.GG.Coord.Cli 0.23.0)` = `0.49.0` as of 2026-08-11, the highest of the three prior
       independent versions, so adopting the shared scalar cannot make any member appear to
       downgrade. It is NOT `0.49.0` itself: `0.49.0` was already the newest FS.GG.Kit published on
       nuget.org at declaration time, and `check-kit-published-coherence.py`'s PR arm requires any PR
       that edits `src/FS.GG.Kit/FS.GG.Kit.csproj` — which adopting this property necessarily does —
       to declare a version STRICTLY GREATER than what is already published (verified live: the PR
       that first tried `0.49.0` reproduced exactly this red). `0.50.0` satisfies both constraints at
       once. See docs/registry/compatibility.md for the full migration note. Advancing this property
       is now the ONLY way to bump any of the three packages' <Version>; do not reintroduce an
       independent <Version> literal in any of their project files —
       scripts/check-coherent-set-version.py gates exactly that, with gate-inversion evidence in
       tests/coherent-set-version/.

       WHY THIS LIVES BELOW THE ORG IMPORT, NOT IN IT. The imported dist/dotnet/Directory.Build.props
       is byte-identical across every receiver (sync-build-config.sh's subject); it carries no
       <Version> property today and must not gain one on this repo's behalf — FsggCoherentSetVersion
       names packages that exist ONLY in .github (ADR-0039 §5: .github is a producer here, uniquely
       among receivers). This is exactly the "repo-specific override goes below the import" escape
       hatch the comment above already describes, used for the first time.
       ════════════════════════════════════════════════════════════════════════════ -->
  <!-- 0.50.0 to 0.50.1 (.github#2451): a same-line patch bump. Required so check-kit-published
       coherence.py's PR arm sees a version STRICTLY GREATER than 0.50.0, already published on both
       feeds — this PR edits independent-review.md, a "kit:" source in registry/repos.yml. This PR
       also changes src/FS.GG.Coord.Core/Driver.fs and Review.fs, so coord-engine genuinely changes
       too; moving the whole coherent set together is honest rather than incidental, per the property
       group above's own rule (advancing this scalar is the ONLY way to bump any of the three). -->
  <!-- 0.50.3 to 0.50.4 (.github#2500): another same-line patch bump, same cause and shape as 0.50.2
       to 0.50.3 (3172d4ac). .github#2496 merged 182a2a62 after FS.GG.Kit 0.50.3 was packed at
       42c63af9, editing pnext-item/SKILL.md — a kit-packed source — so the published 0.50.3 kit
       drifted from canonical and check-kit-published-coherence reds on main. No engine source change;
       this bump exists solely to let the coherent set republish with current canonical content. -->
  <!-- 0.50.4 to 0.50.5 (.github#2504): same-line patch bump, same cause and shape as 0.50.3 to 0.50.4
       above — this PR edits pnext-item/SKILL.md, a kit-packed source, moving the live `delivery` call
       ahead of the `landable` wait so §6's merge order stays satisfiable now that `claim-generation`
       is a required status context (.github#1858). No engine source change; this bump exists solely to
       let FS.GG.Kit republish above the currently-published 0.50.4 with the corrected skill content. -->
  <!-- 0.50.5 to 0.50.6 (.github#2512): NOT the usual republish bump. 0.50.5 IS A PERMANENT
       TWO-OF-THREE SET and must not be adopted. The bump above moved this scalar and did NOT update
       FS.GG.Coord.Cli.fsproj's PackageReleaseNotes, which still opened "0.50.4" — so at release time
       check-engine-release-notes (.github#1762) correctly refused to publish the engine, AFTER
       FS.GG.Kit 0.50.5 and FS.GG.Drivers 0.50.5 had already published to the feeds. Tags are
       immutable and .github#1772's sibling-tag precondition requires all three tags at the SAME
       commit, so 0.50.5 cannot be completed from a corrected tree: correcting the notes needs a new
       commit, and that is a new version. This is exactly the 0.50.1 shape, recorded verbatim in
       registry/dependencies.yml. 0.50.6 is that corrected cut — notes and scalar moved TOGETHER,
       which is the whole point — and it is the version the fleet should adopt.

       WHY IT COULD HAPPEN AT ALL, AND WHAT NOW PREVENTS IT. A PR-time arm of that same checker
       already existed (.github/workflows/engine-release-notes.yml), but its `paths:` filter did not
       select THIS FILE — only the project file. A bump that lands solely here therefore ran none of
       it, and the gate first spoke at release time, which is after the irrevocable part. Both that
       filter and the checker's own PATHS_SUBJECT now name this file, and check-paths-coherence rule
       (c) plus tests/engine-release-notes/run.sh keep the two from drifting apart again. -->
  <!-- 0.50.6 to 0.50.7 (.github#2526): same-line patch bump, the ordinary republish shape — same cause
       as 0.50.3 to 0.50.4 and 0.50.4 to 0.50.5 above, NOT the two-of-three repair immediately above.
       This PR edits pnext-item/SKILL.md, a kit-packed source, correcting three prose claims that call
       `claim-generation` advisory-only when it has been a REQUIRED context since .github#1858. No
       engine source change and no behaviour change of any kind (AC4).

       WHY A NEW VERSION RATHER THAN RIDING 0.50.6. `kit-auto-publish` tags on merge to `main`, so
       0.50.6 was cut and published from .github#2512's merge commit 8de950c3 minutes before this
       branch merged `origin/main` — measured, not assumed: `git merge-base` in its ancestor-test form
       exits 1 for 5daf9126 against `kit/v0.50.6^{}`, and SKILL.md at that tag hashes e86617534873ba74
       and still contains
       "stays advisory in the engine's own rollup". The published FS.GG.Kit 0.50.6 is byte-faithful to
       its tagged tree; the tagged tree simply predates this fix. So the corrected skill body cannot
       reach receivers under 0.50.6, and republishing 0.50.6 is impossible (immutable tags). -->
  <!-- 0.50.7 to 0.51.0 (.github#2527): a MINOR bump, and the line change is the point. The three
       preceding cuts (0.50.5, 0.50.6, 0.50.7) were prose and release-notes corrections on the patch
       line. This one carries RECEIVER-VISIBLE BEHAVIOUR: the review protocol admits a case it
       previously refused, so `review` can return a different action for comment evidence a receiver
       already had, and the JSON render of `review` gains a `retiredChains` array.

       WHY NOT PATCH, given Protocol.fs does not move. The "no verb, flag, help entry, render name,
       result name or exit code moved" test the registry rows apply detects MOVED public surface; it
       does not detect ADDED behaviour, so it is necessary and not sufficient. The rule this cut
       follows is the one check-kit-published-coherence states itself: patch for a comment or doc
       edit, MINOR when the change is receiver-visible behaviour, a distinction no gate can draw for
       itself.

       CONSEQUENCE TO EXPECT, NOT A FAULT: kit-auto-publish admits only a same-line patch bump
       (.github#2442), so it will refuse this candidate with `candidate-not-next-patch`. That refusal
       is the rail working as designed; a coherent-set version publishes through .github#2409's
       release path instead, from three sibling tags at ONE commit.

       NOTES AND SCALAR MOVE IN THIS SAME COMMIT, which is .github#2512's requirement and the whole
       reason 0.50.5 is a permanent two-of-three set. -->
  <!-- 0.51.0 to 0.51.1 (.github#2533): a same-line PATCH bump, and the reason it is a patch is the
       rule check-kit-published-coherence states about itself. That item's kit-visible change is
       PROSE: `.claude/skills/pnext-item/references/merge-and-release.md` gains the table of which
       post-merge acts are automated on merge into `main`, and the rule that a pre-act stop condition
       on an automated act belongs in a PRE-MERGE gate. No engine verb, flag, help entry, render
       name, result name or exit code moves, and no receiver-visible engine behaviour is added; the
       item's other half is a new CI gate arm, which ships in this repository rather than in any
       package.

       WHY THE BUMP IS REQUIRED AT ALL, and why it was not required when this branch opened.
       check-kit-published-coherence.py's PR arm demands a `<Version>` STRICTLY GREATER than the
       newest STABLE FS.GG.Kit on nuget.org whenever a pull request edits a `kit:` source. That was
       satisfied for free while 0.51.0 was tagged and unpublished: the tree was legitimately ahead of
       the feed and this change rode into the pending release. `FS.GG.Kit 0.51.0` then PUBLISHED
       during this item's work, the feed caught up with the tree, and the ride-along stopped being
       available. An evidence claim has to hold at the commit it ships with, not the commit it was
       measured on; re-reading the feed before pushing is what caught this one.

       CONSEQUENCE TO EXPECT, AND IT IS THE OPPOSITE OF THE ENTRY ABOVE: kit-auto-publish admits a
       same-line patch bump (.github#2442), so unlike the 0.51.0 minor it refused, it will ADMIT this
       candidate and cut all three sibling tags at the merge commit itself. Confirmed by running
       `scripts/kit-auto-publish.py` over the post-merge facts rather than inferred from #2442's
       prose. That makes the release an AUTOMATED act, so this item's post-merge obligation is to
       VERIFY the published bytes against canonical, never to perform the release by hand. That
       distinction is the whole subject of .github#2533.

       NOTES AND SCALAR MOVE IN THIS SAME COMMIT, for the reason the entry above records. -->
  <!-- 0.51.1 to 0.52.0 (.github#2549): a MINOR bump, and the reason is the criterion the entry
       immediately above states about itself. That one was a patch because "no engine verb, flag, help
       entry, render name, result name or exit code moves, and no receiver-visible engine behaviour is
       added". This change moves two of those and adds the third:

         * a new RENDER NAME on the `fsgg.coord.review/1` wire — `state: "acceptedAwaitingChecks"`;
         * a new RESULT NAME on the same wire — `action: "authorizeDelivery"`;
         * receiver-visible engine behaviour: a well-formed, host-accepted chain whose checks are not
           green now reports that new state with `stateErrors: null`, where it previously reported
           `malformedEvidence` with `["review checks are not green"]`. A consumer switching on `state`
           sees a value it has never seen, and — more to the point — a consumer that treated
           `malformedEvidence` as "this chain is broken" was being told something false on every
           ordinary landing.

       It also adds one OPTIONAL input key, `facts.repairAssertionGranted`, read additively: a snapshot
       that omits it parses exactly as before, which is why this is a minor and not a major.

       CONSEQUENCE TO EXPECT, AND IT IS THE OPPOSITE OF THE ENTRY ABOVE. `kit-auto-publish` admits only
       a same-line PATCH bump (.github#2442), so it will REFUSE this candidate with
       `candidate-not-next-patch` and cut nothing. That refusal is the rail working, not a fault. The
       release is therefore a MANUAL coherent-set publish through .github#2409's path, exactly as the
       0.51.0 minor was — which means this item's post-merge obligation is to PERFORM the release and
       then verify it, not merely to verify an automatic one. Measured, not inferred from #2442's prose:
       `scripts/kit-auto-publish.py` was run over this candidate's facts and its refusal recorded on the
       pull request, on the same discipline the entry above used.

       A two-of-three set is permanent and uncompletable from a corrected tree — that is how 0.50.1 and
       0.50.5 became permanent gaps — so all three sibling tags publish at the SAME merge commit.

       NOTES AND SCALAR MOVE IN THIS SAME COMMIT, for the reason the entries above record.

       0.55.0 -> 0.56.0 is a MINOR. .github#2561 changes receiver-visible done-stamp behaviour for
       large closure and project-item sets: four previously bare GraphQL windows now refuse an
       incomplete read instead of silently deriving red, green, or NoStatus from a hidden tail.
       This new refusal boundary is observable coordination behaviour, so a patch would understate
       the change and the coherent set requires a real release.

       0.56.0 -> 0.57.0 is a MINOR. .github#2587 changes receiver-visible packed pnext-item review
       guidance: issue and pull-request body path/count/suite claims now require repository/revision
       and command/check provenance before they can serve as acceptance evidence. This is a new
       reviewer protocol boundary, not a correction to an existing description; the engine and
       drivers move only because all three packages are one coherent set.

       0.58.0 -> 0.58.1 is a PATCH, and .github#2571 is the item. The packed change is one correction
       to `pnext-item`'s `merge-and-release.md`: row 1 read `kit-auto-publish.yml`'s TRIGGER and stated
       its ACT, so it told every worker that the coherent-set release is something the merge always
       performs. It is not — `kit-auto-publish.py` admits only a same-line patch bump (.github#2442) and
       terminally refuses a minor, which every coherent-set release is. That is a FALSE CLAUSE removed
       from an existing description, not a new receiver protocol boundary, which is the distinction the
       0.56.0 and 0.57.0 entries above drew when they took minors. The behaviour change proper lives in
       `scripts/check-kit-published-coherence.py`, a CI gate this repository runs and the kit does not
       pack (`registry/repos.yml`'s `kit:` block does not name it), so no receiver's behaviour moves
       with it. .github#2533 — the same shape, a CI-gate change plus a section added to this same
       document — took a patch at 18af7595 for the same reason.

       CONSEQUENCE TO EXPECT, AND IT IS THE OPPOSITE OF THE 0.52.0 ENTRY ABOVE: 0.58.1 IS the next patch
       above both feed frontiers, so `kit-auto-publish` will cut all three sibling tags at the merge
       commit and the release is AUTOMATIC. This item's post-merge obligation is therefore to VERIFY
       that release against canonical, never to perform it — which is `merge-and-release.md`'s own
       patch-line rule, the item self-applying rather than exempting itself. Measured, not inferred:
       the frontier was read from nuget.org and `scripts/kit-auto-publish.py` was run over this
       candidate's facts, on the same discipline the entries above used. -->
  <!-- 0.58.1 to 0.59.0 (.github#2648): a MINOR bump that also SKIPS 0.58.1, and the two facts have
       different reasons. Read them separately, because collapsing them is how this cut gets
       mis-derived as "0.58.2, because 0.58.1 is burned".

       WHY THE LINE IS MINOR. The criterion is the one the 0.56.0 and 0.57.0 entries above apply: a
       patch when no receiver-visible engine verb, flag, help entry, render name, result name, exit
       code or behaviour moves, and a MINOR when a new receiver protocol boundary appears. The
       measurement span is the last commit any receiver actually restores — coord-engine/v0.58.0 at
       12ec83f8, the published frontier — because 0.58.1 reached no feed. Two legs decide it, and BOTH
       are about reachability rather than size:

         (1) RECEIVER-VISIBLE BEHAVIOUR MOVES, which the 0.50.7 to 0.51.0 entry states as its own rule
             ("MINOR when the change is receiver-visible behaviour"). Five defect fixes in this span
             change what a receiver observes from the engine it actually runs: .github#2575 (delivery
             reports a pending check as a CHECK, not a review problem), .github#2662 (a granted
             successor critic can record its verdict), .github#2683 (take walks its own ranked
             candidates after a lost claim CAS instead of giving up), .github#2678 (only LIVE claims
             count as implementer slots) and .github#2694 (no inventory is not an empty inventory).
             Verification: those five commits — 25ce038c, 682dc694, febcb5b6, 1624a011, c8e5ac3f — are
             among the unreleased engine commits `scripts/check-engine-freshness.py` lists at this
             head, so no receiver has any of them.

         (2) THE PACKED KIT ADDS A NEW RECEIVER PROTOCOL BOUNDARY, which is the 0.57.0 entry's exact
             shape — that cut took a minor for "a new reviewer protocol boundary, not a correction to
             an existing description" in packed `pnext-item` content. This span adds the
             finding-packet contract and the independent-review consolidation to that same skill.
             `pnext-item` genuinely reaches receivers: `scripts/generate-driver-manifest` asked with
             `which pnext-item` answers `FS.GG.Kit` at exit 0.

       WHAT THE .fsi COUNT IS, AND WHAT IT IS NOT. This span also adds 290 lines of public signature
       surface across five .fsi files: a new module, src/FS.GG.Coord.Core/Operation.fsi (154 lines,
       .github#2311), plus additions to Driver.fsi (37), StructuredDecision.fsi (37), Batch.fsi (37)
       and Delivery.fsi (26). Read that as CORROBORATION of legs (1) and (2), never as the criterion
       itself, because on its own it does not meet the criterion:

         * Operation IS NOT YET RECEIVER-REACHABLE. FS.GG.Coord.Core declares IsPackable false (its
           own fsproj) and ships as no package; FS.GG.Coord.Cli is PackAsTool, and a dotnet tool's
           payload is INVOKED, not referenced, so no consumer can open this module. Nothing in
           src/FS.GG.Coord.Cli references it either — it is slice 1 of 6 of .github#2311, and that
           fsproj says so itself: "Nothing compiled after it references it yet; slices 2 to 6 are its
           first callers." Public to the F# compiler is not the same fact as reachable by a receiver,
           and only the second one this criterion asks about.
         * ONLY Operation.fsi IS NEW. Batch.fsi, Delivery.fsi, Driver.fsi and StructuredDecision.fsi
           all exist at 12ec83f8 and were WIDENED — Batch.fsi is 264 lines there. An earlier draft of
           this entry called Batch.fsi new; it was wrong, and independent review caught it.
         * 26 OF THE 290 ARE ALREADY CLASSIFIED AS A PATCH. All 26 Delivery.fsi lines land in
           12ec83f8..a415652f, the 0.58.1 span, which the entry above called a false clause removed
           from an existing description.
         * THE WIRE SURFACE DID NOT MOVE AT ALL. Protocol.fs is byte-identical across this span, and
           check-engine-freshness reports 0 of the unreleased commits touching it.

       So do NOT read this entry as licensing "any new public module implies a minor". The 0.52.0
       entry's minor was for two names ON THE WIRE — `acceptedAwaitingChecks` and `authorizeDelivery`
       — and comparing a line count against it measures size where the criterion measures reach.

       Verification (flags named without their leading dashes, per this file's own header note — an
       XML comment may not contain a double hyphen): `git diff` with `stat`, and with
       `diff-filter=A name-only`, over `12ec83f8..HEAD` restricted to `src/FS.GG.Coord.Core/*.fsi` and
       to `src/`, the latter returning ONLY Operation.fs and Operation.fsi; `git show` of
       `12ec83f8:src/FS.GG.Coord.Core/Batch.fsi` piped to `wc -l` giving 264; `git diff` with `numstat`
       over `12ec83f8..a415652f` for Delivery.fsi giving 26 and over `a415652f..HEAD` giving nothing;
       `grep` for `Operation.` across src/FS.GG.Coord.Cli source matching no file.

       WHY 0.58.1 IS SKIPPED RATHER THAN COMPLETED, AND WHY THAT IS NOT WHAT SETS THE LINE. The
       0.58.1 cut tagged `kit/v0.58.1`, `drivers/v0.58.1` and `coord-engine/v0.58.1` at a415652f and
       published NOTHING: all three release workflows died on `release not found`, because
       `release-saga-prepare.yml` was `workflow_dispatch`-only and no operator had run it
       (.github#2654). Tags are immutable (.github#1772), so 0.58.1 cannot be re-cut to carry the
       commits that landed behind it, and the operator recorded the route on .github#2648 on
       2026-08-16: abandon it, bump past it, cut manually. But the line above would be MINOR even if
       0.58.1 had never been cut — legs (1) and (2) are what decide it, and neither one mentions the
       burned tag — so this bump is not "the next number after a burned one". That independence is
       measured in both directions rather than argued: all three defect-class fixes 1624a011,
       c8e5ac3f and febcb5b6 are absent from BOTH 0.58.0 and 0.58.1, so no route to a 0.58.2 patch
       exists, and the signature span measured from the burned tag instead of the frontier is still
       264 lines across four files including Operation.fsi. Verification: both feeds read directly at
       2026-08-16, nuget.org flat-container index and `orgs/FS-GG/packages/nuget/*/versions`; all
       three packages frontier `0.58.0` and NO `0.58.1` on either feed; `git merge-base` in its
       ancestor-test form for each of the three commits against `a415652f`.

       AND THAT IS WHY 0.58.1 GETS NO STANDING ADVISORY. $(FsggStandingAdvisories) warns consumers
       away from versions that PUBLISHED partially — 0.50.1, 0.50.5 and 0.52.0 each put real bytes on
       a real feed that a consumer can still resolve today. 0.58.1 put none anywhere, so there is no
       listing to warn from and nothing a consumer could adopt by accident. It is a three-of-three
       TAG-only gap, which is a repository fact recorded here, not a feed fact; adding it to the
       advisories would tell consumers to avoid something that does not exist.

       CONSEQUENCE TO EXPECT, AND IT IS THE 0.52.0 SHAPE, NOT THE 0.58.1 SHAPE. `kit-auto-publish`
       admits only a same-line PATCH bump (.github#2442), so it REFUSES this candidate and cuts
       nothing. Measured, not inferred from prose: `scripts/kit-auto-publish.py` was run over this
       candidate's facts and returned
       `{"action":"refuse","reason":"candidate-not-next-patch","version":"0.59.0","terminal":true}`.
       The release is therefore a MANUAL coherent-set publish through .github#2409's path —
       `release-saga-prepare.yml` by `workflow_dispatch` first, so the bytes exist, THEN the three
       sibling tags pushed together at one commit. Until that publish happens, `kit-auto-publish`
       stays red on `main` on its streak bound (.github#2435): that is the frontier rail working on a
       minor, the same as it did for 0.51.0, 0.52.0, 0.56.0 and 0.57.0, and it is not a regression
       introduced by this bump.

       NOTES AND SCALAR MOVE IN THIS SAME COMMIT, for the reason the entries above record — 0.50.1
       and 0.50.5 are permanent partial sets precisely because they did not. -->

  <!-- 0.59.0 to 0.60.0 (.github#2645): a MINOR bump, and it is owed because 0.59.0 PUBLISHED. Unlike
       the 0.58.1 entry above, this is not a skip past a burned tag: `kit/v0.59.0`, `drivers/v0.59.0`
       and `coord-engine/v0.59.0` were cut at 41199bd2 and all three packages serve 0.59.0 on
       nuget.org. `check-kit-published-coherence` requires declared STRICTLY GREATER than published,
       so a tree that edits a `kit:` source while still declaring 0.59.0 is refused: merging it would
       leave every `coordination-kit` receiver materializing 0.59.0 whose bytes no longer match
       canonical. This item edits two kit sources, so the bump is a precondition of landing it at all.

       WHY THIS BUMP BELONGS TO THIS ITEM AND NOT TO A RELEASE ROW. `check-engine-release-notes`
       requires the notes' first token to equal the evaluated Version, so notes and scalar must move
       together, and a standalone bump has no content to describe. Placeholder notes for a contentless
       bump are precisely the failure the engine project's own comment records at its release-notes
       property: a listing that announces the PREVIOUS release's break and none of its own. Notes and
       scalar drifting apart is what made 0.50.1 and 0.50.5 permanent two of three sets. .github#2451
       set the precedent in this exact situation, and this entry follows it: the item that has real
       receiver-visible content carries the bump that describes it.

       WHY MINOR RATHER THAN PATCH. Two legs, either of which would carry the line on the criterion
       the 0.56.0, 0.57.0 and 0.59.0 entries above used, and neither of which is a republish.

         * THE `claim` RECEIPT CHANGES WHAT IT REPORTS. `statusWrite` gains a FIFTH value, `withheld`,
           distinct from `failed` (which asserts a mutation was sent) and from `deferred` (which
           promises `flush` will land one); and `converged` stops meaning agreement with the literal
           column `In progress` and starts meaning agreement with the destination the projection
           derived. A consumer reading that JSON observes both. This is a change in what the tool
           reports for you, not an internal refactor.
         * THE PACKED KIT RETIRES A PREDICATE RECEIVERS COPY VERBATIM. The `pnext-item`,
           `intra-repo-parallel-work` and `drive-board` reference pages carried a start-gate `jq`
           predicate asserting `.status == "In progress"`, which every worker pastes as written. This
           release removes it, states that asserting the literal is a bug, and documents the
           `withheld` versus CLAIM-STATUS-LAG distinction that the fifth value makes necessary. A
           receiver whose copied predicate silently stops matching has been failed by a patch label.

       WHAT DID NOT MOVE, STATED SO THE LINE IS NOT MIS-READ. The `fsgg-coord-engine` wire surface is
       unchanged: no verb, flag, help entry, render name, result name or exit code moved. The new
       value is a new INHABITANT of an existing reported field, and the field's documented vocabulary
       is what this release widens. Verification: `git diff` with `name-only` over 41199bd2..HEAD
       matching no file under `src/FS.GG.Coord.Core/*.fsi`, and `Render.fsi`'s change being the added
       `withheld` case on the existing claim-receipt type.

       NOTES AND SCALAR MOVE IN THIS SAME COMMIT, for the reason every entry above records. -->
  <!-- 0.63.0 -> 0.64.0 (.github#2758): MINOR on the stable 0.x line. The packed
       `scripts/fsgg-coord` now stamps the dispatch-time agent-contract digest into a claim, while
       heartbeat and re-claim preserve that original attribution instead of replacing it with the
       contract active in a later process. A receiver therefore gets changed coordination behavior,
       not a prose correction. The marker grammar is additive, the legacy absence remains accepted,
       and no command, flag, member, destination, or package identity is removed, so this is not a
       major. Main, all four immutable tag namespaces, GitHub Packages, nuget.org, and the registry
       independently put the previous coherent release at 0.63.0 before this move. -->
  <!-- 0.64.0 -> 0.65.0 (.github#2770): MINOR on the stable 0.x line. The packed pnext-item
       skill gains a new required worker action and a new linked measurement-discipline member for
       evidence assertions. That is the same additive required-action shape classified as MINOR by
       the Kit's 0.20.0 -> 0.21.0 precedent, not a prose-only correction. No command, wire value,
       existing package member destination, or runtime behavior is removed, so this is not a major.
       Main, all four immutable tag namespaces, GitHub Packages, nuget.org, and the registry
       independently put the complete predecessor at 0.64.0 before this next-minor move. -->
  <!-- 0.65.0 -> 0.66.0 (.github#2757): MINOR on the stable 0.x line. The packed pnext-item
       findings contract adds a new terminal disposition with four required conditions and assigns
       who may declare it at each workflow boundary. Receivers therefore make a new stopping
       decision rather than reading corrected prose about an existing action. This matches the
       additive required-behavior precedent used for 0.65.0; no command, member, destination, or
       runtime implementation is removed. -->
  <!-- 0.66.0 -> 0.67.0 (.github#2756): MINOR on the stable 0.x line. The coordination engine and
       packed Kit add an append-only review-wait wire contract, a new `review wait` writer/projection,
       and the ordinary fresh-successor action. These are additive receiver-visible protocol and
       command behaviors; legacy structured succession records remain readable and no command,
       package member, destination, or identity is removed. -->
  <!-- 0.67.0 -> 0.68.0 (.github#2794, producers .github#2797/.github#2772): MINOR on the stable 0.x line.
       The coordination engine preserves an exhausted ordinary round-three review across claim turnover,
       projects that exhausted phase explicitly, and authorizes exactly one structured escalation for a
       fresh claimant after validating the old claim's complete chain and wait evidence. It also repairs the
       forced-claim transition so repair-phase latest-review/backlink validation remains coherent after that
       escalation. These four merged engine commits add or repair receiver-visible review behavior;
       Protocol.fs is unchanged and no command, member, destination, or package identity is removed. -->
  <!-- 0.68.0 -> 0.69.0 (.github#2807): MINOR on the stable 0.x line. The coordination engine
       corrects the fresh-claim ordinary-exhaustion authorization so the historical initial and
       confirmation records retain their own advancing heads while the escalation, completed wait,
       legacy exhaustion evidence, and live PR remain bound to the exact round-three head. The
       production writer now also proves readable noncontiguous history and a malformed legacy
       confirmation backlink refuse before writes. This repairs receiver-visible review behavior;
       no command, member, destination, or package identity is removed. -->
  <!-- 0.69.0 -> 0.70.0 (.github#2801): MINOR on the stable 0.x line. The coordination kit makes
       reciprocal overlap waits automatically enforceable: one generation-bound room, live-lease
       host precedence, claim-preserving loser narrowing, production mutation freezes, and guarded
       winner-land/rebase/re-overlap/re-widen recovery. It also makes the single Coordination-board
       orchestrator lease executable, caller-bound, race-safe, and able to project external blocking
       requests to the board's highest safe severity. Additive commands/policy; no identities removed. -->
  <!-- 0.70.0 -> 0.71.0 (.github#2813): MINOR on the stable 0.x line. Release preparation now
       resolves the live promoted coherent-set receipt before packing, binds predecessor version plus
       content identity into the manifest, and rejects stale/missing/contradictory authority and stale
       draft retries. This is additive release-orchestration behavior. Version 0.70.0 remains a poisoned,
       unpromoted immutable package/tag set; 0.71.0 is its forward-only recovery. -->
  <!-- 0.71.0 -> 0.72.0 (.github#2753): MINOR on the stable 0.x line. The coordination client adds
       file-backed create and explicit-id amend comment mutation, authoritative UTF-8 length/SHA-256
       readback, and per-operation recovery capabilities. Packed skills adopt this verified route in
       place of raw comment mutation. Additive behavior; no command or package identity is removed. -->
  <!-- 0.72.0 -> 0.73.0 (.github#2830): MINOR on the stable 0.x line. The coordination engine adds
       typed review/delivery lifecycle authority, exact completion receipts, digest-bound candidate
       self-hosting, bounded change-completeness gates, and receiver release recovery. Packed skills
       adopt the terminal delivery-apply route and stop treating standalone `done` as completion.
       Receiver-visible behavior changes additively; no package, command, or member identity is removed. -->
  <!-- 0.73.1 -> 0.73.2 (.github#2639): PATCH refresh for the generated FS.GG.Drivers manifest after
       the published Rendering skill-delivery channel updates the packed publishing-and-deployment skill. -->
  <!-- 0.73.2 -> 0.74.0 (.github#2876): MINOR on the stable 0.x line. Five unreleased engine
       commits make dependency projection atomic and authoritative at the Ready write boundary,
       extract lifecycle handling behind a typed completion dependency, and make review refusals
       name their actionable remediation. These are additive receiver-visible coordination semantics;
       Protocol.fs and all command/package identities remain unchanged. -->
  <!-- 0.74.0 -> 0.75.0 (.github#2835): MINOR on the stable 0.x line. The coordination engine
       canonicalizes documented severity input before validation and external writes, resumes the
       bounded legacy receipt/intent representation through complete board projection, and preserves
       an issue-bound recovery diagnostic when creation succeeds before receipt persistence. The
       packed Kit corrects the intake template to the board's canonical severity vocabulary. These
       are additive and repaired receiver-visible behaviors; no command, package, or member identity
       is removed. -->
  <!-- 0.75.0 -> 0.75.1 (.github#2859): PATCH on the stable 0.x line. The packed coordination-kit
       review guidance now routes queue entry through the host-owned engine boundary, preserves the
       canonical generation-token contract, and makes structured-record completion evidence
       unambiguous. The engine adds the matching derived-entry and normalization controls. Additive
       repair; no command, package, or member identity is removed. -->
  <!-- 0.75.1 -> 0.75.2 (.github#2908): PATCH on the stable 0.x line. The receiver wrapper now binds
       tier-4 engine selection to its own tool manifest from any caller cwd, verifies and executes the
       exact restored assembly, and emits deterministic resolution evidence. Additive routing and
       observability repair; no command, package, member, or identity is removed. -->
  <!-- 0.75.2 -> 0.75.3 (PR #2947): PATCH repack required by the post-merge packaging workflow.
       Its embedded release notes described only the documentation merge even though the immutable
       package also contained nine accumulated engine commits. The published bytes remain valid, but
       their bounded narrative cannot be rewritten under the same NuGet version. -->
  <!-- 0.75.3 -> 0.75.4 (.github#2941): forward-only PATCH repair on the stable 0.x line. It accurately
       announces the nine engine commits already present in 0.75.3: atomic serialized Blocked-by set
       mutations, exact-check landable diagnostics, and exact-default-branch-SHA completion gating.
       Recutting 0.75.3 would violate immutable package identity, so 0.75.4 is the first version whose
       own listing tells the complete story. Protocol.fs, package identities, commands, and members
       remain unchanged. -->
  <!-- 0.75.4 -> 0.75.5 (.github#2983): PATCH on the stable 0.x line. Three compatible lifecycle defect
       repairs ship: post-merge verification now classifies successful completed runs correctly;
       completion provenance preserves GraphQL's full merge object id so it can equal the full REST
       merge_commit_sha; and closed-item delivery reads authoritative issue Paths while preserving
       unread-versus-undeclared state. Protocol.fs has zero commits across the span; package identities,
       commands, flags, schemas, exits, and public members remain unchanged. Typed SDD P5 stays deferred
       until OperatingV2 and no provider/receiver default changes in this cut. -->
  <!-- 0.75.5 -> 0.76.0: MINOR on the stable 0.x line. FS.GG.Kit adds the
       initialize-sdd-workspace skill as a new materialized member. It guides a freshly scaffolded
       repository through deferred local and optional GitHub configuration and clears the scaffold's
       pending initialization marker. Existing kit members, destinations, engine commands, flags,
       schemas, exits, and public members remain unchanged. Drivers and Coord.Cli advance with the
       coherent scalar; their payload behavior is otherwise unchanged. -->
  <!-- 0.76.0 -> 0.77.0 (ADR-0079): MINOR on the stable 0.x line. The packed
       pnext-item delivery contract replaces mandatory external critic authorization with one
       Accountable Delivery Owner. Exact-head critique, repair, and host-acceptance records remain
       required evidence through distinct phase identities, while no second person, account, agent,
       or approval quorum is required. This changes receiver-visible delivery behavior without
       removing a package, command, member, schema, or technical gate. -->
  <!-- 0.77.0 -> 0.78.0: MINOR on the stable 0.x line. The intake command now
       canonicalizes Class through the shared issue/Projects vocabulary and can recover explicitly
       declared legacy drafts after a partial create. Recovery requires the receipt-bound exact
       predecessor body, re-reads the canonical PATCH, and advances the receipt before projection.
       The packed coordination skills remove the unprojectable `capability` example. -->
  <!-- 0.78.0 to 0.78.1: mandatory post-merge patch bump and local pack after the
       documentation-only orchestration visualization design in PR #3138. No package behavior
       changes; the fresh identity belongs to the required post-merge verification artifacts. -->
  <!-- 0.79.0 -> 0.80.0 (.github#3189): MINOR on the stable 0.x line. The packed pnext-item and
       work-roadmap skills add receiver-visible lifecycle telemetry for every normal FS.GG item and
       roadmap unit: digest-chained external phase authority, exact runtime/model/toolchain versions,
       discrete durations, and authoritative token reconciliation. Candidate heads no longer attempt
       to contain future review/merge facts; immutable repository logs are projections only. -->
  <!-- 0.80.0 -> 0.80.1 (.github#3199/.github#3201): PATCH. The packed pnext-item and work-roadmap
       supervision contract now makes post-response usage reconciliation an enforceable parent gate:
       a child returns an unposted terminal draft, the parent harvests the completed Codex JSONL or
       Claude SubagentStop record, and host acceptance, cycle completion, and Done fail closed until
       measured or strictly qualified unavailable telemetry is sealed. This repairs lifecycle evidence
       enforcement without changing a coordination-engine wire command, flag, result, or exit code. -->
  <!-- 0.80.1 -> 0.81.0 (.github#3208): MINOR on the stable 0.x line. The coordination engine adds
       the typed telemetry usage/lifecycle/summary and bounded roadmap-close command families, and
       compiles critique/feedback validation into the immutable tool package. Existing Python skill
       helpers remain frozen oracles until this command-bearing release is published and verified. -->
  <!-- 0.81.0 -> 0.81.1 (.github#3208): PATCH. This is the publish-before-adopt completion: packed
       callers now invoke the already-published compiled telemetry surface, cycle-ledger provider
       validation no longer shells out, and the compatibility helper payload is removed. No command,
       option, result, or exit-code vocabulary changes. -->
  <!-- 0.81.1 -> 0.82.0 (.github#3209): MINOR on the stable 0.x line. The coordination engine adds
       the receiver-visible telemetry qualification validate/run command family, a strict closed
       execution manifest, content-addressed claim evidence, independent mutation fixtures, exact
       checkout/tool/executor identity, converged GitHub run/job/check observations, and typed
       current-head PR obligation comments. This is additive public behavior and therefore not a
       patch under the same criterion used for 0.81.0. -->
  <!-- 0.82.0 -> 0.83.0 (.github#3210): MINOR on the stable 0.x line. The coordination engine adds
       typed roadmap work-unit preparation and acceptance commands. They compile authoritative
       roadmap/catalog bytes into deterministic staged intake drafts, validate qualification,
       lifecycle, critique, SDD, and revision evidence, and seal one atomic acceptance bundle. -->
  <!-- 0.83.0 -> 0.83.1 (.github#3233): PATCH. Work-unit preparation now accepts an ordered partial
       catalog that omits already-accepted historical roadmap rows while preserving canonical order,
       first-unchecked selection, and immediate-prerequisite validation. No command, option, result,
       or exit-code vocabulary changes. -->
  <!-- 0.83.1 -> 0.83.2 (.github#3242): PATCH. Live work-unit acceptance no longer treats ignored
       generated SDD outputs as candidate-tree authority; the independent exact-revision observer
       still regenerates, validates, and canonical-compares every required SDD result. No command,
       option, result, or exit-code vocabulary changes. -->
  <!-- 0.83.2 -> 0.83.3 (.github#3247): PATCH. Roadmap acceptance now gives the immutable acceptance
       envelope its own post-create comment identity, binds qualification to the preceding structured
       review authority, and reads the SDD work identity from the current structured route ledger.
       No command, option, result, or exit-code vocabulary changes. -->
  <!-- 0.83.3 -> 0.83.4 (.github#3251): PATCH. Compiled roadmap acceptance now supports one immutable
       unit PR fulfilling implementation and acceptance, derives its repository from the applied unit
       registration, and accepts the unit's canonical work-cycle critique before the final evidence
       commit. No command, option, result, or exit-code vocabulary changes. -->
  <!-- 0.83.4 -> 0.83.5 (.github#3255): PATCH. Roadmap acceptance validates the native SDD 1.5.0
       analyze, verify, and ship artifact shapes, permits only non-blocking readiness warnings, rejects
       hidden index state, and runs production qualification in a disposable exact-candidate clone.
       No command, option, result, or exit-code vocabulary changes. -->
  <!-- 0.85.0 -> 0.85.1 (.github#3274): PATCH. Exact-head review acceptance now survives a live base
       advance only when complete GitHub comparisons prove it is forward-only and path-disjoint from
       the reviewed candidate. Rewrites, overlap, conflicts, truncation, stale authority, and unreadable
       evidence still fail closed. No command, option, result, or exit-code vocabulary changes. -->
  <!-- 0.85.1 -> 0.85.2 (.github#3286): PATCH. Guarded delivery recognizes the existing typed
       acceptance-receipt obligation as the narrowly fenced markerless implementation phase of a
       single-owning-item two-phase flow. All other authority remains mandatory, and terminal completion
       still requires canonical closing linkage from the later receipt PR. No command, option, result,
       or exit-code vocabulary changes. -->
  <!-- 0.85.2 -> 0.86.0 (.github#3330): MINOR on the stable 0.x line. The packaged roadmap and board
       drivers plus pnext-item add the reduced one-owner route for explicitly admitted routine,
       reversible source work. Protected operations and non-routine items retain the strict
       claim/review/completion route. The coordination engine's command, option, result, and exit-code
       vocabulary is unchanged; all three packages advance together under the coherent-set rule. -->
  <!-- 0.86.0 -> 0.86.1 (R5 release preparation): PATCH. The routed board drivers now reserve the
       three-round fresh implementer/critic repair chain for strict items, removing the last wording
       that could send routine work back through strict ceremony. No coordination-engine command,
       option, result, or exit-code vocabulary changes; all three packages advance together under the
       coherent-set rule. -->
  <!-- 0.86.1 -> 0.87.0 (UTEL-06.5 release preparation): MINOR on the stable 0.x line. The coherent
       set adds prospective host-local SQLite telemetry commands, repository-owned Codex lifecycle
       observation, exact-head CI population reconciliation, and machine-derived whole-item budget
       inputs. Telemetry remains advisory and future-only; all three packages advance together. -->
  <!-- 0.87.0 -> 0.88.0 (standalone telemetry L1 source preparation): MINOR on the stable 0.x line.
       The coordination CLI adds explicit private workspace association, local or HTTPS destinations,
       prospective cutover and advisory workflow capture. This is source/package validation, not a
       published coherent release claim; all three package identities advance together. -->
  <!-- 0.88.0 -> 0.89.0 (SVG-WORKSPACE-01.2 shared producer): MINOR on the stable 0.x line.
       FS.GG.Drivers adds the closed routine policy/helper/native-check workspace payload required by
       installed work-roadmap receivers. FS.GG.Kit and FS.GG.Coord.Cli advance unchanged because the
       three package identities share one coherent version and release transaction. -->
  <!-- 0.91.1 -> 0.91.2 (UTEL-ROOT): PATCH release for the opt-in exact native root
       telemetry launcher and bounded JSONL frame classification. All three package identities
       move as one coherent set; earlier published archives remain immutable. -->
  <!-- 0.91.2 -> 0.91.3 (UTEL-OUTCOME): PATCH release for schema-10 native orchestration
       outcome ingestion and dashboard projection. The CLI, Drivers and Kit move together so
       the installed public stage can read both migrated private Host workspaces. -->
  <!-- 0.91.3 -> 0.91.4 (UTEL-GROUP): PATCH release for prospective roadmap member
       originals and canonical completed-group projection. The CLI, Drivers and Kit move
       together; a reviewed assignment and real delivery remain required for live evidence. -->
  <!-- 0.91.4 -> 0.91.5: PATCH coherent successor. Rebuild the CLI against the
       centrally pinned FSharp.Core 10.1.401 required by FCS 43.12.401, and ship
       accumulated compatible telemetry and driver updates in all three members. -->
  <!-- 0.91.5 -> 0.92.0 (SKILL-FS-01.5): MINOR coherent successor. The CLI adds
       read-only, bounded telemetry configuration discovery for installed skill
       workflows. Drivers and Kit move with it as one coherent set. -->
  <!-- 0.92.0 -> 0.93.0 (SKILL-FS-01.5): MINOR coherent successor. Supported
       skill callers use the packaged F# telemetry and preflight commands, while
       protected native collection provenance advances with the coherent set. -->
  <!-- 0.93.0 -> 0.94.0 (SKILL-FS-01.6): MINOR coherent successor. Drivers
       removes the retired Python skill-helper implementations and compatibility
       wrapper after every supported caller moved to the packaged F# commands. -->
  <!-- 0.94.0 -> 0.95.0 (COORD-BOARD-V2-01.4): MINOR coherent successor.
       Kit and Drivers add gated organization-only V2 inspection guidance; the CLI
       adds the structurally read-only board-v2 inspect command. No live population
       adoption or hosted activation is implied by this source version. -->
  <!-- 0.95.0 -> 0.96.0 (UTEL-H3): coherent source successor carrying the
       telemetry CI legacy-default selection repair. Publication and installed
       consumer adoption remain separate from this source version. -->
  <PropertyGroup>
    <FsggCoherentSetVersion>0.103.0</FsggCoherentSetVersion>
  </PropertyGroup>

</Project>