Día 7 - De la petición al ticket, automatizado

Automatización de punta a punta: el formulario de ideas y Admin Help convierten peticiones en tickets claros, con revisión humana antes de implementar.

Introducción

El día 7 es una entrada especial: documenta la automatización que cierra un hueco que los días anteriores dejaban abierto. Alguien enviaba una idea o incidencia; un desarrollador leía el texto crudo, lo reescribía como issue de GitHub y solo entonces empezaba la implementación. Ese traspaso era el cuello de botella.

El 4 de junio de 2026 cableamos el ciclo completo en dos canales: feedback público en km0digital.com (producción) y Admin Help interno en un stack Laravel ecommerce en staging. Mismo modelo mental: cola, borrador autoissue, etiqueta humana, recogida por autoagents.

Resumen

Antes y después

Petición: mensaje suelto o email → JSON estructurado en cola.
Comprensión: el dev interpreta texto crudo → cursor-agent escribe borrador .md estructurado.
Ticket: gh issue create manual → issue automatizado con cuerpo Markdown limpio.
Control humano: implícito → etiqueta waiting for human validation.
Implementación: el dev asigna trabajo → humano quita la etiqueta → autoagents (001 / FEAT) recogen el issue.

El desarrollador ya no abre la petición cruda y redacta el ticket desde cero. El sistema encola, redacta y publica en GitHub en segundos. Un humano valida o corrige quitando la etiqueta; a partir de ahí el pipeline de agentes puede implementar.

Arquitectura

Dos entradas, un patrón

ENTRADA
  km0-web:     POST /hooks/ideas        (público /ideas/)
  ecommerce:   POST /api/v1/admin/help  (/admin/help autenticado)
        ↓
  Cola JSON (spool / storage)
        ↓
  Disparo inmediato (systemd path / queue job)
        ↓
  cursor-agent (--yolo) + prompt autoissue → borrador .md
        ↓
  gh issue create --body-file + etiqueta waiting for human validation
        ↓
  Humano revisa → quita etiqueta → autoagents 001 → FEAT → código

Por qué encaja

Una solución práctica para equipos pequeños

No buscábamos automatizar por moda. Queríamos que una petición útil no se perdiera entre un chat, un email y la cabeza de quien la recibió. El sistema convierte cada envío en un ticket legible, con contexto y prioridad, en unos segundos.

Rapidez: quien escribe no espera a que alguien tenga un hueco para redactar la incidencia.
Calidad: el borrador sigue siempre la misma estructura (qué pasa, para quién, qué se espera).
Control: nada entra en desarrollo sin pasar por una persona del equipo.
Reutilizable: el mismo patrón sirve para feedback público y para peticiones internas.

Para KM0 encaja especialmente bien: recibimos ideas de gente no técnica y las queremos tratar con el mismo rigor que un informe de un administrador de tienda online.

Dónde aplica

Dos puertas de entrada, un recorrido

Quien usa KM0: el formulario Ideas en km0digital.com. Sirve para sugerencias de producto, mejoras de la web o cosas que echas en falta al usar el cloud.
Quien opera un proyecto interno: la pantalla Admin Help de una tienda online en staging. Sirve cuando alguien del equipo ve un fallo o necesita un cambio y quiere dejarlo registrado con trazabilidad.

En ambos casos el recorrido es el mismo: formulario → cola → ticket redactado → revisión humana → implementación. Cambia quién escribe y dónde, no la lógica.

Ejemplos

Cómo se ve en la práctica

Imagina que alguien envía desde Ideas: «Me gustaría un botón para compartir entradas del blog». En unos quince segundos el sistema genera un ticket titulado y ordenado: qué pide la persona, en qué idioma escribió, qué parte del sitio toca. Aparece marcado como pendiente de validación humana.

Alguien del equipo lo lee. Si el texto está bien, quita la marca y el ticket pasa a la cola de implementación automática. Si hace falta matizar («solo en móvil», «icono de WhatsApp»), se edita el ticket antes de aprobarlo. Sin volver a copiar el mensaje original a mano.

Otro caso: un administrador de la tienda en staging reporta desde Admin Help que un filtro de productos no guarda bien. Misma mecánica: ticket claro, revisión, y solo entonces entra en el flujo de desarrollo. El objetivo es que nadie tenga que adivinar qué quiso decir quien escribió.

Personas

Qué hace (y qué no) la automatización

La máquina redacta y clasifica. La persona decide. Los agentes de desarrollo no recogen tickets mientras sigan marcados como pendientes de validación: así evitamos implementar a ciegas un mensaje ambiguo o una broma.

Para quien envía una idea, el beneficio es simple: escribes una vez en lenguaje normal y el equipo recibe algo accionable. Para quien mantiene el servicio, el beneficio es dejar de ser el traductor permanente entre «mensaje de WhatsApp» y «ticket bien escrito».

Resultado

Qué logró el día 7

El paso manual entre «alguien pide algo» y «hay un ticket que se puede implementar» desaparece en producción (ideas públicas de KM0) y en el entorno de pruebas del ecommerce (Admin Help).

Hoy el ciclo completo funciona: petición, ticket redactado, validación humana e implementación asistida por agentes. Es la pieza que faltaba para cerrar el círculo entre escuchar a la comunidad y entregar cambios con criterio.

Serie

Días 1–6

Las entradas anteriores cubren el stack (OpenCloud, Dex, LDAP, clientes nativos, tutoriales, visión). El día 7 añade el bucle de feedback: prueba el formulario de ideas o revisa el día 6 para onboarding en dispositivos. Dudas: contacto.