✅ No new issues found.

Reviewed changes — re-reviewed the delta since the prior Pullfrog review (73ca2b16): the endpoint switched its identifier from the project slug to the immutable projectId, made slug itself a patchable field, and added 409 conflict handling for duplicate slugs.

• Lookup by immutable projectId — handler.go now resolves the project via FindProjectByWorkspaceAndId and the request body requires projectId (^[a-zA-Z0-9_]+$, len 8-255), byte-identical to the sibling getProject request schema. The UpdateProject SQL is now keyed by WHERE workspace_id = ? AND id = ?.
• slug is now a mutable field — a new slug = CASE WHEN ... THEN ? ELSE p.slug END clause plus SlugSpecified/Slug params let callers rename the slug; the no-op short-circuit and the response/audit slug now reflect the requested value via the slug := project.Slug; if req.Slug != nil { ... } block.
• 409 on duplicate slug — db.IsDuplicateKeyError (MySQL 1062) maps the projects.workspace_slug_idx UNIQUE(workspace_id, slug) violation to codes.Data.Project.Duplicate, with a 409 spec block and ConflictErrorResponse $ref added to the path.
• Test coverage extended — new 409_test.go (slug collision), an update slug only 200 case asserting name survival, and 400 cases for projectId length/charset; 400 tests now use ptr.P for optional slug.

The identifier scheme now fully mirrors getProject, the read-independent CASE-on-specified-flags UPDATE keeps the persisted write race-free, and the 409 path is only reachable when the slug is actually being changed (the message correctly interpolates the requested slug). Verified IsDuplicateKeyError, the Duplicate URN, FindProjectByWorkspaceAndId, ConflictErrorResponse, and ptr.P all exist and the unique constraint backs the conflict. Both humans approved at 1853feca. Mergeable as-is.

ℹ️ Slug mutation vs. deployment domains

The new request-body description states that changing the slug "affects the deployment domains generated for this project," but the handler only updates the projects row.

• Deployment domains are built in svc/ctrl/worker/deploy/domains.go from <prefix>-<deploymentID>-<workspaceSlug>.<apex> — they key off the workspace slug, not the project slug.
• Already-generated domains are not retroactively rewritten by this endpoint, so existing deployments keep their current hostnames after a slug change.

This is a forward-looking scope question for the human, not a bug — flagging it only so the doc wording and any downstream expectation (e.g. whether future deployments pick up the renamed slug) stay aligned.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}