Parche — Dependabot para APIs

In English. Parche reads your code and inventories every third-party API it uses: SDKs, direct HTTP calls and AI model IDs. When a provider ships a dated change that affects you, it tells you the file and the line, or opens a small PR with a deterministic fix. Every changed file is parsed before the PR, and with --verify your own tests run too. What can't be inferred is never made up: the PR asks for it. Today's packs cover Argentina's ARCA e-invoicing change (due December 1, 2026), Mercado Pago Payments → Orders, and OpenAI and Anthropic model and parameter deprecations.

Try it with npx parche-cli scan . (Node 22+): it runs locally, with no account and no telemetry (security and data). GitHub Action: quick start below. The rest of this README is in Spanish for now · getparche.com · hola@getparche.com

GitHub Action quick start

Copy templates/github-workflow.yml to .github/workflows/parche.yml. Every Monday it installs your dependencies (so your tests can run) and runs Parche, which opens one PR per API change that affects the repo, as a draft if something needs a human, and lists everything else in the job summary. The job needs contents: write and pull-requests: write, and the repository (or its organization) needs Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests" turned on: it's off by default for new personal repositories and new organizations. Step by step, with private repositories and what to do if a run fails: installation guide (Spanish, with an English summary). The key step:

- uses: Pepo08/parche@v0
  with:
    verify: 'true'   # run your tests before opening each PR

Input	Default	What it does
path	.	Folder to scan.
pack	all packs	Run a single pack (list them with npx parche-cli packs).
verify	'true'	Run the repo's tests (npm test, composer test or vendor/bin/phpunit) before opening each PR.
dry-run	'false'	Build the branches and PR bodies without opening any PR.
token	github.token	Pushes the branches and opens the PRs. With the default GITHUB_TOKEN, GitHub holds the PR's workflows until someone approves them; with a GitHub App token or a personal token they run on their own.
snapshot	'true'	Save a snapshot of the run (API inventory, findings and the PRs it opened, as JSON; no source code) as a workflow artifact.
snapshot-name	parche	Artifact name. Use a different one for each step if you call the Action more than once in a workflow.
summary	'true'	Build the weekly summary (an email-style HTML and plain-text digest, in Spanish) from the snapshot, add it to the job summary and save it in the artifact. It's not emailed anywhere. To compare with the previous week the job needs actions: read.

@v0 follows every 0.x release; to pin one, use its release commit: Pepo08/parche@<sha> # v0.7.2. PR bodies and the job output are in Spanish for now.

Parche lee tu código y arma el inventario de todas las APIs de terceros que usás: SDKs (Stripe, Twilio, OpenAI, AWS, Mercado Pago, ARCA…), llamadas HTTP directas y modelos de IA. Lo cruza contra una base de cambios de API verificados y, cuando un proveedor cambia algo que te afecta, te avisa o abre un PR con el arreglo, explica qué cambió y por qué, y marca lo que necesita una persona. Ningún PR sale sin pasar la verificación. Las APIs de pagos y facturación de Latinoamérica son el fuerte, pero el inventario cubre cualquier API.

$ parche scan .
APIs del repo (6):
  SDK   Anthropic · @anthropic-ai/sdk          alta   messages.create  · con pack
  SDK   ARCA (ex AFIP) · @afipsdk/afip.js      alta   ElectronicBilling.createNextVoucher ×3  · con pack
  SDK   Mercado Pago · mercadopago             alta   Payment.create ×3, Payment.get  · con pack
  SDK   OpenAI · openai                        alta   beta.assistants.create  · con pack
  IA    Anthropic · modelos                    alta   claude-3-5-haiku-20241022  · con pack
  IA    OpenAI · modelos                       alta   gpt-4o  · con pack

