Sin alucinaciones
Antes de escribir una sola línea, confirma que lo que va a tocar existe de verdad en tu sistema — y se detiene si no está seguro, en vez de inventar.
MANIFEST · RDS COSTA RICA
Programar es apenas
una de seis etapas.
Tu equipo ya escribe código rápido. El problema es todo lo demás — aclarar, definir, probar y entregar con evidencia — y nadie lo mide. MANIFEST convierte ese trabajo invisible en un proceso con dos firmas humanas obligatorias.
RDS CRM
MANIFEST · JIRA IN · PRS OUT
TCK-231[FRD] Checkout — Mostrar el motivo de un pago rechazado
158ktokens
00:14elapsed
4/6phase
5/5sprint
✓ TICKETS✓ GROOM✓ PLAN✓ REVIEW5 BUILD
Las 2 specs están aprobadas — listo para construir. (2/5 aprobadas)▸ Implementar 2 aprobadas
TTRIBUNALticket audit · opus
AANARCHorchestrator · opus
OORACLEassumption validation · sonnet
PPRISMshipped
BBUNKER—
FFORGE—
CCONDUITshipped
WWITNESSskipped
VVEILangular · opus
BBREACHqa gate · opus
WWARDENsec/arch · opus
● LIVE CONSOLE
sistema listo · elegí un ticket o un sprint
▸ conectado al backend de MANIFEST (live)
ANARCH: specs generadas · esperando aprobación
BREACH: build y pruebas corriendo…
WARDEN: 4 hallazgos · 0 críticos · 1 alto · 1 medio · 2 bajos
● TOKENS / AGENT
TRIBUNAL
ANARCH
ORACLE
VEIL
BREACH
WARDEN
● SPRINT
TCK-224pass ✓
TCK-225pass ✓
TCK-226pass ✓
TCK-228pass ✓
TCK-229pass ✓
- Agentes · 1 director
- 21
- Fases · 5 compuertas
- 13
- Firmas humanas obligatorias
- 2
- Pantallas, una por puesto
- 36
Cómo funciona MANIFEST
CÓMO FUNCIONA
Entra un ticket. Sale un Pull Request revisado.
Y cuando el sistema necesita que alguien decida, avisa. No escribe código más rápido: hace todo lo que va alrededor del código, que es donde realmente se va el tiempo del equipo.
Backlog4
Checkout — reembolsos parciales
En progreso2
Checkout — mostrar motivo de pago rechazado
Code Review3
Perfil — verificación de identidad
Notificaciones — silenciar por canal
Done12
Onboarding — invitar equipo
Reportes — export a CSV
LA MITAD DESCONFÍA DE LA OTRA MITAD
Ninguna compuerta puede escribir en tu repo.
Seis controles de calidad revisan de verdad que el código compila, que las pruebas pasan y que lo que promete el frontend coincide con lo que entrega el backend. Solo con ese reporte en verde se abre el Pull Request — y eso no lo decide una instrucción, lo hace cumplir la herramienta.
▶TCK-231Checkout — retry de pagolisto para QAPR ↗
Primer QA del dev: aprobó · A. Morgan
📝 Notas del devCaso de retry cubierto — falta reintento con tarjeta vencida.
Sign-off ✅ (habilita merge)Rebotar ⛔ (abre ticket de fix)
SE REVISA ANTES DE CONSTRUIR
Vos no aprobás código. Aprobás la especificación.
Todas las especificaciones de una tanda se revisan juntas antes de aprobarlas una por una, así se detecta lo que a nadie se le escapa mirándolas de a una. Aprobar, pedir cambios o devolver con comentarios: la decisión siempre es tuya.
MANIFEST · SPEC GATE
CKO-014Checkout — retry de pagoaprobado✓ datos OK
CKO-015Checkout — reembolsospendiente⚠ suposición falsa
AprobarEditar✦ Sugerencia CHORUS
DOS FIRMAS HUMANAS
Firmás las pruebas. Con evidencia real.
Quien construyó lo prueba primero. Luego, control de calidad confirma exactamente lo que se marcó como probado — sin eso, no hay forma de firmar. Al cerrar cada pedido, el sistema deja escrita la guía de cómo probarlo, con la ruta real que se construyó.
▶TCK-231Checkout — retry de pagofirmado
📝 Auto-prueba del dev3/3 casos probados — aprobó y envió a QA.
Sign-off ✅ (habilita merge)
▸ ver guía completa
MANIFEST
Una línea de ensamblaje, no un asistente.
21 especialistas de IA, cada uno con una tarea puntual, coordinados por un director que lleva el control de todo el proceso. Nada avanza sin pasar su revisión.
QA que corre de verdad
Corre pruebas reales sobre cada criterio de aceptación del pedido — no una revisión superficial de que 'se ve bien'.
Frontend y backend, sincronizados
Detecta cuando una parte del sistema entrega algo distinto a lo que la otra espera recibir — antes de que ese error llegue a producción.
Dos firmas humanas
Aprobás la especificación y firmás las pruebas. No se pueden saltear desde la pantalla.
Métricas por ticket
Duración, consumo y costo real de cada tarea — para cotizar con evidencia, no con intuición.
Freno de presupuesto
Antes de arrancar y antes de cada ticket, consulta cuánta cuota queda. Si se pasa, pausa limpio y avisa por qué.
EL PILOTO
Dos semanas, medidas contra tu propio histórico.
Así es el piloto: no una demo, un sprint real de tu equipo, acompañado de cerca la primera semana.
Día 1
Instalación y arranque sobre tu propio repositorio. El sistema aprende las reglas y patrones que tu equipo ya usa, para no inventar las suyas.
Día 2
Un sprint real de tu equipo, dividido en grupos de 3 a 6 tareas. Las especificaciones se aprueban en conjunto.
Semana 1
Ejecuciones acompañadas — tu equipo ve cada control de calidad en acción antes de dejarlo trabajar solo.
Semana 2
Trabaja solo durante la noche, con revisión a la mañana siguiente. El freno de presupuesto lo mantiene bajo control en todo momento.
Cierre
Tareas entregadas, tiempos, costos y errores encontrados — medidos contra tu propio histórico, no contra un promedio genérico.
Qué pedimos: un repo y una contraparte técnica, un sprint real (no un ejercicio), y dos horas de calendario. Qué no prometemos: un porcentaje de ahorro, cero defectos, o que funciona sin que nadie revise.
SIN INFRAESTRUCTURA NUEVA
Lo que necesita de tu lado.
Sin infraestructura nueva que levantar: se instala sobre lo que tu equipo ya usa.
Construye con
AngularFlutterNestJSExpressFastifyNodeTypeScript / JavaScript
Datos
SupabaseSQL (TypeORM / Prisma / Knex)MongoDBSAP Business Onen8n
Entrega
GitHubGitLabBitbucketJira o tablero propio
Avisa por
WhatsAppMicrosoft Teams
¿No ves tu stack o tu framework? El Definition of Done y las reglas también son configurables: lo adaptamos a tu forma de trabajar. Contáctanos y lo configuramos para ti
Las preguntas que siempre hacen.
Sin vueltas — incluido lo que MANIFEST todavía no hace.
¿Reemplaza a mi equipo?
No. Redacta, propone y pregunta — qué se construye y en qué orden lo sigue decidiendo una persona. Dos compuertas humanas (aprobar la especificación y firmar las pruebas) no se pueden saltear desde la pantalla.
¿Garantiza cero errores?
No, y no lo va a prometer nadie de nuestro equipo. Reduce clases enteras de error y las hace visibles: lo que sí garantiza es que ningún ticket llega a revisión sin que las pruebas se hayan corrido de verdad.
¿Corre en la nube?
Hoy corre en la máquina de cada quien — el código del cliente no sale de ahí. El plan de servidor ya está escrito y presupuestado; se habilita en una fase posterior.
¿Aprende de mi repo automáticamente?
No por magia. Lee las convenciones que tu equipo ya escribió; en un repo con historia hay que levantarlas primero — eso es el 'censo', un trabajo de implantación de una sola vez.
¿Qué necesito para empezar?
Node 18 o superior, git, el CLI del motor y tu herramienta de Pull Requests. El panel no tiene dependencias propias que instalar.
¿Cómo se cobra?
Tres estructuras: licencia (por instalación o por persona), implantación (licencia + adopción acompañada), o entrega gestionada (no comprás la herramienta, comprás tickets terminados). El precio se define en la propuesta, después del piloto.
Pedí el piloto de 2 semanas.
Un repositorio real, un sprint real, medido contra tu propio historial — no una demo genérica.
¡Mensaje enviado!
Gracias por escribirnos. Te contactaremos en menos de 24 horas hábiles.
