Roadmap Consolidado — FuaFlow Ecosystem¶

Auto-generado por GitHub Actions. No editar manualmente.

Ultima actualizacion: 2026-03-25

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)

Legal y compliance¶

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")

Legal¶

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 (noreply@fuaflow.com)
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 support@fuaflow.com 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¶

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¶

Cambiar result.get("matches") → result.get("results") en find_similar.
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.
Cambiar enc.get("prime") → enc.get("results", [{}])[0].get("prime_factor") en flag_predictor.
Cambiar x.get("name") → x.get("namespace") en user_info.
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¶

Tests para /candidates/index y /candidates/similar con mocks — ahora cubiertos en test_triadic_contract.py.
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¶

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¶

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.

Legal¶

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

Legal & Compliance¶

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).

Legal¶

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).

Legal y compliance¶

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 (support@fuaflow.com 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¶

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.

Legal¶

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¶

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@, legal@fuaflow.com 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:

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.
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.
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 support@fuaflow.com") pero no es la experiencia deseada.
Sin screenshots de producto — 9 placeholders entre el hub y /log/. Un sitio comercial sin imágenes del producto no convierte.
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)¶

34 capitulos completos, compilables con XeLaTeX
Revision por Gemini (promedio 9.7/10)
5 rondas de debate multi-agente (consenso 9.3/10)
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)¶

51 primitivos, 9 categorias, 8 operaciones, 9 reglas
49 edge cases testeados (24.5% bien, 40.8% parcial, 34.7% pobre)
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¶

Representacion dual: 63 bits + producto de primos
3 estados: [+] activo, [0] ausencia experimentada, [null] N/A
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¶

v1: 500 conceptos, v2: 900, v3: 2,050
5,000 pares en inventario (724 con factorizacion profunda)
50 palabras aleatorias fuera del dataset: todas derivables
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¶

Python puro para validacion (sin deps externas)
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:

Validacion humana (dataset/validacion_humana/protocolo_validacion.md): 3 niveles (concordancia, coherencia, reconstruccion), minimo 5 participantes. Sin sujetos reclutados.
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
Configurar key.properties en android/ (gitignored) — template key.properties.example creado con instrucciones. build.gradle.kts lee automáticamente de key.properties cuando existe
Actualizar android/app/build.gradle.kts — signing config de producción implementado. Lee key.properties si existe, fallback a debug signing si no
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
Habilitar R8/ProGuard — CI build ahora usa --obfuscate --split-debug-info=build/symbols en lugar de --no-shrink

CI/CD¶

Firmar APK en CI — CI workflow actualizado con steps para decodificar keystore y crear key.properties. Solo falta agregar secrets en GitHub repo settings
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
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%
Crear CHANGELOG.md — creado con historial completo de v1.0.0+1

Código Pendiente¶

Testing¶

Performance¶

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

Seguridad¶

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

Legal¶

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 (pip install reptimeline — v0.1.0 publicado 2026-03-24)
GitHub Actions: tests (Python 3.10-3.13), ruff lint, coverage en cada PR
Pre-commit hooks (.pre-commit-config.yaml con ruff check + ruff-format)
Coverage reporting (pytest-cov configurado en pyproject.toml + coverage XML en CI)
Badges en README: CI status, Python versions, license

Calidad de código¶

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

Documentación¶

Generar sitio de docs con pdoc + GitHub Pages workflow automático
Docstrings de API reference para todos los parámetros de thresholds en BitDiscovery
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)
Export a CSV y JSON round-trip (Timeline.to_csv(), save_json/load_json, from_dict)
Export a Parquet, WandB, TensorBoard
Serialización robusta: schema_version: "0.1" en ConceptSnapshot y Timeline JSON
Paralelización de discovery triádica (actualmente single-thread, O(K³))
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¶

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

Comercial¶

Licencia y legal¶

Auditoría de dependencias: todas las dependencias son comercialmente compatibles (BSD, MIT, Apache-2.0, MPL-2.0)
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)
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¶

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

Bloqueos¶

Críticos (bloquean producción)¶

