team-review

PredatorAlgo Landing

Período: 2026-05-27 → 2026-06-24 · Generado por: oscar · 2026-06-29 12:00 · Fuentes: jira, github, code

PredatorAlgo Landing — Cronología, entregas y madurez

Versión cliente del informe de equipo: incluye la línea de tiempo día por día, las entregas por área funcional, los pendientes reales en Jira y la conclusión honesta de madurez del proyecto por la IA. Datos reales de Jira (SD-1170) + GitHub (predatoralgo) + lectura del código; nada inventado; agrupado por equipo, no por persona.

⏱️ Duración real: 19 días laborales. El período del 27 de mayo al 24 de junio de 2026 abarca 28 días corridos, de los cuales se descuentan sábados, domingos y 2 feriados nacionales de Bolivia (Corpus Christi, 4 de junio y Año Nuevo Andino, 21 de junio) → quedan 19 días laborales. El equipo tuvo actividad en 20 días — es decir, trabajó todos los días hábiles y además el feriado de Corpus Christi (15 commits el 4 de junio). No hubo días muertos dentro de la jornada hábil.

1. Línea de tiempo — día por día

Cada día es un desplegable: el título resume qué se hizo; al abrirlo se ven los tickets y la actividad (cerrados · commits · PRs). Por defecto están colapsados. Fines de semana y feriados omitidos. En los días sin tickets cerrados se muestran las tareas en progreso y los commits.

Semana 1 — Scaffold, dominio y tooling (27–29 may)

Mié 27 may — Arranque del repositorio (commit inicial). Sin tickets cerrados aún.

En progreso: scaffold inicial del proyecto.

Commits del día (1): Initial commit.

Actividad: 0 done · 1 commit · 0 PRs

Jue 28 may — Scaffold de la landing V1 (reframe + listo para lanzar), conexión del dominio predatoralgo.com (Hostinger + Cloudflare) e infraestructura de agentes de Claude + comandos de PR.

Tickets: SD-1172, SD-1185, SD-1173 · 3 done · 19 commits · 3 PRs

Vie 29 may — Configuración de Cloudflare y Vercel apuntando al dominio real predatoralgo.com; importación y adaptación de los comandos de IA al proyecto.

Tickets: SD-1200, SD-1183 · 2 done · 9 commits · 2 PRs

Semana 2 — Branding, specs y arquitectura de pagos (1–5 jun)

Lun 1 jun — Sin tickets cerrados: limpieza visual de la landing (unificar fondos, quitar secciones) en curso.

En progreso (referido en commits): SD-1202.

Commits del día (4): unificar fondos de secciones con grilla de decoración · quitar la sección Trading Journal de la landing · ignorar caché de tooling.

Actividad: 0 done · 4 commits · 1 PR

Mar 2 jun — Branding y assets de la landing (fondos oficiales, mejoras de logo y copy, imagen del hero con el gráfico de TradingView) y setup de tooling de desarrollo (Supabase agents/skills, MCPs, GGA, OpenSpec).

Tickets: SD-1184, SD-1198, SD-1214, SD-1216, SD-1202, SD-1218, SD-1224 · 7 done · 26 commits · 4 PRs

Mié 3 jun — Lectura de documentación y creación/refinamiento de las tareas del proyecto; rediseño de precios (Pro/Lifetime) y el spike de arquitectura de Stripe (contrato + smoke-test).

Tickets: SD-1212, SD-1227, SD-1260, SD-1232, SD-1243 · 5 done · 23 commits · 3 PRs

Jue 4 jun *(feriado de Corpus Christi — trabajado)* — Stack tipográfico y tokens de color de marca; productos, precios y checkout de Stripe (con 2 campos personalizados) + infraestructura de tests (Vitest).

Tickets: SD-1230, SD-1244, SD-1268 · *(SD-1199 marcado "no se hará", reemplazado por SD-1244)* · 5 done · 15 commits · 3 PRs

Vie 5 jun — Sin tickets cerrados: páginas y cliente de TradingView en curso.

