---
description:
globs:
alwaysApply: false
---
# Execute Planned Task Commits from Task File

**Your Primary Goal: Systematically execute the step-by-step plan defined in a specified task file (e.g., `docs/tasks/<YYYY-MM-DD-task-name>.md`), creating each commit as planned and verifying its success.**

## File Existence Check

Verify that the provided task file exists before starting:

```bash
ls . docs
```

If the file is missing, stop and notify the user.

## Workflow for Each Commit in the Task File:

1.  **Implement Changes:** Execute the instructions for the *current* commit precisely as written in the task file.
2.  **Verify Thoroughly:** BEFORE committing, perform **ALL** specified **Verification** steps for that commit. Confirm successful completion of each verification step.
3.  **Commit Changes:** Stage all implemented changes. Create the Git commit using the exact commit message specified in the task file for this commit.
4.  **Proceed to Next Commit:** Immediately advance to the next commit outlined in the task file. **Do not ask for feedback or confirmation.** Continue this cycle until all commits in the task file are processed.

## Definition of "Task Completion"

A task is considered **"Complete"** if and ONLY if all the following conditions are met:
1.  **All Commits Created:** Every commit detailed in the task file has been successfully created.
2.  **Tests Pass:** All automated tests relevant to the changes made pass successfully.
3.  **All Verifications Successful:** Every verification step specified for *every* commit in the task file has been performed and has passed.

## Actions After Entire Task is Complete:

1.  **Invoke Project Update Rule:** Once the entire task is Complete (as defined above), you MUST then load and meticulously follow all instructions within the `.cursor/rules/project-update-rules.mdc` file.
2.  **Provide Feedback (to `project-update-rules.mdc`):** When prompted by the `project-update-rules.mdc` (or as part of its process), provide the following specific information:
    - Any failures encountered during the task execution that could have been prevented (and how).
    - Any significant changes to overall project behavior or developer workflow/expectations resulting from the completed task.

## Strict Output Constraints:

- **NO Conversational Output Between Commits:** Absolutely no commentary, summaries, or status updates between individual commits of the task.
- **Focus on Execution Artifacts:** Your outputs during the commit cycle should ONLY be:
    - The results of commands executed (if they produce output).
    - The diffs of file changes applied.
- **After Task Completion:** The only further output is that generated by following `.cursor/rules/project-update-rules.mdc`.
- **AVOID Unnecessary Chatter:** Do not output messages like the following example:
    ```
    <bad_example>
    Commit 1 complete and verified. Tests green. Verification successful.
    Moving to Commit 2 now.
    </bad_example>
    ```

**REMEMBER: Execute the task plan with precision. For each commit: Implement, Verify, Commit, then immediately Proceed. No chatter. Once all commits are done and verified, trigger the project update rule.**