Base del servicio
FastAPI ofrece salud, capacidades y estimación teórica. La estimación no ejecuta órdenes ni guarda posiciones.
Ver código observadoINVESTIGACIÓN · PAPER
De la señal
a la evidencia.
Un espacio para seguir el desarrollo de HAIS: qué está planificado, qué espera revisión y qué evidencia tenemos hoy.
ALCANCE ACTUAL01 / PAPER
Simulación primero.
La estrategia de entrada, salida y riesgo está por definir. El proyecto mantiene el límite PAPER.
SIN OPERATIVA REAL01 / PANORAMA
El trabajo, de un vistazo
Snapshot generado al construir la web: .
TAREAS ACTIVAS43en la organización HAIS
PENDIENTES21por iniciar
EN CURSO4trabajo en desarrollo
EN QA / REVISIÓN4esperan validación
ARCHIVADAS1se muestran aparte
Distribución de tareas activas: pendientes · en curso · QA · otros.
Cómo leerlo: son estados declarados en el tablero, no un porcentaje de implementación ni una comprobación automática de que los criterios se hayan cumplido. Los cambios aparecerán tras reconstruir la web. Consultar la fuente en develop >
02 / EVIDENCIA
Código y validación
Observación manual del 1 de noviembre de 2026. No se actualiza automáticamente al cambiar el repositorio.
Contratos PAPER
Modelos y esquemas con pruebas locales, preparados en una rama. Pendientes de PR, revisión, CI e integración.
Ver commit observadoRama de desarrollo
En el momento de la observación contenía únicamente el README inicial. Las ramas pueden haber cambiado.
Ver snapshot observadoLa recepción de señales, la cartera y el backtest figuran como tareas pendientes. Una estimación teórica no demuestra la efectividad financiera de una estrategia.
03 / DEPENDENCIAS
Lo que espera a otras tareas
Relaciones declaradas en el snapshot; no comprueban que exista un bloqueo automático.
Calculando dependencias…
04 / TABLERO
Explora las tareas
Datos de la organización HAIS. Las tareas archivadas se cuentan por separado.
43 tareas activas
#900004Vincular GitHub, Jules y proveedores BYOKOK
Probar configuración BYOK OpenAI/OpenRouter y Jules desde dev.hypenosys.com contra dev.tc.hypenosys.com con claves de prueba y cuotas mínimas; auditar exposición en localStorage, network, logs y errores. No cargar secretos de pago sin vault validado.
Criterios de aceptación
sin claves expuestas en navegador ni logs
permisos mínimos
Proveedor y modelo identificables; llamada de coste mínimo; clave nunca devuelta en API/logs/HTML; revocación y límite de gasto demostrados
Subtareas
- ○ Auditar almacenamiento de claves en navegador, servidor y logs antes de usarlas
- ○ Probar Jules y un proveedor BYOK con credencial efímera de cuota mínima
- ○ Verificar límites de consumo, error 401/429 y revocación
- ○ Redactar evidencia sin exponer tokens ni secretos
#900007Verificar bloqueos y dependenciasOK
Implementar o demostrar scheduler de DAG: blocked_by usa IDs numéricos 900001–900024; bloquear tareas con dependencias Pending/Failed y permitir solo tras Completed validado. Tratar ciclos, duplicados y reintentos.
Criterios de aceptación
no despachar tareas bloqueadas
Tarea dependiente no se despacha antes de gate; casos de ciclos, fallo y retry automatizados; registro de decisiones del scheduler
Subtareas
- ○ Normalizar blocked_by como referencias a ID numérico de tarea
- ○ Bloquear despacho cuando una dependencia está Pending o Failed
- ○ Probar DAG con ciclo, dependencia ausente y completitud tardía
- ○ Registrar decisiones de desbloqueo y evitar doble ejecución
#900008Ejecución Jules de tarea realOK
Desde el Kanban HAIS lanzar una tarea inocua a Jules contra hypenosys/HAIS en rama feature; registrar session_id, branch, commit, coste y resultado sin permitir merge automático ni secretos de producción.
Criterios de aceptación
evidencia de sesión y commit
Session ID real y enlace GitHub; al menos un commit verificable; error visible y recuperable; revisión humana antes de merge
Subtareas
- ○ Seleccionar una tarea inocua PAPER del repositorio HAIS
- ○ Despachar sesión Jules con branch aislada y permisos mínimos
- ○ Registrar session_id, cambios, commit y coste de la ejecución
- ○ Revisar resultado y fallo controlado sin merge automático
#900009Sincronizar PR, CI y estado de tareaOK
Sincronizar sesión Jules, commits, PR y checks GitHub con estado Kanban; reconciliar webhooks/polling, cambios concurrentes y PR cerradas sin merge. No marcar Completed por simple apertura de PR.
Criterios de aceptación
transiciones verificadas sin marcar DONE anticipadamente
Estados Pending/In Progress/In Review/Completed coherentes; reintento idempotente; referencias PR y CI persistidas
Subtareas
- ○ Correlacionar task_id, Jules session_id, branch y PR de GitHub
- ○ Consultar CI y revisión para actualizar el estado del Kanban
- ○ Probar PR cerrada sin merge, timeout y eventos duplicados
- ○ Demostrar que Completed requiere evidencia y no solo una PR abierta
#900010Esqueleto del servicio HAISOK
Auditar y consolidar bootstrap FastAPI de HAIS ya preparado en PR #1; ejecutar health, capabilities y paper/estimate en Docker; documentar configuración local sin pretender motor de trading real.
Criterios de aceptación
FastAPI levanta health check
docker compose up y endpoints comprobados; /v1/capabilities devuelve live_trading_enabled=false; pruebas CI verdes
Subtareas
- ○ Revisar la implementación de la PR #1 del backend HAIS
- ✓ Levantar FastAPI en contenedor y consultar /health
- ✓ Comprobar capabilities y /v1/paper/estimate sin colocación de órdenes
- ○ Documentar ejecución local y defectos encontrados con enlaces a CI
#900011Esquemas tipados de decisionesOK
Definir modelos Pydantic versionados para MarketBar, Signal, Thesis, RiskAssessment, PaperOrder, PaperFill y DecisionTrace; incluir timestamps UTC, source, currency, precision, idempotency_key y validación de instrumentos.
Criterios de aceptación
validación Pydantic y tests
JSON Schema versionado; invalidación de precios negativos, timestamps ambiguos y campos LIVE; unit tests y muestras serializables
Subtareas
- ✓ Definir modelos tipados MarketBar, Signal, Thesis y DecisionTrace
- ✓ Definir RiskAssessment, PaperOrder y PaperFill con UTC y precision decimal
- ✓ Rechazar datos inválidos y órdenes de modo LIVE mediante validación
- ✓ Publicar JSON Schema y pruebas de serialización y compatibilidad
#900012PostgreSQL y migracionesWORKING
Implementar PostgreSQL de simulación para series, estrategias, órdenes PAPER, fills, posiciones y auditoría; migraciones Alembic adelante/atrás y constraints tenant_id/idempotency_key.
Criterios de aceptación
migración reversible probada
Migraciones reproducibles en DB efímera; rollback y backup probados; aislamiento por tenant y unique constraints verificadas
Subtareas
- ○ Diseñar tablas con tenant_id para mercados, estrategias y decisiones
- ○ Crear migraciones Alembic para órdenes, fills y posiciones PAPER
- ○ Añadir índices e idempotency_key únicos por organización
- ○ Probar upgrade/downgrade y aislamiento usando base efímera
#900013Gateway OpenAI y OpenRouter seguroWorking
Crear gateway server-side para OpenAI/OpenRouter con secretos por organización, redacción de logs, timeout, retry con backoff, presupuestos en EUR y medición de tokens; proveedor mock para CI.
Criterios de aceptación
BYOK server-side y presupuestos
tests con proveedor simulado
Sin claves en navegador ni Git; rate limit/budget antes de solicitar; tests timeout/429/revocación y atribución por tenant
Subtareas
- ○ Definir interfaz provider para OpenAI, OpenRouter y mock
- ○ Guardar claves solo server-side con segregación por organización
- ○ Implementar cuotas, timeout, backoff y medición de uso/coste
- ○ Probar 401, 429, secretos revocados y redacción completa de logs
#900014Fixtures financieras mínimas para pruebas reproduciblesPending
Mantener únicamente fixtures SYNTHETIC pequeñas y deterministas para CI, validación y fallos difíciles de reproducir. Reutilizar muestras reales saneadas cuando sean suficientes; no construir un feed sintético como fuente habitual de la aplicación.
Criterios de aceptación
fuente marcada SYNTHETIC y sin órdenes reales
Fixtures con seed estable; timestamps ordenados, sin look-ahead; etiquetado SYNTHETIC visible en API, DB y reportes
- Cada fixture tiene un caso de prueba justificado; se reutilizan muestras y se evita duplicar datasets.
- Una indisponibilidad externa produce estado no disponible, nunca un fallback numérico sintético.
Subtareas
- ○ Generar fixtures OHLCV con semilla fija y timestamps UTC
- ○ Validar precios/volúmenes y ausencia de datos futuros en backtest
- ○ Propagar etiqueta SYNTHETIC hasta API, DB y reportes
- ○ Repetir ejecución y comprobar resultados deterministas sin órdenes LIVE
#900015Configurar CI del repositorio HAISFixed
Endurecer CI de hypenosys/HAIS: pytest, type/lint o checks equivalentes, seguridad de dependencias, build Docker, pruebas de prohibición LIVE y permisos mínimos de GITHUB_TOKEN.
Criterios de aceptación
checks obligatorios y permisos mínimos
Workflow verde en PR; tests negativos de LIVE y build repetible; sin secretos persistidos en artefactos
Subtareas
- ○ Ejecutar pytest y validaciones estáticas en develop/PR
- ○ Construir imagen Docker y comprobar usuario no privilegiado
- ○ Añadir pruebas negativas que prohíban LIVE y broker externo
- ○ Verificar permisos mínimos del workflow y publicar estado CI
#900016Comprobar workflow de creación de PRPending
Probar creación de PR HAIS desde Jules, vínculo con tarea Kanban y feedback de CI, revisión y merge controlado; registrar correctamente PR descartadas y ramas huérfanas.
Criterios de aceptación
PR vinculada a tarea
Tarea/PR/commit correlacionados; tests CI visibles; no hay merge sin autorización humana
Subtareas
- ○ Abrir PR desde branch de tarea con identificador HAIS visible
- ○ Vincular PR a task_id y comprobar checks automáticos
- ○ Simular revisión solicitada y PR descartada o cerrada
- ○ Impedir marcado Completed y merge automático sin revisión
#900017Probar dos ejecuciones independientes en paraleloWorking
Ejecutar dos tareas independientes con Jules usando ramas separadas y máximo dos workers; simular escrituras simultáneas, timeout y reintentos sin duplicados.
Criterios de aceptación
sin conflictos de ficheros ni tareas duplicadas
Dos ejecuciones trazables y separadas; límite de concurrencia respetado; sin pérdida de progreso ni corrupción
Subtareas
- ○ Elegir dos tickets sin dependencias mutuas y ramas distintas
- ○ Lanzar como máximo dos sesiones Jules en paralelo
- ○ Simular colisiones, timeout, retry y reentrega de evento
- ○ Verificar trazabilidad de ambas sin commits perdidos ni duplicados
#900018Eventos auditables e idempotenciaPending
Agregar ledger de eventos para decision_id, run_id, source_version, model/provider, prompts saneados, coste estimado y resultados PAPER; replay idempotente y sin exponer contenido secreto.
Criterios de aceptación
event_id único y replay seguro
Replay no duplica órdenes PAPER; orden causal comprobado; logs exportables sin tokens ni PII innecesaria
Subtareas
- ○ Definir eventos con event_id, run_id, tenant_id y source_version
- ○ Registrar decisiones PAPER y costes con saneamiento de secretos
- ○ Reprocesar eventos para demostrar idempotencia de escritura
- ○ Exportar línea temporal verificable sin datos sensibles
#900019Cognito sandbox smoke testPending
Probar Cognito desde Axlfc/connect-core en sandbox de solo lectura sobre HAIS, con red/FS limitados, timeout, cuota y sin acceso a claves; comparar con Jules usando el mismo ticket.
Criterios de aceptación
sin acceso a secretos ni producción
fallo controlado
Informe comparable de resultados; sandbox aislado; salida controlada si worker falla; cero escrituras productivas
Subtareas
- ○ Preparar sandbox Cognito con repo HAIS sin secretos y solo lectura
- ○ Ejecutar ticket de smoke test con límites de CPU, red y tiempo
- ○ Comparar evidencias y resultados con ejecución Jules equivalente
- ○ Verificar salida controlada y ausencia de escrituras de producción
#900020Diseñar infraestructura y gestión de secretosPending
Diseñar despliegue aislado HAIS: red privada entre servicios, reverse proxy autenticado, variables secretas inyectadas, Postgres persistente, límites CPU/RAM y política de backup. Entornos dev/staging separados.
Criterios de aceptación
sin claves en repositorio ni navegador
Diagrama y threat model revisados; no acceso público sin autenticación; matriz de secretos y permisos con responsables
Subtareas
- ○ Dibujar red entre Hub, tc, HAIS y PostgreSQL privado
- ○ Definir inyección de secretos, rotación, roles y políticas de acceso
- ○ Fijar recursos, backups, observabilidad y separación dev/staging
- ○ Revisar threat model y prohibir endpoints de trading públicos
#900021Desplegar staging con health checksPending
Desplegar staging PAPER con compose/imagen fijada por digest, health/readiness, logs estructurados, red privada y acceso desde tc vía contrato autenticado; test sin órdenes reales.
Criterios de aceptación
acceso privado y health check real
Health real registrado; endpoints no accesibles anónimamente; imágenes y versión reproducibles; alertas mínimas
Subtareas
- ○ Construir imagen HAIS reproducible y ejecutar staging PAPER
- ○ Configurar proxy autenticado y conectividad privada con tc
- ○ Probar health, readiness, errores y logs estructurados
- ○ Verificar denegación de acceso anónimo y ausencia de broker LIVE
#900022Verificar backups y rollbackPending
Ejecutar backup y restauración en entorno de staging, rollback de migración e imagen; medir RPO/RTO y documentar comandos y evidencias sin tocar producción.
Criterios de aceptación
restauración ensayada
Restauración verificada mediante checksums/conteos; rollback ensayado; RPO/RTO anotados
Subtareas
- ○ Crear backup reproducible de PostgreSQL en staging
- ○ Restaurar backup en instalación aislada y comparar checksums
- ○ Ensayar rollback de esquema e imagen ante fallo simulado
- ○ Documentar RPO/RTO observados y pasos de recuperación
#900023Desplegar piloto limitado sin LIVEPending
Solicitar aprobación humana explícita del piloto PAPER con presupuesto objetivo 100 EUR/techo 150 EUR para servicios; verificar límites en proveedores, telemetría de coste y kill switch lógico. NO habilitar LIVE.
Criterios de aceptación
autorización explícita de despliegue
LIVE deshabilitado
Autorización registrada; gasto bajo techo; trading LIVE imposible; runbook de parada e incidentes probado
Subtareas
- ○ Revisar presupuesto aprobado, límites por proveedor y alertas
- ○ Verificar kill switch lógico y ausencia de capacidades LIVE
- ○ Solicitar aprobación explícita humana para habilitar staging PAPER
- ○ Registrar comprobaciones de costes, parada y responsables
#900024Pruebas E2E y dictamen GO/NO-GOPending
Realizar E2E con haopengwang123 y axlfc: login, org, BYOK mínimo, tarea→Jules→PR→CI→Kanban, ejecución HAIS PAPER, audit trail, backup/rollback y prueba negativa cross-tenant. Emitir dictamen GO/NO-GO por evidencia.
Criterios de aceptación
pruebas de permisos, BYOK, tareas, PR y rollback
Matriz de escenarios con URL/capturas/logs saneados; todas las puertas de seguridad pasan o dictamen NO-GO motivado
Subtareas
- ○ Ejecutar login y cambio de organización con Haopeng y Axlfc
- ○ Completar tarea→Jules→PR→CI→Kanban con evidencia trazable
- ○ Ejecutar cálculo PAPER y pruebas negativas BYOK/tenant/rollback
- ○ Emitir informe GO/NO-GO firmado con bloqueos y URLs de evidencia
#900025Definir las reglas de la estrategia de inversión PAPEROK
Concretar con el usuario la compra tras una señal de Investing y la venta después de una subida cuando se agote el impulso o aparezca presión bajista. El README vigente limita HAIS a simulación; cualquier ampliación requiere una decisión y un cambio de alcance explícitos.
Criterios de aceptación
- Quedan registradas la fuente exacta y la forma de recibir señales, los mercados y acciones, la frecuencia de precios y la modalidad automática o con aprobación.
- Se definen con ejemplos de precios las condiciones de compra y venta, cómo medir velocidad y presión bajista, el intervalo y los parámetros ajustables; no se inventan umbrales.
- Se acuerdan capital, tamaño y límites de riesgo, incluidas las pérdidas antes de una subida y el comportamiento ante datos caducados o mercado cerrado.
- Las dudas pendientes y las decisiones aprobadas quedan diferenciadas y el alcance inicial sigue siendo PAPER.
Subtareas
- ○ Confirmar fuente, modo de ejecución y mercados con el usuario
- ○ Definir las reglas de entrada y salida mediante ejemplos
- ○ Acordar capital y límites de riesgo simulados
- ○ Registrar decisiones y dudas pendientes
#900026Investigar la recepción autorizada de señales de InvestingPending
Confirmar si la fuente mencionada es Investing.com y determinar cómo recibir sus señales con un método disponible y autorizado. No asumir que exista una API o que los datos se puedan usar sin restricciones.
Criterios de aceptación
- La fuente, método de recepción, campos, frecuencia, cobertura y retraso quedan identificados y validados con el usuario.
- Se comprueban permisos de uso y disponibilidad; las limitaciones o credenciales necesarias se registran sin guardar valores secretos.
- Se documenta un ejemplo de señal con instrumento, sentido, hora y origen, o el bloqueo concreto si el proveedor no los facilita.
Subtareas
- ○ Confirmar proveedor y canal con el usuario
- ○ Comprobar disponibilidad, permisos y datos de una señal
- ○ Documentar contrato y limitaciones sin secretos
#900027Recibir y validar señales de entradaPending
Implementar una entrada de señales PAPER desacoplada del proveedor confirmado, con un adaptador real solo cuando esté disponible y autorizado. Permitir fixtures identificadas como simuladas durante el desarrollo.
Criterios de aceptación
- Una señal aceptada conserva instrumento, sentido, origen, hora y un identificador reproducible.
- Se rechazan o registran señales duplicadas, incompletas y caducadas según la política acordada, sin iniciar una compra.
- Los tests ejercitan señales válidas y rechazadas; si se usa un fixture se identifica como simulado y no se presenta como integración real.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Definir y validar el contrato de señal
- ○ Gestionar duplicados, antigüedad y errores
- ○ Probar datos válidos e inválidos con fixtures
- ○ Conectar el proveedor confirmado cuando sea posible
#900028Obtener y validar precios para las posiciones PAPERPending
Elegir y conectar una fuente de precios adecuada para las acciones del alcance acordado; puede ser distinta de la fuente de señales. Registrar las limitaciones de retraso y cobertura.
Criterios de aceptación
- Cada observación identifica instrumento, precio, fuente y hora; la cobertura y la latencia de la fuente se documentan.
- Precios ausentes, inválidos, atrasados o fuera de orden se detectan y se tratan según la regla acordada, sin usarlos como datos actuales.
- Las pruebas cubren disponibilidad, huecos y recuperación; los precios de prueba están identificados como sintéticos.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Seleccionar una fuente y comprobar su cobertura y retraso
- ○ Normalizar y validar precios con hora y origen
- ○ Probar precios inválidos y recuperación
#900029Medir velocidad de subida y pérdida de impulsoPending
Calcular sobre series temporales la velocidad de cambio y la pérdida de impulso que alimentarán la regla de salida acordada; los indicadores y sus umbrales quedan sujetos a la definición de estrategia.
Criterios de aceptación
- La fórmula, unidades, intervalo y parámetros configurables están documentados y se basan solo en datos disponibles en ese momento.
- Las pruebas incluyen subida sostenida, subida que se frena, lateralidad, presión bajista y huecos de datos.
- Cada evaluación permite reconstruir precio, periodo, parámetros y resultado sin confundir precios sintéticos con reales.
Subtareas
- ○ Definir las métricas y parámetros con ejemplos
- ○ Calcular el impulso sin usar datos futuros
- ○ Cubrir escenarios de subida, meseta, caída y datos incompletos
#900030Aplicar límites de riesgo y parada en PAPEROK
Proteger el capital simulado con los límites que el usuario acuerde antes de permitir compras. La forma de gestionar posiciones abiertas y posibles pérdidas previas al beneficio queda por decidir.
Criterios de aceptación
- Capital inicial, tamaño máximo de posición, exposición y límites de pérdida son configurables y no se inventan valores aprobados.
- Una compra que rebasa límites o saldo se rechaza con motivo; se prueba también el comportamiento ante datos caducados.
- Una parada manual impide nuevas compras; el tratamiento de posiciones abiertas y salidas de protección sigue la regla aprobada.
- No existe una ruta de órdenes LIVE en este alcance.
Subtareas
- ○ Acordar y documentar límites y salidas de protección
- ○ Validar saldo y límites antes de comprar
- ○ Probar la parada manual y los rechazos
#900031Comprar en simulación ante una señal válidaPending
Implementar la decisión de entrada y una compra exclusivamente PAPER usando el contrato de señales y las reglas aprobadas; el motor debe poder probarse con señales sintéticas antes de conectar un proveedor.
Criterios de aceptación
- Una señal válida del instrumento acordado produce como máximo una compra simulada cuando se cumplen las reglas y límites.
- Se verifican saldo, riesgo, frescura, estado de mercado y cualquier aprobación humana requerida antes de la compra.
- Se registran señal, hora, precio, cantidad y motivo; los reintentos no duplican operaciones y no se envía ninguna orden real.
Subtareas
- ○ Evaluar la señal y los requisitos de entrada
- ○ Ejecutar la compra PAPER con idempotencia
- ○ Registrar la decisión y probar rechazos
#900032Vender en simulación al cumplirse la regla de salidaPending
Seguir cada posición PAPER y decidir la venta tras la subida y el agotamiento del impulso o la presión bajista, según la definición que confirme el usuario. Considerar por separado las salidas de protección acordadas.
Criterios de aceptación
- Se prueba la secuencia subida, pérdida de impulso y presión bajista con el resultado acordado y parámetros configurables.
- También se prueban subida continuada, movimiento lateral, caída antes del beneficio y datos no válidos según las reglas aprobadas.
- Cada posición se cierra como máximo una vez y la venta registra datos y motivo; no se envía ninguna orden real.
Subtareas
- ○ Modelar las condiciones y estados de salida acordados
- ○ Vender la posición PAPER sin duplicados
- ○ Probar escenarios favorables, adversos y datos incompletos
#900033Mantener cartera y resultados de operaciones PAPERPending
Usar las tareas existentes de base de datos y auditoría para conservar saldo, posiciones y operaciones simuladas, incluidos costes y trazabilidad de cada decisión.
Criterios de aceptación
- Se pueden consultar saldo, posiciones abiertas y cerradas, y beneficio o pérdida realizado y no realizado.
- Cada compra o venta conserva señal o motivo, horas de decisión y ejecución, precio, cantidad y costes simulados documentados.
- Tras reiniciar se reconstruye el estado sin duplicar operaciones; las fuentes sintéticas se distinguen en el registro.
Subtareas
- ○ Guardar compras, ventas y posiciones simuladas
- ○ Calcular saldos y resultados con costes
- ○ Probar recuperación e idempotencia
#900034Evaluar la estrategia con reproducción históricaPending
Preparar una evaluación reproducible de la estrategia PAPER con datos y señales históricos disponibles, indicando expresamente cuándo las señales son sintéticas.
Criterios de aceptación
- La evaluación usa solo datos disponibles en cada instante y es reproducible con los mismos datos y parámetros.
- Incluye supuestos de comisiones, diferencial, deslizamiento y latencia; reporta rentabilidad, caída máxima y número de operaciones.
- Distingue los datos usados para ajustar de los usados para evaluar y documenta la cobertura y limitaciones de precios y señales históricas.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Preparar datos y señales históricos o fixtures identificados
- ○ Ejecutar reproducción sin mirar datos futuros
- ○ Reportar resultados, costes y limitaciones
#900035Probar el recorrido completo de compra y venta PAPERPending
Validar de extremo a extremo la estrategia en simulación con una señal y precios controlados; complementar el E2E general del piloto existente sin dar por probada una integración externa simulada.
Criterios de aceptación
- Un caso automatizado recorre señal válida → compra PAPER → subida → pérdida de impulso y presión bajista → venta PAPER conforme a las reglas aprobadas.
- Se prueban señal duplicada o antigua, precios inválidos, límites de riesgo, reintentos y ausencia de doble venta.
- Se comprueban el saldo y la posición final, los motivos y el historial; se identifica si el proveedor usado es real o simulado y no hay órdenes LIVE.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Preparar una señal y serie temporal deterministas
- ○ Verificar compra, seguimiento y venta PAPER
- ○ Cubrir errores, límites y trazabilidad del resultado
#900036Terminal web PAPER con valores sintéticos y cartera localIn Review
Implementar en dev.hypenosys.com/hais/operar/ panel de cotizaciones sintéticas editables, gráficos, efectivo, cartera PAPER, compras/ventas simuladas, validaciones y registro local; mantener claramente separados valores ficticios de telemetría del backend. Integrar el mismo terminal en la portada /hais/ para operar y consultar saldo, posiciones e historial sin cambiar de página; conservar la cartera local existente del mismo origen.
Criterios de aceptación
- La ruta /hais/operar/ entrega el terminal PAPER, /hais/ muestra mercados reales, /hais/estado/ muestra el seguimiento y /hais/demo/ mantiene el prototipo general.
- Los valores etiquetan su fuente sintética; no aparecen cifras como datos de mercado reales.
- Compras, ventas, P/L, parada, persistencia local, exportación y reinicio funcionan, con aceptación explícita por operación.
- No hay peticiones HTTP de compra/venta ni credenciales en cliente; no se anuncia operativa de servidor.
- Test Playwright y build Jekyll ejecutados y verificados en CI antes de cerrar.
- /hais/ integra el terminal PAPER y conserva la misma cartera al recargar o abrir /hais/operar/ desde el mismo navegador; explica que no hay sincronización entre dispositivos ni modelo CFD.
Subtareas
- ○ Completar implementación accesible, responsive y modo local PAPER
- ○ Revisar delimitación de operaciones del navegador frente a backend
- ○ Ejecutar Playwright y build sobre despliegue develop
- ○ Integrar terminal PAPER en /hais/ y verificar persistencia entre portada y terminal
Referencias
#900037API PAPER segura para valores y operaciones persistidasPending
Diseñar e implementar en hypenosys/HAIS, en una fase posterior, endpoints autenticados de cotizaciones, saldo, posiciones, órdenes simuladas, auditoría y parada; publicar vía proxy protegido en /api/hais, con controles de tenant y CSRF. La API v0.1 únicamente estima importes.
Criterios de aceptación
- Todos los endpoints PAPER de escritura requieren autenticación, autorización tenant, CSRF, rate limit e idempotencia.
- Precios/símbolos muestran origen, timestamp y latencia; nunca se confunde SYNTHETIC con LIVE.
- Las compras/ventas PAPER persisten con ledger auditable y tienen límites de riesgo aprobados; trading LIVE es imposible.
- La web cambia a modo backend solo después de contrato probado y consentimiento humano; sin secretos cliente.
- Pruebas negativas cross-tenant, duplicados, desconexión y kill switch.
Subtareas
- ○ Especificar contrato de lectura/cartera y alcance PAPER
- ○ Configurar autenticación proxy y sesión same-origin
- ○ Persistir y auditar órdenes simuladas con protección contra duplicados
- ○ Integrar frontend con backend tras pruebas E2E
#900038Smoke y pruebas E2E de terminal HAIS en developPending
Validar en el dominio de desarrollo las rutas del observatorio real y terminal PAPER separado, el estado, la demo y la seguridad de los límites del simulador; probar sin gateway y con gateway PAPER simulado, y evitar publicar falsos estados de operativa real.
Criterios de aceptación
- Build Jekyll produce /hais/index.html, /hais/operar/index.html, /hais/estado/index.html, /hais/demo/index.html sin rutas duplicadas.
- Playwright valida cotizaciones sintéticas, compra/venta local, parada, persistencia, estimación de backend y cero POST de órdenes.
- Verificación HTTPS y navegación en dev.hypenosys.com documentada con evidencia reproducible.
- No se declara gateway conectada, órdenes del backend ni mercado real sin pruebas externas.
Subtareas
- ○ Ejecutar Jekyll build y Playwright en CI
- ○ Verificar enlaces y rutas en dev.hypenosys.com
- ○ Adjuntar logs/capturas y dictamen de QA
Referencias
#900039HAIS Web: observatorio real S&P/NASDAQ/CSI300/IBEX/bonos/commodities/criptoIn Review
Construir la portada /hais/ con widgets oficialmente embebidos de TradingView para índice/bonos/commodities/cripto y datos numéricos CoinGecko atribuibles; permitir seleccionar símbolo y abrir fichas, sin mocks ni falsa operativa. Cobertura ampliada con ApeCoin (APE), sin simulación de precios.
Criterios de aceptación
- Cotizaciones del observatorio /hais/ sin datos sintéticos; el terminal PAPER embebido se presenta como simulación separada y etiquetada; fallback sin número si falla proveedor; título y ficha de fuente del activo.
- S&P 500, NASDAQ Composite/100, CSI 300, IBEX35, deuda USA/DE/ES/CN, oro/plata/WTI/Brent, BTC/ETH/SOL y FX visibles.
- Mostrar demora, atribución, licencias y limitaciones; no decir tiempo real garantizado.
- Jekyll build y Playwright verificados, navegador desktop/mobile y proveedor externo smoke test antes de Done.
- APE (ApeCoin, `COINBASE:APEUSD`) figura en la selección, watchlist y tabla de criptomonedas sin precios simulados.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Integrar widgets oficiales y tabla CoinGecko sin valores predeterminados
- ○ Ejecutar test local y deploy en develop
- ○ Verificar proveedores/cobertura web real en navegador
#900040HAIS backend: lectura real CoinGecko + FRED de solo lecturaIn Review
API FastAPI GET market/catalog, market/crypto y market/treasury con atribución, validación de actualidad, caché, fallos explícitos y sin endpoints de órdenes. PR #2 CI verde y fusionado a develop; pendiente prueba de proveedor desde infraestructura y staging. Cobertura ampliada con ApeCoin (APE), sin simulación de precios.
Criterios de aceptación
- CI incluye test offline de CoinGecko y FRED con casos inválidos; migración a develop sin activar LIVE.
- CoinGecko BTC/ETH/SOL incluye valor USD, cambio 24h, hora observada y límite de edad; FRED DGS2/DGS10 indica porcentaje de yield y cambio en pb.
- Datos no disponibles producen 503 y no fallback inventado; no hay proxy URL arbitrario.
- Prueba E2E en staging contra fuente real y autenticación antes de cerrar.
- La API y el catálogo incluyen ApeCoin APE (CoinGecko ID apecoin), con timestamp y validación de antigüedad, incluidas las pruebas.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Implementar consumidores upstream de allowlist y validaciones
- ○ Incorporar endpoints y CI en develop
- ○ Verificar conectividad a upstreams desde staging protegido
#900041Contratar y validar feed de índices globales y materias primas para HAISWORKING
Escoger API con derechos adecuados para S&P500, NASDAQ, CSI300, IBEX35, bonos globales, oro, plata y petróleo; distinguir spot, futuros, índices y proxies; negociar frecuencia, cobertura, latencia y redistribución. No scraping ni asumir que los widgets permiten extracción API.
Criterios de aceptación
- Documento por instrumento con ticker exacto, bolsa/fuente, monedas/unidades, frecuencia, zona horaria, horario, retraso y coste/licencia.
- Permiso explícito para ingestión, almacenaje y uso algorítmico; rechazo de feeds no licenciados.
- API server-side con claves en secret manager; tests de cuotas, datos obsoletos y desviaciones.
- No derivar operaciones PAPER de widgets TradingView.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Evaluar proveedores y condiciones de mercado en UE, EEUU y China
- ○ Aprobar cobertura/licencia, plan de coste y BYOK seguro
- ○ Implementar adaptadores y tests de retraso/frescura
#900042Conectar API de mercado HAIS con dev.hypenosys.com por gateway protegidoPending
Configurar y validar proxy autenticado /api/hais desde Cloudflare Pages y staging HAIS. Preferir HAIS API para criptomonedas y yields FRED, con CoinGecko público directo como fallback explícito si no hay gateway; bloquear escrituras a backend PAPER hasta motor validado.
Criterios de aceptación
- Auth, tenant, CORS same-origin y rate limit confirmados en staging; ningún secreto en JS.
- /hais/ muestra origen HAIS / CoinGecko cuando responde API y no oculta caídas.
- GET market/treasury devuelve DGS2/DGS10 con observación de fecha, 503 si no hay upstream; ningún valor fingido.
- Smoke HTTPS de dev con captura/logs saneados y test real de origen.
- Priorizar datos reales de una fuente disponible y autorizada, con origen, hora y retraso visibles. Limitar mocks/fixtures a CI reproducible y escenarios de error; nunca sustituir una caída del proveedor por precios inventados ni presentar una prueba offline como integración real.
Subtareas
- ○ Configurar proxy same-origin y políticas de acceso
- ○ Desplegar imagen HAIS con API de mercado
- ○ Verificar E2E de cripto y rendimientos con upstreams
#900043Monitorizar calidad de datos y progreso del dashboard HAISWorking
Establecer vigilancia de disponibilidad/frescura y discrepancias entre proveedor y gráficos, y mantener tareas del Kanban con evidencia de CI/deploy, bloqueo de fuentes y límites. No marcar completado por código sin verificación.
Criterios de aceptación
- Registrar timestamp del proveedor, último éxito, retraso, estado de mercado y fallos/429 en telemetría sin secretos.
- Alertar sobre datos obsoletos y deshabilitar decisiones automáticas.
- Revisiones periódicas y comentarios de avances de tareas con PR/CI/URLs y aceptación contrastada.
Subtareas
- ○ Registrar SLIs de frescura/cobertura/errores
- ✓ Añadir pruebas de ausencia de mock y degradación
- ○ Revisar incidencias y actualizaciones del tablero HAIS
#900044Definir simulación CFD comparable con la cuenta Plus500Working
Acuerdo del usuario: definir primero el mínimo de datos y reglas para simulación CFD, con ejecución manual en Plus500 y sin conexión de órdenes. La cuenta confirmada es Plus500 CFD. Obtener especificaciones del instrumento concreto antes de calcular margen o costes; no asumir que comprar CFD equivale a poseer acciones. Conservar el alcance exclusivamente PAPER.
Criterios de aceptación
- Identificar instrumento, dirección larga/corta, moneda de cotización y de cuenta, unidades por contrato, mínimo y paso de cantidad, horario y fecha de vigencia de sus especificaciones.
- Registrar bid/ask, origen y timestamp. Entrada larga al ask y salida al bid; entrada corta al bid y cierre al ask. No sumar de nuevo un spread ya incluido en esos precios.
- Definir tamaño y exposición nominal a partir de cantidad y multiplicador; margen inicial y mantenimiento conforme a especificaciones verificadas. No inventar apalancamiento ni reglas de cierre por margen.
- Incluir conversión de divisa, comisiones aplicables y financiación solo cuando proceda según la tarifa y hora verificadas. Valores desconocidos se muestran pendientes, no como cero.
- Distinguir cotizaciones reales del CFD de Plus500 de precios del subyacente procedentes de otra fuente. Si solo existe el subyacente, etiquetar la evaluación como aproximada y explicitar el modelo de spread; no presentar equivalencia de ejecución con Plus500.
- Acordar con el usuario instrumento inicial, capital simulado, tamaño máximo, pérdida máxima y condiciones de entrada/salida antes de habilitar una estrategia automática en simulación. Ningún umbral se considera aprobado por defecto.
- Sin datos vigentes o configuración obligatoria completa, no simular una nueva ejecución como válida. Ante fallo de fuente, mostrar no disponible; fixtures mínimas únicamente para CI y escenarios controlados, etiquetadas SYNTHETIC.
- Definir casos verificables de beneficio/pérdida en largo y corto, spread, cambio de divisa, financiación aplicable, margen insuficiente y datos caducados. No se envían órdenes a Plus500 ni se automatiza su interfaz.
Subtareas
- ○ Confirmar instrumento inicial y recoger especificaciones vigentes de la cuenta CFD
- ○ Confirmar fuente bid/ask disponible y distinguir CFD de precio del subyacente
- ○ Acordar capital, tamaño y límites de riesgo; documentar entradas y salidas
- ○ Definir cálculos de P/L, margen, divisa y costes con casos reproducibles mínimos
#900006Verificar creación y persistencia de tareasOK
Verificar que crear/editar/reabrir tarea HAIS conserva ID numérico, pilot_task_id, subtareas, etiquetas, criterios y dependencias; validar persistencia tras recarga y conflicto de edición SHA 409.
Criterios de aceptación
lectura tras reinicio
Round-trip de datos sin pérdida; escritura a _data/orgs/hais/tasks.json; no fallback a dashboard_tasks.json ni corrupción de otros shards
Subtareas
- ○ Inspeccionar contrato de tasks.json y editor del Kanban HAIS
- ○ Crear y editar tarea conservando ID, criterios, dependencias y subtareas
- ○ Forzar dos escrituras concurrentes y comprobar tratamiento de conflicto 409
- ○ Recargar y comprobar que no hubo escritura en shard ajeno o legacy
#900002Crear workspace HAIS en HypenosysOK
Verificar registro HAIS en _data/organizations.json y _data/orgs/hais/meta.json, membresía, aislamiento del shard y compatibilidad con Kanban; no marcar completado solo porque exista el nombre.
Criterios de aceptación
workspace aislado verificado
Lectura y escritura aisladas en org hais; ninguna tarea de hypenosys/empty-space-videogames aparece; checklist de consistencia isSharded
Subtareas
- ○ Comparar entrada HAIS en organizations.json con meta.json y miembros
- ○ Comprobar isSharded y la ubicación exclusiva de tasks.json
- ○ Crear y releer una tarea de prueba sin contaminar otra organización
- ○ Documentar resultado y corregir inconsistencias del shard
#900001Verificar permisos y autenticar HaopengOK
Comprobar OAuth GitHub de haopengwang123 y axlfc en dev.hypenosys.com; validar MFA, repositorios visibles, revocación de sesión y permisos mínimos sobre hypenosys/HAIS. No asumir que ser miembro del workspace implica acceso al repo privado.
Criterios de aceptación
GitHub MFA activo
acceso limitado comprobado
Sesión real de ambos usuarios registrada sin tokens; prueba de acceso denegado a recurso no autorizado; evidencia de rol y alcance GitHub
Subtareas
- ○ Verificar acceso OAuth de haopengwang123 y axlfc en dev.hypenosys.com
- ○ Comprobar MFA y permisos efectivos sobre el repo privado hypenosys/HAIS
- ○ Probar cierre de sesión, token revocado y acceso no autorizado
- ○ Adjuntar evidencias saneadas de los permisos por usuario
#900003Crear repositorio privado hypenosys/HAISOK
Verificar repo privado hypenosys/HAIS, ramas master/develop, protección de develop, PR #1, checks CI y privilegios reales de los colaboradores.
Criterios de aceptación
repositorio privado y ramas protegidas
PR #1 referenciada; ruleset/branch protection comprobado; ningún colaborador sin autorización puede escribir directamente
Subtareas
- ○ Comprobar privacidad y permisos efectivos de hypenosys/HAIS
- ○ Verificar ramas develop/master y reglas de protección de develop
- ○ Revisar PR #1 y resultados CI sin darla por fusionada
- ○ Registrar enlaces y permisos faltantes sin conceder privilegios globales
#900005Prueba de autenticación y autorización multitenantOKArchivada
Ejecutar pruebas de autorización entre usuarios y organizaciones en Hypenosys y tc; cubrir lectura, escritura, invitaciones y cambios de rol; incluir pruebas de IDOR, fallback legacy y acceso a tareas privadas.
Criterios de aceptación
pruebas negativas de acceso cruzado
Suite con escenarios 401/403 y cross-tenant; pruebas negativas pasan; rutas vulnerables documentadas y bloqueadas
Subtareas
- ○ Mapear endpoints de organizaciones, tareas y sesiones en Hub y tc
- ○ Probar lectura y escritura cruzada entre HAIS y otra organización
- ○ Probar IDOR y falsificación de roles o identificadores de usuario
- ○ Corregir fallos y registrar pruebas 401/403 reproducibles
No hay tareas que coincidan con los filtros.