Ângulo

Cada andar do contexto que absorve quinhentos e-mails de condomínio foi acrescentado por uma falha datada do nível anterior: o diário cronológico porque a agregação tinha apagado as datas da obra; o arquivo de diretrizes porque as regras de tratamento sufocavam sob o material; a divisão em quinze arquivos temáticos porque o context.md tinha passado das mil linhas; o glossário porque o mesmo vocabulário técnico se repetia em todo lugar. A arquitetura final — diretrizes, glossário, índice, arquivos temáticos — se lê, portanto, como a lista das falhas encontradas, na ordem em que apareceram; e, como essa lista é justamente o que falta a quem a pega pronta de outro lugar, um sistema copiado pela forma devolve apenas a estrutura de quem sofreu essas falhas, deixando intactas as falhas que você ainda não encontrou.

Síntese

As quatro falhas da série não têm nada em comum quanto à causa. Uma é um apagamento voluntário que não produz nenhum erro — uma ficha exata, apenas amnésica. Outra é um desacordo de organização, em que a máquina trabalhou bem e o que ela devolve não é a estrutura de ninguém que vá ter de usá-la. Uma terceira é um efeito de volume que se volta contra o próprio modelo. A última é uma redundância de vocabulário. O que as reúne está numa coisa só: nenhuma era visível do patamar anterior, e cada uma só pôde ser nomeada depois de ter sido sofrida.

Daí decorre a ordem, que não é intercambiável: só dá para dividir direito por tema depois de ter tirado as regras do arquivo, sem o que você não sabe o que precisa ser copiado em cada pedaço. E daí decorre o estatuto singular do primeiro patamar — ele não produz um sistema, produz o inventário das falhas por vir, o que torna a substituição dele normal em vez de cara, e o que explica por que esse inventário não pode ser emprestado de outra pessoa: uma arquitetura pronta só mostra as respostas dela.

Falta a condição que autoriza todo o percurso, e que nenhum desses patamares enuncia. Consertar depois da falha pressupõe que a falha se pague em desvio e não em perda — o histórico que falta é reencontrado nos e-mails brutos guardados ao lado, um fornecedor mal vinculado se corrige reabrindo uma mensagem. Num material em que o erro não se recupera, a construção por falhas sucessivas deixa de ser um método e vira uma aposta de risco.

Tensões / contradições

Duas orientações da mesma série não puxam para o mesmo lado. Uma diz para só subir um patamar quando o anterior não bastar mais; a outra diz que a primeira versão é feita para ser jogada fora. Consertar em passos curtos e recomeçar do zero são dois gestos diferentes, e nada diz em que momento um deixa de ser o certo.

Outra tensão, entre o princípio e a prática de quem o enuncia: ele recomenda começar com um arquivo e avançar por falhas, enquanto mantém um sistema de contextos completo — pastas, manifestos de carregamento, notas conectadas — já na terceira versão. O conselho se dirige a quem começa; ele não descreve a posição de quem o dá.

Questões

• Um sistema herdado — pego de um colega, de um modelo público — consegue produzir as próprias falhas rápido o bastante para que você as entenda, ou é preciso tê-lo construído para enxergá-las?
• Quantos patamares uma equipe consegue subir junta, quando a falha só é sentida pela pessoa que trata o material?
• O que acontece com um andar cuja falha de origem desapareceu — porque o limiar que o motivou mudou — e que ninguém pensa em desmontar?