v0.4.0

v0.4.0 — list_releases, upgrade briefings, and privacy as a ladder

A minor-version worth of change, field-tested against a real in-cluster agent (kagent) whose failures shaped every item.

New tool

• list_releases(project, limit) — the newest N reviewed releases of one project as light summaries (fact counts by severity, max advisory-group severity), newest first. THE tool for "recent releases of X" — list_facts is an oldest-first sync feed and must not be used for recency questions.

Upstream API additions (live at ratatosk.io/v1)

• GET /v1/upgrade/{project}?from=&to= — everything you take on by upgrading: facts from every release in between, the same advisory folded across release branches (envoy 1.36.8→latest: 75 facts → 40 distinct issues). Tag spelling never matters.
• version_rank on facts and release summaries — sortable integer components so REST callers can range-compare locally without sending their versions anywhere.
• Version tags accepted with or without the leading v; wrong tags 404 with the project's recent reviewed tags to retry with; project slugs matched case-insensitively.

Privacy, stated precisely

Three rungs, most private first:

1. check_stack — versions compared locally; only slugs reach the server. Now guaranteed in writing: check_stack never calls the server-side /v1/upgrade endpoint.
2. version_rank — pull facts, compare locally, send nothing.
3. /v1/upgrade — convenient; the versions you send reach the server. They are never written to access logs (query strings stripped, IPs masked v4 /24 / v6 /48 — see ratatosk.io/privacy), and the endpoint discloses this itself.

Improvements

• Error bodies pass through up to 400 chars so self-correcting 404s (with retry-able tag lists) arrive intact.
• Tool descriptions state list_facts ordering explicitly (oldest analyzed first; page with next_since).

No breaking changes.