[observed] enrich run: expected A post linking a long-form article should enrich from the body the fetch returned.; observed The body was discarded and the file written held only the bare link. fp-312128ad0c9f

[leeovery]

Session-observed report from a dex instance. Structured mechanics
only: each field was refused, not scrubbed, on any detected leak,
and the reporter's fuller note never leaves the instance.

• engine: 0.1.0
• verb: enrich run
• date: 2026-08-26
• expected: A post linking a long-form article should enrich from the body the fetch returned.
• observed: The body was discarded and the file written held only the bare link.
• fingerprint: fp-312128ad0c9f

steps:

1. Capture a social post whose only text is a link to a long-form article on the same platform.
2. The driver fetches the post and reads only its text field, ignoring the article body in the same response.
3. The enrichment file holds the bare link; promoting the article URL parks it manual as not a post URL.

[leeovery]

Reproduced and fixed in #57. Your suggested fix was right on both halves; one of them turned out not to be buildable, and the PR says why.

Cause, precisely. _text_of is an or chain: post.get("text") or _article_text(post). The fixture (article-700.json) has text: "", so the fallback always fired in tests. In the field it doesn't — fxtwitter expands the t.co, so text arrives already reading https://x.com/i/article/<id>. Truthy, so article was never consulted.

It also sailed past _SHORTLINK_ONLY_RE, which is scoped to t.co only. That guard exists for exactly this case — "a body that is nothing but a shortlink is a pointer, not content" — and fxtwitter's own expansion defeats it. Hence done rather than a park.

Fixed:

• article is asked for first. A post that has one has no other subject.
• Body renders from content.blocks[] — draft.js types map onto markdown directly (header-*, both list kinds, blockquote, code-block), and a type we haven't met renders as a paragraph rather than vanishing. preview_text stands in where no blocks are relayed.
• The link-only guard now refuses any bare-link body, not just a t.co.

The article-URL half. Your note said to "teach the driver to resolve an /i/article/ URL to its carrier post" — and your own via: line on the hand-recovered file records that the endpoint 404s. The ids confirm it's not derivable either: article …66759235586 vs status …72929151135, adjacent but unrelated. There's no way from an article id back to its post, so that URL stays a park — but the park now says capture that post instead rather than not a status URL.

Recovery — needs your explicit yes. done is terminal for the drain, so the fixed driver never revisits the three stubs already stored. #57 carries migration 4 to seed them: membership read off the stored file (units whose enrichment body carries an x article URL), not off a vintage, since this defect shipped inside 0.1.0 and most x posts have no article at all.

The design doc carries an owner ruling — "No new migration without explicit approval" — so that PR doesn't merge until you say yes to the migration specifically.

Not closing until then.

[leeovery]

Correction from review: migration 4's cohort predicate has been tightened since the comment above. "Body carries an x article URL" turned out to violate the migration framework's idempotency rule — the repaired body keeps the article link at its tail (harvest reads links out of stored bodies), so URL-presence would re-seed already-repaired work on any log-race re-application.

The shipped predicate requires the stub shape: every non-empty line an attribution (@… — …), a media note, or a bare link — one of them an x article URL. A repaired body fails on its first prose line; a prose post merely linking someone else's article fails too, and is correctly left alone. Two tests pin this, both confirmed failing against the loose predicate.