■ Condición frente al IVA del receptor obligatoria en WSFEv1
  ARCA (ex AFIP) · severidad critical · vence 2026-12-01 (46 días)
  ✅ automático     src/facturacion.js:14  Agregado CondicionIVAReceptorId: 5 (Consumidor Final)…
  👀 revisar       src/facturacion.js:56  Agregado CondicionIVAReceptorId: 5 por inferencia (DNI + comprobante B/C)…
  ✋ falta un dato  src/facturacion.js:62  Falta CondicionIVAReceptorId y no se puede inferir… (comprobante clase A).

■ Modelos, endpoints y parámetros de IA retirados o por retirarse
  🔎 detectado     src/ia.js:9  El modelo `claude-3-5-haiku-20241022` fue retirado el 2026-02-19: las llamadas ya fallan…
…

El inventario completo (con operaciones, ubicaciones y nivel de confianza) queda en .parche/inventory.json; el formato está en docs/inventario.md. Para ver un repo con APIs de todo tipo, desde este repo: node bin/parche.js scan examples/saas-demo.

Por qué packs y no "un LLM que arregla todo"

Ya hay varios prototipos que le piden a un modelo que lea un changelog y escriba el fix. El problema es que el modelo solo sabe lo que aprendió en su entrenamiento, y una migración de pagos o de facturación no admite "casi bien". Parche separa las dos cosas:

• El pack es dato, no prompt. Cada cambio de API es un JSON versionado con fuente, fecha límite, reglas de detección, mapeo de campos, casos bloqueados y checklist de revisión (ver packs/). Un LLM puede ayudar a redactar un pack a partir de un changelog, pero una persona lo verifica antes de publicarlo.
• El arreglo es determinístico. Los codemods trabajan sobre el AST, respetan el formato del cliente (el diff de ARCA es de 2 líneas por factura) y son idempotentes.
• Lo que no se puede inferir, no se inventa. Si falta un dato del negocio (¿este cliente con CUIT es Responsable Inscripto o Monotributo?), el PR lo dice y muestra los valores válidos.
• Cada PR mergeado, editado o rechazado vuelve como señal (.parche/ledger.jsonl, parche feedback). Eso es lo que hace que la base mejore con el uso.

Uso

Requiere Node 22 o más nuevo. El paquete de npm se llama parche-cli; si lo instalás (npm i -g parche-cli), el comando es parche.

npx parche-cli packs                 # cambios que Parche conoce
npx parche-cli scan .                # inventario + qué te afecta (.parche/report.md)
npx parche-cli scan . --upgrades     # + qué cambia en las versiones nuevas de tus SDKs
npx parche-cli diff <paquete> --from <v> --to <v>   # qué cambia en la API de un paquete
npx parche-cli fix .                 # aplica los arreglos en tu working copy
npx parche-cli pr . --verify         # una rama + commit + PR por cambio
npx parche-cli feedback . --pack <id> --outcome merged|edited|rejected

parche pr abre el PR por la API de GitHub si hay GITHUB_TOKEN y un remote origin en github.com; si no (o con --dry-run), deja la rama, el commit y el cuerpo del PR en .parche/pr-<pack>.md. Si hay ítems para revisar, el PR se abre como borrador.

• Desde un fork: parche pr . --push-remote fork pushea la rama al remote fork (tu fork, con tus credenciales de git) y abre el PR contra origin.
• Nunca deja el repo sucio: si la verificación falla, descarta lo que escribió y borra su rama. Si no hay cambios de código, o solo cambiarían tests o mocks, no abre PR: deja el texto como issue en .parche/.
• .parche/ no va en git: es lo que Parche escribe en cada corrida (el reporte, el inventario, el registro y los cuerpos de los PRs), y lo agrega a .git/info/exclude. Si ya lo commiteaste (por ejemplo, copiando una carpeta escaneada a un repo nuevo), Parche funciona igual: no lo cuenta como un cambio sin commitear, nunca lo incluye en sus PRs y te avisa. Para dejar de versionarlo: git rm -r --cached .parche y sumá .parche/ al .gitignore.

