---
asset_id: PLAN-EL-SX-JayServer-Conectado-v01
tipo: PLAN — Plan de proyecto / experimento
version: v01
status: Activo — plan en revisión (seed, pendiente ratificación VH)
owner: Victor Heredia
sherpa_owner: Jay
tech_lead: Alex (Operativo)
fecha: 2026-06-19
intellibank: IB-EL-EmpowerLabs / PB-EL-Project-Bank / PB-SX-SherpaX
gate_g0: PASS — construido sobre ARQ-XX-SX-SherpaAPIPlan, ARQ-XX-AI-SherpaOS-Canonical/DataModel, TP-EL-R100X-TP-SherpaIA, MePB-VH-MiSherpaIA y MePB-EL-SX-DemoVaultSherpaGuide
experimento: EXP-2026-07 (Tablero de Experimentos)
proposito: >
  Plan para "Jay Server": un SherpaX conectado a los IntelliBanks (con acceso
  por usuario) y DESPLEGABLE a clientes que NO usan Cowork — gente operativa, no
  cognitiva. Es la productización del nivel L2 de "Tu Sherpa IA" (BrainOS +
  retrieval sobre IntelliBanks). Sintetiza el pensamiento previo del ecosistema y
  cierra las decisiones abiertas. Se corre como experimento.
relacionado_con:
  - ARQ-XX-SX-SherpaAPIPlan-v01.md
  - ARQ-XX-AI-SherpaOS-Canonical-v0.1.md
  - ARQ-XX-AI-SherpaOS-DataModel-EventLedger-v0.1.md
  - TP-EL-R100X-TP-SherpaIA-v01.md
  - MePB-VH-MiSherpaIA-v01.md
  - MePB-EL-SX-DemoVaultSherpaGuide-v01.md
  - DC-EL-SX-SherpaX-ArquitecturaOperacion-v01.md
  - BRD-EL-Home-Live-v01.html
  - BRD-EL-Experiments-Lab-v01.html
  - ARQ-EL-HyperLoopX-MejoraRecursiva-v01.md
---

# PLAN · Jay Server — SherpaX conectado y desplegable
## Un SherpaX con acceso real a los IntelliBanks, para clientes operativos sin Cowork

> *El Jay del Home responde genérico porque le falta la arquitectura debajo (Tip 4 de "Despierta tu SherpaX"). Jay Server es esa arquitectura: un SherpaX que de verdad consulta los IntelliBanks a los que el usuario tiene acceso — y que el cliente solo abre y usa, sin saber que existe un vault.*

---

## 0. TL;DR (la recomendación en una página)

**Qué es:** una app de chat sencilla, desplegable, donde un cliente operativo conversa con *su* SherpaX, que responde anclado en *sus* IntelliBanks. Sin Cowork, sin fricción técnica.

**La clave honesta:** ningún HTML estático puede leer el vault. Esto exige un **backend** (un servidor) que: (1) indexa los IntelliBanks del cliente, (2) recupera lo relevante a cada pregunta (RAG), (3) aplica control de acceso por usuario, (4) corre Claude (Sonnet) con la llave **en el servidor**, nunca en el navegador. Eso ya está diseñado en tu ecosistema — falta ensamblarlo.

**No partimos de cero:** el `SherpaAPIPlan` ya tiene el MVP por fases; el `SherpaOS Canonical/DataModel` ya define el stack (Supabase + pgvector + OpenRouter + MCP) y el scoping por usuario (RLS); "Tu Sherpa IA" ya define el producto (L1/L2/L3); el `Demo Vault` ya define cómo se entrega a un cliente. **Jay Server = productización del L2 "Tu Sherpa IA con BrainOS", desplegable como app.**

**Recomendación de arranque:** MVP con **1 cliente, 1 IntelliBank indexado, web chat, RAG con pgvector, Sonnet 4.6, llave en servidor**. Lo opera Alex sobre el Supabase que ya existe. Lo corremos como **experimento EXP-2026-07**.

---

## 1. Para quién y la hipótesis

