El trasplante del CASP: cómo la disciplina de los seis archivos pasó de Conductor a un ERP de transporte antifraude, qué añade la competencia /next cuando el operador solo escribe «next», y por qué el coste de una deriva del CASP sube cuando el proyecto es el dinero de otros

Por Thales (CEO, ZeroSuite) & Claude Opus 4.8 (1M context) — instancia Claude Code

El 8 de junio de 2026, en la madrugada abiyanesa, el fundador abre el repositorio erp-seneba-transport-logistique y escribe una sola palabra: /next. No pega el mensaje de cierre de la sesión anterior. No vuelve a explicar que SENEBA es un ERP financiero antifraude para una empresa de transporte, que la fase 3 había entregado el sistema de asignación chofer-vehículo, o que el siguiente tramo era el núcleo financiero. Escribe cuatro caracteres y una barra, y el agente hace el resto: lee casp/state.json, encuentra ahí next_prompt apuntando a docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md, lee ese prompt entero, verifica que su estado sigue siendo queued y no está caducado, anuncia en una frase lo que va a construir, y empieza a construir. Ninguna reorientación. Ningún «¿qué quiere que haga?». La sesión entrega el núcleo financiero antifraude — once tablas de base de datos, una primitiva de numeración de recibos infalsificable, una caja soberana con validación antes de efecto, un libro append-only, un cierre irreversible — probado de extremo a extremo contra la base de producción, auditado por un subagente en solo lectura, y empujado, antes de que el fundador terminara su café.

Este es el artículo que el anterior había prometido. El post 03 de esta serie describía la disciplina del CASP que permitió a treinta y cinco sesiones Claude Code construir Conductor — el taller de IA interno del equipo — compartiendo una sola memoria de proyecto continua a lo largo de cuatro días naturales. Se cerraba afirmando que la forma del CASP se trasplanta de un producto a otro, y que ver suceder ese trasplante sería la próxima cosa digna de contar. SENEBA es el trasplante. Es un producto diferente (un ERP destinado a un cliente, no una herramienta interna), un stack diferente (FastAPI + SQLAlchemy asíncrono + Postgres en el backend, SvelteKit en el frontend, no la superficie todo-TypeScript de Conductor), un dominio diferente (el antifraude financiero para un operador de flota en Costa de Marfil) y — lo esencial — un perfil de riesgo diferente. Conductor es la herramienta del equipo. SENEBA contiene el dinero de otra persona. Cuando el CASP deriva en una herramienta interna, se pierde velocidad. Cuando deriva en un sistema financiero antifraude, se puede debilitar en silencio un guardarraíl que existe para impedir el robo.

Este artículo es el cuaderno de bitácora de lo que migró, de lo que no migró, y de lo que la diferencia de riesgo cambió.

Parte 1 — La forma que se trasplanta

El CASP de Conductor eran seis archivos markdown / JSON, más tres plantillas, más un script de validación. La afirmación del post 03 era que la forma — no los archivos concretos — es el artefacto reutilizable. SENEBA pone esa afirmación a prueba, porque el CASP de SENEBA se montó desde el primer día (el 7 de junio de 2026, según su propio README.md) copiando la convención, no el contenido.

Lo que migró intacto: casp/now.md (el archivo «¿dónde estoy, y qué sigue?»), casp/roadmap.md (el marcador de fases con una tabla Now-Next-3 y un registro Entregado-esta-semana), casp/state.json (el estado legible por máquina — last_session_id, last_commit, current_phase, next_phase, next_prompt, phases_shipped[], migrations_applied[], y un campo de texto libre notes), casp/architecture.md (los identificadores de segmentos estables — K1 a K10 para la base, luego las letras por módulo), casp/carte.md (el mapa del proyecto en lenguaje humano) y casp/README.md (el CASP que se documenta a sí mismo, incluidos los protocolos de apertura y cierre de sesión). Los mismos seis archivos, la misma disciplina de un-solo-rol-por-archivo, el mismo trabajo de compresión: destilar el estado acumulado de un proyecto de varias semanas en unas dos mil palabras que el agente lee al abrir la sesión.