Qué cambia en las versiones nuevas de tus SDKs

--upgrades compara, para cada SDK de npm que usás, la versión instalada con la última publicada. Lee los tipos (.d.ts) de las dos versiones y te dice qué operaciones de tu código desaparecen, piden parámetros nuevos, cambian de tipo o pasan a deprecadas. Solo avisa: no toca código.

$ npx parche-cli scan . --upgrades
…
Versiones nuevas de tus SDKs de npm:
  openai                 3.3.0 → 7.34.0       ⚠ 2 de tus operaciones cambian o desaparecen
      OpenAIApi.createChatCompletion  (src/asistente.js:8)
        `OpenAIApi` ya no existe.
      OpenAIApi.createEmbedding  (src/asistente.js:16)
        `OpenAIApi` ya no existe.
  stripe                 17.0.0 → 23.0.0      ✓ lo que usás no cambia (22 cambios en el SDK)

Y para un paquete cualquiera, sin repo: npx parche-cli diff stripe --from 17 --to latest (acepta versiones parciales y latest; --all para ver todo, --json para procesarlo). Los tarballs quedan en ~/.parche/cache (cambiable con PARCHE_CACHE); con PARCHE_OFFLINE=1 usa solo el caché.

En GitHub Actions

Para que corra todas las semanas, copiá templates/github-workflow.yml a .github/workflows/parche.yml. El paso a paso (los permisos, la primera corrida, repos privados y qué hacer si algo falla) está en la guía de instalación. El paso clave es:

- uses: Pepo08/parche@v0
  with:
    verify: 'true'     # corre tu npm test antes de abrir cada PR
    # pack: arca.wsfe.condicion-iva-receptor   # opcional: un solo pack
    # dry-run: 'true'                          # opcional: armar las ramas sin abrir PRs

El workflow necesita permissions: contents: write y pull-requests: write. Además, en el repo (o en la organización, si el repo es de una) tiene que estar prendido Settings → Actions → General → Workflow permissions → "Allow GitHub Actions to create and approve pull requests": viene apagado en los repos personales y las organizaciones nuevas, y sin eso GitHub no deja que la Action abra el PR (Parche te lo dice en la corrida). Con un token de una GitHub App o uno personal (abajo), no hace falta. Antes de Parche, la plantilla instala las dependencias de tu proyecto para que corran sus tests: npm ci si hay package-lock.json y composer install si hay composer.json (Composer viene en los runners de Ubuntu de GitHub). Así anda igual en un repo de Node y en uno de PHP.

Si ya hay un PR de Parche abierto, la corrida siguiente no abre otro: si el arreglo es el mismo, no lo toca; si cambió (por ejemplo, salió una versión nueva del pack) y el PR tiene solo el commit de Parche, lo actualiza. Si alguien le sumó un commit, Parche no lo pisa: lo deja como está y lo dice en el resumen del job. Si un pack falla (por ejemplo, porque no pasan tus tests), los que siguen corren igual y la corrida termina con error al final.

Lo que no abre un PR también se ve en la corrida: los avisos de solo detección (modelos de IA que se retiran, por ejemplo) y lo que quedó sin PR porque falta un dato de tu negocio aparecen en el resumen del job y como anotaciones con el archivo y la línea (GitHub muestra las primeras 10; el resumen las tiene todas).

La foto de la corrida: además, la Action guarda un artifact del workflow (parche, salvo que le pongas otro nombre con snapshot-name) con dos archivos. scan.json es la salida de parche scan --json: el inventario de APIs y los avisos, cada uno con su fingerprint, un identificador que no cambia aunque se muevan las líneas, para comparar una semana con la anterior. ledger.jsonl es el registro de esa corrida: los PRs que abrió y lo que quedó sin PR. Lleva rutas, números de línea, paquetes, versiones, operaciones y los mensajes de Parche; no lleva código. Lo baja quien puede ver las corridas de Actions del repo (gh run download <id> -n parche), y dura lo que diga la retención de artifacts del repo. Si no lo querés: snapshot: 'false'. Si la foto falla, la corrida no falla: queda un aviso.

