backlog_update can mutate sibling-project tasks by ID

backlog_update can mutate sibling-project tasks by ID A write from ARBT resolves and changes a task UUID belonging to another project. Runnable reproduction / implementation sketch backlog_get({"project":"<sibling-project>","taskId":"<sibling-task-id>"}) backlog_update({"taskId":"<sibling-task-id>","status":"pending"}) backlog_get({"project":"<sibling-project>","taskId":"<sibling-task-id>"}) // Restore original status immediately. Steps Read a sibling task and record status. From the current project, update the UUID without project. Read the sibling task again. Restore its exact original status. Safety HIGH RISK. Prefer preserved evidence. If rerun, restore in the same sequence. Observed The current-project write returns ok:true and the sibling task changes. Independently reproduced and restored twice. Expected / proposed Current-project mutations must not resolve sibling-project task IDs. Why it matters Project-isolation failure capable of corrupting unrelated backlog state.

This gathers what several people told us separately. Their original messages stay private: only this rewording is public, and nobody sees who wrote what.

Discussion0

You will be told by email and in the app on every reply. Every message carries a link to stop them.