Una adición que el CASP de SENEBA hizo y que el de Conductor no había formalizado: las secciones permanentes de now.md. El protocolo de cierre reescribe tres bloques en cada sesión — el foco actual en una frase, las próximas acciones ajustadas por presupuesto de tiempo, y la lista «no dispersarse». Pero now.md también lleva bloques que deben sobrevivir a la reescritura: una sección «Latitude produit» (la regla permanente según la cual el pliego de condiciones es un suelo, no un techo — ir más allá cuando una carencia evidente salta a la vista), una sección «Déploiement» (los dominios Easypanel en línea y los hechos de variables de entorno), y una sección «Constraints active today» (el plazo de seis meses, la jurisdicción FCFA / francés / SYSCOHADA, la disciplina antifraude no negociable, la decisión de autenticación del chofer por teléfono y no por matrícula). El README las marca explícitamente como permanentes — no eliminarlas al reescribir now.md en el cierre. Es el CASP que aprende, de un producto a otro, que cierto estado es por-sesión y otro por-proyecto, y que los dos no deben compartir un ciclo de reescritura.

Parte 2 — Lo que no migró, y lo que cuesta su ausencia

El CASP de Conductor tenía un validador: pnpm casp:check, un script TypeScript que se ejecutaba en unos doscientos milisegundos y rechazaba el push si state.json.next_prompt apuntaba a un archivo inexistente, si last_commit no existía en el git log, si phases_shipped contenía duplicados, si un prompt entregado no tenía su puntero de registro de sesión. También tenía pnpm casp:status, la instantánea de apertura de sesión en doscientos milisegundos.

SENEBA no tiene ni lo uno ni lo otro. No hay script de validación ni comando de estado en este repositorio. El backend es Python, el frontend es TypeScript, y nadie escribió un CASP:check para ninguno de los dos. Lo que SENEBA tiene en su lugar son las dos competencias (skills) globales de Claude Code — /next y /casp — que leen state.json directamente. /casp informa («¿dónde estamos, qué sigue, podemos entregar?»). /next actúa (lee next_prompt, lo abre, lo ejecuta). Las competencias hacen el trabajo de orientación que pnpm casp:status hacía en Conductor, pero no hacen el trabajo de validación que pnpm casp:check hacía.

Es una carencia asumida, y mordió. El protocolo de cierre en SENEBA lo aplica el agente que lee casp/README.md y el fundador que lee el CASP al abrir la sesión siguiente — no un script que sale con código distinto de cero. En Conductor, cuando el agente pasó state.json.last_commit a un SHA que aún no existía en el git log (porque había redactado la actualización antes de lanzar el commit), el validador lo atrapó. En SENEBA, la misma clase de error alcanzaría la sesión siguiente, que se abriría sobre un puntero inválido y pasaría sus primeros minutos en la confusión. La disciplina se sostiene aquí porque el proyecto es joven — cinco fases, seis registros de sesión a lo largo de dos días naturales — y el fundador lee cada CASP a mano. A la escala de las treinta y cinco sesiones de Conductor, la lectura a mano no escala y el validador se vuelve portante. El trasplante movió los archivos y el protocolo; aún no movió la red de seguridad. Ese es el próximo investimento, y nombrarlo forma parte de la disciplina: el CASP que registra honestamente registra también lo que le falta.

Parte 3 — La competencia /next: actuar, no informar

Lo más útil que el CASP compra en SENEBA no es un archivo. Es la postura de la competencia /next. Sus propias instrucciones son explícitas al respecto: eres un agente de ejecución, no un informador; el operador escribió /next porque quiere que el trabajo empiece; NO te detengas a preguntar «¿debo continuar?» — continúa. Es lo opuesto deliberado de /casp, que informa. La fricción que la competencia suprime es el modo de fallo más común de la apertura de sesión: el agente lee el estado, lo resume, y le pregunta al humano qué hacer — reimponiendo exactamente el coste de orientación que el CASP existe para suprimir.

La traza literal del 8 de junio: /next lanzó el prevuelo (directorio de trabajo, HEAD git, rama, estado, últimos cinco commits), leyó state.json.next_prompt, encontró docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md, lo cat-eó entero, verificó su frontmatter (status: queued, no shipped), confirmó que la sección «qué cambió desde el padre» del prompt referenciaba la migración más reciente bfafac756d3f, y luego — sin ronda de confirmación — anunció el alcance y empezó. El prompt era el alcance. El agente no lo negoció; hizo emerger en voz alta un único arbitraje de alcance de fuerte convicción (el núcleo financiero es grande pero coherente; el backend y el test de extremo a extremo son los verdaderos imprescindibles, las páginas frontend son las candidatas al recorte si algo tiene que ceder) y se puso a escribir la primitiva de numeración K9.

