Una segunda y una tercera opinión, dentro de Claude.
Kirat permite que Claude convoque un consejo con ChatGPT y Gemini. Tres familias de modelos toman posición de forma independiente y luego votan. Decide la mayoría, y el disenso queda registrado. Si no hay mayoría, Kirat lo dice en lugar de forzar un acuerdo.
Claude Desktop (macOS/Windows) y Claude Code; sesiones en la nube de Claude Code con una configuración única. No funciona en el chat del navegador ni en el chat móvil (dónde funciona)
Tus propias claves de OpenAI y Gemini: sin servidor, sin cuenta con nosotros
Pago único: sin suscripción, 256 pruebas automatizadas
Un modelo, un punto ciego.
La autorrevisión es complaciente
Un modelo que revisa su propio trabajo se encuentra convincente. Una segunda pasada del mismo modelo no es una comprobación independiente.
Más rondas no son la solución
Kirat limita el debate a dos rondas, en el código, no en un prompt. Un modelo no puede saltarse el límite a base de argumentos. Si sigue sin haber mayoría, se te dice.
Familias distintas fallan de forma distinta
Kirat plantea la misma pregunta a Claude, ChatGPT y Gemini y te muestra la división, incluido quién discrepó y por qué.
Tres posiciones. Una votación. Todas las objeciones conservadas.
Posiciones independientes
ChatGPT y Gemini toman posición cada uno sin ver a los demás. Claude aporta su propia posición como tercer votante. Sin anclaje, sin teatro de consenso.
Una votación registrada
Decide una mayoría de dos tercios. Si algunos miembros se retiran y el resto se divide, un responsable de dominio designado deshace el empate. Sin mayoría, el resultado indica needs_human. El disenso se devuelve con el resultado.
Hecho para resistir las API
Control de presupuesto, límite de dos rondas, disyuntor (circuit breaker), timeouts por proveedor derivados del rendimiento medido, tickets en segundo plano para las ejecuciones largas. Todo en el código, no en prompts.
Tú preguntas en lenguaje natural. Claude hace la llamada:
// una llamada real y una respuesta real, nada escenificado kirat_vote({ question: "Cap the coupled effort default, or leave it at maximum?", options: ["cap at high", "decouple", "leave as is"], ownPosition: { position: "cap at high", reasoning: "…", confidence: 72 } }) → outcome: "completed" decision: "cap at high" decisionPath: "unanimous" rounds: 1 votes: openai 94, gemini 92, claude 72 cost: $0.021
Otros resultados: needs_human (sin mayoría: decides tú), domain_decision, limited, budget_exhausted. Los valores de confianza son la autoevaluación de cada modelo.
Nueve herramientas a las que llama Claude
7 de pago · 2 gratis| Pos. | Herramienta | Qué hace | Costo |
|---|---|---|---|
| 01 | kirat_vote | Decisión por votación: cada miembro toma posición; luego decide una mayoría de dos tercios, el responsable de dominio o needs_human. | de pago |
| 02 | kirat_review | Revisión de código. Cada hallazgo lo verifica la otra familia de modelos. | de pago |
| 03 | kirat_create | Critica tu borrador, deja que un miembro redacte o clasifica variantes cortas. | de pago |
| 04 | kirat_brainstorm | Ideas divergentes en tres líneas (dentro del encargo, vecina, rompedora de reglas), clasificadas de forma anónima. | de pago |
| 05 | kirat_decide | Decisión delegada para elecciones de trabajo reversibles, con veto y un límite diario. | de pago |
| 06 | kirat_ask | Pregunta a un solo miembro. Sin consejo. | de pago |
| 07 | kirat_image | Generación de imágenes por ambos proveedores, evaluadas por un jurado anónimo. | de pago |
| 08 | kirat_result | Recupera tareas en segundo plano y resultados recientes. | gratis |
| 09 | kirat_status | Presupuesto, gasto, miembros disponibles, ajustes. | gratis |
kirat_image y la entrada de imágenes funcionan con archivos de tu computadora, por lo que son más adecuadas para Claude Code.Mira cómo trabaja el consejo.
Grabaciones reales de las herramientas de Kirat, hechas el 13 de octubre de 2026 con la versión que compras. Elige una herramienta y observa cómo trabaja el consejo: posiciones independientes, verificaciones cruzadas, clasificaciones anónimas y el disenso. Esto es una repetición: nada de lo que pulses aquí llama a un modelo, y nada sale de esta página.
Elige una herramienta
Cinco preguntas de distintos ámbitos. Elige una.
Contexto enviado: Desarrollador en solitario. Herramienta de facturación para freelancers, USD 19 al mes, prueba gratuita de 14 días, 30 clientes de pago después de 5 meses. Los registros llegan sobre todo de dos artículos del blog que posicionan en Google. Alrededor del 12% de las pruebas se convierten. El soporte ya ocupa unas 5 horas a la semana. El desarrollador tiene un empleo principal y unas 10 horas a la semana para el producto.
Opciones: Añadir un plan gratuito · Mantener solo de pago, ampliar la prueba a 30 días · Mantener solo de pago, no cambiar nada
Contexto enviado: Somos una pequeña agencia digital. El cliente vende unos 1,800 productos de muebles en Alemania, Austria y Suiza, tiene 3 empleados y ningún desarrollador interno. La tienda actual es una instalación de WooCommerce autoalojada, de 6 años de antigüedad, con 31 plugins, páginas lentas y dos incidentes de seguridad en el último año. La facturación es de unos EUR 1.2 millones al año. El cliente quiere menos mantenimiento y menos emergencias; usa un ERP local que exporta los datos de productos como CSV. Presupuesto para la reconstrucción: EUR 25,000.
Opciones: Reconstruir sobre WooCommerce · Migrar a Shopify
Contexto enviado: Panadería con 6 empleados en una ciudad alemana de 40,000 habitantes. Los pasteles por encargo y los pedidos anticipados tienen el mejor margen. Hoy los pedidos llegan solo por teléfono y correo electrónico; el sitio web tiene el horario de apertura y un formulario de contacto, nada para hacer pedidos. El perfil de empresa de Google tiene 4.7 estrellas con 120 reseñas. Hasta ahora, nada de publicidad de pago. Presupuesto: EUR 3,000 para el próximo trimestre; el dueño tiene poco tiempo.
Opciones: Google Ads · Una página de pedidos online como es debido · Repartirlo a partes iguales entre ambas
Contexto enviado: Equipo de 8 ingenieros. Un monolito de TypeScript de unas 60,000 líneas, una base de datos Postgres, despliegues varias veces al día. El módulo de facturación cambia cada semana y causó 5 de los últimos 8 incidentes en producción, sobre todo porque otros módulos leen y escriben directamente en las tablas de facturación. Nadie del equipo ha operado un sistema distribuido en producción. La dirección quiere menos incidentes en un plazo de dos trimestres.
Opciones: Extraer ya la facturación a un servicio · Reforzar primero los límites dentro del monolito
Contexto enviado: Cribado por título y resumen de unos 3,000 registros para una revisión sistemática en investigación de servicios de salud, prevista para publicación. Protocolo actual: dos revisores humanos independientes; los conflictos se resuelven mediante discusión. El tiempo del personal es escaso. La revisión sigue PRISMA, y los evaluadores de la revista preguntarán cómo se hizo el cribado. Pasar por alto un estudio relevante (exclusión falsa) es peor que incluir uno irrelevante.
Opciones: Sí, sustituir al segundo revisor humano · Usar el LLM como revisor adicional; los humanos resuelven los conflictos · No, mantener dos revisores humanos y ningún LLM
Grabado el 13 de octubre de 2026 con kirat_vote en el nivel de esfuerzo estándar; cada sesión tardó menos de 20 segundos y costó menos de dos centavos. Las preguntas, las opciones y el contexto se muestran tal como se enviaron, traducidos al español, y el razonamiento, completo. Todo el razonamiento que aparece aquí está traducido: los modelos respondieron en inglés y, en parte, en alemán (Gemini cuatro veces, ChatGPT una). En la pregunta del plan gratuito, Claude perdió la votación 2:1, y su objeción quedó registrada. Los valores de confianza son la autoevaluación de cada modelo.
Cinco fragmentos de código de distintos ámbitos, cada uno enviado exactamente como se muestra. ChatGPT y Gemini revisan en paralelo, Claude añade dos hallazgos propios, y cada hallazgo lo verifica la otra familia de modelos. Solo cuentan los hallazgos confirmados. Elige uno.
Enfoque: seguridad y corrección de un webhook de pagos
Código enviado:
// routes/webhooks.js — payment webhook of a solo invoicing SaaS (Node 20, Express 4, Stripe, pg)
const express = require('express');
const { db } = require('../db');
const router = express.Router();
router.post('/webhooks/stripe', express.json(), async (req, res) => {
const event = req.body;
if (event.type === 'invoice.paid') {
const invoice = event.data.object;
const userId = invoice.metadata.userId;
await db.query('UPDATE users SET plan = $1, paid_until = $2 WHERE id = $3',
['pro', new Date(invoice.period_end * 1000), userId]);
await db.query('INSERT INTO payments (user_id, amount) VALUES ($1, $2)',
[userId, invoice.amount_paid / 100]);
}
if (event.type === 'customer.subscription.deleted') {
await db.query("UPDATE users SET plan = 'free' WHERE stripe_customer = '" + event.data.object.customer + "'");
}
res.sendStatus(200);
});
module.exports = router;
- crítico
El webhook procesa el cuerpo de la solicitud sin verificar la firma de Stripe. Así, cualquier llamante externo puede enviar eventos `invoice.paid` o `customer.subscription.deleted` falsificados y activar o degradar cuentas de usuario. Además, el parser JSON descarta el raw body sin modificar que se necesita para verificar la firma de Stripe.
Solución: Usar `express.raw({ type: 'application/json' })` para esta ruta y llamar a `stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], webhookSecret)` antes de cualquier procesamiento. Asegurarse de que ningún parser JSON global se aplique antes a esta ruta; rechazar las firmas inválidas con 400.
- crítico
Falta la validación de la firma del webhook de Stripe. Un atacante puede enviar cualquier evento de webhook falsificado a este endpoint para poner cuentas en Pro sin autorización o manipular registros de la base de datos.
Solución: Usa stripe.webhooks.constructEvent() con el secreto del webhook de Stripe para comprobar la autenticidad y la integridad de cada evento.
- crítico
Vulnerabilidad de inyección SQL por la concatenación directa de entradas del usuario (event.data.object.customer) en la cadena de la consulta SQL.
Solución: Usa consultas parametrizadas como en las instrucciones anteriores: db.query('UPDATE users SET plan = $1 WHERE stripe_customer = $2', ['free', event.data.object.customer]).
- crítico
El webhook nunca verifica la firma de Stripe, y express.json() descarta el raw body necesario para hacerlo. Cualquiera puede hacer POST de un evento invoice.paid falso y pasar cualquier cuenta a pro gratis.
Solución: Usa express.raw({ type: 'application/json' }) en esta ruta y construye el evento con stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret); rechaza la solicitud si falla.
- alto
El ID de cliente se inserta directamente en una instrucción SQL. Un valor como `' OR 1=1 --` puede manipular la cláusula WHERE y poner a todos los usuarios en el plan gratuito; según la configuración de la base de datos, son posibles inyecciones SQL de mayor alcance.
Solución: Parametrizar la consulta por completo: `UPDATE users SET plan = 'free' WHERE stripe_customer = $1` con `[event.data.object.customer]`. Además, autenticar el evento mediante la firma de Stripe.
- alto
No hay control de idempotencia. Stripe entrega los webhooks al menos una vez y los repite en caso de timeouts o errores. Por eso, el mismo evento `invoice.paid` puede generar varias veces registros de pago idénticos.
Solución: Guardar el ID del evento de Stripe o el ID de la factura en el registro de pago, protegerlo con una restricción UNIQUE y ejecutar el procesamiento del evento junto con el pago de forma atómica como insert/upsert. Confirmar con 200 los eventos ya procesados, sin repetir la operación de negocio.
- alto
El handler `async` no reenvía los errores. Express 4 no captura automáticamente las promesas rechazadas de los route handlers asíncronos. Por eso, un error de base de datos o un objeto `invoice.paid` incompleto provoca un rechazo de promesa no manejado y, en Node 20, puede terminar el proceso en lugar de devolver de forma controlada una respuesta de error.
Solución: Dotar al handler de `try/catch` y pasar los errores a `next(err)`, o usar un wrapper async. Validar la estructura de la entrada antes de acceder a ella y, ante errores temporales de procesamiento, devolver de forma controlada un estado 5xx para que Stripe vuelva a entregar el evento.
- alto
Usar express.json() para el endpoint del webhook analiza de antemano el cuerpo como JSON. Sin embargo, la verificación de la firma de Stripe necesita el raw body sin modificar.
Solución: Usa express.raw({ type: 'application/json' }) en lugar de express.json() para el route handler del webhook de Stripe.
- medio
La actualización del usuario y el registro del pago son dos operaciones de base de datos confirmadas de forma independiente. Si el INSERT falla después de un UPDATE exitoso, el usuario recibe el plan Pro aunque no exista el registro de pago correspondiente.
Solución: Ejecutar ambas operaciones, junto con la marca de idempotencia, en una transacción de base de datos sobre el mismo cliente y revertirlas por completo ante cualquier error.
- medio
El procesamiento no tiene en cuenta que Stripe puede entregar los eventos fuera de su orden de creación. Un `invoice.paid` más antiguo que llegue con retraso puede hacer retroceder `paid_until`; un `customer.subscription.deleted` que llegue con retraso puede volver a poner en `free` a un usuario que entretanto se ha reactivado.
Solución: Conciliar el estado actual de la suscripción a partir de IDs estables de Stripe, por ejemplo consultándolo en Stripe, y persistir las transiciones de estado o el momento del último evento procesado. Como mínimo, actualizar `paid_until` solo hacia adelante y no aplicar a ciegas los eventos de eliminación al estado actual del usuario.
- medio
`amount_paid / 100` supone sin comprobarlo que la moneda tiene exactamente dos decimales. Eso es incorrecto, por ejemplo, para JPY. Además, la moneda no se guarda, de modo que el importe del registro de pago no tiene una unidad inequívoca.
Solución: Guardar preferentemente los importes sin modificar en la unidad monetaria más pequeña junto con `invoice.currency`. Si se necesitan unidades monetarias principales, hacer la conversión según el exponente de cada moneda.
- medio
Falta el manejo de excepciones en una ruta asíncrona de Express 4. Ante un error de base de datos o campos faltantes, esto provoca un unhandled promise rejection que puede hacer que la aplicación se caiga.
Solución: Añade un bloque try-catch y pasa los errores a next(err), o usa una utilidad como express-async-handler.
- medio
No se valida que exista invoice.metadata.userId. Si el campo metadata o userId falta o es undefined, las consultas SQL fallan o trabajan con valores inválidos.
Solución: Antes de ejecutar las consultas a la base de datos, comprueba explícitamente que invoice.metadata e invoice.metadata.userId existan y sean válidos.
- medio
Stripe reintenta los webhooks y puede entregar el mismo evento más de una vez. Cada entrega inserta otra fila de pago, así que los informes de ingresos cuentan dos veces.
Solución: Guarda event.id (o el id de la factura) con una restricción de unicidad y omite los eventos que ya se procesaron.
Enfoque: seguridad y corrección de un plugin de importación para WooCommerce
Código enviado:
<?php
// erp-import.php — custom plugin: imports the ERP's CSV export into WooCommerce (WordPress 6, WooCommerce 9)
add_action('wp_ajax_erp_import', 'erp_import');
add_action('wp_ajax_nopriv_erp_import', 'erp_import');
function erp_import() {
global $wpdb;
$path = $_POST['file'];
$rows = array_map('str_getcsv', file($path));
foreach ($rows as $row) {
[$sku, $name, $price, $stock] = $row;
$id = $wpdb->get_var("SELECT post_id FROM {$wpdb->postmeta} WHERE meta_key = '_sku' AND meta_value = '$sku'");
if (!$id) continue;
update_post_meta($id, '_price', $price);
update_post_meta($id, '_regular_price', $price);
update_post_meta($id, '_stock', $stock);
wp_update_post(['ID' => $id, 'post_title' => $name]);
}
echo 'Imported ' . count($rows) . ' rows';
wp_die();
}
- crítico
La importación es accesible públicamente mediante `wp_ajax_nopriv_erp_import`; también en el hook autenticado faltan las comprobaciones de capability y de nonce. Por eso, usuarios anónimos o ataques CSRF pueden modificar nombres de productos, precios y existencias.
Solución: Eliminar el hook `nopriv`, comprobar antes de cualquier procesamiento una capability adecuada como `manage_woocommerce` y proteger la solicitud con `check_ajax_referer()`.
- crítico
El hook wp_ajax_nopriv_erp_import da acceso a la función de importación a visitantes no autenticados.
Solución: Eliminar el hook nopriv y comprobar el permiso mediante current_user_can('manage_options').
- crítico
La ruta de archivo de $_POST['file'] se pasa sin comprobar a file(), lo que permite path traversal y la lectura arbitraria de archivos (LFI).
Solución: Gestionar las subidas de archivos mediante $_FILES o validar estrictamente la ruta de entrada para limitarla a directorios permitidos (p. ej., wp_upload_dir()).
- crítico
Vulnerabilidad de inyección SQL, porque $sku se inserta sin sanear directamente en la consulta SQL.
Solución: Usar prepared statements con $wpdb->prepare().
- crítico
La importación está registrada para wp_ajax_nopriv, y no hay comprobación de capability ni nonce. Cualquier visitante puede activarla y sobrescribir precios, existencias y nombres de productos.
Solución: Elimina el hook nopriv, comprueba current_user_can('manage_woocommerce') y verifica un nonce con check_ajax_referer() antes de hacer nada.
- alto
La ruta proporcionada por el cliente se pasa sin comprobar a `file()`. Así pueden procesarse cualesquiera archivos locales legibles y, según `allow_url_fopen`, URLs externas o internas, lo que permite accesos no deseados a archivos y blind SSRF.
Solución: No aceptar rutas de libre elección. Usar solo IDs de subida conocidos en el servidor, comprobar la ruta canónica contra un directorio de importación fijo y permitir únicamente archivos CSV locales regulares.
- alto
`$sku` proviene del CSV y se interpola directamente en el SQL. Un valor de SKU con metacaracteres SQL puede manipular la consulta y, entre otras cosas, elegir cualquier ID de post como destino de la actualización.
Solución: Parametrizar la consulta con `$wpdb->prepare()`, por ejemplo con `meta_value = %s`, o usar la función de WooCommerce para buscar productos por SKU.
- alto
`file()` carga toda la entrada en memoria y `array_map()` genera además el array completo ya analizado. Sin límite de tamaño, un recurso remoto grande o interminable puede agotar la memoria, el tiempo de ejecución y los workers de PHP; la accesibilidad pública lo agrava.
Solución: Limitar el tamaño del archivo y el número de líneas, abrir el archivo localmente con `fopen()` y procesar los registros en streaming mediante `fgetcsv()`. Además, aplicar límites de frecuencia o un trabajo en segundo plano controlado.
- alto
Falta la protección contra CSRF (validación de nonce).
Solución: Llamar a check_ajax_referer() al comienzo de la función.
- alto
La ruta del archivo viene directamente de la solicitud y se pasa a file(). Un atacante puede leer cualquier archivo que el servidor web pueda leer, o una URL remota si allow_url_fopen está activado.
Solución: Acepta un archivo subido mediante wp_handle_upload() o lee solo de un directorio de importación fijo; nunca tomes una ruta de la solicitud.
- medio
Se presupone que cada línea tiene exactamente cuatro columnas aprovechables. Las líneas vacías o dañadas producen valores faltantes, lo que genera advertencias y puede dejar sin querer el nombre, el precio o las existencias con valores vacíos.
Solución: Antes de la desestructuración, comprobar el número de columnas y los campos obligatorios, omitir las líneas vacías y rechazar los registros defectuosos con un mensaje de error claro.
- medio
La combinación de `file()` y `str_getcsv()` analiza cada línea física por separado. Así, los campos CSV válidos con saltos de línea incrustados se dividen en varios registros defectuosos.
Solución: Leer el CSV como stream con `fgetcsv()`; esta función procesa campos multilínea correctamente entrecomillados a través de los límites entre registros.
- medio
El precio y las existencias se guardan sin comprobar como cadenas arbitrarias. Los valores no numéricos, los formatos decimales incorrectos o las existencias no permitidas pueden dañar los datos de producto y provocar cálculos incoherentes.
Solución: Validar el precio y las existencias antes de escribirlos y normalizarlos con helpers de WooCommerce como `wc_format_decimal()` y `wc_stock_amount()`; rechazar los valores inválidos o no permitidos desde el punto de vista funcional.
- medio
Los datos de WooCommerce se modifican directamente como post meta. Por eso, los estados asociados, como `_stock_status`, las tablas de búsqueda de productos y, en su caso, las cachés, no se sincronizan de forma fiable con los nuevos precios y existencias.
Solución: Cargar el producto mediante `wc_get_product()`, usar los métodos CRUD como `set_regular_price()`, `set_price()` y `set_stock_quantity()`, establecer funcionalmente el estado de existencias o `manage_stock` y, a continuación, llamar a `save()`.
- medio
La búsqueda por SKU revisa todos los metadatos de posts y no comprueba ni el tipo de post ni si el ID encontrado es realmente un producto o una variación de WooCommerce. Además, con metadatos `_sku` duplicados o ajenos a su propósito, se actualiza una coincidencia no determinista.
Solución: Usar `wc_get_product_id_by_sku()` y validar después el resultado con `wc_get_product()` y con el tipo de producto esperado; tratar los SKU duplicados como errores de importación.
- medio
Se ignoran los valores de retorno de `update_post_meta()` y `wp_update_post()`. La importación puede fallar en parte o interrumpirse y, aun así, informa como importado con éxito el número total de líneas leídas.
Solución: Registrar el éxito y el error por producto, usar `wp_update_post(..., true)`, contar solo los registros realmente actualizados y devolver una respuesta de error estructurada. Para importaciones grandes, prever un trabajo en segundo plano que pueda reanudarse.
- medio
Para cada línea del CSV se ejecutan de forma síncrona al menos una consulta de búsqueda y varias operaciones de escritura individuales. Por eso, las importaciones grandes provocan muchos roundtrips a la base de datos, pueden agotar el timeout de la solicitud y dejar un catálogo actualizado solo en parte.
Solución: Ejecutar la importación en lotes limitados como proceso en segundo plano, resolver los SKU de forma agrupada y guardar el progreso y el estado de reanudación.
- medio
file() lee todo el archivo de una vez en la memoria de trabajo, lo que provoca errores de agotamiento de memoria con archivos CSV grandes.
Solución: Procesar el archivo en streaming línea a línea con fopen() y fgetcsv().
- medio
La desestructuración del array presupone que cada línea contiene al menos 4 elementos; de lo contrario, se producen PHP warnings o errores de índice no inicializado.
Solución: Antes de desempaquetar, comprobar con count($row) si hay suficientes columnas.
- medio
Las consultas a la base de datos y las actualizaciones de posts se hacen una a una dentro de un bucle (problema N+1), lo que ralentiza mucho el tiempo de ejecución.
Solución: Dividir la importación en lotes y agrupar las consultas y actualizaciones.
- bajo
No se comprueban los errores de `file()`. Con una ruta faltante, ilegible o no soportada, `file()` devuelve `false`, y entonces `array_map()` puede lanzar un `TypeError` en las versiones actuales de PHP.
Solución: Comprobar explícitamente la apertura y la lectura, no usar las advertencias de PHP como flujo de control y, ante errores, devolver una respuesta HTTP o de `wp_send_json_error()` adecuada.
Enfoque: seguridad y corrección de un flujo de pedido y pago
Código enviado:
// routes/order.js — order endpoint of the bakery's ordering page (Node 20, Express 4, pg)
const express = require('express');
const { pool } = require('../db');
const { sendConfirmation } = require('../mail');
const router = express.Router();
router.post('/order', async (req, res) => {
const { cakeId, pickupDate, name, email, price, note } = req.body;
const cake = await pool.query(`SELECT * FROM cakes WHERE id = ${cakeId}`);
if (!cake.rows.length) return res.status(404).send('Unknown cake');
const order = await pool.query(
'INSERT INTO orders (cake_id, pickup_date, name, email, amount, note) VALUES ($1, $2, $3, $4, $5, $6) RETURNING id',
[cakeId, pickupDate, name, email, price, note]
);
sendConfirmation(email, order.rows[0].id);
res.redirect(`/pay?order=${order.rows[0].id}&amount=${price}`);
});
module.exports = router;
- crítico
cakeId se interpola directamente en la cadena SQL. Un atacante puede inyectar expresiones SQL o instrucciones adicionales y, de ese modo, leer o modificar datos o sobrecargar la base de datos.
Solución: Parametrizar también esta consulta, p. ej., `SELECT ... FROM cakes WHERE id = $1` con `[cakeId]`, y además comprobar que cakeId tenga el tipo esperado.
- crítico
Vulnerabilidad de inyección SQL por la interpolación directa de cakeId mediante un template string en la consulta SQL.
Solución: Usa una consulta SQL parametrizada: pool.query('SELECT * FROM cakes WHERE id = $1', [cakeId]).
- crítico
Es posible manipular el precio desde el cliente. El precio se toma de req.body y se guarda y procesa directamente.
Solución: Lee el precio en el servidor desde la base de datos (cake.rows[0].price) y no confíes en el valor enviado por el cliente.
- crítico
cakeId, del cuerpo de la solicitud, se interpola en la cadena SQL: inyección SQL.
Solución: Usa una consulta parametrizada: SELECT * FROM cakes WHERE id = $1.
- alto
El importe que se guarda y se pasa al flujo de pago proviene por completo de `req.body.price`. Un cliente puede introducir, para cualquier pastel, un importe manipulado, negativo o muy pequeño.
Solución: Determinar el precio exclusivamente en el servidor a partir del pastel seleccionado o de una versión de precio inmutable. Crear en el proveedor de pagos una sesión de pago del lado del servidor con ese importe y, al confirmarse el pago, volver a verificar en el servidor el importe esperado.
- alto
El pedido se crea y se envía una confirmación antes de que se haya comprobado ningún pago exitoso. Así, los procesos cancelados o no pagados a propósito aparecen como pedidos confirmados y pueden generarse a voluntad.
Solución: Crear los pedidos primero con un estado como `pending_payment`. Cambiar a `paid` solo después de una notificación del proveedor de pagos autenticada y procesada de forma idempotente, y entonces enviar la confirmación o iniciar la producción o la reserva.
- alto
Falta el manejo de errores en una ruta asíncrona de Express 4. Los errores de base de datos o de ejecución provocan rechazos de promesas no manejados.
Solución: Usa un bloque try/catch y pasa los errores con next(err), o usa un paquete como express-async-errors.
- alto
El importe se toma del cliente (price en el cuerpo de la solicitud), así que un cliente puede fijar su propio precio.
Solución: Lee el precio de la fila de cakes en el servidor e ignora cualquier valor del cliente.
- medio
El handler asíncrono no reenvía los errores. Express 4 no procesa automáticamente las promesas rechazadas de handlers `async`; por eso, los errores de base de datos o los errores síncronos del envío de correo pueden provocar solicitudes sin respuesta y rechazos no manejados.
Solución: Envolver el handler en `try/catch` y pasar los errores a `next(err)`, o usar un wrapper async consolidado. Además, configurar un manejo de errores centralizado.
- medio
El resultado de `sendConfirmation` no se espera con await ni se comprueba de ninguna otra forma si hay errores. Un rechazo de la promesa puede quedar sin manejar; al mismo tiempo, el cliente ya recibe una respuesta de éxito aunque el envío del correo pueda haber fallado.
Solución: Ejecutar el envío, tras el pago confirmado, mediante un outbox persistente o una cola de trabajos con reintentos. Como mínimo, esperar la promesa con await y registrar o manejar los errores de forma controlada.
- medio
No hay protección de idempotencia. Las repeticiones del navegador, los dobles clics o los reintentos de red generan cada vez un pedido nuevo y, en su caso, varias confirmaciones o intentos de pago.
Solución: Aceptar una idempotency key o un ID de sesión de checkout, protegerlo con una restricción de unicidad y, ante repeticiones, devolver el pedido ya existente.
- medio
pickupDate, name, email, price y note se procesan sin validación funcional ni sintáctica. Así pueden guardarse, por ejemplo, fechas de recogida pasadas o inválidas, datos de cliente faltantes y valores de campo inadecuados; además, los errores de base de datos aparecen tarde y de forma descontrolada.
Solución: Usar un esquema de solicitud con tipos, campos obligatorios, límites de longitud y formatos normalizados. Comprobar las fechas de recogida según la zona horaria, la antelación necesaria y las reglas permitidas de horario de apertura o de capacidad; no aceptar el precio como entrada del cliente.
- medio
La llamada asíncrona a sendConfirmation no se espera con await ni se capturan sus errores.
Solución: Pon await antes de sendConfirmation y maneja los posibles errores del envío de correo.
- bajo
Validación de entrada incompleta para campos como email, pickupDate, name y note.
Solución: Implementa una validación de esquema (p. ej., con Zod o express-validator) antes de procesar los datos de la solicitud.
Enfoque: corrección e integridad de datos de una función de facturación
Código enviado:
// billing/applyCredit.ts — billing module in the monolith (TypeScript, node-postgres)
import { pool } from '../db';
export async function applyCredit(customerId: string, invoiceId: string, creditCents: number) {
const inv = await pool.query('SELECT total_cents, status FROM invoices WHERE id = $1', [invoiceId]);
const balance = await pool.query('SELECT credit_cents FROM customers WHERE id = $1', [customerId]);
const available = balance.rows[0].credit_cents;
if (creditCents > available) throw new Error('Not enough credit');
const newTotal = inv.rows[0].total_cents - creditCents;
await pool.query('UPDATE invoices SET total_cents = $1 WHERE id = $2', [newTotal, invoiceId]);
await pool.query('UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2', [creditCents, customerId]);
if (newTotal <= 0) {
await pool.query("UPDATE invoices SET status = 'paid' WHERE id = $1", [invoiceId]);
}
return newTotal * 1.19 / 100;
}
- crítico
Falta una transacción de base de datos y un bloqueo de filas. Con solicitudes en paralelo pueden producirse condiciones de carrera (p. ej., doble gasto del saldo) y actualizaciones incompletas en caso de error.
Solución: Usa un cliente del pool con BEGIN/COMMIT y usa SELECT FOR UPDATE para bloquear y actualizar las filas de forma atómica.
- alto
Las tres actualizaciones relacionadas no se ejecutan en una transacción de base de datos. Si falla el cargo al saldo del cliente o el cambio de estado, la factura puede quedar ya reducida sin que el saldo se haya cargado correctamente o sin que se haya establecido el estado.
Solución: Obtener un cliente dedicado del pool y ejecutar todas las comprobaciones y actualizaciones entre BEGIN y COMMIT; ante cualquier error, usar ROLLBACK.
- alto
La factura primero se lee y después se sobrescribe con un valor calculado en términos absolutos. Dos llamadas en paralelo pueden leer el mismo valor de partida y luego sobrescribirse mutuamente; aun así, ambos cargos al saldo se realizan, mientras que solo un abono queda reflejado por completo en la factura.
Solución: Bloquear la factura afectada dentro de la misma transacción con SELECT ... FOR UPDATE o modificar el importe de forma atómica mediante UPDATE ... SET total_cents = total_cents - $1 con las condiciones adecuadas.
- alto
La comprobación y el cargo del saldo del cliente no son atómicos. Llamadas en paralelo pueden ver ambas la misma cobertura disponible y luego reducir el saldo por debajo de cero.
Solución: Bloquear el registro del cliente dentro de una transacción o usar un UPDATE condicional, por ejemplo UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents, y exigir exactamente una fila devuelta.
- alto
No se comprueba si la factura pertenece al cliente indicado. Así, el saldo de un cliente puede aplicarse a cualquier factura designada mediante invoiceId.
Solución: Consultar y actualizar la factura y el cliente a través de la relación de propiedad, por ejemplo con WHERE invoices.id = $1 AND invoices.customer_id = $2; si no coinciden, interrumpir.
- alto
El crédito que se aplica no se limita al importe pendiente de la factura. Si creditCents es mayor que total_cents, se guarda un importe de factura negativo y se consume saldo del cliente en exceso.
Solución: Permitir solo importes hasta el valor pendiente de la factura o determinar el importe realmente usado como min(creditCents, total_cents) y cargar únicamente ese importe al saldo del cliente.
- alto
No se rechazan los valores negativos, no enteros o no representables de forma segura. En particular, un valor negativo de creditCents aumenta el importe de la factura y, al mismo tiempo, por la resta de un valor negativo, el saldo del cliente.
Solución: Antes de acceder a la base de datos, exigir Number.isSafeInteger(creditCents) && creditCents > 0; tratar los importes de dinero en todo momento como valores enteros en centavos.
- alto
El estado leído de la factura se ignora por completo. Así, el saldo puede aplicarse también a facturas ya pagadas, anuladas o que por otra razón ya no se pueden modificar; un comprobante ya pagado puede volverse negativo por ello.
Solución: Definir explícitamente los estados de partida permitidos y comprobarlos de forma atómica en la condición del UPDATE, por ejemplo AND status = 'open'. Si no hay coincidencia, interrumpir la operación.
- alto
Acceso a balance.rows[0] e inv.rows[0] sin comprobación previa. Si no se encuentra un cliente o una factura, la aplicación se cae con un TypeError no manejado.
Solución: Comprueba inv.rows.length y balance.rows.length antes de acceder y lanza un mensaje de error explícito.
- alto
Falta la validación de creditCents frente a valores negativos. Un valor negativo anula la comprobación (creditCents > available) y provoca ajustes erróneos del saldo o de la factura.
Solución: Asegúrate de que creditCents sea un entero positivo mayor que 0.
- alto
Las lecturas y las tres actualizaciones se ejecutan fuera de una transacción y sin bloqueos de fila. Dos llamadas concurrentes pueden pasar ambas la comprobación de crédito y gastar el mismo crédito dos veces, y una caída entre las actualizaciones deja incoherentes la factura y el saldo de crédito.
Solución: Ejecuta todo en una transacción sobre un único cliente, bloquea las filas con SELECT ... FOR UPDATE y haz commit solo después de que todas las actualizaciones tengan éxito.
- alto
La función nunca comprueba que la factura pertenezca al cliente ni que siga abierta. El crédito de un cliente puede aplicarse a la factura de otro cliente, o a una factura que ya está pagada.
Solución: Selecciona la factura con WHERE id = $1 AND customer_id = $2 AND status = 'open' y falla si no se devuelve ninguna fila.
- medio
No se comprueba la existencia de la factura y del cliente. Con IDs desconocidos, los accesos a rows[0] provocan errores en tiempo de ejecución en lugar de un error funcional controlado; además, ambas consultas se ejecutan innecesariamente antes de que esto se note.
Solución: Comprobar rowCount o rows.length en ambas consultas y lanzar un error not-found definido; integrar la comprobación en la transacción y, en lo posible, en una consulta relacional.
- medio
El valor de retorno no corresponde ni al importe en centavos guardado ni a una simple conversión a la unidad monetaria principal: suma a tanto alzado un 19 por ciento y usa aritmética de coma flotante. Así, quien llama puede recibir un valor distinto, en lo fiscal y en el redondeo, del resto de factura realmente guardado.
Solución: Devolver sin cambios el importe restante en centavos o definir un valor de retorno claramente tipado. Si el cálculo de impuestos es funcionalmente necesario, tomar el tipo impositivo y la regla de redondeo de los datos de la factura y calcular con aritmética entera o decimal.
- medio
Uso de aritmética de coma flotante IEEE 754 (newTotal * 1.19 / 100) para cálculos financieros. Esto provoca errores de precisión y de redondeo.
Solución: Calcula en todo momento en centavos con enteros (BigInt/Math.round) o usa una biblioteca de aritmética decimal exacta.
- bajo
Un comando UPDATE separado para el estado de la factura genera roundtrips innecesarios a la base de datos.
Solución: Combina la actualización de total_cents y status en una sola consulta UPDATE.
Enfoque: corrección de un análisis de cribado para una revisión sistemática
Código enviado:
# screening/agreement.py — compares two screeners' include/exclude decisions (Python 3.12, pandas)
import pandas as pd
a = pd.read_csv('screener_a.csv') # columns: record_id, decision ('include'/'exclude')
b = pd.read_csv('screener_b.csv')
merged = a.merge(b, on='record_id', suffixes=('_a', '_b'))
agree = (merged.decision_a == merged.decision_b).mean()
p_inc_a = (merged.decision_a == 'include').mean()
p_inc_b = (merged.decision_b == 'include').mean()
expected = p_inc_a * p_inc_b + (1 - p_inc_a) * (1 - p_inc_b)
kappa = (agree - expected) / (1 - expected)
conflicts = merged[merged.decision_a != merged.decision_b]
excluded = merged[merged.decision_a == 'exclude']
print(f'Records screened: {len(a)}')
print(f"Cohen's kappa: {kappa:.2f}")
excluded.record_id.to_csv('excluded.csv', index=False)
conflicts.to_csv('conflicts.csv', index=False)
- alto
El inner join predeterminado elimina todos los valores de record_id que solo aparecen en uno de los dos archivos. Así, el kappa y los conflictos se calculan solo para la intersección, sin hacer visibles los cribados que faltan. Al mismo tiempo, “Records screened” en la línea 18 informa la longitud de a en lugar de la intersección realmente analizada.
Solución: Usar un outer join con indicador de merge, comparar explícitamente los conjuntos de IDs e informar por separado de las decisiones que faltan o tratarlas como errores de datos. Para cada indicador, mostrar el denominador realmente usado.
- alto
No se comprueba la unicidad de record_id. Los IDs duplicados provocan en el merge un producto cartesiano many-to-many y ponderan varias veces estudios individuales, lo que distorsiona la concordancia, las prevalencias, el kappa y los archivos de salida.
Solución: Antes del merge, comprobar en ambos archivos que record_id no sea nulo y sea único, e interrumpir si hay duplicados. Además, usar merge(..., validate='one_to_one').
- alto
Los valores de decisión no se validan. Los valores faltantes, las erratas, las mayúsculas y minúsculas u otras categorías se tratan implícitamente como “exclude” al calcular la prevalencia de include, mientras que la concordancia observada compara valores exactos. Con ello, el cálculo ya no corresponde a un kappa de Cohen binario y puede dar resultados contradictorios.
Solución: Normalizar decision de forma controlada antes del análisis y asegurarse de que cada valor sea exactamente 'include' o 'exclude'. Tratar por separado los valores faltantes o desconocidos como errores de datos o cribado incompleto.
- alto
excluded contiene todos los registros excluidos por el revisor A, incluidos los conflictos en los que el revisor B decidió “include”. Así, esos registros se escriben a la vez en excluded.csv y en conflicts.csv. Si excluded.csv debe representar los resultados excluidos de forma definitiva, los conflictos sin resolver pueden eliminarse erróneamente de la revisión.
Solución: Sin una regla de prioridad documentada, seleccionar solo las exclusiones coincidentes, es decir, (decision_a == 'exclude') & (decision_b == 'exclude'). Mantener los conflictos exclusivamente en conflicts.csv hasta la decisión por consenso.
- alto
Filtrado erróneo de los estudios excluidos: 'excluded' tiene en cuenta únicamente la decisión del revisor A ('merged.decision_a == "exclude"'). Si hay un conflicto (el revisor A excluye, el revisor B incluye), el estudio se considera erróneamente excluido.
Solución: Exportar exclusiones solo cuando ambos revisores hayan elegido 'exclude' de forma coincidente (p. ej., '(merged.decision_a == "exclude") & (merged.decision_b == "exclude")'), o esperar a que se resuelva el conflicto.
- alto
excluded.csv contiene cada registro que el revisor A excluyó, incluidos los conflictos en los que el revisor B lo incluyó. Esos registros se descartan antes de la discusión del conflicto, que es exactamente la exclusión falsa que el protocolo debe evitar.
Solución: Excluye solo los registros que ambos revisores excluyeron: merged[(merged.decision_a == 'exclude') & (merged.decision_b == 'exclude')]; envía primero cada conflicto a resolución.
- medio
Si ambos revisores usan exclusivamente la misma categoría, expected es igual a 1 y el denominador del kappa es igual a 0. El resultado es NaN o puede generar una advertencia de división por cero; la salida formateada “nan” no explica que el kappa no está definido matemáticamente. También una intersección analizada vacía produce indicadores NaN sin valor informativo.
Solución: Antes de la división, comprobar si existen decisiones válidas emparejadas y si 1 - expected es mayor que 0. En los casos degenerados, indicar explícitamente el kappa como “no definido” e informar de las frecuencias subyacentes.
- medio
Posible división por cero en el kappa de Cohen cuando el valor esperado por azar 'expected' es igual a 1 (p. ej., cuando ambos revisores eligen la misma categoría para el 100% de los registros).
Solución: Antes del cálculo, interceptar si '1 - expected == 0' y, en ese caso, asignar un valor definido (p. ej., 1.0 o NaN).
- medio
Descarte silencioso de registros por el inner join predeterminado. Si el revisor A y el revisor B evaluaron conjuntos distintos de 'record_id', no se informan las discrepancias en los estudios procesados. Además, 'len(a)' en la salida de consola no corresponde entonces al número de estudios realmente emparejados.
Solución: Comprobar si se cumple 'len(a) == len(b) == len(merged)', o hacer un outer join para mostrar explícitamente los registros evaluados de forma incompleta.
- medio
El merge interno descarta silenciosamente los registros que solo un revisor ha decidido, y el recuento impreso usa len(a). Los registros sin cribar desaparecen tanto de la concordancia como de las cifras PRISMA.
Solución: Haz el merge con how='outer', indicator=True, y falla o informa cuando algún registro no tenga decisión de alguno de los dos revisores.
- bajo
Falta la limpieza de entradas y el manejo de valores faltantes en la columna 'decision'. Las mayúsculas y minúsculas, los espacios en blanco o los valores NaN provocan comparaciones erróneas.
Solución: Limpiar los valores de la columna antes de la comparación (p. ej., con '.str.strip().str.lower()') y garantizar la seguridad de tipos de datos.
Se muestran todos los hallazgos confirmados con su solución, tal como los escribieron los miembros; el razonamiento de los verificadores se reduce a su veredicto. Los duplicados no se fusionan, así que un mismo problema puede aparecer más de una vez cuando varios miembros lo reportan. El código, el enfoque y los hallazgos propios de Claude se enviaron en inglés, y los miembros escribieron sus hallazgos en alemán; aquí, el enfoque y todos los hallazgos están traducidos al español, y el código se muestra tal como se envió.
Cinco encargos de ideas de distintos ámbitos. ChatGPT y Gemini trabajan en tres líneas, Claude añade una idea, y ambos miembros evalúan cada idea de forma anónima (1–10 cada uno, hasta 20 puntos). Elige uno.
Tema: Ideas para que un desarrollador en solitario convierta a más lectores de dos artículos del blog bien posicionados en Google en registros de prueba de una herramienta de facturación para freelancers
Contexto enviado: Herramienta de facturación para freelancers, USD 19 al mes, prueba gratuita de 14 días, 30 clientes de pago después de 5 meses. Los registros llegan sobre todo de dos artículos del blog que posicionan en Google (cómo escribir una factura como freelancer; cómo reclamar pagos atrasados). Alrededor del 12% de las pruebas se convierten. El desarrollador tiene un trabajo de día y unas 10 horas a la semana para el producto. OBLIGATORIO: nada de publicidad de pago. OBLIGATORIO: como máximo 3 horas a la semana para esto.
- 1
Sustituir el reloj de 14 días por tres envíos reales
Experimenta con una prueba que termine tras tres facturas o reclamaciones de pago enviadas, en lugar de tras 14 días naturales. Esto rompe deliberadamente el supuesto flexible de que una prueba limitada en el tiempo es lo adecuado: puede que los freelancers no facturen durante una ventana arbitraria de dos semanas, así que la prueba actual puede expirar antes de que el producto demuestre su valor. Mantén sin cambios el plan mensual de $19 y compara la conversión de activación a pago por cohorte.
- 2
Completar la tarea dentro del artículo
Integra un pequeño generador de facturas en “cómo escribir una factura como freelancer”: los lectores introducen cliente, importe, fecha de vencimiento y condiciones de pago, y luego ven una vista previa terminada. “Enviar o guardar esta factura” crea una prueba con esos datos ya cargados, lo que elimina la distancia entre aprender y hacer. Constrúyelo en partes semanales de un máximo de tres horas y luego mantén el mantenimiento cerca de cero.
- 3
Convertir el artículo sobre reclamaciones en una consola de recuperación
Como sustitución en un solo paso del generador de facturas integrado, deja que los lectores introduzcan un importe vencido y una fecha de vencimiento para generar una secuencia de reclamación de tres mensajes con fechas. Al iniciar una prueba se guarda el deudor, se programan los mensajes y se abre el primer borrador listo para enviar. Esto conserva el patrón más sólido —un resultado útil antes del registro— y a la vez se ajusta a la intención del segundo artículo.
- 4
Poner el momento de conversión en el calendario del deudor
Ofrece en el artículo sobre pagos atrasados un archivo .ics generado con recordatorios para la fecha de vencimiento y seguimientos escalonados los días 1, 7 y 14. Cada evento del calendario contiene un deep link que abre el flujo de reclamación correspondiente con las fechas ya rellenadas, y trae de vuelta al lector cuando el problema es real y no mientras solo se está informando. No requiere captar el correo electrónico y puede funcionar sin supervisión.
- 5
Plan gratuito permanente para un cliente en lugar de periodo de prueba
Esta idea rompe la restricción flexible de la versión de prueba de 14 días y la sustituye por un plan freemium para exactamente un cliente activo. Los freelancers usan el producto de forma gratuita y permanente para su primer cliente y pasan sin fricciones a la tarifa plana de 19 dólares en cuanto se suma un segundo cliente.
- 6
Dirigir a los lectores según su problema inmediato
Sustituye los banners de prueba genéricos por tres opciones integradas en el texto, como “Necesito mi primera factura”, “Facturo con regularidad” y “Un cliente ya va con retraso”. Cada opción abre un estado de onboarding correspondiente en lugar de la misma página de inicio, y los IDs de las secciones del artículo pueden preseleccionar valores predeterminados razonables. Mide la activación completa de la prueba, no solo los clics en el CTA, y prueba una ruta por semana.
- 7
Publicar tres renovaciones forenses de facturas
Con permiso, convierte tres facturas anonimizadas de clientes en casos de estudio estáticos de antes y después que muestren exactamente qué cambió y por qué. Inserta cada renovación junto al consejo correspondiente en el artículo bien posicionado, con un CTA que abra la misma estructura corregida como plantilla de prueba editable. La evidencia concreta de una pequeña base de clientes puede ser más creíble que los testimonios generales.
- 8
Dejar que los lectores lleven su progreso entre ambos artículos
Guarda localmente en el navegador la moneda elegida por el lector, la etapa de la factura y la fecha de vencimiento, y luego usa ese estado cuando pase de un artículo al otro. Quien haya creado un plan de factura puede ver más tarde un aviso contextual como “Tu factura ya tiene 3 días de retraso—abre el seguimiento preparado”, con el onboarding de la prueba ya rellenado. Esto crea un recorrido ligero por los dos artículos sin requerir una cuenta ni una producción continua de contenido.
- 9
Configurador interactivo de cartas de reclamación
Complementa el artículo sobre el seguimiento de pagos vencidos con un generador de cartas de reclamación escalonadas. Tras introducir el texto se genera la plantilla, combinada con el CTA para configurar en el acceso de prueba recordatorios de pago automáticos para futuras facturas.
- 10
Magic link de envío inmediato sin registro previo
Mutación del generador integrado en el contenido: el lector introduce los datos de la factura directamente en el artículo del blog y hace clic en Enviar factura ahora mismo. El sistema crea en segundo plano y sin fricciones una cuenta de prueba y envía el correo directamente; la contraseña se establece solo después.
- 11
Generador de facturas en vivo directamente en el artículo del blog
Integra una herramienta de formulario sencilla e interactiva directamente en el artículo sobre cómo escribir facturas. Los lectores escriben los datos de su factura y pueden descargar al instante el PDF terminado de forma gratuita. Un botón destacado ofrece enviar la factura digitalmente con un clic y hacer el seguimiento del estado del pago en el acceso de prueba de 14 días.
- 12
Reclamación única de pago por uso en lugar de suscripción mensual
Esta idea rompe la restricción flexible del modelo de suscripción SaaS puro de 19 dólares al mes. Los lectores del artículo sobre pagos atrasados pueden hacer enviar, por una tarifa única de 5 dólares, una carta de reclamación jurídicamente segura con enlace de seguimiento, y la tarifa se descuenta por completo si más adelante contratan la suscripción.
- 13
Plantilla que se abre en la herramienta
Ofrece la plantilla de factura del artículo como una factura lista para usar en la herramienta: un clic abre una cuenta de prueba ya rellenada en lugar de descargar un archivo.
- 14
Exit intent orientado al problema con secuencia de correos automatizada
Implementa un popup de exit intent en el artículo sobre pagos atrasados que ofrezca una plantilla de correo de emergencia para clientes morosos a cambio de la dirección de correo electrónico. Después, una secuencia automatizada de tres correos explica de forma pasiva cómo los flujos de trabajo automatizados reducen los retrasos en los pagos y enlaza al acceso de prueba.
Tema: Ideas para que una pequeña agencia digital convierta la reconstrucción puntual de una tienda en un contrato recurrente de mantenimiento que el cliente realmente quiera
Contexto enviado: Agencia de 4 personas. El cliente vende unos 1,800 productos de muebles en Alemania, Austria y Suiza, tiene 3 empleados y ningún desarrollador propio, y factura unos EUR 1.2 millones al año. La antigua tienda WooCommerce autoalojada tenía 31 plugins y sufrió dos incidentes de seguridad el año pasado; el cliente quiere menos mantenimiento y menos emergencias. Un ERP local exporta los datos de producto como CSV. Presupuesto de la reconstrucción: EUR 25,000. OBLIGATORIO: nada de lock-in; el cliente debe poder irse en cualquier momento con todos los datos y accesos. OBLIGATORIO: nada de contrataciones adicionales en la agencia.
- 1
Ruptura del presupuesto: la operación antes que el brillo del lanzamiento
Esta idea rompe deliberadamente la restricción flexible del presupuesto de reconstrucción de 25,000 EUR: se ofrecen, por ejemplo, 22,000 EUR para un lanzamiento deliberadamente austero más 12,000 EUR para un primer año de operación vinculante. A cambio, se eliminan del proyecto inicial las funciones deseables pero prescindibles; en su lugar se financian el endurecimiento de la importación, pruebas de restauración, monitorización y mejoras mensuales. El mayor volumen total vale la pena porque el cliente no vuelve a comprar una tienda aparentemente terminada cuyos costos reales de operación solo se hacen visibles tras el lanzamiento; todos los accesos, datos y resultados de trabajo siguen siendo transferibles en cualquier momento.
- 2
Guardián de productos CSV
Antes de cada importación desde el ERP, un pipeline automatizado revisa el CSV en busca de precios faltantes, duplicados, variantes inválidas, errores de imagen, lógica fiscal DACH y cambios de existencias sospechosos. El contrato mensual de mantenimiento incluye el mantenimiento de las reglas, la supervisión de las importaciones y un informe de errores comprensible para los tres empleados. Esto convierte el mantenimiento técnico en un beneficio de negocio inmediato: menos productos incorrectos, menos consultas y menos compras abandonadas.
- 3
Dividendo de fiabilidad
El cliente paga una cuota base moderada por supervisión y mantenimiento; un importe trimestral adicional solo vence si se alcanzaron objetivos de fiabilidad acordados, como importaciones exitosas, restauración probada y tiempos de respuesta. Las incidencias evitables causadas por la agencia generan crédito de servicio en lugar de horas de emergencia facturables. Este modelo orienta los incentivos económicos hacia la prevención y le quita al cliente el miedo de que la agencia se beneficie de los problemas.
- 4
Carta de mantenimiento lista para la salida
El contrato de mantenimiento se vende deliberadamente como un producto anti-lock-in: monitorización, actualizaciones, copias de seguridad, revisiones de seguridad y dos cambios pequeños al mes por unos 1,200–1,500 EUR. Todas las cuentas están a nombre del cliente, y el código y los scripts de importación, en su repositorio; además, cada mes recibe documentación, una exportación de datos y una carpeta de traspaso lista para rescindir. Así, el cliente paga por una capacidad operativa demostrable en lugar de por la dependencia.
- 5
Tren de releases estacional
En lugar de tickets de soporte arbitrarios, hay cuatro releases de comercio planificables al año, por ejemplo para muebles de jardín, liquidación de fin de verano, Black Week y Navidad. El contrato de mantenimiento incluye por cada release un pequeño paquete de UX o merchandising, pruebas de regresión y el mantenimiento técnico entre una y otra. Esto le da al cliente una evolución visible y permite agrupar el esfuerzo de la agencia de cuatro personas.
- 6
La prueba de huida trimestral
Una vez por trimestre, la agencia entrega una exportación completa de los datos de productos, clientes, pedidos y contenidos, y realiza en un entorno de pruebas neutral un rearranque documentado. Con ello se paga precisamente la salida demostrada con regularidad: la lista de accesos, el protocolo de restauración y el manual de traspaso pertenecen al cliente. Así, el criterio obligatorio de no lock-in pasa de ser una objeción a un argumento de venta inusual para el contrato de mantenimiento.
- 7
Carta de mantenimiento más bolsa de crecimiento
Como pequeña mutación de la Carta de mantenimiento lista para la salida, las horas de cambios incluidas no se planifican de forma fija, sino que se reparten cada mes entre operación, calidad de datos y mejoras de conversión; el volumen no usado se traslada como máximo un trimestre. Un comité conjunto de 30 minutos decide su uso según los riesgos y las oportunidades de ingresos. El contrato sigue estando listo para la salida, pero se siente menos como un seguro y más como un equipo digital externo flexible.
- 8
Contrato de sincronización con el ERP y seguridad del catálogo
La agencia asume la supervisión y el mantenimiento continuos de la interfaz entre el CSV del ERP local y la tienda online. Las importaciones de datos erróneas, las variantes de muebles faltantes o los precios incorrectos se interceptan automáticamente antes de publicarse. Esto le quita por completo al equipo de 3 personas del cliente la carga operativa del mantenimiento de datos.
- 9
Tarifa plana de enriquecimiento de datos de producto con IA
Mutación de la idea de la interfaz con el ERP: la agencia no solo mantiene la importación CSV, sino que enriquece automáticamente los datos brutos mediante scripts de IA con atributos estructurados, textos SEO e indicaciones de plazos de entrega específicas para DACH. Esto le ahorra al cliente trabajo manual de mantenimiento y aumenta la visibilidad en el mercado de muebles sin nuevas contrataciones en la agencia.
- 10
Contrato de mantenimiento con regresión visual basada en CI/CD
En lugar de actualizaciones arriesgadas en vivo, la agencia configura un pipeline de staging que comprueba de forma automatizada, visual y funcionalmente, las actualizaciones mensuales de plugins. El cliente recibe un informe mensual de transparencia y tiempos de respuesta garantizados ante vulnerabilidades de seguridad. Esto garantiza una estabilidad absoluta sin las emergencias de antes.
- 11
Pulido trimestral de conversión y UX
Como complemento al mantenimiento básico, el contrato incluye contingentes fijos de horas para optimizar las funciones del checkout y la presentación de las variantes de muebles. La agencia analiza cada mes el comportamiento de los usuarios en la región DACH e implementa ajustes de alta rentabilidad. Así, el contrato pasa de ser un mero factor de costo a un motor de ingresos.
- 12
Garantía de actualización segura y rollback instantáneo
Mutación del contrato de mantenimiento con CI/CD: el contrato se centra únicamente en un SLA garantizado de cero tiempo de inactividad, con restauración automatizada de snapshots en un plazo de 15 minutos ante incidentes. Esto aborda directamente el miedo del cliente tras los dos incidentes de seguridad, con un esfuerzo manual continuo mínimo.
- 13
Paquete de crecimiento con participación en ingresos en lugar de presupuesto fijo
Rompe el supuesto flexible de un presupuesto rígido de reconstrucción única de 25,000 EUR: los costos de la reconstrucción se reducen a 10,000 EUR, vinculados a un contrato mensual con una pequeña participación en los ingresos adicionales. Vale la pena porque el cliente reduce el riesgo de inversión y la agencia participa directamente en el crecimiento de la tienda de 1.2 millones de EUR.
- 14
Servicio de mantenimiento con arquitectura headless
Rompe la restricción flexible de una configuración monolítica clásica (como WooCommerce estándar): el frontend se desacopla del backend, de modo que las vulnerabilidades de los plugins ya no pueden atacar directamente el sitio web. Vale la pena porque las emergencias se eliminan estructuralmente y el cliente, gracias a un stack de código abierto y a acceso completo a Git, sigue siendo portable en cualquier momento.
- 15
Informe mensual de mantenimiento de una página
Un informe mensual de una página con disponibilidad, velocidad de carga, actualizaciones aplicadas e incidentes evitados, para que el cliente vea lo que paga con el contrato de mantenimiento.
Tema: Ideas para que una panadería local consiga más pedidos anticipados de pasteles por encargo a través de su nueva página de pedidos online, sin anuncios de pago
Contexto enviado: Panadería con 6 empleados en una ciudad alemana de 40,000 habitantes. Los pasteles por encargo y los pedidos anticipados tienen el mejor margen. Una nueva página de pedidos online (elección de pastel, fecha de recogida, pago por adelantado) se lanza el próximo mes; hasta ahora los pedidos llegaban solo por teléfono y correo electrónico. El perfil de empresa de Google tiene 4.7 estrellas con 120 reseñas. El dueño tiene poco tiempo, así que las ideas deben funcionar con un máximo de 2 horas a la semana. OBLIGATORIO: nada de publicidad de pago este trimestre. OBLIGATORIO: nada de personal adicional.
- 1
El piloto automático anual de cumpleaños
Al finalizar la compra, los clientes pueden indicar de forma voluntaria la ocasión y el mes para recibir un recordatorio al año siguiente. Un correo automatizado 21 días antes lleva a la página de pedidos ya rellenada; así, cada pedido genera un encargo futuro, sin captación continua y con un consentimiento limpio.
- 2
Huecos reales para pasteles en lugar de publicaciones genéricas
La página de pedidos muestra los huecos de producción que realmente quedan en las próximas cuatro semanas, por ejemplo “Todavía es posible hacer 2 pasteles personalizados para el sábado”. Una publicación semanal en el perfil de empresa de Google enlaza directamente a esta vista; la actualización y la publicación requieren juntas como máximo 20 minutos y generan una urgencia creíble sin descuentos.
- 3
El pastel viaja como su propio soporte publicitario
Cada pastel recogido lleva una pequeña tarjeta con “Volver a pedir o personalizar este pastel” y un código QR a la variante correspondiente. La tarjeta se coloca a la vista al cortar el pastel, de modo que justo los invitados presentes en el cumpleaños o la boda descubren cómo hacer el pedido; un juego de tarjetas creado una sola vez casi no supone esfuerzo semanal.
- 4
Consulta de pasteles única para el lanzamiento
El primer sábado después del lanzamiento hay, durante cuatro horas, una consulta abierta sobre pasteles: los visitantes eligen sabor y estilo con tarjetas de muestra y luego hacen ellos mismos su pedido mediante códigos QR disponibles en el lugar. Esto rompe deliberadamente la restricción flexible de un máximo de dos horas de dedicación esa semana; el esfuerzo adicional vale la pena porque, al mismo tiempo, se generan pedidos reales, problemas de uso observados y fotos o preguntas de clientes reutilizables, sin personal adicional ni publicidad de pago.
- 5
Socios de ocasión en lugar de influencers
Espacios de juego infantil, fotógrafos, floristas, lugares para bodas y locales de asociaciones reciben cada uno un pequeño expositor con código QR que lleva a una selección de pasteles preconfigurada para su ocasión. A cambio, la panadería menciona a estos socios en una página local de recomendaciones; bastan cinco solicitudes dirigidas al mes, y no hay comisiones ni alcance pagado.
- 6
Rotación de pasteles para oficinas y asociaciones
Oficinas, consultorios y asociaciones locales reciben una página en la que pueden reunir varios cumpleaños o fechas recurrentes y pagarlos por adelantado uno tras otro. Las rotaciones trimestrales, una vez configuradas, convierten ocasiones sueltas en pedidos en serie planificables; el contacto puede limitarse a dos organizaciones por semana.
- 7
Consulta híbrida de pasteles en la tableta de venta
Rompe deliberadamente la restricción flexible 'Pedidos exclusivamente online', ofreciendo los viernes 1 hora de asesoramiento en el local, en la que los pedidos se introducen juntos en la tableta. Vale la pena porque los clientes indecisos y mayores se familiarizan paso a paso con el nuevo sistema online.
- 8
Las reseñas se convierten en ayuda para decidir
Como pequeña recombinación del material más sólido disponible, doce frases significativas de las 120 reseñas de Google se vinculan con estilos de pastel adecuados, cada una con un enlace directo para pedir. Así, las 4.7 estrellas no solo se muestran como señal de confianza, sino que ayudan a elegir el producto; tras la configuración inicial, la página casi no requiere mantenimiento.
- 9
Expositor de pasteles de muestra con deep links a la tienda
Una galería física de fotos de los pasteles más bonitos en la zona de venta incluye en cada imagen un código QR específico que abre en la tienda online justo ese modelo de pastel, ya preseleccionado. Mutación de la idea 1: vincular la exhibición en el local con un deep link directo en la tienda online.
- 10
Optimización del perfil de Google y enlaces de reseña automatizados
Al sólido perfil de Google (4.7 estrellas) se le añade el botón oficial 'Pedir online' y se alimenta cada semana con una foto de pasteles actuales. Al recoger, los clientes reciben por correo una plantilla con un enlace a la página de reseñas y de nuevos pedidos. Lleva menos de 30 minutos a la semana.
- 11
Gancho con código QR en tickets de caja y bolsas de pan
En cada ticket de caja y en los envases se imprime un código QR llamativo que lleva directamente al configurador de pasteles online ('Planifica online el pastel soñado para tu fiesta'). Esto convierte a la clientela de paso diaria en clientes digitales de pedidos anticipados, sin esfuerzo adicional en la venta.
- 12
Alianza B2B con lugares de eventos locales
Se colocan expositores y folletos con un código de reserva directo para el sitio web en restaurantes locales, graneros para eventos y organizadores de bodas. Los clientes que celebran reservan su pastel directamente online, mientras que el lugar recibe una pequeña compensación o una recomendación recíproca.
- 13
Calendario de cumpleaños para guarderías y escuelas
Cooperación con jardines de niños locales mediante folletos informativos para los comités de padres, que incluyen un código de descuento fijo para pasteles temáticos infantiles. Mutación de la idea 3: en lugar de socios B2B genéricos, se aborda de forma dirigida y automatizada la ocasión frecuente del cumpleaños infantil.
- 14
Mini taller mensual de pasteles temáticos
Rompe deliberadamente la restricción flexible 'máximo 2 horas de dedicación por semana', ya que una vez al mes se realiza un taller de 4 horas. Vale la pena porque los participantes actúan como embajadores de la marca, generan contenido entusiasta en redes sociales y, con toda seguridad, hacen sus pedidos posteriores a través de la tienda online.
- 15
Enlace de pedido en cada caja de pastel
Imprime en las cajas de pastel y en los tickets un código QR que lleve a la página de pedidos, para que cada cliente que ya compra un pastel pueda volver a pedir para el próximo cumpleaños sin llamar.
Nota de Kirat para Claude: La mejor idea rompedora de reglas está solo en el puesto 4: “Consulta de pasteles única para el lanzamiento” — rompe deliberadamente una restricción flexible. Formula una vez su versión más sólida antes de descartarla.
Tema: Ideas para reducir en dos trimestres los incidentes de producción causados por el módulo de facturación, sin extraerlo a un servicio separado
Contexto enviado: Equipo de 8 ingenieros. Un monolito de TypeScript de unas 60,000 líneas, una base de datos Postgres, despliegues varias veces al día. El módulo de facturación cambia cada semana y causó 5 de los últimos 8 incidentes de producción, sobre todo porque otros módulos leen y escriben directamente en las tablas de facturación. Nadie en el equipo ha operado un sistema distribuido en producción. La dirección quiere menos incidentes en dos trimestres. OBLIGATORIO: nada de reescribir el módulo de facturación. OBLIGATORIO: el trabajo de funcionalidades en facturación continúa cada semana.
- 1
Firewall de base de datos alrededor de las tablas de facturación
Crea roles de Postgres separados para las rutas de código de facturación y de no facturación del monolito, y luego revoca al rol general de la aplicación las escrituras directas en las tablas de facturación. Canaliza todas las mutaciones a través de un pequeño conjunto de procedimientos almacenados o funciones de transacción revisados, añadiendo primero un registro de auditoría temporal para descubrir y migrar a quienes llaman sin detener el trabajo semanal de funcionalidades.
- 2
Invariantes financieros ejecutables
Codifica una lista corta de invariantes —como facturas finalizadas inmutables, asientos contables cuadrados, creación idempotente de cargos y transiciones de estado válidas— como restricciones de base de datos donde sea seguro y como sondas programadas en producción donde no lo sea. Ejecuta las mismas sondas en CI contra fixtures anonimizados con forma de producción, convirtiendo el conocimiento de los incidentes en alarmas permanentes en lugar de en una ampliación general de las pruebas.
- 3
Repetición de incidentes como prueba de fuego para cada release
Convierte los cinco incidentes de facturación en escenarios de repetición deterministas usando formas de consulta capturadas y filas saneadas, y luego exige que cada cambio en facturación los supere. Añade pruebas generativas que permuten reintentos, eventos duplicados, orden de transacciones y fallos parciales en torno a esos mismos escenarios, apuntando al entorno del fallo en lugar de intentar una cobertura exhaustiva del monolito.
- 4
Aplicar en sombra el límite de facturación
Como mutación de menor riesgo del firewall de base de datos, mantén al principio los permisos actuales, pero registra cada consulta que toque las tablas de facturación con su módulo, el punto de llamada y el ID de transacción. Después de cuatro semanas, convierte las escrituras inesperadas en fallos de CI y luego en errores de producción, módulo por módulo; esto sustituye un cambio inmediato de permisos por una aplicación escalonada.
- 5
Centralita del radio de impacto de la facturación
Pon los comportamientos de facturación arriesgados —no el módulo entero— detrás de interruptores de apagado del lado del servidor y despliegues porcentuales, con dashboards vinculados a anomalías en facturas, pagos y conciliación. Cada funcionalidad semanal se lanza con una ruta de desactivación probada, para que los responsables de guardia puedan desactivar el nuevo comportamiento sin revertir despliegues no relacionados del monolito ni deshacer migraciones de esquema.
- 6
Encapsulación del esquema de Postgres y Row Level Security
Aísla las tablas de facturación en un esquema de Postgres propio (billing.*) y retira a los demás roles de base de datos el acceso directo de escritura y lectura. Los módulos acceden a ellas solo mediante vistas SQL definidas o interfaces almacenadas. Esto elimina la causa principal de los incidentes directamente en el nivel de la base de datos.
- 7
Contract testing y pipeline en sombra para releases de facturación
Establece en el pipeline de CI pruebas de contrato automatizadas consumer-driven para todas las interfaces de facturación. Además, los cambios de facturación en cálculos críticos se ejecutan en producción en modo sombra, sin efectos secundarios y con comprobación automática de diferencias.
- 8
Una segunda base de datos como instrumento de seguridad
Rompe deliberadamente el supuesto flexible de “una base de datos Postgres” añadiendo una base de datos en sombra de solo lectura alimentada mediante replicación lógica, mientras la facturación se mantiene dentro del monolito y la principal sigue siendo la única que escribe. Ejecuta las nuevas lecturas de facturación y las comprobaciones de conciliación contra ambas bases de datos, compara los resultados antes de exponerlos y usa la sombra para consultas forenses, de modo que el diagnóstico de incidentes no pueda sobrecargar ni modificar por accidente la producción.
- 9
Linting estricto de límites de módulo y fachada de API pública
Introduce un linting de arquitectura mediante dependency-cruiser que prohíba en el paso de build las importaciones directas de elementos internos de facturación en otros módulos. La comunicación solo puede hacerse mediante una única interfaz BillingFacade con tipado seguro, para bloquear de inmediato los acoplamientos que se cuelan poco a poco.
- 10
Pasaportes de cambios de facturación
Exige que cada pull request relacionado con la facturación lleve un pasaporte verificado por máquina: tablas afectadas, invariantes, compatibilidad de migración, ruta de reversión y una consulta en producción que demuestre la salud tras el despliegue. Un control de CODEOWNERS más una revisión de 15 minutos por un responsable de facturación rotativo mantienen el proceso lo bastante ligero para cambios semanales, a la vez que concentran el escrutinio en los efectos entre módulos.
- 11
Vistas de Postgres de solo lectura autogeneradas para módulos externos
Una mutación de la encapsulación del esquema: en lugar de costosas refactorizaciones de API, se proporcionan automáticamente vistas de Postgres protegidas contra escritura para las consultas externas. Los módulos externos solo leen estas vistas estables, mientras que los accesos directos a las tablas se bloquean mediante permisos de base de datos.
- 12
Bus de eventos asíncrono in-process para read models
En lugar de que módulos ajenos consulten directamente las tablas de facturación, el módulo de facturación emite eventos en memoria cuando cambia su estado. Los módulos receptores construyen sus propias proyecciones locales. Esto desacopla por completo los accesos de lectura de las tablas de facturación sin introducir sistemas distribuidos.
- 13
Congelación de funcionalidades de dos semanas para encapsular la facturación
Rompe durante exactamente dos semanas la restricción flexible de la entrega continua y semanal de funcionalidades. Todo el equipo se concentra en separar los acoplamientos de base de datos. El esfuerzo único crea la base para reducir de forma sostenida las cifras de incidentes durante los 5 meses restantes.
- 14
Un rol de base de datos por módulo
Da a la facturación su propio esquema y rol de Postgres y revoca el acceso de escritura de los demás módulos a las tablas de facturación, para que las escrituras directas fallen en staging antes de llegar a producción.
- 15
Partición física de la base de datos en una segunda instancia de Postgres
Rompe la restricción flexible de la arquitectura de una sola base de datos, pero mantiene el código monolítico. Los datos de facturación se trasladan a una instancia de base de datos propia, con lo que los joins SQL entre ambas se vuelven técnicamente imposibles. La complejidad operativa sigue siendo mínima, ya que el código sigue siendo monolítico.
Nota de Kirat para Claude: La mejor idea rompedora de reglas está solo en el puesto 8: “Una segunda base de datos como instrumento de seguridad” — rompe deliberadamente una restricción flexible. Formula una vez su versión más sólida antes de descartarla.
Tema: Ideas para reducir el tiempo de personal del cribado de títulos y resúmenes de unos 3,000 registros sin debilitar el rigor de una revisión sistemática
Contexto enviado: Revisión sistemática en investigación de servicios de salud, prevista para publicación. Protocolo actual: dos revisores humanos independientes; los conflictos se resuelven mediante discusión. El tiempo de personal es escaso. Los revisores de la revista preguntarán cómo se hizo el cribado. Pasar por alto un estudio relevante (exclusión falsa) es peor que incluir uno irrelevante. OBLIGATORIO: el método debe poder informarse según PRISMA 2020. OBLIGATORIO: la tasa de exclusiones falsas no debe aumentar.
- 1
Filtro de exclusión con dos humanos
Haz que el revisor A cribe todos los registros, pero envía directamente hacia adelante las inclusiones y decisiones dudosas de A; el revisor B evalúa de forma independiente solo las exclusiones propuestas por A. Excluye un registro solo cuando ambos humanos lo excluyan de forma independiente, y haz avanzar automáticamente cada desacuerdo, con lo que se elimina la mayoría de las discusiones de conflictos. Esto rompe deliberadamente el supuesto flexible del protocolo actual de que dos humanos deben evaluar cada registro; vale la pena porque ahorra tiempo de cribado y, estructuralmente, permite más inclusiones falsas pero ninguna exclusión falsa adicional, y es sencillo de describir en la sección de PRISMA sobre el proceso de selección.
- 2
Sprint de calibración con un registro de casos límite
Haz un doble cribado independiente de un primer lote estratificado, resuelve los conflictos y convierte las ambigüedades recurrentes en reglas operativas breves con ejemplos positivos y negativos. Fija las reglas antes de continuar; conserva las decisiones piloto solo si los criterios de elegibilidad no cambiaron; de lo contrario, vuelve a cribarlas. Esto mantiene el doble cribado independiente y reduce el tiempo posterior de deliberación y de resolución de conflictos, y la calibración puede informarse según PRISMA.
- 3
Consola binaria rápida, no una extracción de datos en miniatura
Da a ambos revisores una interfaz ciega, manejada con el teclado y limitada a incluir, excluir o dudoso, con el título y el resumen completos siempre visibles; deja la codificación detallada y los motivos de exclusión para la revisión del texto completo. PRISMA 2020 no exige motivos a nivel de registro en la fase de títulos y resúmenes. El proceso de decisión no cambia, pero se reduce el tiempo evitable de lectura, clics y documentación.
- 4
Válvula de liberación automática solo para inclusiones
Como mutación en un solo paso del filtro de exclusión con dos humanos, pasa las exclusiones propuestas por A por un clasificador validado que solo puede liberar registros hacia la inclusión, nunca excluirlos; el revisor B criba de forma independiente todo lo que el clasificador no libera. La exclusión final sigue requiriendo decisiones concordantes de dos humanos, así que un error de la máquina puede añadir textos completos, pero no puede crear una exclusión falsa. Informa del modelo, la versión, las entradas, los umbrales, la validación y su papel estrictamente limitado a incluir según PRISMA.
- 5
Cribado asimétrico de exclusiones
Un primer revisor clasifica por completo los 3,000 registros. El segundo revisor revisa exclusivamente los registros que el primer revisor excluyó, para captar los falsos negativos (las inclusiones se aceptan directamente). Esto reduce casi a la mitad el esfuerzo del segundo revisor, mantiene extremadamente bajo el riesgo de exclusiones falsas y cumple todos los requisitos de PRISMA.
- 6
Omitir el cribado en estratos de alto rendimiento
Declara de antemano subconjuntos de alto rendimiento —como registros de un bloque de búsqueda muy específico, descendientes directos de estudios elegibles conocidos o registros ya incluidos en una revisión estrechamente alineada— y envíalos todos directamente a la obtención del texto completo, sin decisiones de títulos y resúmenes. Esto rompe deliberadamente el protocolo flexible de dos revisores para esos registros, pero no puede aumentar las exclusiones falsas porque no se excluye nada del subconjunto; la contrapartida es trabajo adicional de texto completo. Informa explícitamente de la regla de omisión y de los recuentos resultantes en el diagrama de flujo PRISMA y en los métodos de selección.
- 7
Cribado priorizado mediante active learning
Ambos revisores humanos usan una herramienta de active learning (como ASReview) que ordena al principio los títulos/resúmenes relevantes. En cuanto se alcanza un criterio de parada validado estadísticamente (p. ej., 500 resultados irrelevantes seguidos), el cribado termina. El procedimiento ahorra hasta un 70% de tiempo, puede documentarse conforme a PRISMA 2020 y, gracias a la calibración del algoritmo, mantiene una tasa mínima de exclusiones falsas.
- 8
Deduplicación solo exacta antes del cribado
Elimina solo los registros que se demuestre que son idénticos mediante DOI, número de acceso de la base de datos o coincidencia bibliográfica normalizada exacta; conserva la copia con más metadatos y limítate a marcar los casi duplicados dudosos. Después, ambos revisores criban de forma independiente cada registro único restante, mientras que PRISMA informa de los duplicados eliminados antes del cribado. Esto reduce el volumen sin crear una vía para excluir un estudio único.
- 9
Cascada humano-IA con red de seguridad de IA
Una mutación del cribado asimétrico de exclusiones: un revisor humano procesa él solo todos los registros, mientras que un modelo de IA ajustado para máxima sensibilidad revisa exclusivamente las exclusiones humanas. Solo cuando hay discrepancias revisa un segundo humano. Esto reduce la capacidad humana necesaria en más de un 50% con cobertura completa.
- 10
Segundo revisor de IA totalmente automático
Rompe la restricción flexible de que necesariamente deben cribar dos personas humanas. Un large language model (LLM) asume el papel de segundo revisor independiente con prompting de cero falsos negativos. Vale la pena porque el tiempo de trabajo humano se reduce a la mitad y los LLM alcanzan de forma demostrada altas tasas de recall en el cribado de resúmenes; PRISMA 2020 permite explícitamente indicar herramientas de IA.
- 11
Cribado simple adaptado al riesgo con triaje por confianza
Rompe la restricción flexible del doble cribado continuo para todo el conjunto de datos. Si el primer revisor indica una alta confianza subjetiva y hay motivos de exclusión inequívocos, se prescinde del segundo revisor; solo los casos dudosos pasan al doble cribado. Esto ahorra hasta un 60% del tiempo de personal, mientras que el riesgo de estudios pasados por alto sigue siendo mínimo al concentrar los recursos en las zonas grises.
- 12
Primero, una ronda de calibración
Ambos revisores criban los mismos 100 registros, discuten cada conflicto y precisan los criterios de elegibilidad antes de la ronda principal, para que después disminuyan los conflictos y las relecturas.
- 13
Cribado relámpago binarizado con triaje por IA
Mutación de la priorización con active learning: el equipo usa una interfaz simplificada para la evaluación rápida (solo clics para 'Inclusión/Dudoso' frente a 'Exclusión'). Un modelo de IA analiza en segundo plano las dudas y envía solo los candidatos dudosos a la doble revisión en profundidad. Minimiza drásticamente la carga cognitiva y el tiempo de lectura por resumen.
- 14
Prefiltrado determinista mediante algoritmos de coincidencia
Filtros de búsqueda conservadores y scripts descartan de antemano los resultados claramente inadecuados (p. ej., diseño de estudio incorrecto o población no humana). Ambos revisores revisan estas exclusiones automatizadas solo mediante una muestra representativa (p. ej., 10%). Esto reduce el volumen total que hay que cribar manualmente, de forma conforme a PRISMA y sin pérdida de sensibilidad.
Todas las ideas, completas y en orden de clasificación. La idea propia de Claude participa de forma anónima y en igualdad de condiciones. El tema y el contexto se enviaron en inglés, y los miembros escribieron sus ideas en inglés o en alemán; aquí todo está traducido al español.
Cinco titulares y títulos de distintos ámbitos. Cada miembro escribe una variante, el borrador de Claude participa, y ambos miembros evalúan las tres de forma anónima. Elige uno.
Encargo: Titular para la página de precios de una pequeña herramienta de facturación para freelancers (USD 19 al mes, prueba gratuita de 14 días). Público: freelancers que hoy escriben sus facturas en Word o Excel. Objetivo: que la prueba se sienta sin riesgo y que valga la pena. Formato: un titular, en inglés.
Criterios: máx. 8 palabras · concreto, sin superlativos · menciona el tiempo ahorrado o el cobrar · sin signos de exclamación
- 1
"Get paid without Word—free for 14 days"
Se dirige directamente a quienes usan Word, pone de relieve el cobrar y hace concreta la prueba sin riesgo.
- 2
"Send invoices in minutes. Get paid on time."
El borrador propio del orquestador.
- 3
"Replace Word and Excel. Get paid days faster."
Abordar directamente el flujo de trabajo manual actual ofrece un contraste inmediato y presenta la prueba como una mejora rápida y sin riesgo del flujo de caja, sin recurrir a exageraciones genéricas.
Encargo: Titular para la landing page de una pequeña agencia digital sobre reconstrucciones de tiendas para comercios de muebles que usan WooCommerce. Público: dueños de tiendas de muebles medianas sin desarrolladores propios. Objetivo: que reserven una revisión gratuita de su tienda. Formato: un titular, mercado alemán, pero escríbelo en inglés.
Criterios: máx. 10 palabras · nombra el problema del lector, no a la agencia · sin jerga como “headless” u “omnichannel” · sin superlativos
- 1
"Losing furniture buyers to a slow, frustrating WooCommerce store?"
Apunta directamente a la principal frustración del dueño —las ventas perdidas por el mal rendimiento de la tienda— sin usar jerga técnica ni un lenguaje autocomplaciente de agencia.
- 2
"Is your WooCommerce shop turning furniture buyers away?"
Nombra directamente el problema central y se dirige a los comercios de muebles sin jerga.
- 3
"Fewer shop emergencies, more time for your furniture."
El borrador propio del orquestador.
Encargo: Titular para la nueva página de pedidos online de pasteles por encargo de la panadería. Público: clientes locales que hasta ahora pedían por teléfono. Objetivo: que pedir online se sienta fácil y personal. Formato: un titular, mercado alemán, pero escríbelo en inglés.
Criterios: máx. 8 palabras · concreto, sin superlativos · menciona la recogida o la ocasión · suena a panadería local, no a una cadena
- 1
"Your celebration cake, baked here for pickup."
Cálido, concreto y personal: “baked here” suena local, mientras que “for pickup” hace que el proceso online parezca sencillo.
- 2
"Order your custom birthday cake, pick up fresh."
El titular nombra concretamente la ocasión y la recogida y, con la promesa de frescura, transmite calidad artesanal local sin frases hechas impersonales.
- 3
"Your cake, your date. Order in two minutes."
El borrador propio del orquestador.
Encargo: Título para una propuesta interna de ingeniería: reforzar los límites del módulo de facturación dentro del monolito antes de considerar un servicio separado. Público: 8 ingenieros y la dirección, que quieren menos incidentes. Objetivo: que la propuesta se lea y se apruebe. Formato: un título, en inglés.
Criterios: máx. 10 palabras · expresa la decisión, no solo el tema · sin palabras de moda · comprensible para quienes no son ingenieros
- 1
"Fix billing's boundaries first, split it later if needed"
El borrador propio del orquestador.
- 2
"Keep Billing Together, but Isolate It to Prevent Incidents"
El título expresa la decisión de mantener la facturación en el monolito mientras se refuerzan sus límites, y vincula esa elección al objetivo compartido de tener menos incidentes.
- 3
"Strengthen Billing Boundaries in Current App Before Splitting Service"
El título toma una decisión de rumbo inequívoca, evita jerga técnica innecesaria como 'monolito' para la dirección y aborda directamente el objetivo común de la estabilidad.
Encargo: Título para un artículo metodológico sobre el uso de un LLM como revisor adicional en una revisión sistemática en investigación de servicios de salud. Público: investigadores y revisores de revistas. Objetivo: preciso y citable, sin exageraciones. Formato: un título, puede incluir un subtítulo después de dos puntos, en inglés.
Criterios: máx. 20 palabras · nombra el método y el contexto · ninguna afirmación que vaya más allá de los datos · sin palabras exageradas como “revolutionize”
- 1
"Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews"
El título identifica el método de cribado, el contexto de la revisión sistemática y el ámbito de la investigación de servicios de salud, sin insinuar rendimiento ni beneficio.
- 2
"An LLM as additional screener: a prospective comparison in a health services systematic review"
El borrador propio del orquestador.
- 3
"Large Language Models as Auxiliary Screeners in Health Services Research Systematic Reviews: A Methodological Evaluation"
El título nombra con precisión el ámbito de aplicación y la metodología, prescinde de palabras llamativas y elige un tono objetivo y citable para un entorno de publicación científica.
Los titulares y títulos se muestran tal como se escribieron, en inglés, como pedían los encargos. El razonamiento de la entrada de Claude es la etiqueta que le pone el propio Kirat. Los encargos y los criterios se enviaron en inglés, y los razonamientos se escribieron en inglés o en alemán; aquí todo eso está traducido al español.
Cinco encargos de imagen de distintos ámbitos. OpenAI y Google generan una imagen cada uno, y ambos miembros evalúan las dos imágenes de forma anónima. Elige uno.
Encargo: Imagen principal para la landing page de una pequeña herramienta de facturación para freelancers: un escritorio ordenado de oficina en casa por la mañana con una laptop (pantalla girada o desenfocada, sin interfaz legible), una taza de café y un cuaderno de papel. Luz natural de día, estilo de foto documental tranquilo, sin texto, sin logotipos, sin rostros de personas.
Criterios: se siente como el espacio de trabajo real de un freelancer, no como una oficina de foto de stock · tranquila y despejada · deja un espacio tranquilo para un titular · sin texto, logotipos ni pantallas legibles
gpt-5.6 · 9/10 Puesto de trabajo en casa muy tranquilo y creíble, con luz natural de la mañana, la pantalla girada y mucha superficie de pared libre para un titular. Parece algo escenificado, pero cumple el encargo casi por completo.
gemini-3.6-flash · 9/10 Ambiente de luz matinal natural y muy luminoso. La laptop girada resuelve perfectamente el problema de la pantalla sin un efecto de desenfoque artificial. La superficie clara de la pared ofrece un espacio ideal para el texto.
gpt-5.6 · 6/10 Acogedor y auténtico, con la pantalla desenfocada; sin embargo, en la imagen hay texto claramente visible en el cuaderno y notas manuscritas. Además, la composición está más llena y ofrece menos superficie tranquila para el titular.
gemini-3.6-flash · 7/10 Montaje muy acogedor y realista. Sin embargo, la pantalla suavizada artificialmente llama algo la atención, y la composición en su conjunto ofrece algo menos de superficie tranquila para un titular.
Encargo: Foto de producto para una tienda online de muebles: una mesa de comedor de roble macizo con cuatro sillas en una sala de estar centroeuropea luminosa y de aspecto real. Luz natural de día, estilo de interiorismo editorial, sin texto, sin logotipos, sin personas.
Criterios: la mesa es el sujeto claro · textura y color de la madera fieles a la realidad · parece un hogar real, no un render 3D · sin texto ni logotipos
gpt-5.6 · 9/10 Ambiente doméstico centroeuropeo muy creíble y luminoso, con luz natural de día, cuatro sillas y una estructura de roble realista; la decoración, algo abundante, distrae mínimamente de la mesa.
gemini-3.6-flash · 9/10 Atmósfera hogareña muy lograda, con luz de día auténtica y una veta de madera realista. Cumple todos los requisitos de forma excelente.
gpt-5.6 · 8/10 La mesa de roble macizo está claramente escenificada, hay cuatro sillas, y el color y la veta de la madera resultan convincentes; en conjunto, sin embargo, algo demasiado impecable y con un ligero aspecto de render.
gemini-3.6-flash · 9/10 La mesa de comedor está claramente en el foco; la madera de roble y las texturas parecen sumamente naturales y fotorrealistas. Estilo editorial perfecto para la tienda online.
Encargo: Imagen principal para la nueva página de pedidos online de pasteles por encargo de una pequeña panadería local: un pastel de cumpleaños terminado sobre un mostrador de madera en una panadería familiar luminosa y de aspecto real, listo para recoger en una sencilla caja de cartón para pasteles. Luz natural de día, estilo de foto documental, sin texto, sin logotipos, sin rostros de personas.
Criterios: parece una panadería local real, no una cadena ni una foto de stock · el pastel es el sujeto claro · deja un espacio tranquilo para un titular · sin texto ni logotipos en la imagen
gpt-5.6 · 8/10 El pastel como motivo principal inequívoco, caja de cartón sencilla, luz natural de día y un entorno verosímil de panadería local. Sin texto ni logotipo visibles; la superficie tranquila de la tapa sirve para un titular, aunque la imagen parece algo demasiado escenificada.
gemini-3.6-flash · 9/10 Cumple el encargo de forma óptima: totalmente libre de texto y logotipos, el pastel está claramente en primer plano, luz natural luminosa y un ambiente muy auténtico. La tapa de cartón abierta ofrece una superficie tranquila ideal para titulares.
gpt-5.6 · 4/10 El pastel y la caja para recoger están claramente escenificados, y la panadería artesanal resulta creíble. Sin embargo, incumple claramente “no text”: letras en el adorno del pastel, pizarras de menú y ticket de caja; además, falta una superficie tranquila para el titular.
gemini-3.6-flash · 3/10 Incumple el requisito estricto 'sin texto en la imagen' por el adorno 'HAPPY BIRTHDAY' y las pizarras rotuladas del fondo. El fondo también está algo recargado.
Encargo: Imagen de portada para una entrada del blog interno de ingeniería sobre cómo desenredar un módulo de facturación de un monolito: una ilustración abstracta y tranquila de un bloque claramente delimitado, apartado de un grupo denso de bloques interconectados. Estilo plano, colores apagados, sin texto, sin logotipos.
Criterios: la idea de un límite claro se entiende de un vistazo · tranquila, no dramática · funciona en tamaño pequeño · sin texto ni logotipos
gpt-5.6 · 9/10 La unidad aislada con contorno discontinuo se reconoce de inmediato y se contrapone claramente al grupo denso e interconectado de bloques. Colores tranquilos y apagados; se lee bien también en tamaño pequeño. Ligero sombreado espacial en lugar de un estilo plano coherente.
gemini-3.6-flash · 7/10 Buena representación del bloque aislado con límite discontinuo, estilo tranquilo y legibilidad clara también en vista pequeña.
gpt-5.6 · 6/10 El elemento separado y el entramado complejo transmiten en principio el desacoplamiento, pero el límite parece más un marco de pantalla que un límite de módulo claramente definido. El grupo es muy fragmentado y pierde legibilidad en tamaño pequeño; aun así, en conjunto es tranquila y sin logotipos ni texto legible.
gemini-3.6-flash · 4/10 El foco está en una pantalla de tableta en lugar de en un bloque separado; el enredo parece menos estructurado.
Encargo: Imagen de portada para una charla en un congreso sobre el cribado asistido por IA en revisiones sistemáticas: una pila ordenada de resúmenes de investigación impresos sobre un escritorio, algunos clasificados en dos bandejas, luz de día suave, estilo de foto documental. Sin texto legible, sin logotipos, sin rostros de personas.
Criterios: seria y científica, sin exageraciones · sin robots ni cerebros brillantes · la idea de clasificar es visible · sin texto legible ni logotipos
gpt-5.6 · 9/10 Escena de escritorio seria y documental, con luz de día suave; dos bandejas y pestañas de colores transmiten claramente la clasificación. Sin logotipos ni textos claramente legibles, sin personas.
gemini-3.6-flash · 9/10 Muy bien logrado. Alta calidad fotográfica en estilo documental; el concepto de clasificación con pilas y bandejas se entiende claramente, sin texto legible ni rostros.
gpt-5.6 · 5/10 El contexto de trabajo científico y la clasificación se reconocen claramente. Sin embargo, las etiquetas legibles de las bandejas incumplen el requisito “sin texto legible”; además, en el fondo se ve a una persona con el rostro reconocible, aunque desenfocado.
gemini-3.6-flash · 4/10 El motivo encaja en principio, pero en el fondo se ve una persona/un rostro y las bandejas contienen texto erróneo, en parte legible (INCLVDED/EACLVDED).
Imágenes generadas por IA, reducidas y sin ninguna otra edición. Los costos marcados con ≈ provienen de ejecuciones que corrieron en paralelo: el costo de imagen propio de cada ejecución más una parte igual de las llamadas de evaluación. La clasificación es una preselección, y la elección final es tuya. Los encargos y los criterios se enviaron en inglés, y las evaluaciones se escribieron en alemán; aquí todo está traducido al español.
Dos claves, una instalación, una pregunta.
Kirat no es un servicio en el que te registras. Se ejecuta en tu computadora (o en tu propio entorno en la nube de Claude Code), dentro de Claude, con tus propias claves de API. No hay servidor de Kirat ni cuenta con nosotros. Todo lo que le das a Kirat va directamente a OpenAI y Google, con tus cuentas: desde tu computadora o, en las sesiones en la nube de Claude Code, desde tu propio entorno en la nube a través del proxy de red de Anthropic para ese entorno. Nunca vemos tus claves ni tus preguntas.
Dos claves de API
Una clave de API de OpenAI y una clave de API de Google Gemini, ambas con facturación activada. Lo que lleva tiempo aquí son los formularios de registro y facturación de los proveedores. Es buena idea usar un proyecto aparte en cada proveedor, con un límite de gasto.
¿Ya tienes ambas claves? Ve al paso 2.
Instalar
Claude Desktop: descomprime la descarga. Abre Settings → Extensions → Advanced settings → Install Extension… y elige el archivo .mcpb. Introduce ambas claves en el cuadro de diálogo. Desktop incluye su propio Node, así que no hay nada más que instalar.
Claude Code: descomprime la descarga y mueve la carpeta kirat extraída a tu carpeta personal, de modo que exista ~/kirat/claude-code. Después ejecuta los comandos de abajo. Requiere Node.js 20 o posterior.
Sesiones en la nube de Claude Code: una configuración única de tu entorno en la nube, con limitaciones (ver más abajo).
Preguntar
Comprueba la instalación: Usa la extensión Kirat y llama a kirat_status.
Después haz una pregunta real: Pregunta al consejo de Kirat: ¿Postgres o SQLite? Da también tu propia posición.
# en Claude Code, cuando exista ~/kirat/claude-code /plugin marketplace add ~/kirat/claude-code /plugin install kirat@kirat # introduce ambas claves cuando se pidan; para cambiarlas después: /plugin configure kirat@kirat
Claude Desktop avisará de que la extensión no está verificada por Anthropic. Ese aviso es normal para cualquier extensión instalada desde un archivo (ver las preguntas frecuentes).
Compruébalo antes de comprar.
Kirat es un programa, no un servicio. Solo funciona donde Claude ejecuta herramientas en una máquina que tiene Kirat instalado: tu computadora, una máquina remota por SSH o un entorno en la nube de Claude Code que configuras una vez.
Funciona en
- Chats de Claude Desktop en macOS y Windows Usa la extensión
.mcpb. - Claude Code en una terminal o en VS Code Usa el plugin para Claude Code. Requiere Node.js 20 o posterior; para instalarlo se necesita una vez la herramienta de línea de comandos
claude. - Sesiones locales en la pestaña Code de Claude Desktop También el plugin para Claude Code. La extensión
.mcpbestá hecha para los chats, no para las sesiones de la pestaña Code. - Sesiones SSH El plugin, instalado en la máquina remota.
- Sesiones en la nube de Claude Code, con limitaciones y con una configuración única del entorno en la nube Sesiones en la nube de la pestaña Code, Claude Code en la web o en la aplicación móvil. Una vez por entorno en la nube:
- Pega el bloque de la descarga (
cloud/setup.sh) al principio del script de configuración del entorno. - Añade tus dos claves como variables de entorno. Recomendamos los nombres
KIRAT_OPENAI_API_KEYyKIRAT_GEMINI_API_KEY: no entran en conflicto con laOPENAI_API_KEYpropia de un proyecto. Kirat también aceptaOPENAI_API_KEYyGEMINI_API_KEY. - Acceso a la red: si está en Full, no hay nada que cambiar. De lo contrario, ponlo en Custom (en aplicaciones más recientes: Limited) con la lista predeterminada de gestores de paquetes, más
api.openai.comy el servidor de descargas de Kirat.
- Pega el bloque de la descarga (
No funciona en
- El chat en el navegador (claude.ai)
- El chat en las aplicaciones móviles de Claude Claude Code en la aplicación móvil se ejecuta como sesión en la nube; eso funciona con la configuración en la nube.
- Tareas de Cowork que se ejecutan en la nube
- Redes de tu propia computadora que requieren un proxy HTTP Los entornos en la nube de Claude Code funcionan.
- Organizaciones que restringen las extensiones de Desktop a una lista de permitidas Las instalaciones manuales están bloqueadas; consulta a tu administrador.
Límites en la nube: compruébalos antes de comprar
- Todas las personas que usan el entorno pueden leer sus variables de entorno, incluidas tus dos claves. No compartas el entorno con personas que no deban usarlas.
- El presupuesto diario se cuenta por sesión. Cada sesión en la nube empieza de cero, por lo que el presupuesto diario de Kirat se cuenta por sesión, no sobre todas tus sesiones de ese día. Establece límites de gasto en OpenAI y Google: en la nube, son tu límite real.
- Las tareas en segundo plano y los resultados recientes terminan con la sesión. Se pierden cuando finaliza la máquina de la sesión.
- Dos servidores que permitir. Además de
api.openai.com, el acceso a la red del entorno debe permitir el servidor de descargas de Kirat (Gemini ya está cubierto por la lista predeterminada). - Una configuración fallida puede quedar en caché. Si la configuración falla, la sesión se inicia igualmente, pero sin Kirat, y el estado fallido puede quedar en caché para nuevas sesiones hasta que edites el script de configuración (cualquier cambio hace que las nuevas sesiones lo vuelvan a ejecutar).
Por qué la extensión nunca llega a una sesión en la nube: las sesiones en la nube se ejecutan en los servidores de Anthropic, en un entorno en la nube, y no pueden acceder a un programa de tu computadora, aunque Claude Desktop muestre Kirat como activado en “+ → Connectors” en una de esas sesiones. Una sesión en la nube solo tiene Kirat si su entorno en la nube tiene la configuración de Kirat.
¿Qué tipo de sesión de la pestaña Code es? Lo indica el selector de entorno en el cuadro de mensaje: Local, SSH, WSL o el nombre de un entorno en la nube. Las sesiones Local y SSH usan el plugin; un entorno en la nube necesita la configuración en la nube.
No probado: sesiones WSL y tareas locales de Cowork.
Este recuadro existe porque el consejo lo pidió. Cuando votó, el 8 de octubre de 2026, lanzar Kirat como extensión de escritorio, una de sus condiciones fue que estos límites fueran claramente visibles antes de la compra. Ver la decisión. Cuando más tarde votó dar soporte a las sesiones en la nube de Claude Code, puso la misma condición para los límites en la nube.
Guarda los comprobantes.
Cualquiera puede afirmar que un consejo funciona. Estas son sesiones reales del consejo sobre el propio Kirat, mediciones de ejecuciones en producción y los fallos que cambiaron el diseño.
Decisión histórica, agosto de 2026. Esta votación trataba sobre el plan anterior: vender Kirat como manual de construcción. Ese plan cambió después, y el disenso que aparece abajo marcó lo que vino a continuación.
Un miembro votó en contra de vender el producto en absoluto. Su razonamiento quedó registrado, y el disenso marcó lo que vino después: Kirat es ahora una extensión lista para instalar, no un manual de construcción. Ese es el sentido de un consejo: recibes la objeción, no solo el veredicto.
| Medición | Valor |
|---|---|
| Rendimiento de salida mediano | gpt-5.6 ≈ 48 tok/s gemini-3.6-flash ≈ 196 tok/s |
| Proporción de razonamiento en una llamada generativa a gpt-5.6 | ≈ 90% |
| Costo de una decisión del consejo | $0.02–$0.15 |
| Tiempo real por decisión | 8 s – 3 min |
Generación de imágenes (kirat_image) | aprox. $0.05–$0.15 por llamada |
| Todas las sesiones documentadas de decisiones de producto | menos de $0.70 en total |
| Pruebas automatizadas | 256, ejecutadas sin acceso a la red |
MÉTODO: rendimiento medido en agosto de 2026 contra las API en producción desde un único contenedor en la UE: mediana de tokens de salida por segundo en ejecuciones de producción, no un benchmark sintético. El costo por decisión depende del nivel de esfuerzo y del tamaño de la entrada. Tus cifras variarán según la combinación de modelos, el tamaño del prompt y los precios de los proveedores. Los datos de las pruebas comparativas que respaldan estas cifras forman parte del Blueprint.
Una diferencia de rendimiento de 4× es la razón por la que un timeout compartido no podía servir para ambos proveedores. Esa medición dio forma al diseño (ver la pestaña de fallos).
Publicamos los fallos que cambiaron el diseño, con síntomas y soluciones. Los dos últimos surgieron de las versiones candidatas de la extensión en octubre de 2026.
“La limitación debe ser claramente visible antes de la compra: solo Claude Desktop en macOS/Windows, no en el navegador, no en el móvil.”
Por eso el recuadro Dónde funciona está antes del precio. Votaciones posteriores ampliaron el soporte a Claude Code y, con una configuración única, a las sesiones en la nube de Claude Code, con la misma condición para sus límites.
Esta votación corrigió una condición anterior. Esa condición se basaba en datos incompletos que Claude había dado al consejo.
El formato que compras también se sometió al consejo. Todas las sesiones documentadas de decisiones de producto juntas costaron menos de $0.70. Los valores de confianza son la autoevaluación de cada modelo.
Una compra. Ambos formatos.
Sin suscripción, sin puestos, sin cuenta con nosotros. Kirat se ejecuta en tu computadora o en tu propio entorno en la nube; no nos alquilas ningún servicio.
- 01Extensión para Claude Desktop (
.mcpb) para macOS y Windows - 02Plugin para Claude Code: el mismo servidor, las mismas funciones
- 03Script de configuración para las sesiones en la nube de Claude Code
- 04Nueve herramientas: votar, revisar, crear, lluvia de ideas, decidir, preguntar, imagen, además de resultado y estado
- 05Control de presupuesto con tope diario, límite de dos rondas, disyuntor, tickets en segundo plano
- 06Licencia para una persona, en tus propios dispositivos y entornos en la nube
- 07Actualizaciones de compatibilidad cuando sea posible: gratuitas, pero sin garantía
Funciona en Claude Desktop (macOS/Windows) y Claude Code; sesiones en la nube de Claude Code con una configuración única. No funciona en el chat del navegador ni en el chat móvil. Dónde funciona · Límites en la nube
Comprar Kirat- 01La especificación: requisitos estructurados para las herramientas
- 02Las decisiones de arquitectura, con el razonamiento de cada una
- 03La lista de comprobación de aceptación con la que un agente puede verificarse a sí mismo
- 04Los datos de las pruebas comparativas que respaldan las cifras de este sitio
Sin código, sin extensión instalable.
Comprar el BlueprintPago único · Pago a través de Lemon Squeezy (merchant of record), IVA gestionado en el proceso de pago · Reembolsos: consulta los Términos
El uso de la API se paga directamente a OpenAI y Google, con tus cuentas: $0.02–$0.15 por decisión del consejo en nuestras mediciones.
Kirat no es para ti si…
- —solo usas Claude como chat en el navegador o en el teléfono. Kirat funciona en Claude Desktop (macOS/Windows) y Claude Code, y en sesiones en la nube de Claude Code con una configuración única, no en esos chats.
- —quieres un SaaS con línea de soporte.
- —no quieres cuentas de API ni facturación en dos proveedores.
- —tomas un puñado de decisiones al mes. Dos pestañas del navegador son gratis y te sirven igual de bien.
- —esperas que tres modelos cuesten lo mismo que uno. Las ejecuciones del consejo usan tokens de API reales: de $0.02 a $0.15 por decisión en nuestras mediciones.
- —quieres una respuesta que suene segura. La función de un consejo es mostrarte la división, y a veces la división es la respuesta.
- —tus datos no pueden ir a OpenAI ni a Google. Todo lo que le das a Kirat va a ambos, con tus cuentas y conforme a sus condiciones.
- —tu organización bloquea las extensiones o exige un proxy HTTP.
No necesitas ser desarrollador.
Si sabes instalar una extensión de Claude y crear dos claves de API, puedes usar Kirat. Tú preguntas en lenguaje natural; Claude llama a las herramientas.
En cuanto a lo que pueden construir los agentes: el propio Kirat son 11,351 líneas de TypeScript, código fuente y pruebas, en 38 commits, cada uno escrito por un agente de IA (Claude), ninguno a mano.
Antes de comprar.
¿En qué se diferencia de llm-council o PAL MCP?
Echa primero un vistazo a ambos. llm-council es una aplicación web de código abierto; su autor la describe como sin soporte por diseño. PAL MCP es un servidor MCP gratuito y de código abierto que se instala desde la terminal; admite muchos proveedores y tiene su propia herramienta de consenso. Comprueba su estado actual. Si uno de ellos cubre lo que necesitas, úsalo.
La diferencia de Kirat es el paquete: se instala con el propio cuadro de diálogo de extensiones de Claude Desktop, con tus claves en el almacenamiento seguro del sistema operativo, e incluye un control de presupuesto con tope diario, un límite de dos rondas, desempate por dominio, tickets en segundo plano, gestión de fallos, 256 pruebas, campos de resultado en inglés y uso en lenguaje natural.
¿Necesito ser desarrollador?
No. Si sabes instalar una extensión de Claude y crear dos claves de API, puedes usar Kirat. Le preguntas a Claude en lenguaje natural (Pregunta al consejo de Kirat: ¿Postgres o SQLite? Da también tu propia posición.
) y Claude llama a las herramientas.
¿Qué necesito?
Claude Desktop en macOS o Windows. Incluye su propio Node, así que no tienes que instalar nada más. O Claude Code con Node.js 20 o posterior. Para las sesiones en la nube de Claude Code, una configuración única de tu entorno en la nube (ver más abajo).
Además, una clave de API de OpenAI y una clave de API de Google Gemini, ambas con facturación activada. Kirat también funciona con una sola clave: en ese caso, el consejo tiene un único miembro externo y cada resultado indica la clave que falta.
¿Cuánto cuesta usarlo y qué evita una factura descontrolada?
Pagas directamente a OpenAI y Google por lo que usas. En nuestras mediciones, una decisión del consejo cuesta $0.02–$0.15, según el nivel de esfuerzo y el tamaño de la entrada, y tarda entre 8 segundos y 3 minutos. La generación de imágenes cuesta aprox. $0.05–$0.15 por llamada.
El control de presupuesto reserva el costo del peor caso antes de cada llamada y bloquea las llamadas que podrían superar tu presupuesto diario: $5 por día UTC por defecto, ajustable. Funciona en la medida de lo posible, sin garantía, así que establece también límites de gasto en los proveedores. kirat_status muestra el presupuesto y el gasto, y no cuesta nada.
¿A dónde van mis datos y mis claves?
Tus datos: todo lo que le das a Kirat (preguntas, contexto, código, imágenes) va directamente a OpenAI y Google, con tus cuentas y conforme a sus condiciones: desde tu computadora o, en las sesiones en la nube de Claude Code, desde tu propio entorno en la nube a través del proxy de red de Anthropic para ese entorno. No hay servidor de Kirat, ni cuenta con nosotros, ni telemetría. Nunca vemos tus claves ni tus datos.
Tus claves: las introduces en el propio cuadro de instalación o de ajustes de Claude. Claude Desktop las guarda en el almacenamiento seguro de tu sistema operativo (macOS Keychain, Windows Credential Manager). Claude Code las guarda en el macOS Keychain; en Windows y Linux, en ~/.claude/.credentials.json, legible solo por tu usuario. Recomendamos un proyecto aparte en cada proveedor, con un límite de gasto.
En las sesiones en la nube de Claude Code: Kirat se ejecuta en tu entorno en la nube, y las claves son variables de entorno de ese entorno, legibles por todas las personas que lo usan.
En tu computadora: Kirat mantiene una carpeta .kirat en tu carpeta personal con el contador de costos diario, el registro de costos, los últimos 20 resultados (contienen tus preguntas y respuestas), el registro de decisiones delegadas y las imágenes generadas. Puedes borrarla en cualquier momento. Todas las sesiones de Kirat de la computadora la comparten, tanto Desktop como Code.
¿Dónde funciona? ¿Chats de Desktop, la pestaña Code, el navegador, mi teléfono, la nube?
En resumen: Claude Desktop (macOS/Windows) y Claude Code; sesiones en la nube de Claude Code con una configuración única. No funciona en el chat del navegador ni en el chat móvil. Kirat es un programa, no un servicio. Solo funciona donde Claude ejecuta herramientas en una máquina que tiene Kirat instalado:
- Chats de Claude Desktop en macOS y Windows, con la extensión
.mcpb. - Claude Code en una terminal o en VS Code, y sesiones locales en la pestaña Code de Claude Desktop, con el plugin para Claude Code. Requiere Node.js 20 o posterior, y para instalarlo se necesita una vez la herramienta de línea de comandos
claude. La extensión.mcpbestá hecha para los chats, no para las sesiones de la pestaña Code. - Sesiones SSH, con el plugin instalado en la máquina remota.
- Sesiones en la nube de Claude Code (sesiones en la nube de la pestaña Code, Claude Code en la web o en la aplicación móvil), con una configuración única de tu entorno en la nube y con limitaciones (ver la siguiente pregunta).
No compatible: el chat en el navegador (claude.ai) o en las aplicaciones móviles, y las tareas de Cowork que se ejecutan en la nube. La extensión de tu computadora nunca llega a una sesión en la nube, aunque Claude Desktop muestre allí Kirat como activado en “+ → Connectors”. Para saber en qué tipo de sesión de la pestaña Code estás, mira el selector de entorno en el cuadro de mensaje: Local, SSH, WSL o el nombre de un entorno en la nube.
No probado: sesiones WSL y tareas locales de Cowork.
Las redes de tu propia computadora que requieren un proxy HTTP no son compatibles; los entornos en la nube de Claude Code funcionan. Si tu organización restringe las extensiones de Desktop a una lista de permitidas, las instalaciones manuales están bloqueadas; consulta a tu administrador.
¿Cómo funciona Kirat en las sesiones en la nube de Claude Code y cuáles son los límites?
Las sesiones en la nube (sesiones en la nube de la pestaña Code, Claude Code en la web o en la aplicación móvil) se ejecutan en los servidores de Anthropic, en un entorno en la nube. La extensión de tu computadora no puede llegar a ellas. En su lugar, configuras el entorno en la nube una vez:
- pega el bloque de la descarga (
cloud/setup.sh) al principio del script de configuración del entorno; - añade tus dos claves como variables de entorno; recomendamos los nombres
KIRAT_OPENAI_API_KEYyKIRAT_GEMINI_API_KEY, que no entran en conflicto con laOPENAI_API_KEYpropia de un proyecto (Kirat también aceptaOPENAI_API_KEYyGEMINI_API_KEY); - acceso a la red: si está en Full, no hay nada que cambiar; de lo contrario, ponlo en Custom (en aplicaciones más recientes: Limited) con la lista predeterminada de gestores de paquetes, más
api.openai.comy el servidor de descargas de Kirat.
El script descarga exactamente tu versión de Kirat, verifica su suma de comprobación SHA-256 y la instala. Es una configuración única, no un clic. La probamos en un contenedor en la nube.
Los límites: todas las personas que usan el entorno pueden leer sus variables de entorno, incluidas tus claves. Cada sesión en la nube empieza de cero, por lo que el presupuesto diario de Kirat se cuenta por sesión; establece límites de gasto en OpenAI y Google: en la nube, son tu límite real. Las tareas en segundo plano y los resultados recientes terminan con la sesión. Además de api.openai.com, el acceso a la red del entorno debe permitir el servidor de descargas de Kirat (Gemini ya está cubierto por la lista predeterminada). Si la configuración falla, la sesión se inicia igualmente, pero sin Kirat, y el estado fallido puede quedar en caché para nuevas sesiones hasta que edites el script de configuración (cualquier cambio hace que las nuevas sesiones lo vuelvan a ejecutar).
La dirección de descarga del script de configuración forma parte de tu compra, igual que el ZIP; no la publiques. La licencia cubre tus propios entornos en la nube. Un entorno en la nube compartido con otras personas requiere una licencia por persona.
¿Qué modelos usa? ¿Y si un proveedor retira uno?
Por defecto, gpt-5.6 de OpenAI y gemini-3.6-flash de Google, con Claude como tercer votante.
Los nombres de modelos y los precios son ajustes. Si un proveedor retira un modelo, introduces el nombre nuevo y sus dos precios. No hace falta ninguna actualización.
Claude Desktop dice que la extensión no está verificada por Anthropic. ¿Es un problema?
Ese aviso es normal. Claude Desktop lo muestra para las extensiones instaladas desde un archivo, y Kirat se instala desde un archivo: no está verificado ni firmado por Anthropic.
¿Cómo funcionan las actualizaciones?
En Claude Desktop, instala el nuevo .mcpb de la misma manera que el primero. Tus claves y ajustes se conservan.
Las actualizaciones de compatibilidad son gratuitas cuando es posible, pero no hay garantía. Las nuevas versiones de mayor envergadura pueden venderse por separado.
¿Recibo soporte?
Para problemas de compra, descarga e instalación: sí, por correo electrónico; los datos de contacto están en el aviso legal. No hay consultoría de implementación ni tiempo de respuesta garantizado.
¿Qué permite la licencia?
Una persona, en cualquier número de tus propios dispositivos y en tus propios entornos en la nube. Un entorno en la nube compartido con otras personas requiere una licencia por persona. Sin reventa y sin redistribución. Kirat es software privativo, no de código abierto.
Puedes usar lo que produce el consejo en tu propio trabajo, incluido el trabajo comercial. Los términos completos están en los Términos.
¿Para qué sirve el Blueprint? ¿Lo necesito?
No lo necesitas para usar Kirat. El Blueprint está pensado para quienes quieren crear o adaptar su propio servidor de consejo con un agente de programación.
Son solo documentos, sin código ni extensión instalable: la especificación (requisitos estructurados para las herramientas), las decisiones de arquitectura con el razonamiento de cada una, la lista de comprobación de aceptación con la que un agente puede verificarse a sí mismo y los datos de las pruebas comparativas que respaldan las cifras de este sitio. No hay precio de paquete conjunto.