TecsaS3 CLI

tecsas3-cli es el cliente CLI oficial del Ecosistema Salud TecsaS3 para entornos rurales de Colombia. Desde un solo binario puedes listar y crear pacientes, consultar y operar historias clínicas (HCE), exportar recursos FHIR, automatizar operaciones de IA y ejecutar pipelines declarativos sobre cualquier tenant — todo con --json --no-input para que cualquier agente de IA (mcode, pi, claude-code, opencode, hermes, openclaw, cursor, continue, codex) pueda operarlo de forma determinista.

Instalar y configurar el CLI

Pega este bloque en tu agente (mcode, pi, claude-code, opencode, hermes, openclaw, cursor, continue o codex) y deja que él se encargue de la instalación:
El agente ejecutará los pasos, solicitará la contraseña de forma segura (o usará la variable de entorno) y dejará la skill instalada en su carpeta de skills local.

Usar el CLI

Pega estas instrucciones en lenguaje natural a tu agente y él se encargará de mapearlas al comando correcto.

Dashboard del CLI

tecsas3 sin argumentos imprime la ayuda completa con todos los subcomandos. tecsas3 util agent-info (con --json --no-input para JSON puro) devuelve la autodescripción estructurada del CLI que consumen los agentes LLM: lista de recursos, acciones, parámetros, códigos de salida, golden paths y ejemplos conversacionales.Screenshot de tecsas3 util agent-infoEl documento devuelto contiene cuatro bloques clave:
  • resources — catálogo de los 16 recursos (auth, paciente, persona, familia, agente, riesgo, hce, fhir, examen, batch, dashboard, ia, reportes, export, pipe, util) con sus acciones y endpoints REST.
  • golden_paths — 25 flujos verificados (buscar paciente, exportar FHIR, ejecutar pipeline, etc.) con su comando canónico y versión --json.
  • agent_modes — modos soportados por el CLI: human, json, no-input.
  • examples — pares user/agent para que el LLM aprenda el contrato conversacional sin leer documentación externa.
Úsalo como punto de entrada en skills y system prompts para que el agente descubra el CLI de forma autónoma.

Resumen de capacidades

Preguntas frecuentes

El CLI no usa API keys tradicionales: usa un token DRF (legacy) o JWT (SimpleJWT) que se obtiene con tecsas3 auth login --user <USER> --password <PASSWORD> --scheme jwt. Si ya tienes un token emitido por el backend, exporta la variable TECSAS3_TOKEN=<token> y el CLI lo usará directamente, sin pasar por el login. El token se guarda después en keyring del sistema o, como fallback, en ~/.tecsas3/credentials con permisos 0600.
Tres causas habituales, en orden de probabilidad:
  1. El backend rechazó las credenciales — verifica con tecsas3 auth whoami y, si falla, repite tecsas3 auth login.
  2. Estás usando --scheme token (DRF legacy) cuando el servidor solo emite JWT, o viceversa — prueba --scheme jwt (o --scheme token según el endpoint disponible).
  3. La hora del equipo está desincronizada (NTP) y el JWT se considera expirado — sincroniza el reloj del sistema. Para inspección detallada, ejecuta con --debug para ver la traza HTTP.
Tres niveles, de mayor a menor persistencia:
  • Global: tecsas3 config set tenant <slug> (se persiste en ~/.tecsas3/config.toml).
  • Por invocación: tecsas3 --tenant <slug> paciente list o variable TECSAS3_TENANT.
  • Multi-perfil: tecsas3 --profile prod auth login … y luego --profile prod en cada llamada para aislar entornos.
Para rutas protegidas (/api/, /paciente/, /hce/api/, /eps_fhir/, /lab/api/, /agente/api/, /ia/, /facturacion/api/, /rips/api/, /billing/api/, /gestion/api/, /familia/) el CLI inyecta automáticamente los headers X-Tenant-Slug, X-Tenant-Org-ID y X-Plan-ID. Si no se resuelve el tenant, el backend responde 403 tenant_context_required.
Por defecto, el cliente HTTP aplica redacción PHI (redact_blob) antes de escribir a stderr. El flag --debug muestra método, URL, status y cuerpo (redactado) hasta 500 caracteres por línea. Para inspección profunda, usa --debug solo en entornos de desarrollo y nunca dirijas su salida a logs persistentes sin un sink que también redacte.
Sí. El cliente usa httpx y respeta las variables estándar HTTPS_PROXY, HTTP_PROXY, NO_PROXY y SSL_CERT_FILE/SSL_CERT_DIR. Para certificados corporativos autofirmados en redes controladas, desactiva la verificación TLS con tecsas3 config set verify_tls false. La conexión sigue siendo HTTPS: el CLI rechaza http:// salvo para localhost. Si tu proxy requiere autenticación NTLM o Kerberos, expórtala en HTTPS_PROXY como http://user:pass@proxy.corp:8080.
Reinstala el wheel con pip:
Verifica con tecsas3 --version. La versión se incluye en el header User-Agent de cada request (tecsas3-cli/0.4.1) para que el backend pueda correlacionar trazas por versión. Si usas uv o pipx, el comando equivalente es uv tool upgrade tecsas3-cli o pipx upgrade tecsas3-cli. El changelog vive en cli/CHANGELOG.md del repositorio.