| 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
DATABASE_URL=postgresql://testuser:testpass@localhost:5432/testdb
DATABASE_SCHEMA=shadow
TELEGRAM_BOT_TOKEN=1234567890:ABCdefGHIjklMNOpqrsTUVwxyz
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)?"