El resumen de la semana: con la foto, la Action arma el resumen semanal, con el mismo diseño que los mails de Parche:

• qué hay para hacer, ordenado por fecha;
• lo nuevo desde la semana anterior;
• los PRs de Parche;
• lo que se resolvió;
• las APIs del repo.

Lo suma al resumen del job y lo deja en la foto como resumen.html (listo para mandar por mail), resumen.txt y resumen.json. No lo manda a ningún lado. Para comparar con la semana anterior, baja la foto de esa corrida, y para eso el job necesita actions: read (la plantilla lo pide). Sin la foto anterior, el resumen dice que es la primera y no inventa lo nuevo ni lo resuelto. Tampoco dice quién tiene cada dato: Parche no lo sabe. Si no lo querés: summary: 'false'. Para armarlo en tu máquina con dos fotos: npx parche-cli summary --snapshot <carpeta> --previous <carpeta>.

Con el GITHUB_TOKEN por defecto, GitHub deja los workflows del PR que abre Parche esperando aprobación: alguien con permiso de escritura tiene que tocar Approve workflows to run (el cuerpo del PR lo avisa). Para que tu CI corra sola sobre esos PRs, pasale a la Action un token de una GitHub App o un token personal con permiso de escritura en contents y pull-requests:

- uses: Pepo08/parche@v0
  with:
    token: ${{ secrets.PARCHE_TOKEN }}

Desarrollo

npm install
npm test                         # el CI los corre en Linux y Windows
bash demo.sh                     # demo completa sobre examples/tienda-demo (JS)
node bin/parche.js scan examples/tienda-php   # ejemplo PHP con afip.php
node bin/parche.js scan examples/saas-demo    # SaaS con Stripe, Twilio, OpenAI y HTTP directo
node bin/parche.js scan examples/legacy-ia --upgrades   # OpenAI v3: qué se rompe al actualizar (usa la red)

Cómo contribuir, las reglas para el código y cómo se saca una versión: CONTRIBUTING.md.

Estados de cada hallazgo

Estado	Qué significa
✅ automático	El arreglo es seguro y queda aplicado.
👀 revisar	Se aplicó, pero hay una decisión que confirmar (va en el PR, que sale como borrador).
✋ falta un dato	No se puede arreglar sin información del negocio. El PR dice qué agregar y con qué valores.
⛔ bloqueado	Migrarlo rompería algo (ej. application_fee en Orders). No se toca.
🔎 detectado	Solo aviso: cambiarlo cambia el comportamiento (ej. modelo de IA retirado).

Packs incluidos

Pack	Proveedor	Tipo	Fecha límite	Arreglo
arca.wsfe.condicion-iva-receptor	ARCA	rompe	2026-12-01	sí, en JS (afip.js y @arcasdk/core) y PHP (afipsdk/afip.php y forks): consumidor final y DNI B/C; con DocTipo en una variable, consumidor final al ejecutarse (PR parcial)
mercadopago.payments-to-orders	Mercado Pago	migración	—	sí (creación de pagos con el SDK de Node, 2.4.0 o posterior)
ai.model-retirements	Anthropic, OpenAI	retiro	varias	solo detección (también modelos fine-tuned de OpenAI, ft:…). De OpenAI, los modelos que su página de deprecaciones apaga desde 2026: texto, código, imagen, video, voz, transcripción y realtime; y los productos que cierran: Assistants API, prompts reutilizables (pmpt_…, v1/prompts), la plataforma de Evals, ChatKit con un workflow de Agent Builder y la Videos API (cerrada el 24/9/2026). De Anthropic, los modelos retirados o con fecha, también por su alias (claude-sonnet-4-5, que apunta a claude-sonnet-4-5-20250929 y se retira el 30/11/2026), temperature, top_p y top_k con un valor que no es el de por defecto en Claude 4.7 y posteriores, que dan error 400 (SDK de JS/TS y de Python, y HTTP directo), y los mismos tres parámetros con cualquier modelo en la API version 2026-10-21, que usan el SDK de TypeScript 1.0.0 y el de Python 2.0.0 (del 21/10/2026): dice si el pedido ya falla, si falla en una instalación nueva o si va a fallar cuando suban el SDK

