Jet Browser

Visão Geral

Use o Jet Browser como um limite de runtime de navegador substituível para um agente ou executor de testes determinístico. Ele executa uma sessão isolada do WPE WebKit por contêiner e expõe comandos JSONL ordenados para navegação, entrada nativa, inspeção semântica, capturas de tela e limpeza.

Mantenha a seleção de modelos, raciocínio, credenciais e orquestração no projeto chamador. O Jet Browser é um runtime de navegador, não um framework de agente, rede de proxy hospedada, serviço anti-bot ou ponte para o perfil pessoal do Chrome de um usuário.

Quando Usar Esta Habilidade

• Use quando um projeto precisar de um processo de navegador auto-hospedado com um ciclo de vida explícito de contêiner.
• Use quando um harness precisar de JSONL ordenado e neutro em relação ao framework em vez de um loop de agente empacotado.
• Use quando ponteiro nativo, teclado, toque, DOM e evidências de captura de tela devem compartilhar um único runtime.
• Use quando um repositório precisar de um teste de fumaça offline reproduzível ou uma verificação de runtime de navegador no GitHub Actions.
• Não use esta habilidade para controlar um Chrome pessoal já em execução ou reutilizar seu estado de login; use o fluxo de trabalho CDP aprovado pelas permissões do ambiente para isso.

Configuração Segura e Verificação

1. Estabeleça o limite antes de baixar

Confirme que o usuário deseja um contêiner Jet Browser separado em vez de seu navegador diário. Verifique se há Docker e Node.js 24+, e relate um requisito ausente em vez de afirmar que o runtime foi verificado.

Para um novo checkout ou atualização, identifique uma versão imutável ou commit completo, inspecione o package.json do repositório, scripts de ciclo de vida, lockfile, Dockerfiles, arquivos executáveis, links simbólicos, acesso à rede e manipulação de credenciais, e resuma o que será executado. Obtenha aprovação explícita antes de baixar e novamente antes de instalar dependências, construir imagens ou iniciar contêineres. Um pin de commit Git fornece reprodutibilidade, não prova de confiança.

O commit de origem v0.9.0 revisado para esta entrada de catálogo é:

b0867303260212eaeb427970b9a7fc6f8eed2fe1

Revise uma árvore de origem mais recente independentemente antes de alterar esse pin.

2. Execute o fluxo de aceitação autônomo

Após as aprovações acima, instale as dependências exatas do lockfile da origem fixada e execute sua verificação autônoma:

npm ci
npm run standalone

Trate o resultado JSON observado do comando como a verificação de aceitação. Uma execução bem-sucedida deve iniciar a página local, verificar o marcador JavaScript, digitar através do caminho de entrada nativa, capturar um PNG, manter a rede de saída do navegador de fumaça desativada e desligar o contêiner de forma limpa.

Para alterações de origem, também execute:

npm test
cargo test --all-targets

Nunca relate uma passagem quando Docker, Node.js, a construção da imagem, a inicialização do navegador, a entrada nativa, a verificação do DOM, a captura de tela ou a limpeza não foram realmente concluídas.

3. Integre o contrato documentado

Leia docs/demo.md para o ciclo de vida do contêiner e docs/agent-tools.md para declarações voltadas para o modelo. Prefira as declarações versionadas exportadas por sdk/tools.mjs; não invente nomes de ferramentas, campos de entrada ou formatos de resposta.

Envie um comando JSON por linha e consuma uma resposta JSON por linha. Preserve a ordenação, vincule entradas e saídas no harness chamador e feche a sessão em uma limpeza garantida. Mantenha um contêiner por sessão mutuamente não confiável, monte caminhos de perfil ou download explicitamente e nunca passe credenciais de host não relacionadas para dentro do contêiner.

Use evidências semânticas para seleção de destino e capturas de tela para verificação visual quando ambos estiverem disponíveis. Trate avaliação, perfis importados, downloads e acesso à rede de saída como capacidades privilegiadas que exigem que o aplicativo chamador defina seus próprios portões de autorização e política.

Exemplos

Exemplo 1: Verificar um checkout de origem fixado

Após inspecionar a origem fixada e receber as aprovações necessárias:

git clone --filter=blob:none --no-checkout https://github.com/masakaai/jet-browser.git
git -C jet-browser checkout --detach b0867303260212eaeb427970b9a7fc6f8eed2fe1
cd jet-browser
npm ci
npm run standalone

Relate o resultado exato do comando e quais asserções de aceitação foram executadas. Não traduza um log parcial de compilação ou inicialização em uma verificação bem-sucedida.

Exemplo 2: Verificar o Jet Browser no GitHub Actions

Fixe a Ação no commit completo revisado em vez de um branch ou tag em movimento:

permissions:
  contents: read

jobs:
  verify-browser-runtime:
    runs-on: ubuntu-latest
    steps:
      - name: Verify Jet Browser

…