CortexDB 0.9.8

One fix, and it is the other half of the deletion work that shipped in v0.9.7: a scope-wide forget could leave the scope unable to accept new memories.

A forget no longer blinds a scope to everything written after it. After POST /v1/forget with cascade: "redact_events" and confirm_all: true, memories written to that scope afterwards were accepted, acknowledged and durably stored — GET /v1/events/{id} served them — but /v1/recall never returned them again. Not a delay: they stayed invisible indefinitely, and every child scope created under that scope inherited the same blindness. The practical effect was that a scope you had once erased could never be reused, and nothing in the API told you so.

The erasure guarantee is unchanged. Memories written before the cutoff stay suppressed exactly as before; only writes that genuinely postdate the forget come back.

Who was affected. This only surfaced when retrieval fell back to its degraded path — most commonly when the configured embedding provider was failing (an expired or rate-limited API key), so ranked retrieval returned nothing on every query. A healthy deployment would not have seen it, which is why it took a production environment to reproduce. If your logs carry embedding missing for chunk or continuing with WAL-only events, you were in the affected mode, and it is worth checking your embedding credentials as well as upgrading: in that state new writes also get no vectors at all.

Nothing to migrate. Scopes that were already blinded recover on upgrade — the suppression was applied at read time, so the memories were never lost.

Drop-in. No API, schema or configuration changes.