Personal Cronometer MCP

Este es un puente local y personal entre Cronometer y clientes MCP como Codex y Claude Code. Combina la útil cobertura de cuentas en vivo del cliente cronometer-mcp de Paul Hoskins con una capa de TypeScript más estricta que conserva los datos nutricionales faltantes, etiqueta honestamente las acciones que cambian la cuenta y mantiene las credenciales fuera de los archivos de configuración de MCP.

Es un proyecto personal de aprendizaje creado por un entrenador certificado en nutrición deportiva por la NASM (CSNC) que también ha realizado cursos universitarios de nutrición fuera de su especialidad principal. Estos antecedentes orientan las prioridades del proyecto, pero este software no es un dispositivo médico ni un sustituto de la atención médica.

Proporciona acceso completo en vivo respaldado por el cliente fijado: lectura y escritura del diario de alimentos, resúmenes de nutrientes con conocimiento de cobertura, exportaciones CSV sin procesar, búsqueda de alimentos, objetivos y horarios de macronutrientes, registros de ayuno, biométricos, copia/finalización de días y alimentos repetidos.

Límites importantes

• Esta es una herramienta personal no oficial. Cronometer no proporciona ni respalda esta interfaz. Un cambio en el sitio web de Cronometer puede romperla sin previo aviso, y el acceso automatizado puede poner en riesgo la cuenta. Lea los Términos de servicio actuales de Cronometer antes de habilitarla.

• Algunas funciones de exportación CSV pueden requerir Cronometer Gold. Cronometer documenta su flujo de exportación manual compatible en Configuración de la cuenta: Exportación de datos.

• Esto informa de lo que se registró y de lo completo que está el registro. No es un dispositivo médico, no diagnostica deficiencias de nutrientes y no proporciona consejo médico.

• Manténgalo local. El proyecto deliberadamente no tiene servidor HTTP, modo de implementación remota, telemetría ni herramienta arbitraria de ejecución de código.

Qué hace que el resumen de nutrientes sea más seguro

El resumen diario de Cronometer tiene una trampa sutil: una celda de nutriente vacía significa «sin datos», mientras que un cero mostrado significa un cero registrado. Su fila Total puede colapsar las celdas faltantes en cero. Este servidor analiza las filas de los grupos del diario por sí mismo, calcula la cobertura de cada nutriente y solo devuelve un valor de ingesta cuando se cumple el umbral de cobertura solicitado. Con el umbral predeterminado de 1, cada celda de grupo del diario para ese nutriente debe contener datos.

Por lo tanto, un resultado de nutriente tiene una de dos formas:

• kind: "value" — incluye el valor, la unidad, la cobertura del grupo, la cobertura del día y la comparación con el Total de Cronometer.

• kind: "insufficient-data" — incluye la cobertura y un límite inferior explícitamente nombrado observedSubtotal, pero no puede expresar ese subtotal como ingesta.

Esa distinción se mantiene desde el análisis del CSV hasta la salida final de MCP.

Cada lectura del diario se analiza aquí, no aguas arriba

El cliente fijado lee un CSV con csv.DictReader y devuelve filas de cadenas sin tipo. Eso está bien como transporte, pero es inútil como modelo de tu diario, por lo que este servidor no lo utiliza. cronometer_get_food_log, cronometer_get_exercises, cronometer_get_biometric_log y cronometer_get_notes obtienen cada uno la exportación sin procesar y la analizan aquí en su lugar. Lo que esto te aporta:

• 1.00 container - each 5.3 oz se devuelve como una cantidad y una unidad, no como una cadena que haya que adivinar después.

• Una duración de ejercicio en blanco se notifica como faltante, no como cero minutos.

• Las unidades se mantienen tal como las muestra tu cuenta. No se convierte nada.

• Una fila que no se puede leer se descarta y se notifica, con el archivo y la línea, de modo que una lista corta nunca es corta silenciosamente.

• Una hora que nunca se registró es null, nunca medianoche.

Hay una negativa deliberada que conviene conocer. Si la exportación de Cronometer pierde alguna columna que este servidor necesita, el analizador devolvería cero filas, lo que se vería exactamente como un día en el que no registraste nada. En lugar de devolver eso, la llamada falla y nombra la columna que falta. Una respuesta vacía aquí sería el mismo tipo de error que leer un nutriente ausente como cero.