En progreso (referido en commits): SD-1236 (página /about), SD-1264 (esquemas y cliente HTTP endurecido de TradingView).

Commits del día (2): construir la página /about (brand-story) · lib/tradingview schemas + expiración + cliente HTTP endurecido.

Actividad: 0 done · 2 commits · 0 PRs

Semana 3 — Páginas, checkout y automatización de acceso (8–12 jun)

Lun 8 jun — Páginas del sitio (/pricing, /about, /faq), motivo visual "reticle" (glow + scanline), página /checkout/success y cumplimiento de auto-renovación §7.4 (nativo de Stripe).

Tickets: SD-1233, SD-1236, SD-1249, SD-1231, SD-1269, SD-1246, SD-1247, SD-1271 · 8 done · 33 commits · 6 PRs

Mar 9 jun — Día intenso: páginas /how-it-works y /education, contenido de FAQ, navbar; wiring del checkout de Stripe (server action), correcciones de variables de entorno de Stripe en producción; primeros bloques de automatización (cliente TradingView, estado en Redis).

Tickets: SD-1234, SD-1235, SD-1239, SD-1250, SD-1281, SD-1270, SD-1278, SD-1279, SD-1282, SD-1288, SD-1254, SD-1256, SD-1280 · 13 done · 38 commits · 9 PRs

Mié 10 jun — [AUTO-2] Webhook de Stripe (otorgar/extender/revocar acceso), auditoría de Claims Policy, completar SEO y harness de tests de pago/acceso.

Tickets: SD-1255, SD-1240, SD-1242, SD-1251 · 4 done · 27 commits · 7 PRs

Jue 11 jun — [AUTO-4] Cola de fallback híbrida + ruta de grant manual, reconciliación del home con el Bible §5.1, consentimiento de marketing en el checkout (3er campo) y ajustes de política de reembolso.

Tickets: SD-1257, SD-1229, SD-1252, SD-1296, SD-1293, SD-1294, SD-1299, SD-1241 · 8 done · 38 commits · 9 PRs

Vie 12 jun — Automatización de Telegram: [AUTO-6] invite de un solo uso, [AUTO-7] tracking y expulsión de miembros (captura de user_id al unirse) y el [T-26] dashboard de operaciones (colas + grant/revoke/refund).

Tickets: SD-1259, SD-1308, SD-1253 · 3 done · 29 commits · 4 PRs

Semana 4 — Pivot sin-trial, go-live y panel de admin (15–19 jun)

Lun 15 jun — Pivot del modelo de cobro: se elimina el trial de $1/10 días → suscripción directa con reembolso de 7 días; [AUTO-5] cron de revocación + reconciliación, ops de Telegram en el dashboard y reconciliación de la ventana de reembolso (10d→7d).

Tickets: SD-1300, SD-1301, SD-1302, SD-1258, SD-1311, SD-1313, SD-1328 · 7 done · 29 commits · 8 PRs

Mar 16 jun — Cancelación self-serve por el Customer Portal de Stripe, clasificación de fallos permanentes/transitorios en el webhook, cupón dev (99% off) tras feature flag, GA4 + eventos de conversión y "Save TV username" que también otorga acceso.

Tickets: SD-1332, SD-1337, SD-1338, SD-1284, SD-1339, SD-1303, SD-1325, SD-1289 · 8 done · 29 commits · 6 PRs

Mié 17 jun — Runbook de fallback (operador: grant/revoke/refund), suite E2E con Playwright (landing + funnel de checkout + manage-subscription) y refresh de la landing (hero video, Features & How-It-Works).

Tickets: SD-1245, SD-1292, SD-1347, SD-1345 · 4 done · 20 commits · 3 PRs

Jue 18 jun — *Día pico.* Stripe go-live (cobro real con claves y precios live) + dominio de email propio (@predatoralgo.com con DKIM/DMARC); soporte de múltiples indicadores invite-only (TV_PINE_IDS), legal (disclaimer + billing), cookie policy + banner de consentimiento, testing manual completo y fixes de UX móvil.

