📘 Manual TUNIX

← Talk

1.1Quick Start — primer minuto

1. Conectá audífonos bluetooth al celu
2. Abrí Forge OS → tap shortcut Talk (o navegá a /talk)
3. Tap el botón verde 📞 grande
4. Hablá. Cuando termines de hablar, espera 1.2 segundos de silencio — el VAD detecta el fin de tu turno y TUNIX responde
5. Para colgar, tap el botón rojo 🛑

1.2El equipo Tungsteno

4 personajes, cada uno con su modelo y especialidad. Vos siempre hablas con TUNIX — los demás son sub-agentes silenciosos que él delega.

1.3Frases útiles

Le decís	TUNIX hace
"¿quién soy?"	Responde tu perfil cargado del Memory Forge
"¿qué tengo hoy?"	Lista reuniones del día + tareas top
"¿qué recordatorios tengo para el lunes?"	query_reminders en forge_user_context
"recordame X mañana a las 10"	create_reminder (parse fecha con Haiku)
"¿quién es Natalia Garcés?"	Cascada deep_search → forge_global_search → search_entities
"que GOJAN prepare propuesta para X"	Spawnea GOJAN background
"que DEVIX revise por qué falla X"	Spawnea DEVIX
"GOJAN urgente, prepara X"	Spawnea con important=true (interrumpe al terminar)
"¿de qué hablamos la última vez?"	Lee summaries previos de tunix_talk_sessions
"búscame cuando hablamos sobre Nicolás"	search_talk_history (RAG embeddings)
"analizame en profundidad cómo está armado X"	delegate_to_claude_max (Opus 4.7, sin truncar)
"mejorate y agregame la capacidad de Y"	tunix_self_improve flow (análisis → confirma → aplica)
"pará / esperame"	Pausa voz inmediato
"continuá"	Retoma desde donde paró
"dale en tungsteno"	Activa modo autónomo (ver 3.2)

1.4Controles UI (botones)

Botón	Función
🧠 ALTO RAZONAMIENTO	Toggle al lado del verde. ON = TUNIX delega A CADA respuesta no-trivial a Opus 4.7. OFF = router automático según complejidad. Persistente en localStorage.
📞 / 🛑 Verde / Rojo	Iniciar / colgar llamada. Rojo libera mic + cierra WS + persiste sesión.
⏸️ PAUSA	Mic muteado + audio TUNIX cortado + WS sigue conectado. Útil en bus/ruido. Cambia a ▶️ REANUDAR.
▶️ CONTINUAR	Le pide a TUNIX retomar su última idea (cuando él hizo pausa por largo).
❓ Header	Abre este manual.

1.5Modo siempre escuchando

Podés dejar el Talk abierto indefinido:

• Silencio = $0 — OpenAI no factura cuando vos no hablas
• TalkForegroundService (Android specialUse) mantiene el proceso vivo con celu bloqueado + audífonos BT
• TUNIX te interrumpe SOLO si:
  • Un agente importante terminó (te lee resultado + dispara push)
  • Un agente se entrampó (te explica + propone alternativas)

2.1Routing por complejidad

TUNIX matchea la profundidad de la respuesta a la profundidad de la pregunta. Calidad ingeniería sobre velocidad — preferible esperar 30s con respuesta completa que 5s vaga.

Tipo de pregunta	Quién contesta	Tiempo	Profundidad
Simple (1 step, lookup, comando)	gpt-realtime directo	1-2s	natural corta
Mediana atómica (1 tool)	TRUNKS (Haiku)	2-3s	factual
Mediana razonamiento	DEVIX / GOJAN (Sonnet)	5-15s	completa sin truncar
Compleja análisis	Opus 4.7 (quick=false)	15-30s	calidad ingeniería
Razonamiento extenso (estratégico)	Opus quick=false explícito	30-60s	máxima

2.2Cascada de búsqueda (4 niveles)

Cuando preguntás "¿quién es X?" / "¿qué sabes de Y?", TUNIX escala automático hasta encontrar:

NIVEL 1 — deep_search(query)        ~135ms  ILIKE 9 tablas clave
   ↓ si 0 hits
NIVEL 2 — forge_global_search        ~2s     ts_vector full-text 20+ tablas
   ↓ si 0 hits
NIVEL 3a — search_entities           ~220ms  axis_entities (Gemini 768)
NIVEL 3b — axis_hybrid_search        ~330ms  AXIS memory (vector + keyword)
   ↓ si 0 hits
NIVEL 4 — delegate_to_claude_max    ~15-30s  Opus + MCP Supabase SQL custom
   ↓ si 0 hits
"No encontré nada en mi sistema. ¿Probamos otra fuente?"

2.3Memoria conversacional — 3 capas

Arquitectura post 25-may-2026. Realtime NO recuerda nada por sí mismo (es voz + orquestación pura). La memoria vive en Supabase con embeddings Gemini 768d.

Capa 1 — Auto-recencia (siempre cargada, 0ms)

El endpoint /api/tunix-realtime-tools consulta las últimas 5 sesiones Talk de 72h y las inyecta al system prompt al iniciar cada llamada. Formato:

• "título" [hace 3h, 12 turnos] · temas: X, Y, Z
  resumen: ...

Sin tool call. Sin latencia. Solo da contexto a grandes rasgos — para detalles textuales TUNIX usa Capa 2.

Capa 2 — recall(query, hours_back?) — vector search directo (~1.5s)

Embedding Gemini 768 de la query → RPC tunix_talk_recall(p_query_embedding, p_hours_back, p_max_results, p_min_similarity) → top-5 turnos exactos rankeados por similarity × 0.7 + recency_decay × 0.3.

Disparadores: "qué hablamos de X", "qué te dije sobre Y", "te acuerdas cuando...", "leeme lo que dijimos de Z".

Devuelve: {session_id, session_title, when, turn_number, patricio_dijo, tunix_dijo, similarity, score}. TUNIX lee los hits TEXTUAL, mencionando cuándo se dijo y nombrando que vino de Capa 2.

Capa 3 — memory_librarian(query) — Sonnet sintetiza (~6s)

Top-15 fragmentos del mismo RPC → pasados a Sonnet 4.6 vía tunix-claude-max (OAuth Max, $0) → devuelve narrativa cerrada lista para que TUNIX lea TEXTUAL en voz alta.

Disparadores: "hazme un resumen todo lo hablado sobre X esta semana", "qué nos quedó pendiente con Y", "punteo de decisiones de Z".

Memory Forge (memoria estática)

• read_memory(slug) y list_memories() — canon documental en forge_memory + carpeta ~/.claude/projects/.../memory/_core
• recall_lessons(query) — lecciones consolidadas por REM agent nocturno
• forge_global_search(query) — búsqueda híbrida sobre 25 tablas con embeddings

Reflexión post-sesión (al colgar)

• Haiku resume transcript: 1 párrafo + 3-5 key_topics + pending_actions estructurados
• Embedding del summary → forge_tunix_talk_sessions.embedding
• Si sesión ≥4 turnos + insight nuevo → INSERT en forge_memory con slug auto-generado

2.4Reflexión post-sesión auto

Si la sesión tiene ≥4 turns + summary OK, Haiku analiza el transcript completo y decide si hay algo NUEVO que valga la pena guardar como memoria persistente. Criterios:

• Preferencia/regla no obvia que reveló Patricio
• Decisión arquitectural/estratégica nueva
• Bug con causa raíz no obvia + fix
• Info de cliente/prospect/proyecto que no estaba
• Patricio dijo explícito "anotá esto"

Si pasa el filtro → INSERT en forge_memory con slug auto-generado. Costo ~$0.0003/sesión.

2.5Auto-evolución

TUNIX puede mejorarse a sí mismo modificando su propio código. Flow obligatorio en 2 pasos con OK humano:

1. Análisis: tunix_self_improve(observation) → Claude Max lee codebase + devuelve plan JSON: {commit_sha, files, requires_apk_rebuild, already_applied, blocker, summary}. NO modifica nada.
2. Aplicar: solo después de tu OK por voz → tunix_self_improve(observation, proposed_change, confirmed_apply=true) → Claude Max edita + commit + push.
3. Post-deploy watch: endpoint background pollea Vercel hasta READY → dispara push notif al celu con el resultado.
4. Detect APK rebuild: si el cambio tocó android/* o capacitor.config.ts, TUNIX avisa que se requiere compilar APK nueva (más complejo, mejor desde tu PC).

Cada mejora queda registrada en forge_tunix_improvements con observación, plan, commit_sha, status.

3.1Barreras de seguridad

2 capas:

Capa 1 — system prompt (modelo)

TUNIX sabe qué requiere confirmación, doble OK por voz para destructivos, "ingresá a la APK a confirmar" para los mayores.

Capa 2 — backend regex (red de seguridad)

isDestructive(task) bloquea automático si match keywords:

drop table | truncate | delete from (sin WHERE)
git push --force | git reset --hard | git branch -D | git clean -fd
rm -rf | wipe | destroy | nuke | format database
modificar .env | modificar secret | modificar token | modificar oauth
docker rm -f | docker kill -f
DROP DATABASE | DROP SCHEMA

Si match + confirmed_destructive=false → devuelve error destructive_action_requires_confirmation. TUNIX debe pedir confirmación humana y volver con confirmed_destructive=true.

3.2Modo Tungsteno

Qué es: operación autónoma orquestada. TUNIX coordina sub-agentes sin pedir permiso intermedio, hasta cerrar el objetivo. Te reporta al final.

Flow obligatorio (TUNIX SIEMPRE pasa por esto antes de arrancar):

1. Vos proponés una tarea
2. TUNIX explica qué entendió y qué piensa hacer (3 frases máx)
3. TUNIX pregunta: "¿lo hago en tungsteno o paso a paso?"
4. Vos decidís → ahí recién arranca

3.3Acciones destructivas

Tipo	Confirmación requerida
Destructivo menor (delete con WHERE específico, rm de archivo único)	Doble OK por voz: "esto va a [X]. ¿confirmás?" → si sí → "última vez: ¿seguro? Esto no se deshace." → si sí → ejecuta
Destructivo mayor (drop database, wipe disk, push -f, mass delete)	TUNIX NO ejecuta por voz aunque digas sí dos veces. Te pide: "esto es muy grueso, ingresá a la APK y confirmalo manualmente en /tunix-ops"
Mensaje WSP/email a TERCEROS (clientes, prospects)	SIEMPRE pedir OK explícito mensaje por mensaje. TUNIX nunca manda solo
Modificar workflows n8n críticos	Solo vía scripts/lib/n8n_safe.py con verify_callback

3.4Anti-loop (agentes entrampados)

Si un agente intenta la misma tarea 2+ veces y falla, el sistema lo marca stuck:

• NO ejecuta más intentos solo
• Push notif al celu 🚧 [agente] entrampado
• TUNIX recibe alerta automática vía polling cada 6s y te avisa por voz:
  "Pato, GOJAN se entrampó después de 3 intentos. Te explico qué falló y te propongo 2 alternativas..."
• Vos decidís cómo reenfocar la tarea

Heurística backend: agent-run.js cuenta tasks recientes (4h) del mismo agent + prompt similar con status='failed'. Si ≥2 → marca stuck inmediato, NO ejecuta.

4.1Operar tu PC (BRUTAL MODE)

TUNIX puede operar tu PC física con Claude Code SDK real. Arquitectura pull-based (sin tunnels, sin endpoints inbound expuestos):

TUNIX (voz)
  ↓ delegate_to_pc(task)
INSERT en forge_pc_jobs status='queued'
  ↓ (poll cada 8s vía RPC claim_pc_job FOR UPDATE SKIP LOCKED)
forge_pc_agent.py corriendo en TU PC
  ↓ ejecuta: claude --print --permission-mode acceptEdits
Claude Code SDK opera tu filesystem
  ↓ stdout capturado
UPDATE forge_pc_jobs status='done' + result
  ↓ trigger push notif al celu
TUNIX te lee el resultado

Setup en tu PC (una sola vez)

cd e:\TUNGSTENO\forge-os
.\scripts\setup-pc-agent-task.ps1   # PowerShell admin
# Auto-arranca al login, restart si crashea, sobrevive batería

Ejemplos por voz

• "Tunix, listame los archivos de mi carpeta scripts"
• "Tunix, abrí CLAUDE.md y hazme un resumen lo principal"
• "Tunix, ejecutá npm run build en mi PC y avísame cómo va"
• "Tunix, modificá el archivo X agregando Y" (Claude Code aplica edits)

4.2Sub-agentes paralelos

TUNIX puede disparar DEVIX, GOJAN y TRUNKS en paralelo. Mientras trabajan, vos seguís conversando otras cosas. Cuando terminan:

• Important=true → TUNIX interrumpe natural: "Pato, un segundo — GOJAN ya tiene la propuesta, te leo lo clave..." + push al celu
• Important=false → acumula silencioso. Cuando termines tu tema actual, lo menciona casual

Heurística automática: si decís "urgente", "ya", "ahora" o "interrumpime" en el prompt, el backend fuerza important=true aunque TUNIX olvide marcarlo.

4.3Interrupciones y pausas

Método	Cómo	Comportamiento
Por voz	"Tunix espera" / "pará" / "un momento"	Silencio inmediato. WS sigue.
Hablando	Empezás a hablar durante TUNIX	VAD detecta (threshold 0.4) + interrupt_response=true → corta automático
Botón ⏸️ PAUSA	Tap en UI	Mic muteado + audio cortado + WS abierto. Cambia a ▶️ REANUDAR.
Para retomar	"continuá" / "seguí" o botón ▶️	TUNIX retoma desde la idea exacta donde paró

4.4Push notifications

Web Push VAPID a forge_push_subscriptions. Disparado por:

• Agente sub-agente termina (importante o normal)
• Agente queda stuck
• PC agent termina un job delegate_to_pc
• Auto-mejora deploy READY o FAILED
• Build APK CI publicado
• Eventos críticos del sistema

Cliente: scripts/forge_push.py o directo POST /api/push con Bearer.

5.1Costos detallados

Componente	Costo	De dónde
Voz TUNIX (OpenAI Realtime gpt-realtime)	~$0.12/min audio	OpenAI API
Sub-agentes DEVIX/GOJAN/TRUNKS	$0 extra	Tu OAuth Max ($200/mes)
delegate_to_claude_max	$0 extra	Tu OAuth Max
delegate_to_pc	$0 extra	Tu OAuth Max en tu PC
Memoria persistente (Haiku summary)	~$0.0003/sesión	API Anthropic
Reflexión post-sesión (Haiku)	~$0.0003/sesión	API Anthropic
Embeddings OpenAI text-embedding-3-small	~$0.00001/embed	OpenAI
Embeddings Gemini text-embedding-001 (axis_*)	~$0.00001/embed	Gemini API
STT/TTS (cuando aplica fuera Realtime)	centavos	Deepgram + ElevenLabs
Total estimado/mes	~$30-50 USD	uso típico 1h/día

5.2Optimizar cuota Max

• Plan Max tiene weekly limit rotativo. Mirá /usage en Claude Code para ver consumo
• Opus consume ~5x más que Sonnet por mensaje, ~15x más que Haiku
• Router automático tira default a Sonnet salvo casos complejos → ahorra cuota
• Toggle 🧠 ALTO RAZONAMIENTO solo cuando lo necesites (cada respuesta = delegate Opus)
• Sub-agentes idle no cuestan — solo cuando ejecutan

6.1Stack completo

┌─────────────────────────────────────────────────────────────┐
│ FRONTEND (APK Capacitor + WebView + public/talk.html)        │
│  · gpt-realtime WebSocket (audio in/out 24kHz PCM)            │
│  · Plugin nativo ForgeRecording (bypass WebView mic bug)     │
│  · TalkForegroundService (specialUse, celu bloqueado OK)     │
│  · Splash SVG (cubo+T blur→define) + sessionStorage flag     │
│  · Polling agent-status cada 6s → inyecta msg si stuck       │
│  · Pending tool calls counter (response.create 1 sola vez)   │
└────────────────┬─────────────────────────────────────────────┘
                 │ tool calls
                 ▼
┌─────────────────────────────────────────────────────────────┐
│ BACKEND VERCEL (api/tunix-tool-exec.js, maxDuration 300s)    │
│  · 30+ tools registradas                                      │
│  · isDestructive() regex guard pre-execute                   │
│  · embedQuery(text, dims=1536|768) OpenAI ó Gemini            │
│  · Audit a forge_tunix_tool_audit en cada call               │
└─────────┬──────────┬───────────────┬─────────────────────────┘
          │          │               │
          ▼          ▼               ▼
   ┌──────────┐ ┌─────────┐ ┌──────────────┐
   │ Supabase │ │ Bridges │ │ Container    │
   │ RPCs +   │ │ WSP/etc │ │ tunix-claude │
   │ tables   │ │         │ │ -agent (VPS) │
   └──────────┘ └─────────┘ └──────┬───────┘
                                    │ Claude Code SDK
                                    ▼
                            ┌──────────────────┐
                            │ Opus 4.7 / OAuth │
                            │ Max (sin $extra) │
                            └──────────────────┘

6.230+ tools categorizadas

Categoría	Tools
Lectura datos	query_tasks, query_meetings_today, query_meetings_upcoming, query_recent_wsp_audios, query_recent_meetings, query_reminders, get_emotional_state
Búsqueda cascada	deep_search → forge_global_search → axis_hybrid_search → delegate_to_claude_max
Búsqueda especializada	search_entities, wsp_search_history, search_history, search_talk_history
Escritura	mark_task_done, cancel_meeting, create_task, create_reminder, record_emotion
WSP (confirmación previa)	send_wsp_audio, send_wsp_text, preview_wsp_audio_reply
Multi-agent	spawn_agent (devix/gojan/trunks), check_agent_done, list_running_agents
Delegación profunda	delegate_to_claude_max (quick/full), delegate_to_pc, check_pc_job, delegate_to_claude_deep
Memoria	read_memory, list_memories
Sync runtime	sync_forge_now
Auto-evolución	tunix_self_improve, list_improvements

6.3Embeddings dual

El holding usa 2 modelos de embedding según la tabla. embedQuery(text, dims) elige automático.

Modelo	Dims	Tablas
OpenAI text-embedding-3-small	1536	forge_chat_history.embedding, forge_decisions, forge_helix_knowledge, forge_ledger_blueprints, forge_ledger_chat_logs, forge_meeting_embeddings, forge_notes, forge_tunix_talk_sessions, kumelemu_rag, tm_documentos, axis_codex, axis_sessions
Gemini text-embedding-001 (output_dim 768)	764	axis_entities, axis_episodic_memory, axis_procedural_memory, axis_semantic_memory, axis_query_cache, axis_prefetch_cache, axis_tasks, forge_skills.when_to_use_embedding, forge_os_lessons, sys_mind_wiki, forge_chat_history.gemini_embedding

6.4RPCs Postgres clave

forge_global_search(query_text, max_results=30)
  → 20+ tablas Forge + AXIS, full-text ILIKE
axis_hybrid_search(query_embedding, query_text, max_results=10)
  → vector + keyword sobre axis_semantic_memory + episodic + procedural + entities + codex
search_entities(query_embedding, filter_type, max_results)
  → personas/empresas/conceptos axis_entities
wsp_search_history(p_query, p_brand, p_contact_name, p_limit)
  → mensajes WSP histórico
search_talk_sessions(query_embedding, match_count, similarity_threshold)
  → conversaciones Talk previas con summary embeddings
forge_memory_search(p_query, p_project, p_limit)
  → Memory Forge full-text
devix_search_knowledge(q, k=5)
  → knowledge técnico DEVIX
claim_pc_job(target='patricio_pc')
  → atómico FOR UPDATE SKIP LOCKED para el agent PC
search_chats_semantic / search_chat_history_hybrid / search_codex /
search_decisions / search_blueprints / search_notes / search_tasks /
search_sys_mind / search_tm_docs / kumelemu_search_rag / skill_match

6.5Modos de voz

Modelo	Latencia	Costo	Cuándo
gpt-realtime (actual)	1-3s/turn	$0.12/min	DEFAULT
gpt-realtime-mini	1-2s/turn	$0.045/min	Más barato, antes tuvo bug truncate
gpt-4o-realtime	1-3s/turn	$0.32/min	Premium, no usado

Voz default: cedar (neutro latino). Sample rate: 24kHz PCM in/out.

6.5bSTT + Lexicon canónico (25-may)

Doble defensa para precisión en español acentuado y términos del dominio Forge OS.

Transcriber: gpt-4o-transcribe

Reemplazó a gpt-4o-mini-transcribe. ~10× más preciso en español, +~$0.05/día. Configurado en talk.html dentro de session.update.audio.input.transcription:

transcription: {
  model: 'gpt-4o-transcribe',
  language: 'es',
  prompt: 'Patricio Canquil, TUNIX, Forge OS, Tungsteno, ...'  // 110 términos
}

El campo prompt es un hint léxico que se envía UNA VEZ al iniciar la sesión. El STT lo usa para sesgar su modelo acústico hacia el vocabulario del dominio. NO cuenta como tokens de audio (gratis).

Lexicon en system prompt — 9 categorías

~60 mappings "transcripción confundida → forma canónica" que el LLM aplica antes de razonar o disparar tool calls. Cubre:

1. Identidades TUNIX — Twitch/Toris/Túnis → TUNIX, variantes Talk/Code/Búnker
2. Ecosistema Tungsteno — Tunsteno → Tungsteno, Sensor Med → TensorMed, FutaMaps
3. Modelos AI — Sunnet → Sonnet, Antrópic → Anthropic, Yemini → Gemini
4. Agentes — DEVIX, GOJAN, TRUNKS, AXIS, SWARM CORE V10
5. Infra / stack — Súper Base → Supabase, Wercel/Bercel → Vercel, Remoción → Remotion, Hicksfield → Higgsfield, Beilis → Baileys, pege vector → pgvector
6. Personas — vos, Sebas, Nico Luna, Natalia Garcés, Antonella, Verónica
7. Emails / dominios — pc.scholer, canquil27tm, forge.tungsteno.tech, tensormed.cl
8. Modos y comandos — modo Tungsteno, modo Furia DeepMind, nxs, /sync
9. Features Forge OS — hot-reply, voice-lab, grabar-reunión, Forge Studio/Broadcast/Reminders/Research Lab

Impacto en latencia / costo

Componente	Costo	Latencia
transcription.prompt	$0 (hint, no tokens facturados)	+50-80ms una sola vez al conectar
LEXICON system prompt (~600 tokens)	~$0.00009/día (centavos al año)	0ms por turno (prompt caching OpenAI Realtime)

Margen para crecer: hasta ~3000 tokens de lexicon antes de competir por espacio útil. Estamos en ~600.

6.6Trucos de fluidez (2026-05-23)

1. Acknowledgment hablado: antes de delegar a Opus/Sonnet, TUNIX habla "Dame un segundo" con gpt-realtime (1s). El tool corre en background. Cero silencio incómodo.
2. Quick mode condicional: delegate_to_claude_max default quick=false (calidad ingeniería completa). quick=true SOLO para preguntas con respuesta corta natural (factuales puntuales).
3. Router agresivo a Sonnet: DEVIX/GOJAN como default para razonamiento no-trivial. Opus solo casos genuinos o cuando ALTO RAZONAMIENTO toggle ON.
4. Ocupar el tiempo si >20s: TUNIX pregunta "esto me toma 30s, ¿esperas o avanzamos en otra cosa?". Si elegís segundo, procesa el nuevo tema en paralelo y vuelve con la respuesta de Opus cuando llegue.

6.7Streaming Opus SSE (token-by-token)

Cuando TUNIX delega a Opus con quick=false, el flujo NO es request/response tradicional sino Server-Sent Events bidireccional. Patricio ve la respuesta de Opus "escribiéndose en vivo" en el chat con markdown render incremental, en vez de esperar 15-30s en silencio + golpe.

Stack streaming end-to-end

Frontend talk.html (streamClaudeMax)
   ↓ POST /api/tunix-claude-max-stream (fetch streaming)
Vercel proxy (api/tunix-claude-max-stream.js)
   ↓ POST /agent-stream (SSE pass-through, Bearer auth)
Container tunix-claude-agent v10 (server.mjs)
   ↓ for await msg of query({...})
Claude Code SDK (OAuth Max)
   ↓ Opus 4.7 generando token-by-token
Para CADA text block → emit data: {"type":"chunk","text":"..."}\n\n
Para tool_use → emit data: {"type":"tool_use","name":"...","input":{...}}\n\n
Al final → emit data: {"type":"done","full_text":"...","result":{...}}\n\n

Eventos SSE emitidos

type	Payload	Frontend action
chunk	{text: "..."}	Acumula + renderiza markdown cada 250ms con cursor blinking
tool_use	{name, input}	addMsg('tool', '[Opus] toolName(args)')
repo	{status: "git pull result"}	Debug log
done	{full_text, tool_uses, result, duration_ms}	Render final + envía function_call_output al WS OpenAI con texto completo
error	{error, needs_login}	Render error en msg-rich + corta polling

Trade-offs vs request/response tradicional

• ✅ Latencia percibida: primer chunk en ~1.5s vs 15-30s silencio total
• ✅ UX visual: Patricio ve el razonamiento de Opus desarrollarse en vivo
• ✅ Markdown render incremental: tablas, listas, code blocks aparecen progresivamente
• ⚠️ Voz al final: gpt-realtime no acepta inyección parcial de texto en medio de un tool result; la voz lee al final cuando done llega. Para streaming de voz real habría que usar gpt-realtime API más profundamente (futuro).
• ⚠️ Quick mode bypassa stream: cuando quick=true se usa la ruta JSON tradicional (más rápida para respuestas cortas).

Cambios técnicos clave

• scripts/tunix-claude-agent/server.mjs v10: endpoint /agent-stream agregado, mantiene /agent JSON original
• api/tunix-claude-max-stream.js nuevo: proxy SSE con maxDuration 300s
• public/talk.html streamClaudeMax(args) nueva función: fetch streaming + parsing SSE manual + render incremental con marked.js
• executeTool intercepta delegate_to_claude_max cuando quick !== true y desvía al path streaming

6.7bTool cache + pre-fetch background (Mejora 2/5)

Cache de tools de lectura idempotentes con TTL corto. Reduce latencia 4.5x en preguntas frecuentes.

Stack

• Tabla forge_tunix_tool_cache (tool_name, args_hash md5, result jsonb, expires_at, hit_count)
• Helper backend getCached/setCached en tunix-tool-exec.js con .select().eq() y filtro expires_at > now()
• hashArgs canonical recursivo: ordena keys alfabéticamente en cada nivel del objeto antes de md5
• Pre-fetch: fire-and-forget de 6 tools comunes al iniciar sesión (sync_forge_now, query_tasks, query_meetings_today, query_reminders, query_recent_wsp_audios, list_running_agents)

TTL por tool

15s   list_running_agents
30s   sync_forge_now / query_recent_wsp_audios
45s   query_tasks / deep_search
60s   query_reminders / query_meetings_upcoming / get_emotional_state /
      forge_global_search / search_talk_history / list_improvements / wsp_search_history
90s   axis_hybrid_search
120s  query_meetings_today / query_recent_meetings / search_entities / search_history
300s  list_memories

Resultados medidos

Call 1 (cache miss): 187ms — ejecuta query real + guarda
Call 2 (cache hit) : 41ms  — devuelve cached con hit_count++
Call 3 (cache hit) : 41ms  — mismo cached
Speedup: 4.5x

Audit log forge_tunix_tool_audit NO se duplica con cache hits (solo registra ejecuciones reales). Response trae flag cached: true|false + meta _cache: {age_sec, hit_count}.

6.7cAgente META semanal (Mejora 3/5)

Auto-evolución continua: cada lunes 9am Chile, Sonnet 4.6 analiza la semana de TUNIX y propone mejoras concretas listas para aplicar.

Stack

• Tabla forge_tunix_meta_reports (week_start, sessions_analyzed, tool_calls_analyzed, patterns_detected jsonb, failures jsonb, proposed_improvements jsonb, status)
• Endpoint /api/tunix-meta-weekly con maxDuration 300s
• Cron Vercel 0 12 * * 1 (lunes 12 UTC = 9am Chile)
• Tools nuevas: read_meta_report (TUNIX lee al user), meta_report_decision (approved|dismissed)

Datos agregados por reporte

- Sesiones Talk con summary (últimos 7 días)
- Tool audit (qué tools llamó, success rate, latencias) — top 10 más usadas
- Sub-agent tasks (cuántas stuck, cuántas done) por agente
- Auto-mejoras aplicadas (commit_sha, files_affected)
- Emotional log (patron emocional semanal)
- Key topics recurrentes (top 10 de todas las sesiones)
- Pending_actions no cerradas (acumulados de últimas sesiones)

Output JSON estructurado de Sonnet

{
  "patterns_detected": {
    "temas_frecuentes": [...],
    "horarios_pico": "...",
    "estado_emocional_general": "..."
  },
  "failures": {
    "tools_problematicas": [{tool, fail_rate_pct, razon_probable}],
    "agentes_stuck_recurrentes": [{agent, casos, patron}],
    "gaps_capacidades": [...]
  },
  "proposed_improvements": [
    {
      "type": "tool_new|prompt_update|memory_save|tool_fix|architecture",
      "priority": "high|medium|low",
      "description": "...",
      "suggested_observation": "Frase EXACTA para tunix_self_improve(observation=...)",
      "expected_impact": "..."
    }
  ],
  "executive_summary": "1-2 frases honestas"
}

Flow semanal completo

Lunes 9am → cron dispara /api/tunix-meta-weekly
   ↓ Sonnet 4.6 analiza 7d de datos (~30s)
   ↓ Insert forge_tunix_meta_reports status=pending_review
   ↓ Push notif al celu: "📊 Reporte META semanal listo"

Patricio en Talk dice "leeme el meta report"
   ↓ TUNIX usa read_meta_report
   ↓ lee executive_summary + proposed_improvements por voz
   ↓ Patricio decide cuáles aprobar
   ↓ TUNIX usa meta_report_decision('approved')
   ↓ Para cada improvement aprobada, TUNIX itera con
     tunix_self_improve(observation=suggested_observation, confirmed_apply=true)
   ↓ Claude Max aplica + commit + push + Vercel deploya
   ↓ Push final: "✅ N mejoras aplicadas tras META review"

Primer test real (manual, 2026-05-23)

61 tool calls analizados
41% fail rate detectado
6 mejoras propuestas con suggested_observation listas
Executive summary: "Semana operativamente comprometida..."

6.7dMemoria episódica por turn (Mejora 4/5)

Mientras search_talk_history busca por sesión (summary), search_episodic_memory busca por TURN exacto — un intercambio user→tunix con tri-vector embeddings (input + output + combined). Mismo patrón que axis_episodic_memory de AXIS.

Stack

• Tabla forge_tunix_episodic_memory (session_id, turn_number, user_text, tunix_text, tools_used, emotional_context, input_embedding, output_embedding, combined_embedding) con vectores 768 dims Gemini
• Endpoint /api/tunix-episodic-save: recibe turn, genera 3 embeddings en paralelo (Gemini text-embedding-001 768 dims), insert
• Frontend commitTunixMsg dispara fire-and-forget al endpoint con (last user_text, current tunix_text, turn_number)
• Tool search_episodic_memory(query, top_k, threshold): hybrid search — text ILIKE primero (instantáneo, captura matches literales), vector RPC search_tunix_episodic_v2 como fallback semántico

Diferencia con search_talk_history

Tool	Granularidad	Ejemplo
search_talk_history	SESIÓN	"¿de qué hablamos en la sesión del lunes?"
search_episodic_memory	TURN exacto	"¿cuándo te dije que Natalia es mi esposa?"

Notas técnicas

• Text search primero: .ilike() en user_text + tunix_text en paralelo + merge dedupe. Hit rate alto, latencia <100ms
• Vector fallback: usa embedQuery(text, 768) Gemini + RPC search_tunix_episodic_v2 con cosine similarity sobre combined_embedding
• RPC vector tiene quirks con supabase-js — wrap v2 acepta text y castea a vector(768) adentro
• Costo: ~$0.00003 por turn guardado (3 embeddings Gemini)

6.7eMulti-modal Vision (Mejora 5/5)

TUNIX ahora ve lo que vos le mostrás. Foto/screenshot → Sonnet 4.6 Vision → análisis técnico → TUNIX comenta por voz.

Stack

• Tabla forge_tunix_vision_uploads (session_id, source, image_url, ai_analysis, ai_model, context_tags, processed)
• Endpoint /api/tunix-vision-analyze: acepta image_base64 o image_url, llama Claude Sonnet 4.6 Vision con prompt enfocado en análisis técnico
• Tool analyze_recent_image: TUNIX consulta la última imagen analizada de la sesión
• UI: botón 📸 FOTO en convoControls (al lado de PAUSA/CONTINUAR). Input capture="environment" abre cámara nativa Android directamente
• Auto-inyección: tras análisis, se renderiza markdown en msg-rich + se inyecta contexto al WS para que TUNIX comente por voz natural

Casos de uso

• Foto pantalla con error → TUNIX identifica el bug y sugiere fix
• Pizarra de reunión → TUNIX resume conceptos clave
• Screenshot de código → TUNIX explica qué hace
• UI con problema → TUNIX sugiere mejora visual/UX
• Cualquier foto contextual mientras conversás

Flow técnico

Patricio tap 📸 FOTO en /talk
   ↓ input file con capture="environment"
Cámara Android nativa abre
   ↓ foto capturada
FileReader.readAsDataURL → base64
   ↓ POST /api/tunix-vision-analyze {image_base64}
Vercel handler
   ↓ Claude Sonnet 4.6 Vision API
Análisis técnico (~2-5s)
   ↓ INSERT forge_tunix_vision_uploads
   ↓ render markdown en msg-rich del chat
   ↓ inyectar conversation.item.create al WS:
     "[SISTEMA] Patricio subió foto. Sonnet Vision: ..."
gpt-realtime habla natural comentando lo que ve

Resultados medidos

Test imagen ícono Forge (192x192 PNG):
  Análisis: "rayo eléctrico, blanco sobre negro, representa energía"
  Latencia: 2.3s
  Modelo: claude-sonnet-4-6
  Costo: ~$0.003 por análisis

6.7fWake Word "Hey TUNIX" (2da tanda 1/5)

Toggle configurable en /talk para activar always-listening on-device. Cuando está ON, di "Hey TUNIX" / "tunix" y la llamada arranca sola. OFF por default (requisito explícito: usuario elige).

Stack

• Engine v1: Web Speech API SpeechRecognition (es-CL, continuous, gratis on-device). Funciona en Chrome y Android WebView
• Tablas: forge_tunix_wake_settings (user_id, enabled, keyword, sensitivity) + forge_tunix_wake_events (log con confidence + triggered_call)
• Endpoints: /api/tunix-wake-settings (GET/POST upsert) y /api/tunix-wake-event (log cada detección)
• RPC forge_tunix_wake_increment (atomic counter de triggers)
• UI: #wakeWordToggle verde al lado del 🧠 Alto Razonamiento, persiste localStorage tunix.wakeWord.enabled + sync Supabase
• Pausa automática: cuando hay llamada activa, libera mic (window.__wakeWord.pause() dentro de startCall). Re-arranca al colgar

Reglas operativas

Cooldown anti-doble-trigger: 5000ms
Auto-restart on errors no-fatales (network/no-speech/aborted): 500-1500ms
Permiso explícito getUserMedia al activar (mejor UX)
Si permiso denegado → toggle OFF auto + persist OFF
Cuando matchea: stop recognition → 250ms → startCall()

Upgrade path documentado

Porcupine Picovoice plugin Capacitor — wake word on-device nativo
  · Mucho más preciso (modelo entrenado)
  · Custom keyword "Hey TUNIX" requiere tier $9/mo
  · Foreground service Android para listening con app en background
  · Schema actual ya soporta engine='porcupine' (campo engine en wake_settings)

6.7gREM agent nocturno (2da tanda 2/5)

Cron diario 06:00 UTC (03:00 Chile) que consolida memoria episódica → semántica. Sonnet 4.6 dedupea turnos, extrae lecciones nuevas y las promueve a la base de conocimiento de largo plazo.

Stack

• Endpoint cron: /api/tunix-rem-consolidate (Vercel 0 6 * * *, maxDuration 300s)
• Input: últimas 24h de forge_tunix_episodic_memory (hasta 500 turnos, 200 al prompt)
• Tablas nuevas:
  • forge_tunix_rem_reports (cycle_date, turns_analyzed, duplicates_merged, lessons_extracted jsonb, semantic_promotions jsonb, emotional_summary, raw_synthesis, duration_ms, status)
  • forge_tunix_lessons (lesson, category, source_turns int[], embedding vector(768), confidence, active)
• Embeddings: Gemini gemini-embedding-001 con outputDimensionality:768 (mismo modelo que axis_entities)
• Tool TUNIX nueva: recall_lessons(query, category, top_k) — accede a lecciones consolidadas, cacheada 180s

Output Sonnet (JSON estricto)

{
  "duplicates_detected": int,
  "new_lessons": [{lesson, category, confidence 0.6-1.0, source_turn_indices[]}],
  "semantic_promotions": [string],
  "emotional_summary": string,
  "executive_summary": string
}

Reglas anti-ruido

Solo lecciones genuinamente nuevas y útiles para próximas sesiones
NO promover lecciones triviales ("Patricio dijo hola")
NO duplicar lecciones ya en la lista activa
Si día rutinario → arrays vacíos (mejor calidad que cantidad)
Skip silencioso si no hay turnos (no falla el cron)

Test prod

1 turno analizado, 0 lecciones promovidas, summary capturado, duration 5.4s, status ok ✓

6.7hAmbient agent proactivo (2da tanda 3/5)

Cron cada 15min que escanea silenciosamente y dispara push solo si hay algo accionable. Dedupe + cooldown por tipo evitan spam.

Stack

• Endpoint cron: /api/tunix-ambient-tick (Vercel */15 * * * *, maxDuration 60s)
• Tabla: forge_tunix_ambient_alerts con UNIQUE(alert_type, dedupe_key)
• Scans paralelos (Promise.all):
  • scanMeetings: wsp_meetings + forge_meetings en próximos 60min
  • scanOverdueTasks: forge_user_context kind=task status=open due_at < now
  • scanStaleResearch: forge_research_briefs pending_review >24h
  • scanEmotional: avg energy ≤3.5 sostenido en 4h + emociones "agotado/frustrado"