La misma regla se aplica ahora a las lecturas en vivo que no pasan por un CSV. Si una de ellas devuelve vacío en una forma que el conector no reconoce, el resultado lleva unverified: true, lo que significa «vacío, y no pude confirmarlo». Una llamada que realmente falla lanza una excepción en su lugar, por lo que la marca está reservada para el único caso realmente ambiguo: una respuesta que nombra datos que luego no puede encontrar.

Acertar con ese límite requirió dos pasadas. La primera marcó todos los resultados vacíos como no verificados, razonando que un marcador de tipo de elemento faltante podría significar que el formato había cambiado. Al comprobar las respuestas reales se vio lo contrario: una colección vacía no tiene tipo de elemento porque no tiene elementos. Así que la advertencia se disparaba con respuestas correctas, que es como una advertencia se convierte en ruido. Ahora solo se dispara cuando la respuesta contiene algo que el analizador no pudo leer.

Las llamadas en vivo también están espaciadas, al menos un segundo entre ellas. Es imperceptible mientras lees las respuestas, y es la diferencia entre una conversación y un raspado (scraping).

Una cosa que debes evitar al configurar tu diario: no llames Total a un grupo del diario. Cronometer escribe su propio total diario en la misma columna que los nombres de tus grupos, y la exportación no ofrece forma de distinguirlos. Un grupo con ese nombre se leería como el total del día y se excluiría de la suma, por lo que sus alimentos desaparecerían silenciosamente de cada cifra de ingesta. Cualquier otro nombre está bien.

Las celdas de nutrientes también se leen de forma estricta. Una celda debe estar vacía o ser un decimal no negativo simple; cualquier otra cosa (texto, separador de miles, número negativo) se registra como faltante con una nota que indica la columna y la línea, en lugar de convertirse en un número que cambiaría silenciosamente un total.

Configuración en Windows

Abra PowerShell y ejecute:

Set-Location C:\dev\cronometer
.\scripts\setup-windows.ps1

En macOS el equivalente es sh scripts/setup-macos.sh, que hace lo mismo en el mismo orden; consulte Otras plataformas para ver qué está probado allí y qué no.

La configuración hace lo siguiente:

1. Reinstala las dependencias de Node bloqueadas.

2. Crea o actualiza un entorno privado de Python 3.12 a partir de un archivo de bloqueo de cinco paquetes verificado por hash (requests y sus cuatro dependencias transitivas; el cliente de protocolo está integrado (vendored), no instalado).

3. Compila el servidor y ejecuta todas las pruebas sin conexión.

4. Pregunta por la zona horaria del diario de Cronometer. America/New_York es el valor predeterminado recomendado para este equipo.

5. Muestra la advertencia de interfaz no compatible y exige la palabra exacta ENABLE antes de activar el acceso en vivo.

6. Solicita el nombre de usuario y la contraseña de Cronometer. Windows DPAPI cifra la contraseña para la cuenta de Windows actual; no se escribe en este repositorio, en una línea de comandos, en la configuración de Codex ni en la configuración de Claude.

7. Ofrece registrar el servidor con cada cliente que encuentre instalado: Codex, Claude Code y Claude Desktop. Se pregunta por cada uno por separado, y omitir uno no afecta a los demás.

   • Codex también recibe default_tools_approval_mode = "writes" escrito en su config.toml, de modo que cada herramienta no marcada como de solo lectura solicita aprobación. Si ese paso falla, la configuración lo dice claramente en lugar de dejarte con un servidor registrado que no pregunta.

   • Claude Code no necesita configuración de aprobación; consulte Seguridad de escritura para saber por qué.

   • Claude Desktop no tiene CLI para esto, por lo que su claude_desktop_config.json se edita directamente. El archivo anterior se respalda primero, cualquier servidor que ya tuvieras se conserva y una entrada existente de cronometer-personal nunca se sobrescribe.

Reinicie el cliente MCP después del registro. Comience con:

Llame a cronometer_status y luego compruebe la conexión con Cronometer. No cambie nada.

La primera conexión real puede tardar más porque inicia sesión y crea una sesión. Las conexiones posteriores reutilizan una caché de sesión JSON validada.

La cobertura de nutrientes requiere una exportación descargada

Esta es la parte que vale la pena entender, porque decide qué herramienta responde a una pregunta sobre nutrientes.

Cronometer ofrece los mismos datos de dos maneras, y no son equivalentes:

