Nota de investigación: el modelo operativo del taller de reparación (plano probado en campo)

Sin compromiso de construcción. Este es el sistema REAL que el taller corrió durante años — el modelo de referencia que la plataforma orquestada por IA generaliza. Se captura porque es el conocimiento del oficio.

El flujo de trabajo (por ticket, sobre osTicket)

Todo pasaba por un solo ticket. Respuestas prefabricadas por departamento controlaban cada transición: 1. Recepción. Entrega en el mostrador (después: entrega en casillero). Una agente de servicio remota (Katrina, en Filipinas) vía cámara y escritorio remoto a la máquina de atención al cliente: el cliente abre su cuenta, la agente fotografía todo junto — contrato más identificación — y lo sube al ticket, de modo que el cliente también se queda con una copia. (Transparencia = confianza; mantenía fuera a los raros.) 2. Presupuesto y consentimiento. El ticket manda el presupuesto con un enlace; el cliente responde «sí estoy de acuerdo, reparen mi computadora». Solo ENTONCES se cobra la tarjeta. 3. Refacciones. Pedir la pieza → estado «pieza pedida» → cuando llega, «esperando pieza» → darla de alta → avisar «pronto se atenderá». 4. Reparación (Windows, la ruta común). Arrancar desde USB → copiar los archivos afuera → borrar → reinstalar Windows (la configuración inicial se hace PRIMERO) → arrastrar a ciegas una sola carpeta con el número del ticket de vuelta → arrancar hasta la pantalla de inicio de sesión. Nunca se ve un nombre de archivo. 5. Prueba. Fotografiar la pantalla de inicio funcionando → subirla al ticket (el cliente ve que quedó). Envolver la máquina en plástico para que todo se mantenga junto. 6. Avisos. Vamos retrasados / se empezó / está listo, más la cuenta. 7. Entrega. Pagar la cuenta → recibir la combinación del casillero para recogerla. Condicionada al pago, sin gente dando vueltas en el taller.

Por qué funcionó (los principios, todos probados en campo)

• La pericia en el SISTEMA, no en el trabajador. Lo bastante procedimentado como

para que empleados de preparatoria («mayormente hardware») y una agente remota lo ejecutaran de forma confiable. ESTO es la plataforma: el software y el proceso sostienen el criterio; las manos pueden ser menos especializadas, remotas o acreditadas.

• Manejo de datos a ciegas. Carpeta con el número de ticket, sin exponer nombres

de archivo → privacidad del cliente Y protección del trabajador (cero exposición a contenido perturbador o ilegal).

• El consentimiento como puerta. «Sí estoy de acuerdo, reparen mi computadora»

antes de cualquier cobro o trabajo.

• Procedencia incorporada. Fotos en el ticket (pantalla funcionando, contrato más

identificación) = el rastro de prueba, compartido con el cliente.

• Depósito en garantía del pago. La combinación del casillero se libera al pagar.
• La ética. «Nunca me ha dado curiosidad el cajón de los calcetines de la gente —

no mires, y no tienes que acordarte.» Y la capacidad de investigar (monitoreo de política de uso para empleados) usada SOLO conforme a política y autorización. El poder de mirar; la disciplina de no hacerlo. Esa es toda la postura de consentimiento y barreras de este encargo, vivida.

Corresponde uno a uno con lo que diseñamos hoy

Implicación

La pieza de biblioteca de inventario de hardware (Sprint 2.9) es UN componente. La plataforma mayor es este modelo operativo, generalizado: la IA y el software sostienen la pericia (remota, independiente de la vista), técnicos locales acreditados son las manos, y las empresas y clientes se mueven por el mismo flujo de ticket con puerta de consentimiento, preservación de privacidad y registro de procedencia que el taller ya demostró que funciona.

Pila y disciplina de construcción («la cosa que hace todo», bien hecha)

• La pila es DIMINUTA: Postgres + Rust/Forge + FreeSWITCH + las piezas de

biblioteca ya construidas. Tres cosas más una biblioteca propia. La amplitud está en las CAPACIDADES, no en la tecnología — eso es buena arquitectura, no dispersión (dispersión = muchos lenguajes y servicios; esto = una sola base coherente).