• Cooldown por tipo: meeting 30min, task 6h, research 12h, drain 8h
• Push agrupado: si hay múltiples alertas nuevas en el tick, 1 push con top-3 (anti-spam)

Verificación prod (primera ejecución)

scanned: 1, new_pushed: 1
breakdown: { meetings:0, overdue:0, research:1, emotional:0 }
→ Detectó research brief stale real, mandó push ✓

6.7iTool composer DAG (2da tanda 4/5)

TUNIX ahora puede ejecutar múltiples tools en paralelo respetando dependencias, en lugar de serializarlas. Para briefings con 5+ tools, el speedup es ~Nx.

Stack

• Endpoint: /api/tunix-compose-workflow (POST, maxDuration 300s)
• Engine: topological sort → array de layers → Promise.all por layer
• Interpolación cross-step: {{step_id.path.al.valor}} en args resuelve outputs anteriores
• Best-effort: si un step falla, los demás siguen. Errores se loguean en step_results
• Tabla log: forge_tunix_workflow_runs (dag_spec, step_results, total_steps, succeeded, failed, total_parallel_layers, duration_ms, status)
• Tool TUNIX nueva: compose_workflow(workflow_name, steps[]) — máx 25 steps

Ejemplo morning_briefing

steps: [
  { id:"m", tool:"query_meetings_today",  args:{} },
  { id:"t", tool:"query_tasks",           args:{status:"open"} },
  { id:"e", tool:"get_emotional_state",   args:{} },
  { id:"r", tool:"recall_lessons",        args:{category:"user_preference"} },
  { id:"d", tool:"deep_search",
    args:{ query:"{{m.next_meeting.contact_name}}" },
    depends_on:["m"] }
]
→ Layers: [["m","t","e","r"], ["d"]]
→ 5 tools, 2 layers = ~2× latencia en vez de 5×