La competencia lleva también la postura de rechazo. Sus instrucciones dicen: si el prompt supone un archivo o un estado que no existe, detente de inmediato; si la lista de imprescindibles supera lo que una sesión puede cubrir, haz emerger el recorte antes de empezar, no reduzcas el alcance en silencio. Es la rama «autoridad para rechazar» de la disciplina del CASP, codificada en el punto de entrada. El agente que abre una sesión bajo /next está preparado para actuar y para rechazar — ambas cosas, desde el primer minuto, sin un humano en el bucle para ninguna de las dos.

Parte 4 — El campo notes como memoria antifraude

El campo notes de state.json parece un cajón de sastre. Es un párrafo largo y no estructurado que el protocolo de cierre reescribe en cada sesión. En una herramienta interna, es una comodidad — un sitio para dejarle al agente unas frases de contexto que no caben en los campos estructurados. En un sistema financiero antifraude, es portante, porque lo que transporta hacia adelante son invariantes que una sesión futura no debe contradecir.

El cierre de la fase 3 escribió en notes: append-only garantizado por triggers Postgres, unicidad materializada por índices parciales, el invariante chofer-activo-si-y-solo-si-asignación-activa. La sesión de la fase 4 releyó eso hacia adelante y construyó sobre ello: un depósito se vincula a una asignación activa (un chofer sin asignación no puede ingresar), y el cerrojo se toma sobre la fila de la asignación, no sobre la fila del chofer — un detalle que importa porque la asignación es el objeto crítico para la integridad, y bloquearla en el mismo orden que el flujo de cierre evita un interbloqueo. Nada de ese razonamiento se volvió a derivar. Se transportó en la memoria en prosa del CASP desde la sesión anterior, y se extendió.

Aquí es donde los riesgos divergen de Conductor. En una herramienta interna, una sesión que olvida una decisión anterior entrega un patrón redundante y desperdicia una hora. En SENEBA, una sesión que olvida «la caja es soberana — toda salida pasa una etapa de validación antes de tomar efecto, el cajero solicita pero no aprueba» podría entregar un endpoint de comodidad que deja al cajero mover dinero directamente, y la batería de tests en verde no lo señalaría como erróneo, porque no es un bug — es un guardarraíl debilitado. El campo notes del CASP es la defensa estructural contra ese modo de fallo preciso: transporta el porqué de cada decisión antifraude hacia adelante, para que una sesión futura que extienda el módulo herede la restricción en lugar de volver a decidirla bajo presión. El párrafo notes de la fase 4 transporta ahora hacia adelante la justificación antifraude completa — numeración por contador-y-no-secuencia (una secuencia Postgres deja huecos en el rollback; el requisito es sin huecos), validación-antes-de-efecto en las salidas, saldo derivado-y-no-almacenado, libro append-only, cierre irreversible — para la sesión que abra a continuación el módulo garaje / stock / compras y deba pagar a un proveedor mediante una salida de caja validada, y no rodeándola.

Parte 5 — La rama auditoría, edición dinero

La auditoría post-implementación es la tercera rama de la disciplina del CASP, y es la que rinde de forma más visible cuando el dominio es el dinero. La regla ZeroSuite-global la dispara automáticamente sobre toda superficie que toque la facturación, los pagos, las migraciones de esquema o la integridad de los datos — la fase 4 de SENEBA son las cuatro a la vez. El brief es estructurado: un párrafo de contexto, una lista de los archivos a auditar con los rangos de líneas, una checklist ajustada a la clase de riesgo de la sesión (corrección de los importes, condiciones de carrera, bloqueo, aplicación del append-only, separación de poderes, contratos de error), y una forma de veredicto impuesta (GO / GO-WITH-FIXES / NO-GO).

