After onboarding the user ended up in a 1:1 chat with "Chief", and the
"Hauptthread" was a group the web client created and found by name. The
main bot had no conversation it actually led, and addressing another bot
there did nothing unless the user had added it as a member first.
Now the main conversation is a real place:
- bots.ensureMain creates or returns the main bot. Bootstrap and space
navigation return `main` ({ botId, groupId, spaceId }) once the main
bot exists; reading navigation never creates a bot.
- The main bot leads the main conversation and answers when nobody is
addressed: message routing, follow-ups, reactions and clearing the
thread fall back to the group's lead instead of its first member.
- Addressing a same-space bot that is not a member yet, by @Name or a
mention chip, makes it join before the message is routed, so it
answers in the conversation. Specialists from other spaces do not join.
- The main bot cannot be archived or deleted, the main conversation
cannot be archived or deleted or have its members edited, and child
bots never dissolve it. Renaming the main bot renames the conversation.
- Web: onboarding uses bots.ensureMain and finishes in the main
conversation. The main conversation is the first sidebar entry in every
space, shown with the main bot's avatar and name; from another space it
switches back to the home space. The main bot is not listed again among
the bots, its 1:1 thread stays reachable by URL. The client no longer
creates or detects the "Hauptthread" by name, refetches a group when it
changes, and shows the speaker of any of the user's bots in a group.
- Onboarding no longer resets the step when its bootstrap resolves after
the user has already moved on, and new spaces open in the app instead
of walking onboarding again.
Tests: group mention routing with a default responder, lead follow-ups,
child-bot guards, a journey for the main conversation (lead answers,
addressed bot joins, guards, rename), authorization for bots.ensureMain,
and an E2E spec that lands in the main conversation, gets an answer from
the lead, sees an addressed bot join, and reaches the conversation from
another space. Existing E2E specs start in the main bot's thread through
a helper or use the main conversation where that is what they test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
76 lines
2.6 KiB
TypeScript
76 lines
2.6 KiB
TypeScript
import { ORPCError } from "@orpc/server";
|
|
import type { Actor, MainConversationRef } from "@rakazo/contracts";
|
|
import { hasMentionToken } from "@rakazo/core";
|
|
import {
|
|
ensureMainConversation,
|
|
findMainBotId,
|
|
joinMainConversation,
|
|
type PrismaClient,
|
|
} from "@rakazo/db";
|
|
|
|
/**
|
|
* Where the main conversation lives, repaired or created on the way. Null until onboarding has
|
|
* created the main bot: reading navigation must never create a bot by itself.
|
|
*/
|
|
export async function loadMainConversationRef(
|
|
prisma: PrismaClient,
|
|
userId: string,
|
|
): Promise<MainConversationRef | null> {
|
|
if (!(await findMainBotId(prisma, userId))) return null;
|
|
const conversation = await ensureMainConversation(prisma, userId);
|
|
return {
|
|
botId: conversation.leadBotId,
|
|
groupId: conversation.groupId,
|
|
spaceId: conversation.spaceId,
|
|
};
|
|
}
|
|
|
|
export function assertNotMainBot(bot: { kind: string }, message: string) {
|
|
if (bot.kind === "main") throw new ORPCError("BAD_REQUEST", { message });
|
|
}
|
|
|
|
/** Unknown or foreign groups fall through so the caller's own lookup reports them as before. */
|
|
export async function assertNotMainConversation(
|
|
prisma: PrismaClient,
|
|
actor: Pick<Actor, "spaceId" | "userId">,
|
|
groupId: string,
|
|
message: string,
|
|
) {
|
|
const group = await prisma.chatGroup.findFirst({
|
|
where: { id: groupId, spaceId: actor.spaceId, userId: actor.userId },
|
|
select: { kind: true },
|
|
});
|
|
if (group?.kind === "main") throw new ORPCError("BAD_REQUEST", { message });
|
|
}
|
|
|
|
/** The main conversation carries the main bot's name. */
|
|
export async function renameMainConversation(prisma: PrismaClient, userId: string, name: string) {
|
|
await prisma.chatGroup.updateMany({ where: { userId, kind: "main" }, data: { name } });
|
|
}
|
|
|
|
/**
|
|
* Same-space bots the user addresses in the main conversation, by `@Name` or a mention chip,
|
|
* join it first, so the member mention rules route the message to them.
|
|
*/
|
|
export async function joinAddressedBots(
|
|
prisma: PrismaClient,
|
|
actor: Pick<Actor, "spaceId" | "userId">,
|
|
input: { memberBotIds: string[]; text: string; botMentionIds: string[] },
|
|
) {
|
|
const candidates = await prisma.bot.findMany({
|
|
where: {
|
|
userId: actor.userId,
|
|
spaceId: actor.spaceId,
|
|
archivedAt: null,
|
|
id: { notIn: input.memberBotIds },
|
|
},
|
|
select: { id: true, name: true },
|
|
});
|
|
const addressed = candidates
|
|
.filter((bot) => input.botMentionIds.includes(bot.id) || hasMentionToken(input.text, bot.name))
|
|
.map((bot) => bot.id);
|
|
if (addressed.length === 0) return;
|
|
// Subscribers pick up the group.updated event with the send that follows.
|
|
await joinMainConversation(prisma, { userId: actor.userId, botIds: addressed });
|
|
}
|