feat: Add dedicated chats for workspace and PR fixers

[lazabogdan]

Summary

Introduces dedicated chat windows for workspace fixer and PR fixer agents, tracked with runtime conversation IDs. Users can now focus on and interact with fixer runs separately from the main workspace/review chat, with independent runtime controls (model, effort, provider) scoped to each fixer conversation.

User Impact

• New focus types: Workspace and PR repair conversations now appear in the chat focus switcher with "Fixer" and "PR Fixer" labels and warning tone.
• Separate chat UI: When focused on a fixer repair, the composer and chat targeting switch to the dedicated repair conversation instead of the parent workspace.
• Independent runtime controls: Fixer conversations have their own role-based runtime overrides (model, effort, provider), persisted per conversation.
• Back navigation: Users can navigate back from fixer chat to the parent workspace/review conversation.
• Repair tracking: Each repair attempt now carries a runtime_conversation_id to tie it to its dedicated chat history.

Technical Context

Frontend

• Extended AgentsChatFocus union type with workspace_repair and pr_fixer variants, each holding a conversationId.
• Added agentChatFocusRole.ts helpers to centralize derivation of runtime role (workspace_repair | pr_fixer), label ("Fixer" | "PR Fixer"), and tag ("FIX") from chat focus.
• AgentsActiveConversationPanel now:
  • Routes fixer focus types to their child conversations for sends, receives, and context key isolation.
  • Applies workspace runtime controls (model, effort overrides) when a fixer is focused.
  • Renders fixer status in the runtime banner ("Fixer run active" vs. "PR Fixer run active").
• AgentsChatHeader and AgentsComposerWorkspaceChangesCard support navigation to fixer conversations.
• Updated useAgentsViewController to auto-focus durable repair runtime conversations when the review context reports a repair in progress.

Backend

• Added runtime_conversation_id: Option<String> field to AgentWorkspaceRepair entity, persisted in SQLite.
• New migration v20260731170447_agent_workspace_repair_runtime_conversation adds the nullable column and index to repair attempts.
• New agent_workspace_fixer_conversation.rs module manages fixer conversation creation, message routing, and lifecycle.
• AgentWorkspaceReviewContext now exposes:
  • repairRuntimeConversationId: the conversation ID for the durable repair run (if active).
  • repairFixerKind: the fixer type (workspace_repair or pr_fixer).
• Repository methods now support querying and updating repair attempts by runtime conversation ID, with per-attempt fencing to prevent cross-attempt confusion.
• pr_merge_poller dispatches PR fixer repairs through the PR fixer conversation.
• durable_attempt_recovery and unified_chat_commands route repair messages through the runtime conversation.
• Both memory and SQLite repo implementations updated with repair attempt tracking and fencing tests.

Risks / Follow-Ups

• Migration: Existing repair attempts will have NULL runtime_conversation_id. Durable recovery and auto-resume rely on the review context to inject the runtime conversation ID on resume; new attempts will always populate it.
• Fixer lifecycle: Repair conversation creation must happen before the first message arrives; if creation fails or is delayed, messages may not route correctly. Startup recovery validates the tie-in at startup.
• Focus routing complexity: The chat focus system now branches on two fixer types in multiple places; test coverage validates both paths.
• Backward compat: Repair fingerprinting and cross-attempt memory do not depend on runtime conversation IDs, so they remain stable across agent restarts.

View full plan

Dedicated Chat Runtimes for Workspace Fixer and PR Fixer Agents

Goal

"we have a couple of agents that are started ... from different scenarios linked to a agent workspace such as agent > review > fix workspace or agent > pr monitor > fix PR … that are using the same chat surface as the main agent runtime UI. this causes complications with the chat composer ... would like to change these to their own dedicated chat runtimes just like agent workspace review is, switching to the separate chat UI context and getting a back to workspace chat button in the chat header ... and getting a slot into the chat selector in the chat composer so we can switch back and forth."

Move every workspace-linked fixer agent run out of the parent workspace conversation and into its own parented child conversation, exactly like Workspace Review already does, then surface each as a first-class AgentsChatFocus slot.

The Actual Problem (evidence)

Three dispatch families currently launch a fixer into the parent workspace conversation using a one-shot agent_name_override:

