chore: bump the cluster context pin - #36
Merged
Merged
Conversation
Control bump for JorisJonkers-dev/workspace#53. The published context has moved on three times since e839b908 while every consumer stayed pinned to it. Comparing the two contexts by pulling both: cluster-context-public.yml and adapter-compat.yaml are byte-identical. The only substantive difference is the sourceSha provenance field, 22b9d332 -> 7ee477c1. So this should render identically. That is the point of doing one repo first: the estate's replay procedure says always run a known-good consumer as a control, because the first harness reported both configurations as failing and only the control showed the harness was wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deploy Preview — auth-uiEnvironments: production Image refs
SC-11 Readiness Scorecard
Updated by deploy-check on push to this PR. |
This was referenced Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Control bump for JorisJonkers-dev/workspace#53. One repo first, deliberately.
State
Every consumer is pinned to
e839b908…, published 2026-08-26 12:32. The context has been republished three times since:This should be a no-op, and that is the claim under test
I pulled both contexts and diffed them:
cluster-context-public.ymladapter-compat.yamlcontext-manifest.ymlsourceSha: 22b9d332→7ee477c1MANIFEST.sha256So the only substantive change is the provenance field. Nothing a consumer renders should move.
The node-contract reconciliation that prompted this (
nix-config#22,homelab-inventory#17) landed in the internal context, not the public one — which is why the public payload is unchanged.Why one repo and not sixteen
The estate's own replay procedure says to always run a known-good consumer as a control, because when the deploy-artifact harness was first exercised it reported both configurations as failing, and the control is what showed the harness was wrong rather than the manifests.
auth-uiis that control here: simple, fast CI, and currently healthy. Read thedeploy-previewrender, not the green tick — if the rendered manifests are identical to the previous run, the bump is safe and the remaining 14 pin sites can follow. If they are not, the assumption above is wrong and I would rather find out on one repo.Not included
Two further matches for the old digest live in
services/auth-api/.claude/worktrees/generic-500/— stray local worktree state inside that submodule, not a real consumer. Reported on #53 rather than touched.🤖 Generated with Claude Code