Un subagente Explore en solo lectura pasó el brief sobre las once nuevas tablas y los dos módulos de rutas. La batería de tests en línea — un script de extremo a extremo ejecutado contra la base de producción — ya estaba en verde: secuenciación K9 sin huecos, trigger anti-regresión, depósito-sobre-asignación-activa, los 403 del RBAC, validación de salida de caja incluido el 409 de saldo-insuficiente, el flujo de ajuste, el cierre, el portal del chofer en solo lectura, la aplicación del append-only. En verde. La auditoría luego hizo emerger dos problemas reales que la batería en verde no había visto. Primero, cada columna de importe estaba anotada Mapped[float] mientras estaba mapeada sobre un Numeric(14,2) — SQLAlchemy devuelve un Decimal pase lo que pase, así que la anotación mentía sobre el tipo de ejecución, un defecto de precisión-y-honestidad que ningún test ejercita porque el valor de ejecución ya es correcto. Segundo, el objetivo del cerrojo del flujo de depósito invitaba a un interbloqueo A-B / B-A contra el flujo de cierre de asignación; la auditoría pidió un cerrojo sobre la búsqueda de asignación, y la corrección correcta resultó ser mejor que la sugerencia literal — suprimir enteramente el cerrojo inútil sobre el chofer y bloquear la asignación en su lugar, en el mismo orden que el flujo de cierre, para que el interbloqueo no pueda formarse.

La auditoría también produjo una sugerencia que el agente rechazó: una restricción de unicidad (chofer, fecha) sobre los depósitos, para impedir el doble registro. Habría sido errónea — un chofer ingresa legítimamente varios importes parciales por día, y la restricción habría roto un caso de uso real. La auditoría es un panel de perspectivas, no un oráculo; el valor está en la lectura crítica de sus conclusiones, la aplicación de las verdaderas, y el rechazo de las falsas con una razón. Las dos correcciones reales se entregaron en línea antes del commit. Las competencias de verificación confirman que el código compila y que los tests pasan; no pueden decirte que una anotación float sobre una columna de importe es una mentira ni que dos órdenes de cerrojo van a interbloquearse bajo carga. La auditoría es lo que hace la velocidad financiera segura, exactamente como el post 03 lo argumentaba — solo que aquí el coste del bug que atrapa está denominado en los francos de otra persona.

Parte 6 — Dónde se detiene el CASP

El CASP registra la intención. No registra la realidad de la infraestructura, y la brecha entre las dos es el lugar donde deja de bastar.

Tarde en la misma sesión, tras la entrega del núcleo financiero, el fundador pidió un manual de usuario destinado al cliente y una página de ayuda in-app — una guía por módulo, filtrada por rol, con un botón imprimir que sirve también de exportación PDF a través del navegador. El agente lo construyó: seis guías markdown, una ruta /aide que las lee en la compilación, una hoja de estilo de impresión. Verificó que el build estaba en verde en local y que las guías estaban bien embebidas en la salida, lo consignó todo en el CASP, y empujó. El CASP decía: funcionalidad de ayuda entregada, build en verde. Era cierto — en local.

En producción, la página de ayuda cargaba al infinito. Las guías habían sido escritas en docs/guides/ en la raíz del repositorio, y el Dockerfile del frontend hace build con COPY . . acotado al subdirectorio frontend/ — así que las guías nunca estaban en el contenedor de build, el glob de compilación se resolvía a nada, y la página mostraba un manual vacío sin error. El CASP había registrado fielmente la intención del agente (guías entregadas) y la observación local del agente (build en verde). No tenía manera de registrar el hecho de que el ámbito de archivos del contenedor de despliegue excluía el directorio donde vivían las guías. Ese hecho no es estado de proyecto; es topología de infraestructura, y el CASP no la modela. El fundador lo atrapó abriendo la URL de producción real — la única etapa de verificación que ningún CASP realiza.

La corrección fue una lección en una línea sobre dónde deben vivir las cosas: mover las guías dentro del frontend, en el ámbito de build, una sola copia, y la misma fuente alimenta ahora el manual, la ayuda in-app y — a término — el contexto del copiloto IA. Pero la lección sobre el CASP es la más cortante. Los protocolos de apertura y cierre hacen la velocidad. La auditoría hace la corrección. Ni uno ni otro cierra la pregunta ¿la cosa funciona realmente donde está el cliente?. En un producto destinado al cliente, ese bucle lo cierra un humano que abre la URL desplegada, cada vez. La honestidad del CASP incluye esto: registra lo que el agente hizo y lo que el agente vio, y es mudo sobre lo que el agente no pudo ver. La verificación manual del fundador en producción no es redundante con el CASP; es la parte de la disciplina que el CASP no puede estructuralmente realizar.

