Plan — Next-Generation Greentic Deployment

Current direction — one line per axis

1. Context — why this restructure

The prior plan was structured around lifting AWS-specific code into deployer packs and shipping an AWS-stable E2E first. After source review and 2026-05-14 user direction, that framing still had four problems:

1. It treated "Environment" as a string label, not a deploy target. Partial environment types exist today (greentic-config-types::EnvironmentConfig, greentic-types::store::Environment), but neither is the deployment object this plan needs. Several repos still carry an opaque environment string defaulting to "dev". Telemetry exporters, secrets backends, route tables, and credential providers attach to the bundle or provider, not to the environment that the revision runs in. The new spec must reconcile these existing types instead of pretending the name is unused.
2. It treated deploying a new version and shifting traffic as the same act. Greentic today runs exactly one bundle per (tenant, team); deploying v2 overwrites v1 in place. This is incompatible with Cloud Run's industry-standard pattern of Revision (immutable, content-addressed) and TrafficSplit (mutable, separate). Every modern platform that does production traffic separates these concerns; Greentic must too.
3. It conflated "what attaches to Env" with "what we deploy." Greentic has two artifacts with different lifecycles: environment-packs (secret manager, deployer, telemetry exporter, sessions backend, state backend) which link to an Environment, and application bundles (fast2flow, llm, RAG, customer.support) which we deploy onto that Environment. The prior framing obscured this axis.
4. It coupled credentials and provider type to closed enums and to a single-bundle world. Customers' admins refuse to hand over full admin credentials, and the supported provider list must grow without recompiling core types. Both need first-class treatment, not enum sprawl. Separately, the platform's revenue model requires per-customer usage tracking with revenue share — that data has to be anchored on the deployed bundle.

Four business goals still bound the plan:

1. Zain runs on K8s in production — that is the eventual target. AWS is the first cloud proving ground because the existing greentic-deployer/src/aws.rs + Terraform groundwork lets us validate Environment/Revision/TrafficSplit on real infrastructure sooner. K8s design, conformance tests, and manifest generation start in parallel. "Zain ready" = K8s provider shipped, not AWS provider shipped.
2. Monthly-hosted consulting needs repeatable deploys we can price.
3. Ubuntu / Canonical wants first-class Snap + Juju deployers we can demo without recompiling the host.
4. Bima reselling wants a Store that ships platform + bundle updates safely AND a per-customer revenue-share anchor (P6).

2. The six pillars

schema: greentic.environment.v1
environment_id: local                     # default — created on first `gtc setup`
name: Local dev
host_config:                              # set by operator/admin at create/update time
  region: null
  cluster_endpoint: null
  public_hostname: localhost
  tenant_org_id: null
  redis_url: null                         # null when not yet known; runtime fills it later
packs:                                    # env-packs bound to this env, one per capability slot
  - slot: deployer
    kind: greentic.deployer.local-process@1.0.0
    pack_ref: greentic.deployer.local-process
    answers_ref: env-packs/deployer.answers.json
  - slot: secrets
    kind: greentic.secrets.dev-store@1.0.0
    pack_ref: greentic.secrets.dev-store
  - slot: telemetry
    kind: greentic.telemetry.stdout@1.0.0
  - slot: sessions
    kind: greentic.sessions.in-memory@1.0.0
  - slot: state
    kind: greentic.state.in-memory@1.0.0
credentials_ref: env-packs/credentials.json   # see P5
bundles: []                               # application bundles deployed in this env
revisions: []                             # immutable revision records per deployment
traffic_splits: []                        # one TrafficSplit per deployment_id
revocation:
  feed_url: null                          # opt-in; defaults off for `local`
retention:
  archived_max_age_days: 14
  staged_max_count: 5
health:
  last_doctor_status: pending

schema: greentic.deployer-credentials.v1
deployer_kind: greentic.deployer.k8s@1.0.0
requirements:
  - capability: k8s.create-namespace
    check: { kubeconfig_action: namespaces/create }
  - capability: k8s.bind-rbac
    check: { kubeconfig_action: clusterrolebindings/create }
  - capability: aws.assume-role
    check: { sts_action: AssumeRole, resource: arn:aws:iam::*:role/greentic-* }
