P1 Web UI never sends client_type: "ui" — all new browser-created chats will be mislabeled as "api" (Edge Case Analyst P1, Frontend Reviewer P1)

AgentCreatePage.tsx is the only UI code path that calls createMutation.mutateAsync(...). The request object sets organization_id, content, workspace_id, model_config_id, mcp_server_ids, and plan_mode, but never sets client_type. Because the SDK field is json:"client_type,omitempty" and the Go zero-value for the string type is "", this omits the field entirely. The handler treats req.ClientType == "" as "default to api".

Frontend Reviewer adds: This is the only place the UI calls createChat. The migration backfills existing rows correctly to "ui", but all new UI-created chats will be tagged as "api" from the moment this merges.

This defeats the entire purpose of the enum for newly created chats. Fix: add client_type: "ui" to the mutateAsync call in AgentCreatePage.tsx (lines 61–69).

P3 Struct field crammed onto same line as SystemPrompt, breaking one-field-per-line convention (Go Architect P2, Contract Auditor P3, Database Reviewer P3, Style Reviewer Nit)

ClientType: clientType, SystemPrompt: req.SystemPrompt, packs two struct fields onto one line. Every other field in this literal occupies its own line with aligned values. This is likely an artifact of inserting the new field without reflowing the struct.

Same issue appears in two other locations (see comments on chatd.go and subagent.go). In chatd.go:915 the trailing comment // Chats created with an initial user message start pending. originally described Status but now appears to annotate ClientType — which it doesn't. Worth a quick reformat: each field on its own line, comment stays with Status.

P3 Redundant defensive default — could use cmp.Or (Contract Auditor P3, Go Architect P3, Modernization Reviewer Nit)

The HTTP handler (exp_chats.go:571) already defaults to ChatClientTypeApi when req.ClientType is empty and validates the value with .Valid(). Then chatd.go:890 re-applies the same empty-string-to-api default. This isn't a bug — it's defense-in-depth. But it means any new internal caller that forgets to set ClientType will silently get "api" without any error signal.

Modernization Reviewer adds: This if opts.ClientType == "" { ... } pattern can be replaced with opts.ClientType = cmp.Or(opts.ClientType, database.ChatClientTypeApi), which is already established in this codebase (e.g. chatd/chattool/skill.go, agent/agentcontextconfig/api.go).

Acceptable as-is — the defense-in-depth is reasonable with a single caller. If keeping it, the cmp.Or form is more idiomatic for this repo.

Nit Misattributed comment — // Chats created with an initial user message start pending. now trails ClientType instead of Status (Go Architect, Style Reviewer)

The comment was originally on its own line describing Status. The insertion of ClientType on the same line shifted it so it now appears to annotate ClientType. Move the comment back to its own line above Status, and give ClientType its own line.

Also: subagent.go:489 has the same two-fields-on-one-line issue (ClientType: parent.ClientType, Status: database.ChatStatusPending,).

Obs client_type not included in telemetry (Contract Auditor)

The telemetry Chat struct includes Status, Mode, HasParent, etc., but not ClientType. If the purpose of client_type is to distinguish UI-created from API-created chats, telemetry is the main place where that distinction would be analytically valuable — e.g., tracking API adoption rates.

Not blocking, but worth considering as a follow-up if the goal is fleet-wide visibility into client-type distribution.

Obs Child chat inheritance untested (Test Auditor)

subagent.go copies parent.ClientType to the child InsertChatParams, but no existing test creates a parent with one client type and verifies the child got the same value. The code is straightforward (a single field copy), so this is low risk, but a refactor could silently drop it.