Wave Wrapup

Classify each PR:

3. Determine merge order

Build a merge dependency graph:

• Parse PR bodies for Depends on #N or After #N references
• Check if any PR modifies files that another PR also modifies (merge conflict risk)
• Independent PRs can merge in parallel; dependent PRs merge in order

Present the proposed merge sequence:

**Merge Sequence: Phase {P} Wave {M}**

| Order | PR | Title | Status | Dependencies | Action |
|-------|-----|-------|--------|--------------|--------|
| 1     | #N  | ...   | Ready  | None         | Merge  |
| 2     | #N  | ...   | Ready  | After #M     | Merge  |
| —     | #N  | ...   | CI failing | — | Fix first |
| —     | #N  | ...   | Draft  | — | Skip |

Do NOT merge any PRs until the user approves the sequence.

4. Review each ready PR

For each PR marked "Ready", perform a review using charter format (same as /review-pr):

gh pr diff {NUMBER}

Post review comment:

Requestor: {Reviewer.Name}
Requestee: {PR author}
RequestOrReplied: Request

**Review: {LGTM or issues}**
Must-fix: {list or "None"}
Tech-debt: {list or "None"}

For each tech-debt item, create a GitHub Issue labeled tech-debt and the next wave/phase label.

If must-fix items are found, do NOT merge — report and wait for fixes.

5. Merge approved PRs

After user approval, merge in the determined order:

gh pr merge {NUMBER} --merge --delete-branch

After each merge, verify:

• CI passes on the target branch
• No merge conflicts introduced for subsequent PRs

If a merge introduces CI failures, stop and report before continuing.

6. Close resolved issues

Run /wave-audit logic to close issues resolved by the merged PRs:

# For each merged PR, check for Closes/Fixes/Resolves references
gh pr view {NUMBER} --json body

Close referenced issues with audit comments. Also check for issues matched by branch naming convention.

7. Verify completeness

Check that all wave issues are resolved:

gh issue list --state open --label "p{P}-wave-{M}" --json number,title

For any remaining open issues:

• If the work was deferred, move to the next wave label
• If the work was partially done, document what remains
• Report all unresolved items

8. Clean up worktrees (mandatory)

All wave worktrees MUST be removed before the wrapup is considered complete. Stale worktrees accumulate across waves and cause branch contention.

# Prune any stale worktree metadata
git worktree prune

# List all worktrees and identify wave-related ones
git worktree list

# Remove each wave worktree (branches matching wave assignees)
# Example: git worktree remove .claude/worktrees/W.Mwangi+0063-fix-branch-freshness-worktree --force

For each worktree:

1. Check if it has uncommitted changes (git -C <path> status --porcelain)
2. If clean, remove with git worktree remove <path>
3. If dirty, report to the user — do NOT force-remove without approval
4. Delete the remote tracking branch if the PR was merged: git push origin --delete <branch>

Report what was cleaned:

**Worktree Cleanup:**
- Removed: {count} worktrees
- Skipped (dirty): {count}
- Remote branches deleted: {count}

Why: Phase 2 Wave 1 left 6 stale worktrees after merge because cleanup wasn't enforced.

9. Update documentation

Check if any merged PRs affect documentation:

# List files changed across all merged PRs
for pr in {merged_pr_numbers}; do
    gh pr diff "$pr" --name-only
done

Flag any changes to:

• API endpoints (update API docs)
• Configuration files (update deployment docs)
• Architecture (update diagrams)
• Charter or process files (note for retro)

10. Final wave report

**Wave Wrapup: Phase {P} Wave {M}**

**PRs:**
- Merged: {count}
- Deferred: {count} (moved to next wave)
- Still failing CI: {count}

**Issues:**
- Closed: {count}
- Remaining open: {count} (deferred)

**Tech-debt created:** {count} new issues

**Documentation:** {docs updated | docs need update | no doc changes}

**Worktrees cleaned:** {count}

