docs(suite): the deployment plan assumed a fourth product that was never built - #657
Merged
Merged
Conversation
…ver built
The suite is three products, not four. MMS held a namespace, a database, a
CI pipeline it did not have, four risk-register rows, five sizing rows and
the entire M0-M4 ownership migration in this plan — all for a system that
never existed. ADR-0129 records where the tenant boundary really sits;
this makes the deployment plan agree with it.
What changed beyond deleting a product:
- §5 messaging is redrawn on ONE producer and ONE consumer queue.
The exchange is Evolith.Contracts.Tenancy:TenantSnapshotIntegrationEvent
and the endpoint is tracker.tenant-snapshot, both read from T-059's
ConsumerDefinition rather than assumed.
- §5.1's consistent-hash rule is KEPT even though one consumer cannot be
split. It would bite silently the day a second consumer group binds,
which is exactly when nobody would be reading this section.
- §5.5 listed four P0 consumer defects. T-059 closed three; the fourth
(startup migrations at replicas>1) is still open and says so. They stay
on the page struck through, because the reasons are what the next
consumer has to satisfy.
- §12 becomes a table of what the M-phases were migrating toward versus
what happened instead.
- §15 keeps its numbering with the closed and withdrawn rows struck. A
risk register that quietly loses rows cannot be audited.
- §14 stops naming masterdata_projection_applied/discarded_total as
standard meters. They never had an emitter, under any name.
- Sizing drops mms-api and one Postgres: 1.6 vCPU / 3.6 GiB -> 1.4 / 3.1.
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 |
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.
Follow-up to #655, which superseded ADR-0106. That PR deliberately left this document out: its §5 derives a messaging topology over two projection queues, with exchange bindings and the DLX retirement resting on it, and MMS was load-bearing well beyond §5 — a namespace, a database, a CI pipeline it never had, four risk rows, five sizing rows, and the entire M0–M4 ownership migration.
The suite is three products. This makes the plan say so.
Beyond deleting a product
§5 is redrawn on one producer and one consumer queue. The exchange is
Evolith.Contracts.Tenancy:TenantSnapshotIntegrationEventand the endpoint istracker.tenant-snapshot— both read from T-059'sConsumerDefinition, not assumed. Broker permission regexes follow:umswrites,trackerreads.§5.1's consistent-hash rule stays, even though one consumer cannot be split. It would bite silently the day a second consumer group binds, which is exactly when nobody re-reads this section. The text now says why it is kept rather than implying a split that cannot happen today.
§5.5 listed four P0 consumer defects. T-059 closed three — the inbox is wired on the endpoint, the upsert is version-guarded, and the
MasterDataDbfallback is moot because that context is gone. The fourth (startup migrations at replicas>1) is still open and says so. All four stay on the page struck through: the reasons are what the next consumer has to satisfy.§12 was the M0–M4 ladder that migrated tenant authority toward MMS. It becomes a table of what each phase was for versus what actually happened, and keeps the one invariant that outlives it — the Tracker must not become a second tenant master, guarded by the write split and the version guard rather than by a milestone.
§15 keeps its numbering with closed and withdrawn rows struck rather than deleted. A risk register that quietly loses rows cannot be audited.
§14 stops naming
masterdata_projection_applied/discarded_totalas standard meters. They never had an emitter — not in the Tracker after T-059 and not before it — so the section now says what to add and what the honest signals are meanwhile.Sizing drops
mms-apiand one Postgres: ≈1.6 vCPU / ≈3.6 GiB becomes ≈1.4 / ≈3.1.Verified locally: bilingual parity, bilingual sync, inventories
--check, maturity--check.🤖 Generated with Claude Code