La cobertura funciona comparando comidas. Si la celda de omega-3 del almuerzo está en blanco mientras el desayuno indica 0.00, eso es una laguna en la base de datos, no una ingesta de cero. La exportación en vivo ya ha colapsado esas comidas en un solo número, y ese número es precisamente el que contó los espacios en blanco como cero. Por eso el resumen en vivo ahora rechaza la pregunta y apunta aquí en lugar de devolver algo que parezca una respuesta.

En un día real de esta cuenta, con cobertura completa: 16 de 61 nutrientes pudieron notificarse como números. Los otros 45 fueron rechazados, todos ellos casos en los que el total de Cronometer había sumado datos ausentes como cero. La energía y las proteínas coincidían exactamente con Cronometer y son fiables. El omega-3 marcó 0.01 g — en un día con salmón — procedente de solo dos de las cuatro comidas.

Para usarlo: en Cronometer, Configuración → Cuenta → Exportar datos, descargue y extraiga los CSV en una carpeta con fecha dentro del directorio de exportaciones que configura el lanzador (%LOCALAPPDATA%\CronometerPersonalMcp\exports\2026-08-16\, etc.). cronometer_list_exports muestra lo que puede ver. Cada exportación es una instantánea, por lo que mantenerlas con fecha construye el historial que necesita el análisis de varios meses.

Dos cosas sobre ese directorio. Se encuentra dentro de la misma carpeta protegida por ACL que sus credenciales, porque una exportación es todo su diario por comida. Y el servidor nunca acepta una ruta: una herramienta pasa un nombre de carpeta, que se resuelve y se comprueba que esté dentro de ese directorio, de modo que nada fuera de él pueda leerse ni siquiera a través de un enlace simbólico.

Registrar alimentos

Verificado de extremo a extremo el 2026-08-17: buscar, añadir, releer, eliminar, releer.

Requiere dos pasos, porque una entrada del diario se identifica por una medida en lugar de por un alimento:

1. cronometer_search_foods — devuelve food_source_id (el alimento) y food_id (su medida predeterminada), además de una descripción como 1 large - 50g que indica cuánto pesa uno de ellos.

2. cronometer_add_food_entry — pase ambos identificadores, measure_id: 0, el número de medidas como quantity y el peso total real como weight_grams.

cronometer_get_food_details enumera cada medida que tiene un alimento con su peso en gramos, de modo que puedes calcular weight_grams para «dos grandes» o «media taza» sin adivinar.

Una limitación real. servings.csv no incluye un identificador de ración, por lo que cronometer_get_food_log no puede devolver uno, y cronometer_remove_food_entry lo necesita. En la práctica, solo puedes eliminar una entrada cuyo ID aún tengas de haberla registrado en la misma conversación. Para eliminar algo registrado anteriormente, o registrado en la aplicación, usa la aplicación de Cronometer. Esta es una laguna en lo que expone la exportación, no algo que el conector pueda solucionar.

Lo que se ha verificado realmente

Las herramientas se agrupan por evidencia, no por intención. Todo lo siguiente se probó contra una cuenta real el 2026-08-17.

Funcionamiento verificado. Búsqueda de alimentos, detalles de alimentos, el diario de alimentos y las demás lecturas basadas en CSV, el análisis de exportaciones descargadas, lista/creación/eliminación de plantillas de macros, añadir/eliminar elementos repetidos, añadir/quitar biométricos para peso, y añadir y luego eliminar una entrada de alimentos.

Verificado que no funciona, y rechazado en lugar de intentado.

• cronometer_add_biometric acepta solo peso. Pedir una frecuencia cardíaca de 60 creó una entrada de Peso de 60 lb — la codificación de métrica para las otras tres es una suposición, y body_fat comparte la codificación de weight byte a byte, por lo que debe archivar incorrectamente de la misma manera. Una escritura que archiva silenciosamente datos bajo la métrica equivocada corrompe una tendencia que lees más tarde y no da señal de que ocurrió, por lo que las otras métricas se rechazan. Regístralas en la aplicación Cronometer.

• cronometer_set_day_complete falla: Cronometer ha eliminado el método setDayComplete, de la misma manera que eliminó findFoods. Nada local puede arreglarlo.

