Fix chat/send userId attribution + eliminate duplicate browser tabs

[joelteply]

Summary

• chat/send userId bug — personas can't post to chat rooms #376 fix: chat/send without explicit senderId now resolves to the seeded human owner. Previously resolved to "Claude Code" (agent detection) or "@cli" depending on how jtag was invoked. Before/after visible in chat export: message #777bb2 shows "Claude Code", message #5a1c5b shows "Joel".
• Multiple browser tabs launched on npm start #335 fix: Removed Phase 6 browser launch from parallel-start.sh. The SystemOrchestrator.detectAndManageBrowser() already handles browser lifecycle — the shell script was racing it and opening a duplicate tab on every cold start.

Test plan

• npm run build:ts — compiles clean
• npm start — deploys successfully
• ./jtag collaboration/chat/send --room="general" --message="test" — shows senderName: "Joel", senderType: "human"
• AI personas respond to the message
• Verify only one browser tab opens on cold start

Closes #376, closes #335

[Copilot]

Pull request overview

This PR aims to (1) fix incorrect sender attribution for chat/send-style message injection by defaulting to the seeded human owner, and (2) prevent duplicate browser tabs by removing browser-launch logic from parallel-start.sh in favor of the orchestrator-managed lifecycle.

Changes:

• Resolve CLI sessions to the seeded human owner (with a fallback to the prior uniqueId-based behavior when no owner exists yet).
• Change collaboration/chat/send default sender resolution to prefer an explicit senderId, otherwise resolve a human owner.
• Remove shell-script browser launching to avoid racing SystemOrchestrator.detectAndManageBrowser().
• Regenerate command registries/constants/schemas (new commands added to generated outputs).

Reviewed changes

Copilot reviewed 7 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/commands/collaboration/chat/send/server/ChatSendServerCommand.ts	Changes default sender resolution; adds helper to resolve human owner fallback.
src/daemons/session-daemon/server/SessionDaemonServer.ts	Updates CLI session identity mapping to prefer seeded owner.
src/scripts/parallel-start.sh	Removes Phase 6 browser open logic; keeps hot-restart reconnect wait.
src/shared/generated-command-constants.ts	Regenerated command constant list with additional commands.
src/server/generated.ts	Regenerated server command registry with additional commands.
src/browser/generated.ts	Regenerated browser command registry with additional commands.
src/generated-command-schemas.json	Regenerated command schema metadata with additional commands.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

chat/send now overrides the sender to the first type:'human' user whenever senderId is omitted. This breaks the documented behavior (“defaults to current user from session”) and will misattribute messages in multi-user scenarios (e.g., test clients connected as different humans) because their session userId is ignored.

Suggestion: keep params.userId as the default sender, and only remap to the seeded owner when the session user is a tool/placeholder identity (e.g., user.type !== 'human', or uniqueId is '@cli', or uniqueId starts with 'anon-').

Suggested change

	// 2. Get sender — explicit senderId takes priority, otherwise resolve human owner.
	// params.userId reflects the session identity (could be @cli, agent, system).
	// For chat/send without explicit sender, the human owner is the correct attribution
	// since this is a single-owner system and CLI/agent are the human's tools.
	const sender = params.senderId
	? await this.findUserById(params.senderId, params)
	: await this.findHumanOwnerOrFallback(params);
	// 2. Get sender
	// - Explicit senderId takes priority.
	// - Otherwise, default to the session user (params.userId) when it is a real human.
	// - Only remap to the seeded human owner when the session user is a tool/placeholder
	// identity (e.g., user.type !== 'human', uniqueId === '@cli', or uniqueId.startsWith('anon-')),
	// or when there is no session user.
	let sender;
	if (params.senderId) {
	sender = await this.findUserById(params.senderId, params);
	} else if (params.userId) {
	const sessionUser = await this.findUserById(params.userId as UUID, params);
	const sessionEntity = sessionUser.entity;
	const uniqueId = (sessionEntity as any).uniqueId as string | undefined;
	const isPlaceholderIdentity =
	sessionEntity.type !== 'human' ||
	uniqueId === '@cli' ||
	(typeof uniqueId === 'string' && uniqueId.startsWith('anon-'));
	sender = isPlaceholderIdentity
	? await this.findHumanOwnerOrFallback(params)
	: sessionUser;
	} else {
	sender = await this.findHumanOwnerOrFallback(params);
	}

[Copilot]

findHumanOwnerOrFallback() uses DataList with filter: { type: 'human' }, limit: 1, which can return an anonymous browser user (uniqueId starting with anon-) or an arbitrary human depending on DB ordering. This can defeat the goal of attributing to the seeded owner.

Suggestion: mirror SessionDaemonServer.findSeededHumanOwner() logic by fetching multiple human users and selecting the first non-anonymous one (uniqueId not starting with anon-), ideally with a deterministic orderBy (e.g., createdAt asc/desc) to avoid nondeterministic attribution.

Suggested change

	limit: 1,
	context: params.context,
	sessionId: params.sessionId,
	});
	if (result.success && result.items && result.items.length > 0) {
	const owner = result.items[0];
	return { id: owner.id, entity: owner };
	}
	// No human owner seeded yet — fall back to session userId
	// Fetch multiple humans with deterministic ordering so we can skip anonymous users
	limit: 50,
	orderBy: { createdAt: 'asc' },
	context: params.context,
	sessionId: params.sessionId,
	});
	if (result.success && result.items && result.items.length > 0) {
	// Prefer the first non-anonymous human (uniqueId not starting with "anon-")
	for (const user of result.items) {
	const uniqueId = (user as any).uniqueId as string | undefined;
	if (!uniqueId || !uniqueId.startsWith('anon-')) {
	return { id: user.id, entity: user };
	}
	}
	}
	// No suitable human owner found — fall back to session userId

[Copilot]

The cli clientType is now forcibly resolved to the seeded human owner when one exists. If the CLI/websocket client is also used for automation or multi-user testing, this collapses distinct identities into one and can change authorization/audit behavior.

Suggestion: gate this behavior behind an explicit “single-owner dev mode” config/flag, or restrict it to the specific placeholder uniqueId (e.g., '@cli') so other CLI identities can still resolve via uniqueId/userId as before.