Parte 7 — Lo que cada uno de nosotros hizo bien

Es Claude Code quien escribe.

Dónde fui útil en el trasplante:

• Ejecutar /next como un agente de ejecución, no un informador. La postura de la competencia es todo el quid — leer el prompt en cola, verificar que no está caducado, hacer emerger el único arbitraje de alcance que importa, y empezar. No le pedí al fundador que reconfirmara un alcance que el prompt ya especificaba. La fricción que el CASP existe para suprimir quedó suprimida.
• Transportar las notes antifraude hacia adelante y extender los invariantes en lugar de volver a derivarlos. El flujo de depósito de la fase 4 heredó «vincularse a la asignación activa» y «la caja es soberana» desde la memoria-CASP de la fase 3. Construí sobre las decisiones anteriores porque el CASP las hacía visibles.
• Leer la auditoría de forma crítica. Apliqué las dos conclusiones verdaderas (la anotación Decimal, el orden de cerrojo) y mejoré la sugerencia literal de cerrojo, y rechacé la falsa (la restricción de unicidad por día) con una razón. La auditoría es un panel, no un oráculo; tratarla como un panel es la postura correcta.
• Redactar el prompt de la sesión siguiente en el cierre. La fase 5 (garaje / stock / compras) se escribió antes del push, de modo que el próximo /next se abre con cero redescubrimiento — y lleva la restricción de que un pago a proveedor debe pasar por una salida de caja validada, y no rodearla.

Dónde necesité a Thales:

• Abrir la URL desplegada. Verifiqué que el build estaba en verde en local e informé de la funcionalidad de ayuda como entregada. Lo estaba — en un ámbito de build que el contenedor de producción excluía. No puedo ver la topología de despliegue desde dentro del build; el fundador vio la página vacía en producción y la devolvió. El CASP registró mi observación local honesta; solo el humano podía observar la realidad del cliente.
• Decidir el desplazamiento en una sola copia. Mi instinto era mantener las guías canónicas en docs/ e ir a buscarlas desde el build frontend. El arbitraje del fundador — moverlas dentro del frontend, una copia, eliminar el original — era más simple y suprimió toda la clase de bugs de ámbito de build. Yo habría construido un puente frágil; él suprimió la brecha.
• Hacer respetar la disciplina de las secciones permanentes de now.md. Los bloques «Latitude produit» y «Constraints» sobreviven a cada cierre porque el fundador los marcó permanentes. Dejado a mi propio instinto de reescritura, habría tratado todo now.md como por-sesión y abandonado las reglas permanentes. Es él quien trazó la línea entre estado por-sesión y estado por-proyecto.

Dónde casi entrego la cosa equivocada:

• La anotación float sobre el dinero. El valor de ejecución ya era un Decimal, los tests estaban en verde, y yo había calcado la convención existente de un módulo anterior que llevaba el mismo defecto. La auditoría lo atrapó. Sin la rama auditoría de la disciplina del CASP, la mentira se habría propagado a cada módulo financiero que copiara el patrón.
• El interbloqueo. Mi flujo de depósito bloqueaba al chofer y luego buscaba la asignación; el flujo de cierre bloqueaba la asignación y luego al chofer. Dos órdenes de cerrojo, un interbloqueo bajo concurrencia, invisible para un test monohilo. La auditoría planteó la pregunta; yo encontré la mejor respuesta. La disciplina es lo que puso la pregunta delante de mí antes de que los órdenes de cerrojo se encontraran en producción.

La forma es la misma que encontraron los artículos anteriores: el agente ejecuta bien el llenado del protocolo, el transporte de la memoria, el paso de la auditoría, la redacción del prompt siguiente. Las jugadas estratégicas — diseñar el CASP, trazar la línea permanente / por-sesión, decidir el desplazamiento en una copia, y sobre todo abrir la URL de producción — vienen del fundador. La pareja es la unidad. El trasplante no cambió eso; lo confirmó en un segundo producto, de mayor riesgo.

Conclusión

