Bump BlackwellSystems.Gcf from 0.2.1 to 1.0.0

[dependabot]

Updated BlackwellSystems.Gcf from 0.2.1 to 1.0.0.

Release notes

Sourced from BlackwellSystems.Gcf's releases.

1.0.0

First stable release of the GCF codec for .NET.

The public API is now committed under semantic versioning:

• Facade: Gcf — EncodeGeneric / DecodeGeneric, graph Encode / Decode, delta encoding, session dedup, pack roots, and streaming.
• Data types: Symbol, Edge, Payload, DeltaPayload, GenericSet, GenericDeltaPayload, GenericOptions, ReanchorPolicy, GenericDeltaSession, OrderedMap, Session, StreamOptions, StreamEncoder.
• Exceptions: DecodeException, EncodeException.

No wire-format or behavioral changes from v0.2.1. Verified against the shared conformance suite (281 fixtures) and the cross-SDK differential fuzz.

Zero runtime dependencies. Multi-targets netstandard2.0 and net8.0 (runs on .NET Framework 4.6.1+, Mono, Unity, and modern .NET).

NuGet: https://www.nuget.org/packages/BlackwellSystems.Gcf/1.0.0

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[erikdarlingdata]

Review

What this PR does. Bumps BlackwellSystems.Gcf 0.2.1 → 1.0.0 in Directory.Packages.props:13. Single-line change under Central Package Management. Base branch is dev (correct).

Consumer surface. The package is only used by the Darling MCP service:

• Darling/PerformanceMonitor.Darling.Service/PerformanceMonitor.Darling.Service.csproj (PackageReference)
• Darling/PerformanceMonitor.Darling.Service/Mcp/GcfOutput.cs:5,52,72 — uses Gcf.EncodeGeneric, Gcf.DecodeGeneric, OrderedMap
• Darling/Darling.Tests/GcfOutputTests.cs:5,75 — same three symbols
• Darling/Darling.Tests/GcfCallToolFilterTests.cs

All three consumed symbols (Gcf.EncodeGeneric, Gcf.DecodeGeneric, OrderedMap) are listed in the 1.0.0 facade/data-types in the release notes, and the notes explicitly commit to "no wire-format or behavioral changes from v0.2.1." The NumberSurvivesAsDouble fail-safe path in GcfOutput.cs (uses Gcf.DecodeGeneric to round-trip verify) is the load-bearing behavioral assumption — release notes cover it via the "no behavioral changes" wording plus the 281-fixture conformance suite reference.

What's good.

• Scope is minimal: one line in the central props file, nothing else touched.
• Consumed API is stable across the bump.
• No PlanAnalyzer, schema, install-script, workflow, or SQL changes to worry about.

What needs attention.

• Stale lockfile. Darling/Darling.Tests/packages.lock.json:696-779 still records "BlackwellSystems.Gcf": "[0.2.1, )" (requested) and resolved: "0.2.1" with the 0.2.1 content hash. Dependabot updated Directory.Packages.props but did not regenerate the lock file — a known gap for .NET CPM. CI's Darling Linux build passed here, which means restore is not running in locked mode for that job; however, anyone running dotnet restore --locked-mode (or CI that later enables it) will hit NU1403/mismatch. Regenerate with dotnet restore --force-evaluate on the Darling test project and commit the updated packages.lock.json before merging.
• Publisher trust (informational). BlackwellSystems.Gcf is a low-download, recently-versioned package from blackwell-systems/gcf-dotnet. Nothing in the diff itself is suspicious, but a 0.x → 1.0.0 major bump on an infrequently-used dependency is worth a glance at the NuGet publisher and signing metadata before merging, especially since this ships inside the Darling MCP service that fronts SQL Server data.

Not a blocker on the diff itself. Once the lockfile is refreshed this looks good to me — maintainer decides.

---

Generated by Claude Code

[erikdarlingdata]

Claude posting for Erik Darling

This is red on NU1004 because Dependabot moves Directory.Packages.props and does not regenerate the packages.lock.json files that go with it. One command on this branch clears it:

dotnet restore PerformanceMonitor.sln --force-evaluate

then commit the lock files it rewrites. On a CRLF checkout that is Darling/Darling.Tests/packages.lock.json only — seven lines, AWSSDK.PI 4.0.100.11 -> .12 and the AWSSDK.Core 4.0.102.1 -> .3 it pulls with it. A restore run on Linux or macOS also rewrites the other eight lock files with LF; git normalises those away on add.

Worth knowing while this sits: Darling whole-tree guards is not a required check on dev, so this pull request reads UNSTABLE rather than BLOCKED — it is mergeable today, with lock files that do not match the props file it ships. #3147 makes the required build check able to report the mismatch, which it could not before.