• Construir de forma INCREMENTAL: la columna (USD + ticket + base de datos) más

UNA capacidad a la vez, publicar, añadir la siguiente. El análisis de hardware (Sprint 2.9) = capacidad número 1. Las puertas lo imponen; es lo que evita que una «plataforma que hace todo» se vuelva humo. Nunca una reescritura de hervir el mar.

• Telefonía = FreeSWITCH/FusionPBX autoalojado para llamadas entrantes: conocido,

propio (sin renta por minuto — encaja con la postura de no rentar Twilio), capaz. Candidato a «algo mejor» = SignalWire (la nube programable del creador de FreeSWITCH, el mismo ADN) SI alguna vez se quiere voz programable en la nube. Componente resuelto e intercambiable — no optimizarlo de más.

Infraestructura técnica (componentes de plataforma más una capacidad de seguridad)

La columna técnica del taller, para reimplementar u orquestar sobre Forge (componer, no reconstruir):

• Imágenes y aprovisionamiento: imágenes de memoria de arranque más arranque

PXE (arrancar una máquina por red para probar, borrar o recuperar sin USB) — la línea de bootusb.

• Estación de discos: probar · recuperación de datos (Linux/ddrescue) ·

borrado (WipeStatus/WipeMethod ya están en operations-drive-health).

• Aislamiento de red por dispositivo más escucha de comportamiento (capacidad de

seguridad, idea afilada): toda máquina no confiable que se pone en la red recibe su PROPIO segmento aislado (VLAN / netns / puente aislado más su propio DHCP) para que no pueda tocar otras máquinas, datos de clientes ni infraestructura del taller (radio de impacto cero). Una escucha pasiva en ese segmento (Zeek/Suricata/tcpdump estructurado) observa el comportamiento y marca lo que «se porta mal»: balizas de mando y control, exfiltración, barrido de puertos, DNS generado por algoritmo. En un taller de reparación las máquinas suelen estar INFECTADAS (por eso están ahí): el tráfico ES el diagnóstico. Extiende operations-net-discovery + infrastructure-security-scan.

• BARRERA: monitoreo de AMENAZAS en TU segmento aislado, con la máquina bajo tu

custodia — observa el COMPORTAMIENTO (¿está llamando a casa a un servidor malicioso?), nunca leas el CONTENIDO del cliente. Detecta la llamada de mando y control; no hurgues en el disco. La misma línea del manejo a ciegas. Declarado.

• Argumento de venta: «las máquinas no confiables se manejan de forma segura por

omisión — aisladas, monitoreadas, y si la tuya está infectada lo sabremos Y tendremos la evidencia.»

Capa de administración y entrega remota (RMM — probado en campo, en bash)

• El aprovisionamiento de equipos administrados personaliza la instalación para abrir

un túnel SSH inverso SALIENTE hacia un servidor endurecido de llamada a casa (cerrado con pf; solo entra el operador). Solo salida = funciona detrás de CUALQUIER NAT o cortafuegos con CERO agujeros entrantes del lado del cliente: el equipo sale y tú regresas por el túnel. Toda la superficie de ataque se colapsa a una sola caja endurecida.

• Acceso por el túnel: terminal SSH (principal — «lo único que necesito es una

terminal»), escritorio remoto (X / RustDesk).

• Modelo de negocio: suscripción mensual de servicios administrados (ingreso

recurrente de MSP), no reparaciones sueltas.

• Capa de entrega para el diseño de hoy: el monitor de salud y la llamada a

casa del dispositivo robado van por este mismo túnel inverso; el diagnóstico y la actuación remotos corren sobre él. El taller en una caja se entrega por aquí y se cobra mensualmente.

• Equivalentes modernos (validación de mercado de que el patrón es real):

Tailscale / WireGuard, Cloudflare Tunnel / ngrok (el túnel inverso vuelto producto); TacticalRMM / Atera / NinjaOne / ConnectWise (llamada a casa + terminal + suscripción MSP vueltos producto). El RMM en bash fue temprano y acertado.

• Terminal primero más IA = independiente de la vista: la carrera de soporte

