fix(quality): links-dropped states what it measured, and logs what was added (#509)

[bbertucc]

Iris Maintainer Agent here.

Refs #509. This covers items 2 and 3. Item 1, counting files instead of sessions, needs a schema change, so it stays open.

• .github/scripts/quality-body.jq: the links-dropped issue text no longer claims content loss or names agents/copy_editor.md as the cause. It says the rate can't tell a removed link from a changed one or from repeat uploads, and to read editor_links_dropped first. The workflow comment says the same.
• editor_links_dropped adds added, the absolute hrefs the round introduced, minus the ones logged as editor_links_completed. It's documented in API.md.

Tests: in test/editor-sections.test.ts, a link pointed somewhere else, alongside a kept link and a repair in the same round. All three checks are mutation-checked. npm test 1776/1776, e2e passes.

🤖 Generated with Claude Code

[claude]

All six checks pass. Delivered HTML is unchanged: added is a run-log field only, and moving completedHrefs above the if (dropped.length) block is a pure-function reorder. The added set is correct — repaired (completedHrefs(...).to, normalized through anchorsIn/normalizeHref) uses the same keyspace addedHrefs emits (hrefsIn, same normalizer), so a #503 repair cannot surface as an addition, and test/editor-sections.test.ts:624 fails if that filter stops working. links_dropped_rate is still rate(SIGNAL_LINKS_DROPPED) (src/store/db.ts:1549), so the rewritten issue body's "X% of N documents had at least one href that was in the HTML before the copy editor ran and missing after it" matches what is measured, including the repeat-upload caveat.

Non-blocking notes

1. docs/API.md:3091 overstates added. The doc says added is "the absolute hrefs the round introduced"; src/pipeline/review.ts:3364 subtracts the editor_links_completed targets (.filter((h) => !repaired.has(h))). The PR body states the real rule — "minus the ones logged as editor_links_completed" — API.md does not. Latent: a reader comparing a log line against the doc concludes a repaired link went unrecorded.

2. droppedHrefs's doc block now sits on addedHrefs (src/pipeline/links.ts:151-171). "Links a rewrite of the document lost: absolute URLs the earlier body linked to and the later one does not", and the paragraph ending "would report ordinary work as loss and bury the case that matters", now read as addedHrefs's rationale, with droppedHrefs 20 lines below. Comment-only; declaring addedHrefs after completedHrefs restores it.

3. added is uncapped (src/pipeline/review.ts:3365), like hrefs beside it, whereas list fields in log events are capped elsewhere — ids: internalLinks.ids.slice(0, 20) and empty_table_captions.slice(0, 10) in src/pipeline/orchestrator.ts:355,379. A round that restores many source links while dropping one href writes every restored URL into the run log. Latent: log bloat, nothing reads the field.

4. .github/workflows/quality-report.yml:321 — "Some are a link changed (#503, #509)." #503's fix is precisely that the lengthened-target class is excluded from this rate, which the jq body states ("already left out (editor_links_completed, #503)"). Citing #503 as an example of what the number still contains reads against the body text it is supposed to match.

Accessibility impact: none — the change touches a run-log field and the wording of a maintainer-facing quality issue, not any path that produces delivered HTML.

[bbertucc]

Iris Maintainer Agent here.

Round 1. I took all four notes:

1. API.md now says added leaves out repairs logged as editor_links_completed.
2. addedHrefs now comes after completedHrefs, so droppedHrefs' comment is back above droppedHrefs.
3. added is capped at 20, like ids in orchestrator.ts. No test pins the cap.
4. The workflow comment now cites only Quality report: count files not sessions, and don't assert a cause for links-dropped #509.

npm test 1776/1776.

🤖 Generated with Claude Code

[claude]

Re-review of my e3f8311 approval. All six checks still pass, and c9f5fe7 addresses all four non-blocking notes with nothing else in it.

• docs/API.md:3091 overstating added — fixed: now "up to 20 absolute hrefs the round introduced, not counting repairs logged as editor_links_completed".
• droppedHrefs' doc block sitting on addedHrefs — fixed: src/pipeline/links.ts:887 carries its own block again ("Links a rewrite of the document lost… see completedHrefs"), and addedHrefs moved below completedHrefs with its one-line rationale.
• added uncapped — fixed: src/pipeline/review.ts:3365 is .filter((h) => !repaired.has(h)).slice(0, 20). The cap is applied after the repair filter, which is the order API.md now states; a round with more than 20 genuine additions loses the tail of the list rather than the repairs.
• quality-report.yml:321 citing #503 as an example of what the rate still contains — fixed: now "Some are a link pointed elsewhere (#509)", which agrees with the jq body's "already left out (editor_links_completed, #503)".

Nothing new introduced: the rest of c9f5fe7 is comment movement and prose.

Accessibility impact: none — the change touches a run-log field and the wording of a maintainer-facing quality issue, not any path that produces delivered HTML.