**Usuario objetivo:** clientes **operativos, no cognitivos** — gente que necesita respuestas y ejecución ancladas en el conocimiento de su organización, sin querer aprender el vault, el naming ni Cowork. Abren una caja de chat y funciona.

**Hipótesis (EXP-2026-07):** *Si entregamos un SherpaX desplegable que consulta en vivo los IntelliBanks a los que el usuario tiene acceso —sin requerir Cowork—, los clientes operativos lo adoptan y pagan por él, porque responde anclado en su contexto en vez de genérico.*

**Métrica de éxito:** 1 cliente piloto usa Jay Server ≥ 3 veces/semana durante 3 semanas, con respuestas que citan correctamente sus propios documentos, y expresa intención de pago (o renovación).

## 2. Sobre qué construimos (Gate G0 — no reinventar)

| Pieza ya pensada | Qué aporta a Jay Server | Fuente |
|---|---|---|
| Plan de API por fases | MVP Node.js + Anthropic SDK + Sonnet; Fase 2 context injection; Fase 3 MCP | `ARQ-XX-SX-SherpaAPIPlan-v01` |
| SherpaOS Canonical + DataModel | Stack: Supabase + pgvector + OpenRouter + MCP; Event Ledger; Memory Layer; **RLS por user_id** | `ARQ-XX-AI-SherpaOS-*` |
| Tu Sherpa IA (L1/L2/L3) | El producto y sus niveles; L2 = BrainOS con memoria + búsqueda semántica | `TP-EL-R100X-TP-SherpaIA`, `MePB-VH-MiSherpaIA` |
| Demo Vault / Sherpa Guide | Cómo se entrega un banco sanitizado + Sherpa preconfigurado a un cliente | `MePB-EL-SX-DemoVaultSherpaGuide` |
| Jay (SherpaX de Victor) | Caso 0 vivo: L1+L2 operativos desde 2026-03-20 | `MePB-VH-MiSherpaIA` |

**Insight:** Jay Server no es un proyecto nuevo — es la **convergencia** de cuatro líneas ya diseñadas, empaquetada para un cliente sin Cowork.

## 3. Recomendaciones (cierro las decisiones abiertas)

Victor pidió "tú recomienda". Estas son mis recomendaciones; las marcadas con ⚑ siguen siendo decisión suya (sección 7).

- **Posicionamiento:** Jay Server **es** la implementación desplegable del **L2 de "Tu Sherpa IA"** (BrainOS + retrieval sobre IntelliBanks), no un producto separado. Evita fragmentar el portafolio.
- **Acceso / scoping:** **RLS por `user_id`** a nivel base de datos + un concepto de **workspace/organización**: el usuario ve su IntelliBank personal + los bancos compartidos de su organización. **El índice de retrieval solo indexa lo que el usuario puede ver** (doble candado: DB + índice). Esto materializa "los IntelliBanks a los que el usuario tiene acceso".
- **Retrieval:** **RAG con pgvector** (búsqueda semántica top-k) sobre los IntelliBanks indexados — mejor que grep agéntico para usuarios operativos y escala mejor. Recupera, inyecta contexto, responde.
- **Modelo:** **Sonnet 4.6 por defecto** (calidad cognitiva); opción Haiku para bajar costo en cuentas de alto volumen. **La API key SIEMPRE vive en el servidor**, nunca en el cliente (resuelve la fuga de llave del approach navegador).
- **Interfaz:** **web chat minimalista, mobile-friendly, login simple** — cero fricción para gente operativa. Multi-canal (WhatsApp/Slack/Teams) en una fase posterior.
- **Onboarding del cliente:** patrón **Demo Vault** — banco sanitizado + Jay preconfigurado con su tono y su memoria inicial. El cliente "aprende operando", no leyendo.
- **Operación:** sobre el **Supabase que ya existe** (BrainOS de Victor) + la **IntelliBanks app**, operado por **Alex (Operativo)**.

## 4. Arquitectura (componentes)

