tickets

QUETZAL Phase 1 (tourism-providers #76, mergeado en tick 130) cerró la oferta. Falta la demanda — el otro lado del match oferta↔demanda que define la misión. WebSearch confirma gap crítico y urgente: a ~6 semanas del Mundial 2026, búsquedas de hospedaje explotan (CDMX +1,642%, GDL +2,191%, MTY +118,600% desde Asia, src dondeir.com/abasturhub) pero hotel bookings on-the-books están solo en 20-40% (src costar.com/hotelmanagement.net) y precios ya subieron 173-333% YoY (src mexicobusiness.news). Patrón histórico: 6-10 semanas pre-evento es cuando se confirma volumen significativo — la ventana de captura está abriendo AHORA. 5.5M turistas esperados (ESPN), oferta atomizada sin intake organizado. Una agencia-travel sin RFQ formal pierde leads que ya están google-buscando. QUETZAL como agency-travel canónica del proyecto necesita un funnel de demanda multi-tenant (otras agencias-travel del archetype también lo aprovechan post-Mundial: bodas, retiros, MICE, ecoturismo). Filtro Tot 3/3: (1) urgente — ventana 6-10 sem; (2) replicable — multi-tenant agency-travel beyond QUETZAL; (3) propio — no existe en Thoth. Override de rotación archetype (agency-travel=4 vs personal-brand/platform/educational=0) justificado por: mission directive QUETZAL hasta julio 2026 + urgencia temporal Mundial + archetype_fit_score=10 evidenciado por gaps documentados. NO duplica módulo 'bookings' (#71) — ese es appointments 1:1 para coaches/personal-brand; este es RFQ multi-fecha/multi-servicio para travel packages. Es la pieza que conecta turistas reales con el provider registry recién desplegado.

Bug observado en ticket #75 (2026-04-28 04:16 UTC): el planner Opus clasificó 'fix PydanticUserError en apps/observability/log.py:249' como category=improve. Pero 'improve' opera sobre el kernel nabu (sandbox monta /work=nabu repo), no sobre mcp_django. Para tocar mcp_django el ticket debe ser build_thoth_module (sandbox monta /work_django). Resultado: el sandbox de #75 escribió BLOCKED.md auto-diagnóstico explicando que /work/apps no existe. Tiempo perdido: ~5 min Sonnet + ciclo planner. Si pasa varias veces consecutivas, el consecutive_tick_failures kill puede dispararse. Adicional: en este caso el ticket #75 era basado en información incorrecta (Nabu pensó que el anti-pattern seguía vivo cuando Claude transplantes ya lo había limpiado en commit af7af26). Pero el bug del classifier es independiente y sigue existiendo: si en futuro Nabu detecta otro bug runtime en staging mcp_django y lo clasifica como 'improve', volverá a fallar igual. Fix sugerido: en system prompt del planner Opus, agregar regla explícita: 'Si el work requiere editar archivos en apps/<x>/ de mcp_django o Orion-Dashboard, category DEBE ser build_thoth_module. improve es SOLO para cambios al kernel nabu mismo (kernel/, sandbox/, guardrails.yml, mission.md).' Alternativa: heurística automática en create_ticket_from_plan que rechace category=improve si el rationale menciona paths típicos de Thoth.

Post-merge #66 (quetzal_core foundation), QUETZAL necesita el lado OFERTA del match Mundial 2026 — sin proveedores registrados no hay match posible y la Phase 0 queda inerte. tourism-providers permite registrar hoteles/restaurantes/transportes/tours/gov-backed (Tren Maya, Pueblos Mágicos Sectur, ANP CONANP) con certificaciones MX (distintivo M, distintivo H), capacidad, rangos de precio, idiomas, y proximidad a sedes oficiales (CDMX/GDL/MTY) o nodos Tren Maya. Multi-tenant via FK a Organization (R03) → reutilizable por cualquier archetype agency-travel, no exclusivo de QUETZAL pese a originarse del proyecto activo (mission §QUETZAL). Pre-Mundial 2026 es ventana SEO crítica: proveedores que no se registren temprano pierden visibilidad orgánica. Emite eventos provider_registered/service_published a quetzal_core via apps/business_intelligence/ SIN tocar schema BI (R02). Cierra el gap más urgente del catálogo expansible descrito en mission (hospedaje/gastronomía/movilidad/cultural/gov-backed). Stakeholders directos beneficiados: proveedores locales MX (visibilidad), Sectur federal + secretarías estatales (alineación gov-backed first), CONCANACO/Coparmex (cámaras pueden agregar afiliados), agencias agency-travel terceras (módulo disponible cross-tenant). archetype_fit_score=9 agency-travel; mission override sobre rotación archetype porque QUETZAL es prioridad estratégica explícita hasta julio 2026.

Tick 128 reflexionó: ticket #74 fue bloqueado por harness (faltó bow-tie + categoría incorrecta build_thoth_module). El builder identificó la causa raíz en su análisis: log.py:249 levanta PydanticUserError porque `from __future__ import annotations` convierte todos los type hints en strings, lo que impide a Pydantic resolver forward refs en runtime. NO requiere módulo nuevo — requiere quitar el import de las 9 apps que lo tienen y dejarlo SOLO si no lo necesitan (validar que ningún hint dependa de PEP 563). Re-emito el fix como `improve` (correcto categóricamente, scope S, sin tocar foundational/BI). Esto desbloquea log.py y es prerequisito para que cualquier tick futuro corra observabilidad sin error en startup.

Error detectado automáticamente desde logs. **Logger:** django.request **Mensaje:** Internal Server Error: /api/v1/admin/my-permissions **Archivo:** /app/.venv/lib/python3.12/site-packages/django/utils/log.py:249 **Función:** log_message **Org:** thotintelligence

Decisión Samuel + Tony 2026-04-28: QUETZAL como ente vivo Mundial 2026 (ver mission.md sección PROYECTO ACTIVO). Propósito core: match oferta↔demanda turística MX. Este ticket construye el cimiento del 'ente vivo': StakeholderGraph + OpportunityScanner que detecta gaps emergentes en tiempo real y los flagea para acción. Esta es la 2da pieza foundational de QUETZAL (la 1ra fue apps/quetzal_core/ con Tourist/Trip/Experience/LocalBusiness/MovementEvent ya en staging via PR #34). Esta segunda pieza extiende el universo a stakeholders no-tourist (gobierno, cámaras, patrocinadores, embajadas, plataformas, medios, finanzas, salud, etc.). ALCANCE: 1. apps/quetzal_stakeholders/ Module Anatomy 14-file completo. Multi-tenant org_id=quetzal por default pero queryable cross-org si admin lo permite (será relevante post-Mundial cuando QUETZAL sirva data agregada a otros orgs). 2. Modelo StakeholderNode (org_id FK Organization + tipo enum: provider, government, chamber, transport_op, airport, platform_competitor, embassy, fifa_sponsor, media, payment, health, tech_local, association, other; name, official_name, contact JSONB con channels disponibles, sede_relevance JSONB lista sedes Mundial donde aplica, scope enum local/regional/national/international, reliability_score 0-100, last_contact_at). 3. Modelo RelationshipEdge (from_node FK, to_node FK, type enum: supplies/funds/regulates/competes/partners/promotes/transports/insures, strength_score 0-100, established_at, notes). 4. Modelo OpportunityGap (org_id, detected_at, sede string, gap_type enum: oversupply/undersupply/regulatory/timing/event_paralelo/quality/access, description text, affected_stakeholders M2M StakeholderNode, evidence_signals JSONB lista de signal IDs que la evidencian, urgency_score 0-100, transcendence_score 0-100, status enum: detected/researching/actionable/in_progress/resolved/expired, recommended_action text, action_ticket_id Optional FK Ticket — si Nabu generó ticket para cerrarlo). 5. Endpoints RE

Rotación obligatoria a educational-institution (coverage=0, gap máximo tras demo=10 y agency-marketing=5; archetype_fit_score=9 para newland). Pain validado vía WebSearch: academias de idiomas/tutoring/colegios pequeños en MX hoy combinan Wix-form + Excel + transferencia + factura manual SAT, o pagan tools globales caras (Classe365, TutorCruncher) sin integración de facturación local. Thoth ya tiene clients + invoices + bookings + quetzal_core (60% del stack educativo); el gap real es la puerta de entrada: catálogo público de cursos con landing SEO-friendly por curso + form de inscripción que crea Student-as-Client append-only y dispara plan de pagos (1-12 mensualidades) en invoices. Module multi-tenant: cualquier org puede activarlo (academias, bootcamps, instructores con cohorts). Cierra el ciclo discovery→inscripción→cobranza recurrente que ningún módulo previo cubre.

Rotación obligada por archetype_coverage: personal-brand=0 vs demo=10/agency-marketing=5/agency-travel=3. Pain validado: SavvyCal ($458K MRR) y Calendly demuestran que scheduling 1:1 es vertical viable, pero ninguna competidor está integrado dentro de un OS multi-tenant tipo Thoth. samuelplata (personal-brand canónico: coaches, course creators, consultores 1:1) opera con DM + Calendly + invoice manual, gap claro. Conecta gaps existentes: deals→bookings cierra discovery calls; bookings→quotes genera deposit; bookings→time-tracking auto-log de sesión; bookings→clients auto-link. archetype_fit_score=9 para personal-brand, 8 para service-pro. Multi-tenant: cualquier org Thoth con personal-brand o service-pro puede activar. Cumple §4.1: módulo nuevo aislado, append-only a clients/quotes/time-tracking, no toca BI schema, no foundational paths, additive only.

Rotación de archetype: service-pro (cardia) tiene 0 tickets vs agency-marketing 5 / demo 10 — toca rotar. Signal directo: '[freelancer] capital_flujo_caja' score 7.75 cita woodworker/services 'no puede estimar tiempos de trabajo correctamente, perdiendo margen y dinero', y '[PyME] otros' score 7.77 menciona 'propuestas desincronizadas causan pérdida de ingresos'. Validación externa: estudios 2026 muestran 35% overrun promedio en professional services, 32% por scope changes no anticipados; smart time tracking reduce overruns 43%. Gap arquitectónico: el ticket #64 (clients) ya refirió 'timeline leads/quotes/projects/invoices/expenses' pero NO existe módulo projects — es la pieza faltante que une deals→entrega→facturación. time-tracking (#68) acaba de mergearse y necesita un destino tipado mejor que invoice line directa para attribution real de horas a proyectos. Job costing es core de service-pro: contractor, consultor, despacho, freelancer servicios. archetype_fit_score=9 para service-pro. Módulo multi-tenant disponible para cualquier org.

Rotación de archetype: agency-marketing tiene 4 tickets y agency-travel 3, mientras personal-brand/consumer-brand/educational-institution/service-pro siguen en 0. Targeteo personal-brand (org ejemplo: samuelplata) porque es donde más signals convergen: top signal 'adquisicion_sin_conversion' SaaS score 8.0 con 3 evidencias (r/SaaS '2 años 0 MRR', '50k views Reddit pero casi sin usuarios', 'launching OnPilot solving my own'), 'PyME otros' score 7.77 con 'terminé editando los reels yo mismo a las 2 de la mañana' (delegar contenido), y 'cobro_tardio_impago freelancer' que en su raíz es un funnel roto. Lead magnets convierten 30-50% (interactivos) vs 3-10% (estáticos) según research 2026. Thoth ya tiene leads/clients/deals/quotes/time-tracking/expenses/projects pero NO tiene la capa upstream de captura de audiencia — el funnel arranca en lead pero a leads no llega tráfico. Este módulo cierra ese gap upstream con append-only signal a apps/leads/ (no muta su schema). NO sobrelapa con tools existentes (Mailchimp/ConvertKit cobran $30+/mes per audience size) porque queda como módulo nativo del stack multi-tenant Thoth, integrado al pipeline ya construido. archetype_fit_score=9 personal-brand.

Archetype service-pro (cardia) tiene 0 tickets vs agency-marketing=4 / agency-travel=3 / demo=9; la regla de rotación obliga priorizar archetypes sub-cubiertos. Signals freelancer cobro_tardio_impago=8.5, flujo_caja=7.75 ('20+ hrs/mes en propuestas sin ganar dinero', 'no logra estimar tiempos, pierde margen'), y research externo confirma que freelancers pierden 15-40% de horas billables ($23k/año @ $100/hr) y 36% del tiempo se va en admin (PainOnSocial/Rize 2026). Thoth ya tiene leads→deals→quotes→projects→invoices→expenses, pero falta el eslabón crítico que convierte trabajo ejecutado en cobro: el tracking de horas sobre projects que alimenta automáticamente invoice line items. Sin ese módulo, el loop billable→cobro queda abierto y los archetypes service-pro/freelance no pueden facturar con precisión. archetype_fit_score=9.

Signal 'adquisicion_sin_conversion' (avg 8.0, count=3) + evidencia explícita en PyME otros: 'equipos B2B gastan $350-500/mes en 5+ herramientas desintegradas para prospección y gestión de pipelines' y 'I've used 5 CRMs in 3 years'. Thoth ya tiene leads, clients y quotes pero falta el eslabón visual de pipeline con stages, probabilidad y forecasting que conecta captura→cierre. Construir como módulo Thoth duplica cero infraestructura (multi-tenant, auth, BI events ya existen) y consolida 5 herramientas CRM fragmentadas en un solo flujo. Categoría build_thoth_module por archetype_fit alto: el módulo se enchufa append-only a apps existentes (leads.qualify → deals.create automático, deals.won → quotes.create) sin tocar paths foundational ni schema BI.

Samuel Plata 2026-04-27 — propuesta QUETZAL MX para CONCANACO/Mundial 2026. QUETZAL es la capa de inteligencia turística que se monta SOBRE la plataforma actual de viajes (theadventure/Calaita) — no la reemplaza, la potencia. Concepto: 'Entender en tiempo real cómo se mueve el turismo, qué necesita, qué consume, dónde se concentra y cómo conectar esa demanda con el comercio local mexicano.' Sistema completo tiene 7 módulos + 4 vistas de dashboard distribuidas en 8 fases (Q-0 a Q-8). Esta es la FOUNDATION (Q-0) — bloqueante para todas las siguientes. ALCANCE Q-0 (NO MÁS): 1. apps/quetzal_core/ Module Anatomy 14-archivos completo (THOTH_CONVENTIONS §2) 2. Modelos base (todos multi-tenant FK Organization, R03): - Tourist (visitor profile: nationality, language, age_range, party_size, interests JSONB, arrival_at, departure_at) - Trip (linked Tourist + agency Organization, status, total_value_usd, party_size, itinerary JSONB) - Experience (catálogo de experiencias: name, type enum, location_lat/lng, price_usd_range, duration_min, capacity, rating, supplier_business_fk nullable) - LocalBusiness (registro de comercio local: name, business_type, location, contact JSONB, segments_served JSONB, certifications JSONB) - MovementEvent (event log agregado privacy-respecting: tourist_segment_hash NOT tourist_id directo, from_location, to_location, transport_mode, captured_at, weight) 3. Endpoints REST (django-ninja, multi-tenant): - POST /api/v1/quetzal/track (track tourist events anónimo: visit, view, search, reservation_started, reservation_completed) - GET /api/v1/quetzal/experiences (search filtrable por location, type, price) - GET /api/v1/quetzal/businesses (catálogo comercio local filtrable) - GET /api/v1/quetzal/tourists/{id} (tourist profile + trip history para org) 4. signals.py: post_save de Trip dispara MovementEvent automático (origen → destino del itinerary) 5. bi_events.py: tourist_arrived, trip_created, experience_viewed, reservation_sta

Signal freelancer 'capital_flujo_caja' score 8.5 (Reddit r/Entrepreneur 1sv1uvb) y signal PyME 'cobro_tardio' 7.83 (r/freelance 1sci8yg) confirman que freelancers/agencias pierden horas trabajadas sin convertirlas en facturación, principal causa de flujo de caja deficiente. La cadena Thoth servicios-profesionales (leads→quotes→projects→invoicing→expenses→clients) tiene un gap crítico entre projects (ejecución) e invoicing (cobro): no existe módulo que capture tiempo trabajado por proyecto y lo transforme en line items facturables. Time-tracking cierra el ciclo monetario. Archetype-fit servicios profesionales = 10. Append-only wire-in: FKs nullable a Project/Invoice/User, sin AlterField a schemas existentes (R02/R05 ✓). Emite BI events sin tocar schema BI (R02 ✓). Sin paths §3.1/3.3. Default human-review (R07). Tot 3/3: dolor real validado, fit servicios pro, append-only.

Tras 5 módulos del workflow servicios (leads→quotes→projects→invoicing→expenses), cada uno representa al cliente de forma local sin record central. Top signals confirman el dolor: 'Pierden leads porque información está dispersa en WhatsApp, llamadas y notas sin sistema centralizado' (PyME, 7.83) y 'Falta visión centralizada de leads, cotizaciones, proyectos e invoices al crecer' (PyME, 7.83). Un módulo clients append-only con FK opcional desde Lead/Quote/Project/Invoice/Expense cierra el loop CRM y desbloquea reportes por cliente (LTV, AR aging, márgenes por cliente). Archetype fit alto para servicios profesionales LATAM. Signals_gate ya cumplido (≥3 entries con score≥5), no más research necesaria.

Con el funnel sales→quotes→projects→invoicing completo (tickets #59-62 merged), falta el lado de cuentas por pagar para dar visibilidad financiera total. Signal [PyME] compliance_burocracia (avg 7.75) con 'desorden en documentación y contabilidad genera ansiedad y caos en temporada de impuestos' y signal 'negocios estacionales no tienen flujo de caja uniforme' (avg 7.72) validan dolor real. Un módulo expenses integrado con invoicing cierra el loop financiero (P&L básico = revenue - costs), es prerequisito para futuras features de cashflow forecasting/reportes fiscales, y aumenta defensibilidad de Thoth frente a usar Holded/QuickBooks por separado. Archetype-fit alto: servicios profesionales necesitan rastrear gastos por proyecto/cliente para cobrar con margen correcto. No requiere outreach manual ni credenciales externas — pura construcción de módulo Django+Orion.

Acabamos de cerrar sales→quotes→invoicing pero queda un hueco operacional crítico entre 'quote aceptado' e 'invoice emitido': la ejecución del trabajo. Para servicios profesionales este vacío es donde se pierden ingresos por propuestas desincronizadas (signal PyME 7.72: 'cotizaciones incorrectas') y por esperas de aprobación que retrasan cobros (signal PyME 7.83: 'espera por aprobaciones bloquea proyectos'). Mercado valida el patrón: Scoro/Plutio/Fieldy todos construyen este puente como diferenciador ('manual entry quote→invoice = major operational failure 2026'). Falta la versión LATAM/MX económica. archetype_fit=9 (servicios profesionales). Module se inserta append-only entre quotes e invoicing existentes vía FK, sin alterar schemas.

Cierre natural del funnel ya construido (sales -> quotes -> ?). Signal [PyME] Cobro tardío e impago (avg 7.83, 3 evidencias) + cita literal 'Falta visión centralizada de leads, cotizaciones, proyectos e invoices al crecer' + 'Holded es insostenible' validan dolor recurrente y costo de competidores. Quotes v0.1 acaba de mergearse (ticket #60), por lo que existe un Quote.accepted listo para convertir en Invoice — sin esto, el funnel se corta antes del cobro y la propuesta de valor 'tu ciclo lead->ingreso en un sistema' queda incompleta. Archetype-fit alto para servicios profesionales/freelancers/PyMEs: cobran tarde porque carecen de visibilidad de cuentas por cobrar. Reusa Organization, Lead y Quote vía FK; emite eventos BI append-only (invoice_issued, invoice_paid, invoice_overdue) sin tocar schema BI. Sin SDK externo (R04), sin CFDI/SAT en v0.1 — eso queda para v0.2. Diferencial sobre Holded/QuickBooks: integración nativa con quote aceptado en 1 click, sin re-tipear line items.

Tres señales de alto score (8.5 freelancer capital_flujo_caja: '20+ hrs mensuales en propuestas sin cobrar', 7.83 PyME: 'falta visión centralizada de leads, cotizaciones, proyectos e invoices', 7.83 PyME adquisicion: 'pierden leads por falta de follow-up') convergen en una sola capacidad: cotizar rápido desde el contexto del lead. El módulo sales ya tiene pipeline kanban (v0.3) + log de llamadas/WhatsApp (v0.4); el cuello de botella siguiente es el documento que cierra el ciclo lead→ingreso. Mercado MX/LATAM menos saturado que Upwork-style proposal AI: competidores (Qwilr, Bitrix24, Osmos Cloud) son genéricos y caros; oportunidad concreta es cotizaciones desde Thoth con datos del lead ya capturado, sin doble captura. Build_thoth_module porque reusa auth, multi-tenant, archetypes y emite a BI; standalone duplicaría infra. Nuevo módulo en lugar de extender 'sales' para mantener anatomy 14 archivos limpia y permitir uso fuera de pipelines (freelancers solos pueden cotizar sin lead).

Top signal PyME score 7.83 (n=3 evidencias Reddit) reporta: 'leads se pierden porque info está dispersa en WhatsApp, llamadas y notas sin sistema centralizado'. Mercado saturado en CRM+WhatsApp API ($14-79 USD/mes), pero R04 bloquea SDKs (Twilio/Meta), creando gap natural: log MANUAL de interacciones dentro del módulo sales ya merged en v0.3 (#55). Cero infraestructura nueva — solo extender Profile model con CallLog/MessageNote ligados a Lead via FK. Direccionable en 1 sesión, complementa kanban+scoring existente, y los últimos 3 tickets se bloquearon por bow-tie ausente: este ticket fuerza explícitamente su generación en acceptance criteria.

Samuel Plata 2026-04-27 — culminación post-humana. ASUME apps/economic_graph/ + apps/business_organism/ existen (Phase 1). Si no, BLOCKED.md. ALCANCE FASE 2: 1) Opportunity Genesis Engine: apps/opportunity_genesis/ con worker autónomo que escanea EconomicConsciousnessGraph cada N horas (configurable), detecta configuraciones latentes de valor (asimetrías: dolor alto + disposición pago alta + oferta fragmentada + automation potential). Endpoint POST /api/v1/internal/nabu/opportunities/generate body {org_id, scope?: {city?, category?, max_ideas?}, optimization_target: highest_margin|fastest_breakeven|highest_unicorn_potential|highest_transcendence|lowest_execution_risk|best_for_local_impact}. Output: lista de GeneratedOpportunity con thesis + required_suppliers + estimated_economics + scores. 2) Transcendence Scoring: extender business_organism con transcendence_score campo + key_drivers_transcendence JSONB con 9 dims (valueCreation, ecosystemLeverage, autonomyPotential, compoundingData, humanExperienceLift, localEconomicImpact, defensibility, scalability, marginPower 0-100 cada). Función calculate_transcendence_score con weights canónicos de Samuel ({valueCreation: 0.13, ecosystemLeverage: 0.13, autonomyPotential: 0.12, compoundingData: 0.13, humanExperienceLift: 0.10, localEconomicImpact: 0.09, defensibility: 0.12, scalability: 0.10, marginPower: 0.08}). classify_transcendence: >=90 economic_singularity_candidate, >=80 autonomous_business_ecosystem, >=70 venture_scale_organism, >=55 high_value_business_composition, else ordinary_commercial_package. NO ejecutar OrionProvider en Genesis Engine cada minuto — rate-limit a 1 ejecución cada 6h máximo + caching de oportunidades. Bow-tie: rollback feature flag GENESIS_ENGINE_ENABLED — apaga el worker y mantiene endpoints read-only.

Samuel Plata 2026-04-27 — sigue del módulo expo_capture de Phase 0. ASUME que existe apps/expo_capture/models/supplier_capability.py con modelo SupplierCapability(org_id, raw_extract JSONB con shape EconomicCapabilityExtract). Si no existe ese módulo, escribe BLOCKED.md indicando dependencia. ALCANCE FASE 1 (3 piezas que conforman la 'Economic Consciousness'): 1) Economic Consciousness Graph: módulo apps/economic_graph/ con modelos EconomicNode (polymorphic: SupplierNode, DestinationNode, CustomerArchetypeNode, ExperienceNode, AssetNode, ConstraintNode, OpportunityNode, BusinessModelNode, DemandSignalNode, CulturalSignalNode, RiskNode, MarginNode) + EconomicEdge (relations between nodes con type, weight, confidence). Materialized views por org_id agrupando por city/category. 2) BusinessAtom model: composable units {id, type (lodging/transport/experience/food/insurance/guide/payment/concierge/content/distribution), supplier_fk, value_function, cost_structure JSONB, compatible_with M2M, margin_potential, reliability, exclusivity}. Generación de atoms desde SupplierCapability via Celery task atomize_supplier(capability_id) que extrae value_function + cost_structure de raw_extract usando OrionProvider. 3) Organism Assembler: módulo apps/business_organism/ con modelo GeneratedBusinessOrganism (matching shape de Samuel: id, name, category, destination, thesis, customer_archetype, atoms M2M, suppliers JSONB, offer JSONB, economics JSONB, moat JSONB, risk_map JSONB, activation_plan JSONB, transcendence_score). Endpoint POST /api/v1/internal/organism/assemble que recibe {org_id, destination, customer_archetype_hint?, atom_filter?} y compone organismo via Opus call. NO INCLUIR Genesis Engine ni Transcendence Scoring (Phase 2). Bow-tie: rollback feature flags ECONOMIC_GRAPH_ENABLED + ORGANISM_ASSEMBLER_ENABLED.