[claude]

Reviewed this Dependabot bump against the repo's review checklist (T-SQL style, Lite/Darling parity, correctness, security, performance).

Scope: Only Directory.Packages.props and Darling/Darling.Tests/packages.lock.json change (BlackwellSystems.Gcf 0.2.1 → 1.0.0). No T-SQL touched, so the collector style rules don't apply.

Lite/Darling parity: No drift risk — BlackwellSystems.Gcf is only referenced by PerformanceMonitor.Darling.Service (Mcp/GcfOutput.cs). Lite has no dependency on this package, so there's no counterpart to keep in sync. Confirmed no other packages.lock.json in the repo still pins the old version.

Correctness/compat: This is a major version bump (0.x → 1.0), which can carry breaking changes under semver even from a "1.0" release. The only consumer calls Gcf.EncodeGeneric / Gcf.DecodeGeneric, both of which the 1.0.0 release notes explicitly list as stable facade methods with "no wire-format or behavioral changes from v0.2.1," verified against a 281-fixture conformance suite — so this should be a safe drop-in.

Security: No new transitive dependencies, no secrets/network/file/process surface changes — just a version bump and lockfile hash update.

No issues found. Looks safe to merge.

[claude]

Reviewed. This is a clean, low-risk Dependabot bump — no source/T-SQL changes, only Directory.Packages.props and the Darling test project's packages.lock.json (BlackwellSystems.Gcf 0.2.1 → 1.0.0).

• Correctness: Release notes state no wire-format/behavioral changes from 0.2.1, and the public API surface listed (Gcf.EncodeGeneric/DecodeGeneric, OrderedMap, etc.) matches current usage in Darling/PerformanceMonitor.Darling.Service/Mcp/GcfOutput.cs and GcfCallToolFilter.cs. Nothing in the diff suggests a breaking change.
• Lite/Darling parity: BlackwellSystems.Gcf is Darling-only (used for MCP tool-result compression via DARLING_OUTPUT_FORMAT=gcf); Lite has no equivalent output-format feature. That's a pre-existing gap, not something this PR introduces or needs to address, so no parity drift from this change.
• Security: No SQL, no secrets, no new file/network/process surface — just a lockfile/package-version update from the package's own registry with matching content hash.

No findings. Fine to merge once CI passes.

[claude]

Reviewed. This is a mechanical Dependabot bump (BlackwellSystems.Gcf 0.2.1 → 1.0.0) touching only Directory.Packages.props and Darling/Darling.Tests/packages.lock.json. No issues found:

• Parity: the package is referenced only by PerformanceMonitor.Darling.Service.csproj; Lite has no dependency on it, so there's no Lite/Darling drift to flag.
• Lock-file coverage: Darling/Darling.Tests/packages.lock.json is the only committed lock file that pins this package (verified via a repo-wide grep), and Darling.Tests.csproj is restored with --locked-mode in build.yml — satisfying the invariant LockedModeRestoreCoverageTests enforces (Directory.Packages.props and the lock file's transitive pin must move together).
• API surface: the only consumer, GcfOutput.cs, calls Gcf.EncodeGeneric/Gcf.DecodeGeneric, both part of the facade the 1.0.0 release notes commit to under semver with "no wire-format or behavioral changes" from 0.2.1.
• No T-SQL, no security-relevant surface (source is already pinned to nuget.org via nuget.config, and the lock file's contentHash pins package identity).

Nothing to change here.

[claude]

Reviewed. This is a mechanical Dependabot bump (BlackwellSystems.Gcf 0.2.1 → 1.0.0), touching only Directory.Packages.props and Darling/Darling.Tests/packages.lock.json. No T-SQL, no application code, and no Lite/Darling parity concerns — this package is only referenced by Darling (Darling/PerformanceMonitor.Darling.Service/Mcp/GcfOutput.cs and GcfCallToolFilter.cs, used to bound/encode MCP tool-call output), Lite doesn't depend on it at all, so there's no counterpart update needed there.

Notes:

• Upstream release notes for 1.0.0 explicitly call out "no wire-format or behavioral changes from v0.2.1" and list the same public API surface already in use (GcfCallToolFilter, GcfOutput), so no source changes should be required — consistent with the diff being lock-file-only.
• Darling Linux build is already green on this PR; worth confirming Darling PostgreSQL tests finishes clean too before merging, since that's the job that would surface any subtle behavior change in the MCP output path this package feeds.
• Nothing here trips the security/secrets/injection/perf concerns this review is scoped to — no query or network/file/process code changed.

No blocking issues found.