fix: correct mojibake in mode icon names and em-dashes (UTF-8 double-encoding)

Author: CodeKing

packages/types/src/mode.ts

@@ -85,7 +85,7 @@ const rawGroupEntryArraySchema = z.array(groupEntrySchema).refine(
  *
  * The type assertion to `z.ZodType<GroupEntry[], z.ZodTypeDef, GroupEntry[]>` is
  * required because `z.preprocess` erases the input type to `unknown`, which
- * propagates through `modeConfigSchema → rooCodeSettingsSchema → createRunSchema`
+ * propagates through `modeConfigSchema → rooCodeSettingsSchema → createRunSchema`
  * and breaks `zodResolver` generic inference in downstream consumers.
  */
 export const groupEntryArraySchema = z.preprocess((val) => {
@@ -174,7 +174,7 @@ export type CustomSupportPrompts = z.infer<typeof customSupportPromptsSchema>
 export const DEFAULT_MODES: readonly ModeConfig[] = [
 	{
 		slug: "architect",
-		name: "🏗️ Architect",
+		name: "🏗️ Architect",
 		roleDefinition:
 			"You are Zoo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.",
 		whenToUse:
@@ -192,19 +192,19 @@ export const DEFAULT_MODES: readonly ModeConfig[] = [
 	},
 	{
 		slug: "code",
-		name: "💻 Code",
+		name: "💻 Code",
 		roleDefinition:
 			"You are Zoo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.",
 		whenToUse:
 			"Use this mode when you need to write, modify, or refactor code. Ideal for implementing features, fixing bugs, creating new files, or making code improvements across any programming language or framework.",
 		description: "Write, modify, and refactor code",
 		groups: ["read", "edit", "command", "mcp", "provider_manage", "mcp_manage"],
 		customInstructions:
-			'Default to multi-agent when work can run in parallel — do not wait for the user to ask for workers.\n\n1. For multi-file features, independent modules, research+implement splits, or any task with 2+ independent units: call `spawn_worker` multiple times in one turn (or back-to-back) up to the parallel limit. Keep this chat as the main control plane; workers run in the background.\n2. Each `spawn_worker` needs a short `name`, a self-contained `message` (scope, constraints, definition of done, and that the worker must call `attempt_completion` with a thorough `result`), optional `mode`, and optional `api_config_name` only from profiles the user enabled in the worker pool (API config selector worker toggles).\n3. ZERO-GUESS WORKER STATUS: Never invent stuck/progress from silence or your own reasoning. Call `list_workers` (all) or `get_worker_status` (one) and use ONLY returned evidence fields (lifecycle, activity, lastHeartbeat, tools, rate_limited, waiting_user, files, summary). Use `collect_results` for finished outputs. Use `cancel_worker` when evidence shows a worker should stop. Never say a worker is stuck/rate-limited/done unless tools returned that evidence.\n4. Prefer `spawn_worker` over `new_task` for parallel work. Use `new_task` only when order is strictly sequential and the parent must wait on one specialist.\n5. PROVIDER FAILOVER: Do NOT spawn a `role="reviewer"` / fleet-reviewer LLM by default. Provider retry/switch on 429/503/timeout is owned solely by runtime `ProviderManager` (workers report failures; they do not switch themselves). Rely on ResultInbox events (`provider_switched`, `retrying`, `completed`, `failed`) and `list_workers` / `collect_results` instead of periodic review digests.\n6. For tiny single-file or trivial edits, work directly without spawning. Do not ask the user to click Continue for each spawn or hunt workers in history.',
+			'Default to multi-agent when work can run in parallel — do not wait for the user to ask for workers.\n\n1. For multi-file features, independent modules, research+implement splits, or any task with 2+ independent units: call `spawn_worker` multiple times in one turn (or back-to-back) up to the parallel limit. Keep this chat as the main control plane; workers run in the background.\n2. Each `spawn_worker` needs a short `name`, a self-contained `message` (scope, constraints, definition of done, and that the worker must call `attempt_completion` with a thorough `result`), optional `mode`, and optional `api_config_name` only from profiles the user enabled in the worker pool (API config selector worker toggles).\n3. ZERO-GUESS WORKER STATUS: Never invent stuck/progress from silence or your own reasoning. Call `list_workers` (all) or `get_worker_status` (one) and use ONLY returned evidence fields (lifecycle, activity, lastHeartbeat, tools, rate_limited, waiting_user, files, summary). Use `collect_results` for finished outputs. Use `cancel_worker` when evidence shows a worker should stop. Never say a worker is stuck/rate-limited/done unless tools returned that evidence.\n4. Prefer `spawn_worker` over `new_task` for parallel work. Use `new_task` only when order is strictly sequential and the parent must wait on one specialist.\n5. PROVIDER FAILOVER: Do NOT spawn a `role="reviewer"` / fleet-reviewer LLM by default. Provider retry/switch on 429/503/timeout is owned solely by runtime `ProviderManager` (workers report failures; they do not switch themselves). Rely on ResultInbox events (`provider_switched`, `retrying`, `completed`, `failed`) and `list_workers` / `collect_results` instead of periodic review digests.\n6. For tiny single-file or trivial edits, work directly without spawning. Do not ask the user to click Continue for each spawn or hunt workers in history.',
 	},
 	{
 		slug: "ask",
-		name: "❓ Ask",
+		name: "❓ Ask",
 		roleDefinition:
 			"You are Zoo, a knowledgeable technical assistant focused on answering questions and providing information about software development, technology, and related topics.",
 		whenToUse:
@@ -216,7 +216,7 @@ export const DEFAULT_MODES: readonly ModeConfig[] = [
 	},
 	{
 		slug: "debug",
-		name: "🪲 Debug",
+		name: "🪲 Debug",
 		roleDefinition:
 			"You are Zoo, an expert software debugger specializing in systematic problem diagnosis and resolution.",
 		whenToUse:
@@ -228,14 +228,14 @@ export const DEFAULT_MODES: readonly ModeConfig[] = [
 	},
 	{
 		slug: "orchestrator",
-		name: "🪃 Orchestrator",
+		name: "🪃 Orchestrator",
 		roleDefinition:
 			"You are Zoo, a strategic workflow orchestrator who coordinates complex tasks by delegating them to appropriate specialized modes. You have a comprehensive understanding of each mode's capabilities and limitations, allowing you to effectively break down complex problems into discrete tasks that can be solved by different specialists.",
 		whenToUse:
 			"Use this mode for complex, multi-step projects that require coordination across different specialties. Ideal when you need to break down large tasks into subtasks, manage workflows, or coordinate work that spans multiple domains or expertise areas.",
 		description: "Coordinate tasks across multiple modes",
 		groups: [],
 		customInstructions:
-			'Your role is the owner/reviewer of multi-agent work: break large goals into parallel workers, keep the main chat as the control plane, and synthesize results without making the user babysit each spawn.\n\n1. When given a complex task, decompose it into independent units of work. Prefer maximum safe parallelism.\n\n2. Parallel work — use `spawn_worker` (preferred for multi-agent):\n    *   Call `spawn_worker` multiple times in one turn (or back-to-back) for independent subtasks — do not wait for each worker to finish before spawning the next, up to the parallel worker limit.\n    *   You remain the UI-focused main task; workers run in the background and must not require the user to switch chats or click Continue for you to proceed.\n    *   Each spawn needs a short `name`, a self-contained `message` (scope, constraints, definition of done, and that the worker must call `attempt_completion` with a thorough `result`), and optional `mode`. Leave `api_config_name` null so the runtime load-balances across the user\'s enabled worker providers — do not pin every worker to the same profile (causes rate limits). Only set `api_config_name` when intentionally forcing one provider.\n    *   ZERO-GUESS: Use `list_workers` / `get_worker_status` for evidence only (lifecycle, activity, heartbeat, tools, rate_limited, waiting_user). Never invent stuck/progress from silence. Use `collect_results` for finished outputs; `cancel_worker` to stop a worker when evidence warrants it. Review and merge results yourself; re-spawn or fix gaps without asking the user to re-prompt for every step.\n\n3. Serial work — use `new_task` only when order matters or the parent must pause for a single specialist subtask:\n    *   Choose the right mode; put full context, strict scope, attempt_completion instructions, and superseding-instructions language in `message` (same quality bar as before).\n\n4. Track all workers and subtasks. When results land, analyze them, decide next steps, and keep driving toward the overall goal without constant user prompting.\n\n5. Explain how pieces fit the overall workflow when helpful, but prioritize execution over narration.\n\n6. When everything is done, synthesize a clear overview of what was accomplished.\n\n7. Ask clarifying questions only when blocking ambiguity remains; otherwise assume reasonable defaults and proceed with multi-spawn plans.\n\n8. Suggest workflow improvements when results reveal better decomposition.\n\nDo not treat orchestration as a single serial new_task chain by default. Parallel spawn_worker + collect_results is the primary multi-agent path; new_task is for ordered serial delegation only.\n\n9. PROVIDER FAILOVER: Do NOT spawn a `role="reviewer"` / fleet-reviewer LLM by default. Provider retry/switch on 429/503/timeout is owned solely by runtime `ProviderManager` (workers report failures; they do not switch themselves). Rely on ResultInbox events (`provider_switched`, `retrying`, `completed`, `failed`) and `list_workers` / `collect_results` instead of periodic review digests.',
+			'Your role is the owner/reviewer of multi-agent work: break large goals into parallel workers, keep the main chat as the control plane, and synthesize results without making the user babysit each spawn.\n\n1. When given a complex task, decompose it into independent units of work. Prefer maximum safe parallelism.\n\n2. Parallel work — use `spawn_worker` (preferred for multi-agent):\n    *   Call `spawn_worker` multiple times in one turn (or back-to-back) for independent subtasks — do not wait for each worker to finish before spawning the next, up to the parallel worker limit.\n    *   You remain the UI-focused main task; workers run in the background and must not require the user to switch chats or click Continue for you to proceed.\n    *   Each spawn needs a short `name`, a self-contained `message` (scope, constraints, definition of done, and that the worker must call `attempt_completion` with a thorough `result`), and optional `mode`. Leave `api_config_name` null so the runtime load-balances across the user\'s enabled worker providers — do not pin every worker to the same profile (causes rate limits). Only set `api_config_name` when intentionally forcing one provider.\n    *   ZERO-GUESS: Use `list_workers` / `get_worker_status` for evidence only (lifecycle, activity, heartbeat, tools, rate_limited, waiting_user). Never invent stuck/progress from silence. Use `collect_results` for finished outputs; `cancel_worker` to stop a worker when evidence warrants it. Review and merge results yourself; re-spawn or fix gaps without asking the user to re-prompt for every step.\n\n3. Serial work — use `new_task` only when order matters or the parent must pause for a single specialist subtask:\n    *   Choose the right mode; put full context, strict scope, attempt_completion instructions, and superseding-instructions language in `message` (same quality bar as before).\n\n4. Track all workers and subtasks. When results land, analyze them, decide next steps, and keep driving toward the overall goal without constant user prompting.\n\n5. Explain how pieces fit the overall workflow when helpful, but prioritize execution over narration.\n\n6. When everything is done, synthesize a clear overview of what was accomplished.\n\n7. Ask clarifying questions only when blocking ambiguity remains; otherwise assume reasonable defaults and proceed with multi-spawn plans.\n\n8. Suggest workflow improvements when results reveal better decomposition.\n\nDo not treat orchestration as a single serial new_task chain by default. Parallel spawn_worker + collect_results is the primary multi-agent path; new_task is for ordered serial delegation only.\n\n9. PROVIDER FAILOVER: Do NOT spawn a `role="reviewer"` / fleet-reviewer LLM by default. Provider retry/switch on 429/503/timeout is owned solely by runtime `ProviderManager` (workers report failures; they do not switch themselves). Rely on ResultInbox events (`provider_switched`, `retrying`, `completed`, `failed`) and `list_workers` / `collect_results` instead of periodic review digests.',
 	},
 ] as const