Can I grant permissions to a user for just an area, such as a category

Short answer: partly — per-category content permissions exist, but a per-category "admin" role doesn't. (Checked against the server source for the version running here, v1.2026.003.)

What CAN be scoped to a category — Admin → the category → Edit Category → Security tab grants a group per-category permissions: see topics, create pages, post replies, "Edit other people's topics" (may_edit_page), edit others' replies, edit wiki posts, delete topics/replies. Two gotchas:

• Groups only. The dropdown offers built-in trust groups and custom groups, not individual users. To target one person, create a custom group (Admin Area → Groups) with just them in it. (The server-side permission model does accept per-user rows, but there's no UI for that.)
• No inheritance to subcategories. A permission row on a parent category does not apply to pages in its subcategories — the server merges only the permissions set directly on the page's own category (Authz.scala, the [direct_cat_perms] comment; the nearby [cat_perm_inh_bug] note says the client can hint otherwise, but the server refuses). So for a subtree like Talkyard with its 7 subcategories, the same row must be added on every subcategory individually.

What can NOT be scoped — the "alter page" actions: change doing status (Planned / Started / Done), change topic type, accept a reply as the solution, close/reopen. Both the server and the web UI hard-code these to page author OR staff OR Core Members (trust level 6): the server shortcut is Authz.scala:413-415, and the UI controls (ChangePageModal.more.ts:93-96, post-actions.ts:261-264) never consult category permissions. Even a group with "Edit other people's topics" only gains the edit pencil on titles/bodies — the status/type/Solution?/close controls stay hidden. So the practical ways to let someone manage topic statuses are site-wide: lock their trust level at Core member (their admin page → Trust level → Change), or make them a moderator. The moderation queue, post approval, and suspending users are staff-only regardless.

Upstream status: this exact feature is on the maintainer's wish list — [cat_mods] "Category moderators" in docs/maybe-do-later.txt — and comments throughout the alter-page code paths point to a planned granular [alterPage] permission. The database schema already has the forward-looking columns (perms_on_pages3.can_alter_c, is_owner_c, can_manage_pats_c, added in migration v419), but no code reads them yet in this version.

For the example in the question (a "talkyard dev" user administering the Talkyard category): a custom group plus Security-tab rows on the category and each subcategory gives scoped content editing today; for status/solution/close powers the only current options are site-wide — Core member trust level, or moderator.