Content workflow identity in GitSync fixtures

A successful workflow run proves repository content only when its stable workflow file path identifies that repository's content CI. The workflow display name, trigger and default branch are separate checks. Ordinary repository fixtures use .github/workflows/ci.yml, matching the canonical GitHubWebhookProcessor contract; production also supports the core repository's distinct path and explicit repository overrides.

The Plugins fixtures had omitted workflow_run.path. After adopting core's content-workflow verification, three positive tests returned zero before recording a build or starting an import. This was a fixture compatibility failure, not a reason to relax the publication guard.

What the fixtures prove

The valid workflow payloads now include the canonical path. The unsuccessful-build control also includes it, so that control isolates the failed conclusion. Existing assertions remain intact: push and failed builds import nothing; a successful content build imports the actual node; repository renames match and repair the stored configuration; wrong branches and ineligible triggers do not become publication records.

Three additional cases call the actual webhook processor with otherwise publishable payloads: an absent path, an unrelated deployment path, and a path with different casing. Each asserts both the zero result and the absence of a BuildCompletion node. Each then corrects only the path in that same payload and verifies a successful result and actual build record, proving no other guard explains its earlier refusal. They use the existing real mesh and offline repository fixture. No product, authorization, workflow or test-selection code changes.

Measured failure and correction — 11 September 2026

Four independent Portal-host shard-1 jobs failed the same three tests with expected 1, actual 0: 103176514506, 103175713078, 103182843699 and 103177998007. Each checked out core 818c10649389c158594dc20c3e7792367f2cb51f (release 8329), and each finished GitSync with 193 passing and three failing tests. The explicit warning in every failing case says the green workflow carried no path and therefore produced no build record. Other incidental fixture warnings do not explain that explicit early return.

In that core source, GitHubWebhookProcessor.cs lines 741–759 read workflow_run.path and refuse an unidentified workflow before the build-record write. The guard came from the correction for core issue 3978; its tests here must model the contract rather than bypass it.

The local baseline is Plugins bce7c0d5 with an isolated checkout of that exact core. A Release build with warnings as errors passed with zero warnings and zero errors, then the three unchanged positive tests all failed with the same warning and assertion as CI. No timing, retry, access or product changes were needed to reproduce it.

After correcting the payloads, the strict build again completed with zero warnings and errors. The complete GitSync suite passed 199/199 in 43 seconds, including the three previously failing positive cases and all three new path-identity refusal cases. The original three-case red and the expanded full-suite green are separate executions, preserved as such. After adding the paired positive controls, another strict build passed and the final complete suite passed 199/199 in 44 seconds. Shape (261 nodes across 60 packages), the canonical 89-type compile gate, all 60 manifest checks and the whitespace check also passed.

The correction is verified with the same isolated core and SDK 10.0.400 on macOS; the captured CI jobs used SDK 10.0.401. This is a local source-contract result, not a claim that a fresh CI or production rollout has completed.

Separate compiler failure remains unresolved

App commit c12 also failed Portal-host shard 3 in CI run 34571884729, job 103176514529: 13 tests failed and the host exited 124. This is the separate managed compiler poisoning tracked in core issue 890. Its trace has 64 actual PROCESS CANNOT EMIT records; each final flat verdict is EMITS, while the shared and pristine compiler canaries threw. Raw substring counts for flat=SAME-FRAME include explanatory prose and are not verdict counts.

The controls still share Roslyn assemblies, as recorded in core issue 890 comment 5626863378; they do not establish that the cause lies below Roslyn. The GitSync fixture correction does not resolve that independent failure. No retry or timeout mitigation was used. The retained companion receipts are /tmp/sav-app-portal-shard3-failure-receipt.json and /tmp/sav-app-shard3-trace-receipt.json.

Reproduce the build and complete suite from the Plugins checkout, setting MeshWeaverRoot to a separate checkout of the core commit above:

dotnet build src/MeshWeaver.GitSync.Test/MeshWeaver.GitSync.Test.csproj \
  -c Release -warnaserror -p:MeshWeaverRoot=/path/to/core/
dotnet test src/MeshWeaver.GitSync.Test/MeshWeaver.GitSync.Test.csproj \
  -c Release --no-build -p:MeshWeaverRoot=/path/to/core/ --logger trx

The original local source hashes, four CI job identities, logs and executed test results are retained in /private/tmp/roadmap-gitsync-workflow-receipt/receipt.json, before.trx and final-full.trx (with the first corrected execution in after-full.trx). These machine-local files supplement the committed source and reproduction commands; they are not required to run the regression elsewhere.