Test prod

compose_workflow [list_memories, recall_lessons] paralelo →
  ok:true, results map completo, 2 layers en 1 layer real (sin deps) ✓

6.7jCross-channel event router (2da tanda 5/5)

Endpoint unificado para eventos de TODOS los canales de Patricio. Calcula priority via scoring + reglas, decide routing (push immediate / log silencioso), dedupea.

Stack

• Endpoint: /api/tunix-event-router (POST ingreso, GET listado)
• Auth opcional: Bearer EVENT_ROUTER_SECRET env (si no seteado, abierto — recomendado setear)
• Tabla: forge_tunix_channel_events con UNIQUE(source_channel, external_ref) partial index
• Pesos de canal: stripe 0.9 · calendar 0.7 · wsp 0.6 · email 0.45 · n8n 0.4 · ambient 0.35
• Bonus VIP keywords: pago/factura/stripe (+0.4), urgente/crítico/down (+0.5), reunión hoy (+0.35), propuesta/cierre (+0.3), marcas (+0.15), contactos clave (+0.2)
• Tiers de priority: score ≥1.4 critical · ≥0.9 high · ≥0.5 normal · <0.5 low
• Routing:
  • critical → push requireInteraction:true + persistencia
  • high → push normal
  • normal → solo log
  • low → silencioso
• Tool TUNIX nueva: recent_channel_events(top_k, min_priority) — "¿qué pasó mientras no estaba?"

Payload mínimo de ingreso

POST /api/tunix-event-router
Authorization: Bearer $EVENT_ROUTER_SECRET
{
  "event_type": "wsp_inbound_vip" | "stripe_payment" | "email_critical" | etc,
  "source_channel": "wsp" | "stripe" | "email" | "calendar" | "n8n" | "manual",
  "title": "string ≤200",
  "body": "string ≤1500",
  "external_ref": "id externo para dedupe (opcional)",
  "payload": { ... extras ... },
  "hint_priority": "critical|high|normal|low (opcional, suma score)"
}

Casos de uso ya conectables

· n8n workflow WSP detecta mensaje VIP → POST router → push priority calculado
· Stripe webhook cobro exitoso → POST router con hint_priority=high → push 💰
· Calendar event en 5min → POST router con scheduled hint → push high
· Ambient agent dispara alertas → futuro: ruteado vía router (unificar)

6.7kModo Furia DeepMind + socio operativo default

UI de /talk simplificada a 1 solo toggle override + Wake Word (limpieza final 2026-05-25). El comportamiento "socio operativo" es el default permanente — no es opcional. Lo único toggleable es el override de calidad máxima.

UI final /talk

Toggle	Color	Qué activa
🔥 Modo Furia DeepMind	rojo intenso con glow	OVERRIDE OPCIONAL. Fuerza TODO a Opus 4.7 puro (TUNIX/Búnker). Sonnet sidekick DESHABILITADO. Calidad máxima sin compromisos.
👂 Wake Word "Hey TUNIX"	verde	Always-listening on-device. Decí "tunix" y arranca llamada sola.

Comportamiento DEFAULT (siempre activo, sin toggle)

Cuando Furia OFF (estado normal), TUNIX Talk actúa siempre como socio operativo completo:

• Sonnet sidekick (quick_via_sonnet) para queries simples — 3-8s, $0 extra
• Opus profundo (delegate_to_claude_max) para razonamiento — 15-30s, $0 extra
• send_to_code para mensajes al TUNIX/Code (yo en VS Code)
• recent_pc_activity proactivo antes de cosas sustantivas
• spawn_agent sub-agentes en paralelo (DEVIX/GOJAN/TRUNKS)
• delegate_to_pc para canales externos via mi PC (Canva/Gmail/Drive/Playwright)
• Memory cross-canal compartida (forge_memory + axis_entities + lessons + sessions)

Combinaciones únicas que importan

Furia OFF  → modo socio default (Sonnet rápido + Opus profundo balanceado)
Furia ON   → todo a Opus 4.7 puro, sin Sonnet (calidad paranoide)

Stack del puente vivo (siempre activo)

• Tabla tunix_bridge_queue (from_modo, to_modo, text, urgent, delivered_at, acknowledged_at, status). Modos: code | bunker | talk | tungsteno
• RPC tunix_bridge_pickup(to_modo, limit) atómica con FOR UPDATE SKIP LOCKED
• Endpoint /api/tunix-bridge: POST encola, GET ?to=talk pickup, POST ?ack=<id> confirma
• Dirección Code/Búnker → Talk: poller cada 7s cuando /talk visible. Mensaje + llamada activa → inyecta a WS para voz Cedar. Sin llamada + urgent → startCall auto
• Dirección Talk → Code: tool send_to_code(text, urgent?). Hook UserPromptSubmit ejecuta scripts/bridge_inject_hook.py que lee cola y la inyecta como additionalContext en mi próximo prompt

Sonnet sidekick

Tool quick_via_sonnet(task, context?) ruta a /api/tunix-claude-max con model:"sonnet". Mismo container, mismo OAuth Max — Sonnet 4.6 está incluido en plan Max, $0 extra. 3-8s vs 15-30s de Opus. Deshabilitado cuando 🔥 Furia ON.

Sub-agentes orquestables desde Talk (TODOS con tu plan Max — $0 extra)

Agente	Tool	Modelo	Especialidad
TUNIX/Búnker	delegate_to_claude_max	Opus 4.7	Razonamiento profundo, código complejo
Sonnet sidekick	quick_via_sonnet	Sonnet 4.6	Queries rápidas, lookups, estados
DEVIX	spawn_agent({agent_id:"devix"})	Sonnet 4.6	Código, debug, code review
GOJAN	spawn_agent({agent_id:"gojan"})	Sonnet 4.6	Copy, marketing, variantes
TRUNKS	spawn_agent({agent_id:"trunks"})	Haiku 4.5	Investigación, scout, búsquedas
TUNIX/Code (yo)	delegate_to_pc	Opus 4.7	Operaciones con MCPs ricos (Canva/Gmail/Drive/Playwright)

