Conecte seu código: altere, verifique, aprove, publique e reverta um código real

Dê um nome ao projeto e cole o endereço do repositório (do botão verde Code do GitHub) e o branch de onde o site é executado, geralmente main. Escolha como o aiKit acessa o repositório. Token do GitHub: um token de granularidade fina que você cria no GitHub apenas para este repositório, com Contents definido como Read and write; ele vai com um endereço https://. Deploy key: um par de chaves criado somente para este repositório, cuja parte pública você adiciona em Settings, Deploy keys do repositório, com Allow write access marcado; ela vai com um endereço git@. Repositório público: somente leitura, então alterações aprovadas não têm onde ser salvas; use apenas para explorar.

Você cola o token ou a chave por conta própria. Ele é armazenado criptografado no motor do aiKit e nunca é mostrado novamente, para ninguém. A página mostra apenas uma impressão digital. Ao conectar o repositório, o código é copiado para o motor e o sistema identifica que tipo de projeto é (Laravel, JavaScript ou arquivos estáticos). Nada no repositório é alterado.

Um projeto que você já tem também pode ser conectado: na aba Hospedagem dele, o proprietário verá Conecte seu código.

Seu próprio servidor: o site continua exatamente onde está. Informe o endereço do servidor, a porta SSH (geralmente 22), o login que o aiKit usa (os passos de configuração criam um chamado aikit), a pasta do site (para um site do Laravel Forge, /home/forge/seu-site.com), o comando de publicação que o site já usa (geralmente bash scripts/deploy.sh) e as páginas que devem responder após cada publicação, um endereço completo por linha. Cole a chave privada do login do servidor (criada no passo 1 da configuração). Salve e verifique a conexão.

Na primeira vez que o aiKit acessa o servidor, ele mostra a impressão digital do servidor e pergunta: Este é o seu servidor? Compare com o que o servidor exibiu no passo 6 da configuração. Só pressione Confere apenas quando forem idênticas, depois conecte. A partir de então, outro servidor nesse endereço será recusado. Quando a verificação passa, a página informa qual versão o servidor está executando agora.

Hospedagem do aiKit: o aiKit compila e serve o código por conta própria, com um endereço gratuito para começar. Ideal para sites e front ends.

Em Configuração do servidor, a página lista oito passos para copiar e colar, já preenchidos com seus valores; cada um tem um botão Copiar. Os passos 1 e 8 são executados no seu computador; os passos 2 a 7, no servidor, como um usuário com sudo.

O que eles criam: um login sem senha e sem shell (passo 2). Sua única chave fica presa a um pequeno script de controle (passos 3 e 5), que aceita exatamente dois comandos: status (qual versão está rodando e se o site está em modo de manutenção) e deploy de um commit exato. O deploy roda como o usuário próprio do site, por meio de uma única regra do sudo, verifica se o branch no GitHub aponta para aquele commit exato e então executa seu script de publicação atual, sem alterações. O passo 4 define as permissões da pasta para que o login acesse apenas a pasta do site: nem os outros sites na mesma pasta pessoal, nunca o .env. O passo 7 testa tudo e diz o que você deve ver em cada linha, e o passo 8 testa o login a partir do seu computador antes de você colar a chave no aiKit.

Se um servidor hospeda outros negócios também, este é o ponto: o login do aiKit pode publicar apenas este site e mais nada. O código do site continua rodando como o usuário do site, exatamente como quando você publica diretamente pelo GitHub, por isso cada alteração é revisada e os arquivos sensíveis ficam protegidos.

Quatro blocos no topo. Repositório: o repositório, o branch, o commit mais recente e o tipo de projeto. Executa em: seu próprio servidor (com o login e a última vez em que respondeu) ou hospedagem do aiKit. Versão ao vivo: a versão que o site executa, quem a criou e quando. Páginas: quantas das páginas que devem responder responderam na última verificação; Verificar agora as visita novamente, e qualquer página que não respondeu aparece listada abaixo, com o que retornou.

Abaixo dos blocos: Solicitar uma alteração (ou a alteração aberta no momento), Versões, Histórico de alterações, Arquivos protegidos e, para o proprietário, Conexão.

Digite o que deve mudar, indicando a página e o que você quer ver, e pressione Fazer a alteração. O cartão vira Alteração nº 1 com progresso ao vivo: obtenção do código mais recente, os arquivos que a IA lê e edita, depois cada verificação. A IA apenas edita arquivos; ela não executa comandos. Uma alteração fica aberta por vez em cada projeto, e cada solicitação conta para o limite de IA do projeto.

