Phase 4 — Maintain & Evolve

Runs in a fresh session, possibly weeks later, possibly a different AI harness, zero memory of the build. Nothing here assumes "what we discussed earlier" — that context doesn't exist.

Step 1 — Rebuild context from the status file, not memory

Read PIPELINE_STATUS.md in full — app, stack, deploy state, change log (§5), open blockers (§6). Missing something referenced? Ask, don't guess from the app's name or assumptions about "what apps like this usually have."

Need to understand the codebase itself (not just the status file)? Use Repomix (shared/references/repomix-usage.md) — one deterministic command, not manual file-by-file exploration. Check repomix_cache_sha in PIPELINE_STATUS.md §3 first; only re-run if HEAD has moved since.

File missing entirely → reconstruct from git log + README, tell the user plainly, rebuild the status file from what's found plus what they confirm.

Step 2 — Understand the requested change

Same discipline as Phase 1 Step 1: concrete description before touching code. Bug report → get repro detail (what they did, expected, got), not just "it's broken."

Step 3 — Make the change

• Work on a branch (fix/<short> or feature/<short>) — never direct commits to main post-launch (per shared/references/ci-and-branching.md; Coolify auto-deploys on every push to main, so a direct commit is an immediate production deploy with no gate).
• Match existing conventions — don't introduce a new pattern for one change.
• Touches a module Phase 2 disabled-not-deleted (modules_removed_or_disabled)? Check there first — re-enabling beats rebuilding from scratch.
• Adds or changes a feature? Update FEATURE_BLUEPRINT.md (path in PIPELINE_STATUS.md §3) — it's a living document, not a one-time Phase-2 artifact. A stale blueprint defeats its own purpose for the next session that reads it.
• Run existing tests after the change, not just before committing.
• More than three steps? Ledger it. One line per finished task in docs/pipeline/LEDGER.md with its commit range (Task 2: complete (commits a1b2c3d..d4e5f6a)), and a separate reviewer for anything risky — auth, payments, migrations, anything that can lose data. Two verdicts: does it do what was asked (quote the request), and is it any good. Name the model on every dispatch; an omitted one inherits the session's expensive model. Full discipline: 00-orchestrator/SKILL.md → Delegation discipline.

Step 4 — Commit properly

Per shared/references/git-hygiene.md: small logical commits, never commit secrets, schema changes go through the boilerplate's own migration tooling — never hand-edit production data directly.

Step 5 — Push, let CI gate it, then merge and deploy

Push the branch. CI runs automatically (lint/typecheck/build/test — shared/references/ci-and-branching.md). Green → merge to main. Not green → fix on the branch, don't merge around it.

Once merged, Coolify deploys automatically. Verify the live site actually reflects the change — visit it, don't trust "deploy succeeded" alone.

Something breaks in prod → Coolify keeps previous deploy images, roll back from its dashboard immediately if real users are affected, debug separately after.

Step 6 — Update the status file

Append to §5 (maintenance log): date, what changed, git SHA, deployed y/n. Update §6 if anything's now blocked/resolved. This line is what lets the next session — months later, maybe a different AI — pick up instantly.

Recurring housekeeping (surface proactively, don't wait to be asked)

No fixed schedule, but raise it if it's clearly been a while:

• Dependency updates — Dependabot/Renovate if enabled, or manual npm outdated monthly.
• Backup verification — confirm scheduled backups are still landing (03-deploy-vps/references/coolify.md), not just configured.
• Security re-check — 03-deploy-vps/references/security-hardening.md §4: SSH config, Coolify version, dependency audit. A working app doesn't mean the launch baseline held.
• Alerting sanity check — notification channel + Uptime Kuma still active, pointed somewhere actually checked. alerting_configured: no in the status file → close that gap now if it was skipped originally.

Don't do these unprompted mid-urgent-bug-fix — mention once the immediate ask is handled.

Reference files

• references/git-pipeline.md — commit discipline, migrations, rollback, branching
• Also draws on 03-deploy-vps/references/security-hardening.md and 03-deploy-vps/references/alerting-monitoring.md for the recurring checks above