validation:
  command: greentic-deploy-auth check --kind greentic.deployer.k8s
  expected_exit: 0
bootstrap:
  kind: terraform
  module: bootstrap/k8s
  inputs_schema: bootstrap/inputs.schema.json
rules_export:
  formats: [terraform, helm-values, kubectl-yaml]
  output: rules/<env-id>/

schema: greentic.bundle-deployment.v1
deployment_id: 01JTKS_F2F                    # ULID — per (env_id, bundle_id, customer_id)
env_id: prod-eu
bundle_id: customer.support
customer_id: cust-acme                       # billing principal — required for non-local envs
route_binding:
  hosts: [support.acme.example.com]
  path_prefixes: [/]
  tenant_selector: { tenant: acme, team: support }
current_revisions: [01JTKR_v2, 01JTKR_v1]
revenue_share:
  - { party_id: agency-a, basis_points: 3000 }
  - { party_id: greentic,  basis_points: 7000 }
revenue_policy_ref: billing-policies/customer.support/cust-acme/v1.json.sig
usage:
  meter_endpoint: usage://prod-eu/cust-acme/customer.support
  last_seen_at: 2026-05-14T08:01:00Z
authorization_ref: audit/2026-05-14T08-00-00Z-deploy-create.json

3. Today's reality — only what bears on the restructure

4. Locked-in decisions

1. In-process RevisionDispatcher is the Greentic load balancer. Authoritative in local, single-VM, and the K8s/router gateway process. A provider that cannot put all ready revisions behind that dispatcher must use provider-native weighted routing and report drift against deployment-scoped TrafficSplit.
2. Environment is the deploy target. It owns env-packs (by slot) and app bundles. App bundles never embed env config. Multiple bundles and multiple customer deployments of the same bundle per Env are first-class. Per-pack rollout inside a bundle remains Phase E.
3. Wizards keep their homes; env-scoping is surgical. No greentic-wizard-engine extraction in this plan; no per-app-pack wizard.yaml composition.
4. Credentials are a first-class pillar with two modes (P5). Admin credentials are never intentionally persisted; bootstrap paths prefer cloud-native federation / workload identity.
5. Provider taxonomy is extensible by namespaced descriptor, not enum. The closed surface is the small fixed list of capability slots.
6. Env config is split into three sources: host / setup / runtime.
7. Deployed bundles are addressable at usage level with per-customer revenue share (P6). Telemetry stamps deployment_id and customer_id; metrics use curated labels or OpenTelemetry views.
8. local is implicit; dev migrates behind a preflight gate.
9. gtc op is the operator wizard surface; gtc start is the local one-shot. The dozens of default_value("aws") admin sub-commands go away.
10. Restructure dissolves the AWS-first chapter into a generic Revision/TrafficSplit model.
11. Cross-cutting workstreams remain provider-independent. C1 → Phase 0 (security fix). C2 covers pack signatures plus DSSE. C3/C4 stay Phase A.
12. Minimum trust is in this plan; advanced trust is deferred to plans/greentic-trust-and-airgap.md.
13. Deployment extension taxonomy is fixed before Phase D. V1 execution uses native deployer packs loaded by greentic-deployer; .gtxpack deployer extensions remain metadata wrappers with execution.kind = builtin.
14. Operator delegates to greentic-start via library link. No subprocess.
15. Lifecycle endpoints implement INTO the reserved route prefixes at greentic-operator/src/static_routes.rs:65-69.
16. Distributor-client set_bundle_state gains atomic write + transition-validation matrix. Lifecycle includes failed and archived.
17. Non-secret config gets its own runtime channel. The current "write all answers to secrets" behavior is a migration bridge, not a target design.
18. All mutating deployment writes are optimistic-concurrency controlled and idempotent.
19. Mutating deployment operations are audited and authorized. Non-local production paths require RBAC before Phase D.
20. Observability is per revision and per deployed bundle, with customer attribution, but metrics avoid unbounded cardinality.
21. Production EnvironmentStore is a production system. Local files are for local and development.
22. Env-pack changes are revisioned and rollbackable. Rebinding a slot creates an env-pack binding generation with previous-binding metadata.

