Separate content and compiled build paths

The catalogue keeps one repository and the platform's centralized build and release lanes. .github/compiled-validation.json declares the portal build/test inventory and runtime input prefixes. Core's node-repo-project-scope.py supplies the selection mechanics; no selector is copied here. The platform selector resolves the released framework and image digests once per run. The shared workflow follows core main; build-scope resolves its script checkout to one commit and passes that exact run-time identity to both module lanes. No platform or build-logic commit is hard-coded in this repository. The publication receipt records the actual resolved source, images and scripts, so reuse still requires the same inputs.

The first rollout deliberately preserves all existing compiled-source coverage. Every src/ change selects all three host builds and all 49 test/support entries. Node content selects only compiled consumers that read it: Memex.Hosts.Test scans package JSON, and MeshWeaver.Cornerstone.Test embeds Cornerstone content. The ordinary NodeType compilation, Tests-area, shape, manifest and repository-policy gates remain in place.

Local selection checks on 2026-09-09:

The stable required check, Build + test the portal hosts, still reports on every run. It requires successful selection and successful execution of the selected shards. The existing per-suite fresh-result checks and coverage ratchet remain; a missing policy project is a selection failure.

Main publication selects changes since a successful publishing run with matching resolved framework source, build-logic and image inputs. The run's publication-inputs artifact is the evidence. A newer partial, cancelled, active or release-follow publication, missing artifact or unknown baseline forces full publication. This covers variable overrides that Git history cannot see. Release-follow events always rebuild the full set. Intervening reverted changes remain in the module selection so a partial publication cannot survive a source revert.

The module floor remains available to the compile gate and sealed bake. An unaffected floor bundle is reused from that successful run's available artifacts through the shared lane's existing reuse and receipt path. Missing or expired artifacts rebuild normally. DefaultViews joins the rest call's mandatory composition set because the bake consumes it. No extra registry credential, hand-created space, new release pipeline or repository split is needed.

The first successful run establishes the attested baseline and therefore runs broadly. Later content-only runs can avoid unrelated assembly builds and suites. The registry's content-addressed build ledger remains available for broader reuse and cross-run coordination; enabling it is a separate provisioned capability, not a prerequisite for this separation.

The complete shared contract and regression coverage are documented in Build scope narrowing.

Required host tests also gate the sealed publication

publish-bake depends on portal-hosts-gate, the stable Build + test the portal hosts receipt, as well as the existing content, policy and module gates. Its release-event condition keeps GitHub's implicit success() check, so a failed, skipped or cancelled prerequisite prevents the bake from starting. A zero-size compiled selection still needs the aggregate's explicit success verdict; depending on the shard alone would lose that check.

The missing dependency was observed on 2026-09-09: Plugins run 34412991750 started publisher job 102687384576 after host shards 1 and 3 and their required aggregate failed. Push run 34414173231 also started its publisher after the host aggregate failed. The final logs distinguish the two outcomes: 34412991750 skipped an already complete publication without writing targets, while 34414173231 actually replaced both targets under framework identity se5d2c163b0d0c1469c5e7af69806b7a8. Job 102684899327 verified 45 of 45 files as its own bytes, then sealed at 23:54:20 and 23:54:37 UTC, from source b078f1bafb1e621845046d539a682a3e0564a76d; its final receipt says targets-published=2. Publication token Systemorph-MeshWeaver.Plugins-34414173231-1 therefore names an actual publication from a run whose required host gate failed. It replaced the earlier successful core publisher's set, so finding that earlier green origin cannot establish the current set's provenance. The second target's unseal at 23:54:28 also overlaps Manufacturing's 23:54:29 fetch failure; the missing-sentinel read race is investigated separately in core #3876. The repository's existing check-modules-published.py policy guard now checks this dependency and preserves the implicit success condition; mutation regressions remove each gate and try status overrides to prove the guard refuses those changes.

This closes the missing host dependency for the sealed bake.

Module bundles publish on their own verdict (per-module deploy)

MeshWeaver#3878 moved every module's registry hand-over behind the whole run's validation verdict (Plugins#1663, publish-mode: staged plus a publish-modules job). The maintainer rejected that coupling on 2026-09-11, after main had published no module for nine hours: "why do deployments depend on a complete main run?!", "each module should update individually", "we will only force consistency inside a dependency network, not just all — ever". So this repository does not use the staged hand-over.

Each modules-floor leg builds its module, runs the module's OWN suite and POSTs its bundle — a red module is never published, and an unrelated red (a sibling module, a portal-host shard, a repo-wide gate) never holds it. Right before the POST the leg stands down if a newer main commit reaches its dependency network (publish-newest-only), so two runs finishing out of order cannot move a module backwards. No main run is cancelled, a push builds only the network changed since the last successful run, and the platform release is the one full run. Design of record: core Doc/Architecture/ModuleBuildArchitecture → Per-module deploy.

REGISTRY_PUBLISH_TOKEN is therefore passed to modules-floor again, and its pr-secret-preflight-allow.txt entry is restored. The NodeType seal (publish-bake) still waits for the gate set above; it is narrowed to the affected modules and never seals an older commit over a newer one.