Family	Agent	Dispatch site
Workspace repair (base-update / publish / PR-conflict)	ralphx-agent-workspace-repair	pr_merge_poller.rs:2120, pr_merge_poller.rs:~2340, agent_workspace_publish_recovery/durable_attempt_recovery.rs:1043, unified_chat_commands/mod.rs:9003 (private helper, 3 callers)
PR autofix	ralphx-agent-workspace-pr-fixer	pr_merge_poller.rs:4059 (agent_workspace_pr_fixer_send_options), durable_attempt_recovery.rs:998
Review blocking fixer	ralphx-agent-workspace-repair	agent_workspace_review.rs:3190

Not in scope: pr_merge_poller.rs:4211 — uses agent_name_for_workspace_mode (the main workspace agent reviewing PR status), not a fixer dispatch.

Every one of them passes conversation_id_override: Some(workspace.conversation_id.clone()).

Two concrete consequences:

1. Composer role guessing. AgentsActiveConversationPanel.tsx:1318-1350 sniffs activeRoleRunMeta.launchRole out of the parent conversation's chat store to decide whether the composer is talking to Reviewer or Fixer, down to a hardcoded activeRoleTag = ... ? "REV" : "FIX". This is the workaround the request asks to remove.
2. Follow-up messages go to the wrong agent. A user reply typed while a fixer run is live resolves through the parent conversation's normal identity. chat_service_context.rs:2777 falls back to resolve_agent(context_type, status), which for a Project conversation is AGENT_CHAT_PROJECT (chat_service_helpers.rs:50-64) — not the fixer. The override only shaped that one launched run's prompt.
3. The UI actively fights this today. useAgentsViewController.ts:916-927 force-resets chat focus back to workspace whenever reviewFixerStatus becomes queued/running, precisely because the fixer has no runtime of its own to focus.

Why This Is Mostly Mechanical

The seam already exists and is proven by Workspace Review:

• create_workspace_review_conversation (agent_workspace_review.rs:1338) builds ChatConversation::new_project(project_id) with parent_conversation_id = workspace.conversation_id.
• canonical_parented_agent_binding (chat_service/mod.rs:820-833) then automatically persists bound_agent_name for any parented conversation launched with an agent_name_override. That is what makes follow-up user messages route to the reviewer instead of project chat — and it will do the same for the fixers with no new mechanism.
• agent_sidebar_commands.rs:337 already hides parented conversations that own no workspace, so new fixer children stay out of the sidebar for free.
• The frontend focus machinery (agentChatFocus.ts, panelStoreKeyOverride/panelSendConversationId in AgentsActiveConversationPanel.tsx:1564-1607, the header back-button at AgentsChatHeader.tsx:428-506, and the composer selector at AgentsActiveConversationPanel.tsx:1626-1674) is already generic over focus type.

The header "Back to Workspace Chat" button needs no change — showBackToWorkspaceChat already fires for any chatFocus.type !== "workspace".

Approach

Five phases, each independently shippable:

1. Durable identity — migration adding runtime_conversation_id to agent_workspace_repair_attempts; entity + SQLite + memory repo plumbing. Review's review_fixer_conversation_id already exists and only needs to start receiving a real child.
2. Child creation + dispatch rerouting — one shared agent_workspace_fixer_conversation helper; every dispatch site above switches conversation_id_override to the child. One child per durable attempt (AgentWorkspaceRepairAttempt generation / review_fixer_attempt_id), created at reservation, reused across redispatches within that attempt.
3. Authority follows the child (highest risk) — complete_agent_workspace_repair / complete_agent_workspace_pr_fix currently validate the model-supplied conversation id against the trusted header and then load the workspace and the repair attempt by that same id (repair_completion.rs:275-287, :338, :492). With a child runtime the header carries the child id, so the handlers must resolve child → owning workspace through the recorded attempt linkage, not through parent_conversation_id alone. Same for the "is a run active on this workspace" guards (pr_merge_poller.rs:4029-4040) and terminal cleanup.
4. Runtime status surface — add WorkspaceRepair and PrFixer to AgentConversationRuntimeSource (unified_chat_commands/mod.rs:10352) plus item builders, priority, summary labels, and index kinds, mirroring add_workspace_review_runtime_item (:10810).
5. Frontend focus slots — new workspace_repair / pr_fixer focus variants, auto-focus on start (replacing the force-reset effect), composer selector entries, and deletion of the launchRole-sniffing composer role block.

