Lights Off — do ticket do Jira ao PR, no automático

🚧 Em construção — o pipeline principal (ticket → código → testes → PR) está implementado; o chat unificado por linguagem natural e o loop de review de PR são as frentes abertas.

O nome vem de lights-out manufacturing — a fábrica que opera de luz apagada, sem humanos no chão. Lights Off aplica a ideia ao ciclo de desenvolvimento: você aponta um ticket do Jira, e a ferramenta clona os repositórios, cria a branch, sobe um container de desenvolvimento isolado e conduz um agente de IA pelo pipeline completo — Analyze → Plan → Implement → Validate → Submit — até abrir os pull requests.

O fluxo

1. Analyze: o agente lê o ticket e o código e identifica lacunas — perguntas bloqueantes viram um wizard antes de qualquer código.
2. Plan: plano de implementação proposto, revisado e aprovado por você.
3. Implement: sessão streaming do agente (CLI do Claude Code) executa o plano no workspace.
4. Validate: os testes rodam dentro do container, com gate de cobertura de 80% sobre linhas novas e loop de auto-fix (até 2 tentativas) — as falhas voltam pro agente em sessão nova, para não estourar o contexto.
5. Submit: commit por repo, push e abertura de PR — com detecção de PR já existente.

Há também a cadeia autônoma: Implement → Validate → Submit encadeados, parando na primeira falha. Você aprova o plano e vai tomar um café.

Arquitetura

Solução .NET 10 em camadas — Core (domínio puro), Infrastructure (Jira, GitHub, Git, Docker, agentes), App (Blazor Server + minimal API) e uma CLI que fala HTTP com a App. Todo o estado vive fora do projeto, em ~/.lightsoff/ (SQLite, segredos com permissão 0600, workspaces).

Visão de componentes:

Fluxo do pipeline por ticket:

Decisões técnicas que valem a pena contar

A CLI do Claude como runtime de agente. Em vez de integrar uma API de LLM (chave, billing, streaming próprio), o Lights Off sobe a CLI local do Claude Code como subprocesso em modo stream-json, reutilizando o login do host. Um parser de linhas fazbridge dos eventos para a UI, e cada evento é persistido em SQLite — o replay do step é lossless.

Separação de poderes: IA no host, testes no container. O system prompt injetado proíbe o agente de rodar build/test/install — isso é papel do pipeline, via docker exec no container do ticket (com timeout de 10 minutos por comando). O agente escreve código; a validação é determinística e isolada.

Bind-mount em vez de symlink. A primeira versão montava o workspace com symlinks internos — que não resolvem dentro do container. A correção monta cada repo diretamente em /workspace/<nome>, mantendo symlinks só no host para navegação humana.

Roteador de intenção sem LLM. O chat mapeia texto livre (PT e EN) para intents com um roteador determinístico por keywords, gated pelo estado do workflow — "implementa" só é acionável com plano aprovado. Barato, testável, e serve de fallback para um roteador LLM futuro.

Modo demo completo. Toda a infraestrutura tem implementação fake (Infrastructure/Demo/), isolada em ~/.lightsoff-demo/ — dá pra demonstrar o produto inteiro sem Jira, GitHub ou Docker reais.

Stack

.NET 10 · Blazor Server · EF Core + SQLite · LibGit2Sharp · Docker.DotNet · System.CommandLine · Serilog · xUnit · integrações: Jira Cloud REST v3, GitHub REST, CLI do Claude Code / GitHub Copilot.

Status

🚧 Caminho principal implementado: Jira → workspace → container → pipeline de IA → PR, com CLI, health checks e modo demo. Frentes abertas: chat unificado por linguagem natural, loop de review de PR (responder e resolver threads de review automaticamente) e acesso remoto.