Find out what nothing is using

No. It installs no tables, writes nothing and deletes nothing.

Deleting a field deletes its content for every element, permanently, and that decision belongs on Craft's own settings screen — with Joan's cleanup list open next to it. A plugin with a "delete all unused" button would eventually be right about everything except the one field that mattered.

Nothing. One edition, everything included.

Joan reads. It cannot damage anything, which made it hard to argue that anyone should pay to find out whether it worked on their site.

It tells you a useful third of it. The field settings screen lists the field layouts a field appears in, and that is where Joan starts too.

What it does not do: count whether a single element has ever had a value in that field, look at your templates, or identify a field layout it cannot attribute to an element type. For that last one it says "1 unknown field layout" and leaves you there.

Never filled in means the field is on a layout, editors can see it, and not one of them has ever put anything in it. The field is reachable; nobody wants it.

Unused means it is on no layout at all, holds no content, and is named nowhere in the scanned code. Nothing can reach it and nothing would miss it.

The first is a content-model question. The second is housekeeping.

Craft 5 keys stored content by field layout element, not by field. Take a field out of a layout and its values stay behind in the content column under a key nothing will ever read again.

It is not a reason to delete the field faster — it is a reason to check whether the field was removed on purpose. If it wasn't, putting it back in the layout brings the content into reach again. Deleting the field destroys it.

Within what a text search can do, and Joan is clear about which is which. It classifies every hit — entry.myField is worth more than the word myField in a comment — and shows you the file, the line number and the source line, so you can read the evidence rather than the conclusion.

What it cannot see is a handle built at runtime. entry[someVariable] is invisible to any scanner, which is what the leave-alone list is for.

Yes, and this is the part most searches get wrong. Craft 5 lets a layout override a field's handle for itself, so heroImage in one section and image in another can be the same field. Joan reports every handle a field answers to and scans the codebase for all of them — a search for only the field's own handle would miss half its uses.

No. Joan runs in the control panel and in the console, and the inventory is cached against Craft's own field version, so any change to a field or a layout invalidates it the moment it is saved.

The one expensive thing is a rebuild — four passes over the database and the codebase — and it sits behind its own permission for that reason. Nothing in Joan runs on a front-end request unless you call craft.joan from a template yourself.

Yes, and there is a switch for when it doesn't. Count content usage can be turned off, which makes every rebuild cheap and every element count unknown, while the layout attribution and the code scan carry on working.

That is the honest trade, and most sites never need it.

Joan reports it as Not counted — never as zero, because a zero is what gets a field deleted.

The plugin that owns the field type can report the real number instead, through Inventory::EVENT_DEFINE_FIELD_USAGE. There is a second event, CodeScan::EVENT_REGISTER_SCAN_PATHS, for code that lives outside the configured paths. Both are documented in the repo.

Both.

Fine, and neither needs the other. Microscope has a check that counts unused fields as one line in a performance audit, and its own advice is to search the codebase before deleting anything.

Joan is that search, and the rest of the answer.

Nothing is left behind. There are no tables to drop and no content to migrate out, because Joan never put any in.