Skip to content

env: default to 'development' (not 'production') + API explicitly echoes resolved env on every response#63

Merged
mastermanas805 merged 2 commits into
masterfrom
feat/env-default-development-fresh
May 13, 2026
Merged

env: default to 'development' (not 'production') + API explicitly echoes resolved env on every response#63
mastermanas805 merged 2 commits into
masterfrom
feat/env-default-development-fresh

Conversation

@mastermanas805
Copy link
Copy Markdown
Member

Summary

  • Migration 026 flips the column DEFAULT on resources.env, deployments.env, and stacks.env from 'production' to 'development'. Existing rows are NOT touched — only the DEFAULT changes. Accidental no-env provisions now land in the lowest-stakes bucket instead of silently merging with real prod state.
  • API layer updated end-to-end: models.NormalizeEnv, CreateResource / CreateDeployment / CreateStack, the env-policy middleware default, and the resolveEnv doc all point at "development". New typed constants models.EnvDevelopment + models.EnvDefault so future call sites don't hardcode the string.
  • Every provisioning / deploy / stack-create response echoes the resolved env so the agent (Claude Code, curl, MCP) sees which bucket it landed in. The 6 provisioning handlers (db, cache, nosql, queue, storage, webhook) already echoed env; POST /stacks/new was the one gap and now emits "env" too. /deploy/new continues to use "environment" because "env" already means env_vars on that endpoint (deliberate naming collision documented in deploymentToMap).
  • CLAUDE.md gets a one-line convention entry (rule fix: emit upgrade + upgrade_jwt on anonymous fresh-success responses #11).

Backward compat

  • Callers that explicitly send env="production" are unchanged.
  • Migration 026 is a pure ALTER COLUMN ... SET DEFAULT — no UPDATE, no row rewrites. TestMigration026_DoesNotTouchExistingRows guards this.
  • Re-applying the migration is idempotent (verified by TestResourceEnv_MigrationIdempotent).

Test plan

  • make test-unit green (all packages)
  • TestAllProvisioningResponsesIncludeEnv — new regression across /db, /cache, /nosql, /webhook, /storage
  • TestMigration026_DoesNotTouchExistingRows — guards iron rule
  • TestNormalizeEnv_DefaultsToDevelopment, TestResourceEnv_CreateDefaultsToDevelopment, TestDeploymentEnv_CreateDefaultsToDevelopment
  • TestAgentActionContract + TestAgentActionContract_RegistryCoverage green
  • TestStackList updated assertion (default stack env is now development)
  • E2E + deploy intentionally skipped per task instructions

🤖 Generated with Claude Code

mastermanas805 and others added 2 commits May 13, 2026 09:34
…on every response

Migration 026 flips the column DEFAULT on resources.env, deployments.env,
and stacks.env from 'production' to 'development' so accidental no-env
provisions land in the lowest-stakes bucket instead of silently merging
with real prod state. Existing rows are NOT touched — only the DEFAULT.

API layer:
  - models.NormalizeEnv now returns "development" for empty input
  - new models.EnvDevelopment + models.EnvDefault constants
  - models.CreateResource/Deployment/Stack default Env to EnvDefault
  - middleware/env_policy default env name updated to match
  - provisioning, deploy, and stack handlers already echo env (or
    "environment" on /deploy/new where "env" means env_vars); POST
    /stacks/new now echoes "env" too
  - openapi.go default + descriptions updated

Tests:
  - regression test TestAllProvisioningResponsesIncludeEnv across
    /db, /cache, /nosql, /webhook, /storage — asserts response
    includes top-level "env":"development" + DB row matches
  - TestMigration026_DoesNotTouchExistingRows guards against an
    accidental UPDATE-existing-rows regression
  - existing TestNormalizeEnv_/TestDeploymentEnv_CreateDefaults
    tests rewritten to assert 'development'
  - TestStackList env assertion flipped to 'development'

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…velopment-fresh

# Conflicts:
#	internal/models/deployment.go
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant