Skip to content

Roadmap Consolidado — FuaFlow Ecosystem

Auto-generado por GitHub Actions. No editar manualmente.

Ultima actualizacion: 2026-03-24

bip-project

Estado actual: Fases 0-4 implementadas, 45 paginas, 101 tests, CI configurado. Supabase no conectado.

Tecnico

P0 - Bloquean el lanzamiento

  • [ ] Conectar Supabase real - Crear proyecto, ejecutar los 10 SQL schemas en orden, configurar .env con URL y anon key reales
  • [ ] Corregir RLS de perfiles - La politica actual solo permite leer el propio perfil (auth.uid() = id), lo que rompe todos los joins perfiles(nombre, apellido_paterno, ciudad) en alertas, reportes, comentarios y chat. Crear vista publica o politica de lectura para campos no sensibles
  • [ ] Implementar edge function send-push - src/lib/notifications.ts llama a supabase.functions.invoke("send-push") pero la funcion no existe. Crearla con web-push para enviar notificaciones push reales
  • [ ] Normalizar trigger de notificacion al circulo - notify_circle_on_alert busca contactos BIP por coincidencia exacta de telefono. Formatos diferentes (con/sin lada, espacios) causan que no funcione
  • [ ] Eliminar stats falsos de la landing - "10,000+ ciudadanos activos", "500+ reportes", "50+ ciudades" son hardcoded. Conectar a datos reales o reemplazar con propuesta de valor sin numeros
  • [ ] Generar y configurar VAPID keys - Ejecutar npx web-push generate-vapid-keys, configurar publica en .env y privada en la edge function

P1 - Necesarios antes de usuarios reales

  • [ ] Navegacion para paginas huerfanas - 12 paginas sin link desde nav: /estadisticas, /comunidades, /chat, /favoritos, /reporte-rapido, /rutas, /buscar, /admin, /acerca, /terminos, /privacidad, /insignias
  • [ ] Confirmacion antes de SOS - El boton SOS no pide confirmacion. Un toque accidental envia alerta real a todo el circulo
  • [ ] Manejo de errores en Supabase - La mayoria de .insert(), .update(), .delete() no verifican el campo error. El usuario no ve mensaje si falla
  • [ ] Validacion de formularios - Registro: no valida formato email ni fuerza de contrasena. Perfil: CURP acepta cualquier texto (falta regex). Reportes: no valida tipo de imagen
  • [ ] Expirar ubicaciones compartidas - La tabla ubicaciones tiene expira_at pero nada desactiva ubicaciones expiradas. Crear cron job o trigger
  • [ ] E2E tests - Cero tests de flujos completos. Minimo: registro → login → crear alerta → verificar en mapa → resolver
  • [ ] Tests de componentes criticos - Sin cobertura: useAlerts, useReports, useChat, useBadges, useGeofence, useNotifications, Navbar, BottomNav, MapView, CommentSection, FlagButton
  • [ ] Monitoreo y logging - Sin Sentry, sin logging estructurado, sin alertas de error. Los console.error no llegan a ningun servicio

P2 - Calidad para escalar

  • [ ] Paginacion en feeds - Alertas, reportes, propuestas y notificaciones limitados a 50-100 items sin "cargar mas"
  • [ ] Rate limiting server-side - El rate limit del SOS es solo en localStorage (bypasseable). Implementar en RLS o edge function
  • [ ] Optimizar re-renders del mapa - Cada cambio en alertas recarga toda la lista y re-renderiza el mapa completo. Memoizar marcadores
  • [ ] Consolidar cliente Supabase - createClient() se llama multiples veces en el mismo componente. Usar singleton o context provider
  • [ ] Extraer haversine a lib/geo.ts - La formula esta duplicada en useAlerts.ts, useReports.ts, useGeofence.ts. Ya existe lib/geo.ts pero los hooks no lo usan
  • [ ] Reducir uso de any - Varios archivos usan eslint-disable @typescript-eslint/no-explicit-any. Usar tipos generados por Supabase CLI
  • [ ] Accesibilidad - Sin audit de a11y. Falta: aria-labels, focus management, contraste, lectores de pantalla
  • [ ] Performance - Sin audit de Lighthouse. Leaflet se importa completo, bundle size no optimizado

Comercial

Identidad y posicionamiento

  • [ ] Definir propuesta de valor diferenciada - Competidores: Citizen, Neighbors (Ring), Alertux. BIP se diferencia por el enfoque en Mexico (numeros de emergencia locales, CURP, espanol) y organizacion comunitaria
  • [ ] Branding profesional - El logo actual (biplogo.png) necesita version profesional. Definir guia de marca, paleta, tipografia
  • [ ] Landing page orientada a conversion - La actual es funcional pero generica. Necesita: social proof real, screenshots, video demo, CTA claro
  • [ ] Dominio y SSL - Configurar dominio personalizado en Vercel (ej: bip.mx, bipapp.mx)
  • [ ] Revision legal de terminos y privacidad - Los textos actuales son plantillas genericas. Requieren revision por abogado mexicano, especialmente por LFPDPPP (Ley Federal de Proteccion de Datos Personales)
  • [ ] Aviso de privacidad conforme a ley mexicana - Debe incluir: responsable, finalidades, transferencias, medios para ejercer derechos ARCO
  • [ ] Consentimiento explicito de geolocalizacion - La app usa GPS pero no muestra aviso de consentimiento mas alla del permiso del navegador
  • [ ] Politica de datos medicos - El QR medico almacena datos de salud (datos sensibles segun LFPDPPP). Requiere consentimiento explicito y medidas de seguridad reforzadas

Go-to-market

  • [ ] Beta cerrada - Reclutar 50-100 usuarios en una colonia/zona de CDMX. Validar: adopcion, frecuencia de uso, tipos de reporte, tiempo de respuesta del circulo
  • [ ] Metricas de producto - Implementar analytics (Mixpanel, PostHog, o similar): activacion, retencion, alertas enviadas, reportes creados, usuarios activos diarios
  • [ ] Onboarding guiado - No hay tutorial ni flujo de bienvenida. El usuario llega al dashboard sin contexto. Crear: tour de features, setup de circulo de confianza, primer check-in
  • [ ] Modelo de negocio - Definir: freemium, B2G (gobierno), B2B (fraccionamientos/edificios), donaciones, o combinacion. La infraestructura actual es $0 pero no escala gratis
  • [ ] Canal de soporte - Sin forma de contactar soporte. Agregar: email de contacto, formulario de feedback, FAQ
  • [ ] App stores - Publicar como TWA en Google Play. Evaluar wrapper nativo para iOS si se necesita acceso a APIs nativas

Bloqueos

Problemas que impiden avanzar sin decision o recurso externo.

Bloqueo Impacto Necesita
Supabase sin conectar Nada funciona con datos reales 30 min de configuracion + ejecutar SQL
RLS de perfiles Nombres de otros usuarios no aparecen en alertas, reportes, chat Decidir: vista publica vs politica SELECT ampliada
Edge function send-push Push notifications no se envian Crear funcion en Supabase con clave VAPID privada
Revision legal No se puede lanzar sin aviso de privacidad conforme Abogado con experiencia en LFPDPPP
Validacion con usuarios reales No hay datos de si la app resuelve un problema real Beta cerrada con 50+ usuarios
Modelo de negocio Sin ingresos no hay sostenibilidad Decision de negocio: freemium, B2G, B2B
Dominio No hay URL propia para compartir Registrar dominio .mx

Orden sugerido

1. Conectar Supabase + corregir RLS + VAPID keys          (1-2 dias)
2. Confirmacion SOS + manejo de errores + validacion       (2-3 dias)
3. Edge function send-push                                  (1 dia)
4. Navegacion completa + landing sin stats falsos           (1 dia)
5. E2E tests + tests de componentes criticos               (3-5 dias)
6. Beta cerrada con usuarios reales                        (2-4 semanas)
7. Iterar basado en feedback de beta                       (continuo)
8. Revision legal + dominio + branding                     (paralelo)
9. Metricas + onboarding + modelo de negocio               (post-beta)

EXR

Estado actual: motor de encoding funcional con 58 tests, CI verde, encriptación AES-256-GCM, formato .pvault estable. No hay GUI, CLI, empaquetado, ni servidor de licencias en producción.

Tecnico

Empaquetado e instalacion

  • [ ] Crear pyproject.toml con metadata y entry points (pip install . debe funcionar)
  • [ ] Agregar CLI: pvault pack, pvault unpack, pvault info
  • [ ] Eliminar los hacks de sys.path.insert en playground/ y verify_setup.py

Cobertura de tests

  • [ ] Tests para IntegrityScanner (integrity.py) — 0 tests, 0 uso interno
  • [ ] Tests para TriadicRelationalFramework (triadic_logic.py) — 0 tests
  • [ ] Tests para get_hwid (fingerprint.py) — 0 tests
  • [ ] Tests para LicenseClient (license_client.py) — 0 tests, requiere mock del servidor
  • [ ] Test de path traversal explícito en packer.py (crafted tar con ../)
  • [ ] Test con archivos >1 GB para validar uso de memoria

Rendimiento y escalabilidad

  • [ ] engine.info() lee el archivo completo en RAM solo para mostrar metadata — leer solo el header
  • [ ] Streaming de frames en pack/unpack para archivos grandes (evitar cargar todo en memoria)
  • [ ] Evaluar LZMA preset 3 vs 6 para archivos >2 GB (tradeoff velocidad/compresion)

Robustez

  • [ ] Escritura atomica del .pvault (escribir a .tmp, renombrar al final) para evitar archivos parciales si el disco se llena
  • [ ] Logging cuando packer.py descarta miembros no regulares del tar (symlinks, devices, FIFOs)
  • [ ] Soporte para Windows long paths (\\?\ prefix) en archivos con rutas >260 chars
  • [ ] config.py referencia .env.test que no existe — eliminar o crear template

Deuda tecnica

  • [ ] FLAG_SPLIT en format.py definido pero nunca usado — decidir: implementar split archives o eliminar
  • [ ] Docstrings mezclados español/ingles — unificar a un idioma
  • [ ] is_pro en VaultEngine solo desactiva GPU — no hay feature gating real
  • [ ] Limpiar __pycache__/ local (contiene .pyc de modulos eliminados)

Seguridad

  • [ ] license_client.py tiene SECRET_KEY default en codigo fuente publico — el guard en linea 82 lo mitiga pero depende de comparacion con string exacto
  • [ ] Agregar certificate pinning en license_client.py para requests al servidor de licencias
  • [ ] fingerprint.py fallback (hostname) es spoofable — evaluar alternativas

Comercial

Distribucion

  • [ ] Crear releases con git tags (no hay ninguno a pesar de versiones v1.5, v1.7 en commits)
  • [ ] Build de binario standalone (PyInstaller o Nuitka) para usuarios sin Python
  • [ ] Publicar en PyPI como paquete instalable

Servidor de licencias

  • [ ] Desplegar EXR-privado/licensing/server.py en produccion (Railway, Fly.io, etc.)
  • [ ] Configurar PV_SECRET_KEY como secreto de entorno en el servidor
  • [ ] Conectar dominio api.fuaflow.com o subdominio dedicado
  • [ ] Implementar dashboard de licencias (activaciones, revocaciones, metricas)

Producto

  • [ ] GUI desktop (vive en EXR-privado, depende de este engine como libreria)
  • [ ] Documentacion de usuario (guia de uso, FAQ, troubleshooting)
  • [ ] Landing page con descarga en fuaflow.com (botones APK actualmente dicen "Proximamente")
  • [ ] Verificar que BUSL-1.1 cubre el caso de uso comercial deseado
  • [ ] Definir terminos de la licencia Pro vs Free
  • [ ] Preparar Terms of Service y Privacy Policy para fuaflow.com

Bloqueos

Bloqueo Impacto Dependencia
No hay pyproject.toml El engine no se puede instalar como paquete — EXR-privado y cualquier consumidor dependen de hacks de sys.path Ninguna, se puede hacer ya
Servidor de licencias no desplegado LicenseClient apunta a URL placeholder que no responde — activacion/verificacion de licencias no funciona Necesita deploy de EXR-privado/licensing/ + secretos de entorno
Sin CLI Solo se puede usar como libreria Python con imports manuales — no hay forma de usarlo desde terminal Depende de pyproject.toml con entry points
4 modulos sin tests integrity, triadic_logic, fingerprint, license_client no tienen cobertura — cualquier refactor puede romperlos sin aviso Ninguna, se puede hacer ya
info() carga archivo completo en RAM Para vaults de varios GB, engine.info() consume RAM innecesariamente — bloquea uso en sistemas con poca memoria Ninguna, requiere refactor de parse_container para leer solo header

EXR-privado

Estado actual del proyecto hacia release comercial.

Bloqueos

Cosas que impiden lanzar a producción.

Iconos y branding

  • [ ] Crear desktop/icon.ico (256x256) para Windows builds
  • [ ] Crear desktop/icon.png (256x256) para Linux AppImage — actualmente genera un placeholder 1x1 (build_linux.py:169)
  • [ ] Agregar icono a macOS build (build_macos.py)
  • [ ] Favicon para website/index.html

Versión unificada

  • [ ] Sincronizar versión en todos los archivos — actualmente:
  • pixelvault/__init__.py → 1.0.0
  • desktop/app.py:63 → v1.0
  • desktop/build_nuitka_windows.py:35 → 1.0.2.0
  • desktop/installer.iss:14 → 1.0.2
  • desktop/build_macos.py:71 → 1.0.0
  • [ ] Hacer que desktop/app.py lea version de pixelvault.__version__ en vez de hardcodear

Secrets en producción

  • [ ] Generar PV_SECRET_KEY real (min 32 chars) y configurar en Railway
  • [ ] Obtener PV_WEBHOOK_SECRET de LemonSqueezy y configurar en Railway
  • [ ] Generar PV_ADMIN_TOKEN y configurar en Railway
  • [ ] El cliente (license_client.py:15) tiene fallback "CHANGE_ME_set_PV_SECRET_KEY_env_var" — en release builds este valor debe venir del entorno o embeberse en build
  • [ ] El servidor (server.py:23) tiene fallback "pixelvault_shared_secret_placeholder_2026" — nunca debe llegar a producción

Code signing

  • [ ] Obtener certificado de firma de código para Windows (EV o estándar)
  • [ ] Firmar .exe con signtool — sin esto aparece "Editor desconocido" en SmartScreen
  • [ ] Configurar codesign + notarización para macOS — sin esto Gatekeeper bloquea la app

Documentos legales

  • [ ] Redactar Privacy Policy (requerido por GDPR/CCPA — el software no colecta datos, pero el licensing server sí procesa email + HWID)
  • [ ] Redactar Terms of Service
  • [ ] Publicar ambos en website/ y linkear desde la app

Técnico

Seguridad del licensing server

  • [ ] Agregar rate limiting a /activate y /webhook/lemonsqueezy — actualmente sin protección contra brute force
  • [ ] Agregar CORSMiddleware en server.py — la variable ALLOWED_ORIGINS está en .env.example pero no se usa en el código
  • [ ] Reemplazar datetime.utcnow() por datetime.now(datetime.UTC) — deprecado en Python 3.12+ (warnings en tests)