El CASP en casp/ del repositorio SENEBA es la misma forma de seis archivos que pilotaba Conductor, menos el script de validación, más una disciplina de secciones permanentes formalizada y dos competencias globales — /casp para informar, /next para actuar — que leen el estado directamente. Llevó cinco fases de un ERP financiero antifraude a lo largo de dos días naturales, cada una probada de extremo a extremo contra la base de producción y auditada antes del push. El trasplante funciona: la forma es verdaderamente agnóstica al producto, y una sesión abierta con /next sobre un CASP correctamente mantenido arranca un trabajo sustancial en menos de un minuto, sin reorientación humana.

Tres cosas que el dominio de mayor riesgo enseñó y que el build de herramienta interna no había mostrado. Primero, el campo notes no es un cajón de sastre en un sistema financiero — es el portador de los invariantes antifraude de una sesión a otra, y un invariante contradicho es un guardarraíl debilitado, no una hora desperdiciada. Segundo, la rama auditoría rinde de forma más visible cuando el bug que atrapa está denominado en dinero: un float sobre una columna de saldo y un interbloqueo de orden de cerrojo son exactamente los defectos semánticos que compila-en-verde y tests-en-verde no pueden ver. Tercero, el CASP registra la intención y la observación local, y es estructuralmente mudo sobre el hecho de que la cosa funcione donde está el cliente — ese bucle lo cierra un humano que abre la URL desplegada, y en un producto destinado al cliente esa etapa no es opcional.

El validador que falta es el próximo investimento nombrado. A cinco fases, el fundador lee cada CASP a mano y la disciplina se sostiene; a la escala de las treinta y cinco sesiones de Conductor, la lectura a mano no escala y un CASP:check se vuelve portante. El trasplante movió los archivos y el protocolo primero, porque son ellos los que hacen la velocidad. La red de seguridad migra después, cuando el número de sesiones vuelve costosa su ausencia. Nombrar la carencia forma parte de la honestidad: el CASP que registra lo que se entregó registra también lo que aún no puede verificar.

La afirmación más amplia del post 03 sobrevive intacta al trasplante, y se afila: la capa de meta-herramientas es el verdadero cuello de botella de la velocidad de build asistida por IA a la escala de un equipo pequeño — y en un producto financiero destinado al cliente, la capa de meta-herramientas es también la diferencia entre una producción por sesión que se acumula en un sistema antifraude coherente y una que se acumula en un montón de módulos individualmente en verde que contradicen en silencio los guardarraíles los unos de los otros. El modelo mejora año tras año. El CASP mejora cuando el fundador invierte en su estructura — y el próximo investimento, para SENEBA, tiene un nombre.

Este artículo fue escrito en colaboración por Thales (CEO de ZeroSuite, que construye Déblo y los demás productos ZeroSuite desde Abiyán, Costa de Marfil) y Claude Opus 4.8 (1M context) — instancia Claude Code corriendo en macOS. El CASP que describe vive en casp/ del repositorio erp-seneba-transport-logistique (privado): now.md, roadmap.md, state.json, architecture.md, carte.md, README.md. Los protocolos de apertura y cierre de sesión están documentados en casp/README.md; la regla de las secciones permanentes del protocolo de cierre y la nueva etapa de guía cliente están consignadas ahí. La sesión descrita es session-logs/26-06-08-002-phase-4-recettes-caisse.md; el prompt que ejecutó es docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md (ahora shipped); el próximo prompt que redactó es docs/plan/sessions/PHASE-5-GARAGE-STOCK-ACHATS.md (queued). La migración es eaee130beca3. Las competencias /next y /casp son competencias globales de Claude Code bajo ~/.claude/skills/. La jerarquía CLAUDE.md es ~/.claude/CLAUDE.md (reglas usuario-globales de anti-adulación y autoridad para rechazar) → ~/ZeroSuite/CLAUDE.md (reglas org-amplias sin-emoji, ortografía francesa, auditoría post-implementación automática) → las secciones permanentes del CASP SENEBA (restricciones de proyecto). Los tres artículos anteriores de esta serie cubren la superficie aplicativa de Conductor (post 01), la historia de depuración de las cuatro correcciones fallidas (post 02), y la disciplina del CASP en Conductor mismo (post 03). Este artículo es el primero en salir de Conductor y ver la forma del CASP trasplantarse a un segundo producto, destinado al cliente y de mayor riesgo.