Uma IA executando na sua máquina valida o checkout com workspace validate, sem pacote de entrega. Uma IA na web que precisa enviar mudanças a outro checkout usa um produtor com Git e POLIS para criar e transferir um arquivo .polis.
A diferença depende de onde estão o código e a validação, não apenas da interface do chat. Em ambos os caminhos há contrato, prova exigida e gates.
O agente tem acesso ao repositório e executa a CLI no mesmo checkout que está editando. Após bloquear o contrato, produzir a prova necessária e implementar, valide a alteração localmente.
polis workspace validateSem arquivo de entrega .polis. Um relatório de checkpoint externo é opcional e não é um pacote.
Se a mudança precisa chegar a outro checkout, um produtor com acesso real ao código, ao Git e à CLI executa o POLIS. Uma conversa sem essas ferramentas não cria nem verifica pacotes.
polis build → verify → preflight → applyCom arquivo de entrega .polis, criado fora do repositório. O consumidor verifica e só aplica após autorização.
Arquivo .polis ≠ diretório .polis/ mudanca.polis é um pacote transportável gerado por polis build. Já .polis/ é um diretório de configuração do projeto: pode conter .polis/policy.json, .polis/policy-provenance.json e evidências em .polis/artifacts/. Também é possível usar uma política JSON externa com --policy. Ter o diretório não exige gerar um pacote, e novos pacotes nunca ficam retidos nele.
O POLIS liga requisitos, provas de desenvolvimento, políticas de validação e uma mudança de código identificável.
Uma mudança nasce com requisitos, critérios de aceite, limites de arquivos e provas definidas.
Explorar contratos 02 / EVIDÊNCIASGates, provas Red/Green, identidade das entradas e resultados explícitos: PASS, FAIL ou BLOCKED.
Conhecer a validação 03 / CONSUMOO consumidor verifica o pacote no próprio contexto antes de autorizar qualquer aplicação.
Entender preflight e applyO diagrama abaixo vale apenas para transferir uma alteração: um produtor com CLI constrói o arquivo .polis, e o consumidor decide sua aceitação. Para um agente no mesmo checkout, use workspace validate, sem pacote.
Define, implementa e empacota para outro checkout.
polis startcapture-redpolis buildVerifica e aplica com autorização.
polis verifypolis preflightpolis applyEste diagrama descreve a entrega remota. No próprio checkout, use workspace validate sem pacote. capture-red é exigido em Red-to-Green; Green-to-Green usa caracterização. O plano é opcional. Saiba mais.
Comece instalando a CLI. O comando doctor avalia o ambiente; init prepara a política para seu repositório; plan mostra como a validação será executada a partir da política explicitada.
# Requer Go 1.23+ e Git
go install github.com/MarcosAlves90/polis/v6/cmd/polis@latest
# Verifique a instalação
polis doctor
# Explore sua configuração de validação
# Execute na raiz de um repositório Git com módulo Go
# Diretório temporário fora do repositório
POLIS_OUTSIDE="${POLIS_OUTSIDE:-$(mktemp -d)}"
mkdir -p "$POLIS_OUTSIDE"
polis init --repo . --profile auto --dry-run > "$POLIS_OUTSIDE/policy.json"
polis doctor --repo . --policy "$POLIS_OUTSIDE/policy.json"
polis plan --repo . --policy "$POLIS_OUTSIDE/policy.json"Da primeira execução à especificação dos contratos e das fronteiras de confiança.
Escolha validação local ou entrega remota.
02 — REFERÊNCIAGuia de comandos com exemplos e efeitos.
03 — FUNDAMENTOSSaiba quais garantias o sistema oferece e seus limites.
04 — PROJETOEntenda as camadas Guide, Specification e CLI.
Explore o código-fonte, leia a especificação V6 e acompanhe a evolução do POLIS.