# Confluence Space Administration & Color Schemes — Agent Guidance Covers `src/tools/spaces-admin.ts` (19 tools) and `color-schemes.ts` (9) — space lifecycle (create/update/archive/delete/trash/properties/watchers/categories) plus global and per-space theming. Confirmed live 2026-08-20; see `docs/plans/2026-08-20-full-api-coverage.md` batches 6 and 8 for the full record. ## Space/personal-space `description` must be a structured object, not a string `create_space`, `update_space`, `create_private_space`, `create_personal_space`, and `admin_create_personal_space_for_user` all build the request body as `{plain: {value: , representation: "plain"}}` internally — you just pass a plain string as `description` and the tool wraps it. This matters if you're ever debugging a raw request: a bare string 400s with a genuinely confusing error (`"Cannot construct instance of EnrichableMap ... no String-argument constructor"`). This bug existed in two different tools (`create_personal_space` and `admin_create_personal_space_for_user`) until live-testing the second one exposed it — the first one's own live test happened to 400 on an unrelated "already exists" error before ever reaching the bad request body, which masked it. Worth remembering: a tool's own passing live-verification only proves the paths it actually exercised. ## `admin_restore_space` doesn't reliably restore anything Confirmed live: calling it against a space whose deletion had *already fully completed* (verified via the deletion's own longtask: 100%, successful) returns a misleading 200 success with an empty body — but the space is **not** actually restored, still 404 afterward. The request genuinely succeeds; the claimed effect doesn't happen for a hard-deleted space in this environment. Don't treat a 200 from this tool as confirmation the space came back — verify with `get_space` or `list_space_content` before telling a caller it worked. ## Deleting a space (or a user) is asynchronous `delete_space`, `empty_space_trash`, and `admin_delete_user` all return quickly with a task reference, not a completed result — the actual deletion happens in the background. If you need to confirm completion (e.g. before recreating something with the same key), poll `admin_get_backup_restore_job`-style status isn't applicable here; instead re-fetch the space/user directly (`get_space`, `get_user`) until it 404s, or check `admin_list_long_tasks` for the matching task's `percentageComplete`. **Deleting a user does not delete their personal space** — confirmed live, it's left behind as orphaned content at `~`, fully accessible. If a caller wants both gone, that's two calls: `admin_delete_user` then `delete_space` on `~`. ## Color schemes: pass the whole object back on update `get_global_color_scheme`/`get_space_color_scheme` return an object with `colorSchemeModelLight` and `colorSchemeModelDark`, each a flat map of many named hex-color fields (topBar, headerButton, searchField, menuItem, etc. — see a live response for the full field list, it's long and not worth duplicating here). `update_global_color_scheme`/`update_space_color_scheme` expect the **full** replacement object, not a partial patch — read the current scheme first if you only want to change one field. `reset_global_color_scheme`/`reset_space_color_scheme` revert to Confluence's built-in default in one call, no object needed. ## Space categories vs. labels `add_space_category`/`remove_space_category` (this domain) are a different, older mechanism from `list_space_labels` and friends (`skill://content`) — categories are a small, space-level classification tag; labels are the general-purpose tagging system used everywhere else. Don't conflate them when a caller says "tag this space."