Integrate Seren API-key flow (#48)

* feat: integrate Seren API-key flow

* chore: fmt main

Author: taariq

.gitignore

@@ -21,8 +21,9 @@ Thumbs.db
 # Local AI/Agent configuration
 CLAUDE.md
 AGENTS.md
+GEMINI.md
 
 # Local documentation (not for repo)
 docs/20251127_AlphaGrowth_Testing_Bugs.md
 docs/design-onboarding-improvements.md
-docs/plans/
+docs/plans/

Cargo.lock

@@ -14,7 +14,7 @@ categories = ["command-line-utilities", "database"]
 [dependencies]
 tokio = { version = "1.35", features = ["full"] }
 tokio-postgres = { version = "0.7", features = ["with-serde_json-1"] }
-clap = { version = "4.4", features = ["derive"] }
+clap = { version = "4.4", features = ["derive", "env"] }
 anyhow = "1.0"
 tracing = "0.1"
 tracing-subscriber = { version = "0.3", features = ["env-filter"] }
@@ -37,3 +37,21 @@ base64 = "0.21"
 mongodb = "3.4"
 bson = "2.9"
 mysql_async = "0.34"
+dirs = "5.0"
+url = "2.5"
+chrono = { version = "0.4", default-features = false, features = ["clock"] }
+
+[[test]]
+name = "fallback_test"
+path = "tests/fallback_test.rs"
+doc = false
+
+[[test]]
+name = "state_test"
+path = "tests/state_test.rs"
+doc = false
+
+[[test]]
+name = "interactive_serendb_test"
+path = "tests/interactive_serendb_test.rs"
+doc = false

Cargo.toml

@@ -24,9 +24,31 @@ SerenAI provides managed PostgreSQL databases optimized for AI workloads. When r
 - Job monitoring and logging
 - Optimized for large database transfers
 
-To replicate to SerenDB, simply run:
+### Option 1: Interactive Project Selection (Recommended)
+
+With just your API key set, the tool will interactively guide you through selecting your target project and database:
+
 ```bash
 export SEREN_API_KEY="your-api-key"  # Get from console.serendb.com
+
+database-replicator init \
+  --source "postgresql://user:pass@source:5432/db" \
+  --local
+```
+
+The tool will:
+
+1. Show a picker to select your SerenDB project
+2. Automatically enable logical replication if needed
+3. Create missing databases on the target
+4. Save your selection for future `sync` commands
+
+### Option 2: Explicit Connection String
+
+If you already have your connection string, you can provide it directly:
+
+```bash
+export SEREN_API_KEY="your-api-key"
 database-replicator init \
   --source "postgresql://user:pass@source:5432/db" \
   --target "postgresql://user:pass@your-db.serendb.com:5432/db"

README.md

@@ -0,0 +1,32 @@
+I've got an idea I want to talk through with you. I'd like you to help me turn it into a fully formed design and spec (and eventually an implementation plan) Check out the current state of the project in our working directory to understand where we're starting off and then check the idea details below. Once done, ask me questions, one at a time, to help refine the idea. Ideally, the questions would be multiple choice, but open-ended questions are OK, too. Don't forget: only one question per message. Once you believe you understand what we're doing, stop and describe the design to me, in sections of maybe 200-300 words at a time, asking after each section whether it looks right so far. Keep in mind that whatever we fix here will affect the upstream repo /Users/taariqlewis/Projects/Seren_Projects/seren-replicator so all changes must be refactored upstream.
+
+Here's the idea
+
+1.would it be better UI/UX to remove the need for users to use the connecton string in the CLI for the databse the replicator/
+2. Instead have users use their SerenDB API key Alone
+3. The API Key allows users to lists all projects and all databases so the user just needs to select their target database to replicate against. 
+4. And then the connection_string can be read from the project by the database replicator instead of the user entering it. Easier UI/UX.
+5. This will also fix the `sync` issue where there's no direct API to look up a project by endpoint hostname.
+6. The API is setup for users to adjust settings on project.
+7. When init is run, the user selects their target project and then database. No more need for connection string.
+8. When sync is run, the system selects their already targeted project and database so they are syncing to the same database. We want to avoid users having to be confused by different branches so just make sure they are syncing to same database.
+9. Existing APIs:
+  
+  GET  /api/projects                              → List user's projects
+  GET  /api/projects/{project_id}/replication     → Get replication settings
+  PATCH /api/projects/{project_id}/replication    → Enable logical replication (set enabled: true)
+  GET  /api/projects/{project_id}/branches        → List branches
+  GET  /api/projects/{project_id}/branches/{branch_id}/endpoints  → List endpoints
+  GET  /api/projects/{project_id}/branches/{branch_id}/databases  → List databases
+
+ 10. Proposed UPDATED Replicator flow:
+
+USER enters their API KEY  
+GET /api/projects → Show project picker
+GET /api/projects/{id}/replication → Check if logical replication is enabled
+If not enabled: PATCH /api/projects/{id}/replication with {"enabled": true}
+USE the DEFAUTL branch from the project
+GET /api/projects/{id}/branches/{bid}/databases → Show database picker
+Start replication using the selected database's connection string
+Store replication target for sync run so that sync is to the same replication target.
+

docs/20251205_APIKEY_Upgrade_Brainstorm.md

@@ -4,11 +4,13 @@
 pub mod init;
 pub mod status;
 pub mod sync;
+pub mod target;
 pub mod validate;
 pub mod verify;
 
 pub use init::init;
 pub use status::status;
 pub use sync::sync;
+pub use target::command as target;
 pub use validate::validate;
 pub use verify::verify;