Base de datos

  • [ ] Configurar Railway Volume en /data para persistencia de SQLite — actualmente efímero (se pierde en cada redeploy)
  • [ ] Evaluar migración a PostgreSQL para alta disponibilidad
  • [ ] Agregar Alembic para migraciones de schema

Dependencias faltantes

  • [ ] Agregar a requirements.txt (o crear requirements-streaming.txt):
  • pyvirtualcam — usado en stream_vcam_sender.py
  • mss — usado en stream_remote_host.py
  • pynput — usado en stream_remote_client.py y stream_remote_host.py

Tests faltantes

  • [ ] tests/test_integrity.py — IntegrityScanner no tiene tests
  • [ ] tests/test_triadic_logic.py — TriadicRelationalFramework no tiene tests
  • [ ] tests/test_fingerprint.py — get_hwid() es crítico para licencias y no tiene tests

CI/CD

  • [ ] Agregar workflow de deploy automático del licensing server a Railway
  • [ ] Agregar workflow de build de .exe (PyInstaller/Nuitka) en GitHub Actions
  • [ ] Agregar workflow de release con versionado automático
  • [ ] Agregar build de AppImage (Linux) y DMG (macOS) en CI

Builds multiplataforma

  • [ ] Validar build Linux AppImage en Ubuntu real (build_linux.py)
  • [ ] Validar build macOS DMG en macOS real (build_macos.py)
  • [ ] Testear desktop app en Linux y macOS (actualmente solo Windows verificado)

Calidad de código

  • [ ] Resolver warning de tar.extract() sin filtro — Python 3.14 lo bloqueará (packer.py:116)
  • [ ] Agregar tar.extract(member, path=output_dir, filter='data') para compatibilidad futura

Monitoreo

  • [ ] Configurar uptime monitoring para el licensing server (UptimeRobot o similar)
  • [ ] Evaluar Sentry para error tracking en el servidor
  • [ ] Agregar structured logging (JSON) para Railway logs

Comercial

Pagos (LemonSqueezy)

  • [ ] Crear cuenta y producto "PixelVault Pro" en LemonSqueezy
  • [ ] Configurar webhook order_created apuntando a /webhook/lemonsqueezy
  • [ ] Obtener signing secret y configurar PV_WEBHOOK_SECRET
  • [ ] Actualizar link de checkout en website/index.html
  • [ ] Testear flujo completo: compra → webhook → licencia creada → email enviado → activación en app

Email de licencias

  • [ ] Obtener cuenta y API key de Resend (o SendGrid)
  • [ ] Configurar RESEND_API_KEY en Railway
  • [ ] Verificar dominio de envío ([email protected])
  • [ ] Testear que el email llega con la license key después de una compra

Website

  • [ ] Verificar links de descarga del .exe en website/index.html
  • [ ] Verificar link de compra Pro apunta al producto correcto de LemonSqueezy
  • [ ] Configurar hosting (Vercel, Netlify, o GitHub Pages)
  • [ ] Configurar dominio custom y SSL

Distribución

  • [ ] Subir release builds a GitHub Releases (o hosting propio)
  • [ ] Configurar auto-update mechanism (o al menos check-for-update en la app)
  • [ ] Preparar página de descarga con checksums SHA-256

Mobile

  • [ ] Status actual: solo existe mobile/planimplementacion.md — no hay código
  • [ ] Decisión pendiente: Kivy, Flutter, o React Native
  • [ ] No es bloqueante para v1.0 desktop — puede ser v2.0

Soporte

  • [ ] Configurar canal de soporte (email [email protected] o helpdesk)
  • [ ] Escribir FAQ / guía de troubleshooting
  • [ ] Documentar proceso de desactivación y transferencia de licencia entre dispositivos

Prioridades sugeridas

Fase 1 — Mínimo viable para lanzar (desktop Windows): 1. Iconos y branding 2. Versión unificada 3. Code signing Windows 4. Secrets en producción + Railway volume 5. LemonSqueezy + email integración 6. Privacy Policy + ToS 7. Rate limiting + CORS

Fase 2 — Estabilización: 1. Tests faltantes 2. CI/CD automation 3. Monitoreo 4. Website hosting + dominio 5. FAQ y soporte

Fase 3 — Expansión: 1. macOS build + code signing + notarización 2. Linux AppImage 3. Auto-update 4. Mobile (v2.0)

fuaflow-ai-backend

Estado actual: v1.1 contract-fix — 346 LOC en monolito single-file, 19 tests (11 smoke + 8 contract), deploy configurado para Railway. Contrato API con Triadic Cloud alineado.

Repo privado, 1 contribuidor, CI configurado en master, sin releases ni tags. Parte del ecosistema FuaFlow (26 repos, 5 públicos, 21 privados).

Arquitectura desplegada

Love-Log (Flutter)      ──→  https://ai.fuaflow.com   ──→  https://api.fuaflow.com
FuaFlow-CRM (Flutter)        (este backend, Railway)        (triadic-cloud, Railway)
   ↕ P2P sync (settings)                                         ↓
fuaflow-network-server                                    neurosym (PyPI)
  (Dart, Railway:8765)                               Prime factorization engine

fuaflow.com (Cloudflare Pages) ← sitio marketing estático, NO consume este backend

Dominios: - fuaflow.com → Cloudflare Pages (marketing) - api.fuaflow.com → Railway (triadic-cloud, 31 endpoints, Stripe billing) - ai.fuaflow.com → Railway (este backend, 5 endpoints) - network.fuaflow.com → Railway (lighthouse P2P, WebSocket)

Bloqueos

Problemas que impiden operar correctamente hoy.

~~Contrato API roto~~ RESUELTO

~~Los response fields del backend no coincidían con la API real de Triadic Cloud.~~ Corregido en commit 66dc2e6:

Endpoint Antes (roto) Después (correcto)
POST /index/{ns}/search result["matches"] result["results"]
(items) m["label"], m["score"] m["concept"], m["distance"]
POST /encode enc["prime"] enc["results"][0]["prime_factor"]
GET /index x["name"] x["namespace"]

8 contract tests con mocks validan la estructura real. La cadena Flutter → backend → Triadic ahora funciona end-to-end.

CI/CD parcialmente roto

  • [x] CI branch corregido — workflow ahora escucha branches: [master]. Corregido en commit 66dc2e6.
  • [ ] Python mismatch — Dockerfile: 3.12, CI: 3.11. Triadic-cloud usa 3.12 en ambos.

Errores de runtime

  • [ ] resp.json() sin protección — _triadic() línea 109 no catchea JSONDecodeError. Triadic Cloud puede devolver HTML en errores 5xx.
  • [ ] triadic_prime = string "None" — Ahora extrae correctamente de results[0]["prime_factor"], pero si Triadic devuelve results: [] (concepts vacíos), str(None) sigue produciendo "None". El Flutter client parsea triadicPrime como String?, así que "None" pasa como truthy.

Seguridad

  • [ ] Namespace collision — _user_namespace() sanitiza re.sub(r'[^\w\-]', '-', ...). En la práctica los tokens de Flutter son 32 hex puro (generados con Random.secure()), pero la función no lo garantiza. Dos IDs con caracteres especiales podrían colisionar.

Código muerto

  • [ ] import math (línea 23), import secrets (línea 25) — nunca usados.
  • [ ] _NS_RE (línea 46) — regex compilada nunca referenciada.
  • [ ] Docstring línea 14 dice GET /user/namespace, endpoint real es GET /user/info.

Técnico

~~Arreglar contrato API~~ COMPLETADO

  • [x] Cambiar result.get("matches") → result.get("results") en find_similar.
  • [x] Cambiar m.get("label") → m.get("concept") y m.get("score") → m.get("distance"). Nota: distance = count de prime factors compartidos (mayor = más similar), no un score 0-1.
  • [x] Cambiar enc.get("prime") → enc.get("results", [{}])[0].get("prime_factor") en flag_predictor.
  • [x] Cambiar x.get("name") → x.get("namespace") en user_info.
  • [x] 8 contract tests con mocks validando estructura real de Triadic (tests/test_triadic_contract.py).
  • [ ] Considerar usar neurosym-client (PyPI SDK oficial con typed exceptions AuthError, RateLimitError, etc.) en vez del cliente HTTP manual.

Validación de datos

  • [ ] DateEntry.stars: Field(ge=1, le=5) — Flutter envía 1-5 (DateLogsTable default 3), pero la API no lo valida.
  • [ ] CandidateSimilarRequest.top_k: Field(ge=1, le=100) — Flutter usa topK=8.
  • [ ] DateEntry.cost: Field(ge=0).
  • [ ] candidate_id: no vacío, sin ] — find_similar parsea [id] trait y trunca si contiene ].
  • [ ] traits y dates: limitar longitud de listas. Love-Log extrae traits de 9 campos, máximo ~15 traits por candidato.
  • [ ] X-User-Token[8:]: validar hexadecimal — Flutter genera con Random.secure() → hex, pero un atacante podría enviar no-hex.

Bugs lógicos

  • [ ] Trend con n=3 — compara solo stars[0] vs stars[2], ignora el medio.
  • [ ] Duplicación por race condition — Flutter llama indexCandidateQuietly() fire-and-forget al guardar. Double-tap = traits duplicados.
  • [ ] Distance vs Score — Triadic devuelve distance (count de prime factors compartidos, entero), no score (float 0-1). La lógica de ranking con max(sc) necesita adaptarse.
  • [ ] Condición redundante — línea 283: avg_cost > 0 and avg_cost > 120.

Performance

  • [ ] httpx.AsyncClient singleton con lifespan — TCP+TLS nueva por request (línea 93). Triadic-cloud también usa timeout 30s internamente, así que la latencia se acumula.
  • [ ] Rate limiting local — Triadic Pro: 60 req/min, 5K req/día. Sin throttling local, un usuario podría agotar la cuota para todos.

Seguridad

  • [ ] CORS: restringir a https://ai.fuaflow.com y orígenes de las apps.
  • [ ] Request size limits.
  • [ ] Rotación de FUAFLOW_INTERNAL_KEY — formato tne-pro-{48 hex}, hasheado con SHA-256 en Triadic.
  • [ ] Upper bounds en requirements.txt: fastapi>=0.109.0,<1.0, etc.

Testing

  • [x] Tests para /candidates/index y /candidates/similar con mocks — ahora cubiertos en test_triadic_contract.py.
  • [x] Tests de contrato con mock de Triadic usando response shapes reales (results/concept/distance/prime_factor). 19 tests totales.
  • [ ] Tests edge cases: n=3 dates, ] en candidate_id, namespace collision, resp.json() failure.

CI/CD

  • [x] Branch name: main → master corregido en ci.yml.
  • [ ] Python: 3.12 en ambos (CI y Dockerfile).
  • [ ] Type checking (mypy).
  • [ ] Coverage (pytest-cov).
  • [ ] Considerar CI pipeline como triadic-cloud: test → docker-build → deploy automático a Railway con RAILWAY_TOKEN.

Arquitectura

  • [ ] Extraer modelos a models.py.
  • [ ] Extraer flag logic a services/flags.py.
  • [ ] Extraer cliente Triadic a clients/triadic.py con AsyncClient singleton.
  • [ ] Structured logging (JSON) — actualmente toda la infra tiene logging básico, 0 observabilidad (sin Sentry, Prometheus, Grafana en ningún repo del ecosistema).
  • [ ] Health check real: ping GET /health de Triadic Cloud.
  • [ ] Request IDs.

Comercial

Integración con apps (funciona parcialmente)

  • [ ] Love-Log (fuaflow_ai_client.dart, 262 LOC) — Cliente completo: indexCandidate, findSimilar, getFlags, isHealthy. Token via FlutterSecureStorage. URL: https://ai.fuaflow.com. Traits extraídos de 9 campos (job, education, nationality, physique, height, origin, livingLocation, languages, bioNotes). UI: FindSimilarScreen, AiInsightsCard. Indexa automáticamente al guardar candidato (fire-and-forget). Graceful offline fallback.
  • [ ] FuaFlow-CRM (fuaflow_ai_client.dart, 266 LOC) — Casi idéntico a Love-Log. Diferencia: usa SalesActivityEntryAI con isLost/isSuccess en vez de isStrike/isLove. Mismo patrón de indexación y flags.
  • [ ] Code duplication — Los dos AI clients son copias casi exactas. Extraer a un package compartido (fuaflow_ai_client en pub.dev o path dependency local como ya hacen con fuaflow_network).
  • [ ] Backend CRM compatibility — FlagRequest usa is_strike/is_love (dating). CRM envía is_lost/is_success (ventas). Verificar que el backend maneje ambos dominios o tenga endpoints separados.

Documentación

  • [x] Campos reales de Triadic (results/concept/distance/prime_factor) ahora usados en código y validados en tests.
  • [ ] Guía de integración Flutter → backend (ya existe el client, falta documentar contrato).
  • [ ] Documentar las 4 rutas Triadic: /index/{ns}/encode (persistir concepts), /index/{ns}/search (buscar por GCD), /encode (fingerprint one-shot), /index (listar namespaces).
  • [ ] Documentar que distance = count de prime factors compartidos via GCD (mayor = más similar).

Pricing y límites

  • [ ] Key Pro de Triadic: 60 req/min, 5K/día, 10 namespaces max, 10K concepts/request. Sin tracking ni enforcement en el backend.
  • [ ] Web muestra pricing Triadic ($0 / $29 / $299 mo). El backend se presenta como feature gratuita de las apps. Sin monetización propia clara.
  • [ ] Sin tracking de uso por usuario.

Onboarding

  • [ ] Token generado en cliente sin registro ni billing. FlutterSecureStorage persiste entre reinstalaciones, pero el usuario no tiene forma de recuperarlo si cambia de dispositivo.
  • [ ] P2P sync solo sincroniza settings (locale/theme), no el token AI ni datos de candidatos. Un usuario con dos dispositivos tendría dos namespaces separados en Triadic.

Operaciones

  • [ ] Sin releases, tags, deployments, ni environments en GitHub.
  • [ ] Triadic Cloud soporta webhooks (usage_warning, anomaly_critical, subscription_expiring) — no configurados.
  • [ ] Todo el ecosistema usa 0 observabilidad externa (sin Sentry, DataDog, Prometheus, Grafana).
  • [ ] Triadic Cloud tiene admin dashboard (GET /admin) y métricas JSON (GET /admin/metrics). Este backend no tiene nada equivalente.
  • [ ] Backup: datos de usuario viven en namespaces Triadic (SQLite en /data/neurosym/). DELETE /index/{namespace} los borra irreversiblemente. Sin backups automáticos.
  • [ ] SLA, rotación de key, runbooks — sin definir.
  • [ ] Privacy: traits de candidatos (job, nationality, bio) enviados automáticamente a Triadic Cloud vía indexCandidateQuietly() sin opt-in explícito del usuario. Love-Log se presenta como "100% offline, privacy-first" pero los AI features envían datos a un servidor externo.
  • [ ] La web tiene /privacy/ y /terms/ pero cubren el sitio, no la API.
  • [ ] Datos almacenados en SQLite de Triadic Cloud (/data/neurosym/index.db) en Railway. Sin encryption at rest documentada.
  • [ ] Evaluar cumplimiento con regulaciones de datos personales.