Corregido tras una prueba en vivo. cronometer_get_repeated_items solía devolver food_source_id y measure_id transpuestos, una lista de días de la semana siempre vacía y un grupo de diario de 0. Ahora lee la respuesta de la manera en que el protocolo realmente la escribe — de atrás hacia adelante — e informa los días de la semana correctamente.

El grupo de diario se informa como null, porque Cronometer no lo envía de vuelta: dos reglas creadas en grupos diferentes devolvieron respuestas idénticas salvo por sus ids, cantidad y días de la semana. El grupo que eliges al crear una regla se aplica, pero no puede leerse de vuelta. null dice eso; 0 habría parecido un grupo real.

Nunca probado. copy_day (copia un día completo y no puede deshacerse limpiamente, porque los IDs de servicio no se pueden leer de vuelta desde la exportación), set_macro_targets y set_macro_schedule_day (Cronometer calcula objetivos recomendados a partir de tu perfil y establecerlos anula ese cálculo — no es algo que se haga como prueba), y las dos herramientas de ayuno (no hay herramienta de crear ayuno, por lo que no hay nada que eliminar o cancelar).

Seguridad de escritura

Las herramientas de lectura y escritura están deliberadamente separadas. Toda herramienta que cambia la cuenta está marcada como no de solo lectura, y toda herramienta marcada como destructiva rechaza la llamada a menos que esté presente confirm: true.

La aprobación funciona de manera diferente en cada cliente, así que esto es exactamente lo que obtienes en cada uno:

El caso de Claude Code es el más sólido, porque el requisito viaja con la herramienta en lugar de vivir en un archivo de configuración que podrías cambiar más tarde. Los demás dependen de la configuración del cliente: el script de configuración establece el de Codex y te avisa en voz alta si no puede. Las versiones antiguas de Claude Code ignoran la marca y recurren a su manejo de permisos normal, al igual que otros clientes MCP — una clave _meta desconocida es inofensiva, por eso se envía incondicionalmente.

Las herramientas de lectura deliberadamente no llevan esa marca. Una comprobación de estado que insistiera solo te enseñaría a hacer clic en los avisos sin leerlos.

Las escrituras nunca se reintentan automáticamente. Si una escritura se agota, el servidor informa que su resultado es desconocido. Inspecciona la aplicación Cronometer antes de decidir si intentarlo de nuevo; de lo contrario, un reintento podría duplicar alimentos, biometrías, plantillas o elementos repetidos.

Registro manual de MCP

La configuración normalmente ofrece hacerlo. Si lo omitiste, el comando contiene solo la ruta del lanzador local, nunca credenciales.

Codex:

codex mcp add cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

Luego añade esta línea dentro de la nueva sección [mcp_servers.cronometer-personal] de %USERPROFILE%\.codex\config.toml:

default_tools_approval_mode = "writes"

Claude Code, disponible para el usuario de Windows en todos los proyectos:

claude mcp add --scope user cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

Claude Desktop no tiene comando de registro. Añade esto al objeto mcpServers en %APPDATA%\Claude\claude_desktop_config.json, conservando cualquier servidor que ya esté allí, y reinicia Desktop:

