docs(adr): the tenant master is UMS, and ADR-0106's MMS was never built - #655
Merged
Conversation
ADR-0106 has been Accepted since 2026-07-08 naming MMS "the sole owner of
the Master Tenant identity and lifecycle", with MMS publishing a projection
to UMS and the Tracker. MMS was never built. On 2026-08-22 both satellites
recorded the opposite: ADR-UMS-107 makes UMS the master and supersedes
UMS-083, and T-059 removes the Tracker's MMS consumer, its contract, its
read-model migrations and its MasterDataDb requirement.
Core owns none of that code but publishes the corpus that describes it, so
this repository was still the place where a reader found an accepted
architecture for a system nobody will build.
ADR-0129 records where the boundary sits, supersedes 0106 rather than
amending it — the MMS reasoning stays legible, which is the point of a
corpus — and declares implementation-status none, because Core neither
emits nor consumes the snapshot and ADR-0101 keeps it that way.
The sweep covers what described CURRENT behaviour:
- the glossary, which defined MMS as a product and gave it the tenant
- both ADR indexes
- the poison-message runbook, which sent an operator to shovel two queues
that do not exist; the Tracker's consumer endpoint is
tracker.tenant-snapshot, verified in T-059's ConsumerDefinition
- two Prometheus rules built on the same two dead queue names
- two source comments listing MMS as a .NET suite product
The runbook also named masterdata_projection_applied_total and its
discarded twin. Neither has an emitter — not in the Tracker after T-059 and
not before it — so the verify step now reads queue depth and the
ums_projection_version column, which do exist.
ADRs 0107, 0108, 0109 and 0110 name MMS in their historical context and are
deliberately left unamended, for the same reason 0106 keeps its text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…nt master
Both describe CURRENT intended behaviour rather than a point-in-time
decision, so unlike ADRs 0106-0110 they are corrected in place:
- the governed-composition target design carried MMS as a node in three
diagrams, as a row in the tenant-responsibility table, and as the first
step of the tenant sequence
- the Tracker technical interfaces carried the same, plus a REST intake
(`PUT /tenants/projections/...`) authorized for "MMS integration
credentials". T-059 replaced that with a bus consumer, so the PUT is
gone and the section says how intake actually arrives:
Evolith.Contracts.Tenancy.TenantSnapshotIntegrationEvent on
tracker.tenant-snapshot, upserted by version
The suite deployment strategy is deliberately NOT in this commit. Its §5
derives a messaging topology over two projection queues, with exchange
bindings and the DLX retirement resting on it; that is a redrawing, not a
rename, and it gets its own change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
Adding one ADR adds one generated conformance ruleset, and four artifacts
descend from that corpus. CI found them in the order the chain declares:
- native-evaluability-snapshot.json (415 rules, documentation-only 140→141)
- iso-5055-mapping.{json,csv}
- maturity-reconciliation.json
- the three pinned counts in rule-corpus-triage.spec.ts
The spec's numbers are pinned deliberately, so each one carries a note
saying what moved it. Superseding costs +1 rather than trading one for
another: ADR-0106 keeps its placeholder, because a superseded decision keeps
its record.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sixth artifact downstream of one new decision record: ADRs 143 -> 144 in both language copies. Found by CI rather than by the local chain replay, because 07-generate-inventories.mjs is not one of the nine links guard 46 walks — worth knowing the next time an ADR lands. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
ADR-0106 has been Accepted since 2026-07-08 naming MMS "the sole owner of the Master Tenant identity and lifecycle", with MMS publishing a projection to UMS and the Tracker. MMS was never built — not in BeyondNetCode, not in the suite.
On 2026-08-22 both satellites recorded the opposite, with code behind it:
ums) makes UMS the tenant master and supersedes UMS-083. Version comes from a database sequence, publication happens beforeSaveEntitiesAsyncbehind the bus outbox.evolith_tracker) removes the Tracker's MMS consumer, its contract, its read-model migrations, its health probe and itsMasterDataDbrequirement, replacing them withTenantSnapshotConsumerand an upsert guarded byums_projection_version.Core owns none of that code, but it publishes the corpus that describes the suite — so this repository was where a reader still found an accepted architecture for a system nobody will build.
What this does
ADR-0129 supersedes ADR-0106 instead of amending it. The MMS reasoning stays legible; that is what a corpus is for. 0129 declares
implementation-status: none, because Core neither emits nor consumes the snapshot and ADR-0101 keeps it that way.The sweep covers what described current behaviour, and stops there:
Two things found while sweeping
The runbook sent an operator to shovel two queues that do not exist.
ums.tenant-projection_errorandtracker.tenant-projection_errorwere MMS-era. The real endpoint istracker.tenant-snapshot, verified in T-059'sConsumerDefinition; UMS publishes and consumes nothing of it. Two Prometheus rules asserted the same dead names —TenantProjectionQueueMissingwould have fired critical forever once anyone deployed it.masterdata_projection_applied_totaland its discarded twin have no emitter. Not in the Tracker after T-059, and not before it. The verify step now reads queue depth and theums_projection_versioncolumn, which do exist.The Tracker interfaces doc also carried
PUT /tenants/projections/:globalTenantKeyauthorized for "MMS integration credentials". Intake is a bus consumer now, so the PUT is gone.Not here on purpose
The suite deployment strategy (46 of 335 lines) derives its whole §5 messaging topology over the two projection queues, with exchange bindings and the DLX retirement resting on it. That is a redrawing, not a rename, and it gets its own PR.
Verified locally: guards 44, 04, 66 and 59 pass.
🤖 Generated with Claude Code