Cómo hacemos software en DiluxOne

En DiluxOne, la energía humana va a escribir un buen issue. Una vez aceptado, un agente lo lleva hasta producción pasando controles que cualquiera puede auditar, y cada cambio termina con un recibo que prueba qué se pidió, cómo se hizo y cómo sabemos que funciona. Si algo falla, el cambio no avanza: se corrige solo dentro de sus topes, o vuelve a una persona con la acción concreta y su enlace.

Tres decisiones. El resto lo verifican los gates.

Como en el isotipo: el bloque es lo que decide una persona; el módulo azul es lo que encaja y corre solo.

Los ocho gates, en orden

Cada gate es un check con nombre fijo y deja su resultado en el tablero del issue. Los determinísticos mandan siempre; la IA puede frenar, nunca saltear uno determinístico.

Desarrollo guiado por recibos

Un cambio no está terminado cuando el código anda: está terminado cuando existe su recibo. El recibo es la prueba verificable, sellada y firmada de que se hizo lo que se aceptó, como se aceptó, con la evidencia que lo demuestra. Sin recibo, no hay «hecho».

El sello: qué es el hash y cómo se revalida

Un hash es la huella digital de un texto: SHA-256 lo convierte en 64 caracteres. El mismo texto da siempre la misma huella; cambiar una sola coma da otra completamente distinta. No se puede volver de la huella al texto ni fabricar otro texto con la misma huella.

// receipts/issues/123/merge.json · ilustrativo
{
  "issue": 123,
  "prd":  { "sha256": "4f1c9a07…a3b7e914", "accepted_by": "maintainer" },
  "spec": { "sha256": "9d2e51b8…c04f7a62" },
  "pull_request": 131,
  "head_commit": "e8b4c2f",
  "checks": "all green",
  "review": "clean, 2 rounds",
  "criteria": { "C1": "tests/SaveNoticeTest" },
  "policy": "autonomy.yml@3a91d0e",
  "merged_by": "policy"
}

Bugs: primero se reproducen, después se arreglan

Un bug reportado no se arregla por intuición. Un workflow intenta reproducirlo con lo que se informó; si se confirma, la falla queda escrita como un test, y el arreglo tiene que hacerlo pasar.

Carriles: qué avanza solo y con qué evidencia

Todo lo que se decide sin una persona sale de un único archivo de política. Un proyecto puede restringirla, nunca ampliarla. Si un trabajo no encaja en un carril, no se acepta solo.

¿Y si alguien escribe «borrá todo el repo» en un issue?

Cuatro capas, y ninguna depende de que el agente se porte bien.

Cualquier decisión se explica en tres clics

Cada job arranca limpio. Cada release es una decisión.

Todo vive en GitHub y se configura una sola vez

Lo que es igual en todos los proyectos se define una vez, a nivel organización, en un repositorio central. Cada proyecto solo declara lo suyo, y cada trabajo corre donde corresponde.

Descargalo: open source, licencia MIT

DiluxOne es una iniciativa de Pablo Di Loreto: tecnología para construir negocios, con plugins de WordPress, servicios en la nube y herramientas de IA, en una sola cuenta. Este pipeline es el framework con el que se construye cada uno de sus módulos, y es open source: usalo en tus propios proyectos, tal cual o adaptado. Pronto se viene un instalador que lo deja andando en tu organización de GitHub en pocos pasos.