v0.8.0

A minor release that adds ALTCHA as a second challenge provider for public procedures. It changes no 0.7 form: an application raises its pin and nothing else changes (0.7 → 0.8). Its framework window is 0.4, 0.5, 0.6, 0.7 and 0.8.

Upgrade steps for operators

• Upgrade the platform before any application raises its pin to 0.8. Control refuses an application whose framework release is newer than the platform.
• Zerops: a namespace whose proxy is pinned to an older source refuses the first deploy of an application with an ALTCHA challenge until the proxy is re-pinned: fabrika control namespaces update --namespace=<id> --proxy-source=current. Every other application deploys there as before.
• No generated file, environment variable or provider state changes on upgrade.

New

• ALTCHA challenge. challenge: { provider: 'altcha', secret: 'ALTCHA_HMAC_KEY' } on a public procedure is a proof of work the application issues and verifies itself: no request leaves the installation, and there is no third-party account or site key. Turnstile stays available.
  • The build adds an anonymous issuer row GET /__fabrika/challenge/<action> beside each such procedure, with rate-limit buckets of its own. The /__fabrika/challenge/ prefix is reserved.
  • ALTCHA_HMAC_KEY is an application variable the operator sets, at least 32 characters (openssl rand -base64 32). boot refuses a shorter one.
  • On the page: Challenge from @fabrika/ui/challenge at challengeUrl(api.<procedure>), with altcha added to the dependencies. The widget solves in workers, so the CSP gains worker-src 'self' blob:, which the approval shows like any other directive.
  • Tests: kit.solveChallenge(api.<procedure>); fabrika app dev issues the cheapest challenge and verifies it as production does.
  • The agent skill's public intake now uses ALTCHA.
• The platform reads 0.7 applications with the 0.7 reader. Their snapshot and contract digests are the ones 0.7.0's own Control recorded, so stored approvals stay valid.

Fixes

• A deploy whose access the pinned namespace proxy cannot parse is refused before it becomes the published snapshot, so a refused deploy cannot block later rebuilds of the namespace.
• An older namespace proxy is judged by its own CSP parser too, so a directive it does not know can no longer take every member's proxy down at the next republish.
• A deployment that shortens maxAgeMs keeps refusing replays of challenges its predecessor signed.
• A mount's compatibility promise covers its generated challenge routes, so renaming an action or removing an issuer is refused instead of breaking existing clients.

Full changelog: v0.7.0...v0.8.0