oracle explorar
Vibe coding
El pedido guía la próxima prueba.
- Pedísuna idea
- La IA generacódigo
- Probásel resultado
- Ajustásel pedido
Repetís hasta acercarte a lo que buscabas.
Sirve para explorar. La confianza depende de cómo revises y pruebes lo generado.
metalenguaje de medidas
Reglas que fallan, y dicen por qué.
Cuando un programa, o un modelo de lenguaje, escribe el código y también decide si está bien, puede repetir el mismo error en ambos lados. Oracle es un lenguaje para escribir las reglas de tu proyecto aparte, de forma que se puedan poner rojas: con un número, un umbral que dice de dónde sale y las filas exactas que ofendieron.
uv tool install oracle-metalenguaje Python 3.11 o posterior · cero dependencias · MIT
el problema
Quien escribe el código no puede ser el único que decide si está bien.
Cuando la misma persona, o el mismo modelo de lenguaje, escribe el código y en la misma pasada escribe los tests, estos pueden repetir los mismos supuestos y pasar por alto el mismo defecto. Separar la evaluación ayuda a detectar esos puntos ciegos.
Oracle separa las dos cosas. Las reglas viven en un catálogo aparte, escritas en un lenguaje chico que al cargarse no ejecuta código. Cada regla dice qué no ve. Y el catálogo mismo se pone a prueba: se lo debilita a propósito para ver si sus casos lo notan.
desarrollar con IA
Dónde entra Oracle en el desarrollo con IA.
Una IA puede construir rápido. Todavía necesitás decidir qué querés, cómo comprobarlo y qué hacer cuando falla. Cada fila muestra un foco del trabajo. El SDLC abarca el ciclo completo; SDD y Oracle se pueden incorporar en él.
organizar
Software Development Lifecycle
SDLC: el ciclo de vida del software.
- Requisitosqué hace falta
- Diseñocómo construirlo
- Códigoimplementación
- Pruebasverificación
- Operaciónentregar y mantener
Lo aprendido vuelve al ciclo; las etapas pueden solaparse.
Ordena el trabajo completo. Personas e IA pueden participar en sus distintas etapas.
acordar
Spec-driven development
La especificación guía la implementación.
- Spec revisadaconducta y límites
- Plandecisiones
- Tareaspasos concretos
- IA + códigoy pruebas
- Revisióncontra la spec
Revisás los acuerdos cuando cambia lo que necesitás.
Reduce ambigüedad. La calidad depende también de la spec y de las verificaciones que la acompañan.
medir
Oracle development
Desarrollar con Oracle dentro de tu proceso.
Reglas + casos que revisásQué cuenta como falla, por qué y con qué evidencia.
También probás las reglasLa mutación comprueba si los casos detectan que se debilitan.
Este catálogo alimenta el juicio de Oracle.
- Construísel producto con IA
- Sensorlo observa
- Hechosfilas de evidencia
- Oracleaplica las medidas
- Veredictovalor, testigos y alcance
Corregís con los testigos, volvés a ejecutar el producto y medís otra vez.
Hace discutible el resultado. Las medidas viven aparte del producto; el juicio expone su alcance y la evidencia que falta.
qué suma Oracle
La IA recibe algo concreto que corregir.
En un juego, «los barcos deben quedar dentro del tablero» puede vivir en la spec. Oracle permite convertirlo en una medida: si el sensor informa una casilla en la fila 10, devuelve el barco y la casilla que rompieron la regla. Podés pasarle ese testigo al agente y volver a medir después del arreglo.
Si trabajás con specs, podés enlazar sus requisitos con medidas y consultar qué se cumple, qué falla y qué quedó sin medir.
La mutación comprueba si los casos distinguen las reglas de las variantes probadas. Los casos construidos prueban situaciones imaginadas; los observados aportan respaldo de lo que ocurrió al usar el producto.
Vos seguís revisando las reglas, el sensor y los casos. Un verde vale para las medidas y los hechos evaluados; los tests del producto, la revisión de código y la prueba con personas siguen aportando su propia evidencia.
Hacelo desde cero con el juego de batalla navalcómo funciona
Tu producto cuenta hechos. Las medidas los juzgan.
- 1Tu productoun juego, un servicio, un repositorio
- 2Un sensorun programa tuyo que lo observa
- 3Hechosfilas planas en JSON, sin opinión
- 4Medidasreglas escritas en Oracle
- 5Veredictovalor, umbral, testigos y lo que no vio
oracle juzgar evalúa los hechos que le pasás; no ejecuta tu producto.
Por eso el veredicto trae siempre su alcance, la frase que dice qué quedó sin mirar.
una medida real
Un barco fuera del tablero, atrapado.
Un juego de batalla naval tiene una regla simple: ningún barco fuera del tablero de 10 por 10. Escrita como medida, esa regla no dice «revisá la colocación»: cuando se rompe, te muestra el barco exacto y la casilla. Así sabés qué corregir sin adivinar.
colocacion.dentro_del_tablero.oracle
medida colocacion.dentro_del_tablero:
de celda_ocupada c
donde c.fila < 0 o c.fila > 9 o c.columna < 0 o c.columna > 9
resumen contar(1)
umbral <= 0 segun contrato porque "el tablero es de 10x10 …"
requiere celda_ocupada
ambito universal
alcance "valida que las celdas reportadas estén en el rango 0..9. NO ve …"Recorte del archivo real de la primera medida real. Los … acortan el texto del porque y del alcance.
- de, donde
- qué filas mirar y cuáles ofenden
- umbral
- cuántas ofensas se toleran: cero
- segun
- de dónde sale ese número: un contrato, una medición, una convención o un tanteo
- porque
- la defensa del número, en prosa
- requiere
- sin celdas no hay veredicto: sale , no verde
- alcance
- lo que la medida admite no ver
$ oracle juzgar --con hechos-defecto.json
✗ colocacion.dentro_del_tablero 1 (<= 0)
→ c={'barco': 'destructor', 'fila': 10, 'columna': 5}
VEREDICTO: 1 de 1 medidas en rojouna sola forma de escribir
Cada regla se escribe de una sola manera.
Como el código Go con gofmt: el texto válido es exactamente el que
escribe el impresor de Oracle. Un espacio de más no es un estilo, es otro texto, y no carga. Da
igual si la regla la escribió una persona o un modelo: oracle formatear la deja en la
forma única sin cambiar lo que significa, y una forma que Oracle ya no acepta falla diciendo cómo
se escribe ahora. Medidas en .oracle, casos en .caso, relaciones en
.relacion; los comentarios son líneas que empiezan con #.
$ oracle formatear catalogos/flota/flota.casillas_dentro_del_tablero.oracle
catalogos/flota/flota.casillas_dentro_del_tablero.oracle: requiere formato
--- actual
+++ impresor
@@ -1,5 +1,5 @@
ninguno-requiere flota.casillas_dentro_del_tablero:
- de casilla c
+ de casilla c
donde c.fila < 0 o c.fila > 9 o c.columna < 0 o c.columna > 9
…
oracle formatear catalogos/flota/flota.casillas_dentro_del_tablero.oracle --escribir
$ oracle formatear catalogos/naval/naval.cuenta.oracle
✗ catalogos/naval/naval.cuenta.oracle: línea 3, columna 20: escribí a + bCómo funciona lo muestra paso a paso, y Escribir una medida tiene las reglas completas.
la medida se pone a prueba
Una medida que nada puede romper es decoración.
Oracle debilita cada medida a propósito: afloja el umbral de 0 a 1,
invierte un comparador, le quita el filtro o el requiere. A cada versión debilitada
la llama mutante. Si algún caso del corpus nota la diferencia, el mutante muere. Si ninguno la nota, esa
parte de la medida no la está fijando nadie, y Oracle lo dice.
Al lado de los muertos informa el respaldo real: cuántos mueren por casos
observados en el producto y no sólo por evidencia construida o generada. Y si un mutante sobrevive,
oracle caso generar busca y encoge evidencia hasta dar con el caso que lo mata.
generación con búsqueda
El generador no se rinde: busca y encoge hasta dar con el contraejemplo.
Cuando las reglas directas no alcanzan para matar a un mutante, oracle caso generar
explora el espacio de evidencia: toma literales de la medida, vecinos y filas del corpus hasta encontrar
una combinación donde la regla y el mutante discrepen.
Una vez hallada la discrepancia, no te deja una masa de datos ruidosa: encoge la evidencia quitando filas y campos mientras sigan discrepando, hasta aislar el caso mínimo irreducible.
deuda con límite
La sombra perdona, pero sólo hasta su cota.
Un proyecto real tiene deuda. Una medida en sombra se evalúa y se informa, pero no pone rojo el veredicto. Tiene una cota: el máximo que se tolera. Si la deuda la supera, la sombra deja de perdonar y el rojo vuelve. Así la deuda no crece sin que nadie se entere.
vigilancia de cambios
Nadie afloja una regla ni toca un sensor a escondidas.
Un verificador se debilita cuando alguien sube un umbral, quita un requiere o modifica
un sensor para esconder un fallo en vez de arreglarlo. oracle cambios --desde <ref>
compara tu árbol de trabajo contra el commit de referencia.
Aflojar no se prohíbe, pero se declara: subir un umbral con el mismo porque es error.
Y con "sensores" en oracle.json, vigila además los archivos que alimentan
a las medidas para que ningún sensor deje de avisar.
requisitos y cobertura
Cada promesa del producto tiene su veredicto exacto.
Una medida dice qué ofende, pero un .requisito dice qué promesa del producto protege.
Con oracle cobertura --con <hechos.json>, el catálogo juzga la evidencia real y califica
cada requisito con honestidad:
✓ se cumple por completo; ◐ se cumple en lo medido pero admite
escenarios sin_medir; ✗ no se cumple (incluso si la medida está en sombra);
y ? quedó sin juicio por falta de evidencia.
de la spec a la medida
OpenSpec entra como especificación y sale como requisitos.
Las especificaciones de desarrollo para agentes ya tienen formato estándar. Con
oracle requisito importar, cada sección ### Requirement: y cláusula
SHALL de OpenSpec se convierte en un archivo .requisito con su texto y su fuente.
Nace con sus escenarios pendientes en sin_medir para no fingir cobertura. Desde allí,
oracle medida nueva <dominio.nombre> --escenario-de … crea las medidas que cierran el circuito entre la spec
y el código.
agentes
El agente escribe. Oracle juzga desde afuera.
Un agente de programación puede consultar a Oracle por MCP: qué reglas aplican, qué dice una medida sobre estos hechos, cuál es el veredicto del catálogo entero. El servidor es de sólo lectura: por ahí el agente no puede cambiar las reglas para darse la razón.
El lenguaje se amolda a cómo escriben los modelos: t2.turno == t1.turno + 1 se lee
tal cual. Y un modelo puede servir de sensor de la prosa de un catálogo, nunca de juez:
un modelo como sensor.
Si el agente intenta aflojar reglas o sensores en vez de arreglar su código, oracle cambios
vigila el catálogo, las escalares y los sensores declarados. Y con oracle requisito importar
y oracle cobertura --con, las promesas de una spec se verifican contra hechos reales:
OpenSpec y Oracle.
64
medidas en el catálogo de Oracle
221
casos que las ponen a prueba
0
dependencias
Oracle es experimental. Los resultados de mutación dependen de los archivos y las líneas que se probaron; una ronda parcial no demuestra que todo el núcleo esté fijado. Consultá el alcance de la verificación.
por dónde seguir
Elegí según lo que necesitás hoy.
desde cero · se juegaTu primer juego con un LLMUna batalla naval en nueve misiones: predecís cada salida, rompés la regla en un tablero y cazás sus mutantes.
cómo funcionaCómo funciona OracleQué hace, en qué orden y qué contesta en cada caso, con cada salida ejecutada.
si ya programásDe cero a un rojoUn recorrido corto: instalar, escribir una medida y verla fallar con sus testigos.
tu productoLa primera medida realDe un producto nuevo a un hecho exportado, una medida y un veredicto.
el lenguajeEscribir una medidaAnatomía, macros, la forma canónica y los errores que te dice.
integrarConectar un proyectoSensor puro, adaptador, vigilar sensores con cambios, escalares propias y la sombra.
specsOpenSpec y OracleImportar requisitos con oracle requisito importar y juzgar evidencia con cobertura --con.
trabajoEl tracker de tareasTareas en carpetas y Markdown, con el próximo paso como relevo.
referenciaEspecificaciónEl álgebra entera, para implementarla sin ver el núcleo.
empezar
Tres comandos.
uv tool install oracle-metalenguaje
oracle init mi-proyecto && cd mi-proyecto
oracle testUn proyecto recién creado sale : todavía no midió nada, y Oracle no lo disfraza de verde. El paso siguiente está en de cero a un rojo.