INTERNAL-MID · personal · venezuela

Task Flow

cliente: internal (Arlex) · iniciado 2026-01-01

SCORE 59%

SELLO REQUIERE ≥ 80% faltan 21%

Outcome (Gate 0)

Fuente de verdad de tareas personales y de proyectos. Home del "founder operating system" — pulso del día, inbox de captura, profundidad por proyecto. Objetivo: Arlex ve estado real de todo sin tener que buscar en 5 lugares. Ya en uso: vida.arlexperalta.com.

Distribución · cómo llega al mercado

Tier · Interno

0/100

0 acciones pendientes en 0 dimensiones

SIN SELLO ✓ SELLO PLENO

D1 · Presencia pública

n/a

No aplica para este tier.

D2 · Audiencia propia (owned)

n/a

No aplica para este tier.

D3 · Contenido sistematizado

n/a

No aplica para este tier.

D4 · Lead magnet / activador

n/a

No aplica para este tier.

D5 · Outreach activo

n/a

No aplica para este tier.

D6 · Autoridad pública

n/a

No aplica para este tier.

D7 · Redes sociales

n/a

No aplica para este tier.

Producto · hacia dónde vamos

Misión

Founder operating system. Home de tareas, pulso del día y capa de profundidad por proyecto. Herramienta principal de Arlex para ver estado real sin buscar en múltiples lugares.

En qué estamos ahora

Uso diario en vida.arlexperalta.com. Pendiente: completar páginas del mockup (command, pulse, timeline), cubrir test coverage básico.

KPIs del producto

Daily active users

1 / 1 user

Uptime

99 / 99.5 %

Endpoints API

4 / 6 endpoints

Páginas mockup construidas

3 / 6 páginas

Test coverage

0 / 60 %

✓ Hechos 10

● vida.arlexperalta.com vivo
● 3 cerebros operativos (Groq triage + Claude API + Claude Code)
● 3 capas UI base (Pulso, Inbox, Profundidad)
● API-First con 4 consumidores (Web, Telegram, MCP, Monitor)
● Endpoint /api/tasks/stats con KPIs + 14d + 8w
● IDs de proyectos definidos y operativos
● Refactor pages dashboard a server components (descartado 2026-04-19, síntoma no se reproduce)
● httpOnly cookies en dev — COOKIE_SECURE sigue DEBUG (2026-04-19)
● Warnings ESLint — unused vars removed + no-img-element disabled (2026-04-19)
● Alembic fail-fast vía entrypoint.sh (2026-04-19)

⟳ En progreso 1

◐ Páginas faltantes del mockup HTML (command, pulse, timeline)

○ Pendientes 2

○ Tests cero en backend y frontend
○ Eventualmente: ser home del Plomada Dashboard

Protocol · cómo lo construimos

Entry

No se arranca sin que ambas partes sepan qué se va a construir y por qué.

100%

5 / 5

Evidence

Decisión interna de iniciar. Tier internal-mid (datos personales, no financiero, no multi-tenant).

Subgates

✓

Brief escrito (1 pág) con problema + outcome medible
✓

Tier asignado (Express / Professional / Enterprise / Internal)
✓

Clasificación inicial de datos (público / personal / sensible / crítico)
✓

Scope en/fuera explícito
✓

Pago inicial recibido (externos) / decisión documentada (internals)

Discovery

Entender contexto real antes de diseñar solución.

80%

4 / 5

Evidence

3 cerebros (Groq triage + Claude API análisis + Claude Code ejecución). 3 capas UI (Pulso, Inbox, Profundidad). IDs de proyectos definidos.

Subgates

✗

Sistemas actuales del cliente mapeados

Mapeo formal de qué OTROS sistemas quedan fuera (y por qué)
✓

Data mapping: origen, volumen, frecuencia
✓

Stakeholders y decisores identificados
✓

Documento de diagnóstico (1–2 páginas)
✓

Cliente reconoce su operación en el diagnóstico

Architecture

Diseño coherente antes de código.

85%

4 / 6

Evidence

API-First. 4 consumidores documentados (Web, Telegram, Claude Code MCP, Dante Monitor). Stack Next.js 15 + FastAPI + Postgres.

Subgates

✗

Design Doc con diagrama de componentes

Diagrama de arquitectura actualizado
✓

Stack justificado (qué y por qué)
✗

Flujos de datos principales documentados

Threat model básico (datos personales)
✓

Decisiones técnicas + trade-offs registrados
✓

Riesgos identificados + mitigación
✓

Plan de módulos en fases

Build

Código funcional, en repo, con CI.

75%

7 / 7

Evidence

Funcional en vida.arlexperalta.com. Endpoint /api/tasks/stats operativo (KPIs + 14d + 8w).