5. Target object model (spec-level)

5.1 greentic.environment.v1

Decomposes into three persistence units that map to the three config sources:

• environment.json — top-level env identity, bound env-packs, bundles deployed, revisions, traffic splits, host_config. Operator-owned.
• env-packs/<slot>/answers.json — non-secret setup answers per env-pack. Wizard-owned.
• runtime.json — discovered runtime values. Deployer env-pack-owned.

// greentic-deploy-spec
pub struct Environment {
    pub schema_version: SemVer,
    pub environment_id: EnvId,
    pub name: String,
    pub host_config: EnvironmentHostConfig,   // moved from greentic-config-types
    pub packs: Vec<EnvPackBinding>,            // one entry per CapabilitySlot
    pub credentials_ref: Option<SecretRef>,    // P5; points into Environment.packs[secrets]
    pub bundles: Vec<BundleDeployment>,        // §5.4; multiple per env
    pub revisions: Vec<Revision>,              // §5.2; flat list, indexed by id
    pub traffic_splits: Vec<TrafficSplit>,     // §5.3; one per deployment_id
    pub revocation: RevocationConfig,
    pub retention: RetentionPolicy,
    pub health: HealthStatus,
}

pub struct EnvPackBinding {
    pub slot: CapabilitySlot,            // closed enum: Deployer | Secrets | Telemetry | Sessions | State | Revocation
    pub kind: PackDescriptor,            // namespaced descriptor — open, e.g. "greentic.deployer.k8s@1.0.0"
    pub pack_ref: PackId,
    pub answers_ref: Option<PathBuf>,
    pub generation: u64,                 // bumped on attach/update/remove/rollback
    pub previous_binding_ref: Option<PathBuf>,
}

pub struct PackDescriptor(pub String); // "<namespace>.<id>@<semver>" — never enum-matched

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

5.2 greentic.revision.v1

Revisions are per BundleDeployment. Each customer-scoped deployment has its own revision sequence and its own TrafficSplit.

schema: greentic.revision.v1
revision_id: 01JTKR9X7ZQK3FN5W3TX9CHEAM        # ULID — unique within Env
env_id: prod-eu
bundle_id: customer.support
deployment_id: 01JTKS_CS_ACME                   # references BundleDeployment
sequence: 42                                    # monotonic per deployment_id
created_at: 2026-05-14T08:00:00Z
bundle_digest: sha256:abc...                    # digest of the .gtbundle archive
pack_list:
  - pack_id: customer.support.flows
    version: 1.2.0
    digest: sha256:abc...
    source_uri: oci://ghcr.io/greentic-biz/customer/packs/support-flows:1.2.0
pack_list_lock_ref: revisions/01JTKR.../PackList.lock
config_digest: sha256:ghi...
signature_sidecar_ref: revisions/01JTKR.../revision.sig
lifecycle: ready
staged_at: 2026-05-14T08:00:00Z
warmed_at: 2026-05-14T08:01:14Z
drain_seconds: 60

State-transition matrix

5.3 greentic.traffic-split.v1

One TrafficSplit per deployment_id. Splitting traffic between revisions of customer A's customer.support is independent of customer B's deployment of the same bundle, and independent of llm-router.

schema: greentic.traffic-split.v1
env_id: prod-eu
deployment_id: 01JTKS_CS_ACME
bundle_id: customer.support
generation: 17
entries:
  - { revision_id: 01JTKR9X..., weight_bps: 100 }
  - { revision_id: 01JTKR8W..., weight_bps: 9900 }
updated_at: 2026-05-14T09:30:00Z
updated_by: operator://prod-eu/api
idempotency_key: 01JTKW5B4W4Q5Y1CQW93F7S5VH
authorization_ref: audit/2026-05-14T09-30-00Z-01JTKW5B.json
previous_split_ref: traffic-splits/01JTKS_CS_ACME/2026-05-14T09-25-00.json

Constraints

