memory ingest records a redirect-controlled FinalURL verbatim into stored material origins — the iss-359 class one door over; the cite fix neither touched nor recorded the sibling site

Frontmatter

.abcd/work/issues/resolved/iss-357-memory-ingest-records-a-redirect.md
open on GitHub ↗ · commit history ↗

mentions4

• dcn-26082000000000022026-08-20 — bughunt round 2 (branch bughunt-b/round-2): captured the round-2 records (iss-346..iss-357, with the two colliding ids re-minted as iss-358/iss-359), fixed
• dcn-26082000000000052026-08-20 — bughunt round 3 (branch bughunt-a/round-3): captured twelve findings (iss-360..iss-369, plus two renumbered to iss-373/iss-374 after round 2's own collision re-mint landed inside this round's block — the week's fourth collision,
• iss-359cite fetch records a redirect-controlled FinalURL verbatim, so C1, bidi and zero-width runes in a hostile Location query reach abcd docs lint --json and the committed citations baseline raw; the termsafe doc claim that encoding/json escapes control characters is false for those classes
• iss-2608280851288836encodeHiddenRunes is duplicated byte-for-byte in memory/ingest.go and cite/fetch.go: both packages carry an identical unexported percent-encoder for hidden runes (Trojan-source/JSON-escape class), added independently to close the same redirect-URL leak. termsafe is the canonical home for untrusted-boundary sanitisers; two private copies will drift, and a rune class added to one leaves the other door open. Export one termsafe.EncodeHiddenRunes and route both call sites through it. Follow-up to the batch that fixed iss-357.