Verificación

Antes de commitear, Parche parsea siempre cada archivo modificado (JS/TS o PHP): eso no ejecuta nada del repo. Con --verify, además corre los tests del repo que correspondan a lo que cambió: npm test para JS/TS; para PHP, composer test o vendor/bin/phpunit. Si no hay tests, queda el chequeo de sintaxis y el PR lo dice. Sin --verify (por ejemplo, en un PR a un repo de terceros, donde no se ejecuta su código), el PR dice que Parche no corrió los tests y nombra los workflows del repo que los corren en cada pull request. Si algo falla, no hay PR. El commit lleva la versión del pack que lo generó, para poder rastrear qué regla produjo cada cambio.

Quién firma el commit: --author "Nombre <email>" si lo pasás; si no, PARCHE_GIT_NAME y PARCHE_GIT_EMAIL si están; si no, tu identidad de git (user.name y user.email, también la que configure tu workflow); en GitHub Actions sin identidad, github-actions[bot], el mismo que abre el PR. Si no hay ninguna, parche pr frena antes de tocar el repo. Antes de pushear, si el email no es un noreply de GitHub, avisa: va a quedar público en el commit del PR.

Copias de respaldo: Parche no lee ni edita carpetas BAK/, backup/, old/, _old/ y deprecated/, ni archivos como factura copy.php, factura - Copy.js, factura.bak.php o factura-old.php. El scan dice cuáles saltó, por si alguno es código que corre.

Seguridad y datos

Parche corre en tu máquina o en tu runner. Tu código no sale de ahí, salvo el PR que abre en tu propio repo.

Red	scan, fix y packs no usan la red. pr llama a api.github.com para buscar, abrir o actualizar el PR en tu repo y pushea su rama parche/<pack>. La pisa con --force solo si todos sus commits son de Parche: si alguien le sumó uno, no la toca y lo dice en la corrida. diff y scan --upgrades bajan metadatos y paquetes de registry.npmjs.org, que ve qué paquetes y versiones consultás. Nada más.
Telemetría	Ninguna. parche feedback escribe en .parche/ledger.jsonl de tu repo y queda ahí.
Qué ejecuta	git y, solo con --verify, los tests de tu repo (npm test, composer test o vendor/bin/phpunit).
Qué escribe	Tu working copy (solo fix y pr), .parche/ (se agrega a .git/info/exclude) y, para diff y --upgrades, un caché en ~/.parche/cache. En GitHub Actions, además, la foto de la corrida como artifact de tu workflow (inventario y avisos en JSON, sin código; se apaga con snapshot: 'false').

Para reportar una vulnerabilidad, y el detalle de todo esto: SECURITY.md. Si te llegó un PR de Parche: por qué lo recibiste.

Qué puede cambiar dentro de v0: mientras Parche esté en 0.x, Pepo08/parche@v0 y npx parche-cli reciben cada versión nueva. Una versión 0.x puede sumar packs, avisos y opciones. No cambia sin aviso en el CHANGELOG el formato de .parche/inventory.json (tiene schemaVersion), los nombres de los comandos ni el de los inputs de la Action. Si tu organización exige fijar las Actions, usá el commit de un release: Pepo08/parche@<sha> # v0.6.7.

ARCA en PHP

¿Tenés que agregar el campo a mano? La guía paso a paso, para afip.js, afip.php, @arcasdk/core y SOAP propio: Cómo agregar CondicionIVAReceptorId antes del 1/12/2026.