Tickets: SD-1283, SD-1350, SD-1237, SD-1352, SD-1351, SD-1363, SD-1358, SD-1353, SD-1355, SD-1360, SD-1361, SD-1349, SD-1357, SD-1346, SD-1359 · 15 done · 40 commits · 10 PRs

Vie 19 jun — Revisión meticulosa de cumplimiento de todas las páginas legales, mejoras del panel de admin (cola de grant manual con email+usuario TV, botón Diagnose, "Refresh payment" por fila, persistir tab por query param) y tests manuales de update/cancel por el portal.

Tickets: SD-1367, SD-1365, SD-1370, SD-1369, SD-1371, SD-1366, SD-1372, SD-1362, SD-1364 · 9 done · 26 commits · 6 PRs

Semana 5 — Cierre: lifetime, Telegram y legal (23–24 jun)

Mar 23 jun — Username de Telegram opcional en el checkout y purga del @username en todo el flujo; fix del checkout Lifetime (pago único no otorgaba acceso porque session.customer venía null); email de soporte y gate de checklist pre-lanzamiento.

Tickets: SD-1368, SD-1385, SD-1386, SD-1383, SD-1384, SD-1248 · 6 done · 9 commits · 3 PRs

Mié 24 jun — Clientes Lifetime ahora pueden unirse/ser gestionados en Telegram (re-key del flujo desde subscriptionId a customerId) y fix del email de contacto legal + redes del footer. Último día de actividad del período.

Tickets: SD-1390, SD-1394 · 2 done · 5 commits · 2 PRs

2. Entregas por área funcional (scope)

Todo lo entregado (106 Done), agrupado por área.

#	Área (scope)	Período activo	Qué se construyó
1	Pagos y checkout (Stripe)	3 – 19 jun	Productos/precios Pro y Lifetime, checkout con campos personalizados, auto-renovación §7.4, pivot a suscripción directa (sin trial, reembolso 7 días), Customer Portal, cupones, go-live real
2	Automatización de acceso (webhook → TradingView + Telegram)	9 – 24 jun	`[AUTO-1..8]`: cliente TradingView endurecido, estado en Redis, webhook grant/extend/revoke, cola de fallback + grant manual, cron de revocación/reconciliación, invite único de Telegram, tracking/expulsión de miembros, ops manuales
3	Landing y sitio	2 – 23 jun	Home, /pricing, /about, /how-it-works, /education, /faq, navbar, footer, copy alineado al Bible, UX móvil, success page
4	Branding y diseño	2 – 18 jun	Fondos oficiales, logo, tipografía y tokens de color, motivo "reticle" (glow/scanline), hero video optimizado
5	Legal y compliance	10 – 24 jun	Disclaimer, billing, claims policy, cookie policy + banner de consentimiento, revisión meticulosa de páginas legales
6	Infraestructura y DevOps	28 may – 23 jun	Dominio (Hostinger/Cloudflare/Vercel), email corporativo + DKIM/DMARC, Redis (Upstash), harness de tests, CI
7	Tooling IA / Claude Code	28 may – 4 jun	Infra de agentes, comandos de PR, MCPs, GGA, OpenSpec — productividad interna
8	SEO y analítica	10 – 18 jun	SEO completo, GA4 + eventos de conversión, tracking de join a Telegram
9	Dashboard de administración	15 – 19 jun	Cola de grant manual (email + usuario TV), Diagnose, "Refresh payment" por fila, persistencia de tab

Nota: 6 tickets transversales (lectura de documentación y creación de tareas del Bible, confirmación de comportamiento v2.3, CSP, gate de checklist pre-lanzamiento) no se asignan a una sola área. La automatización de acceso (filas 2) es el corazón técnico del producto: conecta el pago con el acceso real a TradingView y Telegram.

3. Pendientes (estado real en Jira)

De los 111 tickets de la épica, 5 no están Done:

