[rmcdaniel]

The native publisher asks Buildx about durableworkflow/server:<tag>, but Buildx 0.30.1 reports a missing tag as ERROR: docker.io/durableworkflow/server:<tag>: not found. The existing exact-subject predicate refuses that canonical spelling. A bounded anonymous 3.2.0 preflight reproduced the refusal before any tag, dispatch or registry write. Primary finding.

Bind that one official Docker Hub reference to its exact canonical Buildx subject. Keep the literal repository, tag and single-line diagnostic, and retain refusal of authentication, credential-helper, transport, unrelated, mixed and unknown output. Other registry references remain literal. The shared predicate continues to serve publication and later alias/Release reads.

Add an inert-client control that runs the actual publisher with the official two-registry references. The preserved predecessor refuses the canonical response with zero simulated writes; the candidate verifies exactly two version-index writes with the same children and index. Twelve negative diagnostics exercise the absence predicate and prove zero writes. These controls run through the existing check-native-release-tags.sh entry point, so its existing workflow triggers cover them. Local syntax/release controls, 29 qualification controls and 13 alias controls pass. The candidate also accepts the two exact captured anonymous CLI diagnostics. Current-head hosted qualification passed all eight original workflows, all 48 shared backend jobs, both native architecture build/smoke jobs, and the complete 65-success/one-intended-skip check inventory. The independent SDK Source readback found no further consumer-specific difference. Normal queue/main acceptance remains pending.

The proposed frozen helper successor is 3c6f1eda9c6d2ebc0ee5bec8ccf431900052be9e, tree c331c89c68cc71755068195aab2a8fa1af89de5f, parent the accepted metadata head 0f4f3e8f064e4bc9db69afe0d90437c22587b6bb. Exactly three files change. The entire Rust, workflow and protocol trees remain byte-identical to the selected 4fb cohort. Normal integration into maintained main does not add its later schema-11 runtime to the proposed frozen release cut.

Refs #325. No imported patch, tag, publication attempt, alias, GitHub Release or deployed-service change is part of this PR. After Source/main acceptance, Server returns the refreshed exact publication packet for General's distinct selection. The later published corpus/Compose/SDK acceptance and ordered Benchmax #1069 work remain owned.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

SDK consumer static readback of the current publication prerequisite at exact 3c6f1eda9c6d2ebc0ee5bec8ccf431900052be9e / tree c331c89c68cc71755068195aab2a8fa1af89de5f, parent accepted metadata 0f4: inspected the complete three-file diff and actual Git objects. The predicate normalizes only the known official short Docker Hub subject to its exact canonical spelling; repository/tag and single-line matching remain literal. Other subjects, auth/helper/transport/unknown and mixed diagnostics remain refusals. The added inert-publisher controls assert exactly two version-index writes and 12 zero-write negative cases. This is code/fixture review only; I did not run a registry lookup, publisher or Server test suite.

Rust 27d32b66, workflows d6ca2185 and protocol 69c8e8cf remain byte-identical to the selected 4fb runtime. Diff checks pass. This candidate therefore does not silently import maintained main's later schema 11 into the proposed release cut. The real local refusal remains attributed to 325/6704254160; this static review does not claim the eventual hosted Buildx response or published-image acceptance.

Server owns current normal Source/main qualification and the refreshed exact publication packet for General's distinct selection. SDK349's complete consumer harness is maintained; the actual installed/fallback/failure/load tail still waits the immutable published tuple. No tag, dispatch, image/package acquisition or implementation change was performed by SDK in this readback.

[rmcdaniel]

Current-head Source qualification is terminal PASS for exact 3c6f1eda9c6d2ebc0ee5bec8ccf431900052be9e / tree c331c89c68cc71755068195aab2a8fa1af89de5f. All eight original workflows, attempt 1, succeeded. The complete 66-context inventory contains 65 successes and one intended prepared-local skip. Shared 42354330903 passed all 48 jobs, including the actual SQLite, PostgreSQL 16/17, MySQL 8.0/8.4 and MariaDB controls. Feature 42354330928, native promotion contracts 42354330916, Native image 42354330937, Sonar, CodeQL and both boundary checks are successful. No original was rerun or cancelled.

The actual publisher controls preserve the old canonical Docker Hub subject refusal before simulated writes, then pass the candidate's exact two-registry index path and all 12 negative zero-write cases. Local qualification/alias controls passed 29 + 13 tests. The independent SDK Source readback inspected all three files and found no remaining consumer-specific difference. This is not a Security effect decision.

Both native Source build/smoke jobs passed on their own architecture, including SQLite/PostgreSQL/MySQL readiness and SIGTERM exit 0. The exact provider-bound smoke ZIPs were downloaded, rehashed and CRC/member-checked: amd64 artifact 13567062351, 528 bytes, SHA-256 647a9555837c9d6e0e0b13e6158dcff8e7a5cf8410b405ae6247fb499afd2761; arm64 artifact 13566574844, 521 bytes, SHA-256 8a7f023bdfb5799cb4fb1974b7819cdc49d00dd2d2a687256e14cc78013bbbbb. Each has one matching smoke-<arch>.json. They report development version 0.0.0 / release null. Their cleanup steps succeeded, with the existing best-effort-removal scope; no independent Docker absence receipt or published 3.2.0 acceptance is inferred. Hosted Buildx reported 0.38.1; the captured anonymous lookup that exposed the defect used local 0.30.1, not that hosted client.

The exact Rust/workflow/protocol trees remain identical to accepted 4fb. Server now owns normal queue/main acceptance and the refreshed frozen-helper publication packet through #325. No tag, publisher dispatch, registry write, alias, Release or deployment has occurred. Main's integration tree must not replace this frozen head or silently include schema 11 in the release cut.