Skip to content

Do not call a fully-visible list paginated - #216

Open
DavertMik wants to merge 1 commit into
mainfrom
fix/no-pagination-for-complete-list
Open

DavertMik wants to merge 1 commit into
mainfrom
fix/no-pagination-for-complete-list

Conversation

@DavertMik

Copy link
Copy Markdown
Contributor

Problem

Researcher could attach a > Pagination: marker to a section on the strength of how a different list on the page pages, inventing a control that was nowhere in the section it mapped.

Observed on a Testomat.io plan detail overlay. The research handed Planner:

> Pagination: controls – The test list under the tree has "Load more" pagination.

There is no such control on that page, and none of the 13 elements the section actually mapped is one. Planner grounds scenarios on capabilities the research confirms (capabilityGroundingRule, src/ai/rules.ts:187) and had no item count to contradict the claim, so it proposed "Load additional test entries in the current plan and verify that more test rows are appended" — against a plan holding one test.

Tester then burned the run asking four times for a button that does not exist, and finished by asserting the pagination bar of the list behind the overlay. Pilot caught it and failed the test, correctly — but the scenario should never have existed.

Fix

One line in rules/researcher/pagination.md:

Omit the line when the items already shown are the whole collection.

The rule already opened on "a list that continues beyond what is shown", but only as a premise. This gives it a form the model can act on. It reads on item volume rather than on controls, so both strategies and Data sections are unaffected — in the same research, the ## Data: Plans List marker pointing at .pagination-centered was real and still stands.

Knock-on benefit: detectPagination skips any section already carrying a pagination blockquote (src/ai/researcher/pagination.ts:18), so fewer invented claims means the deterministic DOM probe runs on those sections instead of being suppressed.

Trade-off

A list whose first page happens to hold everything today loses its marker, so a paging control that only appears once the data grows goes unreported until a later run sees more items.

Testing

  • bun test tests/unit — 1415 pass
  • bun test tests/integration/researcher.test.ts tests/integration/researcher-sections.test.ts tests/integration/planner.test.ts — 46 pass
  • bun run format, bun run lint — clean

🤖 Generated with Claude Code

The Researcher could attach a "> Pagination:" marker to a section on the
strength of how a different list on the page pages, inventing a "load more"
control that was nowhere in the section it mapped. The Planner grounds
scenarios on capabilities the research confirms, so it proposed a test to
load more rows into a plan holding one test, and the Tester spent the run
hunting a button that does not exist.

The rule already opened on "a list that continues beyond what is shown", but
only as a premise. Give it a form the model can act on: omit the line when
the items already shown are the whole collection.

Trade-off: a list whose first page happens to hold everything today loses its
marker, so a paging control that appears once the data grows goes unreported
until a later run sees more items.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants