[BUG] Failed deployment with uppercase stack names leaves behind orphaned cloned repositories

[xd003]

Description

When creating a stack from a Git repository, using a stack name that contains uppercase letters results in an inconsistent deployment flow.

Steps to reproduce

1. Create a new stack from a Git repository.
2. Enter a stack name containing uppercase letters (e.g. Zerobyte).
3. Deploy the stack.

The deployment proceeds as follows:

Connects to the repository.
Clones the repository.
Fetches the branch.
Reads the compose file.
Only then fails with:
Error: Stack name must be lowercase, start with a letter or number, and contain only letters, numbers, hyphens, and underscores

At this point, the repository has already been cloned into:

DATA_DIR/{environment}/Zerobyte

If I then rename the stack to zerobyte and deploy again, the deployment succeeds, but Dockhand clones the repository again into:

DATA_DIR/{environment}/zerobyte

This leaves the original Zerobyte directory behind as an orphaned/unused clone.

Dockhand version

1.0.37

Hawser version (if used)

No response

Connection mode

socket

Please confirm the following

• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.

[jotka]

hi @xd003 Thanks for the clear repro.
Root cause: the git-stack create path validated the name with a looser rule than the deploy path — it allowed uppercase, so Zerobyte passed the form and the create endpoint, got its DB rows and repo clone, and only then failed at deploy (where Docker Compose requires a lowercase project name), leaving the orphaned git-repos/{env}/Zerobyte clone behind.

We now enforce the lowercase rule early — in the form and at the create endpoint, before anything is cloned. An uppercase name is rejected immediately with inline validation, so no repo is cloned and no orphan is created. Landing in the next release (1.0.38).