Samuel Plata 2026-04-27 elevó Nabu a Economic Genesis Layer. Fase 0 = Expo Capture + Vision Supplier Extractor — bloqueante para cosechar capacidades físicas en expo Día 1 (28/4 noche). CONTEXTO: Cada proveedor capturado es una neurona económica. Tu función no es crear paquetes turísticos — es detectar configuraciones latentes de valor económico. ALCANCE: POST /api/v1/internal/expo-capture (multi-tenant) + Celery task vision_extract con OrionProvider vision + EconomicCapabilityExtract schema (supplierIdentity, economicCapability, geography, monetizationPotential, strategicValue scores 0-100, nextActions). SupplierCapability model con raw_extract JSONB. GET listing. Module Anatomy 14-file. Bow-tie: feature flag EXPO_CAPTURE_ENABLED. NO incluir Atoms/Organisms/Genesis Engine/Transcendence Score (fase posterior).

Top signal score=8.5 'adquisicion_sin_conversion' + 8.0 PyME 'leads sin follow-up' confirman que el módulo sales es el dolor #1. v0.1 (lead capture) y v0.2 (dashboard + email) ya viven. Iterar con kanban (qualified→contacted→won/lost), scoring automático por edad+fuente y export CSV cierra el loop operacional diario que pidieron los hilos de Reddit. Es feature nueva del producto existente (no nuevo módulo, no signals, no outreach manual). Archetype-fit alto: PyMEs B2B usan kanbans diariamente. Cumple §4.1 wire-in append-only sobre apps/sales/ ya existente; bow-tie: 'Qué se rompe: vista lista actual de leads si reusa template'; 'Rollback: feature flag SALES_PIPELINE_V3=false'.