• Sum of weight_bps MUST equal 10,000.
• All revision_ids MUST resolve to a Revision with matching deployment_id + bundle_id and lifecycle == Ready.
• Update is atomic (write-temp + rename + generation check; ArcSwap for in-memory).
• Mutating requests MUST carry an idempotency key. Stale generation fails with conflict.
• Mutating requests MUST pass authorization and write an audit event before the state file is swapped.
• Previous split is kept under traffic-splits/<deployment_id>/<ts>.json for last-N rollbacks.

5.4 greentic.bundle-deployment.v1

The usage-level anchor (P6). One per (env_id, bundle_id, customer_id). Required for non-local envs. (See schema in §P6 pillar.)

Constraints

• sum(revenue_share[*].basis_points) == 10_000.
• customer_id is required for any env where host_config.tenant_org_id is set (i.e., not local). For local, defaults to local-dev.
• route_binding MUST resolve public traffic to exactly one deployment_id. Ambiguous bindings fail at deploy time.
• revenue_policy_ref points to a signed, versioned policy document; mutating revenue_share creates a new policy version.
• Status transitions: active → paused | archived; paused → active | archived; archived is terminal.

5.5 greentic.credentials.v1 (P5)

schema: greentic.credentials.v1
env_id: prod-eu
deployer_kind: greentic.deployer.k8s@1.0.0
mode: requirements                            # requirements | bootstrap
provided_credentials_ref: secret://prod-eu/credentials/k8s-sa-token
validation:
  last_run_at: 2026-05-14T07:30:00Z
  result: pass                                # pass | fail
  missing_capabilities: []
bootstrap:
  admin_credential_consumed_at: 2026-05-14T07:00:00Z
  rules_pack_ref: rules/prod-eu/k8s-min-permissions.gtpack
  generated_credentials_ref: secret://prod-eu/credentials/k8s-sa-token
expiry:
  expires_at: 2026-06-14T07:00:00Z
  rotate_at: 2026-06-07T07:00:00Z

5.6 greentic.pack-config.v1 (per-revision, per-pack)

schema: greentic.pack-config.v1
pack_id: customer.support.flows
revision_id: 01JTKR9X...
non_secret:
  default_locale: en-GB
  webhook_base_url: https://prod-eu.example.com
secret_refs:
  bot_token: secret://prod-eu/customer.support/telegram/bot_token
runtime_refs:
  alb_dns: runtime://prod-eu/discovered/alb_dns

Three address spaces in one schema: non_secret (inline), secret_refs (resolved through Environment.packs[secrets]), runtime_refs (resolved through Environment.runtime.discovered). Runtime resolves secret_refs and runtime_refs lazily; values never embedded in the bundle.

6. Phase plan

One security hotfix plus four product phases. Each phase is independently shippable. Cross-cutting workstreams C1-C5 run in parallel and gate Phase ends.

7. Cross-cutting concerns (apply to all phases)

8. Critical files to create or modify

New files

• New crate greentic-deploy-spec — owns Environment, EnvironmentRuntime, Revision, TrafficSplit, BundleDeployment, Credentials, PackDescriptor, CapabilitySlot (Phase A)
• greentic-deployer/src/environment/{mod.rs, model.rs, store.rs, lifecycle.rs, atomic_write.rs, file_lock.rs, migration.rs, traffic.rs, bundle_deployment.rs} (Phase A/B)
• greentic-deployer/src/environment/{remote_store.rs, backup.rs} or operator-owned equivalent production EnvironmentStore (Phase D)
• greentic-deployer/src/environment/audit.rs (Phase A)
• greentic-deployer/src/env_packs/{registry.rs, slot.rs} (Phase A, A9)
• greentic-deployer/src/env_packs/local_process/{mod.rs, credentials.rs} (Phase A/C)
• greentic-deployer/src/env_packs/k8s/{mod.rs, credentials.rs, bootstrap/} (Phase C stubs → Phase D real)
• greentic-deployer/src/credentials/{mod.rs, validate.rs, bootstrap.rs, rules_export.rs} (Phase C, P5)
• greentic-start/src/{runtime_config.rs, revision_dispatcher.rs, revision_pin.rs} (Phase B)
• greentic-deployer/src/tool_check.rs (Phase A, C3)
• greentic-bundle/src/build/{signing.rs, doctor_secrets.rs} (Phase 0/B, C1/C2)
• greentic-setup/src/gtbundle/exclude.rs (Phase 0, C1)
• New repo greentic-deploy-auth (Phase D)
• Deployer-env-pack conformance test suite (Phase D)
• Dockerfiles for greentic-deployer, greentic-operator, greentic-bundle (Phase A, C4)
• (Not in this plan) greentic-wizard-engine extraction — deferred. The four existing wizard runtimes stay; they gain an env_id parameter only.

