Varun reported his hand-written tasks disappearing on Aug 27. The guard shipped that day (#2605) stopped the agent deleting and closing them, and it works: since the deploy every cancel-task and every update-task carrying status has been refused (9 refusals across 3 users, 0 user-authored tasks deleted).

He came back the next day anyway. Twice on Aug 28: "I'm also getting the updating animation for tasks that I made", then "My tasks keep getting moved or deleted. I'm going to stop using the tasks feature." He had asked for the wider thing on Aug 27, right after the fix landed: "I don't want the AI to close or reorganize my tasks", and earlier "can cedar not also move my tasks to a different column either?"

The guard was scoped to status alone, so it never looked at the calls that were actually reorganizing his board.

What was still getting through

dueDate is not a schedule on this surface, it is where the row sits. The board buckets by due date (dueBucket, TaskListView.tsx:63), so writing it moves the task to another column.

Run 2cece6ef, Aug 28 17:25:48, on his hand-written "Review Tech memos for residential":

{"taskId":"b2fdc9bf…","dueDate":"2026-09-01T13:00:00Z",
 "notes":"…Move to Sep 1 to align with next week's work plan."}
→ {"changed": true, "success": true}

No status in the payload, so the guard never ran.

description is the wording the user chose. agenda-to-tasks.ts:258 already treats it as human-origin only ("the user's wording is gone and the next rewrite layers more decoration on top of the decoration"); the tool path disagreed with the document path and rewrote a second user's task title the same day.

Fleet-wide since the deploy: 5 dueDate, 5 notes, 3 description writes on user-authored tasks; 3 landed.

The change

UserOwnedTaskField now names {status, description, dueDate} and the refusal is built from that list. Enrichment stays allowed , notes, taskType, tags, agentExecutionEnabled, draft attachment , because it annotates a task without changing what it says, when it is, or whether it is done.

Three details worth review:

• The whole call is refused, not just the protected fields. In a mixed call the allowed fields are written to justify the protected one: the Aug 28 run paired its move with a note explaining the move. Applying the note alone would leave a false statement on the user's own task.
• Placed after due-date normalisation. skipToNextWeekday and the past-due reschedule can both turn a supplied date into the one already stored, and re-asserting a task's current position is not a move.
• The refusal path also now closes its DB connection, which the original guard returned without doing.

Second, unrelated-looking half: the reappearing task

Same reporter, same day: "every time I navigate to the tasks tab, I see a task that I marked complete but it reappears… I'm not sure if I'm hallucinating."

He wasn't, and nothing was resurrected in the database , I checked for completed_at IS NOT NULL AND status='todo' and he has zero such rows. It was purely client-side. AgendaDocument runs its own day-ranged listUserTasks and mirrored the result through raw setTasks, the one door into the store that server task data reached unmasked. During the ~5s undo window the server still says todo, so the mirror put the row straight back.

Adds upsertServerTasks: masked like hydrateTodoTasks, reconciling no removals because a day-ranged list is partial. Both now share one upsertMaskedTasks helper, so the mask can't be dropped from one door and kept on the other.

Deliberately not in scope

• NULL authorship. isUserAuthoredTaskProtected only matches the literal 'user', so NULL fails open. All ten insert(userTasks) paths stamp authorship, and all 149 NULL rows predate June 2026 with 79 carrying a creation_run_id , they are legacy agent rows. Protecting them would block cleanup