# cc-ci Phase 7 — run targeted upgrades on n8n, ghost, and matrix-synapse

**Status:** QUEUED — runs after phase 6.
**Owner:** `cc-ci-assistant` session only. Not a Builder/Adversary loop phase.
**This file:** `/srv/cc-ci-orch/cc-ci-plan/plan-phase7-upgrade-three-recipes.md`

---

## 1. Goal

Run the targeted post-build recipe upgrade work for:

- `n8n`
- `ghost`
- `matrix-synapse`

This is operational recipe-maintenance work and should be driven by the assistant, not the
Builder/Adversary loops.

## 2. Definition of Done

- [ ] Research the current upstream upgrade target for each of the three recipes.
- [ ] For each recipe, determine whether an upgrade is actually available and worth opening.
- [ ] Run the established upgrade workflow for each upgradeable recipe.
- [ ] For each recipe PR opened, verify the expected cc-ci testing path is triggered and record the outcome.
- [ ] Summarize all opened PRs, blocked upgrades, and any follow-up needed from the operator.
- [ ] Leave the assistant session idle and ready for the next assignment when complete.

## 3. Method

- Prefer the existing assistant-accessible upgrade tooling and documented workflows.
- Default to the smallest correct per-recipe change set.
- Keep one clear record per recipe: checked, upgradeable or not, PR opened or not, verified or blocked.
- If a stale cc-ci test is the only blocker, report that explicitly instead of improvising beyond the
  established workflow.

## 4. Deliverables

- A summary covering:
  - `n8n`
  - `ghost`
  - `matrix-synapse`
- For each: upstream target, action taken, PR URL if any, verification result, and remaining risk.

## 5. Guardrails

- Never merge PRs.
- Do not use the Builder/Adversary loop clones as the assistant's scratch workspace.
- Record blockers clearly rather than pushing through uncertain migrations.