Hey — reviewed this against our full task landscape. The concept can work, but the framing needs to shift to pass the overlap gate. Here's why and how:
The problem with the current framing: As written, this reads as "deploy CloudNativePG + PgBouncer + WAL archiving + monitoring" — a greenfield build task. That overlaps heavily with the approved PostgreSQL HA + PgBouncer task (Patroni), which covers the same flow with a different tool. "Different tool, same operation" is a tough sell when we have 15+ PostgreSQL tasks.
The angle that makes this distinct: What no existing task covers is live infrastructure migration — the planned, zero-downtime migration of running production databases from one management paradigm to another. That's the genuinely novel core of your idea, and it tests skills that none of the existing PG tasks touch: migration planning, cutover orchestration under live traffic, data consistency across the migration window, rollback strategy, and decommissioning old infrastructure.
Concrete reframing suggestions:
-
Make migration the headline, not CloudNativePG. The task is "live-migrate Bleater's production databases to operator-managed PostgreSQL," not "deploy CloudNativePG." The operator is the target, not the point.
-
Pre-deploy the operator in setup.sh. The CloudNativePG controller and CRDs should already be installed. This removes the "greenfield deployment" overlap and puts the agent's work squarely in migration territory — they need to create Cluster resources, plan the migration, execute it, and verify it.
-
Emphasize migration-specific complexity in the description:
- 3 databases to migrate under live traffic (auth, bleat, like services)
- Migration ordering and dependency analysis
- Data consistency during the export-import window
- Connection string cutover while services are running
- Rollback plan if a migration fails partway through
- Decommissioning old StatefulSets only after verified stability
-
Grade on migration outcomes, not setup steps. The grading criteria should focus on: zero-downtime cutover, data integrity verification, all services successfully pointing to new clusters, old infrastructure cleanly retired. WAL archiving and Pooler configuration become supporting requirements of "the new setup must be production-ready," not standalone objectives.
This reframing should pass cleanly — live infrastructure migration is a distinct operation category from troubleshooting, greenfield builds, DR, and restructuring, which are what our existing PG tasks cover.