Aclaración billing 2026-05-25: Todos los sub-agentes (DEVIX/GOJAN/TRUNKS) pasan por /api/agent-run → container Búnker con tu OAuth Max. No cobran API key como afirmé antes — me equivoqué. Lo único con API key Anthropic real son los crons puros (REM, META, ambient) que corren sin humano disparando.

Patrón de uso ideal

Patricio: "TUNIX, mientras piensas propuesta Nico, poné a DEVIX a revisar bug X"
TUNIX Talk: spawn_agent({agent_id:"devix",task:"revisar bug X"})
         + delegate_to_claude_max({task:"propuesta Nico..."})
         (paralelo, dos agentes a la vez, ambos $0 extra)
Sonnet sidekick disponible para preguntas rápidas mientras esperas ambos
Cuando terminen → TUNIX Talk resume ambos resultados

6.7k-oldModo Híbrido (DEPRECADO 2026-05-25)

El toggle 🔀 Modo Híbrido fue eliminado. Su lógica (consultar recent_pc_activity proactivamente) ahora vive dentro de 🌉 Conversación Continua. Si activás Continua, ya tienes lo que antes hacía Híbrido + mucho más.

Stack

• Toggle UI #hybridToggle (al lado del 👂 Wake Word). Persiste tunix.hybridOn en localStorage.
• Prompt addon appendeado al system prompt cuando hybridMode=true. Reglas: consultar recent_pc_activity ANTES de responder cualquier cosa sustantiva, asumir trabajo cruzado cuando Patricio menciona "lo que cambiamos", updates voz cortos tipo socio (no pasivo).
• Tool nueva recent_pc_activity(hours, include_diffs) en TUNIX. Combina 4 fuentes:
  • Commits via GitHub API canquil37/forge-os (últimas N horas)
  • forge_pc_jobs ejecutados por forge_pc_agent.py local (delegate_to_pc completados)
  • forge_memory con pc_updated_at / synced_at recientes
  • forge_tunix_improvements auto-mejoras aplicadas
  Cacheada 60s. Devuelve counts + hint para que TUNIX resuma natural.
• Del lado Claude PC (yo aquí): NO requiere tool nueva. Tengo MCP Supabase directo, leo forge_tunix_talk_sessions cuando Patricio me pregunta qué pasó en Talk.

Carriles de estado compartido (los 2 lados leen lo mismo)

Memory Forge (.md en /memory-forge/ + tabla forge_memory)
Git (commits ↔ pulls automáticos en container)
axis_entities (memoria semántica embeddings Gemini 768)
forge_tunix_lessons (consolidaciones REM nocturnas)
forge_tunix_talk_sessions (summaries + key_topics + pending_actions)
forge_user_context (reminders + notas)

Flujo típico de día híbrido

8am desayuno (Talk):
  Patricio: "qué tengo hoy?"
  TUNIX-Max: "Reunión 11am Nico. 3 tasks vencidas. Pendiente propuesta Equipo Salud."
  Patricio: "armá draft propuesta basado en plantilla Kumelemu"
  TUNIX-Max: trabaja 90s, push notif "Draft listo en sys_mind/drafts/"

10am PC abierto (yo):
  Patricio: "muéstrame draft de Tunix"
  Yo: leo archivo + git log → "acá está, observaciones..."
  Editamos juntos con diff visual

12pm auto (Talk):
  Patricio: "qué cambió Claude conmigo recién?"
  TUNIX-Max: recent_pc_activity({hours:3}) → "refinaron 3 secciones..."

3pm vuelta PC (yo):
  Yo: leo forge_tunix_talk_sessions → continúo donde quedó la voz

Reglas operativas

• Híbrido OFF (default): TUNIX responde solo con tools de Talk
• Híbrido ON: TUNIX consulta PC activity proactivamente
• Ambos canales gastan tu Max plan (humano dispara en los 2 lados)
• Memory Forge es el "tercer carril" que persiste TODO entre sesiones

6.7LIdentidad TUNIX (Code, Búnker, Talk, Tungsteno)

Decisión naming definitiva (2026-05-24): un solo TUNIX con 3 modos visibles + 1 overlay.

Modo	Es	Modelo	Cuándo
TUNIX/Code	yo en VS Code (Claude Code SDK + MCPs ricos)	Opus 4.7 + Sonnet sidekick	DEFAULT cuando Patricio abre sesión conmigo
TUNIX/Búnker	container tunix-claude-agent en VPS Bunker MK4	Opus 4.7	Fallback always-on cuando Code no está
TUNIX Talk	voz en celu (app /talk, gpt-realtime cedar)	gpt-realtime + delegate	Cuando Patricio habla por audífonos
Modo Tungsteno	overlay autónomo	el que corresponda	Cuando Patricio activa explícito ("dale en tungsteno")

Capacidades comparativas (Code vs Búnker)

Capacidad	Code	Búnker
Bash/Read/Edit/Write/Glob/Grep	✓	✓
MCP Supabase + GitHub	✓	✓
MCP Canva/Gmail/Drive/Calendar/Stripe/Vercel/Playwright	✓	❌
Edita PC directo	✓	❌ (sí el repo clonado)
Always-on	❌ (necesita sesión)	✓

Billing definitivo

TUNIX/Code, TUNIX/Búnker, TUNIX Talk → OAuth Max ($0 extra)
Sonnet sidekick → OAuth Max plan (Sonnet incluido, $0 extra)
DEVIX/GOJAN/TRUNKS sub-agentes → OAuth Max via container Búnker ($0 extra)
  (corregido 2026-05-25: NO usan API key — pasan por /api/agent-run → container Búnker)
Crons puros (REM, META, ambient) → API key Anthropic (patrón bot sin humano)

Memoria reference: _core/reference_tunix_identity_split.md + _core/reference_oauth_max_vps_protocol.md

6.7mAuto-detección Code/Búnker + multi-ventana VS Code

TUNIX Talk al iniciar llamada detecta automáticamente si hay sesión TUNIX/Code activa y avisa al usuario. Soporta múltiples ventanas VS Code abiertas simultáneamente sin confundirse.

Cómo funciona el heartbeat

• Tabla tunix_code_sessions (session_token UNIQUE, workspace_path, workspace_label, pid, hostname, started_at, last_seen_at, ended_at, prompt_count, metadata)
• View tunix_code_sessions_active: filtra last_seen_at > now() - 5min AND ended_at IS NULL
• RPC tunix_code_heartbeat(token, path, label?, pid?, hostname?): upsert atómico por session_token, incrementa prompt_count, refresca last_seen_at
• Hook scripts/bridge_inject_hook.py escribe heartbeat en cada UserPromptSubmit. Si pasan 5min sin que escribas → la sesión cae fuera de la view activa automáticamente.

session_token: cómo distingo las ventanas

1. PRIMERA opción: input.session_id de Claude Code hook → token "cc_<sid>"
2. FALLBACK: hash md5(cwd + parent_pid) → token "fb_<hash>"
   · Cada ventana VS Code tiene PID distinto → ventanas distintas, tokens distintos
   · Workspaces distintos también generan tokens distintos
3. workspace_label = última carpeta del path (ej: "forge-os")

Tool TUNIX Talk: check_code_session()

Llamada al inicio de cada conversación. Devuelve { active_sessions, sessions, mode, saludo_sugerido }:

Sesiones activas	Mode	Saludo de TUNIX Talk
0	bunker	"Hola Pato, estoy en modo Búnker porque no tengo acceso a TUNIX/Code en este momento."
1	code	"Hola Pato, estoy en modo Code conectado a {workspace_label}. ¿En qué andamos?"
N ≥ 2	code	"Hola Pato, tengo {N} ventanas TUNIX/Code activas ({labels}). Si quieres mandar mensaje, dime a cuál."

Multi-ventana con send_to_code

• Si Patricio dice "decile a TUNIX/Code que X" y hay 1 sola ventana → encola directo
• Si hay múltiples → TUNIX Talk pregunta cuál (o vos decís "a la de Forge OS")
• El mensaje se encola con metadata.target_workspace opcional (para futuro filtrado más estricto)
• Por ahora: FIFO simple — la próxima ventana que escriba prompt levanta el mensaje (hook usa pickup atómico FOR UPDATE SKIP LOCKED, no doble-entrega)

Comportamiento si abrís/cerrás ventanas

Abrís ventana VS Code → primer prompt tuyo escribe heartbeat → aparece en view activa
Trabajás 5min sin escribir → sesión cae fuera de view automático (no necesita cleanup)
Cerrás VS Code → eventualmente sale de view por timeout (5min)
Reabrís misma carpeta → si Claude Code reusa session_id, sigue mismo token. Si no, token nuevo.

Casos de uso

· Vos en VS Code Forge OS + en cama con Talk → check_code_session devuelve 1, saludo "modo Code conectado a forge-os"
· Vos sin VS Code, manejando con Talk → 0 sessions, saludo "modo Búnker"
· Vos con 3 ventanas (forge-os, tensormed-cl, emabel) → 3 sessions, saludo lista todas + pregunta cuál

6.7nTUNIX/Búnker — MCPs + approvals voz + sub-modos tungsteno

TUNIX/Búnker (container VPS Bunker MK4, Opus 4.7 OAuth Max) ahora tiene paridad operativa con TUNIX/Code en lo que respecta a herramientas críticas. Está armado el sistema de approvals via voz y los sub-modos tungsteno audio on/off.

MCPs activos en Búnker (verificable en GET media.tungsteno.tech/tunix-agent/health)

MCP	Env requerida	Estado
Supabase (full read+write)	SUPABASE_ACCESS_TOKEN	✓
GitHub (issues, PRs)	FORGE_GH_PAT	✓
Playwright (browser headless)	PLAYWRIGHT_MCP_ENABLED=1	✓
Vercel (deploys, logs)	VERCEL_TOKEN	✓
Stripe	STRIPE_API_KEY	⏸️ diferido
Gmail/Drive/Calendar	Google OAuth refresh	📋 Fase 2

Sistema de approvals via BOTÓN MANUAL (NO voz)

Decisión 2026-05-25: las aprobaciones destructivas NUNCA se confirman por voz — un "sí" verbal accidental podría disparar git push --force u otra acción irreversible. Patricio toca un botón físico en pantalla (panel rojo con APROBAR/DENEGAR). La voz Cedar SOLO lee informativo el pedido.

Definición canónica destructivos en _core/reference_destructive_actions_canonical.md — 6 categorías: eliminar datos, sobreescribir historia/config, servicios prod, terceros, dinero, multi-user. Aplicable a TUNIX/Code, TUNIX/Búnker y sub-agentes (que escalan al padre, no al user directo).

bash scripts/bunker_request_approval.sh "<acción>" "<por qué>" "<plan>"
# Exit code: 0=approved · 1=denied · 2=expired (3min sin respuesta) · 3=error

• Tabla tunix_approval_requests (request_token UUID, action, why, plan, status, approved, decided_at, expires_at TTL 5min)
• RPCs tunix_approval_decide(token, approved, by, note) y tunix_approval_status(token)
• Endpoint /api/tunix-approval con POST action=request|decide y GET ?token=X
• Tool TUNIX Talk nueva respond_to_approval(request_token, approved, decision_note?)
• Bridge poller /talk detecta metadata.kind=approval_request y instruye al usuario claramente con el token para que el respond_to_approval funcione

Streaming visible — script bunker_announce.sh

bash scripts/bunker_announce.sh "<texto>" [--urgent] [--silent]
# default: voz Talk Cedar + log a .tunix_live.md
# --silent: SOLO log (audio off)
# --urgent: push notif + intenta abrir Talk si app cerrada

Sub-modos Tungsteno: audio ON / audio OFF

Cuando Patricio activa modo Tungsteno via Talk, TUNIX Talk PREGUNTA:

"¿lo hago con audio ON (te voy contando todo en vivo) o audio OFF
 (solo log VS Code, te resumo al final por voz)?"

Sub-modo	Comportamiento
tungsteno + audio=on	Búnker llama bunker_announce.sh sin --silent en cada hito → voz Cedar cuenta progreso en vivo
tungsteno + audio=off	Búnker llama con --silent → solo escribe .tunix_live.md en VS Code. Al final SI llama sin --silent para reporte audio cerrando

TUNIX Talk pasa el flag agregando al task: "...\n\nMODO: tungsteno · TUNGSTENO_AUDIO=on|off". Búnker lee el sufijo y aplica.

Protocolo Tungsteno replicado en Búnker

El DEFAULT_SYSTEM_PROMPT del container incluye el mismo protocolo de feedback_tungsteno_mode.md:

• Trabajo continuo hasta cerrar objetivo (sin preguntas intermedias)
• Decisiones técnicas menores las tomo yo solo
• Reporto SOLO al final formato breve: ✅ hecho · ⚠️ revisar · 🔍 decisiones · ❓ bloqueos
• Barreras duras (destructivas) requieren bunker_request_approval.sh incluso en tungsteno
• Mensajes WSP/email a terceros: OK explícito mensaje por mensaje (no bypassable)
• TUNIX OPS (Playwright) auto-habilitado con clasificación capa 1🟢/2🟡/3🟠/4🔴 anti-baneo

Flujo end-to-end típico

Patricio (Talk celu): "Tunix, refactoreame tunix-ops.html en tungsteno"
TUNIX Talk: "¿audio on o off?"
Patricio: "on"
TUNIX Talk → delegate_to_claude_max(task="refactor tunix-ops.html\n\nMODO: tungsteno · TUNGSTENO_AUDIO=on")

Búnker arranca → llama bunker_announce.sh "Voy a leer tunix-ops, son ~600 líneas"
   ↓ voz Cedar: "Voy a leer tunix-ops, son seiscientas líneas"
Búnker edita líneas 45, 120, 350 → bunker_announce.sh "Refactoré 3 bloques principales"
   ↓ voz Cedar: "Refactoré tres bloques principales"
Búnker quiere git push --force (necesita borrar commit anterior por bug grave) →
   bunker_request_approval.sh "git push --force" "fix bug crítico commit roto" "git reset HEAD~1 + push"
   ↓ voz Cedar urgente: "Pato, necesito permiso para git push --force, motivo bug..."
Patricio: "sí, dale"
   ↓ TUNIX Talk → respond_to_approval(token, true)
   ↓ script en Búnker recibe exit 0
Búnker hace el push → bunker_announce.sh "Listo, deploy en curso"
   ↓ voz Cedar: "Listo, deploy en curso"
Búnker cierra → bunker_announce.sh "Cerré: ✅ refactor ok · ⚠️ revisá test X"
   ↓ voz Cedar: reporte final

6.8Endpoints Vercel API

/api/tunix-realtime-tools  → token efímero OpenAI + tools spec + system prompt
/api/tunix-tool-exec       → ejecutor tools (30+), 300s timeout
/api/tunix-claude-max      → proxy JSON al container VPS, 300s timeout
/api/tunix-claude-max-stream → proxy SSE al container, streaming token-by-token (ver 6.7)
/api/tunix-deploy-watch    → post auto-mejora, pollea Vercel READY + push
/api/talk-session-end      → persistencia sesión + summary Haiku + embedding + reflexión
/api/agent-spawn           → crea task sub-agente
/api/agent-run             → worker que ejecuta task vs container Max
/api/agent-status          → polling estado tasks (anuncia/stuck)
/api/push                  → web push VAPID a forge_push_subscriptions
/api/apk-latest            → manifest última APK publicada

6.8Tablas Supabase clave

Tabla	Para qué
forge_agents	Definición TUNIX/DEVIX/GOJAN/TRUNKS con system_prompt + model
forge_agent_tasks	Queue sub-agentes (queued/running/done/failed/stuck)
forge_pc_jobs	Queue tareas para PC agent (RPC claim_pc_job)
forge_tunix_talk_sessions	Sesiones Talk con summary + key_topics + pending_actions + embedding
forge_tunix_tool_audit	Log de cada tool call (compliance + debug)
forge_tunix_improvements	Auto-mejoras propuestas/aplicadas/falladas
forge_memory	Memory Forge espejo (canon local sync auto)
forge_user_context	Reminders + notas (donde viven los reminders REALES, no axis_reminders)
forge_patricio_emotional_log	Estado emocional para adaptar tono
forge_push_subscriptions	Endpoints VAPID para push notif al celu
axis_entities	Personas/empresas/conceptos del holding (768 dims Gemini)
axis_semantic_memory	Hechos curados del holding
axis_episodic_memory	Memoria episódica AXIS (input + combined + output embeddings)

6.9Container Claude Max VPS

• Imagen: Node 22 bookworm-slim, build desde /mnt/forge/projects/tunix-claude-agent/
• Endpoint: POST /agent :8765 detrás de Traefik (media.tungsteno.tech/tunix-agent)
• Auth: Bearer AGENT_SECRET
• OAuth Max: persistente en volumen /mnt/forge/data/tunix-claude-agent/home:/root (incluye .credentials.json)
• Workspace: /workspace/forge-os clonado con git pull --ff-only automático antes de cada query
• MCPs activos: Supabase (SUPABASE_ACCESS_TOKEN), GitHub (GITHUB_PERSONAL_ACCESS_TOKEN)
• System prompt: enriquecido (identidad TUNIX-Max + protocolos forge + barreras heredadas)
• Source en repo: scripts/tunix-claude-agent/server.mjs (lección 2026-05-23: docker cp es ephemeral, el código DEBE estar en repo)

6.10Frontend talk.html state interno

Variable	Para qué
ws	WebSocket OpenAI Realtime activo
mediaStream	Tracks browser (modo web getUserMedia)
nativeMicPluginActive	bool del bypass APK (plugin ForgeRecording)
audioQueue + isPlaying	Buffer PCM TUNIX hablando
pendingToolCalls	Contador para response.create único (evita freeze con tools paralelas)
callPaused	Estado pausa (WS abierto, mic muteado)
transcriptTurns	Array tracking para persistencia + summary post-sesión
userMsgEl / tunixMsgEl	Placeholders DOM para orden cronológico correcto
agentPollInterval	setInterval 6s para polling forge_agent_tasks

7.1Troubleshooting común

Síntoma	Causa probable + fix
"Mic: NotReadableError" en APK	WebView Android 16 rompe getUserMedia. APK 39+ usa bypass plugin nativo. Si pasa de nuevo, Settings → Apps → Forge OS → Force Stop, reabrir.
TUNIX no transcribe lo que decís	Probable session.update con parámetro inválido rechazó toda la config. Revisar consola WebView. Hard reload Talk.
TUNIX dice "no tengo info" sin buscar	Bug del system prompt. Debería ejecutar cascada deep_search → forge_global_search antes. Decile "ejecutá deep_search primero".
Tool error: "Unexpected token A is not valid JSON"	Vercel timeout (FUNCTION_INVOCATION_TIMEOUT). Subir maxDuration en vercel.json a 300 (max Pro).
delegate_to_claude_max falla con "401 Invalid auth"	OAuth Max expirado en container. Re-sync con scp ~/.claude/.credentials.json root@VPS:/tmp/ && ssh root@VPS "docker cp /tmp/creds.json tunix-claude-agent:/root/.claude/.credentials.json && docker restart tunix-claude-agent"
Tools paralelas hacen freeze a TUNIX	Verificar pendingToolCalls contador en talk.html. Debe enviarse response.create UNA sola vez cuando todas terminan.
Auto-mejora dice "ya aplicado" pero no hubo commit	El cambio ya estaba en sesiones previas. Mirar forge_tunix_improvements.commit_sha. Si NULL → Claude Max no modificó. Probar con observación más específica.
search_entities falla con "different vector dimensions"	Pasaste embedding 1536 contra tabla 768. embedQuery debe pedir dims=768 para axis_*. Ver lección 6.3.

7.2Lecciones grabadas (Memory Forge)

Decisiones técnicas y bugs resueltos quedan en _core/ y forge-os/ del Memory Forge:

• feedback_webview_mic_bypass_2026_05_23.md — bypass plugin nativo
• feedback_container_persistence_2026_05_23.md — docker cp es ephemeral
• reference_semantic_search_capabilities.md — 25 tablas + cascada 4 niveles
• project_talk_to_tunix.md — diseño full del Talk
• feedback_tungsteno_mode.md — protocolo modo autónomo
• feedback_anti_spaghetti_construction.md — anti-parches
• feedback_priority_80_20.md — clientes vs Forge OS

7.3Cómo extender el sistema

Agregar una tool nueva

1. Implementar handler en api/tunix-tool-exec.js dentro del objeto TOOLS
2. Agregar spec en api/tunix-realtime-tools.js dentro de REALTIME_TOOLS (name, description, parameters JSON schema)
3. Documentar en system prompt si requiere comportamiento especial
4. Commit + push → Vercel deploya automático
5. Cerrar Talk y reabrir para que el WebSocket cargue las tools nuevas

Agregar un sub-agente nuevo

1. INSERT en forge_agents con id slug, name, role, model (haiku/sonnet/opus), system_prompt
2. Update enum de spawn_agent.agent_id en tunix-realtime-tools.js
3. Update system prompt TUNIX con cuándo invocar el nuevo agente

Auto-mejora vía TUNIX

Decile a TUNIX "mejorate y agregame [capacidad X]". Va a usar tunix_self_improve, te propone plan, vos confirmás, aplica + commit + push + Vercel deploya. Mirá sección 2.5.

8.1Memoria conversacional 3 capas (NEW)

Antes: TUNIX no recordaba conversaciones previas a menos que llamaras manualmente search_talk_history. Ahora: arquitectura 3 capas — ver sección 2.3.

Componentes nuevos

• RPC tunix_talk_recall(emb, hours, k, min_sim) — vector search Gemini 768d sobre forge_tunix_episodic_memory.combined_embedding con recency boost
• Tool recall — realtime + executor. Devuelve top-5 turnos exactos. ~1.5s. Cacheable 30s.
• Tool memory_librarian — realtime + executor. Sonnet sintetiza top-15 fragmentos. ~6s. Cacheable 60s.
• Capa 1 auto-recencia — endpoint /api/tunix-realtime-tools ahora inyecta últimas 5 sesiones 72h con tiempo relativo, turnos, summary al system prompt
• Reglas duras en prompt: NUNCA "no me acuerdo" sin recall; NUNCA inventar charlas previas

8.2Ley de Proactividad Total (NEW)