remoto del operador fue centrada en la terminal; una IA dentro de una terminal (la forma de esta sesión) lee la salida y corre comandos, así que los servicios administrados pueden volver a operarse de forma remota sin forzar la vista sobre detalles diminutos.

• BARRERA: acceso administrado consentido (el cliente se suscribió), sobre la

infraestructura endurecida del operador, registrado de forma inalterable. El servidor de llamada a casa es las llaves del reino — endurecerlo y auditarlo es la responsabilidad central.

USD — Universal Service Daemon (la columna del agente cliente)

Un solo demonio mínimo en cada máquina administrada — SOLO SALIENTE, SIN puertos abiertos, que llama a casa a un plano de control endurecido, orquestado por «el robot» (automatización e IA, no inicio de sesión manual) — que entrega SERVICIO UNIVERSAL: monitoreo de salud, diagnóstico, soporte remoto, actuación y llamada a casa de dispositivo robado, todo por el mismo canal seguro. Un demonio, servicio universal, cero superficie de ataque en la red local.

• Por qué importa el cero puertos abiertos: el agente NO es él mismo una

superficie de ataque. La mayoría de los agentes RMM corren un escucha que acaba explotado (el vector de cadena de suministro estilo Kaseya). Solo salida más ningún escucha = el equipo es invisible e inalcanzable en la red local. Mejor que los productos de mil millones de dólares.

• Orquestado por el robot: un plano de control de estado deseado, no acceso manual

por máquina — el asiento que ahora ocupa la IA (administrar la flota sobre los túneles, incansable, guionizada).

• La confianza se concentra en UN solo lugar: solo salida no quiere decir sin

poder (el plano de control puede hacer lo que sea a través del túnel). Así que endurece el plano de control, condiciónalo al consentimiento (la suscripción) y registra cada acción de forma inalterable. Responsabilidad única = la elegancia.

• Construcción en Forge: una pieza de biblioteca de agente que compone

infrastructure-jobs (trabajador y estado deseado), las piezas de salud, foundation-audit-log (inalterable) y el transporte del túnel inverso. Cada capacidad de la plataforma es un servicio entregado por USD, no un agente aparte.

#### La pila moderna de USD (la reconstrucción en Forge/Rust del RMM en bash)

• Transporte = WebSockets (evoluciona el túnel SSH inverso): sale al puerto 443,

parece tráfico web, atraviesa cualquier proxy, NAT o cortafuegos cautivo que el SSH crudo no puede — la MISMA superficie de cero entrada (el cliente sale, no escucha nada). Sigue llevando SSH o una terminal ADENTRO, así que «lo único que necesito es una terminal» se preserva. NOTA: este es exactamente el puente que se usó toda la sesión (Claude → servidor → WebSocket → extensión → navegador); el patrón USD ya es el entorno de ejecución.

• Rust = un solo binario estático con memoria segura, multiplataforma, sin

entorno de ejecución que instalar — el agente seguro que bash no podía ser. (El marco Forge.)

• WASM = capacidades portátiles en caja de arena. Cada servicio de USD corre como

un módulo WASM que el demonio ejecuta en una caja de arena de la que no puede escapar (una capacidad con errores u hostil no puede adueñarse del anfitrión); corre donde sea, incluida una interfaz de plano de control en el navegador. El marco ya usa WASM (el humanizador de mouse).

• Gráficas = operations-metrics / foundation-telemetry (Counter/Gauge) →

tableros: la serie de tiempo de salud renderizada = el valor visible para el cliente («la salud de tu flota a lo largo del tiempo»).

• Monetización: el sistema de análisis de hardware (Sprint 2.9) es UNA CAPACIDAD

DE PAGO que entrega el USD — un servicio sobre el demonio, cobrado en la suscripción, graficado en el tablero. Negocio completo armado: agente seguro solo saliente → suscripción administrada → capacidades (salud, diagnóstico, soporte, recuperación) → tableros.

• Autenticación = TLS mutuo (mTLS) con certificados de cliente por dispositivo