Quando terminar, você verá: a solicitação e quem a fez; o que a IA diz que fez; as verificações, cada uma com um visto ou um x e sua saída; botões Prévia para as páginas verificadas; os arquivos com Adicionado, Alterado ou Removido e um selo Protegido quando aplicável; e as diferenças, arquivo por arquivo, em verde para linhas adicionadas e vermelho para linhas removidas. Essa diferença é exatamente o que será enviado e publicado.

Aprovar e publicar (proprietários e construtores) envia a alteração para o branch com uma mensagem que informa quem pediu e quem aprovou, faz o push (nunca forçado: se alguém tiver enviado algo nesse meio tempo, a alteração é marcada como Desatualizada e nada é publicado), publica e verifica as páginas. Descartar apaga a alteração depois de uma confirmação; nada foi publicado. Revisores podem ver tudo, mas não podem pressionar nenhum dos dois botões.

Depois que as verificações passarem é uma configuração em Conexão, Verificações e revisão. Aguardar aprovação é o padrão. Publicar automaticamente publica uma alteração sozinha somente quando todas as verificações passaram e nenhum arquivo protegido foi modificado; qualquer outro caso continua aguardando.

Para um projeto Laravel, as verificações são: cada arquivo PHP alterado é analisado (php -l); cada view Blade é compilada (php artisan view:cache); o front end é construído (npm run build); e o app é iniciado em um teste com um banco SQLite descartável, migrado e preenchido a partir do repositório, em que cada página listada em Páginas que o teste deve abrir precisa responder 200. Elas rodam no motor do aiKit, nunca no seu servidor e nunca no seu banco de dados ativo. O arquivo .env do projeto nunca é copiado nem lido; o teste usa configurações descartáveis.

Uma verificação com falha bloqueia Aprovar. Somente o proprietário pode marcar Publicar mesmo com falhas nas verificações, para uma verificação que falhou por um motivo que não afeta o site no ar.

A pré-visualização abre o app alterado do teste em uma nova aba, com dados de teste e formulários desligados. Ela para 15 minutos após o último uso e termina quando a alteração é aprovada ou descartada.

A IA não mexe em arquivos protegidos. A lista começa com: migrações que já foram executadas no site ativo (cada migração da versão ativa, pois cada publicação as executa), novas migrações (elas alterariam o banco ativo na próxima publicação), o script de publicação e os arquivos de dependências (composer.json, composer.lock, package.json, package-lock.json). Cada item informa o motivo. O proprietário adiciona um arquivo ou pasta (config/** significa tudo dentro de config) com um motivo, remove itens e pressiona Salvar arquivos protegidos.

Para alterar um arquivo protegido de propósito, o proprietário marca Permitir arquivos protegidos para esta solicitação. A alteração então mostra quais arquivos protegidos ela tocou, e somente o proprietário pode aprová-la, depois de marcar Sim, publicar as alterações em arquivos protegidos. Um construtor que não marca nada não tem acesso a arquivos protegidos.

Arquivos .env, chaves privadas e auth.json estão em um nível mais restrito: nunca são lidos, nunca são alterados, nunca fazem parte de um diff, e ninguém pode desativar isso.

Na primeira vez que o aiKit se conecta ao seu servidor, ele registra o que o servidor executa como versão 1, Antes do aiKit, para que até a primeira publicação do aiKit possa ser revertida. Depois disso, cada publicação é uma versão numerada: Alteração (uma alteração aprovada; o nome abre essa alteração), Republicar ou Reversão, com seu commit, quem fez, seu status (No ar, Anterior, No ar, mas páginas com falha, Falha na publicação), quantas páginas responderam e o registro da publicação. O aiKit guarda as últimas 5.

Publicar o código mais recente publica o que estiver mais novo no branch neste momento, após uma confirmação, por exemplo quando alguém enviou uma correção diretamente.

Reverter para esta, em uma versão anterior, cria um novo commit cujos arquivos são exatamente os dessa versão, envia o commit e o publica da forma normal, depois verifica as páginas. O histórico nunca é reescrito, então a própria reversão também pode ser revertida.

Cada solicitação com seu número, o pedido, quem pediu, quem aprovou ou descartou, quando, e em que situação está. Pressione uma linha para abrir essa alteração com suas verificações e diff; o endereço recebe ?change=<id>, para que você possa compartilhar o link com sua equipe.