[imoital]

Summary

When the API renames or drops a parameter, nothing tells us a host still sends it. This makes the published spec the reference and CI the verdict.

• api: in a code host's vars.yaml lists the operations and parameters it sends:

  api:
    GET /: [url, mode, js_instructions]
    GET /subscriptions/self/details: []

• npm run validate reads the published spec (https://www.zenrows.com/openapi.json, cached in .cache/ for when the network is down, or the file in ZENROWS_OPENAPI) and checks that each operation exists, each parameter is one it takes, and the host's rendered files send each name, so the list can't go stale and a mistyped name in the code shows up as not sent.
• api-changed.yml runs on a ping from the docs repo (the spec's home) or by hand: waits for the published file to match the sha the ping carries, runs validate, and on a host being out of date opens or updates one issue and posts to #proj-integrations. A clean run closes the issue. A download failure fails the run without blaming a host.

No host declares api: yet; #5 adds it for Activepieces. The docs-side workflow that sends the ping comes separately, once the PR bot app is installed on this repo.

How to check it

• npm run render -- --check, npm run validate and npm test pass (33 cases, 6 new, on a spec stub).
• With a throwaway host declaring what the Activepieces piece sends: passes against the live spec; fails naming the parameter when js_instructions is removed from a copy; warns and uses the cache with the network down.
• The Report step was run with a stub gh for all three outcomes.
• actionlint passes.