3.1 KiB
SLICE13 — Idempotent Conductor upgrade process
Status: Planned
Purpose
Provide one reusable upgrade process that preserves customer data, configuration and installed applications and can be rerun safely.
Working instructions
Read CODEX.md and applicable AGENTS.md instructions before work. Current source and tests are authoritative. Preserve unrelated working-tree changes. Use this file as both the slice specification and its continuing log.
This slice is planned; do not start it as part of SLICE10. Update the checklist and append dated log entries as work proceeds. Record decisions, changed files, checks and results, failures, unresolved issues and the next action. Do not erase earlier log entries or claim VM/release acceptance from local tests alone.
Scope
- Choose a shared upgrade implementation exposed through an upgrade mode or update-conductor.sh; avoid accumulating one-off numbered patch scripts.
- Inspect current installation and target compatibility before changing live state; support a read-only dry run.
- Back up Conductor data, keys, configuration and installed-app state before mutation.
- Preserve users, passwords/keys, projects, publications, app packages, registry records and API connection settings.
- Apply supported migrations once and keep source-independent installed apps functional during core upgrades.
- Use locking and repeatable steps so interrupted or repeated runs do not duplicate apps, regenerate credentials or reset settings.
- Check health and representative application routes after upgrade.
- Provide and verify recovery to the previous working image/data combination.
- Document update, retry, compatibility-failure and recovery procedures.
Acceptance checks
| Action | Purpose / expected behavior |
|---|---|
| Upgrade the existing supported installation | Customer data, identity and installed applications remain available. |
| Repeat the same upgrade | No duplicate entries, unnecessary key rotation or configuration reset occurs. |
| Interrupt a controlled test upgrade and rerun | The process resumes safely or exits with an actionable recovery path. |
| Simulate failed health/compatibility checks | Live state is preserved or the documented recovery path restores service. |
| Run dry-run with protected setup records | sudo permits inspection while no application state changes. |
Boundaries and dependencies
Depends on SLICE12. Preserve the earlier completed slices and their logs.
The customer control panel and other SaaS backlog items remain outside these four slices. The user reports only one live Conductor instance, which has Social Scheduler installed. A clean Conductor reset is an available fallback if a safe retrofit is impractical; first record the exact scope and backup/recovery plan. This does not authorize wiping the entire VM or deleting Node-RED's saved connections or PostgreSQL's schedules.
Progress log
2026-09-13 — Plan recorded
- Renamed the proposed four phases to SLICE10, SLICE11, SLICE12 and SLICE13, respectively.
- Implementation has not started.
Current handoff
Await completion of the preceding slice and the instruction to proceed.