Proposal: Capture alt-account context from leader feedback

[jthingelstad]

Decision

Approve a small capability for Elixir to capture leader-confirmed alternate-account relationships and use them to avoid treating an alt as a brand-new stranger in future welcomes, relays, and recognition.

This is a proposal, not build-ready work. Jamie should approve by swapping proposal to approved + ready, or decline with wontfix.

Mission fit

• Help members understand what is happening and what matters right now: distinguishes a true new member from an existing member's alt.
• Reinforce clan identity and memory: remembers leader-supplied clan knowledge instead of discarding it after one reaction.
• Support leadership with grounded recommendations: reduces leader cleanup on welcome relays and account-context misses.

Evidence

Elixir treated p2w_gtr0410 as a new member, then leadership supplied exact corrective context:

• #welcome, 2026-06-24T11:34:34Z, Discord message 1519304724732444742, workflow/event v5-reactive / welcome:member_joined, intent 156: public generic welcome for p2w_gtr0410.
• #leader-actions, 2026-06-24T11:34:37Z, Discord message 1519304739701919936, workflow/event arena-relay / welcome_relay, action 82: in-game welcome relay for p2w_gtr0410.
• Action 82 was rejected at 2026-06-24T12:42:38Z with leader note: This is another players alt account so I’m skipping a welcome message.
• #player-highlights, 2026-06-27T10:03:48Z, Discord message 1520369049148850206, workflow/event v5-reactive / celebrate:badge_earned, intent 182: Elixir later wrote Three days in and already leaving a mark, still treating the account as a fresh independent member.

Current storage check found p2w_gtr0410 only as member 134, player tag #VRL829LGY, with no visible alias/metadata state describing an alt-account relationship.

Smallest valuable version

When a leader rejects or comments on a welcome/identity-related leader action with clear alt-account language, Elixir should create a leadership-scoped account-relationship fact for review/use by future workflows.

The smallest useful behavior is not full automatic identity merging. It is:

1. store candidate alt account context with source evidence and scope;
2. suppress generic in-game welcome relays for that account after the leader has said it is an alt;
3. let future recognition copy avoid false-newcomer language like three days in when the account has leader-confirmed alt context.

Guardrails

• Do not publicly reveal that an account is an alt unless leaders explicitly choose that wording.
• Do not merge stats or identities automatically in public leaderboards without a separate approved design.
• Prefer leadership-scoped memory first; promote to durable public/member identity only after an explicit leader confirmation path exists.
• Treat this as signal reduction and memory accuracy, not as a reason to add more posts.

Acceptance criteria

• Given a rejected welcome_relay or leader note that marks a player as an alt, Elixir persists a scoped relationship fact with the action ID, Discord message ID, timestamp, and note evidence.
• Future welcome relay generation checks that fact and suppresses or reframes generic welcome copy for the same player tag.
• Future player-highlight copy can avoid newcomer framing for a leader-confirmed alt account.
• Tests cover the positive case and a guardrail case where ambiguous feedback does not create an alt relationship.