Verified via FW_DEBUG=1 + systematic param-name probing that the
correct parameter is `taskCategoryId` with value = full metaId from
get_categories (e.g. taskCategory/23431854_200). Numeric systemCategoryId
alone causes API error; full metaId is accepted and stored.
Changes:
- create_task: add optional category_id parameter → sent as taskCategoryId
- update_task: add optional category_id parameter → sent as taskCategoryId;
guard now accepts category_id-only updates
- get_tasks: expose category_id field in returned task objects
- get_categories: update docstring (param name now known)
- SPEC.md: document verified taskCategoryId param + clarify categories[]
vs taskCategoryId field distinction
- scripts/find_category_param.py: discovery script used to find param name
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bug 1: all 171 category locale variants were returned; now filtered by
locale parameter (default "de") → 13 German categories for shopping lists.
Bug 2: TODO lists returned 171 shopping categories because
sortingIndexByTaskList contains ALL list IDs regardless of type.
Fix: look up list's taskListType via taskgettasklists, then match against
category's taskListType. TODO lists (type=TODOS) return empty list since
all API categories are SHOPPING_LIST type.
sortingIndexByTaskList is explicitly documented as unreliable for type
filtering in both code comments and SPEC.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- get_categories(list_id): new tool filtering taskcategorysync by
sortingIndexByTaskList, returns {id, name, emoji} ordered by sort index
- get_activities: author IDs now resolved to display names (firstName) via
famlistfamily members; raw author_id preserved as separate field; member
lookup is non-fatal (falls back to raw ID on error)
- CLAUDE.md: tools table updated to reflect all implemented tools (v0.4.8)
- SPEC.md: full accgetallfamily response structure documented including
categories[] on tasks and category parameter investigation findings
- Category assignment in create/update task: all tested parameter names
ignored by API; still to verify (Service Worker blocks web inspection)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
famlistfamily response already contains members[] on each circle object.
get_members(circle_id=None) extracts id, name, email, role, right, color,
avatar, circle_id and circle_name. get_circles refactored to use the new
_famlistfamily() helper, eliminating duplicated auth/call/logout logic.
SPEC.md updated with full famlistfamily response structure.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
FW_DEBUG=1 investigation revealed:
- wallmood can silently fail (200 OK, frozen modifDate, no state change) due to
self-like restriction, unsupported post type (FAMILY_CREATED), or rate limit
- Response contains two complementary like indicators: moodStarShortcut (primary)
and moodMap (secondary) — both must be checked
- liked: false with like=True now surfaces a warning instead of silently
returning a misleading result
- SPEC.md documents silent-fail scenarios and dual indicator pattern
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Extensive FW_DEBUG=1 testing revealed:
- wallmood with moodType=STAR is an idempotent SET operation, not a toggle
- Tested: all moodType variations, moodStarShortcut param, 9 alternative
endpoints — none could remove a like
- Service Worker in the web app prevents intercepting the real unlike payload
- like=False now returns a clear error; like=True continues to work correctly
- SPEC.md updated with full investigation notes and ruled-out approaches
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
FW_DEBUG=1 verification revealed:
- moodType "LIKE" was silently mapped to "STAR" server-side; use "STAR" directly
- Response a00.r.r contains full wall object with moodMap showing actual like state
- liked status now derived from moodMap rather than echoing the input bool
- SPEC.md updated with fully verified wallmood endpoint details
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
API error message confirmed the expected parameter is 'wall_message_id',
not 'wallId'. SPEC.md updated to reflect verified finding.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
marcus