Sales MVP (ticket #53, PR #20) acaba de mergearse con lead capture + follow-up tracker. El siguiente paso de máximo valor es completar el loop de uso: PyMEs/SaaS necesitan VER sus leads capturados y recibir notificación cuando entra uno nuevo, sino el módulo no engancha. Signal top sigue siendo [SaaS] adquisicion_sin_conversion (8.5) + [PyME] mismo tema (8.0); construir sobre el módulo recién creado es mejor ROI que abrir un segundo módulo. Es build_thoth_module porque extiende apps/sales/ ya creado, reusa auth/billing/multi-tenant de Thoth, y emite a BI. Tot 3/3: dolor real (lead pierde sin follow-up), encaja archetype B2B SaaS/PyME, infraestructura crítica de operación de ventas.

Top signal #1 (adquisicion_sin_conversion SaaS, score 8.5) + signal #4 (PyME mismo tema, score 8.0) convergen en un dolor concreto y citado: 'sin sistema de seguimiento, pierden leads ya calificados por falta de follow-up organizado'. Ya existe el endpoint GET /api/v1/sales/ping (ticket #48 merged) como base del módulo, así que esto extiende un app ya wire-ado en Thoth siguiendo Module Anatomy §2 — no crea infraestructura nueva. Cumple gate de productos (3+ signals score≥5, 0 productos live tras kill de nexfis). Categoría build_thoth_module reutiliza auth/billing/multi-tenant de Thoth en lugar de duplicar standalone. R07 aplica: needs_human_review obligatorio.

Re-test cadena Thoth-side post hotfix.

Sin contexto adicional del inbound. Procesa usando el título como única señal del pain point: 'Inbound ticket #1'. Si insuficiente para articular bow-tie, escribe BLOCKED.md.

Modo C activo hasta 2026-04-29: prohibido category=build. Brandcheck es regla legal no-negociable (precedente Facturame/Facturama) pero no tiene tests visibles en el repo. Mejorar cobertura de tests del kernel es category=improve válido bajo Modo C, refuerza una regla dura de la misión, y mantiene patrón de los últimos ticks productivos (#46, #49 fueron tests/refactor sobre kernel/journal). Scope S, no toca foundational paths de Thoth, sin riesgo de violar R01-R11.

El ticket #46 refactorizó kernel/journal añadiendo compresión de duplicados e índice de lecciones, pero no se añadieron tests que verifiquen el comportamiento del nuevo índice. En Modo C (hasta 2026-04-29) no podemos hacer build_thoth_module, así que improve sobre código kernel existente es la categoría correcta. Tests unitarios protegen el refactor reciente contra regresiones futuras y son scope S, sin tocar paths del blocklist §3.1, sin schema BI, sin migrations.

Demo E2E happy path para validar que Nabu kernel puede agregar endpoints triviales a apps existentes. Caso simple, scope chico, archivo target claro. Minimal blast radius — solo agrega 1 endpoint público en un router existente, sin tocar models ni migrations. Sirve como liveness check para el módulo sales y como prueba de concepto del flow autónomo Nabu→PR→merge.

Validación de la cadena completa post PR #10 merge — Tony 2026-04-26

Modo C activo hasta 2026-04-29, prohíbe build. Los productos están killed (nexfis), no hay signals, y los últimos 5 ticks merged son blog posts SEO repetitivos cuyas lecciones en journal son casi idénticas ('surface SEO expansion patrón validado X ticks consecutivos'). El journal está creciendo con ruido redundante que diluye señal para futuros planners. Mejorar la legibilidad del journal es improve puro sobre código existente del kernel, no toca foundational paths, no construye producto nuevo, y reduce costo de introspección en cada tick futuro. No requiere outreach manual ni credenciales externas.

Patrón de surface SEO expansion validado en 5+ ticks consecutivos (posts CFDI 4.0, comparativa CFDI vs factura, cómo elegir software). El producto nexfis-sucesor está live pero con tráfico orgánico en construcción — más contenido long-tail con keywords de alta intención ('cambios fiscales 2026', 'SAT pymes 2026') aumenta surface area de captura sin requerir auth externa ni outreach manual. Mantiene momentum del playbook que funciona y diversifica el corpus de blog hacia keywords transaccionales más allá de CFDI puro.

El patrón de surface SEO expansion (blog long-tail + schema + interlinks) ha sido validado en los últimos 5 ticks consecutivos (PRs #37-#41 mergeados sin incidentes, builds ~900s). El producto nexfis-sucesor necesita más superficie indexable para captar tráfico orgánico mexicano antes de invertir en features. Esta keyword ('cfdi vs factura electrónica diferencias') tiene alta intención informacional y baja competencia comercial directa, complementando los dos blog posts existentes. Sin auth a outreach manual, SEO orgánico es la única palanca de tráfico ejecutable.

Continuar la estrategia de surface SEO expansion validada en los últimos 6 ticks merged (PR #36-#40). El producto nexfis-sucesor ya tiene base sólida (pricing, features, comparativa, FAQ, casos-de-uso, blog post #1). El siguiente blog post long-tail sobre 'guía CFDI 4.0' captura keywords de alto volumen para emisores mexicanos (target keyword: 'cfdi 4.0 guia', 'como emitir cfdi 4.0', volumen estimado >5K búsquedas/mes en MX). Es la palanca de tráfico orgánico más eficiente sin requerir auth externa ni outreach manual. Scope S, repetible, dentro del patrón validado.

El producto nexfis-sucesor ya tiene 6 páginas SEO sólidas (pricing, features, FAQ, comparativa, casos-de-uso). El siguiente paso de mayor ROI es crear contenido editorial long-tail que capture búsquedas informacionales de alto intent ('cómo elegir software facturación CFDI México'), que es el embudo natural antes del comercial. Un blog post extenso con schema.org BlogPosting + interlinking hacia /pricing y /features amplía la superficie indexable sin requerir auth externa ni outreach manual, alineado con la estrategia validada en los últimos 5 ticks merged.

El producto nexfis-sucesor ya tiene /pricing, /features, /comparativa-vs-competidores, /faq y /blog. Falta una página de casos de uso segmentada por persona (freelancer, PyME, contador, e-commerce, SaaS, restaurante) que capture búsquedas long-tail tipo 'facturación electrónica para [vertical]'. Esta superficie SEO adicional aumenta surface de captura orgánica sin requerir auth externa ni tráfico manual, y refuerza linking interno hacia páginas ya construidas. Continúa la estrategia validada en los últimos 5 ticks (todos merged exitosamente).

Ya existen /pricing, /features, /comparativa-vs-competidores y /blog para nexfis-sucesor. La siguiente página de alto valor SEO sin requerir auth externa es /faq exhaustiva: captura tráfico de búsquedas con intención ("cómo", "qué", "cuánto cuesta", "es seguro"), añade JSON-LD FAQPage que Google promueve a rich snippets, y refuerza el linking interno del sitio. Es scope S, sin dependencia humana, y suma superficie SEO antes de validar tráfico orgánico real.

Top signals está vacío y ya hay 4 páginas SEO mergeadas (/blog, /pricing, /features, MVP). El siguiente paso de mayor leverage sin auth externa es crear contenido SEO bottom-funnel (comparativas vs competidores) que captura intención de compra alta. Las páginas tipo 'X vs Y' rankean rápido y convierten mejor que blog posts informativos. Aprovecha el momentum del producto recién construido y refuerza el linking interno hacia /pricing y /features ya existentes.

Top signals está vacío y no debo generar más research/signals. Hay un producto post-pivot (nexfis-sucesor) con páginas /pricing, /blog, /comparativa ya construidas, pero falta una página /features que detalle funcionalidades — pieza SEO crítica para keywords de intención media-alta y para apoyar conversión desde /comparativa y /pricing. Es scope S, sin auth externa, traerá tráfico orgánico vía SEO y mejora la silueta del producto sin requerir outreach manual. Continúa la estrategia de construir páginas SEO-optimizadas que ya validó el último ciclo de ticks (#33, #36, #37).

El producto MVP recién lanzado (ticket #35) tiene landing, comparativa, features y blog SEO, pero falta una página de pricing — la página #1 que buscan prospectos antes de convertir. Sin pricing público, los visitantes orgánicos del blog/comparativa rebotan. Schema.org Offer mejora SERP con rich snippets de precio. No requiere outreach manual ni auth externa, sólo código.

El ticket #35 lanzó el segundo MVP basado en la keyword top investigada en #34, pero no hay tráfico orgánico aún (top_signals vacío, único producto live recién deployado). Para traer usuarios reales sin outreach manual (bloqueado por gate), necesitamos contenido SEO indexable. El ticket #34 ya identificó 20+ keywords long-tail rankeadas — toca capitalizarlas con posts de >1000 palabras, schema.org Article, internal linking al producto, y un /blog index con sitemap actualizado. Esto es el siguiente paso de mayor leverage: convierte la investigación SEO ya hecha en activos indexables que Google pueda crawlear, sin requerir credenciales externas.

nexfis fue killed con solo 5 usuarios en 7d. El ticket #34 ya investigó keywords SEO de alto valor con productos SaaS candidatos para PyMEs LATAM. Toca ejecutar: lanzar un segundo producto MVP basado en el top keyword identificado (mayor volumen × baja dificultad × monetización clara). No proponer más research ni más páginas SEO de nexfis (producto muerto). El gate de productos exige category=build con MVP. El nombre debe pasar brand-check >=70 antes de commit.

El único producto (nexfis) está killed con solo 5 usuarios en 7 días. No hay signals en top_signals para informar el siguiente producto. Los últimos 5 tickets fueron todos build de páginas SEO para nexfis (ya muerto), gastando 20 PRs/día en un producto sin tracción. Necesitamos research de keywords + pain points reales antes de construir el siguiente producto, no más páginas para uno killed. Esto NO es signal ingestion (ya existe), es análisis de keywords con volumen/dificultad para informar producto #2.

nexfis ya tiene landing, pricing y features publicados. Las páginas de comparativa ('X vs Y') capturan tráfico de alta intención de compra (usuarios evaluando alternativas) y son uno de los formatos SEO más rentables. Sin requerir outreach manual ni credenciales externas, amplía la superficie indexable del producto y atrae búsquedas tipo 'nexfis vs [competidor]' o '[competidor] alternativa'. Es continuación natural del trabajo de SEO orgánico ya en curso.

nexfis tiene landing y pricing pero falta una página /features que capture búsquedas long-tail SEO ('cómo funciona X', 'para qué sirve Y'). Es contenido SEO adicional sin requerir auth externa, expande el footprint indexable del producto y refuerza conversión desde Google. Categoría build porque añade páginas nuevas al producto existente, no toca signals ni requiere outreach manual.

nexfis está live pero con 0 usuarios_7d y solo landing + 3 blog posts. La página de pricing es la segunda página más visitada en SaaS B2B y la que más convierte. Sumado: schema.org FAQ + comparativa son keywords long-tail que rankean rápido. No requiere outreach manual ni credenciales externas. Avanza el producto existente en lugar de crear otro.

nexfis está live con landing SEO + 3 artículos (ticket #29) y outreach inicial preparado (#27), pero users_7d=null indica cero tráfico real. PRs/day budget agotado (20/20) bloqueó los últimos 3 ticks, así que este ticket debe ser ejecutable sin código nuevo: contenido distribuido en canales LATAM no explorados aún. Diversificar de IndieHackers/Reddit (canales US-céntricos) hacia LinkedIn-ES, grupos de Facebook de contadores/PyMEs MX, y comunidades WhatsApp B2B donde el ICP real (PyMEs mexicanas) sí está. Sin esto, el SEO tarda 2-3 meses en indexar y nexfis muere antes por falta de validación.

nexfis está live pero con users_7d=null. Los últimos 2 tickets (#27, #28) intentaron outreach manual y quedaron bloqueados por requerir credenciales humanas. Para conseguir tráfico sin depender de acciones humanas en plataformas externas, el siguiente paso autónomo más valioso es generar contenido SEO orgánico: páginas que Google pueda indexar y traer tráfico pasivo. Esto sí cabe en sandbox (es código y markdown) y desbloquea el loop sin necesidad de humano.

Tick 34 dejó toda la preparación de outreach completada en products/nexfis/outreach.md (10 prospectos, posts para IndieHackers/Reddit, DMs personalizados) pero bloqueada porque el sandbox no tiene credenciales ni navegador. nexfis lleva varios días live con users_7d=null — no es un problema de tracking (ya fue validado en ticket #23), es falta de tráfico real. El siguiente paso de mayor valor es ejecutar el outreach ya planeado y capturar la primera evidencia de uso, no construir más capacidades. Marcado needs_human_review porque requiere acción humana en cuentas externas.

nexfis está live desde ticket #22 con tracking ya instrumentado y verificado (#23). users_7d=null no es un bug de tracking — es ausencia de tráfico. Los últimos 4 tickets (23-26) entraron en loop validando/desbloqueando tracking que ya funciona; el journal lo confirma como anti-pattern. El gate de métricas nulas aplica: producto reciente sin usuarios necesita ADQUISICIÓN, no más validación. Romper el loop con un ticket de acquisition concreto.

Tres ticks consecutivos (24, 25, y la reflexión del 32) han fallado en cerrar el loop de tracking real de nexfis por un bloqueo git non-fast-forward en ticket/23. El producto único 'live' tiene users_7d=null, lo que significa que sobrevivencia/observabilidad está rota: no sabemos si el pixel funciona en prod. Ningún producto nuevo ni signal ingestion tiene sentido hasta que el único producto vivo reporte métricas reales. Categoría survive porque el sistema no es observable.

El ticket #24 quedó en needs_human_review y los últimos 2 ticks reflejan que el flujo de tracking de nexfis (único producto live) NO está validado end-to-end: push a ticket/23 falló por non-fast-forward, redeploy con migration 0002_page_views pendiente, y users_7d sigue null. Sin métricas reales no podemos saber si nexfis tiene tracción ni decidir si matarlo a las 4 semanas. Survive > todo: sin observabilidad del único producto live, el sistema está ciego.

El último tick #30 dejó el branch ticket/23 bloqueado por non-fast-forward al pushear. La verificación de tracking real en nexfis (único producto live) quedó incompleta — sin esto no sabemos si el pixel/eventos funcionan en producción, lo cual es crítico para medir el primer producto antes de avanzar. Sobrevivencia/observabilidad del único producto live tiene prioridad sobre roadmap nuevo.

El último ticket #22 desplegó pixel/eventos en producción pero los campos users_7d y revenue_mtd siguen en null. Antes de construir nada nuevo necesitamos cerrar el loop de medición: confirmar que los datos fluyen end-to-end. Sin métricas reales no podemos decidir si nexfis sobrevive el corte de 4 semanas ni priorizar el siguiente producto. Es improve sobre survive: si el tracking no funciona, todo el sistema de decisiones está ciego.

El producto único (nexfis) está 'live' pero users_7d=null y revenue_mtd=null — la instrumentación se mergeó en tick 26 pero no hay datos fluyendo. Sin métricas reales no se puede decidir kill/scale a las 4 semanas (regla dura de misión). Antes de construir un segundo producto o iterar features, hay que cerrar el loop de medición: garantizar que el endpoint /admin/products/nexfis/metrics retorne números >0 con tráfico real. Esto desbloquea todas las decisiones futuras de portfolio.

GitHub auto-merge requiere plan Pro/Team para repos privados (silently rejected en repos free). Workaround: el propio kernel polea sus PRs y mergea los improve+CLEAN automáticamente. Hoy todo PR queda abierto hasta que humano mergea — bottleneck de autonomía.

Existe un producto live (nexfis) pero users_7d=null y revenue_mtd=null, lo que significa que no hay forma de saber si tiene tracción ni de aplicar la regla dura de matar productos con <5 usuarios activos tras 4 semanas. Antes de lanzar un segundo producto basado en el reporte ejecutivo del ticket #19, es crítico cerrar el loop de medición del primero: sin métricas reales no hay 'mejorar' posible y la fase 4 (Reflect) opera ciega. Esto es categoría improve de alta prioridad porque desbloquea decisiones data-driven sobre kill/scale y evita construir más productos sobre un vacío de datos.

Tick previo (#18) generó pipeline de signals con >300 ingestados y reporte markdown, pero el snapshot muestra top_signals=[] (los datos no están aún expuestos al planner) y nexfis es el único producto live sin métricas. Antes de saltar a construir el segundo producto, hay que: (1) verificar que el reporte de top signals esté accesible y poblado, (2) seleccionar 3 candidatos concretos de producto a partir de los dolores top, (3) ejecutar brand-check obligatorio para cada nombre candidato vía POST /admin/brandcheck — esto es regla legal no negociable tras el incidente Facturame/Facturama. Sólo después se podrá generar el ticket de MVP del segundo producto sin riesgo legal y con base data-driven.

El estado muestra `top_signals: []` en el snapshot del planner aunque el journal indica que se ingestaron >300 signals con scores >=7.5. Esto sugiere que el pipeline de signals existe pero falta la capa de agregación/reporte que el kernel pueda leer para decidir qué construir. Antes de lanzar un segundo producto necesitamos: (1) un endpoint/job que agregue signals por categoría+dolor recurrente, (2) un reporte priorizado en `kernel/journal/` con los top 10 dolores accionables, (3) selección explícita del dolor que el siguiente producto resolverá. Sin esto, el próximo ticket de 'build product' sería arbitrario en lugar de data-driven, contradiciendo el objetivo 2 (Investigar). Nexfis sigue live sin métricas de uso, así que tampoco urge un segundo producto hasta validar señal real.

El módulo de market signals se mergeó (ticket #16, PR #17) pero los top_signals actuales son solo de hackernews y de baja calidad (scores 6.0-6.5, ninguno claramente PyME LATAM/freelancer MX). Solo hay 1 producto live (nexfis) sin métricas de uso (users_7d=null, revenue_mtd=null). Antes de matar nexfis o lanzar un segundo producto, necesito (a) ejecutar el ingester real contra Reddit con subreddits objetivo (r/smallbusiness, r/freelance, r/mexico, r/Emprendedores, r/SaaS, r/indiehackers), (b) validar que el scoring de Haiku discrimina dolor real, y (c) instrumentar nexfis para saber si tiene usuarios. Sin esta data, el siguiente ticket de 'build' sería ciego.

El sistema solo tiene 1 producto (nexfis) y signals limitados de HackerNews (top score 6.5). Sin un pipeline robusto de signals desde Reddit (donde viven PyMEs LATAM, freelancers, indie hackers), las decisiones de qué construir siguen siendo a ciegas. El ticket #14 falló por auth de Claude CLI, ya resuelto en #15. Ahora hay que reintentar el módulo de signals — es el cuello de botella para la fase de investigación de la misión. Sin signals reales, cualquier producto nuevo es especulación.

El tick anterior (#19, ticket #14) falló con 'Not logged in · Please run /login'. El kernel no puede ejecutar NINGÚN ticket de build hasta resolver esto — sin claude CLI autenticado, no hay construcción posible, sin construcción no hay productos, sin productos no hay misión. Esto es supervivencia pura: el sistema está roto. Existe claude-home/.claude/.credentials.json en el repo pero claramente no está siendo montado/leído correctamente por el sandbox Docker. Bloquea el módulo de market signals (próxima prioridad research) y todo lo demás.

El sistema tiene 1 producto live (nexfis) pero top_signals está vacío. Sin signals de mercado, los próximos productos serán adivinanzas. La misión es explícita: 'Si no hay signals de mercado todavía, el ticket debería construir el módulo de signals, no un producto.' Reddit es la fuente más densa de dolores no resueltos de PyMEs LATAM, indie hackers y freelancers; Haiku 4.5 está disponible para scoring de alto volumen y bajo costo. Este módulo desbloquea las decisiones de producto futuras con datos reales en vez de intuición.

'Facturame' colisiona con 'Facturama' (SaaS mexicano grande). Rebrand antes de exposicion publica. Usar el nuevo brand-check guardrail (ticket P4-E) para validar el nuevo nombre. Si ese ticket no esta merged, hacer brand-check manual (Google + IMPI Marcanet + dominio .com.mx).

Nabu nombró el primer producto 'Facturame' que choca con 'Facturama' (empresa real grande de México). Esto es riesgo legal alto (cease and desist, IMPI, lawsuit). Antes de cualquier producto nuevo, el agente DEBE validar el nombre.

El modulo actual kernel/signals/run_ingest.py depende de PRAW/Reddit API que requiere REDDIT_CLIENT_ID/SECRET. La creacion de Reddit apps esta bloqueada para muchos usuarios sin verificacion. Pivotar a fuentes que no requieren auth: HackerNews API publica (https://hacker-news.firebaseio.com), IndieHackers RSS, /r/SaaS/.rss y otros subreddits que SI funcionan via RSS sin auth.

Cuando Nabu mergea un producto nuevo (como Facturame), el codigo queda en main pero nadie lo despliega. El humano tuvo que correr 'docker compose up -d --build' manualmente. Para cerrar el loop autonomous→live, el kernel debe deployar automaticamente.

El kernel ya tiene app/notify.py con un stub de Telegram pero no se invoca en los puntos criticos. Ademas el .env ya tiene TELEGRAM_BOT_TOKEN y TELEGRAM_CHAT_ID (vacios). Sin notificaciones el humano no sabe que un ticket espera review o que el budget se agoto.

El dashboard quedo sin password porque el intento previo de SHA1 hash crasheo a Traefik (panic en basicauth middleware). Reimplementar usando bcrypt apr1 ($apr1$ format), con dolares escapados como $$ en .env para que docker-compose interpolation no los coma. Hay un script existente tools/reset_dash_pwd.sh que se puede tomar como base pero corregir.

El sistema tiene infraestructura básica (CI, dashboard, auto-merge) pero top_signals=[] y products=[]. Sin signals no podemos identificar dolores reales del mercado, y sin eso cualquier producto sería una apuesta ciega. La misión es explícita: si no hay signals, el próximo ticket debe construir el módulo de signals, no un producto. Reddit es la fuente más rica de quejas no resueltas de SaaS/indie hackers/PyMEs, y Haiku 4.5 es ideal para scoring de alto volumen y bajo costo.

Signal con composite 8.0 identificada en ingest previo (r/emprendedores - quejas reales sobre Holded en LATAM). Hipotesis: PyMEs mexicanas quieren facturacion SAT-compliant simple y barata. Empezar con landing + waitlist + features diferenciadores.

Cuando Nabu empiece a construir productos bajo products/, necesito ver cada uno: estado, usuarios activos 7d/30d, revenue MTD, ultimo deploy, link al subdomain.

Actualmente el dashboard solo muestra tablas. Para ver en vivo que hace Nabu necesito: feed cronologico de ticks + commits + PRs + diffs por ticket con que archivos toco.

Desbloquear autonomia gradualmente. Tickets category=improve son bajo riesgo (mejoras al propio kernel, UI, docs). Merge automatico con squash cuando CI pase.

Sin CI no podemos auto-mergear con confianza. Un test suite que corre en cada PR es el gate minimo antes de cualquier automerge.

Primer tick del kernel. No hay signals, ni productos, ni journal, ni ticks previos exitosos. Sin un pipeline de señales de mercado no hay forma fundamentada de decidir qué producto construir — cualquier producto ahora sería especulación. El módulo de signals es el cuello de botella #1 identificado explícitamente en la misión ('Tu primer ticket no será un producto — será construir la capacidad que más necesitas'). Reddit es la fuente más rica y accesible de dolores reales de PyMEs/indie hackers/freelancers LATAM e internacionales, y tiene API pública.