En aquesta pàgina
5 min de lectura

Dia 7 - De la petició al ticket, automatitzat

Automatització de punta a punta: el formulari d'idees i Admin Help converteixen peticions en tickets clars, amb revisió humana abans d'implementar.

Introducció

El dia 7 és una entrada especial: documenta l'automatització que tanca un buit que els dies anteriors deixaven obert. Algú enviava una idea o incidència; un desenvolupador llegia el text cru, el reescrivia com a issue de GitHub i només llavors començava la implementació. Aquest traspàs era el coll d'ampolla.

El 4 de juny de 2026 vam cablejar el cicle complet en dos canals: feedback públic a km0digital.com (producció) i Admin Help intern en un stack Laravel ecommerce en staging. Mateix model mental: cua, esborrany autoissue, etiqueta humana, recollida per autoagents.

Resum

Abans i després

  • Petició: missatge solt o email → JSON estructurat en cua.
  • Comprensió: el dev interpreta text cru → cursor-agent escriu esborrany .md estructurat.
  • Ticket: gh issue create manual → issue automatitzat amb cos Markdown net.
  • Control humà: implícit → etiqueta waiting for human validation.
  • Implementació: el dev assigna feina → humà treu l'etiqueta → autoagents (001 / FEAT) recullen l'issue.

El desenvolupador ja no obre la petició crua i redacta el ticket des de zero. El sistema encua, redacta i publica a GitHub en segons. Un humà valida o corregeix traient l'etiqueta; a partir d'aquí el pipeline d'agents pot implementar.

Arquitectura

Dues entrades, un patró

ENTRADA
  km0-web:     POST /hooks/ideas        (públic /ideas/)
  ecommerce:   POST /api/v1/admin/help  (/admin/help autenticat)
        ↓
  Cua JSON (spool / storage)
        ↓
  Dispar immediat (systemd path / queue job)
        ↓
  cursor-agent (--yolo) + prompt autoissue → esborrany .md
        ↓
  gh issue create --body-file + etiqueta waiting for human validation
        ↓
  Humà revisa → treu etiqueta → autoagents 001 → FEAT → codi

Per què encaixa

Una solució pràctica per a equips petits

No buscàvem automatitzar per moda. Volíem que una petició útil no es perdés entre un xat, un correu i el cap de qui la rebia. El sistema converteix cada enviament en un ticket llegible, amb context i abast, en pocs segons.

  • Rapidesa: qui escriu no espera que algú trobi un forat per redactar la incidència.
  • Qualitat: l'esborrany segueix sempre la mateixa estructura (què passa, per a qui, què s'espera).
  • Control: res entra en desenvolupament sense passar per una persona de l'equip.
  • Reutilitzable: el mateix patró serveix per a feedback públic i per a peticions internes.

Per a KM0 encaixa especialment bé: rebem idees de gent no tècnica i les volem tractar amb el mateix rigor que un informe d'un administrador de botiga online.

On s'aplica

Dues portes d'entrada, un recorregut

  • Qui fa servir KM0: el formulari Idees a km0digital.com. Suggeriments de producte, millores de la web o coses que trobes a faltar en usar el cloud.
  • Qui opera un projecte intern: la pantalla Admin Help d'una botiga online en staging. Quan algú de l'equip veu una fallada o necessita un canvi i vol deixar-ho registrat amb traçabilitat.

En ambdós casos el recorregut és el mateix: formulari → cua → ticket redactat → revisió humana → implementació. Canvia qui escriu i on, no la lògica.

Exemples

Com es veu a la pràctica

Imagina que algú envia des de Idees: «M'agradaria un botó per compartir entrades del blog». En uns quinze segons el sistema genera un ticket titulat i ordenat: què demana la persona, en quin idioma ha escrit, quina part del lloc toca. Apareix marcat com a pendent de validació humana.

Algú de l'equip el llegeix. Si el text està bé, treu la marca i el ticket passa a la cua d'implementació automàtica. Si cal matisar («només en mòbil», «icona de WhatsApp»), s'edita el ticket abans d'aprovar-lo. Sense tornar a copiar el missatge original a mà.

Un altre cas: un administrador de la botiga en staging informa des d'Admin Help que un filtre de productes no desa bé. Mateixa mecànica: ticket clar, revisió, i només llavors entra en el flux de desenvolupament. L'objectiu és que ningú hagi d'endevinar què volia dir qui va escriure.

Persones

Què fa (i què no) l'automatització

La màquina redacta i classifica. La persona decideix. Els agents de desenvolupament no recullen tickets mentre segueixin marcats com a pendents de validació: així evitem implementar a cegues un missatge ambigu o una broma.

Per a qui envia una idea, el benefici és simple: escrius una vegada en llenguatge normal i l'equip rep alguna cosa accionable. Per a qui manté el servei, el benefici és deixar de ser el traductor permanent entre «missatge de WhatsApp» i «ticket ben escrit».

Resultat

Què va aconseguir el dia 7

El pas manual entre «algú demana alguna cosa» i «hi ha un ticket que es pot implementar» desapareix en producció (idees públiques de KM0) i a l'entorn de proves de l'ecommerce (Admin Help).

Avui el cicle complet funciona: petició, ticket redactat, validació humana i implementació assistida per agents. És la peça que faltava per tancar el cercle entre escoltar la comunitat i lliurar canvis amb criteri.

Sèrie

Dies 1–6

Les entrades anteriors cobreixen el stack (OpenCloud, Dex, LDAP, clients natius, tutorials, visió). El dia 7 afegeix el bucle de feedback: prova el formulari d'idees o revisa el dia 6 per a onboarding en dispositius. Dubtes: contacte.