fix: release follow-ups for domain preflight, secret rotation, re-setup, logs and deletes

[alongubkin]

Follow-ups from the v3.3.27 release validation. One commit per fix.

Custom-domain-only stacks fail the domain metadata preflight

Cause: DomainMetadataRequiredCheck counted every public HTTP container and only checked whether domainMetadata was set. Containers listed in stackSettings.domains.customDomains bring their own domain and certificate, and the control plane sends no metadata when every public resource has one, so such stacks were rejected.
Change: resources_requiring_domain_metadata takes the config and skips custom-domain resources, in both should_run and check.
Test: custom-domain-only public container passes (fails on main); a mixed stack without metadata still fails and names only the managed container.

Deployer secret rotation is not picked up by a redeploy

Cause: vault-native deployer secrets were named, never versioned, in workload config. Overwriting one in the secret store and redeploying changed nothing the executor diffs, so workloads kept the old value until an unrelated change restarted them.
Change: Vault::secret_presence returns Present { version } from metadata only: SSM parameter Version, Secret Manager version name, newest Key Vault version id, Kubernetes resourceVersion, and a per-secret write counter for the local vault, counted before the value is saved so a failed save can only cause an extra restart (a counter instead of the file mtime: mtimes can collide between quick writes and are not per key). DeployerSecretReport and DeployerSecretEnv carry version (serialized only when present), so the next update after an overwrite changes the worker/container config and rolls it; an update without a write changes nothing. On Kubernetes the pod spec only references the Secret, so a deployer-secret-checksum pod-template annotation carries the versions. Workloads with filled slots roll once on the first update after this ships.
Test: test_redeploy_after_deployer_secret_overwrite_restarts_workloads (alien-deployment test_platform): write V1, run to Running, overwrite V2, same-release update → env version changes and the worker goes through an update; second update without a write → identical env, no worker update. Kubernetes manifest test: same version renders the same template, a new version changes only the annotation. Local vault test: reads keep the version, overwrite changes it.
Regenerated packages/core with pnpm --filter @alienplatform/core generate.

alien deploy re-run waits two minutes for a lock nobody grants

Cause: for running / update-failed / refresh-failed deployments alien deploy asked for the runtime lock with the deployment token. The runtime lock never matches a running deployment or a blocked update, and the setup lock refuses deployment tokens, so it timed out.
Change: alien deploy reads the active update from the platform (with the deployment token) and decides:

• running with nothing pending → prints "Nothing to do" and exits;
• an update waiting for setup while running or provisioning-failed, or update-failed / refresh-failed → gets setup authority from a deployment group token passed with --token (now kept instead of dropped for tracked deployments, checked against the deployment's group) or a first-party group session minted from the user's login, retries the failed operation when needed, takes the setup lock with it, prepares the setup update and runs setup; the installed release is loaded so step reconciliation keeps it; the deployment token keeps configuring the runtime (same split as alien-deploy up --setup-update);
• an update waiting for setup in another status (e.g. update-pending, which the setup lock does not accept) → fails immediately and points to alien deployments get;
• neither available → fails immediately with DEPLOYMENT_SETUP_AUTHORITY_REQUIRED, naming alien login and --token.
  Test: decision table for every status/active-update combination in platform and standalone mode; token selection against a mock platform API (supplied group token wins and no login happens; login mints a session for the deployment's group with the user's bearer; no login and no token gives the error with both hints). Not run against staging.

Push-created Lambda log groups never expire

Cause: the push-model AWS Worker controller left /aws/lambda/<name> to the Lambda runtime, which creates it on first invoke with no retention.
Change: new CloudWatch Logs client (CreateLogGroup single attempt, PutRetentionPolicy); the controller creates the group with 30-day retention before CreateFunction, sets retention when it already exists, and keeps it on delete (matches the CloudFormation log group with Retain). The management role's permissions only change when setup runs again, so an install from before this change lacks the new grants: access denied on either call logs a warning and the worker is still created (Lambda then creates the group without retention). Other errors stay fatal. The update flow runs the same idempotent step, so the first update after setup grants the permissions sets the retention. worker/provision grants logs:CreateLogGroup and logs:PutRetentionPolicy on /aws/lambda/${stackPrefix}-* (and the resource-scoped name).
Test: controller harness: log group + retention happen before the function; an existing group still gets retention; access denied on create or on retention still creates the function; other errors (e.g. throttling) fail it. Client tests against a mock endpoint (request shape, ResourceAlreadyExistsException → conflict). To verify live: deploy a push-model AWS worker, then aws logs describe-log-groups --log-group-name-prefix /aws/lambda/<prefix>-<worker> shows retentionInDays: 30 before the first invocation.

Deleting a deployment silently keeps deployer secrets

Cause: delete removes only Alien-synced vault keys; deployer secrets (values the deployer wrote) stay by design, but nothing said so.
Change: DeployerSecretLocation gains deleteCommand per store; the delete step logs kept secrets; alien destroy and alien deployments delete list every deployer secret slot with its delete command (a slot last reported missing may have been written since). There is no inputs/secrets page in this repo to update.
Test: exact delete command per store, next to the write command test; destroy output lists present/invalid secrets with their commands and includes one last reported missing.

alien deployments redeploy --wait waits silently

Change: prints the operation's status, reasons and actionRequired whenever any of them changes; the timeout error names the last of them.
Test: progress lines for queued → queued with action → applying → succeeded (each change once); timeout error includes the action.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[High risk] Modifies secret storage and retrieval across multiple vault providers.

The PR appears safe to merge; no outstanding blocking finding or new actionable issue was established.

Summary

The PR addresses release-validation follow-ups for domain preflight, deployer-secret rotation, re-setup, Lambda log retention, deletion notices, and redeploy progress. The changes since the previous review add an installed-release fallback for refresh retries and metadata-only Azure Key Vault version selection with pagination.

_{Reviews (11) · Last reviewed commit: "fix: retry failed refreshes and order sa..."}

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

The last review covered the volume backup and restore work, which came in only through the merge of main (it landed there separately). It isn't part of this PR's diff: the 39 changed files are the release follow-ups (custom-domain preflight, deployer secret versions and delete notes, alien deploy re-run, worker log group retention, redeploy --wait reasons) plus the platform API spec refresh, whose only change against main's spec is deleteCommand and version on deployer secret reports. Please review the diff against main.

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review