```
[Cliente operativo]
      │  (web chat simple, login)
      ▼
[ UI Jay Server ]  ── sin Cowork, mobile-friendly
      │  POST /sherpa/message { user_id, message, session_id }
      ▼
[ Sherpa Middleware ]  Node.js + Anthropic SDK
   ├─ Context Loader → RAG (pgvector top-k) sobre IntelliBanks del usuario
   ├─ Prompt Maestro de Jay (identidad + reglas) + contexto recuperado
   ├─ Conversation Manager (sesión, historial)
   └─ Claude API (Sonnet 4.6) ── KEY EN SERVIDOR
      ▼
[ Supabase ]  PostgreSQL + pgvector + Auth(JWT) + RLS por user_id
   ├─ intellibank_docs (chunks + embedding) ── indexa SOLO lo accesible
   ├─ sessions / events (Event Ledger) / memories
   └─ workspaces (organización → bancos compartidos)
```

Reusa íntegro el stack del `SherpaOS DataModel` (Event Ledger, Memory Layer, RLS). Lo nuevo es el **indexado de los IntelliBanks como fuente de retrieval** y el **front-end sin Cowork**.

## 5. Fases (mínimo viable → completo)

- **F0 · Plan + decisiones** — este documento + cerrar las ⚑ de la sección 7. *(estás aquí)*
- **F1 · MVP (1–2 semanas)** — 1 cliente, 1 IntelliBank indexado (vía Demo Vault sanitizado), web chat, RAG pgvector, Sonnet 4.6, key en servidor, sin multi-usuario. Objetivo: que Jay responda citando documentos reales del cliente.
- **F2 · Scoping + memoria (2–3 semanas)** — RLS multi-usuario + workspaces, Event Ledger, memoria persistente, ritual de actualización (L2 completo).
- **F3 · Soberano + multicanal** — tareas programadas (captura diaria, weekly review), WhatsApp/Slack, panel admin. (L3.)

## 6. Riesgos y frenos

- **Aislamiento de datos entre clientes** — RLS estricto + índices por workspace; test de fuga obligatorio antes de cada alta. *(crítico)*
- **Confidencialidad** — aplicar los **tiers del Demo Vault** (T3/T4 nunca salen); Brain Codes excluidos del banco del cliente.
- **Costo de tokens** — presupuesto por cliente; Haiku para alto volumen; cache de contexto.
- **Calidad del retrieval** — evaluar relevancia top-k (no responder genérico ni citar mal); medir con casos reales.
- **Seguridad de la llave** — solo en servidor, nunca en cliente; rotación.
- **Anti-sobreingeniería** — no construir L3 antes de validar F1 con 1 cliente.

## 7. Decisiones que siguen siendo tuyas ⚑

1. **Modelo comercial / precio** — ¿Jay Server incluido en "Tu Sherpa IA" o add-on? ¿setup + suscripción?
2. **Primer cliente piloto** — ¿quién? (candidatos operativos no-Cowork).
3. **Alcance del scoping v1** — ¿solo su banco personal, o también bancos de su organización desde F1?
4. **Confirmar naming canónico** de este activo y del producto desplegable (¿"Jay Server" es codename interno y el producto se llama "Tu Sherpa IA · Conectado"?).

## 8. Conexión con el ecosistema

Es **EXP-2026-07** en el Tablero de Experimentos; sus aprendizajes suben al **HyperLoopX** (→ LabPraxis si generan principio operativo). Usa el patrón **Demo Vault** para entregar. Y es, de fondo, **la productización del WORX OS para clientes**: lo que el Home Live es para EmpowerLabs (Caso 0), Jay Server lo es para cada cliente.

## 9. Próximo paso

Cerrar las 4 decisiones ⚑ (sesión corta contigo) → escribir el `ARQ-` técnico de F1 y prototipar el servidor MVP con Alex sobre el Supabase existente.

---

**PLAN · Jay Server v01 · 2026-06-19**
*Owner: Victor Heredia · Sherpa: Jay · Tech lead: Alex · Experimento: EXP-2026-07 · Gate G0: PASS*