Modified files (highlights)

• greentic-distributor-client/src/dist.rs:3315 — atomic write
• greentic-distributor-client/src/dist.rs:3956 — real DSSE verifier
• greentic-config-types/src/lib.rs — EnvironmentConfig split: EnvironmentHostConfig stays; setup/runtime slices move to greentic-deploy-spec
• greentic-types/src/store.rs — Environment becomes a read-only compose view
• greentic-runner-host/src/runtime.rs:37 — ActivePacks keyed by (tenant, deployment_id, bundle_id, revision_id)
• greentic-runner-host/src/host.rs:155 — add load_revision(...); keep load_pack(...) compatibility helper
• greentic-runner-host/src/engine/host.rs:28-54 — session key shape gains deployment-scoped revision pins; telemetry context gains customer_id, deployment_id
• greentic-operator/src/admin_api.rs — handlers for reserved /deployments/* endpoints, scoped by (env, deployment_id)
• greentic-operator/src/static_routes.rs:65-73 — wire handlers into reserved prefixes
• greentic-bundle/src/setup/{mod.rs:63-71, backend.rs} — replace secret_values with secret_refs
• greentic-start/src/bundle_ref.rs:341-361 — backhand not unsquashfs
• greentic/src/bin/gtc/deploy.rs:47-66 — replaced by gtc op; cloud strings deleted
• greentic-telemetry — context schema adds customer_id, deployment_id, bundle_id, revision_id, env-pack kind

Reuse, don't reinvent

• greentic-distributor-client::{stage_bundle, warm_bundle, rollback_bundle, set_bundle_state, evaluate_retention, apply_retention} — wire in, don't duplicate.
• greentic-pack/crates/packc/src/signing/{signer.rs,verify.rs,canon.rs} — Ed25519 primitives.
• greentic-secrets-lib providers (AWS-SM, Azure-KV, GCP-SM, Vault) — already implemented; unused at deploy time today. Plug in as secrets env-packs in Phase D.
• backhand SquashFS crate — already used in greentic-setup.
• arc_swap — already used for TenantRuntime swap; reuse for TrafficSplit.
• greentic-qa-lib::WizardDriver — kept in place; reused by all four existing wizards. No extraction in this plan.

9. Verification plan

For each phase, every check below passes on real hardware before that phase ships.

10. Open questions / risks

• AWS sandbox account. Phase D nightly E2E needs a Greentic-owned AWS account or LocalStack. Same blocker as the prior plan; not resolved.
• K8s test cluster. The K8s slice needs a cluster for CI — kind/minikube for per-PR; a real EKS (or Zain-provided) cluster for nightly. Decision needed: long-running Greentic EKS sandbox, or ephemeral kind in GitHub Actions?
• Ingress / Gateway choice on K8s. NGINX Ingress, Traefik, Istio, or Gateway API. Must support at least NGINX Ingress and Gateway API; Istio opt-in.
• External Secrets Operator presence. K8s slice assumes ESO is installed. If not, either deployer env-pack installs it (cluster-admin required), or fallback that mounts secrets via a sidecar.
• K8s router availability. The corrected K8s model adds a stable router Deployment. Must be HA from day one: ≥2 replicas, PDB, readiness on loaded split generation, graceful config reload.
• Deployment route resolution. deployment_id is now the rollout key. Router must deterministically resolve it from tenant/team/customer/host/path before revision selection. Ambiguous bindings must fail at deploy time, not at request time.
• Production EnvironmentStore choice. Operator DB, Kubernetes CRDs, or object storage plus a lock service before AWS/K8s production acceptance.
• Existing Environment type split mechanics. 100+ call sites referencing the current monolithic type today. Phase A must land the split with adapter functions and CI to keep callers compiling.
• Aggregator / invoicer for P6 usage metering. This plan delivers the data model and the telemetry stamping; the aggregator is out of scope. Needs a separate GREENTIC-BIZ/greentic-billing workstream.
• Customer_id assignment for local. Defaulting to local-dev is safe; gtc op bundles add prod-eu … MUST refuse to default.
• Telemetry cardinality. Customer and deployment labels are useful for traces/logs/usage events but dangerous on every metric. Phase B must define metric views and budgets before exporters ship.
• Admin-bootstrap rules-pack acceptance. Customers' admins must trust the IaC rules pack we generate. Risk: generated Terraform/YAML doesn't match house style. Mitigation: templating override hook.
• Secrets trait integration. Provider crates exist, but runner/deployer integration still needs feature flags, auth material, sync/async adapters, policy decisions.
• component-deployer-{hetzner,digitalocean,oracle} fate. Stubs only. Recommend deprecation in Phase D unless a customer asks.
• backhand compression parity. Must cover whatever mksquashfs defaults greentic-setup emits today (gzip / zstd).
• Chainguard licensing. Default to distroless free image. Upgrade to Chainguard when subscription lands.
• Toolchain-manifest field. Phase D's image-digest lookup needs runtime_image.greentic-start.digest in ghcr.io/greenticai/greentic-versions/gtc:<channel>. Add as part of Phase D.
• set_bundle_state is per-bundle, not per-pack. Per-pack lifecycle is Phase E-or-later; v1 ships bundle-as-revision.
• Lifecycle enum drift. Current distributor enum lacks failed and archived. Phase A must extend or wrap.
• WebSocket sessions across revisions. Cookie/header-pinned long-lived WebSocket connections must survive a traffic rollback. v1 keeps connections on whichever revision they hit first; revision drain waits the full drain_seconds. Mid-connection migration not supported.
• Pack-config drift across revisions. Two revisions of the same bundle may have different pack-config.v1 answers. Dispatcher pins sessions to revisions, so a session sees consistent config.
• Local env multi-bundle + multi-revision routing. Dispatcher runs in-process; multiple deployments × multiple revisions share the same port + greentic-start process. Memory scales with active revisions.
• Cloud-side LB sync drift. Phase D mirrors the in-process split to ALB/Cloud Run as a perf optimization. If they drift, the in-process dispatcher is authoritative; deployer env-pack logs a warning. Phase E adds drift detection.
• Env-pack discovery + publication. Greentic Store integration? Local-only registration via gtc op env-packs install <oci-ref>? Phase A ships built-in registrations; Phase D needs publication semantics.
• Migration of dev → local for live customers. No-dual-read is allowed only if the Phase A preflight proves zero production usage of env = "dev". Otherwise compatibility alias is mandatory.

11. Deferred (Trust + Wizard + Billing + Phase E)

These move out to separate workstreams so this plan stays scoped:

plans/greentic-trust-and-airgap.md (new, to be opened)

• KMS-backed signing keys (kms://aws/<arn>, kms://gcp/<resource>, kms://azure/<vault>/<keyname>).
• SLSA Provenance v1.2 predicate full content + slsa-verifier integration.
• Rekor public-transparency-log integration (cosign attest --rekor-url).
• Revocation feed polling on Environment.revocation.feed_url.
• Drift detection (terraform plan -detailed-exitcode from greentic-deployer doctor --drift).
• DID/VC: tenant/team/env DIDs, six VC types, status-list snapshots.
• .gtairgap package format for offline / on-prem installs.
• Reproducible builds (SLSA L3 hermetic + isolated).

plans/greentic-wizard-unification.md (new — carved out 2026-05-14)

• Extract a single greentic-wizard-engine crate from the four existing wizard runtimes.
• greentic.pack-wizard.v1 spec — per-app-pack wizard.yaml contribution.
• Composition: load all packs in target env's resolved pack-list; dedupe; resolve dependencies; run unified session.
• First-class Adaptive Card surface (CLI + AC renderers from one composed runtime).
• Shared-question mechanism for cross-pack dedupe.
• Deprecation + removal of the four legacy wizard runtimes.

GREENTIC-BIZ/greentic-billing (new workstream)

• Usage record aggregator — consumes telemetry stream with (customer_id, deployment_id, bundle_id, revision_id).
• Revenue-share apportionment against BundleDeployment.revenue_share.
• Invoicing + payout reconciliation.
• Rate limits / quotas / SLA enforcement keyed on customer_id + bundle_id.
• Storage layer (DB schema for usage records, monthly rollups, dispute trail).

Phase E (after Phase D ships AWS + K8s)

• Per-pack independent lifecycle inside a bundle (true pack-first granular updates).
• Cloud-side LB drift detection.
• Mid-connection WebSocket migration.
• Metric-driven progressive delivery (abort_metrics on Revision).
• Provider-native K8s weighted routing as first-class option if Zain chooses Gateway API or Istio.
• GitOps round-trip for Environment (declarative env apply -f env.yaml).
• Additional multi-operator store backends.
• Env-pack hot-swap without bundle re-warm.

12. Critical anchors for execution

When implementation begins, these are the load-bearing pointers to read first:

• greentic-runner/crates/greentic-runner-host/src/runtime.rs:37 — ActivePacks and ArcSwap are the atomic-swap primitive for the dispatcher. Phase B extends the key from tenant to (tenant, deployment_id, bundle_id, revision_id).
• greentic-runner/crates/greentic-runner-host/src/host.rs:155 — RunnerHost::load_pack(). Phase B adds load_revision(..., deployment_id, ...).
• greentic-config/crates/greentic-config-types/src/lib.rs:59 — EnvironmentConfig to split: host stays here; setup + runtime move to greentic-deploy-spec (A1).
• greentic-types/src/store.rs — store Environment becomes a read-only compose view.
• greentic-operator/src/static_routes.rs:65-73 — the reserved /deployments/* prefixes B4 must implement into.
• greentic-operator/src/admin_api.rs:20-26 — AdminState is single-bundle today; B4 extends it.
• greentic-operator/src/wizard.rs — existing wizard driver that A10/C6 reuse for env-pack QASpec rendering (no extraction).
• greentic-pack/crates/greentic-pack/src/builder.rs:151-162 — DistributionSection.environment_ref becomes the env-pack ↔ env binding hook (P2).
• greentic-distributor-client/src/dist.rs:470-477, :1902, :1960, :2030, :2124, :3315, :3956 — state machine, lifecycle methods, non-atomic write, no-op verifier.
• greentic-setup/src/gtbundle.rs:85-99, :136-170, :394-427 — the two archive paths C1 must both gate.
• greentic-bundle/src/bundle_fs/* — the bundle writer/reader paths C1 must also gate.
• greentic-bundle/src/setup/mod.rs:63-71 — PersistedSetupState.secret_values plaintext field Phase 0 removes from artifacts and Phase B replaces with secret_refs.
• greentic-setup/src/qa/persist.rs, greentic-operator/src/qa_persist.rs, greentic-start/src/qa_persist.rs — current all-config-through-secrets behavior that Phase C migrates.
• greentic-runner/crates/greentic-runner-host/src/engine/host.rs:28-54 — session key shape that B6's deployment-scoped session-pin Redis hash augments. B11 also extends telemetry context.
• greentic/src/bin/gtc/{router.rs,cli.rs} and deploy/start_stop.rs — top-level CLI dispatch and existing gtc start. A3 keeps op passthrough and deletes 10+ default_value("aws") args.
• greentic-qa/crates/qa-lib — crate name greentic-qa-lib; WizardDriver gains env_id parameter (A10).

Appendix A — Implementation audit (anchor verification)

Source review on 2026-05-15 checked the plan's load-bearing assertions against the current workspace. The table records what is true today, before this plan is implemented.

What the audit means for this plan

• The single-bundle operator state, unused environment hook, plaintext setup secret field, and no-op signature verifier are current and must be fixed by the planned phases.
• Two details need exact wording during implementation: the AWS default count is 11, and env is embedded inside tenant_key rather than stored as a separate SessionKey field.
• The deployer extraction should scope against the cloud-specific implementation surface, not the whole greentic-deployer crate.

— End of plan —
Rendered from plans/next-gen-deployment.md · 2026-05-15