Para afipsdk/afip.php y sus forks (fertandil87/afip.php, ivanalemunioz/afip.php, eesnaola/afip.php), Parche busca $afip->ElectronicBilling->CreateVoucher($data) y CreateNextVoucher($data) (también en minúsculas: PHP no distingue) y agrega una línea por factura:

            'DocNro'     => 0,
            // parche: 5 = Consumidor Final (DocTipo 99, sin identificar)
            'CondicionIVAReceptorId' => 5,

• Lee el array cuando está en la llamada (array(...) o [...]) o en una variable definida una sola vez, antes de la llamada y en la misma función. Si los datos llegan de otro lado, se reasignan o se completan en varios pasos ($data['DocTipo'] = ...), lo reporta como "falta un dato" y no toca nada.
• Copia el estilo del array: comillas de las claves, indentación (espacios o tabs), alineación de los =>, coma final y fin de línea (LF o CRLF).
• Saltea vendor/.

La versión de la librería importa. Con afip.php 0.x y eesnaola/afip.php el pedido se arma con un WSDL de 2021 que no tiene CondicionIVAReceptorId: aunque el campo esté en el código, no llega a ARCA. Con afip.js 0.x y ts-afip-ws (un fork de afip.js 0.x; su última versión, la 1.3.2, trae el WSDL sin el campo), el WSDL que traen tampoco lo tiene; no está confirmado que el campo no viaje, así que conviene tratarlo como si no viajara. Parche lee la versión instalada (composer.lock, package-lock.json, node_modules) y, en esos casos, el arreglo sale como "revisar" y lo que pide un dato lleva el mismo aviso: qué actualizar para que el campo viaje. También avisa si el repo tiene un .wsdl de WSFEv1 sin el campo.

Clave casi bien escrita. Si el detalle del comprobante lleva CondicionIVAReceptor (sin Id), CondicionIvaReceptorId o condicionIVAReceptorId, ese elemento no existe en el WSDL: el dato nunca llega y el repo parece migrado. Parche renombra la clave a CondicionIVAReceptorId sin tocar el valor, en JS y en PHP, y el PR sale borrador para revisar que el valor sea un código válido. Solo lo hace dentro de objetos o arrays con al menos dos claves de WSFEv1 (DocTipo, CbteDesde, ImpTotal…), para no tocar modelos propios con un nombre parecido, y nunca en tests. También renombra una asignación aparte (det.CondicionIVAReceptor = x, det['CondicionIVAReceptor'] = x o $det['CondicionIVAReceptor'] = $x) cuando det es, en la misma función, un objeto o array con esas claves; si no puede confirmarlo, lo avisa sin tocar. Si un interface o un type del repo declara la clave mal escrita, no renombra, porque TypeScript dejaría de compilar, y el aviso dice dónde está ese tipo.

Otros lenguajes: en Python, C#, Java, Go y VB.NET, Parche detecta integraciones SOAP propias y clientes SOAP generados sin el campo (no los reescribe).

ARCA con DocTipo en una variable: PR parcial

Cuando DocTipo no es un número fijo (DocTipo: docTipo), Parche no puede saber la condición frente al IVA de cada cliente. Lo único que se sabe sin datos del negocio es que 99 (consumidor final sin identificar) va con 5, así que aplica esa regla al ejecutarse y, con cualquier otro DocTipo, el pedido sale exactamente igual que hoy:

    DocNro: docNro,
    // parche: 5 = Consumidor Final solo si DocTipo es 99; con otro DocTipo falta la condición frente al IVA del cliente
    ...(Number(docTipo) === 99 ? { CondicionIVAReceptorId: 5 } : {}),

        );
        // parche: 5 = Consumidor Final solo si DocTipo es 99; con otro DocTipo falta la condición frente al IVA del cliente
        if ((int) $data['DocTipo'] === 99) {
            $data['CondicionIVAReceptorId'] = 5;
        }

