/platform-update

Operate the fleet's platform-update pipeline — the signed CD webhook, the pin-bump PRs under the service credential, and the provisioning that arms it.

• Instructions: The platform half of dependency maintenance: when the platform repo promotes a build, every plugin repo gets a platform-pin bump PR proven by its own compile gate. Dependabot never touches the pins — this pipeline owns them. 🚨 **There is more than one pin, and they are ONE promoted build.** The tester image is pinned as `MW_IMAGE_DIGEST` **and** as a `tester-image-digest:` literal on each module-pack call; the portal image as `MW_PORTAL_IMAGE_DIGEST` **and** a `platform-image-digest:` literal per call. The literals exist because a reusable workflow's `with:` cannot read the workflow `env` — so **a pin moves by grepping its OLD VALUE across the file, never by editing the named variable**. `MW_PLATFORM_SET` names the promoted build all of them must resolve to, is CHECKED against the registry, and moves with them. See [Platform Builds](../PlatformBuilds) for the full table and the two times `main` came apart. # The chain 1. **CD notifies** (platform repo, `main-cd.yml` job `notify-platform-update`): after the release is armed, POST the build fact — sha, version, and the `mw-plugin-test:main` digest — to `{registry}/api/hooks/Hosting/PlatformBuilds`, HMAC-SHA256-signed over the raw body (`X-Hub-Signature-256`). 2. **The inbox lands it verbatim** (`Hosting/PlatformBuilds/_Inbox/{id}`) — fail-closed on the portal's `WebhookInbox:Targets` allowlist. 3. **The watcher verifies and acts** (`PlatformBuildInboxWatcher`, armed on the `Hosting/PlatformBuilds` node's OWN hub, which the Hosting module's `InboxHubAnchor` keeps activated for the life of the portal — #777): HMAC check against `Hosting:PlatformWebhookSecret`; on a verified build it runs `PlatformPinUpdater` — for each repo in `Hosting:PlatformUpdateRepos` (default: the four Systemorph node repos) it pushes `chore/platform-{sha}` bumping **every** pin the repo carries and opens a PR under the registry's GitHub App. Processed and unverifiable events are deleted. A repo that pins a por…
• Auto mount: yes
• Launches sub thread: no