Wrap Up

/wrap-up $ARGUMENTS

You are running the delivery phase. Merge the branch, generate the PR document, and update tracking documents. You do NOT create GitHub PRs — the user handles PR creation manually.

Step 1 — Gather context

1. Read the plan file for $ARGUMENTS from docs/agomez/plans/
2. Determine if this is a standalone task or epic sub-task (from plan file)
3. Check the current branch: git branch --show-current
4. Get the commit history for the branch: git log --oneline <base-branch>..HEAD
5. Get the diff summary: git diff --stat <base-branch>...HEAD

Step 2 — Branch merge (epic sub-tasks only)

If this is an epic sub-task:

# Merge feature branch into epic branch
git checkout epic/MLID-XXXX-epic-name
git pull origin epic/MLID-XXXX-epic-name
git merge --no-ff feature/$ARGUMENTS-short-description
git push origin epic/MLID-XXXX-epic-name

# Clean up feature branch
git branch -d feature/$ARGUMENTS-short-description
git push origin --delete feature/$ARGUMENTS-short-description

Then continue to Step 3 to update the tracking documents.

Step 3 — Update plan status

This step always runs, for both task types, and it runs BEFORE the PR document — an epic sub-task with siblings still open stops after this step and never reaches Step 4, so status updates must not live downstream of it.

Which files to update depends entirely on whether the task belongs to an epic. Determine that from the plan file read in Step 1 (a sub-task plan names its epic and its base branch is an epic/… branch; a standalone plan has develop as its base).

Case A — standalone task (not part of an epic)

Update only the task plan document, docs/agomez/plans/<task_id>*.md:

• Set Status to Done
• Record the branch and the commit hashes

There is no epic document to touch. Do not go looking for one.

Case B — epic sub-task

Update both documents. Neither is optional, and the epic one is the one that gets forgotten.

1. The task plan — docs/agomez/plans/<task_id>*.md:

• Set Status to Done
• Record the merge commit into the epic branch, and the feature commit
• Note anything deferred (for example a staging pass scoped out), so a green plan is not mistaken for "verified everywhere"

2. The epic plan — docs/agomez/plans/<epic_id>-plan-progress.md:

• In the deliverable's task table, update this sub-task's row: Status → Done, Branch → the feature branch, Merged to Epic → Yes with the merge hash
• Use the Notes column for anything a sibling sub-task needs to know — a migration number, a constraint discovered during implementation, a deferred verification

3. Then check the rest of the epic document for reasoning the implementation invalidated.

The table row records that the sub-task is done. It does not record what building it taught you, and the epic document usually holds prose that is now wrong. Nobody arrives at these sections by updating a row, so check them deliberately. The usual places:

• Flagged concerns / resolved rulings — a ruling can stay correct while the reasoning behind it turns out to be incomplete. Implementation often finds consequences the ruling never considered. Mark it as refined, not overturned, and say what changed. This is the section a future reader consults before reopening the question, so leaving it as-is quietly hides what you learned.
• Dated "current state" observation sections — each later sub-task reads these before starting. Do not rewrite a dated observation; append a short "What <task_id> changed" note covering what the next sub-tasks actually need: what now exists, what is already wired, what is deliberately still pending, and any pre-existing failure they should not mistake for their own.
• Risk register entries — a risk this sub-task closed, realised, or made concrete.
• Open items carried forward — anything this sub-task answered.

Only touch what the implementation genuinely changed. If nothing outside the table row is affected, say so and move on — this is a check, not a mandatory edit.

Then decide whether to continue:

• If more sub-tasks remain in this deliverable → STOP here. Tell the user the sub-task is merged, both documents are updated, and what the next sub-task is. Do NOT generate a PR document.
• If the deliverable group is complete → continue to Step 4.

Step 4 — Generate PR document

Create a PR message document at docs/agomez/PR/$ARGUMENTS.md by analyzing:

• The plan file (for summary and context)
• Git log (for commits)
• Git diff (for files changed)

PR Document Structure

# [$ARGUMENTS] type(scope): short description

## Summary
- Bullet points of what was done and why

## Root Cause
(For bug fixes only — explain the underlying problem)

## Changes Overview
- **Files changed**: N
- **Lines added**: +N
- **Lines removed**: -N

## Files Changed

| File | Change | Description |
|------|--------|-------------|
| `path/to/file.ts` | Modified | What changed and why |

## What Changed and Why
Detailed breakdown of each change area. Include:
- Before/after examples where applicable
- Alternatives considered
- Design decisions made

## Commits
| Hash | Message |
|------|---------|
| `abc1234` | [$ARGUMENTS] - feat(scope): description |

## Test Plan
- [ ] Manual verification step 1
- [ ] Manual verification step 2

## Jira
- [$ARGUMENTS](https://localinfusion.atlassian.net/browse/$ARGUMENTS)

Step 5 — Present next steps to the user

Tell the user what manual steps remain for PR creation. Include the exact commands tailored to their task type:

For standalone tasks:

Next steps (manual):
1. Push the branch:  git push origin -u <branch-name>
2. Create the PR:    gh pr create --base develop --head <branch-name> --title "<title>" --body-file docs/agomez/PR/$ARGUMENTS.md

For epic sub-tasks (deliverable complete):

Next steps (manual):
1. Rebase on develop: git rebase develop && git push origin <epic-branch> --force-with-lease
2. Create the PR:     gh pr create --base develop --head <epic-branch> --title "<title>" --body-file docs/agomez/PR/$ARGUMENTS.md

Important Rules

• Git commands are OK — merges, rebases, pushes are allowed (user will approve via permission prompt)
• NEVER create GitHub PRs — no gh pr create or any gh commands. The user handles PR creation manually.
• NEVER transition Jira tickets — only update Jira when the user explicitly asks
• PR body from the document — use the generated PR doc content
• Epic sub-tasks: if the deliverable isn't complete, STOP after Step 3 — don't generate a PR doc. The status updates in Step 3 still happen; only the PR document is skipped
• Status updates are never skipped: a standalone task updates its task plan; an epic sub-task updates its task plan AND the epic plan-progress file. Step 3 owns this for both types, and it runs before the PR document precisely so an early stop cannot skip it
• Commit format: [$ARGUMENTS] - type(scope): description — no Co-Authored-By
• Always rebase before PR — ensure clean history against the base branch