Subgates

✓

Código en repo Git (no local-only)
✓

Commits atómicos con mensajes estructurados
✓

CI configurado (tests/lint/build por push)
✓

Branch strategy clara
✓

No secrets en código (git-secrets scan)
✓

Dependencies lockfile committed
✓

README mínimo (stack, setup, deploy)

QA

Funcional y robusto antes de producción.

10%

1 / 6

Evidence

Pruebas manuales de uso personal.

Subgates

✗

Tests unitarios ≥60% en lógica crítica (≥70% Enterprise)
✗

Tests de integración de flujos principales
✓

Pruebas manuales (happy path + edge cases)
✗

Performance mínimo verificado

Performance audit (tiempos de carga)
✗

Accessibility WCAG AA para UIs públicas
✗

Code review por IA o humano (mínimo 1 pase)

Security Review

Checkpoint formal de seguridad antes de lanzar.

55%

6 / 9

Evidence

HTTP Basic Auth en subdominio. Tokens httpOnly cookies en prod. Contabo backups daily.

Subgates

✓

Datos clasificados y mapeados
✓

Auth/authz revisadas (multi-tenant: aislamiento verificado)
✓

Secrets en .env, git-secrets scan limpio
✗

npm audit / pip-audit sin CVEs críticas
✓

TLS 1.2+ configurado
✓

OWASP Top 10 revisado (SQLi, XSS, CSRF, SSRF)
✗

Rate limiting en endpoints públicos
✓

Logs auditables (quién, qué, cuándo, dónde)
✗

Plan de respuesta a incidente (mínimo 1 página)

Plan incidente (mi propia data)

Legal & Data Governance

Cumplimiento legal y manejo responsable de datos.

30%

8 / 11

Evidence

Uso personal. No hay terceros (todavía).

Subgates

✓

Contrato firmado con cliente
✗

Términos de uso públicos (si UI pública)

Si se abre a otros usuarios futuro: términos, privacidad, LOPD
✗

Política de privacidad (LGPD/LOPD según jurisdicción)

Si se abre a otros usuarios futuro: términos, privacidad, LOPD
✗

Base legal del tratamiento de datos identificada

Por ahora: doc interno de qué datos guardo, dónde, cuánto tiempo
✓

NDA con partners/colaboradores si aplica
✓

IP clara: código propietario vs open source
✓

Data retention policy escrita
✓

Data portability: cliente puede exportar
✓

Right to deletion implementado
✓

Audit trail activo
✓

Registro de marca iniciado si lleva nombre público

Launch

Producción estable con capacidad de rollback.

75%

3 / 8

Evidence

Producción en vida.arlexperalta.com + Contabo. Backups automáticos.

Subgates

✗

Deploy pipeline documentado (replicable)

Rollback plan documentado
✗

Monitoring activo (uptime, error rate, logs)

Runbook formal (Alembic startup silencia errores con 2>/dev/null)
✗

Rollback plan documentado + probado 1 vez

Rollback plan documentado
✗

Runbook operacional (restart, backup, restore)

Runbook formal (Alembic startup silencia errores con 2>/dev/null)
✓

Cliente entrenado en uso básico
✓

Health checks automáticos
✗

Alerting configurado (qué dispara, quién recibe)
✓

Sistema estable 72h post-launch sin emergencias

Documentation Check

Cualquiera puede entender y operar el sistema.

35%

4 / 8

Evidence

Commits estructurados. Algunos docs dispersos.

Subgates

✗

README técnico actualizado

README técnico consolidado
✗

Design doc de arquitectura vigente

Doc de arquitectura 3 cerebros + 3 capas
✗

Runbook operacional vigente

Runbook operacional
✓

Manual de usuario / onboarding cliente
✓

API docs (si hay API pública)
✓

Changelog inicial con versionado
✗

Diagrama de arquitectura actualizado

Doc de arquitectura 3 cerebros + 3 capas
✓

Doc 'qué hacer si Arlex no está'

Operate

El sistema no solo vive — cumple el outcome del cliente.

45%

3 / 9

Evidence

En uso diario por Arlex. Backups 4AM VE.

Subgates

✗

SLA definido (response time, uptime target)
✓

Canal de soporte activo
✗

Backups automáticos + probados (restore real ≥1 vez)
✓

Rotación de secrets en calendario
✗

Updates de dependencias mensuales

Updates dependencias
✗

Reportes periódicos al cliente

SLA personal (yo mismo soy cliente)
✗

★ Outcome de Gate 0 VERIFICADO (medición real vs objetivo)

Outcome verificado: ¿soy más productivo con Task Flow?
✗

Retrospectiva a los 90 días

Retrospectiva 90 días
✓

30 días de operación estable