fix: warn if build_command is missing git add uv.lock after template update

[ichoosetoaccept]

Adds a post-update validation to poe update-template that checks
pyproject.toml for the required git add uv.lock line in build_command.
Warns users who may have missed the fix due to copier merge behavior.

Resolves DOT-479

Closes #

[ichoosetoaccept]

This change is part of the following stack:

• fix: warn if build_command is missing git add uv.lock after template update #304 ◀

_{Change managed by git-spice.}

[linear]

DOT-479 copier update doesn't propagate build_command fix to downstream projects

[greptile-apps]

Greptile Summary

This PR extends the update-template poe task in the generated pyproject.toml.jinja with a post-update validation: for projects using semantic-release, it greps pyproject.toml for git add uv.lock CHANGELOG.md and warns if the line is missing, catching cases where copier's merge left the old build_command intact after a template update.

Confidence Score: 5/5

Safe to merge — the only finding is a P2 edge case (false negative if the target string appears outside build_command) that is very unlikely in practice.

The TOML/shell quoting and escaping is correct, the Jinja guard is scoped properly to use_semantic_release, and the shell group-command syntax is POSIX-compliant. The single P2 concern (grep scope) does not block correctness for the intended use case.

project/pyproject.toml.jinja line 259 — grep scope

Important Files Changed

Filename	Overview
project/pyproject.toml.jinja	Extends update-template poe task with a post-update grep check that warns when build_command is missing git add uv.lock CHANGELOG.md; grep searches the whole file rather than only the semantic-release section, risking a false negative if the string appears elsewhere.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["poe update-template"] --> B["copier update --trust . --skip-answered --defaults"]
    B --> C["uv sync --upgrade"]
    C --> D["prek autoupdate"]
    D --> E["echo ✓ Dependencies upgraded"]
    E --> F{use_semantic_release?}
    F -- No --> Z["Done"]
    F -- Yes --> G["grep -q 'git add uv.lock CHANGELOG.md' pyproject.toml"]
    G -- found --> Z
    G -- not found --> H["echo ⚠ WARNING: build_command missing git add uv.lock CHANGELOG.md"]
    H --> Z

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: project/pyproject.toml.jinja
Line: 259

Comment:
**grep searches entire file, not just `build_command`**

The check `grep -q 'git add uv.lock CHANGELOG.md' pyproject.toml` scans the whole file. If this exact string appears anywhere outside of `[tool.semantic_release]` (e.g. in a changelog entry, comment, or documentation string), the check silently passes and no warning is shown — even when `build_command` is still missing the line. A false negative here means releases silently produce stale lockfiles, which is the exact problem this check exists to prevent.

Scoping the grep to the semantic-release section would make it robust:

```suggestion
update-template = { shell = "copier update --trust . --skip-answered --defaults && uv sync --upgrade && prek autoupdate && echo '  ✓ Dependencies upgraded and hook versions updated'{% if use_semantic_release %} && { awk '/\\[tool\\.semantic_release\\]/,/^\\[/' pyproject.toml | grep -q 'git add uv.lock CHANGELOG.md' || echo '  ⚠ WARNING: build_command in pyproject.toml is missing \"git add uv.lock CHANGELOG.md\" — releases will produce stale lockfiles. Add \"git add uv.lock CHANGELOG.md\" to build_command.'; }{% endif %}" }
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (2): Last reviewed commit: "Update project/pyproject.toml.jinja" | Re-trigger Greptile}