Skip to content

Audit 2026-10-08: a moved shape is never an empty listing (v0.1.1) - #1

Merged
jehrr merged 1 commit into
mainfrom
audit-2026-10-08
Oct 8, 2026
Merged

jehrr merged 1 commit into
mainfrom
audit-2026-10-08

Conversation

@jehrr

@jehrr jehrr commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator

Works through the third-party audit of v0.1.0 (2026-10-08, commit cfab156). Every finding was reproduced before anything changed, and every fix is pinned by a check that a planted fault turns red (6 of 6, run without bytecode).

Accepted

P1 — a moved shape read as advertising, then as an empty listing. Reproduced, and worse than reported: with UniqueId renamed on page 2, a 3-page run ended complete, exit 0; with Seller renamed on page 1, the search read as empty (exit 4). Now:

  • is_sponsored only on a positive marker. Across every capture, 3 of 3 sponsored tiles carry MediaZeroKm and AdvertisementLink, and 0 of 3,386 listings carry either.
  • A listing record that cannot be read is counted (malformed_records). A page of them is parser_found_nothing: exit 5, or exit 6 with earlier pages kept. This is binance's _unread rule, tightened by a stronger signal than arithmetic: the records are in the response.
  • columns_below_floor goes into the sidecar, not only the log. The canary fails on it and on malformed records.

P2 — ad-mode identity was a count. The query now carries ads_sha256 (order-independent; gone adverts stay in the asked scope), and the sidecar lists ads_requested. diff_runs.py also refuses search runs of different pages_requested.

Missing negative tests — added: an id renamed on page 1 and on page 2, one bad record among five, a moved Seller, two advert lists of one length, two search depths.

Accepted in part

"The canary's green badge proves nothing." True here, because this repo has no proxy secret, so every run skips. But skipping is deliberate: a canary that cannot pass must skip rather than be red every day. I did not build "last real success" tracking. Instead, a skipped run now says so at the top of its summary, and the README says the badge is green because it skips.

Not changed

  • "Mixed gone/content batch" test — already existed: check_ad_mode_end_to_end runs dealer, gone, private and bike adverts in one list and asserts complete, the gone one in ads_gone, and three rows.
  • A malformed record makes the run partial — not adopted. partial means pages were left unfetched, and here nothing was. The run stays complete and carries malformed_records, which the canary fails on. A page with no readable record is not complete.
  • Competitor parity (gallery, FIPE/market history, seller contacts, hosted API) — product decisions, not defects. Contacts stay out on purpose: no private seller's name, phone or postcode is written. History is what a scheduled run plus diff_runs.py gives you.

Live, 2026-10-08

Playwright, Gol, 2 pages through a residential exit: 94 rows, complete, malformed_records: 0, columns_below_floor: [], BRL, total_results: 1894.

🤖 Generated with Claude Code

- is_sponsored only on a positive marker (MediaZeroKm / AdvertisementLink;
  3/3 tiles have both, 0/3,386 listings have either). A listing record that
  cannot be read is counted (malformed_records); a page of them is
  parser_found_nothing: exit 5, or 6 with earlier pages kept. Before: a
  renamed UniqueId read as an empty page, exit 4 on page 1 and a complete
  exit-0 run on page 2.
- columns_below_floor in the sidecar, not only the log; canary fails on it
  and on malformed records.
- Ad-mode query identity is the set of adverts (ads_sha256), not the count;
  diff_runs also refuses search runs of different depth.
- Skipped canary runs say so in their summary; README says the badge is
  green because it skips.

Each fix pinned by a check a planted fault turns red (6/6, run without
bytecode). Live: 94 rows, 0 malformed, no shortfall.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@jehrr
jehrr merged commit cfd811c into main Oct 8, 2026
7 checks passed
@jehrr
jehrr deleted the audit-2026-10-08 branch October 8, 2026 11:26
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.

1 participant