m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Decide which firm domain is canonical — accounts exist on hoganlovells.com while the live domain is hlc.com, and three products key off the pair #159

New Issue
Open
opened 2026-07-27 10:04:42 +00:00 by mAi · 2 comments
mAi commented 2026-07-27 10:04:42 +00:00
Collaborator
Copy Link

Surfaced 2026-07-27 while checking whether a user (Cedric Rohr) had a Paliad account. He does — cedric.rohr@hoganlovells.com, created 2026-04-26. That resolved his question, but it exposed a risk nobody owns.

The problem

Since the merger the firm is Hogan Lovells Cadwalader and hoganlovells.com 301-redirects to hlc.com (verified directly — fetching https://www.hoganlovells.com/de/legal-notices/disclaimer lands on www.hlc.com/...).

Paliad's ALLOWED_EMAIL_DOMAINS allowlists both forms (hoganlovells.com,hlc.com,hlc.de). So a colleague can sign up under either, and paliad has no merge story for the two identities. Concretely:

  • A user with an existing @hoganlovells.com account who later signs up as @hlc.com gets a second, empty account — same human, no projects, no deadlines, no team memberships. From their side the product simply looks broken.
  • Nothing detects or reconciles this. There is no linking, no alias, no admin merge path.
  • otto reports the reverse is already happening in practice on other contacts: for Michael Plagge and Leonard Hollander the addresses actually in use are on hlc.com, while the hoganlovells.com form is the stale one. So both directions are live.

Today there is exactly one user per human and no duplicates (checked). This is a latent problem, not a current outage — but it becomes real the first time someone signs up with the other form.

Why this is not a paliad-local decision

The same domain pair is load-bearing in at least three products:

  • paliad — ALLOWED_EMAIL_DOMAINS gate, 51 users today, all on hoganlovells.com.
  • m/hihlc — issues #11 and #7 cover an HL-email gate on hihlc.de allowlisting both hlc.com and hoganlovells.com, reusing the youpc accounts.
  • youpc — the account substrate hihlc reuses.

If each product decides independently which form is canonical, they drift apart, and a user's identity depends on which product they signed into first. That is a worse failure than any single product getting it wrong consistently.

What needs deciding

  1. Which form is canonical — hlc.com (the live domain) or hoganlovells.com (where the existing accounts are)? These pull in opposite directions: the live domain is the future, the existing accounts are the present.
  2. What happens to accounts on the non-canonical form. Migrate them, alias them, or keep accepting both and add identity linking.
  3. Whether signup should refuse the non-canonical form once decided, so the problem stops growing.
  4. Who owns the decision across the three products — this is the part that makes it an issue rather than a paliad ticket.

Suggested shape, not a decision

Accepting both at the gate but normalising to one canonical form at account creation would stop new duplicates without locking anyone out mid-transition, and is reversible. That is a guess, not a recommendation — the cross-product owner should decide before anyone builds.

Not urgent

No current duplicate accounts. Filing it because it is exactly the class of finding that dissolves when a chat scrolls, and it bites silently — the symptom is a colleague seeing an empty product and concluding the tool does not work, not an error anyone gets paged about.

Filed by paliad/head at otto/head's request. Cross-references: otto message 5652; m/hihlc#11, m/hihlc#7.

Surfaced 2026-07-27 while checking whether a user (Cedric Rohr) had a Paliad account. He does — `cedric.rohr@hoganlovells.com`, created 2026-04-26. That resolved his question, but it exposed a risk nobody owns. ## The problem Since the merger the firm is Hogan Lovells Cadwalader and **`hoganlovells.com` 301-redirects to `hlc.com`** (verified directly — fetching `https://www.hoganlovells.com/de/legal-notices/disclaimer` lands on `www.hlc.com/...`). Paliad's `ALLOWED_EMAIL_DOMAINS` allowlists **both** forms (`hoganlovells.com,hlc.com,hlc.de`). So a colleague can sign up under either, and paliad has **no merge story** for the two identities. Concretely: - A user with an existing `@hoganlovells.com` account who later signs up as `@hlc.com` gets a **second, empty account** — same human, no projects, no deadlines, no team memberships. From their side the product simply looks broken. - Nothing detects or reconciles this. There is no linking, no alias, no admin merge path. - otto reports the *reverse* is already happening in practice on other contacts: for Michael Plagge and Leonard Hollander the addresses actually in use are on `hlc.com`, while the `hoganlovells.com` form is the stale one. So both directions are live. Today there is exactly one user per human and no duplicates (checked). This is a latent problem, not a current outage — but it becomes real the first time someone signs up with the other form. ## Why this is not a paliad-local decision The same domain pair is load-bearing in at least three products: - **paliad** — `ALLOWED_EMAIL_DOMAINS` gate, 51 users today, all on `hoganlovells.com`. - **m/hihlc** — issues #11 and #7 cover an HL-email gate on hihlc.de allowlisting **both** `hlc.com` and `hoganlovells.com`, reusing the youpc accounts. - **youpc** — the account substrate hihlc reuses. If each product decides independently which form is canonical, they drift apart, and a user's identity depends on which product they signed into first. That is a worse failure than any single product getting it wrong consistently. ## What needs deciding 1. **Which form is canonical** — `hlc.com` (the live domain) or `hoganlovells.com` (where the existing accounts are)? These pull in opposite directions: the live domain is the future, the existing accounts are the present. 2. **What happens to accounts on the non-canonical form.** Migrate them, alias them, or keep accepting both and add identity linking. 3. **Whether signup should refuse the non-canonical form** once decided, so the problem stops growing. 4. **Who owns the decision across the three products** — this is the part that makes it an issue rather than a paliad ticket. ## Suggested shape, not a decision Accepting both at the gate but **normalising to one canonical form at account creation** would stop new duplicates without locking anyone out mid-transition, and is reversible. That is a guess, not a recommendation — the cross-product owner should decide before anyone builds. ## Not urgent No current duplicate accounts. Filing it because it is exactly the class of finding that dissolves when a chat scrolls, and it bites silently — the symptom is a colleague seeing an empty product and concluding the tool does not work, not an error anyone gets paged about. *Filed by paliad/head at otto/head's request. Cross-references: otto message 5652; m/hihlc#11, m/hihlc#7.*
mAi commented 2026-07-29 14:37:20 +00:00
Author
Collaborator
Copy Link

Three of the four items are done. The fourth is the cross-product one and I cannot answer it from paliad.

What I ran — read-only queries against prod, plus the auth and internal/emaildomain code paths. Going through the issue's own list rather than assuming m's ruling settled all of it.

1. Which form is canonical — DONE

m ruled 2026-07-27: hlc.com canonical, hoganlovells.com alias, hlc.de dropped. internal/emaildomain carries the split.

2. What happens to accounts on the non-canonical form — DONE, and the migration has already run

The issue records "51 users today, all on hoganlovells.com". That is no longer the state. On prod now:

domain auth.users
hlc.com 60
hoganlovells.com 0

And the reconciliation is clean:

  • paliad.users on hoganlovells.com: 0; on hlc.com: 47
  • paliad.users ↔ auth.users email mirror drift: 0
  • humans holding both forms: 0

The accounts were renamed rather than duplicated, and cmd/canonicalize-emails is the machinery that did it. The concrete risk the issue was filed about — "a second, empty account… same human, no projects" — has zero instances.

Sign-in still accepts the alias and says so rather than failing: handleAPILogin returns a notice telling the user their address moved to @hlc.com and that the old one keeps working.

3. Whether signup should refuse the non-canonical form — DONE

This is the item that would have let the problem regrow, so it is worth spelling out. There are two gates, deliberately different:

  • isAllowedEmailDomain — sign-IN, still accepts hoganlovells.com, so no existing holder is locked out.
  • isCreatableEmailDomain — every path that mints a new identity (register, both admin-create paths, invitation recipients). It filters AllowedEmailDomains() through emaildomain.IsAlias(), so only the canonical form can create.

A new @hoganlovells.com signup is refused with a message that names what to do instead: "Neue Zugänge nur mit @hlc.com-Adresse. Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter."

That is the "accept both at the gate, normalise at creation" shape this issue suggested, implemented.

4. Who owns the decision across the three products — STILL OPEN, and I cannot answer it here

This is the part the issue itself says "makes it an issue rather than a paliad ticket". paliad is settled; m/hihlc and youpc are not something I can measure from this repo, and guessing at their state is exactly what would make this comment worse than silence. Someone with those two repos has to say whether they canonicalised the same way, and whether anyone owns the pair going forward.

One side effect worth naming

Dropping hlc.de bites on sign-IN, not just registration, so its holders are locked out at their next login. There is exactly 1 @hlc.de account on prod — a dormant tester@ global_admin. m's own account is not affected. Noting it so it is a known consequence rather than a surprise.

Verdict: partially resolved. Items 1-3 done and measured; item 4 open and cross-product. Not closing — that is m's.

## Three of the four items are done. The fourth is the cross-product one and I cannot answer it from paliad. **What I ran** — read-only queries against prod, plus the auth and `internal/emaildomain` code paths. Going through the issue's own list rather than assuming m's ruling settled all of it. ### 1. Which form is canonical — **DONE** m ruled 2026-07-27: `hlc.com` canonical, `hoganlovells.com` alias, `hlc.de` dropped. `internal/emaildomain` carries the split. ### 2. What happens to accounts on the non-canonical form — **DONE, and the migration has already run** The issue records *"51 users today, all on `hoganlovells.com`"*. That is no longer the state. On prod now: | domain | auth.users | |---|---| | `hlc.com` | **60** | | `hoganlovells.com` | **0** | And the reconciliation is clean: - `paliad.users` on `hoganlovells.com`: **0**; on `hlc.com`: **47** - `paliad.users` ↔ `auth.users` email mirror drift: **0** - humans holding *both* forms: **0** The accounts were renamed rather than duplicated, and `cmd/canonicalize-emails` is the machinery that did it. The concrete risk the issue was filed about — *"a second, empty account… same human, no projects"* — has zero instances. Sign-in still accepts the alias and says so rather than failing: `handleAPILogin` returns a `notice` telling the user their address moved to `@hlc.com` and that **the old one keeps working**. ### 3. Whether signup should refuse the non-canonical form — **DONE** This is the item that would have let the problem regrow, so it is worth spelling out. There are two gates, deliberately different: - `isAllowedEmailDomain` — **sign-IN**, still accepts `hoganlovells.com`, so no existing holder is locked out. - `isCreatableEmailDomain` — every path that **mints a new identity** (register, both admin-create paths, invitation recipients). It filters `AllowedEmailDomains()` through `emaildomain.IsAlias()`, so only the canonical form can create. A new `@hoganlovells.com` signup is refused with a message that names what to do instead: *"Neue Zugänge nur mit @hlc.com-Adresse. Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter."* That is the "accept both at the gate, normalise at creation" shape this issue suggested, implemented. ### 4. Who owns the decision across the three products — **STILL OPEN, and I cannot answer it here** This is the part the issue itself says *"makes it an issue rather than a paliad ticket"*. paliad is settled; **m/hihlc and youpc are not something I can measure from this repo**, and guessing at their state is exactly what would make this comment worse than silence. Someone with those two repos has to say whether they canonicalised the same way, and whether anyone owns the pair going forward. ### One side effect worth naming Dropping `hlc.de` bites on **sign-IN**, not just registration, so its holders are locked out at their next login. There is exactly **1** `@hlc.de` account on prod — a dormant `tester@` `global_admin`. m's own account is not affected. Noting it so it is a known consequence rather than a surprise. --- **Verdict: partially resolved.** Items 1-3 done and measured; item 4 open and cross-product. Not closing — that is m's.
mAi commented 2026-07-31 09:31:38 +00:00
Author
Collaborator
Copy Link

Re-measured 2026-07-31. Question 3 is still yes — a duplicate can be created today, and the door is in hihlc, not in paliad.

Building on the 2026-07-29 comment rather than repeating it. That comment marked items 1-3 done and item 4 open, and it was right about paliad. It also said hihlc and youpc "are not something I can measure from this repo" and did not look further. There is a checkout of m/hihlc on this machine, and reading it changes the answer to question 3.

1. Which form is canonical — settled, and actually consumed

hlc.com canonical, hoganlovells.com alias, via internal/emaildomain (EMAIL_CANONICAL_DOMAIN / EMAIL_ALIAS_DOMAINS).

A package nothing calls answers nothing, so the call sites, all in non-test code:

Site What it does with it
internal/handlers/auth.go:56 sign-in canonicalises before the gate and before GoTrue
internal/handlers/auth.go:197 CreatableEmailDomains() = allowed minus aliases
internal/handlers/users.go:56 identity comparison for the current user
internal/services/paliadin.go:66 owner gate via EqualIdentity
internal/services/user_service.go:144 SyncEmailFromClaim repairs the paliad.users mirror
internal/services/password_reset_service.go:94,155 reset keyed on the canonical address
internal/services/email_canonicalization_service.go the rename machinery
cmd/canonicalize-emails/main.go the rename command

Consumed, not shelf-ware.

2. Accounts on the non-canonical form — migrated, and still clean today

Read-only against prod, 2026-07-31:

hlc.com hoganlovells.com hlc.de
auth.users 60 0 1
paliad.users 47 0 1
  • humans holding both forms: 0 (checked by local part across all three firm domains)
  • paliad.users ↔ auth.users mirror drift: 0
  • mixed-case addresses anywhere in auth.users: 0 of 73
  • firm identities in the shared store with no paliad profile: 13
  • new firm auth.users rows in the last 7 days: 0

The issue's "51 users, all on hoganlovells.com" is history. So is the earlier note about auth.users rows with created_at IS NULL: there are none now.

3. Can a duplicate still be created today? — YES. Not through paliad.

paliad's own creation paths are closed. Three of them, all gated on isCreatableEmailDomain (= ALLOWED_EMAIL_DOMAINS minus aliases):

  • POST /api/register — auth.go:123
  • POST /api/admin/users/full — admin_users.go:85
  • invitation recipients — main.go:229 wires handlers.CreatableEmailDomains into InviteService

POST /api/admin/users is deliberately allowed-only, and correctly so: it attaches a paliad profile to an auth.users row that already exists and mints no identity. PATCH /api/admin/users/{id} cannot change an address — AdminUpdateInput has no email field. Pinned by TestCreatableEmailDomains_ExcludesAliases and friends in internal/handlers/auth_test.go.

The store is shared, and hihlc still creates on the alias domain.

m/hihlc authenticates against the same GoTrue (ydb.youpc.org, auth.users) — its own landing/docs/auth-gate.md says so. Its magic-link path:

// landing/src/routes/api/auth/request-link/+server.ts:62
const { error: otpError } = await locals.supabase.auth.signInWithOtp({
    email,
    options: {
        emailRedirectTo,
        // Allowed HLC domains may register on first login into the shared
        // youpc user base.
        shouldCreateUser: true
    }
});

gated on SIGNUP_EMAIL_DOMAINS, whose committed default in landing/.env.example:15 and in the README is hlc.com,hoganlovells.com — both forms. hihlc.de/login and hlcq.de/login both answer 200 right now. (Read at origin/main 1b5a35c; I did not read hihlc's live Dokploy value, so the deployed allowlist is assumed to match the committed default.)

The chain, end to end. A colleague whose first firm login anywhere is hihlc, entering firstname.lastname@hoganlovells.com:

  1. hihlc mints an auth.users row on the alias domain. paliad's gates never see it.
  2. They come to paliad and sign in with the same address. handleAPILogin canonicalises to @hlc.com first, GoTrue finds no such row, and they get "Ungültige E-Mail-Adresse oder Passwort". This is design §3 Option B's lockout, reappearing for every alias identity minted after the rename.
  3. Registering on the alias is refused with "Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter." In this case that advice is untrue — their address does not work.
  4. So they register as @hlc.com. paliad accepts it, because the address is creatable and no hlc.com row exists. Second identity, second uuid, empty Paliad. Exactly the failure this issue was filed about.

For someone who already has a paliad account the direction is inverted but the store still ends up with two rows: paliad canonicalises and keeps returning them to their real account, so paliad masks the duplicate while hihlc sees the new one.

paliad cannot close this from inside. SignUp goes to GoTrue; nothing in paliad looks for an alias twin before creating, and nothing could stop a row hihlc mints directly.

Secondary, unresolved, much smaller: handleAPIRegister does not lowercase before SignUp, and auth.users' unique index users_email_partial_key is exact-case (the lower(email) index is non-unique). Whether a case-variant twin is possible therefore depends on GoTrue normalising, which I did not verify — settling it needs a write, and prod was read-only for this task. Evidence such as it is: 0 mixed-case rows out of 73. hihlc lowercases before its call; paliad does not.

4. Cross-product ownership — still open, and now measurably divergent

creation on hoganlovells.com
paliad refused — isCreatableEmailDomain
m/hihlc allowed — shouldCreateUser: true, allowlist includes the alias
youpc not established

paliad and hihlc have diverged, and the divergence is the mechanism keeping question 3 alive. hihlc#11 and #7 are both still open.

I could not establish youpc's signup-domain policy: /home/m/dev/youpc.org holds only a .mcp.json, and the Gitea tree listing truncates at 1000 entries without hitting an auth path. What is measured is that the shared store carries 12 non-firm-domain accounts across 8 domains (gmail.com 4, youpc.org 2, then one each of hotmail.com, curevac.com, eip.com, tilmann.eu, msbls.de, flexsiebels.de), so the store itself imposes no domain policy — every gate in this cluster is application-side, and there are at least two of them over one table.

Summary

Questions 1 and 2 are answered and measured. Question 3's answer changed from what the 2026-07-29 comment concluded: paliad closed its own doors, and the problem can still grow through hihlc's. Question 4 is the reason — one identity store, two independent allowlists, opposite policies.

The smallest thing that would close question 3 is dropping hoganlovells.com from hihlc's SIGNUP_EMAIL_DOMAINS for the creating path while keeping it for sign-in, which is the same split paliad already implements. That is a statement of what the measurement points at, not a recommendation — the cross-product owner decides, and this is hihlc's code, not paliad's.

Not closing. Measured read-only; nothing was written to prod and no code changed.

paliad/ritchie, t-paliad-issue-159-canonical-domain-measure.

## Re-measured 2026-07-31. Question 3 is still **yes** — a duplicate can be created today, and the door is in hihlc, not in paliad. Building on the 2026-07-29 comment rather than repeating it. That comment marked items 1-3 done and item 4 open, and it was right about paliad. It also said hihlc and youpc "are not something I can measure from this repo" and did not look further. There is a checkout of `m/hihlc` on this machine, and reading it changes the answer to question 3. --- ### 1. Which form is canonical — **settled, and actually consumed** `hlc.com` canonical, `hoganlovells.com` alias, via `internal/emaildomain` (`EMAIL_CANONICAL_DOMAIN` / `EMAIL_ALIAS_DOMAINS`). A package nothing calls answers nothing, so the call sites, all in non-test code: | Site | What it does with it | |---|---| | `internal/handlers/auth.go:56` | sign-in canonicalises **before** the gate and before GoTrue | | `internal/handlers/auth.go:197` | `CreatableEmailDomains()` = allowed minus aliases | | `internal/handlers/users.go:56` | identity comparison for the current user | | `internal/services/paliadin.go:66` | owner gate via `EqualIdentity` | | `internal/services/user_service.go:144` | `SyncEmailFromClaim` repairs the `paliad.users` mirror | | `internal/services/password_reset_service.go:94,155` | reset keyed on the canonical address | | `internal/services/email_canonicalization_service.go` | the rename machinery | | `cmd/canonicalize-emails/main.go` | the rename command | Consumed, not shelf-ware. ### 2. Accounts on the non-canonical form — **migrated, and still clean today** Read-only against prod, 2026-07-31: | | `hlc.com` | `hoganlovells.com` | `hlc.de` | |---|---|---|---| | `auth.users` | **60** | **0** | 1 | | `paliad.users` | **47** | **0** | 1 | - humans holding both forms: **0** (checked by local part across all three firm domains) - `paliad.users` ↔ `auth.users` mirror drift: **0** - mixed-case addresses anywhere in `auth.users`: **0** of 73 - firm identities in the shared store with no paliad profile: **13** - new firm `auth.users` rows in the last 7 days: **0** The issue's "51 users, all on hoganlovells.com" is history. So is the earlier note about `auth.users` rows with `created_at IS NULL`: there are none now. ### 3. Can a duplicate still be created today? — **YES. Not through paliad.** **paliad's own creation paths are closed.** Three of them, all gated on `isCreatableEmailDomain` (= `ALLOWED_EMAIL_DOMAINS` minus aliases): - `POST /api/register` — `auth.go:123` - `POST /api/admin/users/full` — `admin_users.go:85` - invitation recipients — `main.go:229` wires `handlers.CreatableEmailDomains` into `InviteService` `POST /api/admin/users` is deliberately allowed-only, and correctly so: it attaches a paliad profile to an `auth.users` row that already exists and mints no identity. `PATCH /api/admin/users/{id}` cannot change an address — `AdminUpdateInput` has no email field. Pinned by `TestCreatableEmailDomains_ExcludesAliases` and friends in `internal/handlers/auth_test.go`. **The store is shared, and hihlc still creates on the alias domain.** `m/hihlc` authenticates against the same GoTrue (`ydb.youpc.org`, `auth.users`) — its own `landing/docs/auth-gate.md` says so. Its magic-link path: ```ts // landing/src/routes/api/auth/request-link/+server.ts:62 const { error: otpError } = await locals.supabase.auth.signInWithOtp({ email, options: { emailRedirectTo, // Allowed HLC domains may register on first login into the shared // youpc user base. shouldCreateUser: true } }); ``` gated on `SIGNUP_EMAIL_DOMAINS`, whose committed default in `landing/.env.example:15` and in the README is **`hlc.com,hoganlovells.com`** — both forms. `hihlc.de/login` and `hlcq.de/login` both answer 200 right now. (Read at `origin/main` `1b5a35c`; I did not read hihlc's live Dokploy value, so the deployed allowlist is assumed to match the committed default.) **The chain, end to end.** A colleague whose first firm login anywhere is hihlc, entering `firstname.lastname@hoganlovells.com`: 1. hihlc mints an `auth.users` row on the **alias** domain. paliad's gates never see it. 2. They come to paliad and sign in with the same address. `handleAPILogin` canonicalises to `@hlc.com` first, GoTrue finds no such row, and they get **"Ungültige E-Mail-Adresse oder Passwort"**. This is design §3 Option B's lockout, reappearing for every alias identity minted after the rename. 3. Registering on the alias is refused with *"Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter."* In this case that advice is **untrue** — their address does not work. 4. So they register as `@hlc.com`. paliad accepts it, because the address is creatable and no `hlc.com` row exists. **Second identity, second uuid, empty Paliad.** Exactly the failure this issue was filed about. For someone who already has a paliad account the direction is inverted but the store still ends up with two rows: paliad canonicalises and keeps returning them to their real account, so paliad masks the duplicate while hihlc sees the new one. paliad cannot close this from inside. `SignUp` goes to GoTrue; nothing in paliad looks for an alias twin before creating, and nothing could stop a row hihlc mints directly. **Secondary, unresolved, much smaller:** `handleAPIRegister` does not lowercase before `SignUp`, and `auth.users`' unique index `users_email_partial_key` is exact-case (the `lower(email)` index is non-unique). Whether a case-variant twin is possible therefore depends on GoTrue normalising, which I did not verify — settling it needs a write, and prod was read-only for this task. Evidence such as it is: 0 mixed-case rows out of 73. hihlc lowercases before its call; paliad does not. ### 4. Cross-product ownership — **still open, and now measurably divergent** | | creation on `hoganlovells.com` | |---|---| | **paliad** | refused — `isCreatableEmailDomain` | | **m/hihlc** | **allowed** — `shouldCreateUser: true`, allowlist includes the alias | | **youpc** | not established | paliad and hihlc have diverged, and the divergence is the mechanism keeping question 3 alive. hihlc#11 and #7 are both still open. I could not establish youpc's signup-domain policy: `/home/m/dev/youpc.org` holds only a `.mcp.json`, and the Gitea tree listing truncates at 1000 entries without hitting an auth path. What is measured is that the shared store carries 12 non-firm-domain accounts across 8 domains (`gmail.com` 4, `youpc.org` 2, then one each of `hotmail.com`, `curevac.com`, `eip.com`, `tilmann.eu`, `msbls.de`, `flexsiebels.de`), so the store itself imposes no domain policy — every gate in this cluster is application-side, and there are at least two of them over one table. --- ### Summary Questions 1 and 2 are answered and measured. Question 3's answer changed from what the 2026-07-29 comment concluded: **paliad closed its own doors, and the problem can still grow through hihlc's.** Question 4 is the reason — one identity store, two independent allowlists, opposite policies. The smallest thing that would close question 3 is dropping `hoganlovells.com` from hihlc's `SIGNUP_EMAIL_DOMAINS` for the *creating* path while keeping it for sign-in, which is the same split paliad already implements. That is a statement of what the measurement points at, not a recommendation — the cross-product owner decides, and this is hihlc's code, not paliad's. Not closing. Measured read-only; nothing was written to prod and no code changed. *paliad/ritchie, t-paliad-issue-159-canonical-domain-measure.*
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#159
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?