Roadmap del ecosistema (contexto)

  • [ ] fuaflow-web en modo mantenimiento: botones Google Play deshabilitados, newsletter rota (Formspree YOUR_FORM_ID), index.full.html oculto.
  • [ ] Love-Log y fuaflow-CRM: APKs signed/ready, Play Store submission pendiente.
  • [ ] EntityOS (FuaFlow-Playground): NestJS Phase 1 MVP, sin integración con AI backend. Potencial futuro: directorio de servicios AI.
  • [ ] PixelVault licensing: servidor FastAPI separado en Railway, sin relación directa con este backend.
  • [ ] Triadic Cloud: CI funcional (test → docker-build → deploy), Stripe billing integrado, admin dashboard, PostgreSQL opcional. Mucho más maduro que este backend.

fuaflow-CRM

Lo que falta para que el proyecto esté production-ready y listo para comercializar.

Técnico

Release & Distribución

  • [ ] Configurar firma de release para Android (keystore, signingConfigs en build.gradle.kts — actualmente usa debug keys)
  • [ ] Generar plataforma iOS (flutter create . --platforms ios) y configurar signing con Apple Developer account
  • [ ] Preparar builds para Google Play (AAB) y App Store (IPA)
  • [ ] Configurar CI/CD para builds firmados (secrets de signing en GitHub Actions)
  • [ ] Alinear versión de Java entre CI (Java 17) y desarrollo local (Java 21)
  • [ ] Publicar fuaflow_network en pub.dev o repositorio privado (actualmente es path dependency local)

Base de Datos & Datos

  • [ ] Implementar sync de datos CRM entre dispositivos (actualmente P2P solo sincroniza locale/theme)
  • [ ] Agregar cloud backup opcional (iCloud, Google Drive, o backend propio)
  • [ ] Auditar transaccionalidad en operaciones batch (setBaseline, setTopLead no usan transacciones)
  • [ ] Corregir LIKE queries sin cláusula ESCAPE (riesgo de inyección de wildcards %, _)
  • [ ] Cerrar gaps de sincronización FTS5 (entradas huérfanas posibles si falla el sync manual del índice)
  • [ ] Ampliar rango del calendario (hardcoded 2020–2030)

Calidad de Código

  • [ ] Migrar a Riverpod 3.x cuando riverpod_generator soporte async* generators
  • [ ] Eliminar 8 keys huérfanas de la era dating en localización ES
  • [ ] Reemplazar strings hardcoded en español dentro de componentes UI por keys de l10n
  • [ ] Expandir widget tests (29 archivos son scaffolds placeholder con smoke tests básicos)
  • [ ] Agregar integration tests E2E (actualmente solo 1 archivo con 31 tests)
  • [ ] Alcanzar >80% code coverage (subir reporte a Codecov ya está en CI)

Seguridad

  • [ ] Revisión de seguridad del almacenamiento de API keys en flutter_secure_storage
  • [ ] Auditar que datos enviados al backend AI (ai.fuaflow.com) no incluyan PII
  • [ ] Implementar certificate pinning para conexiones al backend AI y lighthouse P2P
  • [ ] Revisión OWASP Mobile Top 10

Internacionalización

  • [ ] Soporte multi-moneda (actualmente USD $ hardcoded en toda la app)
  • [ ] Agregar más idiomas según mercado objetivo (actualmente solo EN/ES)
  • [ ] Formateo de números/fechas según locale (verificar consistencia)