"cronometer-personal": {
  "command": "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
  "args": ["-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "C:\\dev\\cronometer\\scripts\\run-mcp.ps1"]
}

Usa la ruta real a pwsh.exe en esta máquina — (Get-Command pwsh).Source la imprime. Haz una copia de seguridad del archivo antes de editarlo: contiene las propias preferencias de Claude Desktop además de la lista de servidores, y una mala edición las pierde. El script de configuración hace todo eso por ti, que es la mejor vía.

Comprueba el registro con codex mcp get cronometer-personal o claude mcp get cronometer-personal. La guía de MCP de Claude Code actual de Anthropic explica sus ámbitos de configuración y las reglas de permisos que se aplican a las herramientas MCP. Codex usa la misma configuración MCP para su CLI y su extensión de IDE; consulta la documentación de MCP de OpenAI.

Empaquetar esto como una Extensión de escritorio (.mcpb/.dxt) eliminaría el paso de edición manual, pero un paquete de extensión también tendría que incluir el aviso de credenciales y el entorno Python. Eso no está construido; la ruta de lanzador más configuración descrita arriba es lo que admite este repositorio.

Límite de credenciales y red

• scripts/run-mcp.ps1 descifra la contraseña protegida por DPAPI y se la pasa al servidor a través de variables de entorno. Sé claro sobre lo que eso cuesta: el lanzador se ejecuta durante el mismo tiempo que la sesión MCP y, mientras se ejecuta, la contraseña en texto plano está presente en el entorno de tres procesos: el lanzador, Node y el hijo de Python. Nunca se escribe en disco en claro, nunca se coloca en una línea de comandos y nunca se almacena en un archivo de configuración MCP, pero cualquier proceso que se ejecute como este usuario de Windows podría leerla. Ese es el precio por no escribir una contraseña en un archivo de configuración.

• El hijo de Python reemplaza la sesión pickle ejecutable existente por JSON con verificación de tamaño y lo almacena en el directorio privado de datos de aplicación. En Windows, ese directorio está protegido por una ACL que aplica el script de configuración: herencia rota, una única regla de acceso para tu propia cuenta y ninguna entrada para SYSTEM ni para el grupo de administradores. Dos capas lo protegen, y comprueban cosas diferentes. El lanzador lee la ACL real en cada inicio y se niega a ejecutarse si el directorio se ha vuelto heredable o ha ganado cualquier otra identidad. El puente de Python no puede leer una ACL de Windows sin paquetes adicionales, por lo que solo se niega a ejecutarse cuando CRONOMETER_DATA_DIR no está definido: suficiente para evitar que la cookie de sesión recurra a un valor predeterminado no protegido en el directorio de inicio, pero no es una comprobación de los permisos en sí. Si inicias el servidor de cualquier otra forma que no sea a través del lanzador, obtienes la más débil de las dos.

• La sesión de red acepta solo solicitudes HTTPS cuyo host exacto sea cronometer.com, incluidos los redireccionamientos. Las variables de entorno de proxy y certificados no se pasan al hijo, por lo que un proxy de toda la máquina no puede interponerse.

• Las llamadas se serializan, las fechas y los identificadores se validan dos veces, y cualquier resultado de herramienta de más de 2 MB se rechaza en lugar de truncarse silenciosamente: pide un rango de fechas más corto.

• Los nombres de alimentos, notas, errores del sitio web y cualquier otro texto en vivo se devuelven dentro de un límite explícito de datos no confiables, codificado en JSON para que el texto no pueda falsificar el final de ese límite. Nunca deben tratarse como instrucciones.

Herramientas útiles

Las 32 herramientas MCP se agrupan conceptualmente de la siguiente manera:

• Conexión: comprobación de estado y conexión.

• Exportaciones descargadas: listarlas y ejecutar el análisis de nutrientes consciente de la cobertura sobre una. Estas leen una carpeta en este equipo y nunca tocan la red.

• Diario: registro de alimentos, ejercicio, historial biométrico, notas, resumen nutricional consciente de la cobertura, exportación CSV sin procesar, añadir/eliminar alimentos, copiar un día y marcar un día como completo.

• Base de datos de alimentos: búsqueda y detalles de alimentos.

• Macros: leer objetivos/horarios, establecer objetivos diarios, listar/crear/eliminar plantillas y asignar una plantilla a un día de la semana.

• Ayuno: historial, estadísticas, eliminar un ayuno y cancelar un ayuno activo conservando su serie.

• Biometrías: leer valores recientes, añadir un valor y eliminar un valor.

• Alimentos repetidos: listar, añadir y eliminar reglas.

Intencionadamente no hay ninguna herramienta arbitraria de solicitud GWT, automatización de navegador, SQL sin procesar, ejecución de shell, sincronización automática en segundo plano ni transporte HTTP remoto.

Verificación de desarrollo

Todas las pruebas son sin conexión y usan datos sintéticos:

npm run verify      # typecheck, TypeScript, Python, and the setup scripts

Eso son 450 pruebas TypeScript, 45 de Python y 24 comprobaciones de configuración. Los pasos individuales son npm run typecheck, npm test, npm run test:python y npm run test:setup; el último se omite a sí mismo en voz alta donde PowerShell está ausente, en lugar de fallar por una razón no relacionada con el código que se está comprobando.

npm test compila primero y comprueba tanto el MCP heredado como el handshake moderno de stdio 2026-07-28. La suite de protocolo llama a todas las herramientas contra un puente falso, verifica las etiquetas de permisos de las herramientas, comprueba que toda herramienta destructiva rechace una llamada no confirmada, garantiza que los manejadores de lectura no puedan alcanzar métodos de mutación, y pasa texto hostil multilínea por las rutas de éxito y de error para demostrar que ninguna puede falsificar el final del límite de datos no confiables.

Dos límites honestos sobre lo que muestran esas pruebas. El esquema de salida genérico tipifica deliberadamente data como desconocido, porque la forma de una respuesta en vivo la decide Cronometer — así que «validar contra el esquema de salida» es una comprobación real solo para el resumen nutricional, que es la única herramienta con un resultado completamente especificado. Y cada prueba es sin conexión: demuestran que el envoltorio se comporta, no que la interfaz no documentada siga funcionando.

La única comprobación en vivo que debería ejecutarse de forma casual es la comprobación de conexión. No pruebes herramientas de escritura contra la cuenta real a menos que el cambio de cuenta previsto sea en sí la prueba.

Una nota sobre dos archivos que este repositorio no contiene

Partes del código fuente y de la auditoría de seguridad se refieren a CLAUDE.md y AGENTS.md. Esos son archivos de trabajo para los asistentes de IA utilizados para construir este proyecto, y permanecen en la máquina en lugar de en el repositorio — están escritos para un asistente en lugar de para un lector, y llevan contexto personal que se lee mal si se elimina.

Nada esencial está oculto por eso. Las reglas de diseño que declaran son visibles donde se aplican: el tipo de falta-versus-cero en src/domain/nutrient.ts, las anotaciones de escritura en src/mcp/registry.ts, la valla de datos no confiables en src/mcp/server.ts, el límite de red en python/live_bridge.py. El razonamiento detrás de ellas está en BUILD_PLAN.md, DATA_MODEL.md y la auditoría de seguridad, todos dirigidos a una persona. Las referencias a los dos archivos ausentes se dejan tal como están escritas en lugar de eliminarse editándolas, porque la auditoría en particular es un registro fechado y reescribir silenciosamente sus citas la haría menos confiable, no más.

Otras plataformas

macOS está construido: scripts/setup-macos.sh y scripts/run-mcp.sh reflejan el par de Windows paso a paso, almacenando la contraseña en el llavero de inicio de sesión en lugar de DPAPI y protegiendo el directorio de datos con modo 700 en lugar de una ACL. Todo lo demás es el mismo código.

Ser claro sobre el estado de la cosa, porque importa más que la afirmación:

Las partes de la ruta de macOS que son código ordinario — el escritor de configuración de Claude Desktop, el validador de configuración, todos los analizadores — están cubiertas por pruebas que se ejecutan en macOS en CI en cada push. Lo que nunca se ha probado en un Mac es la parte que lo necesita: la solicitud de Keychain, la denegación del modo directorio y una lectura y escritura reales. MACOS.md enumera esas cuatro comprobaciones explícitamente y dice cuál es más probable que revele una diferencia.

Linux recibe el lanzador de forma gratuita, ya que toma la rama no Darwin para su directorio de datos y la comprobación de permisos, pero no hay script de instalación y nadie lo ha ejecutado.

Procedencia y licencia

La implementación del protocolo GWT-RPC comenzó como el cronometer-mcp 2.0.3 de Paul Hoskins, con licencia MIT. Ahora está vendorizado y modificado en python/vendor/cronometer_client.py en lugar de instalarse desde PyPI, con su aviso de copyright conservado en THIRD_PARTY_NOTICES.md como exige la licencia.

Ese cambio se hizo en agosto de 2026, por una razón específica. El último commit de upstream fue el 8 de marzo de 2026. Para agosto tenía ocho incidencias abiertas y cuatro pull requests sin fusionar — dos de ellos corregían un cambio de Cronometer que ya había roto por completo la búsqueda de alimentos, y con ella la capacidad de registrar alimentos en absoluto. Una dependencia fijada no se puede parchear. El vendorizado de la dependencia hizo que esas correcciones pudieran aplicarse, y significa que la próxima rotura se puede arreglar aquí en lugar de solo poder notificarse en otro lugar.

Cada diferencia deliberada con respecto al original está listada en la cabecera del archivo vendorizado, y dos de ellas están adaptadas de pull requests de otros contribuyentes, acreditados en los avisos. La propia ingeniería inversa del protocolo es obra de Paul Hoskins y sigue siendo la parte difícil de este proyecto.

requests es ahora la única dependencia de ejecución que este proyecto no posee.

El código propio de este proyecto tiene licencia MIT; ver LICENSE.