• El PR sale borrador, con "(parcial: consumidor final)" en el título. En "Lo que este PR NO resuelve" dice qué falta: los comprobantes con otro DocTipo (CUIT, DNI y otros) siguen sin el campo y desde el 1/12/2026 ARCA los va a rechazar. Ahí también están los códigos válidos para la clase del comprobante.
• Con otro DocTipo la clave ni existe (no queda en undefined ni en null): el pedido no depende de cómo lo serialice la librería y no aparece un rechazo que hoy no existe.
• Number(...) y (int) hacen que '99' como texto también cuente.
• En JS solo se aplica si DocTipo se puede releer sin efectos (docTipo, cliente.docTipo, this.datos['DocTipo']), no si es una llamada o un await. En PHP se lee del array ya armado, así que sirve cualquier expresión, pero el array tiene que estar en una variable ($data = [...]): con el array dentro de la llamada no hay dónde poner el if.
• No se aplica a facturas A ni a otras clases conocidas que no sean B o C.
• Si se vuelve a correr después del merge, no cambia nada y sigue avisando lo que falta.

Límites del MVP

• JS/TS (ESM y CommonJS) y, para ARCA, PHP. Siguen Python y Java.
• ARCA: cubre @afipsdk/afip.js, @arcasdk/core (arca.electronicBillingService.createVoucher y createNextVoucher) y afipsdk/afip.php (con sus forks). Las integraciones SOAP propias (en cualquier lenguaje) se detectan pero no se reescriben, salvo el renombre de una clave casi bien escrita. Un archivo JS o TS con saltos de línea \r sueltos (por ejemplo \r\r\n) no se edita: el aviso dice qué cambiar a mano.
• IA, parámetros de Claude 4.7 y posteriores: avisa solo si el modelo del pedido se lee en el mismo archivo (un literal, una constante asignada una vez o el valor por defecto de una variable de entorno) y el parámetro es un número escrito en el código. Si el modelo llega de otro archivo o de la configuración, no avisa: no se puede saber si el pedido va a fallar.
• IA, API version 2026-10-21 de Anthropic: la versión del SDK sale de package-lock.json, node_modules o el rango de package.json, y en Python solo de requirements.txt (todavía no de pyproject.toml, poetry.lock ni uv.lock). Un rango sin número (latest, *) cuenta como versión desconocida. Por HTTP directo avisa solo si el archivo manda anthropic-version: 2026-10-21. Los SDKs de Go, Java, .NET, Ruby y PHP no se leen.
• IA, alias de Anthropic: avisa los de Claude Sonnet 4.5, Opus 4.5 y Haiku 4.5 (claude-sonnet-4-5, claude-opus-4-5, claude-haiku-4-5), escritos enteros entre comillas. Los alias de modelos ya retirados (claude-3-5-sonnet-latest, claude-3-7-sonnet-latest y otros) todavía no: la documentación actual de Anthropic ya no los nombra.
• Mercado Pago: migra la creación de pagos con el SDK de Node 2.4.0 o posterior, la primera versión con Order (con una anterior instalada, no migra y pide actualizar). No agrega una idempotencyKey: el SDK genera una en cada escritura, y una fija quedaría en el client por un bug abierto del SDK (mercadopago/sdk-nodejs#481). Las consultas, capturas y reembolsos de pagos existentes se dejan a propósito en Payments API, como indica la guía oficial.
• Se distribuye como CLI (npx parche-cli) + GitHub Action (Pepo08/parche@v0). La GitHub App (instalación en un click, PRs automáticos al publicarse un pack nuevo) es el próximo paso.
• La capa de LLM (redactar packs desde changelogs y resolver casos "falta un dato" leyendo el modelo de datos del cliente) todavía no está incluida; cuando entre, va a pasar por la misma verificación.