0.2.1

A patch release, and worth taking: two of these fixes are visible in Tour #1 itself. Follow the tour on 0.2.0, map a class to a folder, generate its base — and the view is empty. That is fixed, along with the reason it was empty.

Fixed

• A generated base returned nothing for a class bound by folder or tag. The managed view filtered on the class property alone — fileClass == "Author" — and a note bound by Files paths or by a tag never carries that property. The filter now matches every binding it can express: the property, one file.inFolder() per mapped folder, one file.hasTag() per tag, or-ed together. inFolder rather than an equality on the folder because binding is by prefix: a note in Authors/Deep/ is bound too, and equality left it out. Bookmark groups and Base-view bindings have no Bases equivalent and stay outside the filter — the docs say which, instead of implying full coverage
• A base generated before its class was mapped is repaired on the next sync — and the Sync button now knows it needs one. Mapping a class to a folder changes no field, so the status compared columns, found them equal, and reported Synced over a view returning nothing. It compares the filter too, computed from the options in the form, and the folder and tag settings refresh it as you type. A filter you edited yourself is never touched: it becomes yours, and sync leaves it alone
• A nested tag now binds to the class its parent tag maps. A note tagged #author/french was left untyped while a class mapped on author claimed #author — and the generated view listed it anyway, because Bases' file.hasTag() includes children, as do Obsidian's tag search and tag pane. None of the Bases expressions can exclude children, so the two sides were aligned the other way: the resolver matches a tag and every tag it nests under, most specific first. This types notes that were not typed before — additive, nothing loses its typing — so a vault using nested tags will see more rows in its bases and more notes under validation
• Switching Bases on after Fileclass no longer needs a restart. Feature detection ran once, at layout-ready, and nothing re-ran it: a vault where the core Bases plugin was enabled later kept File/Media candidates and generated views disabled for the whole session, with no way to tell why
• A generated base could report Unknown view type: fileclass-table. The editable view is registered when Bases is available; a session that missed that moment rendered every base Fileclass had generated as an error — on a file Fileclass wrote itself. Registration is retried, and a failure is logged instead of being swallowed by a silent catch
• The Template option said what it was, not what it wasn't. It read "compose each value from fixed parts" — which is exactly what someone defining a list of allowed values believes they want — and never mentioned Select/Multi. Both the setting and the docs now name the two types that limit a field to values you choose, before explaining template syntax. That confusion cost a reader an hour and a half of goodwill; it was worth a sentence

Learning the plugin

The documentation home page now opens with the tour, the README links the series, and views.md describes exactly what the generated view filters on — including what it cannot.

Compatibility: minAppVersion 1.12.7. Fileclass builds on the core Bases plugin, which needs to be enabled.