feat(cli): place environments and tasksets in a Project

[solvemproblr]

Summary

Gives the CLI a way to say which HUD Project a new environment or taskset belongs to. Without this, everything the CLI creates lands in the team's default project, which is fine until a team starts separating work.

• hud project reports where a deploy from this directory would land, hud project list shows the projects you can see, hud project create <name> makes one, and hud project use <name> pins the directory by writing projectId to .hud/config.json.
• hud deploy and hud sync tasks take --project <name-or-id> and otherwise follow the pinned directory. Both send project_id on create and write the resolved project back into .hud/config.json, so a teammate deploying the same directory places it the same way.
• HUD_PROJECT is a machine-wide fallback for directories that are not pinned. Precedence is the flag, then .hud/config.json, then HUD_PROJECT, then the team default.

An environment or taskset that already exists stays where it is; naming a different project fails rather than moving it, since the platform does not support moving a resource between projects.

Depends on the platform's Projects API (/projects, and project_id accepted on environment and taskset create). Until that ships, the new commands return errors against production.

Test plan

• hud project list, hud project create, hud project use, and bare hud project against a control plane with the Projects API
• hud deploy with --project, with a pinned directory, with HUD_PROJECT, and with none of the three
• hud sync tasks in the same four cases
• Deploying an environment that already exists while naming a different project fails cleanly
• Unit tests: hud/cli/utils/tests/test_project.py, hud/cli/tests/test_deploy.py, hud/eval/tests/test_sync.py

Made with Cursor

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 46c5f09. Configure here.}

[cursor]

Writable check blocks sync no-ops

Medium Severity

resolve_writable_placement runs before the sync plan is known, so a pinned read-only project aborts the command even when nothing would be written. That blocks --dry-run and the “all tasks up to date” path for anyone whose .hud/config.json names a project they cannot create in, despite those flows only needing placement for display or for a later upload.

Additional Locations (1)

• hud/cli/sync.py#L355-L362

 

^{Reviewed by Cursor Bugbot for commit 46c5f09. Configure here.}