**Next step:** Run `/wave-retro` for full retrospective with assessments and trust updates.

11. Merge to main (final wave only)

If this is the final wave of the phase:

# Create PR from deployments branch to main
gh pr create --base main --head "deployments/phase{P}/wave-{M}" \
    --title "Phase {P} Wave {M} → main" \
    --body "Final wave merge. All PRs reviewed and merged to deployment branch."

Do NOT merge to main without user approval. This is a significant action that affects all downstream repos.

12. Ontology rebuild

Run /ontology-rebuild to process any files that changed during this wave. This ensures the ontology reflects the current state of all repos before the wave closes.

• If no dirty files exist in ontology/checksums.json, report "Ontology: up to date" and skip
• The resolver will auto-update docs where appropriate and flag recommend-only changes
• Include ontology changes in the final wave report

13. Annunaki error attack

Run /annunaki-attack to process any errors captured by the Annunaki monitor during this wave. This converts observed errors into preventative automation (hooks, skills, charter updates) before the wave closes.

• If .claude/annunaki/errors.jsonl is empty or missing, report "Annunaki: No errors captured this wave" and skip
• Use the current wave label for any issues created
• Include Annunaki-created issues and PRs in the final wave report totals
• This step runs before the memory-to-automation audit so that new hooks/skills from error analysis are visible to the memory audit

14. Memory-to-automation audit

Examine all memory files in the project memory directory for entries that describe behaviors, rules, or patterns that could be codified as a hook, skill, or charter update instead of remaining as soft memory.

Process:

1. Read all memory files:

   ls ~/.claude/projects/*/memory/*.md
   

2. For each memory file, classify it:

   Category	Criteria	Action
   Hook candidate	Describes a rule that should be enforced automatically (e.g., "always do X before Y", "never do Z")	Create the hook, add to settings.json, create GH issue for bookkeeping
   Skill candidate	Describes a repeatable multi-step workflow (e.g., "when doing X, follow these steps")	Create the skill in .claude/skills/, create GH issue
   Charter update	Describes a process rule or convention that should be documented for all agents	Update the relevant charter section, create GH issue
   Keep as memory	User-specific context, preferences, or project state that doesn't fit the above	Leave as-is

3. For each hook/skill/charter candidate: a. Create a GitHub Issue describing the automation opportunity b. Assign to the best-fit team member based on the charter mapping:

   • Hooks and charter updates → Aino Virtanen (Standards & Quality Lead)
   • Skills → Aino Virtanen or the domain expert for that workflow
   • Code changes → the relevant repo's tech lead c. Spawn or message that person with the issue details and full context d. Wait for them to confirm completion e. Once confirmed: verify the implementation (hook works, skill invokes, charter reads correctly) f. Push changes and close the issue g. Delete or update the memory file — if the memory's content is now fully captured in a hook/skill/charter, remove it. If partially captured, update it to reference the new automation.

4. Report what was converted:

   **Memory-to-Automation Audit**
   
   | Memory File | Classification | Action Taken | Issue |
   |-------------|---------------|--------------|-------|
   | feedback_x.md | Hook | Created validate_x.py | #N |
   | project_y.md | Keep | No action | — |
   | ...         | ...           | ...          | ...   |
   

Why: Memory files accumulate rules and patterns that should be enforced automatically. If a memory says "always do X", that's a hook. If it says "follow these steps for Y", that's a skill. Leaving these as memories means they only work when the LLM happens to load them — hooks and skills are deterministic.

Designated owner: Aino Virtanen handles most conversions (hooks, charter, standards). The orchestrator spawns her with the audit list and she reports back when done.

What remains manual

• User must approve merge sequence before any PR is merged
• Must-fix items require engineer action before merge
• Deferred issues need user decision on next-wave placement
• Final-wave merge to main requires explicit user approval
• /wave-retro must be run separately after wrapup completes
• Memory audit classifications are proposed — user can override keep/convert decisions