Impact: a post's author handle comes from the first @word anywhere in the User-Name block, so an @ in the display name wins over the real handle. Display names like "Alice @alice.bsky.social" or "Jane | @acme" are common. Every export from that account then carries the wrong handle in the title, byline, .llm.md Author line, library index and library folder name (acme-<id>). Thread scope compares these handles too. If the real @acme account replies directly under Jane's post, both parse as @Acme and the company's reply is captured as "Post 2 of 2" of Jane's thread.
Where: authorFromNameBlock in sourcecapsule.user.js (2204-2216) runs text.match(/@[A-Za-z0-9_]+/) over the whole block text. buildTweetSequence (1686-1697) compares the result with ===, and bundlePaths (880) names the folder after it. Articles are safe because resolveArticleAuthor trusts the handle in the URL. Posts have no such check. #4 fixed the display-name half of this parse; the handle half was never fixed.
Evidence: Node + jsdom repro. Alice has handle alice_real and display name "Alice 🦋 @acme.bsky.social". Bob has handle bob_other and display name "Bob @acme".
authorFromNameBlock -> { name: 'Alice 🦋', handle: '@acme' }
model.title = Alice 🦋 (@acme) on X
thread = {"capturedPosts":2,"sourcePostIds":["1790000000000000000","1790000000000000001"],...}
Environment: main 72777ef (v1.6.8). Engine loaded in Node through the module.exports guard with jsdom. No browser.
Next action: take the handle from the post's own status permalink (/<handle>/status/<id>) or the User-Name profile link href, and fall back to the last @word in the block. Add a dom test with an @ in the display name.
Impact: a post's author handle comes from the first
@wordanywhere in the User-Name block, so an@in the display name wins over the real handle. Display names like "Alice @alice.bsky.social" or "Jane | @acme" are common. Every export from that account then carries the wrong handle in the title, byline,.llm.mdAuthor line, library index and library folder name (acme-<id>). Thread scope compares these handles too. If the real @acme account replies directly under Jane's post, both parse as@Acmeand the company's reply is captured as "Post 2 of 2" of Jane's thread.Where:
authorFromNameBlockinsourcecapsule.user.js(2204-2216) runstext.match(/@[A-Za-z0-9_]+/)over the whole block text.buildTweetSequence(1686-1697) compares the result with===, andbundlePaths(880) names the folder after it. Articles are safe becauseresolveArticleAuthortrusts the handle in the URL. Posts have no such check. #4 fixed the display-name half of this parse; the handle half was never fixed.Evidence: Node + jsdom repro. Alice has handle
alice_realand display name "Alice 🦋 @acme.bsky.social". Bob has handlebob_otherand display name "Bob @acme".Environment: main 72777ef (v1.6.8). Engine loaded in Node through the
module.exportsguard with jsdom. No browser.Next action: take the handle from the post's own status permalink (
/<handle>/status/<id>) or the User-Name profile link href, and fall back to the last@wordin the block. Add a dom test with an@in the display name.