How Environment is going to work

1. The core idea, in one sentence

Today a .gtbundle carries its deployment knowledge inside itself — which secrets backend, which telemetry exporter, which deployer, all baked into the bundle's setup-state. Tomorrow, the Environment is the deploy target — a separate, addressable thing that knows where it lives, what capabilities are attached, and what's deployed into it. Bundles become environment-agnostic; the Environment owns the wiring.

2. Kitchen vs recipe

3. The object model at a glance

4. Three sources of config, three owners

This split is load-bearing — today's mess is that all three ride the same channel.

5. Capability slots: closed surface, open content

pub enum CapabilitySlot {
    Deployer,
    Secrets,
    Telemetry,
    Sessions,
    State,
    Revocation,
}

pub struct PackDescriptor(pub String);
// "greentic.deployer.k8s@1.0.0"
// "greentic.secrets.aws-sm@1.0.0"
// "greentic.telemetry.otlp@1.0.0"

v1 binds exactly one env-pack per slot. Fan-out cases (e.g. two telemetry exporters) are represented by a composite env-pack until a future schema version adds list semantics.

6. On-disk layout

Operator-owned in production; CLI-owned for local. The local env is auto-created on first gtc setup with five default env-packs bound: local-process deployer, dev-store secrets, stdout telemetry, in-memory sessions, in-memory state.

7. Code architecture — crate boundaries

The new crate — greentic-deploy-spec

greentic-deploy-spec/
├── Environment, EnvPackBinding, CapabilitySlot, PackDescriptor
├── Revision (lifecycle state-machine)
├── TrafficSplit
├── BundleDeployment
├── Credentials               // P5
└── RuntimeConfig

Inside greentic-deployer (extended)

src/environment/
├── model.rs              // re-exports from deploy-spec
├── store.rs              // EnvironmentStore trait + LocalFsStore impl
├── atomic_write.rs       // write-temp + rename
├── file_lock.rs          // per-env flock
├── lifecycle.rs          // state-transition matrix enforcement
├── migration.rs          // legacy dev → new layout
├── audit.rs              // append-only audit events
├── traffic.rs            // TrafficSplit persistence
├── bundle_deployment.rs
└── env_packs/
    ├── registry.rs       // kind-string → handler resolver
    └── slot.rs

src/cli.rs                // gtc op env / env-packs / bundles / traffic / ...
src/tool_check.rs         // preflight: tools, credentials, region access

Inside greentic-start (extended)

src/revision_dispatcher.rs   // NEW: in-process router (see §8)
src/runtime_config.rs        // loads runtime-config.v1, multi-bundle
src/http_routes.rs           // keyed by (deployment_id, revision_id, public_path)
src/http_ingress/mod.rs      // consults dispatcher
src/runner_host/runtime.rs   // ActivePacks: (tenant, deployment, bundle, revision) → TenantRuntime

8. Runtime request flow

Every HTTP request goes through this resolution chain. The deployment_id is resolved from authenticated context — public traffic cannot select an arbitrary deployment.

9. Phase roadmap

deferred Phase E: per-pack rollout inside a bundle, wizard engine extraction, metric-driven auto-abort, .gtairgap.

10. Key takeaways