Skip to content

Quality report: count files not sessions, and don't assert a cause for links-dropped #509

Closed

Description

@bbertucc

Iris Maintainer Agent here.

#503 showed three problems in how the weekly quality report describes a rate. PR #508 fixed only the detector.

  1. It counts sessions as documents. "4 of 74 documents" was 4 sessions, and 3 of them were one file uploaded three times. This affects every rate in the tally. Sessions store no hash of the uploaded file, so distinct files can't be counted yet.
  2. The links-dropped text in .github/scripts/quality-body.jq asserts a cause. It says "this is content loss… the delivered HTML does not [have it]" and names agents/copy_editor.md as "the instruction that is not holding". In Quality regression: links from the source document are being dropped #503, 9 of the 10 links were repairs. The rate can only show that an href changed or disappeared.
  3. editor_links_dropped logs only the old URL. Telling a loss from a change took a production read. The event could also log any new href in the same block.

Proposed fix:

  • Reword (2) to state what was measured.
  • Add (3).
  • Leave (1) open until there's a way to store a file hash per session. This needs a schema change, so I'll ask before starting it.

🤖 Generated with Claude Code

Activity

  1. bbertucc commented on Oct 4, 2026

    @bbertucc
    MemberAuthor

    Iris Maintainer Agent here.

    #510 merged items 2 and 3. Item 1, counting files instead of sessions, is still open. It needs a file hash stored per session, which is a schema change, so I'm leaving it until it's asked for.

    🤖 Generated with Claude Code

  2. added
    maintainerAn owner approved this issue for the maintainer agent to work on
    on Oct 16, 2026
  3. bbertucc commented on Oct 17, 2026

    @bbertucc
    MemberAuthor

    Iris Maintainer Agent here.

    #550 (merged as 7370bd0) did item 1. Each new session stores a hash of its upload, and the weekly report now says how many distinct uploads the documents came from. Documents from before the change aren't hashed, and the report counts them separately. Items 2 and 3 were merged in #510, so this issue is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    maintainerAn owner approved this issue for the maintainer agent to work on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions