rg --files inventory, which skips gitignored and hidden paths, read the absence of Search Console files as missing data, and proposed a new 7-day views collector. A project-scoped rg --files --hidden --no-ignore plus direct parsing found three existing exports, and an existing collect_devto_views_7d function already did the collector's job, so the proposal was withdrawn before implementation. The exports are historical, so recent comparable data is still a separate gap.I was researching how to improve operations on my blog, and the research reached a confident conclusion early: there was no Google Search Console data to work with. It listed Search Console input as missing. Separately, it proposed building a new collector to measure each dev.to article's views at seven days.
Both premises were wrong. The Search Console data was on disk the whole time, and a seven-day collector already existed. Neither failure was dramatic. What interests me is how ordinary the first one was.
The research built its file inventory with a plain rg --files. ripgrep's defaults are designed for searching code, and the ripgrep user guide is explicit about what they filter out: paths matched by .gitignore and ripgrep's own ignore files, plus hidden files and directories. Those are the relevant filters for this file listing; binary detection concerns searching file contents, not rg --files inventory. The Search Console exports were CSV files in a gitignored location. A default listing was never going to include them.
So ripgrep did exactly what it documents. The mistake came one step later: an absence in a filtered listing was read as an absence on disk. "The inventory did not list any Search Console files" became "Search Console input is missing", and that sentence went into the research as a fact.
The rerun lifted the filters and stayed inside the project:
# illustrative project directory; default listing respects ignore files and skips hidden entries
rg --files ./project
# scoped inventory with filtering lifted (illustrative glob)
rg --files --hidden --no-ignore ./project -g '*.csv'That listing found the files, and parsing them directly, rather than trusting the filenames, established what they were: three Search Console exports. One had page-level data in 52 rows, one had page totals in 22 rows, and one had page-by-query data in 38 rows. Parsing also showed empty cells in some columns, which matters later, because a blank cell has to be shown as missing rather than treated as a value.
The second premise fell separately. An existing function, collect_devto_views_7d, already does what the proposed collector would have done. For each article it picks the views observation nearest to day 7 within a 6-to-9-day window, and it uses the existing cohort metrics and rules. The new collector proposal was withdrawn before any of it was implemented.
I'm not attributing that second miss to ripgrep. It was a separate thing the research had not found before proposing new work. Both corrections landed in the same revision of the research, and they share a lesson more than a cause.
Finding the exports did not settle the original question. They are historical snapshots. Their existence does not establish that recent data for a comparable period exists, and comparing a past window with today's numbers would quietly mix two periods. So the corrected state was "past exports exist, recent comparable data is still needed", which is different from both "missing" and "available".
The same care applied to my local performance data. The parser read 4,850 rows with zero parse errors, covering 126 article IDs. Of those, 79 had an observation inside the 6-to-9-day window and 47 did not. Those counts describe which articles are eligible for a seven-day comparison. They are not users, sessions or a traffic gain, and nothing in this work showed any traffic effect.
Claude Code and agy had both reviewed the original research. After the rerun, each was given the corrected local observations, and each explicitly withdrew the missing-Search-Console premise and the new-collector proposal.
It would be easy to describe that as two independent confirmations. It was not. Neither model scanned the disk. Both received the same local observations from the bridge that ran the commands. Their withdrawal shows they accepted the correction when shown it. The evidence that the files exist is the scoped listing and the parse, not the models' agreement.
The rule I took from this: when an inventory says something is missing, ask what the inventory was able to see before believing it. For a file listing, that means stating which ignore rules applied and whether hidden entries were included, then rerunning with --hidden --no-ignore when the answer matters. Keep that rerun bounded to the project directory. Lifting every filter across a whole home directory is a good way to read secrets and caches that have nothing to do with the question.
Then parse what was found instead of trusting names, and write down the period it covers, the population it describes and what is missing from it. Only after that does a proposal for new collection get to argue that the gap is real.
The direction we took instead is small: a thin, read-only editorial view over data that already exists, with its period, population and missing values labeled. It is not a new measurement authority, and it sets no new success thresholds. Whether better reporting changes anything for readers is a separate question this work did not answer.
It is the same lesson as Your Checker Returned Zero. Four Times, Mine Was Just Looking at Less., where each instrument's printed number was narrower than it looked because of the slice it was built to examine. A file listing is an instrument too. Its ignore rules set its aperture.
By default rg --files respects .gitignore and ripgrep ignore rules and omits hidden entries. Those filters can hide CSV exports that are present on disk; binary-content detection is a separate concern when searching file contents.
Add --hidden and --no-ignore, and keep the search bounded to the project directory rather than a whole home directory, where lifting every filter can read secrets and caches unrelated to the question. Then parse what you find instead of trusting filenames.
No. The three Search Console exports were historical snapshots. Their existence does not establish recent data for a comparable period, so the corrected state was that past exports exist and recent comparable data is still needed.
No. Claude Code and agy were given the corrected local observations and each explicitly withdrew the missing-data and new-collector premises. Neither scanned the disk, so their withdrawal shows they accepted the correction, not that they verified it.