El reto final no consiste en declarar un bot «listo para producción». Consiste en demostrar que entiendes y puedes adaptar un bot de catálogo preescrito, determinista y de solo lectura. Tienda Luna sigue siendo ficticia: una pregunta de precio o stock obtiene datos del archivo que tú verificas, no de un ERP ni de WhatsApp.
Objetivo: demostrar que puedes adaptar y comprobar un bot de catálogo preescrito, determinista y de solo lectura.
Suite offline del kit
Necesitas Python 3.10+ y la carpeta extraída. La suite usa fixtures, SQLite temporal y transportes falsos; no envía mensajes ni llama a un modelo.
PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -v
Un test verde demuestra el comportamiento de la copia y sus dobles. No demuestra que Telegram, Kapso, HTTPS, una cuenta de modelo o un inventario real estén disponibles.
Ejercicio: tu comprobación y tu archivo
Escribe una verificación pequeña para un archivo propio. El ejemplo crea un JSON temporal con un SKU ficticio y comprueba el contrato; cambia el dato sin actualizar lo esperado y la comprobación debería fallar, que es justo lo que hace útil una prueba.
CAPSTONE="$(mktemp -d)"
cp catalogo.json "$CAPSTONE/mi_catalogo_capstone.json"
python3 - "$CAPSTONE/mi_catalogo_capstone.json" <<'PY'
import json, sys
from catalogo_core import load_catalog, respond
path=sys.argv[1]
data=json.loads(open(path, encoding="utf-8").read())
data["items"].append({"sku":"L-901","name":"Sticker Luna","category":"regalos","description":"SKU ficticio de capstone","price_cents":300,"stock":12})
with open(path,"w",encoding="utf-8") as f: json.dump(data,f,ensure_ascii=False)
catalog=load_catalog(path)
result=respond("stock L-901", catalog=catalog)
assert result["status"] == "ok"
assert result["items"] == ["L-901"]
assert "12 unidades" in result["text"]
assert any(step["op"] == "read_stock" for step in result["trace"])
print("Reto final OK: comprobaciones sobre archivo local")
PY
Tu entrega: conserva mi_bot.py y mi_catalogo.json del taller 2. Crea test_mi_bot.py con una clase de unittest y tres casos propios: SKU existente, agotado y desconocido. Puedes seguir la estructura de test_core.py, pero importa tu función consultar_mi_catalogo. Ejecuta python3 -m unittest test_mi_bot -v; deben descubrirse tres pruebas, no cero. Explica qué dato haría fallar cada una y conserva también un ejemplo de fallo esperado. Este trabajo lo escribes tú; el bloque anterior es solo una referencia ejecutada, no sustituye tu entrega.
Lista de comprobación
Lo que debes documentar si haces un ensayo real
Anota qué observaste y en qué modo:
- offline: núcleo, fixtures, tests y SQLite local sin red;
- dry-run: intención preparada, sin POST de salida;
- live: llamada real autorizada, con cuenta y destinatario de prueba.
Antes de un ensayo live revisa allowlist, secretos, destino, firma raw-body, persistencia antes del ACK y el plan para unknown. No uses compras, reservas, pagos, campañas ni datos de clientes con este kit.
Resultado observable
Puedes ejecutar la suite, verificar un archivo propio, explicar las dos máquinas de estados y enumerar los supuestos no validados. Eso es utilidad práctica: un punto de partida pequeño para leer/adaptar un flujo de consulta, no una promesa de sincronización, ROI ni producción.
Error habitual y recuperación
Ran 0 tests no demuestra nada: revisa que el archivo sea test_mi_bot.py, que la clase herede de unittest.TestCase y que sus métodos empiecen por test_. Si un caso falla, contrasta primero el JSON propio con la expectativa. No cambies catalogo.json para hacer pasar pruebas de tu adaptación: esas pruebas deben llamar a consultar_mi_catalogo.