collecting-test-credentials

name	collecting-test-credentials
description	Interactively negotiates test credentials for every external integration found in the analyzed workflows. Ensures complete separation between production and development environments. Activate when analysis is complete and the user is ready to set up test credentials, or when discussing dev credentials, test environments, integration setup, or environment separation.

Collecting Test Credentials

You are setting up a completely isolated development environment. Every external service the n8n workflows touch needs a test instance. The user decides how to handle each one — you present options and respect their choice.

---

1. Build the Integration Registry

From the analysis phase, compile every unique integration. Pull from:

• migration-state/discovery/credentials-list.json (credential types)
• migration-state/learned-nodes.json (nodes with has_side_effects: true)

Create migration-state/integration-registry.json:

{
  "integrations": [
    {
      "name": "PostgreSQL Main Database",
      "type": "postgres",
      "credential_name_in_n8n": "Postgres Production",
      "used_by_workflows": ["workflow_1", "workflow_3"],
      "has_side_effects": true,
      "strategy": null,
      "test_credential_env_var": null,
      "status": "pending"
    }
  ]
}

---

2. Present Each Integration to the User

Go through the registry one by one. For EACH integration, present:

Integration [n] of [total]: [Name]
======================================
Type:            [e.g., PostgreSQL, Telegram Bot, Stripe API]
Used by:         [list of workflow names]
Side effects:    [Yes — writes data / sends messages / charges money / No]
n8n Credential:  [credential name from n8n]

How would you like to handle this for testing?

  [1] PROVIDE TEST CREDENTIALS (Recommended)
      Create a separate test instance and give me the credentials.
      Examples:
      - Database: a separate test database or schema
      - Telegram: create a new bot via @BotFather
      - Stripe: use Stripe test mode API keys
      - Email: use a test mailbox or Mailtrap

  [2] MOCK / STUB IT
      I will create a local mock that simulates this service.
      Good for: services that are hard to replicate or expensive.
      Limitation: won't catch real API behavior differences.

  [3] USE PRODUCTION CREDENTIALS
      ⚠️  I will use the live service for testing.
      ONLY appropriate for read-only integrations with no side effects.
      You must confirm you understand the risks.

Your choice (1/2/3):

---

3. Handle Each Strategy

Strategy 1: Test Credentials

Ask the user for the specific values. Guide them through setup if needed:

Database (Postgres):

"Please provide a test database connection. Options:

• A separate Postgres instance (e.g., local Docker, free Supabase, Neon)
• A separate database on the same Postgres instance
• A separate schema (I will set up the shadow schema strategy)

I need: host, port, database name, username, password."

Telegram Bot:

"I need a test bot token (separate from your production bot). Two options:

[a] Walk me through @BotFather (recommended if you don't have one yet). I'll give you the exact 4 messages to send, you paste the token back here:

1. Open Telegram → message **@BotFather**
2. Send `/newbot`
3. Send a display name (e.g., `MyBot Dev`)
4. Send a username ending in `bot` (e.g., `mybot_dev_2026_bot`)
5. BotFather replies with a token like `1234567890:ABC...` — paste it here.

[b] I already have a test bot — just paste the token.

Which one? (a/b)"

If the user has neither and is unsure: default to (a) and walk them through. Do NOT ask about test bot tokens later in the migration — capture them now, during credentials collection, so the testing phase has them ready to go.

Generic API:

"Does [service name] offer a sandbox or test mode? If yes, please provide the test API key/token. If no, we should use Strategy 2 (Mock) instead."

For each credential received, generate an env var name and add to registry:

{
  "strategy": "test_credentials",
  "test_credential_env_var": "TELEGRAM_BOT_TOKEN_DEV",
  "status": "ready"
}

Add the actual value to workspace/config/.env and a placeholder to workspace/config/.env.example.

Strategy 2: Mock / Stub

Record in registry and note that a mock service is needed:

{
  "strategy": "mock",
  "mock_behavior": "Returns 200 OK with sample payload",
  "status": "ready_mock_needed"
}

During translation phase, generate a mock module in workspace/src/mocks/.

Strategy 3: Production Credentials (with explicit consent)

REQUIRE the user to confirm by typing the exact phrase: "I understand the risks"

Then:

{
  "strategy": "production",
  "risk_acknowledged": true,
  "risk_acknowledged_at": "<timestamp>",
  "test_credential_env_var": "SOME_API_KEY",
  "status": "ready_production"
}

Warn the user: "I will add safeguards — rate limiting, dry-run flags, and confirmation prompts before any write operation during testing. But using production credentials always carries risk."

---

4. Verify All Integrations Are Resolved

Before completing this phase, check the registry. ALL integrations must have a status of ready, ready_mock_needed, or ready_production. If any are pending:

"The following integrations still need credentials:

• [list] We cannot proceed to translation until every integration is resolved."

---

5. Generate the Environment File

Once all integrations are resolved, generate:

workspace/config/.env — actual values (gitignored) workspace/config/.env.example — placeholders for documentation

# Auto-generated by n8n Migration Toolkit
# Phase 3: Credential Collection

# === Database ===
DATABASE_URL=postgresql://testuser:testpass@localhost:5432/testdb
DATABASE_SCHEMA=shadow

# === Telegram ===
TELEGRAM_BOT_TOKEN=1234567890:ABCdefGHIjklMNOpqrsTUVwxyz

# === [Service Name] ===
# Strategy: mock — see workspace/src/mocks/service_name_mock.py
# SERVICE_API_KEY=not_needed_using_mock

And create workspace/config/.gitignore:

.env

---

6. Credential Summary

Present to the user:

Credential Setup Complete
=========================
Total Integrations: [n]

  Test Credentials:    [n] — fully isolated
  Mocked:             [n] — mock services will be generated
  Production (risky): [n] — user acknowledged risks

Environment file: workspace/config/.env ([n] variables)
Example file:     workspace/config/.env.example

All credentials loaded via pydantic-settings. No hardcoding.

Then ask: "All integrations are set up. Ready to proceed to Phase 4 (Translation)?"