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.

1.8 KiB Raw Blame History