Interactive example · from Working with Coding Agents
The unnamed fork
Add re-crawl logic: when a bookmark changes, re-enqueue it for indexing.
Looking at the store. There are two different things that can "change": the bookmark row itself (URL, tags, notes: your edits) and the fetched page metadata (title, description: the web's drift).
Pick the agent's next move, then see where it leads:
This is re-crawling half the store every night. Page descriptions drift constantly. I meant when I edit the bookmark's URL.
Reverting the trigger and re-gating on bookmark edits. One wasted nightly run, one revert.
A gating condition inferred from surrounding code, implemented without surfacing the fork. The reading was plausible: that's exactly why it shipped, and exactly why it was wrong quietly instead of loudly. AF-14
(1). And actually, narrower: URL edits only. Retagging shouldn't trigger a crawl.
Gating on URL change only, then. Spec in one line: re-enqueue iff bookmarks.url differs after an edit. Tags and notes never trigger.
Why is there a config flag? Which one is running? …and why did everything re-crawl last night?
The default is metadata mode, which re-crawls on page drift. You'd want the flag flipped. And the flag, tests, and docs now all exist for a mode nobody asked for.