Release v1.229.0-rc.2 · cloudposse/atmos

chore(deps): add 14-day cooldown for Renovate updates Erik Osterman (Cloud Posse) (@osterman) (#3135)

## what

Add a repo-wide minimumReleaseAge: "14 days" cooldown to renovate.json.

why

Renovate was opening dependency-update PRs (e.g. floci/floci and floci/floci-az Docker digest bumps) the moment a new release/digest was published, with no waiting period.
A cooldown lets a freshly published artifact prove itself before Atmos proposes pulling it in, reducing the chance of adopting a digest/version that's pulled or patched shortly after release.
14 days matches the cooldown.default-days: 14 already set for every ecosystem in .github/dependabot.yml, so cooldown policy is consistent regardless of which bot opens the PR.
Applying it repo-wide (not scoped to Docker only) covers Go modules, GitHub Actions, and npm updates the same way.

references

Summary by CodeRabbit

Chores
- Dependency updates now wait at least 14 days after release before being considered.

feat(website): add download/share to blog post cast embeds Erik Osterman (Cloud Posse) (@osterman) (#3126)

## what

Added a CastEmbed component (website/src/components/CastEmbed/) that wraps CastPlayer with the existing CastShareLink and CastProDownload controls, on by default.
Added a siteCastPath() helper to CastProArtifact/url.mjs (with a unit test) that resolves a cast's public src to its committed website/static/... path, replacing an inline convention previously duplicated only in the file-browser example pages.
Retrofitted all 38 existing blog posts under website/blog/ from bare <CastPlayer> to <CastEmbed>, so every previously published changelog post's cast embed also gets Download/Share.
Updated the changelog, atmos-asciicast, and pull-request skills to reference CastEmbed (with opt-out guidance via download={false}/share={false}) instead of bare CastPlayer for future blog posts.

why

Blog/changelog posts embedded casts with only play/pause and a scrubber — there was no way to download a rendered GIF/MP4/SVG/WEBM or share the cast, even though that capability (CastProDownload/CastShareLink) already existed and was wired into the examples-gallery pages.
Centralizing the player+download+share composition in one CastEmbed component avoids every blog post (and future skill guidance) re-deriving the owner/repo/gitRef/path wiring by hand.

references

Summary by CodeRabbit

New Features
- Added enhanced cast embeds with optional Download and Share controls.
- Controls are enabled by default for supported casts and can be individually hidden.
- Download options support configurable formats and expiration settings.
- Added cast previews to changelog timeline entries, linking recordings to their related posts.
Documentation
- Updated blog posts and authoring guidance to use enhanced cast embeds.
- Existing recordings retain their sources, titles, and playback settings while gaining the new controls.

ci: add sticky cross-workflow timing summary Erik Osterman (Cloud Posse) (@osterman) (#3125)

## what

Add a default-branch workflow_run coordinator for every workflow that can run on an open pull request.
Add a bundled TypeScript action that waits for the latest runs and jobs for the current PR head to finish, then creates or updates one hidden-marker sticky comment.
Report PR wall-clock time, aggregate runner time, per-workflow totals, and the ten longest jobs, including matrix expansions.

why

Make the complete CI critical path visible in one place instead of inspecting workflows individually.
Distinguish elapsed PR latency from additive runner consumption so sharding and cache changes can be evaluated with the right metric.

references

Follow-up to #3123

Summary by CodeRabbit

New Features
- Added automated CI timing summaries to pull requests.
- Posts or updates a sticky comment showing wall-clock duration, aggregate runner time, workflow and job counts, and individual workflow results.
- Includes workflows associated with the pull request, including checks triggered by events beyond standard pull-request workflows.
- Publishes results only after selected workflows and jobs finish.
Documentation
- Added documentation covering timing metrics, reporting behavior, and development workflow.

ci: shard race detector tests across hosted runners Erik Osterman (Cloud Posse) (@osterman) (#3123)

## what

Split the non-acceptance race suite across four hosted-runner jobs using a seeded, precomputed package matrix.
Generalize the matrix output helpers for typed include rows and add coverage for shard planning and deterministic shuffling.

why

Reduce the race check's critical-path runtime and oversized-runner usage while preserving full package coverage.
Vary package assignments between workflow runs so consistently slow package clusters do not remain pinned to one shard.

references

Summary by CodeRabbit

Performance
- Race tests now run across four parallel shards, reducing the CI timeout from 75 to 30 minutes.
- Test packages are distributed deterministically for more consistent execution times.
Reliability
- Added validation for missing or invalid test-shard configuration.
- Improved cleanup and timeout handling for cancelled integration tests.
Maintenance
- Improved test-matrix generation and validation.
- Added dedicated caching for race-test planning to improve repeated workflow runs.

feat(helm): add runtime value overrides and values output Erik Osterman (Cloud Posse) (@osterman) (#3094)

## what

Add Helm-compatible ephemeral -f/--values and --set* overrides to native Helm render, diff, and apply commands.
Add atmos helm values <component> -s <stack> to print final masked values as formatted YAML.
Document the commands and test parsing, precedence, rendering, and value inspection.

why

Let operators inspect, preview, and deploy identical runtime values without editing Atmos stack configuration.

references

Summary by CodeRabbit

New Features
- Added atmos helm values to display fully resolved chart values as masked YAML.
- Added repeatable Helm-compatible runtime overrides for rendering, diffing, inspecting values, and deploying charts.
- Supported overrides include values files and --set, --set-string, --set-file, --set-json, and --set-literal.
- Runtime overrides apply only to the current command and do not modify configuration.
Bug Fixes
- Improved Helm output formatting and chart path display in deployment status messages.
Documentation
- Added command examples, flag references, precedence details, and guidance on invocation-only overrides.

fix(ci): cap concurrent subprocess launches in acceptance test orchestration Erik Osterman (Cloud Posse) (@osterman) (#3116)

## what

Adds a small package-level semaphore (maxConcurrentSubprocesses = 4) in internal/ci/acceptance/command.go that caps how many real subprocesses (go build/go test -c/go test/precompiled *.test.exe) commandRunner.run/.output may have in flight at once, across every commandRunner instance.
Refactors testfixture_test.go's buildFixtureTestBinary to route its go test -c compile through commandRunner.output instead of a bare exec.Command, so it shares the same cap.

why

PR #3115 was added to the merge queue twice and bounced both times for reasons unrelated to its own diff. The first bounce (windows, shard 3/10) failed with a Go runtime fatal error: found pointer to free object (runtime: marked free object in span) during a concurrent os/exec process launch triggered from this package's own acceptance-test suite.
This package's test suite runs ~90 t.Parallel() subtests, many of which shell out to the real go toolchain. On a wide CI runner that lets dozens of real go build/go test subprocesses launch fully concurrently — each independently allocating and syscalling heavily — which is the kind of condition known to trigger a long-standing, still-recurring class of Go runtime GC/allocator race on Windows (see golang/go#44900, #45364, #47415, #54247). It's a documented class of upstream Go runtime flakiness under heavy concurrent allocation+syscall pressure, not a bug in the specific command being run.
Capping actual subprocess launches (while leaving the surrounding Go test logic free to run in parallel) removes the trigger condition without giving up test parallelism where it doesn't involve a real subprocess. Verified locally: go test ./internal/ci/acceptance/... -v still passes in full (~15s, no deadlocks) with the cap in place.

references

Summary by CodeRabbit

Bug Fixes
- Improved reliability of Windows acceptance tests by limiting concurrent subprocess launches.
- Applied the same concurrency control when building test fixtures.
- Improved error handling when subprocess capacity cannot be acquired.
Tests
- Added coverage for subprocess slot-acquisition failures across supported platforms.
Documentation
- Documented the Windows acceptance-test concurrency fix, validation results, and follow-up status.

fix(docs): use localhost redis URL in sops-secrets demo cast Erik Osterman (Cloud Posse) (@osterman) (#3120)

## what

The sops-secrets example's secret-lifecycle screengrab demoed atmos secret set REDIS_URL=redis://prod:6379 --stack=dev --component=api.
Changed the demoed value to redis://localhost:6379, matching the fixture component's own default (redis_url: !secret REDIS_URL | default "redis://localhost:6379").
Regenerated the committed cast (website/static/casts/examples/sops-secrets/secret-lifecycle.cast) via atmos --chdir=demo/casts casts generate examples sops-secrets secret-lifecycle, which re-runs its own validation step.

why

The dev stack demo was setting an obviously production-looking Redis URL (redis://prod:6379), which is confusing/embarrassing in published docs and contradicts the stack it's demoing against.
Using redis://localhost:6379 keeps the demo internally consistent with the fixture's real default for the dev stack.

references

Summary by CodeRabbit

Documentation
- Updated the SOPS secrets lifecycle example to use a local Redis connection.
- Refreshed the terminal recording with updated OpenTofu version output and timing information.
- Removed workspace-switch messages from the recorded deployment and output commands.
- Cleaned up trailing whitespace in displayed secret listings.

🚀 Enhancements

fix: describe/error/prompt DX bugs found while field-testing aws/cloudformation Erik Osterman (Cloud Posse) (@osterman) (#3106)

## What

Four general, cross-cutting bug fixes:

errors/formatter.go — short (2-line) error callouts rendered with a jarring two-tone background instead of a smooth gradient (pure gradient-endpoint colors with no interpolation).
cmd/describe_component.go — describe component couldn't prompt for a missing --stack; it used Cobra's native MarkPersistentFlagRequired, which hard-fails before the interactive-prompt code ever runs.
cmd/terraform/shared/prompt.go / pkg/flags/standard.go — the missing-stack prompt's component-filter was hardcoded to components["terraform"] (so any non-terraform component always matched zero stacks and fell back to an unfiltered, org-wide list), and the flag prompt ran before the positional-arg prompt, so the filter never saw the component name even when one had already been typed.
pkg/provenance/data_transform.go — filterEmptySections treated "no per-key provenance recorded" as "this section is empty," silently dropping any top-level section populated as a plain value rather than merged key-by-key (reproduces for any component type, e.g. a terraform component's settings/hooks).

Why

Found via a real-AWS field-test pass on the (currently unmerged) aws/cloudformation feature stack. All four bugs are general Atmos behavior unrelated to CloudFormation itself, so they ship here independently rather than waiting on that stack to merge.

References

docs/fixes/2026-09-09-error-callout-gradient-two-tone.md
docs/fixes/2026-09-09-missing-stack-prompt-not-firing.md
docs/fixes/2026-09-09-cfn-describe-component-missing-fields.md

Summary by CodeRabbit

New Features
- Interactive prompts now help resolve missing stack values when running describe component.
- Stack suggestions now include components from all supported component types, not only Terraform.
- Interactive prompts resolve required positional arguments before dependent flag suggestions.
Bug Fixes
- Provenance output now preserves non-empty CloudFormation component fields.
- Short error callouts now use smoother gradients, while longer callouts retain full gradient coloring.
- Interactive mode is enabled by default in eligible terminal sessions.

fix(helm): carry `create_namespace` through the stack processor Andriy Knysh (@aknysh) (#3134)

## what

Fix the native-Helm create_namespace setting (added in #3034) being silently dropped by the stack processor, so create_namespace: false had no effect.
The stack processor carries only a fixed whitelist of native-Helm fields into the resolved component config, and create_namespace was not on it — so the key was stripped before it reached the Helm executor. atmos describe stacks --sections create_namespace returned {}, and the default of true always won.
Add create_namespace to the per-component whitelist (helmComponentSectionKeys) and the stack-level helm: defaults whitelist (helmLifecycleSectionKeys), plus a HelmCreateNamespaceSectionName constant, regression + precedence tests, and a fix doc.

why

create_namespace: false validated fine (the JSON schema already accepted it) but was invisible in the resolved config and never reached helm apply. The JSON schema and the stack processor's runtime whitelist are two independent lists; #3034 updated the schema but not the whitelist — hence "validates fine, shows up nowhere."
Without the fix, an identity scoped to a single, pre-existing namespace still forced a namespace create (Helm issues the create request before the already-exists check applies), which fails with a 403 — exactly the case create_namespace: false was meant to solve. Reported by a customer on Atmos 1.228.0.
Backward compatible: the default remains true; only components that explicitly set create_namespace: false change behavior.

Root cause

PR #3034 wired the reader side of the toggle — resolveCreateNamespace / boolFieldDefault in pkg/component/helm/values.go, the CreateNamespace field on chartSpec, the install-action plumbing in pkg/component/helm/client.go, and the JSON schemas — but never wired it through the stack processor. extractHelmComponentSection (internal/exec/stack_processor_process_stacks_helpers_extraction.go) copies only keys in helmComponentSectionKeys; any unrecognized key (including create_namespace) was dropped before the resolved section reached buildChartSpec, so the reader fell back to its true default.

Fix

pkg/config/const.go: add HelmCreateNamespaceSectionName = "create_namespace".
internal/exec/stack_processor_process_stacks_helpers_extraction.go:
- add cfg.HelmCreateNamespaceSectionName to helmComponentSectionKeys (core fix — per-component, flows through base-component inheritance and into the final component config);
- add it to helmLifecycleSectionKeys so it can also be set once as a stack-level helm: default and apply to every Helm component.
internal/exec/stack_processor_process_stacks_helpers_test.go: TestExtractHelmComponentSectionCreateNamespace.
internal/exec/stack_processor_merge_test.go: TestMergeComponentConfigurations_CreateNamespacePrecedence.
docs/fixes/2026-09-11-helm-create-namespace-stack-processor-drop.md: fix record.

Precedence (this PR)

Where	Precedence	Use case
component field (`helmComponentSectionKeys`)	wins	per-release opt-out
stack-level `helm:` default (`helmLifecycleSectionKeys`)	weaker — a component can override it	convenience default across components

Testing

The concern was to prove create_namespace reaches the Helm SDK install action end-to-end (native Helm uses action.Install, not the helm binary), not just that it survives the whitelist. Every link was traced and verified.

#	Stage	Carries `create_namespace`?	How verified
1	Stack manifest YAML	✅	JSON schema accepts it (#3034)
2	Stack processor `extractHelmComponentSection`	✅ (fix)	new unit test; added to `helmComponentSectionKeys`
3	Merge → flatten into component map (`stack_processor_merge.go`)	✅	`comp[key]=value` over `finalComponentHelm`; `TestMergeComponentConfigurations_CreateNamespacePrecedence`
4	Resolved stacks map (read by `describe stacks`)	✅	ran the built binary — see below
5	`processComponentConfig` → `info.ComponentSection`	✅	`utils.go:310` copies the whole component map wholesale (no helm sub-filter)
6	Template + YAML-function round-trips	✅	round-trip type is `AtmosSectionMapType = map[string]any` (generic map — no typed-struct drop)
7	`buildChartSpec` / `resolveCreateNamespace` reads it	✅	`TestBuildChartSpec_CreateNamespacePropagates` (default-true and explicit-false)
8	`newInstallClient`: `client.CreateNamespace = spec.CreateNamespace`	✅	`TestNewInstallClient_WiresCreateNamespace`
9	Helm SDK install action honors it	✅	`TestApplyRelease_CreateNamespaceControlsNamespaceCreate` (recording kube client asserts namespace create only fires when `true`)

Two traps specifically ruled out:

Typed-struct drop: schema.Helm (the struct) is only the global components.helm: type defaults (base_path, plugins, repositories…). The per-component section travels as map[string]any and is never unmarshaled through a typed struct that would silence unknown keys. The template/YAML re-conversions use map[string]any.
Second whitelist: describe stacks uses its own extractDescribeComponentSections, but that only pulls named sub-sections; it passes top-level scalar keys through (proof: namespace, also not in that struct, already appears in output).

Empirical run (built from this branch, against a copy of examples/helm with create_namespace: false added to the demo component):

$ atmos describe stacks -s dev --components demo --component-types helm --sections create_namespace
dev:
  components:
    helm:
      demo:
        create_namespace: false     # ← was {} before the fix

That output comes from the same resolved component map the executor feeds to buildChartSpec; steps 7–9 carry it the rest of the way to client.CreateNamespace = false.

Automated tests + coverage (all pass):

go test ./internal/exec/ -run TestExtractHelmComponentSectionCreateNamespace — fails on the pre-fix whitelist (reproduces the drop), passes after the fix.
go test ./internal/exec/ -run TestMergeComponentConfigurations_CreateNamespacePrecedence — component value wins over stack default; stack default applies when the component is unset.
Coverage of the changed functions: extractHelmComponentSection, extractHelmLifecycleSection, extractHelmOverrideSection 100%; mergeComponentConfigurations 97.6%.
go test ./internal/exec/ -run 'Helm', plus the full ./internal/exec/ suite; go test ./pkg/component/helm/... ./pkg/config/....
go build ./...; gofumpt clean.

references

Fixes the field added in #3034 (Add create_namespace setting to native Helm components).
Docs: Helm components
Fix record: docs/fixes/2026-09-11-helm-create-namespace-stack-processor-drop.md

Summary by CodeRabbit

Bug Fixes
- Helm’s create_namespace setting is now preserved during stack processing.
- Component-level values take precedence over stack-level defaults.
- Explicit true and false values flow through correctly; omitted values retain existing defaults.
- The setting remains unsupported in Helm overrides.
Tests
- Added regression coverage for extraction, lifecycle defaults, precedence, and unset values.
Documentation
- Added documentation covering the issue, supported behavior, validation steps, and known limitations.

fix(ui): output-only plans no longer reported as NO CHANGES in --ui Erik Osterman (Cloud Posse) (@osterman) (#3121)

## what

The streaming terraform UI (--ui) now treats output-only plan diffs as real changes instead of reporting NO CHANGES.
Added DependencyTree.HasOutputChanges()/OutputChangeCount() (from plan.OutputChanges) and ResourceTracker.HasOutputChanges() (from the streamed outputs message's per-output action).
Wired both into the three "no changes" gates in pkg/terraform/ui/executor.go (showPlanTree, showTwoPhasePlanTree, executeWithPlanFile) and into the streaming completion summary in model_render.go.
RenderChangeSummaryBadges gained an OUTPUTS CHANGED badge and no longer renders NO CHANGES when only outputs changed.

why

atmos terraform apply <component> -s <stack> --ui silently skipped the confirmation prompt and the apply entirely when the only diff in the plan was an output value, so the new output never reached state (exit code 0, no error).
atmos terraform plan --ui hid the output diff completely, and atmos terraform deploy --ui (auto-approve) applied the change correctly but printed a misleading ... completed (no changes) summary.
All four call sites derived "has changes" purely from resource add/change/remove counts and never consulted tfjson.Plan.OutputChanges or the streamed output action field, even though that data was already being parsed and stored.
Added regression tests for each of the four affected code paths (tree_test.go, executor_test.go, model_test.go, resource_test.go), written first to confirm the gap before implementing the fix, per the repo's bug-fixing workflow.

references

Closes #3114

Summary by CodeRabbit

Bug Fixes
- Terraform plans that change only output values are now correctly recognized as changes.
- Output-only changes display an “OUTPUTS CHANGED” badge instead of “NO CHANGES.”
- Plans with both resource and output changes now show both types in the change summary.
- Output-only changes proceed through confirmation and apply workflows correctly.
- Completed applies with output-only changes are no longer reported as having no changes.
- Packer variable files now resolve correctly when executing Packer commands.

fix(pro): report full logical component name in Atmos Pro uploads Igor Rodionov (@goruha) (#3111)

## What

Fixes two places where Atmos Pro uploads report a truncated component name for nested (path-style, slash-containing) logical component names — e.g. foo/bar/baz is reported as baz:

Instance-status upload (--upload-status): uploadStatus in internal/exec/pro.go now sends info.ComponentFromArg (the full logical name) instead of info.Component (the truncated working-directory leaf).
Multi-component execution record: terraformNodeHooks.recordExecResult in cmd/terraform/utils.go now passes info.ComponentFromArg into buildTerraformExecData for each per-node entry, instead of the truncated leaf.

The internal name-splitting logic that produces the truncated leaf (internal/exec/utils.go, ProcessStacks) is untouched — it's still required for Terraform working-directory resolution (components/terraform/<prefix>/<leaf>/).

Why

The original issue's proposed fix targeted only recordExecResult, but code review established that call site only fires for multi-component runs (--affected/--all/--components/--query). The issue's own repro — a single-component atmos terraform plan "foo/bar/baz" -s <stack> --upload-status — is actually caused by uploadStatus, a separate call site the original proposal didn't touch. Both are fixed here so the exact repro and the broader bug class are both resolved.

Because other identity channels (stack locks, affected-component uploads, single-component execution records) already report the full logical name, this mismatch caused Atmos Pro's approvals-page "previous plan" lookup to fail with "No previous plan found for this component" for any nested component, even though the plan ran and uploaded successfully.

A related but distinct issue — path-style CLI arguments (atmos terraform plan ./components/terraform/vpc) reporting the raw filesystem path instead of the resolved logical name in single-component execution records — was identified during review and deliberately scoped out to keep this fix minimal. Tracked in #3110.

References

Closes #3102
Follow-up: #3110
Full spec-kit trail: specs/003-fix-upload-component-name/ (spec, plan, research, data-model, contracts, quickstart, tasks)

Test plan

New regression test TestUploadStatusReportsFullComponentName (nested + flat cases) in internal/exec/pro_test.go
New regression test TestRecordExecResult_ReportsFullComponentNameForNestedComponent in cmd/terraform/utils_exec_metadata_test.go
New regression-guard test TestTerraformExecMetadataParserFunc_ReportsFullComponentNameForNestedComponent confirming the already-correct single-component parser path is unaffected
Both new tests confirmed failing before the fix, passing after
All pre-existing tests in internal/exec and cmd/terraform pass unmodified
Full pact consumer-contract suite (go test -tags pact ./pkg/pro/...) passes unmodified — no fixtures assumed the truncated value
internal/exec/utils.go (working-directory split logic) has zero diff
go build ./..., atmos lint --changed, atmos test, and full tests/ package all pass

Summary by CodeRabbit

Bug Fixes
- Atmos Pro uploads now preserve full logical component names, including nested names such as foo/bar/baz, instead of reporting only the final segment.
- Execution metadata and instance-status uploads now use consistent component identity information.
- Flat component names continue to be reported unchanged.
Documentation
- Added specifications and implementation guidance covering component identity, upload behavior, validation, and regression coverage.

fix(website): cast download polls render status as JSON, waits up to 30m Erik Osterman (Cloud Posse) (@osterman) (#3115)

## what

Rewrote the Atmos Pro cast-download polling flow (CastProArtifact/useCastArtifact.ts) to poll the render-status endpoint with Accept: application/json instead of the raw artifact URL, and to treat only a genuine 200 response as "ready" — never response.ok on any 2xx.
Extracted the polling state machine into a new framework-agnostic module, CastProArtifact/polling.mjs, with a companion polling.test.mjs covering the queued→rendering→ready path, an immediate-ready response, terminal errors, the slowdown threshold, the wait ceiling, a hung fetch, and cancellation.
Raised the total wait budget from a hard 60s to 30 minutes, polling every 3s and slowing to every 10s past 13 minutes elapsed, with a "still rendering, try again later" message instead of a false failure at the ceiling.
Updated CastProDownload to show "Queued…"/"Rendering… m:ss" (with a "taking longer than usual" hint) and an optional progress bar, and updated CastProArtifact/README.md to document the render service's actual JSON/200/202/500 contract and the new polling cadence.

why

Downloading a cast that hadn't finished rendering yet redirected the reader to a blank page reading "Cast artifact is not ready yet." instead of keeping them on the page.
The old polling logic asked for the raw artifact and accepted any 2xx as "ready," so a still-rendering response could be misread as done; separately, its 60s wait cap was far below real render times (casts can take several minutes, with queueing up to ~30 minutes worst case), so even correctly-detected renders gave up too early.

references

Summary by CodeRabbit

New Features
- Added clearer rendering status updates with queued and processing phases, elapsed time, progress stages, and visual progress indicators.
- Added immediate readiness detection and automatic navigation to artifact downloads.
- Rendering checks poll every 3 seconds, slow after 13 minutes, and stop after 30 minutes.
- Added support for legacy artifact responses and clearer network, rendering, and terminal error messages.
- Improved progress-bar accessibility with status announcements and percentage information.
Documentation
- Updated service documentation covering polling responses, artifact metadata, errors, and download behavior.

fix: terraform --all bootstrap, list-command lazy eval, init/UI polish Erik Osterman (Cloud Posse) (@osterman) (#3095)

## what

atmos terraform apply --all no longer aborts before the scheduler runs anything, on a fresh environment where a dependent component's !terraform.state/!terraform.output reference points at a component that hasn't been applied yet (e.g. audit-trail reading kms's key_arn before kms has run). This does not skip or fake the value: the preflight's unresolved placeholder is discarded and never reaches Terraform. Each component still independently re-describes and re-resolves its own vars from scratch immediately before its own plan/apply — by which point, in a correctly-ordered dependency graph, kms has already applied and !terraform.state reads the real value.
atmos list stacks/list components/list instances now skip evaluating Go templates (atmos.Component, atmos.GomplateDatasource) and YAML functions (!terraform.state, !terraform.output, !store) for stack/component sections that no displayed column actually reads. Previously every value was resolved eagerly regardless of the requested columns, which produced a spurious "N value(s) could not be determined and are shown as (computed)" warning for values that were never shown, and could take 30s–6+ minutes on stacks that use !terraform.output/atmos.Component in vars — even though list stacks only ever displays stack names by default. Closes #3068.
The atmos init "Select a template" picker now sizes its columns to the real terminal width instead of hard-coded widths, so long descriptions truncate cleanly at a word boundary instead of splitting mid-word onto a stray line.
Under --ui, the after-init providers lock step (triggered by an active registry/plugin cache) now streams through the same init spinner as terraform init/plan/apply, instead of dumping raw provider-fetch/checksum output into the middle of the fancy UI.
Wrapped continuation lines of bullet and ordered markdown lists (rendered in the terminal, e.g. a scaffold README shown by atmos init) are now indented to align under the item's own text instead of falling flush with the bullet/number.

why

The --all preflight only exists to build the dependency graph and validate config before the scheduler starts — it's built purely from static dependencies/settings.depends_on, never from resolved vars. But it previously resolved !terraform.state/!terraform.output for every component strictly, so an unprovisioned dependency (normal and expected on a fresh AWS landing-zone environment: kms → audit-trail/baseline/monitoring) aborted the entire run before a single component was applied. Since the preflight's resolved value for this one recoverable error class is never used for anything but graph construction — and every node re-resolves its own vars fresh, for real, immediately before its own apply — degrading (not failing on) this specific error class during preflight (reusing the existing --error-mode=warn machinery) is safe and unblocks the documented apply --all bootstrap flow. Other error classes (e.g. a missing !secret) are unaffected and still fail the preflight as before.
The describe-stacks pipeline behind list stacks/list components/list instances resolved every section of every component before column projection ever happened, regardless of whether any column would display the result. A new opt-in evaluation-scope filter (evalSections, deliberately separate from the existing output-only sections filter used by describe stacks --sections=X, so that command's behavior is untouched) is derived from the resolved column set and threaded through both the Go-template render pass and YAML-function resolution, falling back to full eager evaluation whenever the column templates can't be statically proven safe to skip.
The template picker's fixed column widths didn't account for actual terminal width or content length, producing broken wrapping on normal-size terminals.
The providers lock hook ran through a raw shell call that bypassed the streaming TUI entirely, so its output leaked raw into an otherwise fully---ui-rendered run.
Glamour renders an entire markdown list into one shared buffer, word-wraps it as a single blob, and applies one uniform block-level margin to every resulting line, with no concept of a hanging indent for wrapped continuation lines.

references

Closes #3068

🤖 Automatic Updates

chore(deps): update dependency posthog-js to v1.418.1 @[renovate[bot]](https://github.com/apps/renovate) (#2954)

This PR contains the following updates:

Package	Change	Age	Confidence
posthog-js (source)	`1.409.5` → `1.418.1`

Release Notes

PostHog/posthog-js (posthog-js)

Uh oh!

Uh oh!

v1.229.0-rc.2

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

Summary by CodeRabbit

🚀 Enhancements

Why

References

Summary by CodeRabbit

why

Root cause

Fix

Precedence (this PR)

Testing

references

Summary by CodeRabbit

Summary by CodeRabbit

why

references

Summary by CodeRabbit

Why

References

Test plan

Summary by CodeRabbit

why

references

Summary by CodeRabbit

why

references

🤖 Automatic Updates

Release Notes

1.418.1

Patch Changes

1.418.0

Minor Changes

Patch Changes

1.417.4

Patch Changes

1.417.3

Patch Changes

1.417.2

Patch Changes

1.417.1

Patch Changes

1.417.0

Minor Changes

Patch Changes

1.416.1

Patch Changes

1.416.0

Minor Changes

Patch Changes

1.415.7

Patch Changes

1.415.6

Patch Changes

1.415.5

Patch Changes

1.415.4

Patch Changes

1.415.3