combo-verify(#3848): record the client-a-test rename that resolves the duplicate memex by rbuergi · Pull Request #5776 · Systemorph/MeshWeaver

rbuergi · 2026-09-26T19:33:27Z

What

The combo-verification roster has refused since it first ran, because two live installations were both named memex. The decision is now taken: the control instance (memex.systemorph.com) keeps memex, and ClientA's installation at client-a.meshweaver.cloud becomes client-a-test. That rename is Systemorph/ClientA.Memex#85. This PR brings core in line with it.

ComboGateWiring.md records the decision and what moved. Only the identity moved. Namespace, overlay directory, release, database, vault prefix, host and registry instance id client-a are unchanged, so nothing is re-registered. The page also says what the rename changes on the running instance: the inventory now lands at Ops/Modules/client-a-test, and Local-route self-update announcements carry the new id. The derivation now prints five names.
It also records where each credential is actually issued:
- The mwi_ key comes from the called portal's own Settings ▸ Instances. InstanceRegistryAuthenticator resolves the key against that portal's own mesh. Register a new entry; never use Reissue, because ReissueKey replaces the entry's key.
- The mw_ token comes from Settings ▸ API Tokens, minted by a global admin on that instance.
- Both secrets live in the Actions store only. No pull-request lane consumes them.
- The page gives the derived COMBO_VERIFY_SOURCES value.
derive-combo-instances.py: the "two repositories, different names" arm now uses the shape the fleet actually resolved to: the same overlay directory with a different Hosting__Deployment. The refusal message names this precedent. The duplicate-name refusal and its arm stay, because they guard the mechanism.
instances.json: the Systemorph/ClientA.Memex reason text names the renamed installation.

Verified locally

python3 .github/scripts/derive-combo-instances.py --self-test: exit 0, 15 PASS, 0 FAIL.
python3 .github/scripts/check-combo-verify.py: exit 0, 0 violations.
python3 .github/scripts/lock-pinned-digests.py --self-test: exit 0. It reads instances.json.

Not in this PR

CD: combo-verify is wired but its inputs are not provisioned — every roll stays UNVERIFIED, and the inputs are one more hand-maintained pin #3848 stays open: it is sev:H and is resolved only when Admin/UpdatePolicy.comboVerifications is non-empty on a live instance.
COMBO_VERIFY_KEYS and COMBO_VERIFY_TOKENS are still unprovisioned. They must be issued per instance by a person.
vars.COMBO_VERIFY_SOURCES was set on this repository as plain data and read back.

🤖 Generated with Claude Code

…rtnerRe's installation to `partnerre-test` The decision the roster refusal asked for is taken: the control instance keeps `memex`, and the installation at partnerre.meshweaver.cloud answers to `partnerre-test` (PartnerRe.Memex#85). Only its identity moved; namespace, overlay directory, release, database, vault prefix, host and the registry instance id are unchanged. - ComboGateWiring: record the decision, what the rename changes on the running instance, the five-name roster it yields, and where each credential is actually issued. The mwi_ key comes from the called portal's own Settings > Instances (the authenticator resolves it against that portal's mesh), as a NEW entry and never a Reissue, which replaces the entry's key. The mw_ token comes from API Tokens, minted by a global admin. Also the derived COMBO_VERIFY_SOURCES value. - derive-combo-instances.py: the "two repositories, different names" arm is spelled as the fleet resolved it (same overlay directory, different Hosting__Deployment), and the refusal names the precedent. The duplicate-name refusal and its arm stay. - instances.json: the PartnerRe.Memex repository reason names the renamed installation. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Copilot

Copilot review overview

🟡 Changes recommended

One or more issues must be addressed before approval.

Review effort: Lite
Findings: 2

Open (2)

Update conflicting PartnerRe instance identities · New
Update earlier sections with the resolved five-instance roster · New

What changed in this PR

Updates combo verification documentation and fixtures for PartnerRe’s rename from memex to partnerre-test, preserving the duplicate-name guard.

Changes:

Documents the rename, credential issuance, and resulting roster.
Updates derivation self-test coverage for differing names in shared overlay directories.
Records the renamed installation in retention metadata.

File	Description
src/MeshWeaver.Documentation/Data/Architecture/ComboGateWiring.md	Updated as part of this pull request.
.github/scripts/derive-combo-instances.py	Updated as part of this pull request.
.github/acr-retention/instances.json	Updated as part of this pull request.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

rbuergi · 2026-10-11T12:43:13Z

    "Systemorph/PartnerRe.Memex": {
      "role": "deployments",
-      "reason": "PartnerRe's deployments repository, created 2026-09-14T21:30:38Z (measured 2026-09-15: 2 overlay files). It declares its own control instance `memex` — partnerre.meshweaver.cloud, LIVE and answering /api/version with core 2592e228 — and `partnerre`, the hand-over template for PartnerRe's own estate, which still carries TODO placeholders including its ingress host. Its images are pinned in memexaksacr43rzd6faaix36.azurecr.io, an ACR in PartnerRe's OWN subscription and Entra tenant, which this lane's credential does not reach; the `registries` table below is where that is accounted for. 🚨 That host CHANGED on 2026-09-17, when the estate was torn down and rebuilt in PartnerRe's tenant, and the registry declaration did not follow it — which is the whole of the 2026-09-17 to 2026-09-21 red.",
+      "reason": "PartnerRe's deployments repository, created 2026-09-14T21:30:38Z (measured 2026-09-15: 2 overlay files). It declares its own instance — partnerre.meshweaver.cloud, LIVE and answering /api/version with core 2592e228 — which was `memex` until PartnerRe.Memex#85 renamed it `partnerre-test` (MeshWeaver#3848: `memex` is the fleet control instance's id, and the combo lane's credential maps are keyed by name; namespace and overlay directory stay `memex`), and `partnerre`, the hand-over template for PartnerRe's own estate, which still carries TODO placeholders including its ingress host. Its images are pinned in memexaksacr43rzd6faaix36.azurecr.io, an ACR in PartnerRe's OWN subscription and Entra tenant, which this lane's credential does not reach; the `registries` table below is where that is accounted for. 🚨 That host CHANGED on 2026-09-17, when the estate was torn down and rebuilt in PartnerRe's tenant, and the registry declaration did not follow it — which is the whole of the 2026-09-17 to 2026-09-21 red.",


(re-posted 2026-10-11; originally by Copilot on 2026-09-26)

This replacement leaves the earlier narrative strings in the same JSON (lines 150–160) saying ClientA's live control instance is still memex, while this reason now says it was renamed to client-a-test. Since the retention record emits both explanations, readers will see conflicting current identities. Update the earlier narrative or explicitly mark it historical.

(re-posted 2026-10-11; originally by @rbuergi on 2026-09-26)

Fixed in e0016b7. The header narrative now says ClientA's instance was memex, is marked HISTORY, and points to the repositories entry for the renamed client-a-test. The file no longer states two current identities. lock-pinned-digests.py --self-test still exits 0.

rbuergi · 2026-09-26T19:53:41Z

+The roster the derivation then prints is five names: `build`, `memex`, `memex-cloud`, `partnerre-test`
+and `pearl`. The refusal and its self-test arm stay: they guard the mechanism, and the next
+deployments repository to declare a taken name meets the same red.


Fixed in e0016b7. Both earlier measured sections, the "derivation says TODAY" paragraph and "the three inputs are necessary and NOT sufficient", now open with a RESOLVED note. The note gives the five-name roster and says the text below is the pre-rename record. It is kept because the refusal still guards the next repository that declares a taken name. The "TODAY" wording became "THEN", and the remainder list item 0 is struck as done.

(re-posted 2026-10-11; originally by Copilot on 2026-09-26)

These new lines say the roster is now five names, but the earlier “what the derivation says TODAY” section at lines 306–324 still says the fleet contains two memex installations and that derivation refuses. That leaves the operator with contradictory instructions about whether to provision credentials. Update the earlier measured sections (including the text around lines 535–543) to record the resolved client-a-test roster instead of only appending the decision.

github-actions · 2026-09-26T19:38:30Z