Lifecycle Setup

​

When Lifecycle Setup Happens

1. Setup Build Environment
2. Set Modernization Goals
3. Generate Project Spec
4. Approve Project Spec
5. Choose Validation Level
6. Project Setup ← lifecycle setup happens here
7. Generate Roadmap

​

Setting Up the Lifecycle in Chat

​

What the agent works through

1. Inventories the repository — framework, install/build/run commands, health-check signals, environment variables, external service dependencies — and reports what it found before writing anything.
2. Proposes the phases and confirms them with you. Beyond the standard five, this can include steps like migrate or per-service splits in multi-service projects.
3. Registers the scripts and environment variables, asking you for values it can’t infer.
4. Executes the lifecycle end to end to prove it works. On failure it shows you the failing phase, the last lines of output, and a proposed fix before retrying.

​

Answering the agent’s questions

​

Providing secrets

​

When setup finishes

​

The Project Setup Panel

Project Setup
├── Origin
│   ├── Scripts
│   ├── Environment Variables
│   └── Lifecycle Document
├── Target
│   ├── Scripts
│   ├── Environment Variables
│   └── Lifecycle Document
├── Acceptance Criteria
└── Dockerfile   (Modelcode Hosted)  /  Dependencies  (Self-hosted)

• Origin - How the source application builds and runs. Set up with you during Project Setup and used as the behavioral baseline for functional testing.
• Target - How the destination application builds and runs. Discovered automatically during the foundation milestone (Milestone 1). The Target entry stays disabled until then, with the tooltip “Available once a target lifecycle configuration has been discovered.”

​

Scripts

• Inline code editor - Edit the script content directly. Scripts are executed as shell commands.
• Logs - The stdout output from the last validation run, with the exit code and duration.
• Errors - The stderr output. A bug icon appears on the script header if the last run failed with stderr output.

​

Environment Variables

​

Lifecycle Document

​

Dockerfile and Dependencies

​

What You Edit Directly vs. What the Chat Owns

The run script should bind to port 8080, not 3000.
Re-validate after the change.

Add a `migrate` script that runs `alembic upgrade head` before `run`.

DATABASE_URL should point at a local Postgres on localhost:5432
for validation. Save it as a regular env var, not a secret.

​

Validation Status

​

Editing and Re-validating

1. Click Save Changes to persist your edits
2. Click Re-validate to run the full validation sequence again

Re-validate the origin lifecycle setup.

​

Authentication Handling

​

What Morph handles automatically

• Disable flags — Many frameworks offer an environment variable or config setting that disables authentication in development or test mode (for example DISABLE_AUTH=true, AUTH_ENABLED=false, or framework-specific flags like EnableTesting). When finds one, it registers the variable, restarts the application, and verifies that protected endpoints are now accessible.
• Static tokens — If the application uses a fixed API key or Bearer token (e.g. an X-API-Key header), asks you for the token with a Provide Secret card, stores it encrypted, and adds a verification script that confirms the token works.

​

What requires your attention

• Session-based login (username/password) — Applications that require a POST /login call to obtain a session cookie or Bearer token. reports this as detected but unsupported for automated bypass.
• OAuth / SSO / MFA — External identity provider flows that involve browser redirects, third-party consent screens, or multi-factor challenges. These cannot be automated.

​

Manual steps for unsupported auth types

​

Add a test-mode environment variable

​

Seed a test user and add a login script

1. Add a bootstrap script (ordered before healthcheck) that seeds a test user:

# seed a test user — adjust for your ORM / CLI
cd $WORKSPACE_DIR
python manage.py shell -c "
from django.contrib.auth.models import User
User.objects.get_or_create(username='testuser', defaults={'email':'test@test.com'})
u = User.objects.get(username='testuser')
u.set_password('testpass')
u.save()
"

2. Add an authcheck script (ordered after healthcheck) that obtains a session token and verifies a protected route:

# login and verify a protected endpoint
TOKEN=$(curl -s -X POST http://localhost:8000/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"testuser","password":"testpass"}' \
  | jq -r '.token')

curl -sf -o /dev/null http://localhost:8000/api/protected \
  -H "Authorization: Bearer $TOKEN" \
  || { echo "Auth check failed"; exit 1; }

3. Store the credentials (testuser / testpass) as secrets in the environment variables section so they are encrypted at rest.

​

Use the connect strategy with a pre-authenticated instance

​

Origin and Target

​

Tips

• Check the Errors tab first. When a script fails, the stderr output usually points directly at the problem - a missing dependency, a wrong port, or a typo in the command.
• Keep scripts minimal. Each script runs in a fresh shell process. If two commands need to share shell context (e.g., activating a virtual environment before running a command), concatenate them with && in a single script.
• Use environment variables for configuration. Avoid hardcoding ports, database URLs, or API keys in scripts. Set them as environment variables so they are easy to change and can be encrypted if sensitive.
• Answer the agent’s questions rather than skipping them. A skipped question means the agent guesses, and a wrong guess usually surfaces later as a validation failure.
• Reuse a working setup. Once the lifecycle validates, it becomes available as Organizational Knowledge so the next project on the same repositories can import it and skip Project Setup.

​

Related Docs