[observed] enrich run: expected A rewrite that replaces stored content with much less should be reported as such.; observed A rewrite that cut a stored file to 45% of its prose read as a plain rewrite. fp-206c0caaaf10

[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 rewrite that replaces stored content with much less should be reported as such.
• observed: A rewrite that cut a stored file to 45% of its prose read as a plain rewrite.
• fingerprint: fp-206c0caaaf10

steps:

1. Re-fetch a unit that already has an enrichment file on disk.
2. Let the new extraction return materially less prose than the stored file.
3. Read the run report: the item is listed as rewritten, with no sign content was lost.

[leeovery]

Triaged as a feature, not an engine defect — so it's backlogged rather than fixed this round. Entry and reasoning in #60.

The rubric in dex-run/references/processing.md is "the engine broke its own contract". Nothing documented says the run report states rewrite magnitude, so there's no contract here to have broken. Per the standing rule — bugs get fixed, features get backlogged — this is the one of the five that goes to the backlog.

That's a comment on the classification, not on the value. Two things make it worth building:

1. It's the detector the other three needed. [observed] enrich run: expected a rerun rewrite keeps the body it already had and only adds link markup; observed rewrites dropped fenced code blocks and table-laid-out discussion bodies fp-b1e7f9a83892 #51 and [observed] enrich run: expected a re-fetch keeps each heading's text on the heading line; observed three headings kept their marker but lost all their text fp-d72051e41cb0 #55 were both found by diffing rewritten files against git by hand, across cohorts of forty-odd files a wave. A report saying "this rewrite lost a third of its prose" would have surfaced all of them on the run that caused them, instead of on the wave someone happened to check.

2. Your Medium case survives the other fixes. Prepare the page before extraction, and let a discussion keep its comments #56 fixes the extractor bugs; it does nothing for a metered host serving a partial render. There the engine is not broken, the content is genuinely absent from the response, and the report says 1 rewritten — indistinguishable from a regression. Your own words are in the backlog file, because they name it better than a summary would: "the reportable half is that the run report cannot tell the two apart and says nothing either way."

The comparison is already in hand — _write_output byte-compares both bodies to decide whether to write at all, so the shrink ratio is one subtraction away. Open questions (threshold, what it's measured against, where it renders) are in the file.

Leaving this open, since the work isn't done. Close it with a pointer to the backlog entry if you'd rather the tracker only held live defects.

[leeovery]

Closing with a pointer: this is tracked as backlog/rewrite-magnitude.md (merged in #60), which carries the full analysis — why it's the detector the silent-loss bugs needed, the metered-host case the extraction fixes don't cover, and the open design questions (threshold, what it's measured against, where it renders). The tracker holds live defects; the backlog holds this until it's designed.