Render hosted production environment from image lock

[SoundBlaster]

Summary

• Add a fail-closed renderer from the hosted managed image lock to the non-secret production environment.
• Link related issue/task (if any): Secure Hosted Runtime Deployment & Production Canary.

Motivation

• Production image refs were still transcribed manually after lock validation.
• Manual rendering can mix stale digests, expand the canary allowlist, or overlap runtime and secret roots.

Goals

• Derive all three runtime images and fixed read-only canary scope from the authoritative lock.
• Preserve secret provisioning, deployment execution, and production sign-off as separate explicit operations.

Changes

• Add atomic mode-0440 environment rendering with image-lock, path, address, and boundary validation.
• Document the renderer and correct the stale Platform image repository example.
• Add regression coverage for invalid locks, overlapping roots, output overwrite, mode, and runbook drift.

Validation

• Tests added/updated for changed behavior
• Local checks passed

Commands run:

.venv/bin/python -m unittest tests.test_hosted_managed_production_env -v
make python-quality
docker compose --env-file /tmp/hosted-production-render.env --file docker-compose.hosted-managed-production.example.yml config
.venv/bin/python scripts/validate_hosted_managed_production_compose.py
git diff --check

Results:

• Focused tests: 5 passed.
• Full Python quality suite: 360 passed, 7 skipped.
• Real published image lock rendered successfully; Compose and production contract validation passed.

Risks / Notes

• Backward compatibility impact: none; the tracked example remains available.
• Migration/config changes required: operators may adopt the renderer for new deployment env files.
• Known limitations: the renderer does not create secrets, deploy containers, or enqueue operations.

Checklist

• PR title clearly describes the change
• Scope is focused and minimal
• Documentation updated (or N/A)
• Workflow/artifact changes distinguish artifact presence from readiness/status
• Temporary or intermediate paths are scoped to the current run/task where relevant
• No secrets or sensitive data added

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f685b79798

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Load the rendered env file before deployment

When operators follow this new renderer path, the file is written to /etc/0al/hosted-managed-production.env, but the later Start and probe commands still invoke docker compose and preflight from the process environment, and I found no --env-file or source step for this output. Docker Compose documents non-default environment files as being selected with --env-file, so following the runbook as written leaves the required PLATFORM_MANAGED_OPERATION_* variables unset unless the operator manually infers an extra load step.

Useful? React with 👍 / 👎.