So the takeaway, is to look for a way to for the folder to hold only new notes. So it seems you want to use an automation†such that when you move apps out of the (Tinderbox) watched folder, the source Finder folder removes handled items (move to trash or archive folder) so we see only new entries after that. If the highlights process exports everything by default, check there aren’t options (or alternate export methods) to only export new/updated highlights.
Inter-app sync is inherently complex, and expensive one-way follow like this. For example were Eastgate to engineer a full synch to ReadWise, then every change potentially means more engineering (cost) for a feature only some user will ever use. Watched folders do just that. Id the process populating the app is putting in too much info or not removing stale info, remember to look at both ends of the pipeline.
†. Tip: think first about the task, rather than the tool/app you will use for the task. The latter way lies lots of “App X won’t let me do task Y” frustration. Work out what Y is, then you can look for tools that can do that. Be open to the fact too, that different apps/tools can get to to the efficient result by different means. In other words, don’t over-commit to using data in format Y or Z just because the first app you tested preferred one particular format. My experience, sad to say, is far too many apps have truly crappy export so we end up jumping hoops at the import end (many devs hubristically think their app is so good, data will never need to leave it: so, so wrong!). Never overlook that it might be better to use an app/API with good export as it will save you a tone of time and ease blood pressure.
This doesn’t entirely solve your problem, but I see one can download all Readwise highlights to a simple CSV file. When I dragged this into a new Tinderbox document, I got every highlight turned into a note, with highlight text in the text box and (and this is quite nice) some useful attributes (Book_Title, Author, etc) all populated and classified as User-created attributes.
Unfortunately each note’s name is also the full text of the highlight (not so useful). So I opened an Attribute Browser view in a new tab, and set it to sort using the “User Attribute” <Book_Title>. This creates an alphabetical list of all the books, and all highlights for a given book appear under its title. Here is the screenshot.
To get a list of all the books in the Tinderbox document, I guess I will create an agent that puts all variables of $Book_Title into the text of a new note. Or I guess I could set an agent to change each note’s name to the book it comes from, ie, $Name=$Book_Title. But that would produce a lot of lookalike notes and lose the preview aspect of the list in the screenshot. So, hmm. (IOW I am now in the moment when you step back and try to get clearer about what you’re using the Tinderbox document for, because there are a lot of possible next steps.)
The unsolved problem here is adding new highlights. The drag-and-drop also creates a new attribute called $Highlighted_at , which gives the date the highlight was made. I suppose that could be the basis for some sort of filter that prevents old highlights from being duplicated. But perhaps that would be too clunky? It’s also potentially confusing that Book_Title is a new “user attribute” which is different from Tinderbox’s built-in BookTitle, I suppose.
Btw this little experiment created more than 7,000 notes and Tinderbox didn’t hiccup or delay during import, creating different views, or running agents. Impressive!