~~No está en PyPI.~~ — Resuelto: v0.1.0 publicado en PyPI el 2026-03-24.
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)¶

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.
Sentinel features sin resolver. 8/16 features SAE mostraron zero cross-activation. No se puede distinguir entre selectividad perfecta y artefacto de sparsity.
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¶

Crear tests/ con pytest: health, encode, search, auth, rate limits, tier gating, usage, webhooks, batch jobs, register, anomaly scan
Agregar conftest.py con fixtures (temp DB por test, httpx.AsyncClient via ASGITransport)
98 tests pasando — CI ya los ejecuta en cada push/PR
pytest.ini con asyncio_mode = auto
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¶

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

Seguridad DONE¶

Generar par RSA para licencias on-premise (deploy/license_private.pem + deploy/license_public.pem)
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¶

docs/MONETIZATION.md — rutas corregidas a auth/keys.py, auth/billing.py, etc.
docs/WEB_DEPLOYMENT_TODO.md — 24 items marcados como completados
CONTRIBUTING.md creado con guía de dev setup
landing/terms.html y landing/privacy.html creados

Code quality DONE¶

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)

Legal DONE¶

Terms of Service — landing/terms.html (10 secciones, dark theme)
Privacy Policy — landing/privacy.html (datos almacenados vs NO almacenados, retención, derechos)
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)¶

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)¶

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.
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:

/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)¶

No auth on API — anyone can call /encode and /audit without credentials. Must add before any public deployment.
No rate limiting — a single client can exhaust server resources. Blocks cloud offering.
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)¶

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

Limitaciones conocidas (del paper, Section 5)¶

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

Cobertura¶

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

Repos sin ROADMAP.md¶

-Bipolar-Triadic-Neurosymbolic-Framework-
arturoornelasb
Bipolar-Universal-Semantic-Scale-BUSS-
kryptos-k4
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

Roadmap Consolidado — FuaFlow Ecosystem¶

bip-project¶

Tecnico¶

P0 - Bloquean el lanzamiento¶

P1 - Necesarios antes de usuarios reales¶

P2 - Calidad para escalar¶

Comercial¶

Identidad y posicionamiento¶

Legal y compliance¶

Go-to-market¶

Bloqueos¶

Orden sugerido¶

EXR¶

Tecnico¶

Empaquetado e instalacion¶

Cobertura de tests¶

Rendimiento y escalabilidad¶

Robustez¶

Deuda tecnica¶

Seguridad¶

Comercial¶

Distribucion¶

Servidor de licencias¶

Producto¶

Legal¶

Bloqueos¶

EXR-privado¶

Bloqueos¶

Iconos y branding¶

Versión unificada¶

Secrets en producción¶

Code signing¶

Documentos legales¶

Técnico¶

Seguridad del licensing server¶

Base de datos¶

Dependencias faltantes¶

Tests faltantes¶

CI/CD¶

Builds multiplataforma¶

Calidad de código¶

Monitoreo¶

Comercial¶

Pagos (LemonSqueezy)¶

Email de licencias¶

Website¶

Distribución¶

Mobile¶

Soporte¶

Prioridades sugeridas¶

fuaflow-ai-backend¶

Arquitectura desplegada¶

Bloqueos¶

~~Contrato API roto~~ RESUELTO¶

CI/CD parcialmente roto¶

Errores de runtime¶

Seguridad¶

Código muerto¶

Técnico¶

~~Arreglar contrato API~~ COMPLETADO¶

Validación de datos¶

Bugs lógicos¶

Performance¶

Seguridad¶

Testing¶

CI/CD¶

Arquitectura¶

Comercial¶

Integración con apps (funciona parcialmente)¶

Documentación¶

Pricing y límites¶

Onboarding¶

Operaciones¶

Legal¶

Roadmap del ecosistema (contexto)¶

fuaflow-CRM¶

Técnico¶

Release & Distribución¶

Base de Datos & Datos¶

Calidad de Código¶

Contrato API roto RESUELTO¶

Arreglar contrato API COMPLETADO¶