Re-index Context7 when the docs deploy

[navbytes]

Context7 serves Vee's docs to LLMs and AI editors
(context7.com/navbytes/vee), indexing
docs/_content per context7.json. It refreshes on its own schedule, which
means a shipped doc change can sit stale in front of every model using it until
that fires — the library was last indexed a month ago, before everything in
0.3.0.

That is the same gap the Pages deploy already closes for the human-facing site,
left open for the machine-facing one.

What this does

Adds a context7 job to the docs workflow that asks Context7 to re-index after
a successful deploy.

• Runs after deploy, not beside it — re-indexing pages that failed to
  publish is pointless.
• Adds context7.json to the path filter. Its rules are part of what
  Context7 serves, so changing them has to re-index even when no page moved.
• A missing CONTEXT7_API_KEY skips rather than fails. The docs deploy is
  the job that matters; failing it over an optional third-party index — on a
  fork, or before the key is set — would be the tail wagging the dog. The step
  prints what to do instead.
• A non-2xx response fails loudly, printing the HTTP code and body. A
  refresh is a request that Context7 queues; if the request itself does not
  land, that is worth knowing.

To make it live

gh secret set CONTEXT7_API_KEY --repo navbytes/vee   # key from context7.com/dashboard
gh workflow run docs.yml                              # first re-index

The manual dispatch matters: 0.3.0's docs are already merged, so nothing will
push to docs/** again to fire this naturally.

Caveat

The API call (POST /api/v1/refresh, bearer auth,
{"libraryName": "/owner/repo"}) comes from Context7's own integration
documentation and has not been executed — there was no key to test it with.
The first real run confirms it, and fails with the HTTP code and response body
if the endpoint has moved.

https://claude.ai/code/session_01Hpit6cxJxkbmRfNu6UJGr5