v0.2.0

zotero-to-thymer: create the mirror folder ourselves, bound by GUID

Waiting for Thymer to export a folder for a newly created collection never
succeeds: the mirror's incremental passes export dirty RECORDS only
(`EXPORT dirtyRecords=…` in .thymer/mirror.log) and never materialise a folder
for a collection that appeared after its last full pass. Restarting the app
does not help either — verified live against a freshly created References,
which sat folder-less while every other folder kept its original timestamp.
So the previous fix just burned its 120s timeout and failed.

A folder is bound to a collection by the hidden `.collection.json` marker it
contains — `{"guid":"…"}` — i.e. by GUID, not by folder name. Provisioning
already knows the guid of every collection it touches, so it now creates the
directory and writes that marker itself. Idempotent: a folder the mirror
already owns has an identical marker and is left alone. This also covers a
pre-existing collection that has never been exported.

`_plugin.json` is deliberately NOT synthesised. It is Thymer's export of the
LIVE schema, and writing our own would reintroduce exactly the second source
of truth this rework removed. `loadFolderSchema` already copes: with the file
unreadable it falls back to default labels and treats every field as present,
which is right for a collection whose schema we just seeded with those
defaults. Confirmed live — Thymer wrote the real `_plugin.json` itself once it
owned the folder.

Verified end-to-end: a real Zotero item synced into a fresh References
(`newRecords=1`), folder created and adopted, schema exported by Thymer.

Adds `IOUtils.makeDirectory` to the hand-written Gecko type declarations.
206 tests green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

release

zotero-to-thymer: create the mirror folder ourselves, bound by GUID

Waiting for Thymer to export a folder for a newly created collection never
succeeds: the mirror's incremental passes export dirty RECORDS only
(`EXPORT dirtyRecords=…` in .thymer/mirror.log) and never materialise a folder
for a collection that appeared after its last full pass. Restarting the app
does not help either — verified live against a freshly created References,
which sat folder-less while every other folder kept its original timestamp.
So the previous fix just burned its 120s timeout and failed.

A folder is bound to a collection by the hidden `.collection.json` marker it
contains — `{"guid":"…"}` — i.e. by GUID, not by folder name. Provisioning
already knows the guid of every collection it touches, so it now creates the
directory and writes that marker itself. Idempotent: a folder the mirror
already owns has an identical marker and is left alone. This also covers a
pre-existing collection that has never been exported.

`_plugin.json` is deliberately NOT synthesised. It is Thymer's export of the
LIVE schema, and writing our own would reintroduce exactly the second source
of truth this rework removed. `loadFolderSchema` already copes: with the file
unreadable it falls back to default labels and treats every field as present,
which is right for a collection whose schema we just seeded with those
defaults. Confirmed live — Thymer wrote the real `_plugin.json` itself once it
owned the folder.

Verified end-to-end: a real Zotero item synced into a fresh References
(`newRecords=1`), folder created and adopted, schema exported by Thymer.

Adds `IOUtils.makeDirectory` to the hand-written Gecko type declarations.
206 tests green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>