Files
cc-ci-orchestrator/cc-ci-plan/plan-phase7-upgrade-three-recipes.md

50 lines
1.8 KiB
Markdown

# 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.