decide & spike: fold postguard-dotnet into postguard (ship pg-ffi and bindings together)

[rubenhensen]

Body rewritten 2026-09-24. The original body was a one-line "spike and decide". It is preserved verbatim in a comment below. The question was decided on 2026-08-11, and that comment is the authority. This body summarises it and records where execution stands.

Decided: fold postguard-dotnet into postguard

The real reason is not tidiness in build.sh. The cryptify merge (#285) removed version drift by giving everything one lockfile, and that guarantee stops at the pg-ffi release boundary. postguard-dotnet consumes a frozen pg-ffi-v* release artifact through a one-line pin. Two lags stack:

1. pg-core → pg-ffi. A "0.6" requirement means a pg-core patch release rebuilds nothing.
2. pg-ffi → .NET. Nothing guards the currency of .github/pg-ffi-version.

The gap has widened since the decision (measured 2026-09-24):

	then (08-11)	now
pg-core on main	0.6.3	0.6.10
newest pg-ffi tag	pg-ffi-v0.1.3	pg-ffi-v0.1.3 (unchanged)
postguard-dotnet's pin	pg-ffi-v0.1.2	pg-ffi-v0.1.2 (unchanged)
E4A.PostGuard on nuget.org	0.6.0	0.6.0

The decision, part by part (reasons are in the decision comment):

• A history-preserving import into pg-dotnet/. The nine closing keywords in its history all target issues that are already closed. Re-run that audit immediately before and after merge (postguard-js#139).
• Kill the pin. dotnet pack takes its five platform binaries as artifacts from a build-ffi matrix in the same run. Delete .github/pg-ffi-version and PgFfiVersionTests.cs.
• pg-ffi pins pg-core with =, plus a ci_wiring.rs-style test that goes red when the two disagree. release-plz's release PR going red on a one-sided bump is accepted as the loud failure.
• One release brain. release-please goes, and E4A.PostGuard's version becomes pg-core's. The cost is accepted: a C#-only fix needs a pg-core release.
• A second required context for the .NET lane. REQUIRED_CHECK in ci_wiring.rs and scripts/ruleset-drift.sh generalise from a scalar to a set. It is not aggregated behind Wire compat.
• The trusted-publishing cutover has no window. Add a postguard policy scoped to delivery.yml plus a dedicated environment:, publish once, verify on nuget.org, then delete the old policy. Create the policy close to the cutover, because a new policy is only "temporarily active" for 7 days.
• Cut a pg-core release deliberately to drive the first publish.

Where execution stands

1. spike: assert the required-context list itself, not just the workflow wiring (the registry half of #272/#222) #318 merges first. Done 2026-08-11 (ci: assert main's ruleset still requires the gate build.yml produces #333).
2. Not started. Import into pg-dotnet/, the .NET CI lane, the artifact fan-in, the = pin and its coupling test, release-please removed. On main today there is no pg-dotnet/, workspace members are [pg-core, pg-cli, pg-pkg, pg-ffi, cryptify], pg-ffi/Cargo.toml has pg-core = { version = "0.6" }, and pg-ffi/build.sh still copies into ../../postguard-dotnet.
3. Not started. Ruleset gains the .NET context; REQUIRED_CHECK and ruleset-drift.sh become sets.
4. Not started. Trusted-publishing policy, a pg-core release, first publish verified, old policy deleted. decide & spike: fold postguard-dotnet into postguard (ship pg-ffi and bindings together) #256 closes here.
5. Retiring postguard-dotnet is task: retire postguard-dotnet — release automation off, banner, transfer #39, archive #342, which is blocked by this ticket.

Steps 2 and 4 need workflow YAML, which dobby-coder cannot push. The work is best split into child tickets per step, each with a dobby-carryable code half and a maintainer-applied YAML half.

Assumption to confirm before step 4

The decision gated step 4 on confirming how consumers pull E4A.PostGuard. One external consumer is now known: Worth-NL/NotifyNL-OMC pins E4A.PostGuard 0.3.0 exactly. That supports the exact-pin premise. It also means a real install base exists, and the package id and nuget.org channel have to survive the move unchanged.

Part of #247 (workstream F).

[rubenhensen]

Decided: fold postguard-dotnet into postguard

This ticket stays open. Per the map's done bar it closes on main and green, not on the decision — see the sequence at the bottom.

Why, precisely

The ticket argued from tidiness ("build.sh already copies binaries into ../postguard-dotnet"). The real argument is stronger and is about a guarantee that silently stops short.

#285 bought drift-freedom by construction: one lockfile, so cryptify and pg-core cannot disagree about bincode-next because they are built from the same tree. That guarantee stops at the pg-ffi release boundary. postguard-dotnet does not consume a workspace member — it consumes a frozen artifact of one, five platform archives attached to a pg-ffi-v* GitHub release, selected by a one-line pin. So it re-opens exactly the drift class the cryptify merge closed.

Measured on origin/main and the live registries, 2026-08-11:

	pg-core embedded
E4A.PostGuard 0.6.0 on nuget.org (pins pg-ffi-v0.1.2)	0.6.1
newest pg-ffi release available (pg-ffi-v0.1.3)	0.6.2
origin/main	0.6.3

Two independent lags stack, which is why the pin alone was never the whole problem:

1. pg-core → pg-ffi. pg-ffi declares pg-core = { path = "../pg-core", version = "0.6" }. A pg-core patch release still satisfies that requirement, so release-plz edits nothing, pg-ffi is not bumped, and no new native binary is built. pg-core 0.6.3 (2026-08-10) has no corresponding pg-ffi release at all.
2. pg-ffi → .NET. .github/pg-ffi-version does not move on its own. PgFfiVersionTests.cs guards the pin's shape (one line, ^pg-ffi-v\d+\.\d+\.\d+$) and nothing guards its currency, so postguard-dotnet#50 traded "silently newest" for "silently stale".

Net effect today: the shipped SDK seals containers with a bincode-next rc.13 serializer while the rest of the fleet is on rc.14.

Correction worth recording, so nobody re-raises it

pg-core 0.6.2 carries fix: bound stream signature length (#228, 8503bb2), and the first read of the changelog looked like a shipped SDK missing a hardening fix. It is not. The fix is on the Unsealer (pg-core/src/client/rust/stream.rs and client/web/stream.rs), and pg-ffi exports only pg_seal, pg_free and pg_last_error — no unseal path exists in the C ABI, and Native.cs imports exactly those three. The .NET SDK cannot reach that code. The gap here is a process gap, not a live vulnerability: nothing in the fleet can tell you whether a given lag matters, and this time it did not.

Coverage that does exist: E4A.PostGuard 0.6.0 is in postguard-e2e#41's nightly version-sweep matrix, so an actual wire break would surface — nightly and after the fact, not at PR time.

The decision, part by part

Fold, rather than gate the seam or build from source. Two alternatives were weighed and rejected. Gate it — fail CI when the pin is behind, and when pg-core released without a pg-ffi rebuild — is cheap and fits "make surviving seams executable", but it concedes the seam is unremovable when it plainly is not, and every firing costs a bump-and-release cycle across two repos. Build pg-ffi from source in postguard-dotnet removes the release-asset hop without moving the repo, but adds a Rust toolchain to .NET CI and relocates the seam from "which release tag" to "which commit". Both leave the SDK consuming a frozen artifact of a workspace member, which is the thing #285 proved is worth paying to avoid.

History-preserving import into pg-dotnet/. The closing-keyword hazard was measured, not assumed: postguard-dotnet's 63 commits carry nine keywords — #11 #12 #13 #14 #23 #25 #26 #27 #49 — and against this repo's numbering all nine are already closed issues or merged PRs. GitHub does not re-close a closed issue, so the import fires into a wall. This is the same luck the postguard-js website import had, except verified. Re-run the audit against the branch immediately before and after merge (both vectors — squash body and the imported commits themselves, per postguard-js#139); if any of the nine has changed state by then, stop and re-decide.

Kill the pin outright: artifact fan-in, not a release download. dotnet pack gets its five platform binaries as workflow artifacts from the build-ffi matrix inside one run (needs: build-ffi), so the binary is provably from the packing commit. Keeping today's mechanism intra-repo was rejected: it would fold the repos and leave the drift mechanism intact — the pin disappears but "which release tag" survives as a lookup, making the whole exercise cosmetic. .github/pg-ffi-version and PgFfiVersionTests.cs are deleted with it.

Close the pg-core → pg-ffi lag too, and do not trust the release tool to do it. pg-ffi pins pg-core with =, so a pg-core release forces a manifest edit and therefore a pg-ffi rebuild. The mechanism is unverified — release-plz's docs do not describe bumping a dependent when a path dependency releases, and the observed history proves nothing either way (pg-core 0.6.3 produced no pg-ffi bump, but "0.6" still matched, so no edit was needed). So: verify empirically in the spike and assert the coupling with a test, in the ci_wiring.rs style — a pg-core version that does not match pg-ffi's recorded requirement goes red. Consequence accepted deliberately: release-plz's own release PR goes red when it bumps one without the other, and sometimes needs a human. That is the loud failure, chosen over "the release tool will handle it", which is the assumption class #272 exists to catch.

One release brain. release-please goes. E4A.PostGuard's version becomes pg-core's, packed from the pg_core_version output delivery.yml already computes. The version stops being an independent number line driven by conventional commits and starts meaning "this SDK wraps pg-core X.Y.Z". The transition is legal — E4A.PostGuard is at 0.6.0, pg-core at 0.6.3. Cost accepted: a C#-only bugfix can no longer ship without a pg-core release. Taken because release-plz cuts one cheaply, and the alternative is two release tools opening release PRs, writing changelogs and tagging in the one repo whose thesis is that unwatched automation drifts. Checked and found not to be a signal: E4A.PostGuard's version numbers resembling pg-core's is coincidence — 0.4.0 shipped the same day as pg-core 0.6.1, and 0.6.0 two months after pg-core 0.6.0.

A second required context, not an aggregation. postguard's main ruleset requires exactly Wire compat with bypass_actors: []. The .NET lane becomes a second required context, which generalises REQUIRED_CHECK in ci_wiring.rs and scripts/ruleset-drift.sh from a scalar to a set. Hiding it behind Wire compat was rejected on #272's own finding: an aggregator's verdict step can be rewritten to exit 0 while every name still looks right, so widening what the aggregator covers makes that failure mode worse. Note the CI matrices are explicit crate lists ([pg-core, pg-pkg, pg-cli, pg-ffi, cryptify]), so pg-dotnet/ is not picked up by them and needs its own job.

Trusted-publishing cutover, with no window. Nothing about the destination changes: same package id E4A.PostGuard, same nuget.org, same owner — only which repository is permitted to publish moves. A consumer's PackageReference is untouched, the same way ghcr.io/encryption4all/cryptify kept its name through #293. Measured from the nuget.org docs: a policy scopes to Repository Owner + Repository + workflow file name only + optional Environment, policies are owned by a user or org rather than by a package, and nothing limits a package to one policy. So the order is add the postguard policy → publish once → verify on nuget.org → delete the postguard-dotnet policy, with no interval where neither can publish. The policy is scoped to delivery.yml plus a dedicated environment: on the publish job, because a policy naming only the workflow file would let any job in delivery.yml with id-token: write mint a publish key — and that file also pushes Docker images and publishes pg-wasm to npm. One documented trap: a new policy can start "temporarily active" for 7 days and only becomes permanent after a successful publish, so create it close to the cutover, not ahead of it.

Cut a pg-core release deliberately to drive the cutover. Under the new version rule the cutover publish needs a pg-core release to ride on. Waiting for an organic one couples an irreversible external step to an unpredictable schedule and risks the 7-day window; cutting one puts the first publish from the new source repo under supervision and lands E4A.PostGuard on pg-core's number in one clean step.

Sequence

1. #318 merges first (PR test(pg-core): assert build.yml's gate wiring so an unapplied patch fails loudly #316's successor, #333). REQUIRED_CHECK and scripts/ruleset-drift.sh are scalars that exist only there, and step 3 generalises them. This ticket is wired blocked by #318.
2. Import into pg-dotnet/ with the keyword audit; the .NET CI lane; the artifact fan-in replacing the release download; the pg-ffi = pin and its coupling test; release-please removed.
3. Ruleset gains the .NET context; REQUIRED_CHECK generalises to a set; ruleset-drift.sh compares a set.
4. Trusted-publishing policy added; a pg-core release cut; the first publish from postguard verified on nuget.org; the old policy deleted. #256 closes here.
5. postguard-dotnet retired — split out as its own ticket, the #286→#294 shape.

Steps 2 and 4 both need workflow YAML, which dobby-coder cannot push. Those arrive as maintainer-applied patches, and per this map's #324 finding, confirm the patch exists at the URL it is claimed to be at — a handover can be reported without having happened.

Assumptions recorded rather than buried

• The consumer pulls E4A.PostGuard from nuget.org on an exact pin. A real consumer exists; how they consume is not confirmed. Steps 1–3 are unaffected by the answer. Gate step 4 on confirming it — if they vendor the nupkg, mirror to a private feed, or float a range, the first publish has a different blast radius and a different rollback.
• postguard-dotnet's GitHub Releases carry zero assets on all ten releases, so nothing can pin one — NuGet is its only live channel. Same verdict shape as postguard-website in #312's audit table. That is what makes step 5 a clean archive rather than a channel migration.

[rubenhensen]

Cross-link: the fold's merge is the last remaining trigger for the closing-keyword hazard, and the audit for it lives in postguard-js#139 (rewritten today to name this ticket as its target — it previously pointed at two long-closed postguard-js PRs).

Two things to do when the import branch is ready, neither of which is covered by this ticket's own body:

1. Re-run the pre-merge audit against the actual import branch. This ticket's session measured 63 commits carrying nine keywords, all nine pointing at already-closed items here — which is what made a history-preserving import the cheap option rather than the risky one. But that measurement was taken against postguard-dotnet's history, not against the branch that will be merged, and this repo keeps numbering upward in the meantime. A number that was closed when measured is still closed, so the risk is one-directional and low; re-run it anyway, because it is one command.

2. Run it again after the merge. This is the half that has never been run on any import in this fleet, and it is what would have caught #146 on the day instead of five days later. Note the two vectors are independent: this repo's squash_merge_commit_message is COMMIT_MESSAGES, so a squash concatenates every imported message into the merge body, and a real two-parent merge instead attributes the closes to the imported commits directly. Editing the merge dialog's body defuses only the first.

git log origin/main..HEAD --pretty=%B \
  | grep -oiE '(close[sd]?|fix(e[sd])?|resolve[sd]?) +#[0-9]+' \
  | grep -oE '#[0-9]+' | sort -u

No dependency edge added — this is a step inside the fold, not a blocker on it.

[rubenhensen]

Claim released on 2026-09-24. It was left over from a session that ended without closing out; nobody is working this. It is back on the frontier.

[rubenhensen]

Original body, preserved verbatim before the 2026-09-24 rewrite:

Decision issue. pg-ffi's build.sh already copies binaries into ../postguard-dotnet; shipping bindings and binaries from one repo removes the version-sync problem at the root (interim mitigation: the pin in encryption4all/postguard-dotnet). Against: different toolchain, NuGet publishing move. Spike and record the decision here.

Part of #247 (workstream F).