Changelog

After pushing a locally-modified CalDAV event to the server, the sync

service updated the local event (to set SyncState="synced" and store

the new ETag) without passing localOnly: true. This caused the Rust

storage layer to clear the local_only column via INSERT OR REPLACE

with local_only=FALSE (extracted from the JSON payload which had no

local_only field).

Once cleared, the event became eligible for cloud sync — pushing

CalDAV-sourced events to the cloud relay when the CalDAV server is

the actual source of truth.

Fixed all three UpdateEventAsync calls in PushEventToServer and

DeleteEventFromServer to pass localOnly: true.

Adds the IApiProvider section listing all 11 REST endpoints with methods,

paths, and descriptions for task and project CRUD via the local API.

Reference implementation of the local HTTP API capability. Exposes 11

REST endpoints for task and project CRUD:

• GET/POST /api/v1/tasks — list/create tasks (supports ?status, ?project_id filters)
• GET/PATCH/DELETE /api/v1/tasks/{id} — get/update/delete task
• GET /api/v1/tasks/search?q= — search tasks
• GET/POST /api/v1/tasks/projects — list/create projects
• GET/PATCH/DELETE /api/v1/tasks/projects/{id} — get/update/delete project

All handlers use Host.Sdk.SendAsync() exclusively — pure SDK boundary.

Follows the existing partial class pattern (TasksPlugin.GraphData.cs,

TasksPlugin.Intents.cs).

Tasks AI features now check AiResponse.WasTruncated to provide clear

user feedback instead of displaying garbled or partial AI output.

Changes:

• Title generation: reject truncated responses with clear status message,

increase MaxTokens from 48 to 128 (48 was too tight for titles)

• Description rewrite: accept content but warn "(may be truncated)"
• Q&A questions: reject truncated responses (JSON would be malformed)
• Q&A description: accept content but show truncation warning

The settings cog button showed a tooltip on hover but clicking did nothing.

Root cause: AsyncRelayCommand's CanExecute returns false while a previous

execution is in-flight. If the RuleService SDK call during initialization

hung or took too long, OpenSettingsCommand would be permanently stuck in

"executing" state, silently rejecting all subsequent Execute calls.

Fix: Replace the Command binding with a Click handler in code-behind that

directly sets Settings.IsOpen and calls LoadSettingsDataAsync(), bypassing

the AsyncRelayCommand concurrency guard entirely. Also cleaned up debug

logging from previous investigation attempts.