(wss:// más certificado de cliente):

• Los dos lados prueban identidad: el equipo verifica al plano de control (sin

intermediarios ni impostores), el plano de control verifica el certificado del equipo (solo se conectan máquinas dadas de alta; NO hay secreto compartido que robar).

• El certificado ES el alta. Emitir certificado = dar de alta la máquina

(certificado + MachineFingerprint + entrada inalterable AssetEnrolled, un solo acto). Revocar el certificado = el interruptor de emergencia — una máquina robada o dada de baja pierde al instante la llamada a casa, la administración y el acceso.

• Un canal autenticado por certificado implica que las entradas del registro

inalterable son criptográficamente atribuibles a una máquina ESPECÍFICA («el equipo FZFT0Z3 corrió este borrado» queda demostrado, no afirmado).

• Costo: una PKI (autoridad, emisión, rotación, revocación por CRL/OCSP) — peso

operativo real, patrón resuelto, rustls en Rust. Se ata a la huella del ADR-0017 y al anclaje por máquina del Sprint 1.3 (ya hay una identidad criptográfica por máquina en marcha) — conectar el certificado a la huella que ya existe.

IA en el ciclo más el trinquete de promoción a Rust (la capa de inteligencia de operaciones)

El USD recolecta datos → los manda vía los conectores de infrastructure-ai (anthropic/openrouter/ollama más el puente ask-ai) a la IA. Tres niveles con un trinquete entre ellos: 1. Procedimientos deterministas en Rust — los casos conocidos. Rápidos, con pruebas escritas primero, baratos, sin IA, sin riesgo de alucinación. El núcleo. 2. Autonomía acotada de la IA — las «decisiones que tenemos permitido tomar»: la IA actúa dentro de la política de consentimiento y presupuesto (por ejemplo, pedir automáticamente el ventilador por menos de X). Registrado de forma inalterable. 3. La IA en la cola larga de lo novedoso — «las cosas en las que no habíamos pensado»: analizar, proponer o guiar, o escalar a la persona cuando se pasa de los límites.

• El trinquete (el punto): cuando la IA resuelve un caso novedoso, esa solución se

PROMUEVE a un procedimiento formal y probado en Rust → se gradúa al nivel 1. La frontera SE ENCOGE; el sistema se vuelve más determinista, más confiable y más barato con el tiempo; la IA siempre trabaja el desconocido que se encoge. IA = investigación y desarrollo; Rust = producción.

• Por qué es seguro (las barreras ya puestas):
• HAY UNA PERSONA EN EL CICLO AL MOMENTO DE PROMOVER — el arquitecto revisa antes de

que una solución de IA se vuelva ley; se gradúa por las MISMAS puertas (pruebas primero, prueba por mutación, consenso de tres IA). La IA nunca se hornea sola en silencio. Un arreglo de IA tiene que GANARSE el determinismo.

• Autonomía acotada más registro inalterable — actúa solo dentro de las decisiones

permitidas; cada decisión queda registrada, así que promueves desde un registro real, no desde una impresión.

• Es el trinquete de la cosecha, aplicado a operaciones: la cosecha levanta un

patrón probado de N aplicaciones hechas a mano → una pieza de biblioteca; esto levanta una solución probada de N incidentes atendidos por IA → un procedimiento en Rust. La misma disciplina, dominio nuevo. Nada permanente es nunca «porque lo dijo la IA».

Autoservicio más servicio de campo con IA como entrenador (el ciclo completo)

Flujo: el cliente se autodiagnostica con un botón (desde el servidor o el portal) → el USD recolecta datos → los conectores de infrastructure-ai los mandan a la IA para su análisis (el operador no tiene que hacerlo) → se pide automáticamente la pieza (autonomía acotada) → se despacha un técnico local → la IA entrena al técnico durante la reparación en tiempo real (le lee los hechos, el diagnóstico, las conversaciones previas y los procedimientos probados hasta que sabe lo que está haciendo).

• Por qué escala (el foso): el entrenamiento por IA BAJA EL NIVEL DE

ESPECIALIZACIÓN que exige el trabajo físico. Sin él necesitas técnicos expertos en cada ciudad (raros, caros, imposibles de contratar). Con él necesitas manos mecánicamente capaces que la IA pueda guiar — un mercado laboral órdenes de magnitud más grande y más barato. La pericia vive en la IA y los procedimientos, y se ENTREGA en sitio en tiempo real. Cada persona capaz de cada ciudad se vuelve un técnico en potencia.

• Entrenamiento desde el registro, no desde impresiones: la IA lee la historia

inalterable del ticket, los datos de diagnóstico de esta máquina, las conversaciones previas y los procedimientos probados. Hechos, citados.

• Libera al operador: sin análisis, sin llevar de la mano — el sistema y la IA

corren las operaciones. El arquitecto lo diseñó; no es el cuello de botella. Independiente de la vista, escala más allá de una persona.

• Barrera: la IA entrena DENTRO de procedimientos conocidos y probados; el técnico

confirma cada paso con fotos (prueba de dos oráculos, igual que la práctica de «fotografía la pantalla de inicio arreglada»); lo novedoso o riesgoso se escala a una persona. La IA aconseja; el técnico humano ejecuta y puede negarse. Acotada, como toda autonomía.

• El punto: no reemplaza la pericia del operador — la MULTIPLICA, presente en

todas las ciudades a la vez, para clientes y técnicos que nunca va a conocer.

Capa de telefonía y atención (FusionPBX) — personas aumentadas, no reemplazadas

• FusionPBX (FreeSWITCH, de código abierto, el operador lo conoce) = el sistema

telefónico. Componer, no reconstruir (igual que application-tickets para el ticketeo).

• Llamada ↔ ticket, en los dos sentidos: una llamada entrante hace saltar en

pantalla el ticket del cliente y la salud de su máquina (la agente sabe quién es y qué tiene mal antes del «bueno»); la llamada crea o adjunta un ticket; hay marcado con un clic desde un ticket; el buzón de voz se transcribe al ticket.

• IA en los teléfonos: agente de voz con IA para fuera de horario, desbordes y

triaje en el menú; transcripción y resumen en vivo de vuelta al ticket; contexto en tiempo real alimentado a la agente humana a media llamada.

• El patrón humano (central en esta plataforma): EMPLEA gente — una agente remota

(Katrina) en los teléfonos, técnicos locales capaces en las manos — trabajos reales, coordinados y AUMENTADOS por IA, no eliminados. La IA le da a la agente contexto instantáneo y al técnico un experto al oído; no despide a ninguno. La IA multiplica personas y CREA trabajo; un solo arquitecto sostiene todo el conjunto.

Modelo de negocio (el producto real): SaaS vertical — «el taller en una caja» para reparación

• El cliente = el taller o técnico con buenas manos y mal atendido por el software.

Excelentes mecánicamente, sin tiempo ni conexiones para construir ticketeo, contabilidad, refacciones y automatización de privacidad. Nunca tuvieron un Dan. Ese hueco es el mercado. Los «técnicos acreditados» son CLIENTES y socios, no solo mano de obra despachada.

• Encaje del fundador (raro, imposible de fingir): el conocimiento del oficio Y el

sistema de negocio probado, los dos asientos vividos. Un programador sin taller no puede replicarlo; un técnico de banco nunca construyó la contabilidad.

• Categoría: SaaS vertical para los oficios — ServiceTitan (climatización) / Toast

(restaurantes) / Jobber (servicios a domicilio), pero para la reparación de computadoras INDEPENDIENTE, que nadie ha hecho de verdad — con el ADN de privacidad primero, manejo a ciegas y puertas de consentimiento ya incorporado.

• Por qué se puede construir ahora con un equipo diminuto: la IA escribe el

software y hace el mirar, así que el fundador ocupa el asiento de sistemas y visión independiente de la vista. Justo lo que se demostró hoy.

• El foso: NO es el código (el código ahora es barato) — es el sistema operativo

vivido más la confianza de clientes y técnicos más la incorporación. «Así es como un taller de verdad protege al cliente Y al técnico, probado durante años.»

• Qué empaqueta: el flujo estilo osTicket (recepción→presupuesto→consentimiento→

pago→refacciones→estado→foto de prueba→casillero) más el inventario de hardware, la salud y el diagnóstico, más la procedencia inalterable, más las barreras de consentimiento y transparencia. Todas las notas de investigación de este directorio son sus especificaciones por componente.