Managed Folder guard: refuse thread.project.adopt-folder explicitly, not only through ScratchThreadPromotion #151

What

The managed Folder guard (apps/server/src/lazurio/managedFolderGuards.ts, commandRefusal, from :107) checks thread.create, thread.metadata.update, message.dispatch, thread.fork and delegated_task.request, and lets every other command through (default: return Effect.succeed(null)). Since v0.1.4 upstream has thread.project.adopt-folder (apps/server/src/orchestration-v2/Orchestrator.ts:506 on v0.1.5 6d450a4284), the command behind "Turn into project", and the guard does not look at it.

Why it is not a bug today

Its only dispatcher, ScratchThreadPromotion (apps/server/src/project/ScratchThreadPromotion.ts:119 on v0.1.5), runs on the guarded project service on a managed Environment and fails closed before it dispatches (decision B in #148; managedFolderGuards.test.ts checks that a promotion under the managed Folder dispatches nothing).

Why it matters later

The guard's comment says every command passes dispatch, so it holds "for clients, agents, scheduled tasks and the server's own launches alike". A future upstream dispatcher of thread.project.adopt-folder that does not go through ScratchThreadPromotion would move a thread out of the Folder project unchecked.

Proposal

Refuse thread.project.adopt-folder in commandRefusal on a managed Environment (or allow it only for a target the guard accepts), with a test that dispatches the command directly and expects the refusal. Found by the independent check of the v0.1.5 rebuild (#148, PR #149); not fixed there to keep the rebuild's scope.

🤖 Generated with Claude Code