Feature request: Implement daily task FORM_AN_INNER_CONNECTION

[tickBit]

What do you want to see in the API?

Add server-side daily task progress tracking for FORM_AN_INNER_CONNECTION.

The task should progress when a player successfully sends one supported predefined message to their current clan chat.

Player-facing instruction in Finnish:

Avaa klaanin chat ja lähetä viesti. Huomaa, miltä tuntuu aloittaa vuorovaikutus. Opit, että viestintä pelissä rakentaa suhteita ja merkityksiä, ei vain siirrä tietoa.

The backend should support the 16 currently documented chat response types:

export enum ChatResponseType {
  NEED_COMPANY = 'NeedCompany',
  NEW_GAME = 'NewGame',
  COMING_TO_PLAY = 'ComingToPlay',
  WANT_TO_PLAY = 'WantToPlay',
  YES = 'Yes',
  NO = 'No',
  ONLINE = 'Online',
  LEAVING = 'Leaving',
  BUSY = 'Busy',
  WINNING_STREAK = 'WinningStreak',
  LOSING_STREAK = 'LosingStreak',
  DISCORD = 'Discord',
  LONELY = 'Lonely',
  GOOD_GAME = 'GoodGame',
  BAD_GAME = 'BadGame',
  SKILL_ISSUE = 'SkillIssue',
}

How do you think this should work?

• Configure FORM_AN_INNER_CONNECTION as a one-step server-tracked daily task with amount: 1.
• The clan chat WebSocket payload should contain a supported responseType and a valid emotion.
• The backend validates both values before creating the message.
• The response type must be one of the 16 currently supported ChatResponseType values.
• Any valid emotion, including the neutral Blank option, can be used.
• The message must be sent by the authenticated player to their current clan.
• Emit a daily task event for ServerTaskName.FORM_AN_INNER_CONNECTION only after the message has been validated and persisted successfully.
• Credit progress only to the player who sent the message.
• Complete the task through the existing daily task completion, reward and MQTT notification flow.
• Failed validation or persistence must not progress the task.
• Global and private messages must not progress the task.
• Reactions, edits and deletions must not progress the task.

Example clan message payload:

{
  "responseType": "GoodGame",
  "emotion": 1
}

Any additional info?

ChatGateway.handleClanMessage() already emits a FORM_AN_INNER_CONNECTION event after the clan chat service returns without an error. Verify that the event is awaited and emitted strictly after successful persistence.

The current task definition uses a random message count and the instruction Lähetä X viesti klaanichattiin. Replace it with the one-step configuration and the Finnish instruction above.

The existing backend Feeling enum is not the source of truth for the predefined chat system. The supported emotion contract is:

export enum ChatEmotion {
  BLANK = -1,
  SORROW = 0,
  JOY = 1,
  PLAYFUL = 2,
  ANGER = 3,
  LOVE = 4,
}

The chat response type should be transferred and stored as a stable string matching the frontend’s C# ResponseType name, such as GoodGame. The selected emotion should be transferred separately using the agreed numeric ChatEmotion value. This avoids relying on enum order or localized message text.

The 16 supported responses and their emotion-specific variants are defined in the [ALT ZONE chat specification](https://docs.google.com/document/d/16lYw-sdYMsDzispOfp-Ad4VRZ5KtEds1quU4qS0Sd6w).

Add tests covering successful completion, invalid response and emotion values, failed persistence, clan ownership, unsupported response types, and message types that must not progress the task.

[CapoMK25]

I dropped this from myself @tickBit due to not wanting to step on the daily task toes so to speak, as this is the last one left on the list anyway by the looks of it.

I instead took #995. The branch created for this issue on the right-hand side under Development should still be usable, I haven't committed or done anything to it yet except locally, that I reversed when I saw @EemeliJ had implemented some of the similar changes in yesterday's PR.

[tickBit]

This issue ( #991 ) could be handled accordingly to #995 , which is planned to be done with AI, because it's quite mechanical change to several files. Edit: After #995 has been merged.

[CapoMK25]

"This issue should be implemented after all the daily tasks are implemented" is mentioned on #995.

Taken literally, this should then be done before it as this is the last daily task issue left on the table?

[tickBit]

My original thought was, that first all daily tasks would be done, then their scoring system renewed, but #995 could be done first and then the last daily task issue. If they're are done at the same time, there will be some difficult merge conflicts.

[CapoMK25]

Assigned this back to myself. I'll take both, and I'll do this first as I started it already last weekend, and move to #995 directly from there.

[CapoMK25]

Baseline done already. Working on creating new tests next.