Status reconciliation — 2026-10-22
Shared namespace implementation merged in PR #72, with reconciliation fixes in merged PR #76/#77. Rollout is blocked, not completed: current ADT-193 evidence records V40 dataset conflicts and a SYSTEM wallet whose display name is also routing identity. A separate source repair is underway; preserve wallet identity/funds. ADT-193 owns serialized staging maintenance and ADT-211 the manual correction follow-up. Production conflict remediation and acceptance remain outstanding.
User requirement
For Hibernia Economy, account names, business names and player names must share one naming namespace: names must not clash across these kinds, rather than merely being unique within each kind.
Requested in Discord: original request, Hibernia Economy clarification.
Existing coverage and conventions
PAR-144 covers player ↔ GOVERNMENT-account collisions and deterministic bare-name resolution; it does not require cross-kind global uniqueness including businesses. Coordinate with it rather than duplicating its resolver audit.
Current repository conventions are not exact/case-sensitive equality: economy-flyway V17 has a LOWER(current_name) player-name unique key under utf8mb4_unicode_ci; Business account duplicate checking uses equalsIgnoreCase. V33 reserves business names after disband until explicit administrator release (PAR-154). NameValidator's separator removal is a blocked-term filtering rule, not an established uniqueness policy. PAR-107 also records Floodgate name-width constraints.
Proposed acceptance details and implementation considerations
These details operationalize the request; unresolved policy choices below require a documented decision before implementation.
- Define one canonical comparison/reservation policy shared by account, business and player names. Decide case folding, surrounding whitespace, Unicode normalization/collation and accent behavior, punctuation/separators, permitted characters and lengths; retain display spelling separately if appropriate. Do not assume exact equality or reuse blocked-term normalization without a decision.
- Cover creation and renaming through commands, admin tools, APIs and automated ingestion/player-name refresh. Reject or explicitly resolve conflicts with any other kind; ensure lookup and autocomplete follow the same policy and give actionable conflict feedback.
- Decide how a player identity and its own PERSONAL account, or a business and its default account, participate when they represent the same owner/entity and currently share a display name. Document whether such projections share one reservation or need distinct addressable names; do not silently exempt unrelated entities.
- Decide lifecycle rules for archived/deleted accounts, disbanded businesses, explicit name release, historical names and reuse. Preserve or deliberately reconcile PAR-154's business reservation behavior. Clarify system/government accounts and business shop aliases where they are addressable names.
- Account for externally controlled Minecraft name changes and Java/Bedrock/Floodgate names: specify what happens if a joining/renamed player's name is already reserved, without silently changing identity or routing funds.
- Audit existing data under the chosen canonical policy across all three kinds. Produce a collision inventory and an approved remediation/migration strategy before enforcement, preserving IDs, ownership, balances, ledger/history and references. Avoid silently overwriting, merging or renaming records. Include rollout, backup/rollback and handling of unresolved collisions.
- Enforce reservations atomically across kinds and writers with a persistent constraint/transactional mechanism appropriate to the design; a check-then-create service check alone is insufficient. Verify actual migrated constraints and safe conflict handling.
- Verify pairwise cross-kind create/rename conflicts in both directions, same-kind conflicts, normalization variants, non-conflicting success, concurrent create/create and create/rename races (including separate writers), lifecycle/release decisions, and migration of representative pre-existing collisions. Ensure conflicts cannot leave partial records or change financial routing.
Scope
Track and implement shared name uniqueness in Hibernia Economy. This issue does not authorize production data changes or deployment; remediation and rollout must be planned explicitly.