easterbrooka treats the project folder as a security boundary
A quiet self-merge promotes matter isolation from convention to enforced control.
In a legal-AI assistant, the project folder is the unit of scope - documents, matter context, and working artefacts all live under one. easterbrooka's change treats that folder as a hard boundary: file reads, writes, and any tool-driven traversal shouldn't be able to escape the active project, leak across matters when several are open, or wander into sibling folders belonging to unrelated clients.
The author left no PR description and merged the work into their own fork within seconds of opening it, so the public signal is thin - but the branch name is unambiguous. The move worth flagging is the promotion of project scope from a UX convenience to an enforced isolation guarantee. For software that routinely handles privileged material, that distinction is the difference between a polite convention and a control you can actually point to.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?