Plugin publication delivery

A plugin release completes when the successful build publishes its bundles, Memex processes the notification, and the intended content is adopted. A merged PR or an HTTP acknowledgement alone does not prove delivery.

The existing paths

Every active plugin repository calls the shared node-repo-publish-bake.yml lane. After its publication succeeds, the lane sends a signed bundle-publication record to https://memex.meshweaver.cloud/api/hooks/Hosting/PlatformBuilds. The inbox verifies and drains the event. Hosting/PlatformBuilds/<source> records the latest publication, and the watcher notifies the registered repositories that declare that source as an upstream. It never dispatches to the publisher itself.

The separate successful GitHub workflow hook writes Admin/_Build/<owner>.<repo>. That drives package reconciliation and GitSync import at the proven content commit. Package auto-update preferences and framework-compatible sealed source selection still apply; a publication callback does not override either. The registry's module publication notification and periodic reconciliation provide the consumer update path.

The active fleet is Plugins, Education, Reinsurance, SocialMedia, Manufacturing and Crm. The source-SHA, workflow-ref and callback-configuration inventory is conserved in Plugin publication provenance. New plugin repositories must use the shared lane and supply its callback URL and HMAC secret, as the existing fleet does. A second notification workflow is unnecessary.

A content release needs its content commit

The callback's digest is the tester image digest. Many plugin commits use that same compiler. Comparing only the framework identity and tester digest therefore discards real content updates.

The receiver reads the persisted sha and suppresses a delivery only when its nonempty content commit, framework identity and tester digest match the registered publication. Missing legacy commits are not evidence of a duplicate; the next delivery refreshes the registration. A redelivery of the same tuple still produces no dependent dispatch. Source and upstream routing are unchanged.

The sender must identify the content checkout. Core CD can run the shared workflow while building Plugins, so the workflow's GITHUB_SHA can belong to a different repository. The resolved platform release must likewise come from the selected image, rather than an optional dispatch payload.

This tuple identifies the reported source commit and compiler; the tester digest is not a hash of the resulting bundle set. It does not establish whether an upstream-only rebuild at the same content commit and compiler produced different output.

Evidence from 11 September 2026

The cloud's successful-build hook was working: Admin/_Build/Systemorph.MeshWeaver.Plugins revision 657 recorded successful run 34567371899 at commit d6fa0338c4eab254402603498228ffe8f3c06c4f. Store/_GitSync revision 573 also named that commit. This was evidence of reception and source selection, not proof that every later main commit had passed its publication gates.

At 08:56 UTC, Hosting/PlatformBuilds/plugins revision 7 reported a core workflow commit beginning 27ea9fd8 while naming Systemorph/MeshWeaver.Plugins, with an empty release version. The live receiver also omitted sha when reading registrations. These are independent sender and receiver defects, despite every repository having a configured callback.

Two new receiver regressions executed against the unchanged source on the sealed 8323 Linux test environment: 473 Hosting cases passed and exactly the two new cases failed. Reading the content SHA and including it in duplicate detection made all 475 native Hosting cases pass; the 871 native Store dependency cases also passed. Mesh-required cases are counted separately. The regressions use the real registration serializer and reader, include a new commit on the same compiler, and preserve the exact-redelivery control.

The separate full mesh gate executed the public Tests areas: 458 Hosting assertions across all 16 types and 888 Store dependency assertions across all 17 types passed, with every type compiling and rendering successfully. The native and mesh runners enumerate different case sets; their totals are separate evidence, not an additive coverage count. All 89 repository NodeTypes also passed the compile gate, with shape and generated manifests validated.

A further production observation remains unresolved by this change: at 09:20 UTC the current publication node was no longer returned, while its persisted history ended at revision 107 on 10 September. Historical revision 7 contained an older payload than the live revision-7 reading above. This discrepancy is not evidence of durable registration, and neither the source-SHA fix nor a successful callback alone establishes persistence across activation. Delivery verification must include the durable record and active production content; the discrepancy needs its own causal investigation before declaring the path restored.

Verify a release

1. Check that the main build and publication jobs actually succeeded. A skipped publisher is not a release.
2. Compare the callback's repository and full content SHA with the published source marker. Confirm the registered framework identity and image release match the selected image.
3. Confirm the signed inbox event was processed and the source's registration advanced. An HTTP acknowledgement proves receipt, not processing.
4. Follow the successful-build record and the package/GitSync reconciliation verdict. If adoption is held, inspect the package's own preference and sealed framework compatibility.
5. Read or exercise something changed in the target production content. For compiled modules, verify the active module version after the supported activation path completes.

See Plugin update on green build, Module publication gate, Webhook inbox and Sync ref contract.