[observed] enrich fetch: expected A fetch that writes new enrichment files lists the item under the write-up section.; observed A fetch wrote two new enrichment files but reported no new material at all. fp-838b42ab6ede

[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 fetch
• date: 2026-08-26
• expected: A fetch that writes new enrichment files lists the item under the write-up section.
• observed: A fetch wrote two new enrichment files but reported no new material at all.
• fingerprint: fp-838b42ab6ede

steps:

1. Promote two URLs onto an item that already has one enrichment file.
2. Both units ledger as done and two new files appear in the item's enrichment directory.
3. The report prints the nothing-to-report line instead of a write-up entry for the item.

[leeovery]

Reproduced exactly and fixed in #58. Your guess at the distinguishing condition was right.

Cause. _write_output byte-compares the rendered file against what's on disk and returns early when they match — correct, and the file must not churn (the fetched: stamp is masked out for that reason). But it returned without registering any outcome, while record_outcome still counted the unit. So the run counted the work in counts and denied it in items.

That's why BERTopic differed from your two contrasting cases: it was a rerun-cohort item drained earlier in the same session, so harvest had already fetched both URLs at depth 1. The explicit enrich fetch re-fetched them to identical content and hit the early return. Your other two items had been seeded by the immediately preceding run, so their URLs were genuinely new.

Reproduced end-to-end:

### first enrich fetch (URLs new to the item)
**done** 2
### Needs writing up — 1 item has new material
  ↳ 2 new enrichment files

### second enrich fetch — same URLs, unchanged content
**done** 2
Nothing to report from this run: no new material...

Fixed. Unchanged re-fetches are counted and rendered under their own heading:

### Already stored — 2 units re-fetched to what was on disk, across 1 item
- **2025-02-12-bertopic-d8e05c**
  ↳ 2 units unchanged

Deliberately not part of the writing-up queue — an unchanged re-fetch isn't new material. It's accounted for, not queued. The nothing-to-report line now prints only when the run truly did nothing.

Your framing of the impact drove the fix: the run report is documented as the session's work list, so on an unattended run a silent omission means content is fetched and then never digested. Two existing tests asserted the old wording; they were pinning the defect rather than the contract, and now assert what matters.

Not closing until the fix is approved and merged.