refactor(frontend): workspace shell unificado + Step2 modular + Zep UX layer

[Marcelo-Rosas]

Resumo

Refatoração estrutural do frontend MiroFish. Ataca três problemas de arquitetura identificados no codebase:

1. Shell duplicado — header, layout switcher, status indicator e painéis eram copy-paste em 5 views
2. Step2EnvSetup monolítico — 2600+ linhas de template + script + polling em um único componente
3. Zep/grafo invisível na UX — backend já usava Zep como peça central, mas nada disso aparecia para o usuário

---

Nova arquitetura do shell

<View>
  ├── useWorkspaceShell()          ← viewMode, systemLogs, addLog, toggleMaximize, panel styles
  ├── <WorkspaceHeader v-model>    ← header 56px: brand · switcher centrado · step counter · status pill
  └── <WorkspaceLayout :viewMode>  ← split panels com transição CSS
        ├── #graph → <GraphPanel :projectData>
        │              └── <GraphContextBar>  ← Zep: nodes/edges/entity types/estado
        └── #content → <StepComponent>
                         └── <SystemLogsPanel>  ← logs compactos/expansíveis

Views migradas: MainView · SimulationView · SimulationRunView · ReportView · InteractionView

---

Step2 modularizado

Step2EnvSetup.vue (2600+ linhas) → orquestrador puro + 6 componentes semânticos:

Componente	Papel
SimulationInstanceCard	Card 01 — criação de instância + IDs
AgentProfilesSection	Card 02 — personas, stats, grid, progress bar
SimConfigSection	Card 03 — time config, agent timeline, plataformas
OrchestrationSection	Card 04 — narrative direction, hot topics, initial posts
SetupReadinessSection	Card 05 — rounds config + launch (v-model com guards de sync/clamp)
ProfileDetailPanel	Modal de detalhe do agente

---

Graph/Zep visível na UX

GraphContextBar aparece acima do grafo D3 em todas as views:

• Badge ZEP + contagem de nodes e edges
• Entity types da ontologia como tags
• Estado da ingestão: Pending → Ontology set → Building → Graph ready → Memory active

GraphPanel agora aceita projectData — propagado e validado em todos os 5 call sites.

---

Logs + i18n

• SystemLogsPanel — compacto por padrão, expansível, coloração semântica (error/success/warn)
• Novas keys em en.json + zh.json: graph.ctxState* · system.label* · step2.showLess/showAll/profileModalProfession

---

Arquivos

Criados (11):
useWorkspaceShell.js · WorkspaceHeader.vue · WorkspaceLayout.vue · GraphContextBar.vue · SystemLogsPanel.vue · SimulationInstanceCard.vue · AgentProfilesSection.vue · SimConfigSection.vue · OrchestrationSection.vue · SetupReadinessSection.vue · ProfileDetailPanel.vue

Modificados (9):
GraphPanel.vue · Step2EnvSetup.vue · MainView.vue · SimulationView.vue · SimulationRunView.vue · ReportView.vue · InteractionView.vue · locales/en.json · locales/zh.json

---

Scope

This PR is intentionally scoped to frontend workspace refactor, step modularization, shared shell architecture, and i18n updates. Ongoing backend/service changes were excluded to keep review scope clean and atomic.

---

Follow-ups não bloqueantes

• Status labels legados ("Error", "Running", "Generating" etc.) — extrair para i18n em rodada futura
• useSimulationPreparation composable — extrair quando: polling > 3 loops, status espalhado entre watchers, reaproveitamento em outra view, ou orquestrador crescendo além de coordenação

🤖 Generated with Claude Code

[Marcelo-Rosas]

QA Checklist — Workspace Shell Refactor

Manual smoke test cobrindo o fluxo completo após merge.

Fluxo principal

• Home → Process: navegação cria projeto, projectData disponível após retorno
• Process (Step 2): cards 01–05 renderizam na sequência correta
  • Card 01 exibe project_id, graph_id, simulation_id após criação
  • Card 02 exibe perfis com progresso e toggle Show All / Show Less funcional
  • Card 03 exibe configs de plataforma e timeline 24h por agente
  • Card 04 exibe narrative e posts sem overflow
  • Card 05 — rounds config: switch auto/custom sincroniza com pai sem loop
  • Card 05 — campo numérico clipa em autoGeneratedRounds quando switch muda para custom
• Process → Simulation: transição de rota limpa, sem erro de console
• Simulation → Run: timer de simulação inicia, GraphPanel recebe projectData
• Run → Report: carregamento encadeado (report → sim → project → graph) sem tela em branco
• Report → Interaction: InteractionView carrega, status inicial cinza (idle), sem pulse indevido

WorkspaceHeader

• Layout switcher (split / workbench / focus) altera painéis em todas as 5 views
• Step counter exibe número correto por view (1 em MainView, 2 em SimulationView, etc.)
• Status pill varia corretamente: cinza → laranja pulsante → verde → vermelho em erro
• LanguageSwitcher no slot #right funcional sem sobreposição

GraphPanel + GraphContextBar

• GraphContextBar visível acima do grafo D3 em todas as views que têm GraphPanel
• Node count e edge count exibem valor real (não —) após grafo carregado
• Entity types da ontologia aparecem como tags; overflow +N correto acima de 5 tipos
• Estado dot anima (laranja pulsante) durante currentPhase === 1 (building)
• Estado dot verde estático após currentPhase >= 2
• shortGraphId trunca IDs longos com … no meio

SystemLogsPanel

• Painel inicia colapsado por padrão
• Clique no header expande/colapsa com animação slide
• Novo log faz scroll automático para o final quando expandido
• Coloração semântica: error → vermelho, success → verde, warning → laranja
• Mensagem "No logs yet" aparece quando lista vazia e painel expandido

i18n

• Troca EN → ZH sem keys ausentes visíveis (nenhum fallback [key] na tela)
• Troca ZH → EN idem
• Keys novas (step2.showLess, step2.showAll, system.noLogs, graph.ctxTypes, etc.) traduzidas em ambos os idiomas

Regressão

• npm run build sem erros de TypeScript/Vite
• Sem console.error no fluxo feliz (DevTools limpo)
• Sem memory leaks óbvios: navegar entre views múltiplas vezes, verificar que os clearInterval disparam no onUnmounted

---

Follow-ups não bloqueantes (fora deste PR)

1. Status labels legados → i18n — strings hardcoded ("Running", "Error", "Generating", "Ready") nos scripts das views. Extrair em limpeza futura.
2. useSimulationPreparation composable — extrair os 3 polling loops do Step2EnvSetup quando qualquer um destes gatilhos for atingido:
   • mais de 3 loops/timers ativos no preparo
   • lógica de status espalhada entre watchers e handlers
   • necessidade de reutilizar parte do fluxo em outra view
   • orquestrador crescendo além do papel de coordenação