One tree, many lines

Post the month from the statement, then categorise it here: pick a tree, get every line in the period on one page, and tab down the tag column. The picker only offers tags from the tree you chose — so the one-per-tree rule is in the control, not in a refusal after you have typed.

⛔ One tree per run, and that is the shape rather than a limitation. A page with a column per tree would need columns that vary with your data, and columns are authored while trees are records — add a fourth tree and no recipe could grow a fourth column. So the multiplicity lives in runs: three trees is three passes, each one a page you tab down.

What you can and cannot type

⛔ Only the tag cell accepts typing. The line, its amount and its date are shown so you know what you are categorising, and locked so you cannot re-point a tag at a different transaction by editing the row it is sitting in. Shown and editable are different questions, and only the second is a write.

⚠ Leave a cell blank to skip that line. Blank means "not now", never "remove its tag" — clearing a dimension is naming a different tag in it, which is what tag-leg is for.

What it writes

One leg_tag row per line you tagged, carrying the line's FULL amount — the same money counted at every level above the tag you picked. Existing tags from OTHER trees are untouched; a tag already set in THIS tree is replaced.

⛔ All of it lands or none of it does. A half-applied page would leave some lines categorised and no way to tell which, on a screen you have already moved on from.

Limits

⛔ 50 lines a page, and the ceiling is arithmetic rather than a preference. Re-tagging a line is two writes — the old tag out, the new one in — and a batch holds 100. A 100-line page could therefore be filled in and then refused, which is the one failure worth designing away: you would have done the work already.

⛔ Past 50 it refuses BEFORE drawing the page, so you are never shown a grid you cannot submit. Narrow it by account — and only by account: a period is a whole month here, so there is no shorter one to ask for.

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 (leg_tag.apply — replacing a tag means deleting the old row), 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.