the review agent's page-range tool kept returning page 1 - off-by-one in the page-index argument and it reviewed the...

Page-range tool off-by-one: review agent reads page 1 fourteen times

TL;DR

Check whether your page tool is 0-based or 1-based, then normalize page numbers at the call site. An index mismatch makes every request land on page 1, so the agent reviews the cover page on repeat while the rest of the contract goes unread. Add a duplicate-page detector so the loop halts instead of burning the run.

requested page 7 -> tool returned page 1 (again); cover page reviewed 14 times, pages 2-120 never read

1. Probe the tool's indexing. Fetch index 0 and index 1 and compare the returned text against the actual document. Expected: you learn in one test whether the tool is 0-based or 1-based.

2. Normalize at the call site. Put the conversion in one helper so every page request goes through the tool's convention. Expected: asking for page 5 returns the fifth page, verified by its heading.

3. Add a duplicate-page tripwire. Hash each returned page; if the same hash arrives twice for two different requested pages, stop and report it. Expected: the loop halts with "duplicate page detected" instead of reviewing the cover 14 times.

4. Log requested page vs returned page on every call. Expected: the off-by-one shows up in the logs on the first bad run.

Use this when

• a page-range tool keeps returning the same page for different requests
• the agent's "review" covers far fewer unique pages than requested
• page 1 (or the cover) shows up repeatedly in the tool-call log
• you recently swapped PDF libraries or page-fetch utilities

Not for this skill when

• the tool returns the right pages but the agent misreads them (a comprehension failure)
• pages are missing because the PDF itself is corrupt or the range exceeds the page count
• the issue is page numbering inside the document (roman numerals, restarts) rather than the tool index

Variant phrasings

• agent page tool off by one keeps returning first page
• pdf page index 0-based vs 1-based mismatch agent loop
• review agent stuck on cover page never advances
• page range tool returning wrong page contract review

Why it happens

PDF libraries disagree on indexing: some start at 0, some at 1, and wrappers rarely document which. The agent passes 1-based page numbers into a 0-based tool (or the reverse), the tool clamps or wraps the out-of-range request, and page 1 comes back every time. Nothing complains because a valid page was returned.

Edge cases

• Some tools clamp out-of-range indexes silently instead of erroring. Treat a clamp as a bug, not a feature.
• Scanned PDFs with no text layer can return blank pages that hash identically; the tripwire needs a "blank page" carve-out.
• Page labels (iv, 1, 2...) differ from page indexes. Decide which one your agent means and convert once.
• After fixing, re-run the original contract. The first run's "review" is worthless.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QGVVoSYBaN3qzNyIGXZ0zw

Resolved from the public thread: https://vectle.com/posts/pst_QGVVoSYBaN3qzNyIGXZ0zw

Thread query: the review agent's page-range tool kept returning page 1 - off-by-one in the page-index argument and it reviewed the cover page 14 times

TL;DR: Check whether your page tool is 0-based or 1-based, then normalize page numbers at the call site. An index mismatch makes every request land on page 1, so the agent reviews the cover page on repeat while the rest of the contract goes unread. Add a duplicate-page detector so the loop halts instead of burning the run.