Previously delete_category made two separate login cycles (accgetallfamily
to verify + taskcategorydelete to delete) = 6 HTTP calls. Now both happen
in one session = 4 HTTP calls. Halves latency and eliminates the risk of
a compounding timeout when the API is temporarily slow.
FW_DEBUG=1 investigation confirmed the API itself is fast (<1s); the
reported 4-min timeout was transient API slowness amplified by the double
session overhead.
Also recreated 'Obst & Gemüse' (emoji 🍎) as taskCategory/23431854_4956806
after it was accidentally consumed by the debug script.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Custom categories (rights.canDelete=true) have no locale field set by
the API and were silently excluded by the locale filter. They now bypass
both the locale and taskListType filters so they always appear in
get_categories output regardless of the locale parameter.
Also: deleted 7 test categories (TEmojiApple, Obst & Gemüse (old),
TestKategorie, ProbeKat2, [TEST]emoji=apple, ProbeKat1, TDelMeta)
and restored 'Obst & Gemüse' (emoji 🍎) as a clean custom category.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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