Decisions

Decision	Status	Value	Rationale
Scope	✅ Confirmed by user	All three families — workspace repair, PR autofix, and the review blocking fixer	Leaving any one behind would keep the launchRole-sniffing workaround alive in the composer.
Conversation lifetime	⚠️ Assumed — open	One child per durable attempt, not per dispatch	Matches Review's per-run isolation while using the unit the backend already fences on (AgentWorkspaceRepairAttempt.generation, review_fixer_attempt_id). Redispatch/redelivery inside one attempt reuses the child, so a retry streak does not spawn conversations; a new failure identity naturally starts a fresh one.

The lifetime question is still unanswered. The alternative — a single persistent child per fixer kind, appended across attempts — is a contained change to create_agent_workspace_fixer_conversation (look up an existing child before creating), so this does not block starting Phase 1. Say the word if you want persistent-per-kind instead.

A third choice is implicit: at most two new selector slots, because the review blocking fixer and workspace repair are the same agent (ralphx-agent-workspace-repair) and read as one "Fixer" concept to the user. They share the workspace_repair focus type with a deterministic precedence rule.

Affected Surfaces

Area	Paths
Migration	src-tauri/src/infrastructure/sqlite/migrations/vYYYYMMDDHHMMSS_agent_workspace_repair_runtime_conversation.rs (new)
Domain	src-tauri/crates/ralphx-domain/src/entities/agent_workspace_repair.rs
Persistence	src-tauri/src/infrastructure/{sqlite,memory}/*_agent_conversation_workspace_repo/repair_attempts.rs
Child creation	src-tauri/src/application/agent_workspace_fixer_conversation.rs (new)
Dispatch	src-tauri/src/application/services/pr_merge_poller.rs, agent_workspace_publish_recovery/durable_attempt_recovery.rs, agent_workspace_review.rs
Authority	src-tauri/src/http_server/handlers/agent_workspaces/repair_completion.rs, agent_workspace_terminal_cleanup.rs, commands/agent_workspace_auto_review.rs
Runtime status	src-tauri/src/commands/unified_chat_commands/mod.rs
Frontend focus	frontend/src/components/agents/agentChatFocus.ts, useAgentsViewController.ts, AgentsActiveConversationPanel.tsx, AgentsComposerWorkspaceChangesCard.tsx
API types	frontend/src/api/chat.ts

Risks

• Completion authority is the sharp edge. Getting child → workspace resolution wrong either breaks every repair completion (fails closed, loud) or lets an unrelated child settle another workspace's attempt (fails open, silent). The blueprint requires exact-linkage validation, never bare parent_conversation_id trust, plus a negative test.
• In-flight attempts across the upgrade. Existing unsettled attempts have runtime_conversation_id = NULL and their live agent is running in the parent conversation. The handlers must treat NULL as "legacy, parent-hosted" and keep working, rather than assuming a child exists.
• Guards that ask "is the workspace busy?" currently query only the parent conversation. Missing one lets a second fixer dispatch concurrently. agent_workspace_review.rs:2802-2831 already models the correct multi-conversation form and is the pattern to copy.

Next Action

Approve to lock the plan, tell me if the conversation-lifetime default is wrong, or run Verify Plan for an adversarial pass over the completion-authority and recovery paths.

---

Generated by RalphX

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[codecov]

Codecov Report

❌ Patch coverage is 86.25793% with 65 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../application/agent_workspace_fixer_conversation.rs	84.34%	18 Missing ⚠️
...rc/application/agent_workspace_terminal_cleanup.rs	75.40%	15 Missing ⚠️
...ent_conversation_workspace_repo/repair_attempts.rs	84.50%	11 Missing ⚠️
...rc-tauri/src/application/agent_workspace_review.rs	70.58%	10 Missing ⚠️
...ents/agents/AgentsComposerWorkspaceChangesCard.tsx	14.28%	6 Missing ⚠️
...pplication/agent_workspace_publish_repair_state.rs	95.23%	2 Missing ⚠️
...447_agent_workspace_repair_runtime_conversation.rs	86.66%	2 Missing ⚠️
...space_publish_recovery/durable_attempt_recovery.rs	95.65%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!