Una capacidad externa no nace lista.

El endpoint era solo la puerta

Cuando una plataforma expone una nueva operación por API, es fácil verla como una capacidad ya lista.

El endpoint existe. La documentación explica el formato. El sistema puede llegar hasta él.

Aun así, falta una pregunta más importante: si cambio algo fuera del sistema, ¿puedo demostrar después qué ocurrió realmente?

Una evolución reciente de la integración con promociones de Shopee volvió concreta esa diferencia dentro de CM ORBE OS.

Primero, saber observar

Antes de liberar el nuevo tipo de cambio, se cerró primero la lectura necesaria para ver el estado involucrado.

El orden importa.

Si el sistema aprende a escribir antes de saber volver a leer, gana la capacidad de enviar un cambio sin ganar, al mismo tiempo, la capacidad de demostrar el efecto.

En lenguaje de API, el write es la operación que intenta cambiar el estado externo. En CM ORBE OS, encontrar ese write no cierra el trabajo.

Abre una secuencia:

operación disponible
→ lectura confiable del estado
→ primer write limitado
→ aprobación
→ ejecución
→ nueva lectura
→ reconciliación
→ evidencia suficiente para aumentar la madurez

La capacidad crece por etapas porque cada etapa responde a una pregunta distinta.

Limitar también es una decisión

El primer write no tiene por qué representar todo lo que la plataforma externa permite hacer.

En esta evolución avanzó con una frontera más pequeña.

Eso deja explícito lo que el sistema realmente sabe controlar en ese momento. El resto queda fuera de la promesa hasta que lectura, ejecución y evidencia puedan acompañar la expansión.

No es una limitación escondida. Forma parte del estado de la capacidad.

Disponible, implementado y demostrado no son sinónimos

Una operación puede existir en Shopee.

El código para usarla puede existir en CM ORBE OS.

Aun así, la capacidad puede seguir sin validación completa.

Ese tercer estado es importante porque impide que la presencia de código se convierta en un atajo hacia la madurez.

Para aumentar la confianza, no basta con señalar la implementación. Hay que añadir evidencia compatible con lo que se está prometiendo.

En el caso de una acción externa, eso incluye poder observar el estado relevante después de la ejecución y comparar lo esperado con lo que realmente apareció.

Qué cambia esta experiencia en la integración

El trabajo con promociones dejó una exigencia práctica para otras funciones de Shopee: antes de anunciar que una acción está lista, necesito saber si el sistema puede observar su estado y comprobar el resultado.

Una función puede existir en la plataforma y tener código en CM ORBE OS sin estar validada para un uso general. Ese límite debe aparecer en la descripción de la capacidad.

Hasta dónde ha llegado esta capacidad

La lectura necesaria para observar el estado se implementó antes del nuevo write. La operación avanzó con un alcance limitado y permaneció deliberadamente sin validación completa mientras faltaban pruebas suficientes en un entorno real.

Es una decisión de ingeniería documentada. No demuestra que todas las operaciones promocionales de Shopee funcionen ni que esta integración haya producido resultados comerciales medidos.

Qué falta para considerarla lista

Para ampliar esta función con seguridad, el siguiente paso no es solo escribir más código. Es reunir pruebas de que los cambios admitidos fueron aceptados, consultados de nuevo y comparados con el resultado esperado.

El nombre de una capacidad debe describir lo que realmente está demostrado, no todo lo que parece permitir la API.