Files
PaperClipAI/server
nickyleachandPaperclip f45b06a150 fix(server): find a glued bearer by its own header anchor, not the chain position
The scanner offered a candidate for a bearer glued to a neighbouring word
only at the chain's own first segment, and only right after a hyphen or an
underscore. A dotted prefix moved the glued segment later in the chain, and
a plain word with no delimiter at all left no offset to try, so the write
path still persisted a live bearer as plain text in both cases.

Every token this product mints starts its header segment with the literal
text "eyJ", the base64url form of the two bytes `{"`. The scanner now looks
for that text, and for a hyphen or an underscore, inside a window's own
first segment wherever that window sits in the chain. This closes the glue
class by the token's own content instead of adding another delimiter-
specific case.

A property test generates 200 random glue words per path (write, read while
live, and read after the expiry sweep) instead of naming one example per
shape, so a new, unnamed glue word cannot reopen this class again. A suffix
glued after the signature segment, with no dot to mark where the token
ends, stays open on the read path once the sweep clears a row's material:
closing it needs the registered value's own length, which the registry
does not store today.

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-09-16 08:35:25 +00:00
..