🤖 De un ticket de Linear a un PR — con agentes
Construye features y resuelve fixes de un ticket de Linear a un PR. Corre en Dify (apps raze-pipeline-rapark / -theriander).
01 · intake
Ticket Linear
RAZ-xx → el planner carga el contexto (AGENTS.md + feature-docs).
→
02 · plan
Plan + aprobás
Plan grounded (cita file:línea o dice UNKNOWN) → respondés APROBADO.
→
03 · dev
Developer
Escribe el código (el pipeline crea la branch y commitea; el dev no toca git).
→
04 · preview
Preview live + aprobás
Build por branch contra staging → lo mirás en vivo → respondés APROBADO.
→
05 · QA · review · docs
Verifica (auto)
Gate determinista + QA escéptico (Playwright) + reviewer del diff + docs — corre solo, cada paso avisa.
→
06 · PR
Pull Request
Push + PR a development (autor bot, reporte QA/review, @mention al reviewer) + mueve Linear a In Review.
✅ En producción — pipeline agéntico en Dify (apps raze-pipeline-rapark / -theriander). 2 gates humanos (plan + preview); el resto corre automático con gates deterministas. Modelos vía OpenCode Go.
🚦 El dashboard dispara, no deploya
Un release nunca sale directo. Dispara el pipeline DevOps, que valida antes y después. Manual (botón) o agendado (release train con guarda de commits).
🌐 Ambientes: staging se actualiza solo en cada push a development. Durante la ventana del release (dom→mar) staging pasa a mostrar el release candidate (release/<fecha>) — lo exacto que va a prod — y vuelve a development solo tras el deploy. Un badge chiquito en la app (y el ref acá arriba en cada env) dicen siempre qué corre. prod se sube con Release → prod (con gates) y se revierte con Rollback prod.
01 · trigger
Release
Manual (botón) o agendado (cron semanal, dom ~23 ART). Crea tag app-vAAAA.MM.DD.
→
02 · gate pre
Correctitud
¿El código está bien? Compila + tsc + unit + integración (RLS/RPC) + E2E funcional contra DB aislada. Bloqueante: rojo → no deploya.
→
03 · deploy
Ship a prod
SPA + edge functions vía key restringida. Tag + GitHub Release con changelog.
→
04 · gate post
Verificación LIVE
¿El deploy quedó sano? Playwright REAL contra prod (monta sin crash + flujos críticos). Si algo importante rompe → auto-rollback al build anterior + aviso.
🚦 Pre ≠ Post (cada gate una pregunta distinta): el gate pre prueba que el código es correcto (entorno aislado, exhaustivo); el gate post prueba que el deploy quedó sano en prod (rápido, en vivo, lo que solo se ve en producción). No repiten lo mismo. "Importante que no puede romperse" = los flujos de tests/prod-smoke/ de cada app → si uno falla, rollback automático.
🗓️ Lo hace solo (release train) o lo disparás vos — ⚙ por proyecto. Con el train activado, el ciclo semanal corre sin tocar nada: dom ~23 ART corta release/<fecha> desde development (fin del cycle) → se deploya a staging como release candidate → lunes = ventana de testeo (un hotfix al release branch redeploya staging solo) → martes = deploy a prod con los gates → back-merge a development y staging vuelve a dev. Con el train en Manual (estado actual), nada sale solo: el release lo apretás vos. El pipeline igual es 100% automático y gateado por tests — solo NO deploya si el gate PRE falla, y si el POST rompe hace rollback; siempre avisa en Slack.
✅ CONSTRUIDO y validado E2E — gate de tests aislado (migraciones + seed + integration + unit + build + E2E) bloqueante antes de cada release, + rollback 1-click. Los botones Release/Rollback disparan desde acá (backend con auth). La cadencia del release train se configura acá mismo (⚙ en cada proyecto), con guarda de commits.