The money follows, and nothing is rewritten

"Groceries should sit under Household, not Food." One move, and every transaction ever tagged Groceries now rolls up under Household — because spending points at the tag, and the tag's identity does not change. Not one recorded transaction is touched.

That is the whole reason the tree is stored as ancestry rather than as a path. A path would have to be copied onto every tagged transaction to make rollups cheap, and then this operation rewrites thousands of rows instead of a handful.

⛔ Detach and re-attach land together. One tag.restructure batch, so there is no moment where the tag hangs under both parents or under neither. A half-done move leaves a tag reachable from some ancestors and not others, and every rollup above it disagrees with every other.

⛔ It moves a tag with NOTHING UNDER IT

A tag that has children is refused, and this is a real limit rather than a policy.

Re-attaching a subtree means writing one edge for every (new ancestor × moved descendant) pair — a CROSS PRODUCT of two lists known only while the recipe runs. A recipe has foreach over one array and nothing that pairs two, so that set cannot be produced. Doing it a batch at a time would leave the tree half-moved between batches, which is worse than not offering it.

⚠ This is specifically a cross product, not "anything involving two lists". Folding many rows into one row per key IS expressible — group_by takes an aggregate and budget-board uses it to do every budget in three queries. Grouping collapses one list; a cross product builds a bigger one, and only the second is out of reach.

What to do instead: move the children out first, move the parent, move them back. Tedious and completely safe — every step is one of these.

⛔ Moving a tag into a DIFFERENT TREE is refused. A tree is a dimension — person -> department -> division is one thing, a project tree is another — and a tag that changed dimension would silently reclassify every transaction ever tagged with it. That is a re-tag, not a move.

⚠ Moving a tag under one of its own descendants is refused too. That would make it its own ancestor, and every rollup beneath would recurse.

It needs FULL access at install

⛔ This recipe is DENIED if the pack was installed with write access — pick all. It drives a batch operation whose allow-list contains a delete (tag.restructure — moving a tag deletes its old closure edges), and a batch's risk floor is the union of everything it may do, so the whole operation is classed destructive. write does not grant that.

⚠ The refusal is operation_not_granted at the gateway, which reads like a bug in the recipe rather than a scope you chose at install. It is not something the recipe can detect and explain for you — the denial happens before its first step runs.