Cookiemonsters

Imported from the pre-Redmine CookieMonsters TODO during the 2026-08-29 migration.

Original priority: P2 — Next feature layer

• Add playful connection labels/statuses to accepted friendships so a friend relationship feels personal rather than like a plain contact list:
  • every accepted friendship is a mutual Connection and a member may have Connections with as many people as they want; there is no exclusivity or limit implied by a label;
  • a connection label describes how one member labels that specific friend (for example, “Ambi is my Snack Commander”); each side may still have a different label for the same friendship, but no label becomes active/public until the friend it describes has approved it;
  • selecting or changing Your connection label must create a pending connection-label request to that friend instead of changing the visible label immediately;
  • the sender must see the pending proposal clearly in their own Friends/Connections UI while waiting for a response, e.g. Snack Commander 🍿 · Pending approval or Snack Commander (pending request) on that friend's card/dropdown area; never leave the sender wondering whether the request was actually sent;
  • the pending marker should remain visible to the sender anywhere they manage that connection until it is accepted, denied, cancelled or replaced; the recipient sees the proposal in their request UI, while ordinary third-party profile viewers must not see the unapproved label;
  • if there is already a previously accepted label, keep that accepted label as the public/active relationship while separately showing the sender their new pending proposal; do not replace the accepted public label with an unapproved one;
  • on Accept, remove the pending indicator immediately and promote the proposed label to the sender's active/accepted label; on Deny or sender cancellation, remove the pending proposal/indicator and leave the previous accepted label unchanged;
  • the recipient must get a clear request showing who proposed the label and which label was proposed, with explicit Accept and Deny actions;
  • until the recipient accepts, keep the previously accepted label in effect; if there has never been an accepted custom label, use the safe neutral Just Friends 🤝 state rather than presenting the pending proposal as agreed;
  • on Accept, make the proposed label the sender's active relationship label for that friend and allow it to appear in the sender's Friends/Connections UI and public friend list according to privacy/NSFW rules;
  • on Deny, discard the proposed change and leave the previously accepted label unchanged; denial must never remove the underlying friendship;
  • the sender should be able to cancel a still-pending label request, and there should be at most one pending label proposal per sender→recipient direction so repeated changes do not create a pile of stale requests;
  • if the sender chooses another label while one is still pending, replace/cancel the older pending proposal cleanly and notify the recipient only about the current actionable request;
  • the recipient may independently propose their own label for the sender, which creates a separate request in the opposite direction and likewise requires approval;
  • connection-label requests should appear in the same polished Friend/Connection Requests experience and count as actionable requests for the dedicated two-members indicator/notification state;
  • if the friendship is removed or either member blocks the other while a label request is pending, cancel the request immediately and ensure no pending/accepted label leaks afterwards;
  • show accepted labels in the friends/connection UI in a warm, small badge/chip and on the visible Friends/Connections profile section; do not show pending labels to ordinary third-party viewers;
  • when a new friend request itself is accepted, the friendship may begin safely as Just Friends 🤝 and either person can immediately propose a more personal label that the other person then accepts/denies; do not force an unapproved playful label during friendship acceptance;
  • initial curated set of 50 connection labels:
    1. Just Friends 🤝
    2. Gaming Buddy 🎮
    3. Co-op Cutie 🕹️
    4. Pixel Pal 👾
    5. Quest Bestie 🗺️
    6. Respawn Partner ♻️
    7. Boss Fight Backup ⚔️
    8. Loot Goblin 💎
    9. Sidekick Supreme 🦸
    10. Chaos Coordinator 🌪️
    11. Circus Master 🎪
    12. Lollipop 🍭
    13. Cookie Accomplice 🍪
    14. Snack Commander 🍿
    15. Tea Spill Partner ☕
    16. Mischief Manager 😈
    17. Bad Influence 😇
    18. Trouble Twin 👯
    19. Sweet Menace 🍬
    20. Tiny Disaster 💥
    21. Chaos Gremlin 👹
    22. Drama Llama 🦙
    23. Moonlight Menace 🌙
    24. Heart Thief 💘
    25. Flirt Alert 😉
    26. Cheeky Monkey 🙈
    27. Cuddle Criminal 🧸
    28. Spicy Sidekick 🌶️
    29. Partner in Crime 🕶️
    30. My Person 💛
    31. Spanking Monkey 🍑🙈
    32. Big Donkey Kong 🍌🦍
    33. Naughty Nibbler 😏
    34. Cheeky Peach 🍑
    35. Banana Bandit 🍌
    36. Velvet Trouble 😈
    37. Saucy Sidekick 🌶️
    38. Wink Magnet 😉
    39. Midnight Snack 🌙🍫
    40. Peachy Problem 🍑
    41. Tease Machine 😜
    42. Pillow Menace 🛏️
    43. Honey Trap 🍯
    44. Hot Cookie 🔥🍪
    45. Kissy Monster 💋
    46. Naughty Nugget 😈
    47. Mischief Magnet 🧲
    48. Flirty Gremlin 😏👹
    49. Sweet & Dangerous 🍭⚠️
    50. Trouble After Dark 🌙😈
  • keep the first set broadly cute/funny and the extra set a little more naughty/suggestive without becoming explicit; the labels are still playful connection nicknames, not sexual-role labels;
  • classify labels 31–50 as 18+/NSFW choices: they are only visible/selectable when the member has a valid birth date showing age 18+ and has explicitly enabled the account's 18+/NSFW content mode; otherwise only the normal SFW connection-label set is shown.
  • an 18+/NSFW connection-label request also requires mutual NSFW opt-in: both the member proposing the label and the friend receiving/approving it must currently have 18+/NSFW content mode enabled (with valid 18+ eligibility); a member must never be able to propose or assign an NSFW relationship status to someone who has not opted into NSFW.
  • enforce the mutual opt-in server-side both when an NSFW label request is created and again when it is accepted, so a preference change while the request is pending cannot bypass the gate.
  • if the recipient does not have NSFW enabled, reject creation of the request and show a friendly explicit message such as: “You selected an 18+/NSFW relationship status, but {name} does not have NSFW enabled. Ask them to enable 18+/NSFW content, or choose a SFW status.”
  • the error must not reveal the recipient's birth date or private age-verification data; it should only state that NSFW is not enabled/available for that connection.
  • if either person later disables 18+/NSFW mode, any existing NSFW relationship label between them must immediately stop being shown in normal member-facing UI and must no longer be usable until both sides have NSFW enabled again; decide during implementation whether to preserve it privately for restoration or reset it to a safe label.
  • changing Content mode back to SFW should hide 18+ label choices from selection UI; decide during implementation whether an already-selected 18+ label is automatically reset to a safe label or simply hidden until 18+ mode is enabled again, but never expose it through SFW-facing UI.
  • keep labels and request/action strings translation-ready through the site language files instead of hard-coding display strings.

CM-TODO-ID:35a3593b7a57faab351b

Future notes, acceptance criteria and status changes belong in this Redmine issue.