alusonhador v.2

entre fakescript e protocolo ritual

[a partir de alusonhador.docx.pdf]

alusonhador situa-se entre literatura, software especulativo e design de interação com modelos de linguagem. O seu ponto de partida não é o da “poesia em código” entendida como simples tematização do digital, mas antes o de um protocolo de ativação: um ritual computacional, uma API simbólica para o sonho, uma instrução performativa que desloca o código do domínio da utilidade para o da deriva, do desvio e da fabulação.

Obra realizada por encomenda do projeto IN&OUT of the BOX, que se foca na interseção entre criatividade, inteligência e tecnologia, explorando a “caixa preta” da inteligência artificial através de práticas que articulam investigação científica, crítica e criação artística.

Contexto e origem

Na sua primeira formulação, alusonhador.docx.pdf apresentava-se como um artefacto híbrido, composto por um README, um script, um conjunto de módulos auxiliares e um arquivo de memórias não vividas. Cada elemento desempenhava uma função precisa dentro dessa arquitetura onírica: o README funcionava como manual de invocação; o .py como encenação do processo; o .zip como campo de incompletude habitável; o abismo.txt como reserva lírica, memória emocional e matéria de contaminação; a página 404 como desvio, falha e meta-interface.

O gesto central da obra consistia em tomar a sintaxe computacional como forma de escrita ritual. Em vez de produzir um programa orientado para a eficácia, alusonhador propunha um anti-paradigma da programação: importava bibliotecas inexistentes, convocava módulos impossíveis, insistia em funções que nada devolviam, percorria ciclos que não resolviam e instalava o erro como condição de funcionamento. Aqui, o código não era corrigido para melhor servir uma máquina; era desviado para melhor expor o seu potencial metafórico. Em vez de determinismo, havia deriva. Em vez de output, suspensão. Em vez de resolução, a permanência do inacabado.

Nesse contexto, o chamado modo onírico não era apenas um tema, mas um verdadeiro estado de execução. Ao declarar que modelo.modo = "delírio", que o estímulo era uma “memória não vivida”, ou que se devia “injectar alucinação”, a obra traduzia conceitos correntes da interação com modelos de linguagem, como contexto, temperatura, prompt e input, em metáforas ontológicas. A temperatura tornava-se febre; o contexto tornava-se abismo; o input tornava-se memória inexistente.

O abismo.txt ocupava, por isso, um lugar decisivo. Não funcionava apenas como ficheiro auxiliar, nem apenas como corpus textual. Era ao mesmo tempo dataset lírico, arquivo afetivo e embedding emocional. Nele acumulavam-se resíduos de experiências não ocorridas e fragmentos de linguagem que operavam como combustível para uma fabulação algorítmica.

Segunda formulação

A segunda formulação do projeto parte desse núcleo, mas decide dar-lhe um corpo parcialmente executável. Não se trata de “corrigir” o fakescript, mas de permitir que ele corra sem deixar de resistir semanticamente. O não-funcional torna-se parcialmente funcional: surgem versões de terminal, ciclos executáveis, delays, pseudo-respostas e logs oníricos.

A partir daí, a obra abre-se a novos contextos de aparição. Em terminal, surge como uma CLI que fala e falha poeticamente. Em website, transforma-se numa consola sonhadora: uma página escura, um cursor vivo, linhas que surgem lentamente e logs atravessados por ruído lírico.

Assim, alusonhador não é apenas um script, nem apenas um poema, nem apenas uma interface. É uma máquina de suspensão. Um sistema operativo do sonho.

Entrar em alusonhador é aceitar um regime em que a falha não é acidente, mas método; em que o erro não é ruído a eliminar, mas matéria composicional.