Infraestructura

  • [ ] Backend AI (ai.fuaflow.com) — documentar SLA, uptime, rate limits
  • [ ] Lighthouse P2P (wss://network.fuaflow.com) — documentar disponibilidad y failover
  • [ ] Monitoreo de salud de servicios externos (health check ya existe en AI client)
  • [ ] Considerar telemetría opt-in para crashlytics (actualmente todo on-device)

Comercial

App Stores

  • [ ] Crear listing en Google Play Store (screenshots, descripción, categoría: Business/Productivity)
  • [ ] Crear listing en Apple App Store
  • [ ] Diseñar assets de marketing (screenshots por idioma, feature graphic, video preview)
  • [ ] Definir pricing model (freemium, suscripción, pago único)
  • [ ] Configurar in-app purchases o suscripciones si aplica
  • [ ] Revisión legal de Privacy Policy para cumplimiento con GDPR, CCPA, y leyes locales
  • [ ] Revisión legal de Terms of Service
  • [ ] Disclaimer sobre naturaleza del scoring AI (no es asesoría financiera/legal)
  • [ ] Política de retención y eliminación de datos (derecho al olvido)
  • [ ] Licencia propietaria — definir términos de uso comercial

Marca & Posicionamiento

  • [ ] Definir mercado objetivo (freelancers, agentes inmobiliarios, vendedores independientes, equipos pequeños)
  • [ ] Landing page / sitio web (fuaflow.com)
  • [ ] Documentación de usuario / onboarding guiado más allá de los 2 pasos actuales
  • [ ] Canal de soporte (email, chat, FAQ)
  • [ ] Estrategia de contenido (blog, redes, caso de uso)

Monetización del AI

  • [ ] Definir modelo de uso de features AI (gratis limitado / premium ilimitado)
  • [ ] Costos de infraestructura AI vs pricing al usuario
  • [ ] Rate limiting por tier de usuario

Bloqueos

Bloqueo Impacto Dependencia
Firma de release no configurada No se puede publicar en stores Keystore Android + Apple Developer Account
iOS no generado Sin acceso al 50%+ del mercado mobile Apple Developer Program ($99/año)
fuaflow_network es path dependency CI falla sin el repo hermano clonado; imposible distribuir como package Publicar en pub.dev o repo privado
Riverpod 3.x bloqueado Deuda técnica creciente, incompatibilidad futura Fix upstream en riverpod_generator para async*
Sin sync de datos CRM Usuarios pierden datos si cambian de dispositivo Implementar cloud backup o P2P full sync
USD hardcoded Limita mercado a usuarios que operan en dólares Refactor de currency formatting en ~20 archivos
Backend AI sin SLA documentado Riesgo de downtime sin plan de contingencia Documentar o self-host la API

fuaflow-network

Estado actual: SDK cliente v0.1.0 publicado. Sin servidor lighthouse ni infraestructura backend.

Técnico

Crítico (sin esto no funciona en producción)

  • [ ] Implementar el servidor Lighthouse — El SDK es solo el cliente. No existe el relay server (WebSocket routing, REST discovery, match engine). Sin esto, el SDK no se puede usar.
  • [ ] Verificación de firmas en mensajes entrantes — P2PService.verifySignatures está en false con comentario // Enable when peer registry is implemented. Se necesita un registro de claves públicas por nodo para activarlo.
  • [ ] Cifrado de payloads (E2E) — Los mensajes están firmados pero el contenido viaja en texto plano por el lighthouse. Implementar cifrado end-to-end (X25519 key exchange + AES-GCM o similar).
  • [ ] Persistencia del estado CRDT — SyncEngine es puramente in-memory. Si la app se cierra, se pierde todo el estado sincronizado. Necesita serialización a disco (SQLite, Hive, o SharedPreferences).

Importante (calidad de producción)

  • [ ] Cola de mensajes offline — sendTo() lanza StateError si no hay conexión. Implementar queue local que envíe cuando se reconecte.
  • [ ] Confirmación de entrega — No hay ACK. El emisor no sabe si el mensaje llegó al destinatario. Definir mecanismo de acknowledgment en el protocolo.
  • [ ] Autenticación en el lighthouse — Cualquier nodo puede conectarse. Implementar challenge-response con la keypair Ed25519 existente para autenticar la conexión WebSocket.
  • [ ] Observabilidad — Cero logging, métricas o tracing. Agregar package:logging y hooks para que apps integren su sistema de observabilidad.
  • [ ] Soporte Web — P2PService usa dart:io WebSocket, incompatible con Flutter Web. Migrar a package:web_socket_channel para soporte multiplataforma.
  • [ ] TTL / expiración de mensajes — Los mensajes tienen timestamp pero no expiran. Definir TTL para evitar replay attacks y acumulación de datos obsoletos.
  • [ ] CRDTs adicionales — Solo hay LWW registers y G-Sets. Faltan: OR-Set (para poder eliminar elementos), PN-Counter, LWW-Map. Necesarios para casos de uso reales.
  • [ ] Multi-lighthouse failover — Dependencia de un solo servidor. Si cae, todos los nodos se desconectan sin alternativa.

Nice to have

  • [ ] Generar documentación API — doc/ está vacío. Ejecutar dart doc y publicar en GitHub Pages.
  • [ ] Extraer test doubles a paquete compartido — InMemoryKeyStore y FakeWebSocket están duplicados en 4 archivos de test. Mover a test/helpers/.
  • [ ] Ejemplo de app Flutter completa — example/example.dart es un script main(). Crear un ejemplo con UI que demuestre el flujo real.

Comercial

Infraestructura

  • [ ] Desplegar lighthouse en la nube — Necesita server, dominio, TLS. Opciones: VPS con Docker, o serverless (Cloud Run, Fly.io).
  • [ ] Dashboard de administración — Panel web para ver nodos conectados, tráfico, matches activos, y métricas de uso.
  • [ ] Sistema de metering/billing — Definir unidad de cobro (mensajes/mes, nodos activos, storage CRDT) e implementar tracking.

Go-to-market

  • [ ] Landing page y documentación — Sitio web con docs, guías de integración, y pricing. Actualmente solo existe el README.
  • [ ] Caso de uso demostrable — Necesita al menos una app publicada que use el SDK (love-log, CRM, etc.) como prueba de concepto.
  • [ ] SDKs para otras plataformas — Solo existe para Flutter/Dart. Para un producto comercial se necesita al mínimo: Swift (iOS nativo), Kotlin (Android nativo), TypeScript (Web).
  • [ ] Términos de servicio — Requerido antes de que terceros usen el lighthouse.
  • [ ] Política de privacidad — El lighthouse procesa metadata (node IDs, IPs, coordenadas GPS). Requiere política GDPR/CCPA compliant.
  • [ ] Revisión de licencia — El SDK es MIT. Evaluar si el server debería tener licencia comercial (BSL, AGPL, o propietaria).

Bloqueos

# Bloqueo Impacto Dependencia
1 No existe el servidor lighthouse Sin server, el SDK es inutilizable. Nada funciona sin el relay. Ninguna — es el primer paso.
2 Verificación de firmas deshabilitada Un nodo puede suplantar a otro enviando from_id falso. Rompe la integridad del protocolo. Requiere registro de claves públicas en el lighthouse (#1).
3 Payloads sin cifrar El lighthouse (y cualquier intermediario) puede leer todo el contenido de los mensajes. Requiere key exchange entre pares — independiente del server.
4 Sin persistencia CRDT El estado se pierde al cerrar la app. Hace inviable cualquier caso de uso real de sincronización. Ninguna — se puede resolver en el SDK ahora.
5 Sin soporte Web Excluye una plataforma completa de Flutter. Apps web no pueden usar P2PService. Migrar de dart:io WebSocket a web_socket_channel.

Orden sugerido: #4 → #3 → #1 → #2 → #5

El bloqueo #4 (persistencia CRDT) y #3 (cifrado E2E) se pueden resolver ya en el SDK sin depender del server. El #1 (lighthouse) es el mayor esfuerzo y habilita todo lo demás.

fuaflow-network-server

Basado en auditoría completa del código fuente, tests, configs y docs.

Técnico

Persistencia y estado

  • [ ] Persistencia de estado — Todo es in-memory. Un restart pierde nodos, perfiles, tokens, matches y mensajes encolados. Evaluar Redis, SQLite o write-ahead log para sobrevivir reinicios.
  • [ ] Expiración de auth tokens — _authTokens crece sin límite. Los tokens persisten hasta restart. Agregar TTL (e.g. 24h) y limpieza periódica.
  • [ ] Limpieza de tokens huérfanos — Cuando un nodo es eviccionado por TTL del registry, su token queda en _authTokens. Sincronizar ambas eviccionas.
  • [ ] Exportar/importar estado — Endpoint admin para snapshot y restore del estado en memoria (útil para migraciones y backups).

Seguridad

  • [ ] Autenticar endpoints sensibles — POST /message, DELETE /profile/:nodeId y GET /matches/:nodeId son públicos. Cualquiera puede enviar mensajes a un target_id, borrar perfiles ajenos, o consultar matches de otro nodo.
  • [ ] Proteger /discover contra scraping — No requiere registro. Un actor puede iterar coordenadas y extraer todos los perfiles. Agregar rate limit específico o requerir nodo registrado.
  • [ ] Limitar tamaño de traits — El campo traits acepta JSON arbitrario sin límite de profundidad ni tamaño (solo el body limit de 64KB lo contiene indirectamente).
  • [ ] Helmet headers — Agregar X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security en respuestas HTTP.
  • [ ] Validar endpoint en /register — Actualmente acepta cualquier string. Validar formato IP:port.

Escalabilidad

  • [ ] Escalado horizontal — Instancia única, máximo ~10K WebSocket concurrentes. Para escalar: estado compartido (Redis/NATS) + sticky sessions o pub/sub entre instancias.
  • [ ] Paginación en /discover — Retorna todos los perfiles que matchean. Con muchos perfiles en un radio grande, la respuesta puede ser enorme. Agregar limit y offset.
  • [ ] Paginación en /matches/:nodeId — Retorna todos los matches de una vez.
  • [ ] Connection pooling / backpressure — No hay mecanismo para rechazar conexiones WS gradualmente antes de llegar al hard limit de 10K.

Observabilidad

  • [ ] Access log completo — Solo se loggean algunos eventos (REGISTER, WS_CONNECT, INTEREST...). No hay log de cada request HTTP (método, path, status, latencia).
  • [ ] Cobertura de tests — CI ejecuta tests pero no mide ni reporta coverage. Agregar --coverage y badge.
  • [ ] Health check profundo — /health solo retorna conteos. No verifica que los timers internos (eviction, prune, cleanup) estén activos.
  • [ ] HEALTHCHECK en Dockerfile — El Dockerfile no tiene instrucción HEALTHCHECK. Railway lo maneja, pero Docker standalone no.

Calidad de código

  • [ ] analysis_options.yaml — No existe. Usa defaults del analyzer. Definir reglas explícitas (lints recomendados por Dart).
  • [ ] Consistencia en .gitignore — pubspec.lock está en .gitignore pero ya está trackeado en git. Decidir: trackearlo (recomendado para apps) o quitarlo del historial.

Comercial

Producto

  • [ ] Client SDKs — No existen. Los consumidores deben implementar el protocolo HTTP+WS manualmente. Crear SDKs para Dart/Flutter, TypeScript, y Python como mínimo.
  • [ ] Admin dashboard — No hay UI. Los operadores dependen de curl contra /admin/metrics. Crear panel web con métricas en tiempo real, gestión de nodos, y logs.
  • [ ] Documentación interactiva — Solo markdown en el repo. Publicar en sitio web con playground (Swagger/OpenAPI o similar).
  • [ ] Multi-tenancy — Namespace único para todas las apps. Para SaaS, cada cliente necesita aislamiento (por API key, dominio, o instancia dedicada).
  • [ ] GDPR / protección de datos — Se almacenan coordenadas geográficas (aunque redondeadas). Requiere política de privacidad, consentimiento explícito, derecho a eliminación, y DPA para clientes europeos.
  • [ ] Términos de servicio — No existen.
  • [ ] Política de privacidad — No existe.
  • [ ] Licencia comercial — La licencia actual es propietaria genérica. Para venta, definir modelo de licenciamiento (SaaS, on-premise, per-seat, etc.).

Go-to-market

  • [ ] Modelo de precios — No definido. Opciones: por conexiones concurrentes, por mensajes, por perfiles activos, o flat fee.
  • [ ] Metering y billing hooks — No hay infraestructura para medir uso por cliente ni integrarse con sistemas de pago.
  • [ ] SLA — No definido. Definir uptime target, latencia máxima, y política de compensación.
  • [ ] Landing page y branding — No existen.
  • [ ] Canal de soporte — Solo email ([email protected] en LICENSE). Evaluar ticketing, chat, o foro.

Bloqueos

Estos items impiden ir a producción real con usuarios pagando:

# Bloqueador Riesgo Esfuerzo estimado
1 Estado in-memory sin persistencia Pérdida total de datos en cada restart o crash Alto
2 Auth tokens sin expiración Memory leak progresivo + tokens válidos indefinidamente Bajo
3 Endpoints sin autenticación Cualquiera puede borrar perfiles, leer matches, o enviar mensajes a cualquier nodo Medio
4 Sin GDPR / política de privacidad Riesgo legal al almacenar ubicaciones de usuarios europeos Medio (legal)
5 Instancia única, sin escalado Techo de ~10K conexiones simultáneas, sin redundancia Alto
6 Sin client SDKs Barrera de adopción alta; cada cliente implementa el protocolo desde cero Medio

FuaFlow-Playground

What's missing to take EntityOS from Phase 1 MVP to a production-ready, commercializable product.

Based on a full audit of the current codebase (March 2026).

Tecnico

Seguridad (critico)

  • [ ] Ownership enforcement — PATCH /entities/:id y DELETE /entities/:id no verifican que el usuario autenticado sea el dueno. Cualquier usuario con JWT puede modificar o borrar cualquier entidad.
  • [ ] Service listing ownership — DELETE /services/:id no verifica que el servicio pertenezca al usuario. PATCH /services/:id recibe req.user.id pero el service no lo usa para validar.
  • [ ] CORS restrictivo — app.enableCors() esta sin configuracion; acepta cualquier origen. Debe restringirse a dominios conocidos en produccion.
  • [ ] Rate limiting — No hay throttling. Un solo cliente puede saturar la API. Implementar @nestjs/throttler.
  • [ ] API key auth guard — Las entidades no-humanas reciben apiKey al registrarse pero no existe un guard que autentique por API key. Solo existe JwtAuthGuard.
  • [ ] Helmet — No se usa helmet para headers de seguridad HTTP.
  • [ ] Input sanitization — class-validator cubre validacion de tipos pero no sanitiza HTML/XSS en campos como bio, comment, description.
  • [ ] JWT refresh tokens — Solo hay access token con 1 dia de expiracion. No hay refresh token ni logout/revocacion.

Backend

  • [ ] Pagination en entities — GET /entities devuelve todos los resultados sin paginacion. Services ya lo tiene; entities no.
  • [ ] Password reset — No hay flujo de forgot/reset password ni verificacion de email.
  • [ ] File uploads — avatarUrl existe en el schema pero no hay endpoint ni storage (S3/R2) para subir imagenes.
  • [ ] Redis integration — Redis esta en docker-compose pero no se usa en el codigo. Decidir: cache de queries, rate limiting, sesiones, o pub/sub.
  • [ ] MQTT gateway — Mosquitto esta en docker-compose pero no hay codigo que conecte al broker. Necesario para IoT/robots.
  • [ ] Error handling global — No hay exception filter global. Los errores de Prisma (unique constraint, not found) se propagan como 500 en vez de 409/404.
  • [ ] Logging estructurado — No hay logger configurado. Usar nestjs-pino o similar para logs JSON en produccion.
  • [ ] Health check endpoint — GET /api/v1 devuelve status pero no verifica la conexion a la base de datos. Usar @nestjs/terminus para un health check real.
  • [ ] Soft delete — DELETE hace hard delete. Considerar soft delete para entidades y servicios (campo deletedAt).
  • [ ] Roles y permisos — No hay sistema de roles (admin, user, readonly). Cualquier usuario autenticado puede crear categorias o borrar entidades.

Frontend

  • [ ] Todo — apps/web es boilerplate de Next.js sin modificar. No hay paginas, componentes, ni integracion con la API.
  • [ ] Paginas minimas: Landing, login/register, dashboard, perfil de entidad, directorio de servicios, detalle de servicio.
  • [ ] API client — No hay cliente HTTP configurado (axios/fetch wrapper con auth headers).
  • [ ] Estado global — No hay state management. PLAN.md sugiere Zustand.
  • [ ] UI components — No hay sistema de componentes. PLAN.md sugiere shadcn/ui.

Infraestructura

  • [ ] Dockerfile — No hay Dockerfiles para API ni web. Necesarios para deploy.
  • [ ] CI/CD — No hay .github/workflows/. Minimo: lint + test + build en PRs, deploy a staging en merge a main.
  • [ ] Produccion config — No hay configuracion por entorno (staging, production). Solo .env.example para desarrollo.
  • [ ] HTTPS/TLS — No hay configuracion de TLS. En produccion, necesita reverse proxy (nginx/Caddy) o managed service.
  • [ ] Database backups — No hay estrategia de backups para PostgreSQL.
  • [ ] Monitoring — PLAN.md menciona Grafana + Prometheus pero no hay nada configurado.
  • [ ] Hosting — No hay decision tomada. PLAN.md lista AWS, Hetzner, Railway como opciones.

Testing

  • [ ] Coverage — 6 unit tests cubren los services pero no hay metricas de coverage ni threshold minimo.
  • [ ] E2E tests reales — El unico e2e test (app.e2e-spec.ts) no prueba ningun endpoint de negocio (auth, entities, services, reviews).
  • [ ] Integration tests — No hay tests que conecten a una base de datos real (todos usan mocks).
  • [ ] Load testing — No hay benchmarks de rendimiento ni tests de carga.

Monorepo

  • [ ] packages/ vacio — pnpm-workspace.yaml define packages/* pero no hay paquetes compartidos. Falta al menos un paquete de tipos compartidos entre API y web.
  • [ ] Shared types — Los DTOs de la API no se comparten con el frontend. Hay que extraer interfaces/tipos a un paquete comun.

Comercial

Producto

  • [ ] Landing page — No hay pagina publica que explique que es EntityOS, para quien es, y por que usarlo.
  • [ ] Onboarding — No hay flujo guiado para que un usuario nuevo registre su primera entidad y publique un servicio.
  • [ ] Admin dashboard — No hay panel de administracion para gestionar categorias, moderar reviews, ver metricas.
  • [ ] Documentacion publica — Swagger existe pero no hay docs para developers externos (guias, tutoriales, API reference).
  • [ ] SDK / client library — No hay SDK para que terceros integren sus robots/agentes con la plataforma.
  • [ ] Mobile app — PLAN.md la contempla en Flutter pero no hay codigo.

Modelo de negocio

  • [ ] Pricing — No hay modelo de precios definido (freemium, por transaccion, suscripcion, etc.).
  • [ ] Billing — No hay integracion de pagos (Stripe, etc.) para cobrar por el uso de la plataforma.
  • [ ] Wallet multi-agente — Descrito en PLAN.md como FEAT_WALLET pero no implementado. Es core para la economia inter-agente.
  • [ ] Analytics — No hay tracking de uso, conversion, retention. Necesario para decisiones de producto.
  • [ ] Terminos de servicio — No existen.
  • [ ] Politica de privacidad — No existe.
  • [ ] Licencia — El proyecto esta como UNLICENSED. Definir si sera open source, source-available, o propietario.
  • [ ] Dominio — No hay dominio registrado. PLAN.md sugiere entityos.io o entityos.app.

Go-to-market

  • [ ] Beta cerrada — No hay mecanismo de waitlist ni invitaciones.
  • [ ] Branding — No hay logo, paleta de colores, ni guia de marca. El favicon es el default de Next.js.
  • [ ] SEO — El web app no tiene metadata, og:tags, ni sitemap.

Bloqueos

Cosas que deben resolverse antes de avanzar porque afectan decisiones downstream.

Bloqueo Impacto Opciones
No hay ownership checks en mutaciones Cualquier usuario puede borrar/editar entidades de otros. Bloqueante para cualquier deploy publico. Implementar guards de ownership antes de abrir la API.
Hosting no decidido No se puede configurar CI/CD, DNS, ni TLS sin saber donde se despliega. Railway (rapido MVP), Hetzner (barato), AWS (escala). Decidir ahora.
Dominio no registrado No se puede configurar email, CORS, ni certificados. Registrar entityos.io o alternativa.
Licencia indefinida No se puede invitar contribuidores ni publicar el repo sin licencia clara. MIT (open source), BSL (source-available), o propietario.
Redis en infra pero sin uso Potencial confusión y recurso desperdiciado hasta que se integre. Integrar para cache + rate limiting, o remover del docker-compose hasta que se necesite.
Frontend inexistente No hay forma de que un usuario no-técnico interactue con la plataforma. Priorizar: landing + auth + dashboard basico.
API key auth no implementada Los robots/IoT reciben API key al registrarse pero no pueden usarla para autenticarse. Crear ApiKeyAuthGuard como complemento al JwtAuthGuard.

fuaflow-web

Estado actual del sitio y lo que falta para que el ecosistema FuaFlow esté listo para comercializar.

Técnico

Sitio web

  • [ ] Salir de mantenimiento — restaurar index.full.html como index.html
  • [ ] Configurar Formspree — el newsletter usa YOUR_FORM_ID como placeholder (index.full.html:1026); crear el form en formspree.io y reemplazar
  • [ ] Screenshots reales de FuaFlow Log — el hub y /log/ tienen 4-5 placeholders con texto "Screenshot" donde deberían ir capturas reales de la app
  • [ ] Assets faltantes referenciados en el HTML:
  • favicon.ico — referenciado en index.full.html:32 pero no existe
  • apple-touch-icon.png — referenciado en index.full.html:33 pero no existe
  • [ ] Agregar .gitignore — el repo no tiene; debería excluir al menos .DS_Store, Thumbs.db, .env, *.log
  • [ ] Menú hamburger en páginas standalone — solo el hub lo tiene; /log/, /pixelvault/, /stream/, /triadic/, /triadic-gpt/ no tienen menú móvil (la nav desaparece en <768px)
  • [ ] Unificar pricing de PixelVault — el hub muestra Free + Pro $29/año; la página standalone muestra Personal $39 + Bundle $59 + Enterprise. Elegir uno y sincronizar
  • [ ] i18n en páginas standalone — solo el hub soporta ES/EN toggle; las páginas standalone son monolingües (Log/PixelVault/Stream en español, Triadic/TriadicGPT en inglés)
  • [ ] Legal duplicado — el hub tiene versiones resumidas de Privacy/Terms como overlay en JS; las páginas standalone (/privacy/, /terms/) tienen versiones más completas. Pueden desincronizarse con el tiempo
  • [ ] 404 sin favicon — 404.html no incluye <link rel="icon">
  • [ ] Footer inconsistente — /privacy/ y /terms/ no listan FuaFlow Stream en el footer; las demás páginas sí

Seguridad

  • [ ] CSP: eliminar unsafe-inline de script-src — actualmente necesario por los scripts inline; migrar a archivos .js externos o usar nonces
  • [ ] Auditar innerHTML en legal overlay — index.full.html:1408 usa innerHTML con contenido de un objeto JS hardcodeado (no es XSS externo, pero es un patrón a evitar)

Infraestructura

  • [ ] Dominio de email — verificar que support@, privacy@, enterprise@, [email protected] están configurados y reciben correo
  • [ ] Servidor de licencias PixelVault — el sitio referencia un FastAPI licensing server; verificar que está desplegado y funcional
  • [ ] Triadic Cloud API — verificar que api.fuaflow.com está en producción con los endpoints documentados (/encode, /search, /audit, /anomaly/scan)
  • [ ] Stripe billing — verificar que api.fuaflow.com/billing/checkout?plan=pro funciona y procesa pagos
  • [ ] LemonSqueezy — verificar que los links de compra (fuaflow.lemonsqueezy.com/buy/pixelvault y pixelvault-bundle) están activos

Comercial

Lanzamientos pendientes

  • [ ] FuaFlow Log en Google Play — los botones de descarga están deshabilitados con "Próximamente" en 3 lugares (hub, /log/ hero, /log/ download)
  • [ ] PixelVault download — la página standalone tiene links de compra en LemonSqueezy pero el hub muestra botones deshabilitados; definir si el producto está a la venta o no
  • [ ] PixelVault Free tier — el hub promete un tier gratuito pero no hay link de descarga para la versión free

Contenido faltante

  • [ ] Screenshots y demos — ningún producto tiene capturas de pantalla reales en el sitio; es lo primero que un usuario busca para decidir si compra/descarga
  • [ ] Video demo o GIF — especialmente útil para PixelVault (mostrar el pipeline) y EXR Play (mostrar el streaming)
  • [ ] Testimonials / social proof — no hay reviews, estrellas, ni conteo de usuarios
  • [ ] Comparación con competidores — Triadic Cloud tiene tabla vs cosine/BM25 (bien); los demás productos no tienen posicionamiento competitivo

Analytics y conversión

  • [ ] Analytics — no hay ningún tracking (ni siquiera privacy-friendly como Plausible o Umami). Sin datos no se puede optimizar conversión
  • [ ] Métricas de newsletter — sin Formspree configurado no se capturan leads
  • [ ] Funnel de conversión — no hay tracking de clicks en CTAs (compra, descarga, API docs)

Expansión

  • [ ] FuaFlow Log para iOS — mencionado como "próximamente" en /log/
  • [ ] PixelVault GUI para macOS/Linux — solo hay CLI; la página lo indica como "próximamente"
  • [ ] Onboarding para Triadic Cloud API — más allá de Swagger docs, un quickstart interactivo o un playground mejoraría la conversión del free tier

Bloqueos

Estos items impiden que el sitio funcione comercialmente hoy:

  1. El sitio está en mantenimiento — nadie puede ver los productos. Hasta que index.full.html se restaure como index.html, todo lo demás es irrelevante.

  2. FuaFlow Log no está en Google Play — el producto principal (gratuito, funnel de entrada al ecosistema) no se puede descargar. Los botones apuntan al Play Store listing correcto (com.fuaflow.lovelog) pero están deshabilitados.

  3. Newsletter roto — el form ID es YOUR_FORM_ID. Hasta que se configure un Formspree real, no se captura ningún email. El código ya maneja este caso con un fallback ("Newsletter próximamente. Escríbenos a [email protected]") pero no es la experiencia deseada.

  4. Sin screenshots de producto — 9 placeholders entre el hub y /log/. Un sitio comercial sin imágenes del producto no convierte.

  5. Assets 404 — favicon.ico y apple-touch-icon.png están referenciados en el HTML pero no existen. Genera errores 404 en cada page load del hub.

la-danza-cosmica-de-los-opuestos

Estado actual del proyecto al 2026-03-22. Basado en auditoria exhaustiva del repositorio.

Tecnico

Libro (LaTeX → PDF)

  • [x] 34 capitulos completos, compilables con XeLaTeX
  • [x] Revision por Gemini (promedio 9.7/10)
  • [x] 5 rondas de debate multi-agente (consenso 9.3/10)
  • [x] 12 correcciones aplicadas
  • [ ] Segunda revision humana profesional (corrector de estilo)
  • [ ] Diseno de portada y contraportada
  • [ ] Maquetacion final para formato KDP (trim size, margenes, ISBN barcode)

Sistema 7x7 (v3.4 estable)

  • [x] 51 primitivos, 9 categorias, 8 operaciones, 9 reglas
  • [x] 49 edge cases testeados (24.5% bien, 40.8% parcial, 34.7% pobre)
  • [x] Estabilidad 6-0 tras 4 rondas de debate + 3 iteraciones
  • [ ] Decidir identidad del sistema: lenguaje fenomenologico (funciona) o algebra formal (rota) — ver Bloqueos
  • [ ] Completar tabla de mapping NSM (Natural Semantic Metalanguage): 51 primitivos vs ~65 de Wierzbicka — solo 9 mapeados de ~65
  • [ ] Resolver ambiguedad 51 trits vs 63 bits — no hay decision formal, afecta todo el pipeline
  • [ ] Formalizar 5 predicciones falsificables con umbrales cuantitativos (Hamming < N, combinaciones invalidas)

Modelo Bits-Primos

  • [x] Representacion dual: 63 bits + producto de primos
  • [x] 3 estados: [+] activo, [0] ausencia experimentada, [null] N/A
  • [x] Toolkit operativo: 35/35 tests unitarios, 18/21 anclas verificadas
  • [ ] Migrar dataset de floats [-1,+1] a bits binarios — decision pendiente (REVISION_REPRESENTACION.md)
  • [ ] Unificar 3 formatos coexistentes (floats en dataset, bits en toolkit, primos en libro)
  • [ ] Agregar schema JSON para validacion automatica de estructura

Dataset

  • [x] v1: 500 conceptos, v2: 900, v3: 2,050
  • [x] 5,000 pares en inventario (724 con factorizacion profunda)
  • [x] 50 palabras aleatorias fuera del dataset: todas derivables
  • [x] 15 clusters emergentes identificados por k-means
  • [ ] Consolidar v1-v4 + inventario en un solo dataset canonico (actualmente fragmentado, formatos incompatibles)
  • [ ] Elevar calidad: 4,276 pares tienen template generico, necesitan factorizacion manual
  • [ ] Deduplicar ~300 conceptos que existen en dataset e inventario con datos distintos
  • [ ] Ejecutar protocolo de validacion multi-IA (Claude vs GPT-4 vs Gemini vs Grok) — disenado, no ejecutado
  • [ ] Ejecutar protocolo de validacion humana (n >= 5 participantes, 3 experimentos) — disenado, no ejecutado

Pipeline computacional (0% implementado)

  • [ ] Encoder: texto → vector 51D/63D (transformer fine-tuned o prompt-based)
  • [ ] Motor de operaciones: ejecutar las 8 operaciones formales sobre pares de vectores
  • [ ] Decoder: vector → texto legible
  • [ ] API REST para exponer como servicio
  • [ ] TriadicGPT: entrenar modelo 40M-params con cabeza triadica de 63 bits (requiere GPU RTX 5060 Ti 16GB+)

Infraestructura de codigo

  • [x] Python puro para validacion (sin deps externas)
  • [x] Scripts reproducibles (.agents/workflows/reproduce_audit.md)
  • [ ] Agregar GitHub Actions (CI): correr tests de toolkit + antigravity en cada push
  • [ ] Agregar pytest.ini o pyproject.toml como entry point de tests
  • [ ] requirements.txt para dependencias opcionales (numpy, sklearn, scipy)
  • [ ] Empaquetar toolkit como libreria pip-installable
  • [ ] Agregar type hints a scripts de Python

Comercial

Publicacion del libro

  • [ ] Obtener ISBN (Agencia Mexicana del ISBN o Bowker para mercado US)
  • [ ] Registrar copyright (INDAUTOR Mexico / US Copyright Office)
  • [ ] Configurar Amazon KDP: interior PDF + portada + metadata
  • [ ] Precio y categoria: filosofia/ciencia, $14.99-19.99 USD
  • [ ] Generar version EPUB/MOBI (conversion desde LaTeX o reflow manual)

Traduccion al ingles

  • [ ] Traduccion profesional: ~150,000 palabras x $0.15/palabra = ~$22,500 USD
  • [ ] Alternativa: traduccion asistida por IA + revision humana (~$5,000-8,000)
  • [ ] Tiempo estimado: 8-12 semanas

Publicacion academica

  • [ ] Resolver inconsistencias algebraicas (ver Bloqueos) — requisito previo
  • [ ] Completar mapping NSM (tabla formal 51 vs 65)
  • [ ] Ejecutar estudio de validacion humana (n >= 10)
  • [ ] Ejecutar validacion multi-IA
  • [ ] Escribir paper: Journal for General Philosophy of Science, Cognitive Science, o ACL/COLING
  • [ ] ArXiv preprint primero, despues journal con peer review

Producto de software (si se decide comercializar como herramienta)

  • [ ] Opcion A — SaaS: API + dashboard web, $99-500/mes por usuario (6-8 meses dev)
  • [ ] Opcion B — Open Source: libreria pip, monetizacion por soporte/consultorias (8-12 semanas)
  • [ ] Opcion C — Hibrido: core open source (GPL), TriadicGPT comercial (modelo entrenado cerrado)

Plataforma de autor

  • [ ] Sitio web del proyecto / landing page
  • [ ] Newsletter o mailing list
  • [ ] Deck de presentacion (pitch para editoriales, conferencias, inversores)
  • [ ] Video demo del sistema (3-5 min)

Bloqueos

B1: Colapso algebraico de la factorizacion prima — CRITICO

Problema: El libro afirma que cada concepto = producto de primos y que la Regla de Tres opera algebraicamente: C4 = (a*C2*C3) / (b*C1). Pero la division de primos produce no-enteros (ej: Velocidad = Espacio(19) / Tiempo(97) = 0.1958), violando el Teorema Fundamental de la Aritmetica.

Evidencia: antigravity/COLAPSO_MATEMATICO.md — prueba formal de la inconsistencia.

Impacto: El sistema funciona como lenguaje semantico (90-100% match en tests ciegos) pero NO como algebra. Cualquier reviewer academico detectaria esto inmediatamente.

Opciones: 1. Reencuadrar — Aceptar que es taxonomia fenomenologica, no algebra. Editar libro y claims. Menor esfuerzo, pero reduce el alcance de la tesis. 2. Redisenar — Migrar de primos a grafos/tensores donde las operaciones si cierran. Mayor esfuerzo (~4-8 semanas), pero resuelve el problema de raiz. 3. Extender la matematica — Definir "primos generalizados" que permitan operaciones fraccionales. Riesgoso, podria no funcionar.

Resuelto? No. Decision pendiente.

B2: Formato de representacion no decidido — ALTO

Problema: Coexisten 3 formatos incompatibles sin decision formal:

Fuente Formato Dimensiones
Dataset (v1-v4) Floats tanh [-1, +1] 51D
Toolkit / Inventario Bits binarios 63D
Libro (teoria) Producto de primos variable

Impacto: No se puede construir pipeline encoder/decoder sin decidir el formato canonico. Migrar requiere re-codificar 2,050-3,675 conceptos.

Documento: dataset/REVISION_REPRESENTACION.md — presenta Opcion A (floats), B (bits/primos), C (hibrido). Sin decision al 2026-03-17.

Resuelto? No. Bloquea todo el desarrollo tecnico posterior.

B3: Validaciones disenadas pero no ejecutadas — ALTO

Problema: Dos protocolos de validacion criticos estan 100% disenados pero 0% ejecutados:

  1. Validacion humana (dataset/validacion_humana/protocolo_validacion.md): 3 niveles (concordancia, coherencia, reconstruccion), minimo 5 participantes. Sin sujetos reclutados.
  2. Validacion multi-IA (dataset/validacion_multi_ia/protocolo_comparacion.md): Claude vs GPT-4 vs Gemini vs Grok, 20 conceptos forward + 10 inverse. Solo baseline Claude completado.

Impacto: Sin estos, las claims del sistema son auto-referentes (IA valida lo que IA genero). Ningun journal serio aceptaria sin validacion externa.

Esfuerzo: Humana: 2-3 semanas. Multi-IA: 1-2 semanas.

Resuelto? No.

B4: Mapping NSM incompleto — MEDIO

Problema: El plan de investigacion identifica la convergencia con NSM (Natural Semantic Metalanguage, Wierzbicka) como critica para publicacion. De ~65 primitivos NSM, solo 9 estan mapeados formalmente al Sistema 7x7.

Impacto: Un reviewer preguntara "por que 51 y no 65?" Si la respuesta es convergencia con un framework establecido, es publicable. Si es "los elegimos nosotros", no lo es.

Esfuerzo: 1-2 semanas de analisis comparativo.

Resuelto? No.

B5: Muro de los Primos — MEDIO

Problema: Conceptos humanos complejos (amor, culpa, promesa, justicia) requieren estructura jerarquica/relacional que el modelo plano de primos no puede representar. Amor filial, romantico y compasivo necesitarian arboles de factores distintos, pero el modelo asigna un solo primo.

Evidencia: antigravity/EL_MURO_DE_LOS_PRIMOS.md.

Impacto: Limita el sistema a conceptos concretos y semi-abstractos. Los conceptos mas interesantes (eticos, emocionales, existenciales) quedan fuera del alcance algebraico.

Resuelto? Documentado como limitacion, no resuelto.

B6: Sin CI/CD ni tests automatizados — BAJO

Problema: No hay GitHub Actions, no hay pytest config, no hay linter. Los 35/35 tests del toolkit y los tests de antigravity existen pero se corren manualmente.

Impacto: Riesgo de regresion silenciosa. Cualquier cambio al toolkit o al dataset podria romper algo sin detectarse.

Esfuerzo: 1 dia para configurar CI basico.

Resuelto? No.

Resumen de prioridades

# Accion Bloquea Esfuerzo Prioridad
1 Decidir identidad del sistema (algebra vs lenguaje) Todo lo academico 1 semana (decision) CRITICA
2 Decidir formato canonico (floats vs bits vs primos) Pipeline, migracion 1 semana (decision) CRITICA
3 Completar mapping NSM (51 vs 65) Paper academico 1-2 semanas ALTA
4 Ejecutar validacion multi-IA Credibilidad 1-2 semanas ALTA
5 Ejecutar validacion humana Paper academico 2-3 semanas ALTA
6 Obtener ISBN + registrar copyright Publicacion KDP 2-4 semanas (tramite) ALTA
7 Consolidar dataset en formato unico Pipeline 3-4 semanas MEDIA
8 Construir encoder/decoder MVP Producto de software 6-8 semanas MEDIA
9 Configurar CI/CD Calidad de codigo 1 dia BAJA
10 Traduccion al ingles Mercado internacional 8-12 semanas BAJA

love-log

Last updated: 2026-03-22 Current version: v1.0.0+1 (Release Candidate) Status: APK builds, CI passes, but not production-signed

Técnico

Release Signing (CRITICAL)

  • [ ] Generar keystore de producción — keytool -genkey -v -keystore fuaflow-release.jks -keyalg RSA -keysize 2048 -validity 10000. Guardar fuera del repo
  • [x] Configurar key.properties en android/ (gitignored) — template key.properties.example creado con instrucciones. build.gradle.kts lee automáticamente de key.properties cuando existe
  • [x] Actualizar android/app/build.gradle.kts — signing config de producción implementado. Lee key.properties si existe, fallback a debug signing si no
  • [x] Configurar secrets en GitHub Actions — CI workflow actualizado para decodificar keystore desde KEYSTORE_BASE64 secret y crear key.properties automáticamente. Solo requiere agregar los 4 secrets en GitHub
  • [x] Habilitar R8/ProGuard — CI build ahora usa --obfuscate --split-debug-info=build/symbols en lugar de --no-shrink

CI/CD

  • [x] Firmar APK en CI — CI workflow actualizado con steps para decodificar keystore y crear key.properties. Solo falta agregar secrets en GitHub repo settings
  • [x] Crear GitHub Release automático — job release en CI: al pushear tag v*, descarga APK, genera release notes desde commits, crea GitHub Release con APK adjunto. Tags -rc/-beta se marcan como prerelease
  • [x] Agregar lint de cobertura — threshold 80% en CI. Parsea lcov.info (excluye .g.dart, .freezed.dart, l10n), cuenta líneas hit vs total, falla el build si coverage < 80%
  • [x] Crear CHANGELOG.md — creado con historial completo de v1.0.0+1

Código Pendiente

  • [x] recFlags en new_log — implementado chip selector con 10 red flags + 10 green flags predefinidos. JSON array guardado en DateLogsTable. Los 12/12 campos de DateLogsTable ahora son escritos por la UI
  • [ ] autoSentiment — siempre 0.0 en DateLogsTable. Requiere NLP on-device o backend. Posponer a v2.0
  • [ ] DashboardTrackersTable — tabla legacy muerta (migrada a EmojiTagsTable en v16). Mantener por backwards-compat de migraciones pero no agregar funcionalidad
  • [x] FuaFlowNetworkService — dependencia fuaflow_network path local reemplazada con stub local. P2P sync es no-op en v1.0. Restaurar cuando se publique en pub.dev
  • [x] Web manifest genérico — actualizado a "FuaFlow Log" con colores correctos (#E94560 theme, #1A1A2E background)
  • [x] Linux app ID — rebranded a com.fuaflow.lovelog
  • [x] Safe jsonDecode — todos los .cast<T>() reemplazados con .whereType<T>().toList() para prevenir crashes en datos legacy
  • [x] Safe list access — .firstWhere() sin orElse reemplazados con .firstOrNull + null guard
  • [x] Silent catch blocks — todos los catch (_) {} reemplazados con catch (e) { debugPrint(...); } para logging de errores
  • [x] Accesibilidad — Semantics, Tooltip, y semanticLabel agregados a: MainScaffold (nav items + FAB), new_log save button, CounterRow (+/- buttons), MoodEmojiSelector (5 emojis con labels), ImagePickerSection (add/delete photo), PersonDetailScreen (edit button), DiotimaLadderWidget (tap hint)
  • [x] Minor dep upgrade — 25 patches aplicados via flutter pub upgrade

Testing

  • [x] Tests de integración — 70 tests de integración con SQLite in-memory real (9 DAOs: PersonDao, DateLogDao, JournalDao, SettingsDao, DateIdeasDao, EmojiTagDao, HabitDao, ConversationAssetsDao, DashboardDao). CRUD, cascade delete, search, streams, upsert. Migración DB: schema fresh install (v25), v15→v25 (incluyendo migración de datos DashboardTrackers→EmojiTags en v16), v22→v25 (custom ALTER TABLE + creación de índices)
  • [x] Tests E2E — 10 tests de workflows cross-DAO: lifecycle completo de persona con cascade delete, top crush replacement, body count tracking, monthly date grouping, cross-table search, date ideas lifecycle, multi-person comparison
  • [x] Tests de providers — 173 tests unitarios cubriendo 15 provider files: dashboard (emoji count, streaks, heatmaps, comparison, emoji roles, used emojis), financial, person, milestone, habit, calendar, emoji analysis, date log, journal, database, network, onboarding, comparison
  • [x] Tests de servicios — 170 tests unitarios cubriendo 13 services: chemistry score, radar score, cycle, flags, emoji, backup, notification, AI client, feature flag, log
  • [x] Tests de widgets — 376 widget tests cubriendo 47 archivos: error boundary, feature slot, mood/stress selectors, skeleton loader, counter row, diotima ladder, calendar stats, security settings, habit heatmap, dashboard heatmaps, person dialogs, habits manager, lock screen, y 30+ widgets de componentes
  • [x] Tests de pantallas — 511 tests de render cubriendo 29 archivos: las 15 feature screens (candidates, calendar, dashboard, journal/chat, settings, new log, finance, comparison, flags, date ideas, playbook, search, onboarding, welcome, licenses)
  • [x] Tests de router — 69 tests cubriendo GoRouter: configuración, ShellRoute, sub-rutas, redirect guard, parámetros de ruta
  • [x] Tests de core — 81 tests unitarios cubriendo modelos y utilidades core
  • [x] Performance benchmarks — 9 tests con 50 personas + 500 logs + 200 journal entries: insert bulk <5s, watchAllLogs <500ms, filtros por persona/mes <200ms, cascade delete <500ms, body count query <200ms
  • [x] Cobertura 80% — 1,469 tests en 112 archivos. Cobertura 80.1% (10,284/12,840 líneas de código fuente, excluyendo archivos generados). CI threshold actualizado de 60% a 80%
  • [ ] Biometric lock en dispositivo físico — verificar local_auth en Android real con fingerprint y face
  • [ ] Home widgets en Android 12+ — probar los 3 widgets (TopCrush, Budget, Habit) en dispositivo real
  • [ ] Notificaciones en background kill — probar flutter_local_notifications + workmanager cuando el OS mata la app
  • [ ] Accesibilidad en dispositivo — audit con TalkBack (Android), verificar contraste y navigation order. Semantics/Tooltip ya agregados programáticamente a 7 widgets clave

Performance

  • [ ] Profiling de arranque — medir cold start en dispositivo gama baja (target < 3s)
  • [x] DB con datos grandes — 9 benchmark tests con 500+ logs y 50+ candidatos verifican que queries reactivos completan en <500ms (in-memory SQLite)
  • [x] Tamaño del APK — CI reporta APK size en MB como ::notice:: annotation después del build. Obfuscation habilitado

Seguridad

  • [x] Audit de dependencias — ejecutado flutter pub outdated: 25 minor patches disponibles, 31 major versions detrás, 0 CVEs. 3 transitive packages discontinued (js, build_resolvers, build_runner_core)
  • [x] Ofuscar Dart — CI build actualizado con --obfuscate --split-debug-info=build/symbols
  • [x] AI Client stubbed — fuaflow_ai_client.dart reemplazado con stub sin HTTP calls. Dependencia http removida de pubspec.yaml. Zero conexiones externas
  • [x] Deps no usadas removidas — flutter_blurhash, flutter_shaders eliminadas (0 imports). Dependencia http eliminada
  • [x] Android hardening — allowBackup="false", usesCleartextTraffic="false", network_security_config.xml creado bloqueando cleartext traffic
  • [x] Feature flag DRY — 13 providers idénticos refactorizados a _watchFeatureFlag() helper (-70 líneas)
  • [x] JSON decode centralizado — decodeIntList() y decodeMapList() agregados a EmojiTagUtils; callers actualizados
  • [x] Magic numbers → constantes — 22 constantes nombradas extraídas en ChemistryScoreService y RadarScoreService
  • [x] Financial providers fix — .when(loading: []) reemplazado con await .future para prevenir cálculos incorrectos
  • [ ] Validar que flutter_secure_storage encripta correctamente en todos los Android target (API 21-34)

Comercial

Play Store

  • [ ] Cuenta de Google Play Developer — $25 one-time fee, requiere identidad verificada
  • [ ] Content rating questionnaire — clasificar como Lifestyle/Dating, High Maturity (tracking de intimidad + alcohol)
  • [ ] Store listing completo — título, descripción corta/larga (EN + ES ya redactados en PLAY_STORE_LISTING.md), categoría, tags
  • [ ] Screenshots reales — mínimo 4 por idioma (phone). Actualmente la landing page tiene placeholders
  • [ ] Feature graphic — banner 1024x500 para Play Store
  • [ ] Icono 512x512 — ya existe lovelog_icon.png (405KB), verificar que cumple guidelines
  • [ ] Política de privacidad pública — URL accesible (requerido por Play Store). El contenido existe en l10n pero no hay URL pública hospedada
  • [ ] Data safety form — declarar: no data collection, no data sharing, local-only storage, biometric auth
  • [ ] Pre-launch report — Firebase Test Lab corre automáticamente en upload al track interno; revisar crashes

App Store (iOS) — v1.2

  • [ ] Proyecto iOS configurado — directorio ios/ existe pero está vacío/stub
  • [ ] Apple Developer account — $99/año
  • [ ] Bundle ID — com.fuaflow.lovelog
  • [ ] TestFlight beta — distribuir a testers antes de public launch
  • [ ] App Store review — más estricto que Play Store, verificar guidelines de dating apps

Landing Page & Web Presence

  • [ ] Deploy fuaflow-web/ en Cloudflare Pages — ya configurado en fuaflow.md, falta ejecutar
  • [ ] Dominio fuaflow.com — vincular a Cloudflare
  • [ ] Screenshots reales en landing — reemplazar placeholders
  • [ ] Botón de descarga funcional — enlazar a Play Store listing una vez publicado
  • [ ] SEO básico — meta tags, Open Graph, robots.txt

Monetización

  • [ ] Definir modelo — opciones viables para app local-first sin backend:
  • Freemium: features avanzadas (chemistry, radar, comparison, AI) detrás de paywall
  • One-time purchase: unlock completo via Play Store IAP
  • Donation-ware: links a BuyMeACoffee/Patreon (ya existen en welcome_screen)
  • Paid app: precio fijo en Play Store (más simple, menor fricción)
  • [ ] Implementar IAP si freemium — in_app_purchase package + receipt validation
  • [ ] FeatureFlagService como paywall — ya existe infraestructura de 12 toggles, se puede reusar para gating comercial

Analytics & Growth

  • [ ] Crash reporting — Sentry o Firebase Crashlytics (actualmente 0 telemetría). Puede ser privacy-respecting (opt-in, no PII)
  • [ ] App store analytics — monitorear installs, ratings, retention desde Play Console
  • [ ] In-app feedback — mecanismo para que usuarios reporten bugs o pidan features sin salir de la app
  • [ ] ASO (App Store Optimization) — keywords, A/B test de screenshots, descripción optimizada
  • [ ] Términos de servicio publicados — URL pública (contenido ya escrito en l10n)
  • [ ] Aviso de disclaimer — la app trackea datos sensibles (intimidad, ciclo menstrual, alcohol); disclaimer visible en onboarding o settings
  • [ ] GDPR compliance — aunque es local-only, el backup exporta .db con datos personales. Documentar que el usuario controla sus datos al 100%
  • [ ] Age restriction — content rating de 17+ o 18+ por tracking de actividad sexual y alcohol

Bloqueos

Estos items impiden el lanzamiento. Sin resolverlos no se puede publicar.

1. No hay signing key de producción

Impacto: No se puede subir a Play Store. El APK actual está firmado con debug key. Solución: Generar keystore, configurar build.gradle.kts, guardar key offline segura (backup en safe/vault). La key es irrecuperable — perderla = no poder actualizar la app nunca.

2. No hay cuenta de Google Play Developer

Impacto: No hay canal de distribución. Solución: Registrar en play.google.com/console, verificar identidad, pagar $25.

3. No hay política de privacidad en URL pública

Impacto: Play Store rechaza apps sin privacy policy accesible. El contenido existe en la app (l10n) pero no en una URL. Solución: Publicar en fuaflow.com/privacy (landing page ya existe en Cloudflare) o usar un servicio gratuito. Enlazar desde Play Store listing y desde la app.

~~4. Dependencia fuaflow_network es path local~~ — RESUELTO

Estado: Reemplazado con stub local (core/services/fuaflow_network_stub.dart). P2P sync funciona como no-op. Restaurar cuando fuaflow_network se publique en pub.dev o como dependencia Git.

5. Content rating requerido

Impacto: Play Store no permite publicar sin content rating. La app trackea: actividad sexual (hadSex, rounds, finisher), consumo de alcohol (alcoholUnits), ciclo menstrual. Esto requiere clasificación de contenido adulto. Solución: Completar IARC questionnaire honestamente. Esperar rating de 17+/18+. Esto limita audiencia pero es obligatorio por los datos que maneja.

Documento generado desde auditoría completa del codebase (153 source files + 42 generated, 112 test files, 1,469 test cases, 80% coverage, CI pipeline, Android config, web config, MASTERPLAN.md). Última actualización: 2026-03-22.

neurosym-client

What remains before v1.0 and commercial launch.

Tecnico

Testing

  • [ ] Add HTTP-level tests (mock httpx responses for every endpoint: encode, search, audit, anomaly_scan, usage, health, batch_*)
  • [ ] Add tests for TriadicRetriever and TriadicVectorStore (mock namespace calls, verify metadata enrichment)
  • [ ] Add tests for error mapping (_raise_for_status with each HTTP code)
  • [ ] Add pytest step to CI pipeline (currently only runs ruff + pyright, never runs tests)
  • [ ] Configure coverage reporting (pytest-cov) with minimum threshold
  • [ ] Add integration test suite (opt-in, requires live API key via env var)

Client robustness

  • [ ] Automatic retry with exponential backoff on 429 and 5xx responses
  • [ ] Expose X-RateLimit-* response headers on RateLimitError (docstring promises them, client ignores them)
  • [ ] Add async client (TriadicAsyncClient) backed by httpx.AsyncClient
  • [ ] Add Python logging integration for request/response debugging
  • [ ] Client-side validation of namespace format (1-64 alphanumeric/dash/underscore, per docstring contract)
  • [ ] Pagination support for namespace.list() and webhooks.list()

Type safety

  • [ ] Add py.typed marker file (PEP 561) so downstream type checkers recognize the package
  • [ ] Replace raw Dict returns with typed dataclasses or TypedDict for each endpoint response
  • [ ] Have TriadicRetriever inherit from langchain_core.retrievers.BaseRetriever (currently duck-typed, fails isinstance checks)
  • [ ] Have TriadicVectorStore inherit from llama_index.core.vector_stores.types.BasePydanticVectorStore (same issue)

Build & release

  • [ ] Single-source version: derive __init__.__version__ and User-Agent header from pyproject.toml instead of hardcoding "0.1.0" in three places
  • [ ] Add CHANGELOG.md (keep-a-changelog format)
  • [ ] Rename PermissionError to TierError or ForbiddenError to avoid shadowing Python's built-in PermissionError
  • [ ] Add Python 3.13 to CI test matrix (currently only tests on 3.11)

Comercial

Distribution

  • [ ] Configure PyPI Trusted Publishing (OIDC) at pypi.org for neurosym-cloud
  • [ ] Push first v0.1.0 tag to trigger initial PyPI release
  • [ ] Make repository public (currently private) so users can discover and report issues
  • [ ] Add GitHub repository social preview image

Documentation

  • [ ] Create examples/ directory with runnable scripts (quickstart, namespaces, RAG chain, anomaly scan)
  • [ ] Add Jupyter notebook demo (examples/quickstart.ipynb)
  • [ ] Deploy docs site (MkDocs or Sphinx) with full API reference
  • [ ] Add "Get your API key" CTA in README hero section with direct signup link

Ecosystem

  • [ ] Publish to conda-forge
  • [ ] TypeScript/Node.js SDK for web developers
  • [ ] REST API OpenAPI spec published (enables auto-generated clients for Go, Java, etc.)

Bloqueos

These must be resolved before any public release:

# Blocker Why
1 PyPI Trusted Publishing not configured CI workflow references OIDC publishing but it may not be set up at pypi.org — first v* tag push will fail silently
2 CI never runs pytest Code ships without automated test verification — a ruff/pyright pass does not catch runtime bugs
3 No HTTP-level tests exist All 12 tests are structural (init, attributes, exceptions) — zero tests verify actual API request/response behavior
4 Version hardcoded in 3 files pyproject.toml, __init__.py, and client.py User-Agent — first version bump will cause drift if any file is missed
5 Repo is private pip install neurosym-cloud will 404 on PyPI until published; GitHub issues/PRs inaccessible to users

reptimeline

What's needed to take reptimeline from research prototype to production-ready, commercially viable tool.

Técnico

Distribución y CI

  • [ ] Publicar en PyPI (el README dice pip install reptimeline pero no está publicado)
  • [x] GitHub Actions: tests (Python 3.10-3.13), ruff lint, coverage en cada PR
  • [x] Pre-commit hooks (.pre-commit-config.yaml con ruff check + ruff-format)
  • [x] Coverage reporting (pytest-cov configurado en pyproject.toml + coverage XML en CI)
  • [x] Badges en README: CI status, Python versions, license

Calidad de código

  • [x] Codebase ruff-clean (0 warnings: import sorting, unused imports, line length, naming)
  • [x] Type checking con mypy (0 errors, integrado en CI)
  • [x] Logging estructurado en CLI y extractors (print_summary/print_report siguen como API de usuario)
  • [x] Progress bars con tqdm en extract_sequence y discovery triádica
  • [x] Manejo de errores más granular: excepciones custom (SnapshotError, ExtractionError, DiscoveryError, ConfigurationError)

Documentación

  • [x] Generar sitio de docs con pdoc + GitHub Pages workflow automático
  • [x] Docstrings de API reference para todos los parámetros de thresholds en BitDiscovery
  • [x] Guía de migración para usuarios de triadic-microgpt (docs/migration-from-triadic.md)

Funcionalidad

  • [ ] Soporte para snapshots incrementales (actualmente requiere todos los checkpoints en memoria)
  • [x] Export a CSV y JSON round-trip (Timeline.to_csv(), save_json/load_json, from_dict)
  • [ ] Export a Parquet, WandB, TensorBoard
  • [x] Serialización robusta: schema_version: "0.1" en ConceptSnapshot y Timeline JSON
  • [ ] Paralelización de discovery triádica (actualmente single-thread, O(K³))
  • [x] Extractors built-in: SAEExtractor, VQVAEExtractor, FSQExtractor (4 backends validados con tests)
  • [ ] Más extractors: concept bottleneck models, DINO features, quantized LLMs
  • [ ] Tests de rendimiento con datasets grandes (actual validación: 10-60 conceptos)

Visualización

  • [x] Plots interactivos con Plotly (4 plots: phase dashboard, swimlane, churn heatmap, causal heatmap)
  • [x] Colores de capas dinámicos en layer_emergence.py (escala a cualquier número de capas)
  • [x] Export de plots a HTML standalone (via Plotly save_html)

Comercial

  • [x] Auditoría de dependencias: todas las dependencias son comercialmente compatibles (BSD, MIT, Apache-2.0, MPL-2.0)
  • [x] Eliminar dependencia AGPL: pdoc3 (AGPL-3.0) reemplazado por pdoc (Unlicense)
  • [ ] Definir términos de licencia comercial (precio, tiers, límites)
  • [ ] Página de pricing o contacto comercial (actualmente solo un email)
  • [ ] CLA (Contributor License Agreement) si se aceptan contribuciones externas
  • [ ] Revisar si BUSL-1.1 → AGPL-3.0 (2030) es el timeline correcto para el negocio

Validación

  • [ ] Resolver el resultado negativo en predicción (-0.13% embedding, -4.20% MLP vs baseline)
  • [x] SAE validado con Pythia-70M (32K features); VQ-VAE y FSQ con unit tests
  • [ ] Validar VQ-VAE y FSQ en producción real; validar concept bottleneck models
  • [ ] Case studies documentados más allá de MNIST y Pythia-70M
  • [ ] Benchmarks de rendimiento: tiempo de análisis vs tamaño de codebook

Go-to-market

  • [ ] Landing page del proyecto (actualmente solo el repo)
  • [ ] Tutorial interactivo (notebook) que funcione en Google Colab
  • [ ] Integración con ecosistema ML: WandB callback, Lightning hook, HuggingFace integration
  • [ ] Paper publicado y citeable (actualmente en draft)

Comunidad

  • [x] CONTRIBUTING.md con guía de contribución
  • [x] Issue templates en GitHub (bug report + feature request)
  • [x] Ejemplos reproducibles que corran sin datos propietarios ni GPUs (default device=cpu, hardcoded paths removed)

Bloqueos

Críticos (bloquean producción)

  1. No está en PyPI. python -m build ya produce sdist + wheel correctamente y el publish workflow existe. Falta: crear cuenta en PyPI y configurar trusted publishing.
  2. Resultado negativo en predicción. Los features descubiertos son causalmente selectivos pero no mejoran predicción. Esto limita el argumento comercial de "interpretabilidad actionable".

Importantes (bloquean escala)

  1. Discovery triádica no escala. O(K³) con K = bits activos. Para SAEs con miles de features activos, es prohibitivo sin paralelización o sampling.
  2. Sentinel features sin resolver. 8/16 features SAE mostraron zero cross-activation. No se puede distinguir entre selectividad perfecta y artefacto de sparsity.
  3. Validación en producción. 4 extractors implementados con 224 tests, pero VQ-VAE y FSQ solo tienen unit tests — falta validación con modelos reales.

Resueltos

  • ~~Sin CI/CD~~ — GitHub Actions CI: tests (Python 3.10-3.13), ruff lint, coverage. Publish workflow con trusted publishing.
  • ~~Solo 2 backends~~ — 4 extractors (SAE, VQ-VAE, FSQ + triadic example). SAE validado con Pythia-70M.
  • ~~Sin logging~~ — CLI y extractors usan logging module.
  • ~~JSON sin schema version~~ — schema_version: "0.1" en ConceptSnapshot y Timeline.
  • ~~Ruff warnings~~ — Codebase 100% ruff-clean.
  • ~~Sin type checking~~ — mypy 0 errors, integrado en CI.
  • ~~Pre-commit hooks~~ — ruff check + ruff-format.
  • ~~Sin progress bars~~ — tqdm en extract_sequence y discovery triádica.
  • ~~Sin docs site~~ — pdoc + GitHub Pages deploy automático.
  • ~~Sin CONTRIBUTING.md~~ — Guía de contribución + issue templates.
  • ~~Build no verificado~~ — python -m build produce sdist + wheel correctamente.
  • ~~ValueError genérico~~ — Excepciones custom: SnapshotError, ExtractionError, DiscoveryError, ConfigurationError.
  • ~~Sin docstrings de thresholds~~ — BitDiscovery.init y discover() documentados con rangos, defaults y guías prácticas.
  • ~~Ejemplos requieren GPU~~ — Todos los examples/ usan default device=cpu; hardcoded paths eliminados.
  • ~~Sin guía de migración~~ — docs/migration-from-triadic.md con import mapping, paso a paso, y referencia de formatos.
  • ~~Sin export CSV~~ — Timeline.to_csv() + save_json/load_json + from_dict round-trip.
  • ~~Colores hardcoded~~ — layer_emergence.py usa colormap dinámico para cualquier número de capas.
  • ~~Sin plots interactivos~~ — 4 plots Plotly (phase dashboard, swimlane, churn, causal) con export a HTML.
  • ~~Dependencia AGPL~~ — pdoc3 (AGPL-3.0) reemplazado por pdoc (Unlicense). Cero copyleft en el árbol de dependencias.
  • ~~Sin auditoría de licencias~~ — Todas las dependencias verificadas: BSD, MIT, Apache-2.0, MPL-2.0. Código 100% original.

triadic-cloud

Estado actual: 66/66 features implementadas. El código está completo. Lo que falta es infraestructura y credenciales.

Técnico

~~Tests (P0 — sin esto no hay CI real)~~ DONE

  • [x] Crear tests/ con pytest: health, encode, search, auth, rate limits, tier gating, usage, webhooks, batch jobs, register, anomaly scan
  • [x] Agregar conftest.py con fixtures (temp DB por test, httpx.AsyncClient via ASGITransport)
  • [x] 98 tests pasando — CI ya los ejecuta en cada push/PR
  • [x] pytest.ini con asyncio_mode = auto
  • [x] Cobertura: /health, /pricing, /license, /encode, /search, /audit, /report, /anomaly/scan, /index, /register, key lifecycle, tier upgrade/downgrade, rate limits, usage tracking, admin metrics, webhook CRUD, batch jobs

~~Dependencias~~ DONE

  • [x] Agregar pandas>=2.0 a requirements.txt
  • [x] Descomentar psycopg2-binary y PyJWT en requirements.txt

~~Seguridad~~ DONE

  • [x] Generar par RSA para licencias on-premise (deploy/license_private.pem + deploy/license_public.pem)
  • [x] license_private.pem en .gitignore — guardar private key offline
  • [ ] Revisar que ADMIN_TOKEN esté configurado antes de deploy (actualmente devuelve 503 si falta, que es correcto)

~~Docs internas desactualizadas~~ DONE

  • [x] docs/MONETIZATION.md — rutas corregidas a auth/keys.py, auth/billing.py, etc.
  • [x] docs/WEB_DEPLOYMENT_TODO.md — 24 items marcados como completados
  • [x] landing/index.html footer copyright actualizado a 2026
  • [x] CONTRIBUTING.md creado con guía de dev setup
  • [x] landing/terms.html y landing/privacy.html creados

~~Code quality~~ DONE

  • [x] Eliminar 542 deprecation warnings: datetime.utcnow() → _utcnow() (timezone-aware)

Bugs pendientes (baja prioridad)

  • [ ] Bug #2: modo contrastive en app desktop requiere UI para hypernym pairs
  • [ ] Bug #4: uso anónimo (Community sin key) no es revocable por IP — solo por rate limit global

Comercial

Stripe (bloqueo principal)

  • [ ] Crear cuenta Stripe y verificar identidad
  • [ ] Crear productos: Pro Monthly ($49), Pro Yearly (~$470), Enterprise Monthly (custom)
  • [ ] Copiar Price IDs al .env: STRIPE_PRICE_PRO_MONTHLY, STRIPE_PRICE_PRO_YEARLY, STRIPE_PRICE_ENT_MONTHLY
  • [ ] Copiar STRIPE_SECRET_KEY y configurar webhook (checkout.session.completed, customer.subscription.deleted, invoice.payment_failed)
  • [ ] Copiar STRIPE_WEBHOOK_SECRET
  • [ ] Test con tarjeta 4242 4242 4242 4242 antes de go-live
  • [ ] Cambiar de sk_test_ a sk_live_ cuando esté listo

Dominio & TLS

  • [ ] Apuntar DNS api.fuaflow.com → servidor (Railway custom domain o VPS con CNAME)
  • [ ] Configurar HTTPS (Railway lo da automático; VPS necesita certbot --nginx)
  • [ ] Cambiar CORS_ORIGINS de localhost a https://fuaflow.com,https://app.fuaflow.com

Email

  • [ ] Configurar SendGrid o Resend para welcome emails post-registro
  • [ ] Verificar dominio fuaflow.com en el proveedor de email (SPF/DKIM)
  • [x] Terms of Service — landing/terms.html (10 secciones, dark theme)
  • [x] Privacy Policy — landing/privacy.html (datos almacenados vs NO almacenados, retención, derechos)
  • [x] Links en footer de landing page

Distribución

  • [ ] Publicar neurosym-client a PyPI (hatch build && twine upload) — single-source version + py.typed + 24 tests listos
  • [ ] PR a langchain-community con TriadicRetriever
  • [ ] PR a llama-index con TriadicVectorStore

Bloqueos

Nada de lo anterior requiere cambios de código. Son 4 acciones manuales que bloquean el go-live:

# Bloqueo Esfuerzo Dependencia
1 Stripe: crear cuenta + productos + webhook ~2 horas Verificación de identidad Stripe
2 Dominio + TLS: DNS + certificado ~1 hora Acceso a Cloudflare/registrar DNS
~~3~~ ~~RSA key pair: generar claves para licencias on-premise~~ ~~DONE~~ ~~Ninguna~~
4 neurosym-client PyPI: push + upload ~30 min Cuenta PyPI con Trusted Publishing

Una vez resueltos 1, 2 y 4, el sistema está listo para recibir pagos.

triadic-emergent-duality

Status snapshot as of 2026-03-24. Items reflect actual repository state.

Technical

Done (no work required)

  • [x] 37 theory documents (~44,000 words) covering formal definitions, philosophical precedents, and empirical tests
  • [x] 32 validation scripts across 9 domains
  • [x] GPT-2 Medium + 72-bit triadic head trained (v5_frozen: PPL 31.95, 90.8% accuracy, 100% unique)
  • [x] requirements.txt with pinned dependencies
  • [x] LICENSE file (BUSL-1.1 with consortium model)
  • [x] TERMS.md and COMMERCIAL.md for contribution obligations
  • [x] reptimeline integration for training dynamics analysis
  • [x] Paper compiled (LaTeX, 7 pages)
  • [x] 5 training runs documented (v1-v5) with full experiment log
  • [x] Inter-rater reliability data (Mathematics domain)
  • [x] Algebraic layer verification (86% match across 6 algebras)

Pending — High Priority

  • [ ] Publish paper on Zenodo — PDF compiled, needs DOI. Independent researcher without institutional affiliation (no arXiv access).
  • [ ] CI/CD — No GitHub Actions. Minimum: lint + validation script runner on push.
  • [ ] Complete inter-rater data — Only Mathematics_rater2.csv exists. Need remaining 8 domains for full external verification.
  • [ ] Publish model weights — v5_frozen checkpoint not publicly available. Options: GitHub Releases or HuggingFace Hub.

Pending — Medium Priority

  • [ ] Scale-algebra tradeoff — GPT-2 355M achieves 76.9% subsumption vs 98.3% at 40M. Cause under investigation.
  • [ ] Docker environment — For reproducible GPU training.
  • [ ] Translate theory docs to English — 37 documents currently in Spanish. At minimum, translate abstracts/summaries.
  • [ ] Generate figures — figures/ directory empty. Need DAG, spiral, and per-domain result visualizations.

Pending — Low Priority

  • [ ] REST API / CLI — For querying primitives of a given concept.
  • [ ] pip-installable package — pip install triadic-emergent-duality.
  • [ ] Technical documentation site — Sphinx or MkDocs. Currently only the 37 theory .md files.

Commercial

Assets Ready

  • Paper — 7-page LaTeX, compiled PDF, ready for Zenodo.
  • Framework — 72 semantic primitives, 6 algebraic layers, 14 dualities. Validated across 9 disciplines.
  • Model — GPT-2 Medium + 72-bit triadic head (v5_frozen). Catastrophic forgetting solved.
  • License — BUSL-1.1 with consortium model. Free for individuals/academia/nonprofits. Companies must participate.

Pending — Monetization

  • [ ] Zenodo DOI — Required before any other publication step.
  • [ ] Benchmarks vs alternatives — Compare against ConceptNet, FrameNet, WordNet for positioning.
  • [ ] Concrete use case demo — NLP, ontology engineering, knowledge graphs, or curriculum design.
  • [ ] Landing page — Interactive demo (input concept, output vector + active dualities).

Blockers

Blocker Severity Impact
No published model weights High Results not reproducible by third parties
Inter-rater data incomplete (1/9 domains) High IDVS metric not externally verifiable for 8 domains
Underpowered statistics (n=7/14) High Peer reviewers may reject ordering claims without more evidence
3 domains within null distribution Medium Weakens universal validation claim
No peer review Medium All results are self-reported
Theory docs in Spanish only Medium Limits international audience

triadic-microgpt

Status snapshot as of 2026-03-22. All items are derived from the actual repo state, not aspirational.

Tecnico

Listo (no requiere trabajo)

  • [x] Modelo de produccion: Run 15 (40M, PPL 7.69, gap +0.020, 0% costo lenguaje)
  • [x] Modelo supervisado: D-A14 v2 (93% test, 98.3% subsumption, 158 anchors)
  • [x] Algebra a 355M restaurada: D-A19 (97.1% bits, 76.9% sub, 100% R3)
  • [x] 37 unit tests pasando (autograd, transformer, triadic, integration)
  • [x] 12 benchmark scripts ejecutados, 27 JSON de resultados
  • [x] 8 audit tests formales con resultados (PF bridge, Aristotelian, enantiodromia, cherry-picking)
  • [x] Paper compilado (27pp, 11 experimentos, 12 figuras)
  • [x] Desktop UI funcional (PySide6, 7 tabs, 3 backends)
  • [x] BitwiseValidator isomorfico a PrimeMapper (1000/1000 equiv, 5-78x mas rapido)
  • [x] Bugs en torch_finetune.py corregidos (GradScaler, dtype, dist-weight)
  • [x] Correcciones de paper integradas (+0.099 -> +0.076, 70% -> 48%, "zero cost" -> "+1.7%")
  • [x] triadic-head v0.1.0 construido y validado (wheel + tar.gz, signal +8.5% sobre random)
  • [x] reptimeline v0.1.0 committed al repo con tests, viz, y discovery
  • [x] Guia de reproducibilidad completa (playground/REPRODUCIBILITY.md, ~46h GPU)
  • [x] environment.yml + requirements.txt para instalacion

Pendiente — Prioridad Alta

  • [ ] Publicar triadic-head en PyPI — wheel listo en triadic-head/dist/, falta twine upload. Publicar DESPUES del paper para que la referencia exista.
  • [ ] Publicar reptimeline en PyPI — codigo listo, falta revisar pyproject.toml y subir con twine. Depende de validacion con un segundo backend (no triadic) para confirmar generalidad.
  • [ ] CI/CD basico — No hay GitHub Actions. Minimo: (1) pytest tests/test_all.py en push, (2) pytest triadic-head/tests/ en push, (3) lint con ruff/flake8. Un workflow de ~30 lineas.
  • [ ] Limpiar archivos legacy de raiz — model_fast.npz (431 KB), model_fast.vocab (48 B), verify_training.py (usa modulos obsoletos), tokenizer.json (13 KB, NO es el de Run 15). Estos confunden a usuarios nuevos.
  • [ ] Estrategia de checkpoints — 45 dirs, ~235 GB via Git LFS. Solo 4-6 son utiles (Run 15, D-A14, D-A19, Concept 49-bit, chat_run8, Exp10 InfoNCE). El resto son artefactos experimentales. Opciones: (a) mover a un release de GitHub, (b) Zenodo dataset, (c) documentar cuales ignorar.

Pendiente — Prioridad Media

  • [ ] torch.compile en Windows — Requiere Triton (solo Linux). El guard try: import triton ya existe, pero training en Windows es ~10-30% mas lento. Opciones: (a) WSL2 doc, (b) Docker con CUDA, (c) aceptar el overhead.
  • [ ] Crear implementacion minima de referencia — <500 lineas, solo torch_transformer.py + triadic.py + train loop. Para que usuarios entiendan la tecnica sin navegar 127 .py files. Pendiente en pending_minimal_triadic.md.
  • [ ] Hardcoded tokenizer paths — Varios scripts asumen paths relativos a checkpoints/. Centralizar en un config.py o variable de entorno.
  • [ ] Conceptual tokenizer Phases 5-6 — Phase 4 (post-hoc) fallo. Phase 4b (end-to-end, 86.2%) funciono. Falta: Phase 5 (subsumption loss supervisado) y Phase 6 (self-supervised a 40M+). Experimental, no bloquea nada.
  • [ ] Relational prime chains — Extension propuesta para anti-alucinacion algebraica O(1). Documentada en research/relational_prime_chains.md, codigo no iniciado. Phase A (post-hoc, 0 GPU, ~5 dias) es viable como siguiente paper.

Pendiente — Prioridad Baja

  • [ ] Dead bits (~15/64) — Entropy regularization mitiga pero no elimina. Aceptable para paper. iFSQ activation (D-A16) reduce a ~0 en modo supervisado, pero no resuelve el caso self-supervised.
  • [ ] R3 loss muerta a k=64 — 3 experimentos confirman colapso a 64/64 dead bits. A k=6-12 funciona pero destruye semantic gap. Documentado como limitacion, no como bug.
  • [ ] Cross-dataset generalization — Run 15 entrenado solo en TinyStories. PPL en WikiText-2 y LAMBADA es alto (OOD esperado). Para produccion real, entrenar en corpus mas diverso.
  • [ ] HuggingFace model card — Deliberadamente omitido (la tecnica importa, no los pesos). Reconsiderar si se busca adopcion academica.

Comercial

Activos Listos

  • triadic-head (BUSL-1.1) — Paquete standalone para cualquier modelo HF. API: wrap, train, encode, compare, validate, explore. Soporta GPT-2, LLaMA, Mistral, Phi, Qwen, OPT, Falcon.
  • neurosym-client (Proprietary, v0.1.0 en PyPI) — SDK Python para triadic-cloud API.
  • triadic-cloud (Proprietary, repo privado) — FastAPI + Stripe ($29-299/mo), desplegado en Railway. Usa neurosym (post-hoc).
  • Paper — 27 paginas compilado, listo para Zenodo. 11 experimentos, 29 runs, resultados reproducibles.
  • Desktop UI — Aplicacion funcional para demos presenciales o screencasts.

Pendiente — Monetizacion

  • [ ] Endpoint /encode-e2e en triadic-cloud — Actualmente solo usa neurosym (post-hoc). Agregar backend MicroGPT para ofrecer encoding end-to-end como servicio. Requiere: (1) serializar Run 15 para inference, (2) endpoint FastAPI, (3) actualizar pricing tier.
  • [ ] Publicar paper en Zenodo — PDF listo. Crear DOI. Sin arXiv (investigador independiente, sin afiliacion institucional). El DOI es necesario para que triadic-head tenga referencia citable.
  • [ ] Publicar triadic-head en PyPI — Secuencia: paper DOI primero -> luego PyPI con DOI en metadata.
  • [ ] Documentacion publica — No hay site de docs (readthedocs, GitHub Pages). El README es extenso (529 lineas) pero no reemplaza docs interactivas. Minimo: un tutorial "attach triadic head to GPT-2 in 20 lines".
  • [ ] Demo hosted — No hay playground web. Opciones: (a) Gradio/Streamlit en HuggingFace Spaces (gratis), (b) pagina en fuaflow.com. La UI de escritorio no sirve como demo remota.
  • [x] Licencia — BUSL-1.1 con modelo de consorcio. Individuos/academia/nonprofits gratis, empresas participan. Change Date 2030-03-22 → AGPL-3.0.

Estrategia de Ecosistema (Definida)

Componente Licencia Estado Rol
triadic-head BUSL-1.1 Built, no publicado Paquete standalone
triadic-microgpt BUSL-1.1 Completo Referencia de investigacion + paper
triadic-cloud Proprietary Desplegado Revenue
neurosym-client Proprietary v0.1.0 en PyPI SDK para cloud API
Triadic Engine BUSL-1.1 v0.2.0 en PyPI Libreria post-hoc (parent)
Paper CC-BY-4.0 (Zenodo) PDF listo Credibilidad academica

Bloqueos

Bloqueo 1: Paper sin DOI

Problema: El paper esta compilado (27pp) pero no tiene DOI ni esta publicado en ninguna plataforma. Sin DOI, triadic-head no puede referenciar el paper en su metadata de PyPI, y la tecnica no es citable.

Causa raiz: Investigador independiente sin afiliacion institucional. arXiv requiere endorsement.

Opciones: 1. Zenodo (mas rapido) — Subir PDF, obtener DOI en minutos. Sin peer review pero citable. 2. OpenReview — Submision abierta, peer review publico. 3. arXiv endorsement — Buscar endorser en cs.CL o cs.AI.

Impacto: Bloquea publicacion de triadic-head en PyPI (secuencia: DOI -> PyPI).

Bloqueo 2: reptimeline necesita segundo backend

Problema: reptimeline esta disenado como backend-agnostic (ABC RepresentationExtractor), pero solo tiene un extractor implementado (TriadicExtractor). Para publicarlo como herramienta general, necesita al menos un segundo backend (VQ-VAE, SAE, o FSQ) que confirme que la abstraccion funciona.

Causa raiz: Prioridad fue el paper, no la generalidad del tooling.

Opciones: 1. Implementar SAEExtractor (~2 dias, SAE es el mas natural siguiente). 2. Publicar como triadic-only y generalizar despues. 3. Mantener en el repo sin publicar en PyPI.

Impacto: Bloquea publicacion de reptimeline como paquete standalone. No bloquea nada mas.

Bloqueo 3: Tamanio del repositorio (~235 GB checkpoints)

Problema: Git LFS trackea .pt files, pero el repo tiene 45 directorios de checkpoints. Clonar el repo descarga ~235 GB. Esto hace el proyecto inaccesible para la mayoria de usuarios.

Causa raiz: Cada experimento guardo checkpoints intermedios. No hubo cleanup despues de la fase experimental.

Opciones: 1. GitHub Releases — Mover checkpoints a releases tagged (Run 15, D-A14, D-A19 como assets descargables). 2. Zenodo dataset — Upload como dataset citeable con DOI separado. 3. HuggingFace Hub — Subir solo los 4-6 modelos utiles. 4. Purge + script — Eliminar checkpoints del repo, agregar scripts/download_checkpoints.py.

Impacto: Bloquea adopcion publica del repo. No bloquea desarrollo local.

No son bloqueos (resueltos o aceptados)

Item Estado Razon
Bugs en torch_finetune.py RESUELTO Todos corregidos en commit 126eb7b
D-A17 algebra destruida a 355M RESUELTO D-A19 restaura algebra (bugs en loss, no limitacion de escala)
Coherence loss = collapse RESUELTO Permanentemente removida, documentada como anti-patron
Dead bits ~15/64 ACEPTADO Mitigado con entropy reg, no eliminable sin iFSQ supervisado
R3 muerta a k=64 ACEPTADO Documentado como limitacion inherente, funciona a k=6-12
torch.compile en Windows ACEPTADO Guard existe, overhead 10-30% aceptable para desarrollo
Paper corrections RESUELTO 7 correcciones integradas en commits recientes

Triadic-Neurosymbolic-Engine

What remains for the Triadic Neurosymbolic Engine to be production-ready and commercially viable.

Tecnico

Test coverage

  • [ ] PrimeIndexDB — 8 public methods, 0 tests (save/load/delete/export/list)
  • [ ] ScalableGraphBuilder — 5 public methods, 0 tests (build_index, find_edges, find_neighbors, get_stats)
  • [ ] ReportGenerator — 8 public methods, 0 tests (to_html, to_json, to_csv, save)
  • [ ] OpenAIEncoder / CohereEncoder — 0 tests (require API keys; add with @pytest.mark.skipif)
  • [ ] DiscreteMapper.get_factor() — exported but never tested
  • [ ] create_encoder() factory — exported but never tested
  • [ ] Edge cases: empty inputs, zero values, overflow at high k

REST API completeness

The API server (api/server.py) only exposes 5 of the engine's core operations:

  • [x] /health, /encode, /audit, /search, /report
  • [ ] /subsumes — DiscreteValidator.subsumes()
  • [ ] /compose — DiscreteValidator.compose()
  • [ ] /gap — DiscreteValidator.explain_gap()
  • [ ] /analogy — DiscreteValidator.analogy_prediction()
  • [ ] /save-index, /load-index — PrimeIndexDB persistence

API hardening

  • [ ] Authentication (API keys or JWT)
  • [ ] Rate limiting per client
  • [ ] Request validation beyond Pydantic (payload size limits, concept deduplication)
  • [ ] Structured logging (replace print statements)
  • [ ] Health check should verify encoder is loaded, not just return 200
  • [ ] OpenAPI schema versioning (/v1/encode)

Containerization

  • [ ] Dockerfile (multi-stage: build + runtime)
  • [ ] docker-compose.yml (API + optional dashboard)
  • [ ] Pre-download all-MiniLM-L6-v2 model in image build (avoid cold-start download)

CI/CD

  • [ ] Add plotly import test to CI (new dashboard dependency)
  • [ ] Add API integration tests (httpx is already in dev deps)
  • [ ] Publish wheel alongside sdist (only .tar.gz in dist/ currently)
  • [ ] Add ruff format --check to CI (currently only ruff check)

Code quality

  • [ ] playground/engine.py — TriadicEngine class defined twice (lines 53 and 132); second overrides first
  • [ ] playground/performance_benchmark.py — calls engine.get_embedding() which does not exist
  • [ ] playground/ is in .gitignore but still tracked; decide: clean up or fully exclude
  • [ ] Add py.typed marker to src/neurosym/ for downstream type checking

Observability

  • [ ] Structured JSON logging across all modules (currently uses logging with no handler config)
  • [ ] Timing metrics for encode/map/search pipeline stages
  • [ ] Error tracking integration (Sentry or equivalent)

Comercial

Cloud API (triadic-cloud)

The engine library is BUSL-1.1 (source-available, not open-source), and a hosted API is the monetization path:

  • [ ] Deploy API behind gateway (e.g., AWS API Gateway, Cloudflare Workers)
  • [ ] Tiered API key system (free/pro/enterprise)
  • [ ] Usage metering and billing integration (Stripe)
  • [ ] Dashboard for API key management and usage stats
  • [ ] SLA documentation (uptime, latency guarantees)

Client SDK (neurosym-client)

  • [ ] Publish Python client that wraps the Cloud API
  • [ ] pip install neurosym-client with TriadicClient(api_key="...")
  • [ ] Thin wrapper: encode, subsumes, compose, gap, search, audit

Documentation

  • [ ] Landing page / docs site (GitHub Pages or similar)
  • [ ] API reference with request/response examples for every endpoint
  • [ ] Integration guides: Python, SQL (PostgreSQL), Prolog (appendix already in paper)
  • [ ] Jupyter notebooks for each use case (RAG, auditing, deduplication, anomaly detection)
  • [ ] CHANGELOG.md — no version history exists

Licensing clarity

  • [ ] FAQ page explaining BUSL-1.1 in plain language for potential customers
  • [ ] Clear boundary: what counts as "competing neurosymbolic validation API"
  • [ ] Commercial license template ready for enterprise deals
  • [ ] Dual license option: BUSL-1.1 (open) + commercial (paid)

Validation

  • [ ] Contrastive projection evaluates on training pairs (paper Section 4.10 notes this); need held-out evaluation
  • [ ] Benchmark on established hypernym datasets (HyperLex, BLESS) for third-party credibility
  • [ ] Case study with real customer data (RAG pipeline or audit workflow)

Bloqueos

Criticos (bloquean produccion)

  1. No auth on API — anyone can call /encode and /audit without credentials. Must add before any public deployment.
  2. No rate limiting — a single client can exhaust server resources. Blocks cloud offering.
  3. Cold-start model download — all-MiniLM-L6-v2 (~80MB) downloads on first use. In containers, this must be baked into the image.

Importantes (bloquean comercializacion)

  1. No client SDK — customers need neurosym-client to integrate without self-hosting.
  2. No billing infrastructure — can't charge for API usage without metering + Stripe.
  3. Test coverage gaps — storage, graph, and reports modules have zero tests. Risky to guarantee correctness to paying customers.
  4. Missing REST endpoints — core operations (subsumes, compose, gap) are only available via Python import, not HTTP.

Limitaciones conocidas (del paper, Section 5)

  1. Hash coincidence != semantic containment — subsumption reflects LSH bucket overlap, not genuine semantic containment. Changing the seed can reverse relationships.
  2. Lossy projection — R^384 -> Z is inherently lossy. "Happy" and "elated" may get identical encodings.
  3. Useful k range is narrow — k=6-12 is the practical regime; no principled selection method exists.
  4. Analogy accuracy is low — 2-10% (paper Experiment 5). The method is for verification, not discovery.

Cobertura

17 repos con ROADMAP.md | 9 repos sin ROADMAP.md

Repos sin ROADMAP.md

  • -Bipolar-Triadic-Neurosymbolic-Framework-
  • arturoornelasb
  • Bipolar-Universal-Semantic-Scale-BUSS-
  • orquestaflow
  • PIXORN-0.1.0
  • Shadow-Engine
  • tibia-bonelord-469-cipher
  • Triadic-Relational-Framework
  • Unified-Holographic-Resonance-Theory-UHRT

Generado automaticamente cada dia por update-inventory.yml.

Para actualizar manualmente: Actions > Update Ecosystem Inventory > Run workflow