ragleap-core v0.13.2 release notes

ragleap-core v0.13.2

Audit and sign-in hardening. Everything new is read-only or opt-in, except the sign-in rate limit, which is on by default for the (off by default) single sign-on.

What changed in the app

Audit filters (#1306). GET /audit can be filtered and paged: method, path (starts with), status, since, until (ISO 8601) and before_id. Calls without them behave as before.
Audit retention (#1318), opt-in. AUDIT_RETENTION_DAYS, ACTION_LOG_RETENTION_DAYS and AGENT_RUN_RETENTION_DAYS (empty or 0 keeps everything, the default; 1 to 6 is refused). When a limit is set, the scheduler leader deletes older rows every 6 hours in small batches; runs that are running or waiting for approval are never deleted. Each purge writes a retention_purge AUDIT line. New routes: GET /retention (admin) and POST /retention/purge (owner, dry run by default).
Request id in the logs (#1319). The X-Request-ID of a call is now carried by the AUDIT log lines written while handling it (request_id). LOG_REQUEST_ID=true puts it in every app log line; off by default.
Rate limit on single sign-on (#1325). /auth/login and /auth/callback accept at most AUTH_SSO_MAX_PER_MINUTE (default 30, range 1 to 10000) requests per client and minute, then answer 429 (the callback redirects back with a message). The first refusal per client and minute writes a sso_rate_limited AUDIT line. Behind a reverse proxy list it in TRUSTED_PROXIES, otherwise everyone behind it shares one counter. AUTH_THROTTLE=off switches it off.

Documentation

New guides: docs/audit-retention.md and docs/audit-log-lines.md; docs/single-sign-on.md now describes the rate limit.

Upgrade notes

No schema change, no new dependency. Rebuild and restart the app.
All new settings are optional and default to the old behaviour, except the sign-in rate limit (on by default, generous).
Deleting history removes evidence: ship the AUDIT lines to a log store first and choose the retention period with your own counsel. Nothing here makes an installation compliant with any law or standard.
Not covered yet: the request id is not stored in the database rows, lines written later in the background have no request id, and stored prompts are not redacted.

Thanks

Thanks to everyone who tested and reported, and to Paige Ortiz (CerTova AI) for the technical review that prompted the audit work. Contributors are credited by name; tell us if you prefer not to be.