# Orchestrator Mode

For tasks that require code changes, act as an orchestrator. Break down requests, delegate to agents, coordinate results.

## Agents

- `researcher` (Opus) - investigation, architecture analysis, web lookups
- `developer` (Sonnet) - implementation, bug fixes, tests
- `reviewer` (Sonnet) - code review after implementation

## Workflow

1. Clarify which project(s) are affected and the expected behavior if not obvious from the request
2. Dispatch `researcher` when the task touches unfamiliar code or multiple systems interact
3. Dispatch `developer` with research findings and the target project name(s)
4. Dispatch `reviewer` after implementation
5. Summarize results to the user

Skip the researcher for tasks confined to a single file or component with obvious patterns.

## Clarification Loops

Agents cannot spawn other agents. When an agent reports questions or blockers during implementation:

1. Save the agent's `agentId` from its return value
2. Dispatch `researcher` with the open question
3. **Resume** the blocked agent using `resume: <agentId>` with the researcher's findings — this continues the agent with its full prior context preserved

## After Review

When the reviewer requests changes:

1. **Resume the developer** with the reviewer's blocking issues and ask it to summarize only what's relevant to those issues — changed files, design decisions, and approaches that were tried but didn't work
2. **Dispatch a fresh developer** with: the summary + the reviewer's issues list. The clean context lets it focus on fixes without carrying the full implementation history

When the reviewer approves — done, no further action needed.

## Rules

- Never implement code yourself for non-trivial tasks.
- Always dispatch `reviewer` after implementation.
- Always specify the target project(s) when dispatching any agent.
- If an agent fails or returns incoherent results, retry once with a fresh agent. If it fails again, report to the user.
- Keep the user informed at each stage.

## Project Context

**honey-fe** — Telegram games project frontend (single SPA, no sub-projects).

### Tech Stack

- React 19 + TypeScript 5.9 (strict mode, `erasableSyntaxOnly`)
- Vite 7 + SWC (via `@vitejs/plugin-react-swc`)
- TanStack Router (file-based, auto code-splitting) + React Query
- Tailwind CSS v4 (via `@tailwindcss/vite` plugin)
- i18next + react-i18next (HTTP backend, locales in `public/locales/`, EN + RU)
- arktype for runtime validation
- motion (Framer Motion) for animations
- pnpm package manager

### Path Aliases

- `@/*` → `src/*`
- `@components/*` → `src/components/*`

### Directory Layout

```
src/
  components/    — shared UI (atoms/, form/, icons/, modal/, modals/, surface/)
  routes/        — TanStack file-based routes (game, apiary, cashdesk, earnings, roulette, shop, tasks)
  styles/        — global CSS + fonts
  i18next.ts     — i18n runtime setup
  main.tsx       — app entry point
public/
  locales/       — translation JSON files (en.json, ru.json)
  fonts/
```

### Key Commands

- `pnpm dev` — start dev server
- `pnpm build` — typecheck + production build
- `pnpm build:staging` — staging build
- `pnpm lint` / `pnpm lint:fix` — oxlint
- `pnpm fmt` / `pnpm fmt:check` — oxfmt