From RogerJagerDone 6 days ago
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.
Fixed in the next release. The ticket update only checked that the ticket belonged to your account, not to the project the agent works in, so an id from a sibling project was accepted. Updates (and mockup publishing) now refuse any ticket outside the current project and change nothing. If you can still reproduce it after this fix, please reopen the ticket with as many details as possible (a screenshot or video helps a lot).
Your request has been resolved and will be available in the next release.