Ticket	Qué es	Estado
SD-1171	Crear los indicadores en TradingView	In Review
SD-1238	[T-10] Revisión legal por asesor externo (pendiente de Rafael)	To Do
SD-1199	Implementar pago Stripe (checkout de suscripción) — reemplazado por SD-1244	Won't Do
SD-1289	[T-14c] CSP con nonce obligatorio (pasar de Report-Only)	Won't Do
SD-1292	[T-24 follow-up] Tests de webhook + cola de fallback + Playwright E2E adicionales	Won't Do

Los pendientes reales son pocos: el principal gate de negocio es la revisión legal externa (depende del cliente/Rafael) y dejar publicados los indicadores en TradingView.

4. 🤖 Conclusión de la IA — madurez del proyecto (análisis sincero)

Esta sección fue generada por la IA (Claude). Es una valoración honesta e independiente —no un argumento de venta—, basada en los datos de Jira/GitHub y en la lectura del código real del repositorio y de su spec/"Bible" (.docs/creation-tasks/SD-1212-…).

Veredicto: funcional, pero arquitectónicamente inmaduro (por diseño deliberado y documentado).

PredatorAlgo cumple su objetivo de MVP —vender acceso, otorgarlo automáticamente al pagar y revocarlo al

cancelar— y lo hace con piezas de buena calidad. Pero no es un producto con backend real, y eso marca un

techo claro de escalabilidad y mantenibilidad.

Lo que está sólido (funcional):

🟢 Flujo de pago y acceso de calidad de producción. Webhook de Stripe con verificación de firma,

idempotencia (Redis), cola de fallback y cron de reconciliación; cobro real en vivo desde el 18 jun.

🟢 Automatización de acceso real. El pago dispara acceso a TradingView y un invite único de Telegram,

con tracking y expulsión automática — no es una maqueta.

🟢 Buenas prácticas de ingeniería en lo que existe: módulos separados (lib/stripe, lib/redis,

lib/tradingview, lib/telegram), helpers tipados, tests Vitest y CI en cada PR.

Lo que lo hace inmaduro en arquitectura (con evidencia en el código):

🟡 No hay backend real — Stripe es la "base de datos". El dashboard se arma con una llamada en vivo a

Stripe (stripe.customers.list, tope de 100 clientes, sin paginación), y el estado de negocio (plan,

access_granted, usuario TV/Telegram) vive como metadata de texto en Stripe, sin esquema, migraciones

ni integridad referencial. La única persistencia propia es Redis (estado operacional).

🔴 No hay autenticación de aplicación. El panel de administración depende **enteramente de una política

de Cloudflare Access en el borde; no hay login, sesión, roles (RBAC) ni tabla de usuarios. Es un único

punto de fallo**: si esa política se desconfigura, todo el panel (datos de clientes, acciones de grant)

queda públicamente accesible.

🔴 NowPayments (cripto) no existe — ni stub ni parcial. El spec lo declara fuera de alcance de esta

iteración. Para soportarlo hay que construir la integración completa (webhook, idempotencia, mapeo de

acceso) desde cero.

Conclusión. Para algo rápido y de lanzamiento, usar Stripe como fuente de verdad está bien y fue

una decisión correcta y documentada en el Bible (que difiere Supabase/auth/NowPayments a V1.5/V2). Pero para

que el producto crezca —que funcione NowPayments, y que exista un **dashboard real con usuarios

autenticados y autorizados— hay que reestructurar este pseudo-backend (Stripe-como-DB) a un backend real**

(p. ej. Supabase/Postgres + capa de auth/autorización). En síntesis: **funcional para su MVP, pero inmaduro

en arquitectura (escalabilidad y mantenibilidad)**; el siguiente salto del producto exige esa reestructuración,

no más parches sobre Stripe.

_— Análisis generado por Claude (IA). Sincero e independiente; basado en datos reales de Jira/GitHub y en la lectura del código del proyecto. (ver el informe completo)_

_Fuentes: Jira épica SD-1170 y GitHub swissbull-group/predatoralgo + lectura del código, extraídos en vivo el 29 jun 2026. Informe por equipo (no por persona). Nada inventado._