QA de desktop Slack do Mantis é a lane de interface real para bugs da classe Slack que precisam de um desktop Linux, resgate por VNC, Slack Web, um Gateway OpenClaw real, capturas de tela, vídeos e um comentário de evidência no PR. Use-a quando testes unitários ou a lane live sem interface do Slack não conseguirem comprovar o bug.Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Modelo de armazenamento
O Mantis usa três camadas de armazenamento diferentes:- Imagem do provedor: de propriedade do Crabbox e armazenada na conta do provedor de nuvem. Ela contém capacidades da máquina, como Chrome/Chromium, ffmpeg, scrot, Node/corepack/pnpm, ferramentas nativas de build e diretórios de cache vazios.
- Estado de lease aquecido: de propriedade da sessão atual do operador. Ele pode conter um
perfil de navegador autenticado,
/var/cache/crabbox/pnpme um checkout de origem preparado enquanto o lease estiver ativo. - Artefatos do Mantis: de propriedade da execução do OpenClaw. Eles ficam em
.artifacts/qa-e2e/mantis/..., depois o GitHub Actions faz upload deles e o GitHub App do Mantis comenta evidências inline no PR.
node_modules ou dist/ em uma imagem de provedor pré-preparada.
Dispatch do GitHub
Execute o workflow a partir demain:
candidate_ref são intencionalmente restritos porque o workflow
usa credenciais live: ancestralidade atual de main, tags de release ou o head de um PR aberto
de openclaw/openclaw.
O workflow grava:
- artefato enviado:
mantis-slack-desktop-smoke-<run-id>-<attempt>; - comentário inline no PR pelo GitHub App do Mantis;
slack-desktop-smoke.png;slack-desktop-smoke.mp4;slack-desktop-smoke-preview.gif;slack-desktop-smoke-change.mp4;mantis-slack-desktop-smoke-summary.json;mantis-slack-desktop-smoke-report.md;- logs remotos como
slack-desktop-command.log,openclaw-gateway.log,chrome.logeffmpeg.log.
<!-- mantis-slack-desktop-smoke -->.
CLI local
Prova fria a partir da origem:--hydrate-mode prehydrated somente quando o workspace remoto reutilizado já
tiver node_modules e um dist/ criado. O Mantis falha fechado se eles estiverem
ausentes.
Modos de hidratação
| Modo | Use quando | Comportamento remoto | Tradeoff |
|---|---|---|---|
source | Prova normal de PR, máquinas frias, CI | Executa pnpm install --frozen-lockfile --prefer-offline e pnpm build dentro da VM | Mais lento, prova mais forte de checkout de origem |
prehydrated | Você preparou intencionalmente um lease reutilizado | Exige node_modules e dist/ existentes; pula install/build | Rápido, mas válido apenas para leases aquecidos controlados pelo operador |
/var/cache/crabbox/pnpm quando presente.
Interpretação de tempo
mantis-slack-desktop-smoke-report.md inclui tempos por fase:
crabbox.warmup: boot do provedor de nuvem, prontidão do desktop/navegador e SSH.crabbox.inspect: consulta de metadados do lease.credentials.prepare: aquisição de lease de credenciais do Convex.crabbox.remote_run: sync, inicialização do navegador, instalação/build do OpenClaw ou validação de hidratação, inicialização do Gateway, captura de tela e captura de vídeo.artifacts.copy: rsync de volta a partir da VM.
crabbox.remote_run pode ser marcado como accepted quando o Crabbox retorna um status
remoto diferente de zero depois que o Mantis copiou metadados comprovando que o Gateway OpenClaw
está ativo e que a configuração foi concluída. Trate accepted como aprovação com explicação,
não como um cenário com falha.
Se a execução estiver lenta:
- warmup domina: pré-prepare ou promova uma imagem de provedor Crabbox melhor;
- remote_run domina em
source: use um lease aquecido, melhore a reutilização do store do pnpm ou mova pré-requisitos da máquina para a imagem do provedor; - remote_run domina em
prehydrated: o workspace remoto não estava realmente pronto, ou a configuração do Gateway/navegador/Slack está lenta; - cópia de artefatos domina: inspecione o tamanho do vídeo e o conteúdo do diretório de artefatos.
Checklist de evidências
Um bom comentário de PR deve mostrar:- id do cenário e SHA candidato;
- URL da execução do GitHub Actions;
- URL do artefato;
- captura de tela inline;
- prévia animada inline quando disponível;
- links para o MP4 completo e o MP4 recortado;
- status de aprovação/falha;
- resumo de tempos no relatório anexado.
Tratamento de falhas
Se o workflow falhar antes da execução na VM, inspecione primeiro o job do Actions. Causas típicas sãocandidate_ref não confiável, segredos de ambiente ausentes ou falha de
install/build do candidato.
Se a execução na VM falhar, mas as capturas de tela tiverem sido copiadas de volta, inspecione:
crabbox vnc ... do relatório.
Pare o lease quando terminar:
--lease-id. Não incorpore esse perfil de navegador em uma imagem de provedor.