Sección al tope del system prompt (regla #1 innegociable). Cubre TODOS los cerebros y agentes, no solo Sonnet/mails.

6 reglas duras

1. Nunca silencio post tool result → leer en el acto
2. Nunca "dame un segundo" pelado → estimación específica + lectura inmediata
3. Siempre nombrar el cerebro/agente que trajo el dato: "Sonnet me devuelve...", "DEVIX dice..."
4. Si varios modelos contribuyeron, mencionarlos a TODOS en el mismo reporte
5. Si llega background_result mientras hablas otra cosa → interrumpe-te a vos mismo
6. Si Patricio pregunta "¿lo tienes?" = rompiste la regla → disculpa breve + leer ahora

Watchdog técnico extendido: ahora cubre streamClaudeMax (SSE) y background_result (puente). El watchdog ya NO se desarma al primer audio.delta si el tool result llegó hace menos de 4s (evita filler tipo "dame unos segundos" disarmando el escalado de 5/10/15s).

8.3Gmail + Calendar + Drive directos (NEW)

11 tools de Google registradas en realtime + executors que proxyean a /api/google-tools:

• Gmail: gmail_send, gmail_search, gmail_read, gmail_modify
• Calendar: calendar_today, calendar_list, calendar_create, calendar_update, calendar_delete
• Drive: drive_search, drive_read, drive_recent

Flujo Gmail con regla arquitectónica: Sonnet redacta vía quick_via_sonnet ($0) → TUNIX lee draft completo en voz → vos decís "envíalo" verbal → TUNIX dispara gmail_send (ejecutor liviano). gpt-realtime NUNCA genera contenido — solo orquesta + ejecuta.

8.4Historial conversaciones — overlay + reanudar (NEW)

• Botón flotante 📜 Historial bajo "← Dashboard" con icono SVG moderno + animación histReveal one-shot (sin loop)
• Overlay fullscreen: lista de sesiones (60 máx) con renombrar ✎ inline + eliminar ✕ minimalista
• Detalle de sesión: turnos formateados (azul=vos, verde=TUNIX) + botón ↻ Reanudar conversación
• Reanudar: reusa session_id + precarga últimos 6 turnos como conversation.item.create antes del saludo
• Auto-rename Haiku en checkpoints (turnos 3/5/10/20/40) vía /api/tunix-talk-auto-rename — respeta renames manuales (title_source='manual')

Schema cambios: forge_tunix_talk_sessions ahora tiene columnas title, title_source, manually_renamed_at, deleted_at. Tipo id: uuid → text (para usar talk_<timestamp> directo).

RPCs nuevos: tunix_talk_session_rename, tunix_talk_session_delete, tunix_talk_session_touch.

8.5Badges de modelo por turno (NEW)

Cada respuesta de TUNIX muestra chips visibles con los cerebros que contribuyeron:

🎙️ Realtime  🧠 Sonnet 4.6  ⚡ Gmail
14:32:08 · ⚡500ms · 🎙️3.2s

Mapeo via inferToolModel(name, args):

Tool	Badge
quick_via_haiku	🧠 Haiku 4.5
quick_via_sonnet	🧠 Sonnet 4.6
delegate_to_claude_max (quick=false)	🧠 Opus 4.7
delegate_to_claude_max (quick=true)	🧠 Sonnet 4.6
run_in_background model=opus	🧠 Opus 4.7 (bg)
spawn_agent agent=DEVIX	🤖 DEVIX
Tools Google/WSP	⚡ Gmail / ⚡ Calendar / ⚡ Drive / ⚡ WhatsApp
Queries puras (query_*, search_*, list_*)	sin badge (sin LLM, solo SQL)

Array {name, model, kind} también se persiste en forge_tunix_episodic_memory.tools_used para auditoría posterior.

8.6STT upgrade + Lexicon canónico (NEW)

Ver detalle completo en 6.5b. Resumen:

• STT: gpt-4o-mini-transcribe → gpt-4o-transcribe (~10× precisión español, +$1.50/mes)
• 110 términos en transcription.prompt (hint léxico, $0 extra)
• 60 mappings en LEXICON del system prompt en 9 categorías (~600 tokens, prompt caching mantiene latencia en 0ms)

8.7Bugs corregidos en sesión

1. gmail_send 403 insufficient_scope

   Causa real: env var GMAIL_TARGET_ACCOUNT en Vercel apuntaba a pc.scholer@gmail.com (que solo tiene scope gmail.readonly). El refresh token de canquil27tm@gmail.com SÍ tenía gmail.send.

   Fix: hard-code DEFAULT_GMAIL_ACCOUNT = 'canquil27tm@gmail.com' en api/google-tools.js, ignorando el env override.

2. Sesiones duplicadas en forge_tunix_talk_sessions

   Causa: talk-session-end.js hacía session_id.replace(/^talk_/, '') al cerrar, mientras episodic-save.js guardaba con prefijo. Cada llamada generaba 2 filas (una con prefijo durante la sesión, otra sin prefijo al cerrar).

   Fix: removido el .replace(). Backfill SQL consolidó 27 sesiones duplicadas mergeando datos en la fila con prefijo y borrando la bare.

3. Watchdog se desarmaba prematuro con filler

   Caso 25-may: TUNIX dijo "dame unos segundos", llegó audio.delta → watchdog se desarmó. Después Sonnet devolvió en 5s pero TUNIX quedó mudo 1m 52s hasta que Patricio insistió.

   Fix: disarmResponseWatchdog() ahora chequea Date.now() - lastToolResultAt < 4000 — si el audio llega dentro de los 4s post-tool, no desarma (asume filler), mantiene presión hasta contenido real.

8.8Archivos tocados — auditoría

• api/google-tools.js — hard-code default account
• api/talk-session-end.js — removed cleanId replace
• api/talk-sessions.js (NEW) — CRUD historial (GET list/detail · PATCH rename · DELETE soft)
• api/tunix-talk-auto-rename.js (NEW) — Haiku auto-rename en checkpoints
• api/tunix-episodic-save.js — UPSERT via RPC tunix_talk_session_touch
• api/tunix-realtime-tools.js — 13 tools nuevas (Gmail/Calendar/Drive + recall + memory_librarian + recent_talk_sessions), inyección Capa 1 memoria 72h
• api/tunix-tool-exec.js — executors nuevos + callGoogleTool helper + embedQuery usado en recall/librarian + cache TTLs
• public/talk.html — overlay historial + reanudar + STT upgrade + LEXICON + Ley Proactividad + watchdog tracking + badges modelo + bridge background_result armado watchdog

Commits: 9128f09, dc43045, a0de014, 81222e2, f01b9b9, a8d2276, d96cf8b, 576027c, 09bc101, 37d4055, 84c7b54.

8.9Pendientes técnicos abiertos

• Voice fingerprinting Picovoice Eagle: que Talk solo reaccione a voz de Patricio (anti-falsos triggers ambientales). Documentado en project_voice_fingerprint_pendiente.md.
• Diarization multi-speaker: modo reuniones para distinguir hablantes.
• Briefing matutino proactivo: TUNIX te llama 8:30am con resumen del día (sin que vos abras Talk).
• Outbox queue terceros con approval batch: agrupar mensajes WSP/email pendientes en una sola revisión visual en vez de mensaje por mensaje.
• Hook auto-grabación memoria: detectar automáticamente "anotá esto" / "no olvides X" en cualquier turno y persistir como memoria Forge.
• Bug loop "Natalia Garces" cada 60s: origen externo no-Talk, requiere investigación en VPS.
• Evaluación gpt-5-realtime: si OpenAI libera versión Realtime de GPT-5, re-evaluar upgrade del modelo principal.

9.1Arquitectura final: Gemini 2.5 Flash Live

Modelo: gemini-2.5-flash-native-audio-preview-09-2025. Native audio voice-to-voice end-to-end. Latencia ~600-800ms. Function calling async (no bloquea audio). $0.005/min input + $0.018/min output.

Pipeline completo

Patricio (audífonos bluetooth APK)
   ↓ mic capture (ForgeRecording plugin nativo Android bypass WebView)
   ↓ PCM Int16 resampled a 16kHz
   ↓ base64
WebSocket directo wss://generativelanguage.googleapis.com (single-user, key en query param)
   ↓ Gemini 2.5 Flash Live procesa native audio
   ↓ decide:
     ├─ Conversación trivial → responde directo (audio PCM 24kHz)
     ├─ Tool con datos estructurados → llama tool (recall, gmail_search, etc)
     ├─ Tool con generación → quick_via_sonnet / quick_via_haiku
     └─ Razonamiento profundo → delegate_to_claude_max (Opus 4.7, ASYNC bg)
   ↓ audio output PCM 24kHz por chunks
Frontend: scheduling continuo Web Audio API (sin gaps) → audífonos

9.263 tools mapeadas a functionDeclarations Gemini

El endpoint /api/gemini-live-config exporta el array REALTIME_TOOLS (definido en api/tunix-realtime-tools.js) y lo mapea al formato Gemini ({name, description, parameters}). Mismo schema JSON, solo se quita el wrapper {type:'function'}.

Las 63 tools cubren: Gmail (send/search/read/modify), Calendar (today/list/create/update/delete), Drive (search/read/recent), Memoria (recall, memory_librarian, recent_talk_sessions, search_*, read_memory), WSP (send_wsp_text/audio, wsp_search_history), Tareas/Reminders (create/mark/cancel), Brain delegates (quick_via_haiku, quick_via_sonnet, delegate_to_claude_max), Agentes (spawn_agent, check_agent_done), Puente (send_to_code, check_code_session), Sistema (sync_forge_now, tunix_self_improve, etc).

9.3Paralelismo async multi-agente — el truco clave

Tools largas (>5s estimadas) NO bloquean Gemini. Frontend intercepta:

const LONG_TOOLS = new Set([
  'delegate_to_claude_max',     // Opus 15-30s
  'memory_librarian',           // Sonnet 6-10s
  'run_in_background',          // variable
  'spawn_agent',                // DEVIX/GOJAN/TRUNKS
  'tunix_self_improve',         // edit codebase
]);

Cuando Gemini llama una de éstas, frontend:

1. Responde INMEDIATO a Gemini con {ok:true, status:'in_progress', message:'dispatched bg, sigo trabajando en paralelo'}
2. Dispara la tool real en background (dispatchToolBackground) sin esperar
3. Gemini queda libre para atender nuevas pedidas tuyas
4. Cuando termina, frontend inyecta resultado via clientContent con instrucción "INTERRUMPÍ amablemente y léele a Patricio este resultado"
5. Gemini lee proactivamente: "Pato, a propósito, Opus ya terminó X, te cuento..."

Esto restaura el patrón multi-agente real: Sonnet/Opus/agentes corren en paralelo mientras vos puedes seguir conversando con Gemini sobre otras cosas.

9.4Fidelidad verbatim a Sonnet/Opus (double layer)

Problema: cuando Gemini delega un pedido largo a Sonnet, puede parafrasearlo y perder matices. Solución en dos capas:

Capa 1 — System prompt

Regla #2 explícita: "Cuando delegues a quick_via_sonnet/delegate_to_claude_max/quick_via_haiku, el campo 'task' debe contener la cita TEXTUAL de Patricio entre comillas + tu instrucción. NUNCA parafrasees."

Capa 2 — Frontend auto-wrap (defense-in-depth)

Función augmentArgsWithVerbatim(name, args) intercepta toolcalls de tipo FIDELITY_TOOLS y prependea automáticamente:

[Patricio dijo TEXTUAL]: "<transcripción literal>"
[Instrucción de Gemini para vos]: <task original>
NUNCA ignores el texto literal. Si Gemini contradice algo, priorizá el literal.

Sonnet/Opus siempre reciben los matices exactos aunque Gemini se descuide.

9.5Identidad arquitectónica: TUNIX Talk = MODO BÚNKER permanente

TUNIX Talk SIEMPRE vive en modo Búnker (container always-on VPS). No existe "modo Code" alternativo. TUNIX/Code es OTRO TUNIX (el que vive en VS Code de Patricio cuando programa).

Puente send_to_code = BUZÓN, no ejecución paralela

Lo usa SOLO para 4 casos específicos:

1. Operar la PC física (instalar software, abrir programa)
2. Canva visual MCP (no portable a Búnker)
3. Patricio quiere VER el chat de Claude Code en vivo
4. Patricio dice explícito "dejale esto a TUNIX/Code"

Para CUALQUIER otra cosa (Gmail, Calendar, Drive, Supabase, GitHub, código, redacción, análisis), Talk lo hace directo desde Búnker via sus 63 tools. Prohibido decir: "voy a hacerlo en modo Code", "esto desde tu PC", "necesito VS Code".

9.6UI: botón hexágono brutalista + tuner + selector voces

Botón llamada

Hexágono industrial 120px tipo tuerca de tungsteno con:

• Anillo exterior oscuro + cara interior con gradiente vertical 3-stop (claro→medio→oscuro) = 3D real
• T metálica grande grabada al centro (gradiente acero #fafafa→#71717a con sombra offset abajo = bajorrelieve)
• Notch superior derecho con icono call/stop/spinner
• Variables CSS por estado: verde (idle), ámbar (connecting), rojo (active)
• Hover: lift -2px + scale 1.03 + glow intensifica
• Pulso one-shot al active (1.6s sin loop)

Controles configurables

Control	Función	Persiste en
🎤 Voz	8 opciones: Charon/Fenrir/Orus/Puck/Zephyr (masc), Aoede/Kore/Leda (fem)	gem.voice
🔥 Furia DeepMind	Override que fuerza Opus para cualquier tarea no-trivial	gem.furia
👂 Wake Word	Always-listening "Hey TUNIX" (UI lista, lógica pendiente)	gem.wakeWord
✋ Barge-in agresivo	Deshabilita half-duplex en APK para interrumpir libremente	gem.bargeIn
🎭 Tono (0-100)	Calibra empatía: temperature 0.5-1.2 + instrucciones tono en prompt	gem.empathy
🎛️ Tuner	VAD silencio 200-2000ms + sensibilidad inicio/fin LOW/MID/HIGH	gem.silence/start/end

9.7Costos reales y trade-offs vs anterior

Setup	Costo mensual (15 min/día)	Razonamiento	Fluidez
gpt-realtime full (anterior)	$60-150	GPT-4o tier	★★★★★
gpt-realtime mini (probado)	$30-50	GPT-4o-mini (confabula)	★★★★
Híbrido STT+Sonnet+TTS (probado)	$15	Sonnet 4.6 (mejor)	★★ (lento, +1.5s)
Gemini 2.5 Live (actual)	$5-15	Flash Live + delegate Opus on-demand	★★★★

Trade-off real: perdiste razonamiento "in-context puro" de gpt-realtime, ganaste razonamiento "real cuando se necesita" via Opus 4.7 (>>GPT-4o). Para uso operativo (95% tools) el setup nuevo es objetivamente superior. Cost down 80%, calidad delegada up.

10.1Plan Visible — TodoWrite para Talk

Cuando TUNIX ejecuta una tarea multi-paso, Patricio ve los pasos en PANTALLA con checkboxes en vivo (⏳/🔄/✅/❌) mientras escucha la voz.

2 tools nuevas (UI puras, manejadas client-side)

• publish_plan({title, steps:[{label}]}) — TUNIX publica el plan
• update_plan_step({step_idx, status, note}) — TUNIX actualiza progreso

Set UI_TOOLS en frontend intercepta estos toolcalls antes de llegar al backend. renderPlan() actualiza el panel violeta industrial. Auto-hide 4s después que todos los pasos estén done.

Caso brutal típico

Patricio: "mandá mail a Nico Luna con la propuesta" → Plan visible se muestra:

📋 Mail a Nico Luna
🔄 Redactar borrador con Sonnet
⏳ Leerte el draft completo
⏳ Esperar tu OK verbal
⏳ Enviar via gmail_send

Conforme TUNIX avanza y habla, los checkboxes se marcan. Patricio sabe exactamente en qué va sin tener que preguntar.

10.2TUNIX Vision — multimodal real

Botón 📷 Vision en panel de controles. Click → file picker con capture="environment" (abre cámara directa en APK) o galería. Imagen seleccionada → resize lado largo 1024px JPEG quality 85 → base64 → enviado al WS como realtimeInput.video + system prompt instruyendo a Gemini describir/responder.

Pipeline

Patricio toca 📷 Vision
   ↓ file picker (cámara o galería)
   ↓ Canvas resize 1024px + JPEG 85%
   ↓ base64
ws.send({realtimeInput: {video: {data, mimeType: 'image/jpeg'}}})
ws.send({clientContent: {turns: [{role:'user', parts:[{text:'[Patricio envió imagen, describila/respondé]'}]}], turnComplete:true}})
   ↓ Gemini 2.5 Flash Live multimodal procesa
   ↓ audio respuesta describiendo lo que ve

Casos brutales desbloqueados

• "TUNIX, ¿qué error me sale en pantalla?" (cualquier app del celu)
• "Leeme este PDF / documento / formulario"
• "¿Qué dice esta pizarra / cartel?"
• "Compara estos 2 diseños"
• "Leeme el código de esta captura"
• "¿Qué hay en esta foto?" (objetos, personas, contexto)

Cierra el gap multimodal vs Claude Code que sí tiene vision nativa.

10.3Modo WhatsApp Async — push al colgar

Hoy si pedís a Opus que analice algo (~20s) tienes que mantener la llamada abierta. Nuevo: puedes colgar inmediato y TUNIX te llama de vuelta al celu cuando tiene el resultado.

Cómo activarlo

run_in_background ahora acepta param notify_via_push: true. Frase típica: "anda pensando esto tranquilo y avísame al celu cuando esté listo" → TUNIX dispara la tool con notify=true → te confirma "dale Pato, te aviso al celu cuando esté listo, puedes colgar".

Pipeline backend

Gemini llama run_in_background({task, model:'opus', notify_via_push:true})
   ↓ INSERT forge_tunix_background_tasks (con notify_via_push:true)
   ↓ fire-and-forget POST /api/tunix-bg-runner
[Patricio cuelga la llamada]
   ↓ runner trabaja en background (Opus 15-30s)
   ↓ al terminar:
       ├─ INSERT tunix_bridge_queue (kind: background_result)
       └─ POST /api/push → push notif celu con CTA URL /talk?bg_task=<token>
Patricio recibe notif → tap →
   ↓ /talk se abre + detecta query param bg_task
   ↓ auto-startCall() 800ms después
   ↓ bridge poller entrega resultado al Gemini → leído proactivo

Schema cambio: forge_tunix_background_tasks.notify_via_push boolean (ALTER aplicado).

10.4Hooks proactivos — TUNIX llama PRIMERO

TUNIX deja de ser reactivo. Triggers configurables que disparan push notif al celu sin que vos abras nada.

Infraestructura

• Tabla forge_tunix_proactive_hooks: id, hook_type, label, enabled, schedule(jsonb), config(jsonb), last_fired_at, next_fire_at
• /api/tunix-proactive-tick — cron cada 5 min (registrado en vercel.json). Checkea hooks enabled donde se cumple condición + dispara push + actualiza last_fired
• /api/tunix-proactive-hooks — CRUD (GET list, POST create, PATCH toggle/edit, DELETE)

Tipos de hooks soportados

Tipo	Trigger	Estado
morning_briefing	Hora fija + días de semana (ej 8:30am lun-vie) → resumen del día	✅ Implementado (deshabilitado por default, Patricio activa)
urgent_contact	Mail/WSP de contacto VIP → llamada inmediata	🔧 Stub, lógica pendiente
meeting_alert	5 min antes de reunión marcada urgent	🔧 Stub, lógica pendiente
task_done	BG task completa cuando APK cerrada (sin notify_via_push)	🔧 Stub, lógica pendiente

Briefing matutino — caso completo

1. 8:30am hora Chile, viernes: cron tick detecta hook morning_briefing activo
2. Construye preview combinando forge_internal_meetings (reuniones hoy) + axis_reminders (reminders pendientes 24h) + wsp_audio_inbox (sin responder 12h)
3. Push notif al celu: "🎙️ TUNIX te llama — Briefing matutino 8:30am" + preview en body
4. También INSERT en tunix_bridge_queue kind=proactive_briefing
5. Patricio tap notif → /talk?proactive=<id> → auto-startCall 800ms
6. Bridge poller entrega briefing → Gemini lee con voz: "Buenos días Pato, hoy tienes 3 reuniones, la primera a las 11 con Nico, 2 reminders pendientes y un audio de Seba sin responder de anoche..."

Para activar

curl -X PATCH https://forge.tungsteno.tech/api/tunix-proactive-hooks?id=<HOOK_ID> \
  -H "Content-Type: application/json" -d '{"enabled":true}'

O via Talk: "TUNIX, activá el briefing matutino" (cuando agreguemos la tool wrapper).

10.5Timeline completo del día (auditable)

El 25-may probamos 4 arquitecturas distintas hasta llegar a la final. Lecciones grabadas:

Hora	Stack	Resultado	Decisión
09:00	gpt-realtime full + safeguards	$11 quemados en 2 días por loop bug	Probar mini
14:00	gpt-realtime-mini	Confabulación grave en saludos	Probar híbrido
15:30	Híbrido Deepgram+Sonnet+TTS-1	Funciona pero +1.5s latencia + ruido entrecortado	Probar Gemini Live
17:00	OpenAI Realtime transcribe (Deepgram WS close 1006 en APK)	Fallback intermedio	Migrar a Gemini
18:30	Gemini 2.5 Flash Live native audio	Funciona OK pero falta capacidades	Iterar mejoras
19:30	+ Affective dialog (close 1007 unknown field)	Bug Gemini API, remover field	Calibrar via temperature + prompt
20:00	+ Botón cubo isométrico Tungsteno	Patricio no convence	Rediseño hexágono 120px
20:30	+ Identidad Búnker permanente + ruteo tools directas	Funciona	Confirmar arquitectura final
21:00	+ Fidelidad verbatim a Sonnet/Opus	Cierra problema paráfrasis	Done
22:00	+ Parte 9 docs auditables	Patricio aprueba	Continuar mejoras
23:00	+ Fix celu bloqueado (regresión) + Plan Visible + Vision + WhatsApp Async + Hooks proactivos (4 mejoras)	4/4 desplegadas	Documentar Parte 10

Lecciones grabadas en memoria: forge_tunix_lessons + decisión final = Gemini 2.5 Flash Live + delegate Opus on-demand.

10.6TUNIX Talk vs Claude Code: paridad real al 25-may medianoche

Capacidad	Claude Code (VS Code)	TUNIX Talk (Gemini Live)	Gap
Razonamiento Opus 4.7	✅ directo	✅ via delegate_to_claude_max	—
Function calling complejo	✅ 60+ tools	✅ 65 tools async	—
Memoria persistente	✅ Memory Forge	✅ 3 capas + Memory Forge	—
Lectura repo/archivos	✅ directa	✅ via Búnker container	—
Editar código	✅ Edit tool live	⚠️ via send_to_code (buzón asíncrono)	Moderado
Plan visible (TodoWrite)	✅	✅ NUEVO 25-may	—
Vision multimodal	✅	✅ NUEVO 25-may	—
Sub-agentes paralelos	✅ Agent tool	✅ spawn_agent + dispatchBg	—
Ejecución shell	✅ Bash live	✅ via Búnker delegate	—
Voz natural	❌ texto only	✅ NATIVO	Talk gana
Always-on 24/7	❌ solo activo en VS Code	✅ Búnker container	Talk gana
Hooks proactivos	❌ no inicia conversación	✅ NUEVO 25-may	Talk gana
WhatsApp async (notif al colgar)	n/a	✅ NUEVO 25-may	Talk único

Conclusión auditable: TUNIX Talk al 25-may medianoche tiene paridad total con Claude Code para uso operativo, + 4 capacidades únicas (voz nativa, always-on 24/7, hooks proactivos, WhatsApp async). El único gap real restante: edición de código en vivo (no es uso típico de Talk, se cubre vía send_to_code → VS Code).

Manual TUNIX · Forge OS · v2026-05-25 medianoche · 10 partes · 74 secciones
Si encuentras algo desactualizado, pídele a TUNIX que se auto-mejore.
Última build: --