-
-
Notifications
You must be signed in to change notification settings - Fork 139
feat: Add experimental feature transparency and controls #1940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add transparency about feature maturity by introducing an <Experimental /> badge component and <FirstReleased /> version component for documentation. Create an "Experimental Features" policy page explaining what experimental means, graduation criteria, and how to provide feedback. Mark 11 experimental features across the documentation. 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <[email protected]>
Dependency Review✅ No vulnerabilities or license issues found.Scanned Files
|
Update the experimental features policy to accurately reflect that: - Features may not be fully functional yet - Documented functionality may not yet be implemented - Full functionality is guaranteed when experimental annotation is removed 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <[email protected]>
Experimental features are on the path to stability, not abandonment. Removal would only occur in extreme circumstances. 🤖 Generated with Claude Code Co-Authored-By: Claude Haiku 4.5 <[email protected]>
📝 WalkthroughWalkthroughAdds a centralized Experimental Features system: CLI-level experimental flags and annotations, help-text badges and warnings, config/schema for experimental mode, UI/website indicators (badges, roadmap, unreleased docs), new components/styles, and supporting tests and docs. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1940 +/- ##
==========================================
+ Coverage 74.51% 74.73% +0.21%
==========================================
Files 777 777
Lines 71044 71171 +127
==========================================
+ Hits 52939 53187 +248
+ Misses 14636 14520 -116
+ Partials 3469 3464 -5
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
📝 WalkthroughWalkthroughTwo new reusable React components are introduced to mark features in documentation: Experimental and FirstReleased, each with accompanying CSS styling and dark theme support. The Experimental component is applied to 11 documentation pages across CLI commands, configuration, and stacks sections. A new community documentation page catalogs experimental features with definitions and cross-references. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested labels
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @website/src/components/Experimental/index.css:
- Around line 23-52: The orange text colors in the light theme
(.experimental-text strong and .experimental-text a) fail WCAG AA; update those
selectors to use darker shades that yield at least 4.5:1 contrast against the
light background (for example replace #e65100 with a darker hex like #b23f00 for
.experimental-text strong and replace #ff9800 with a darker link color like
#a05200 for .experimental-text a, and adjust the corresponding :hover color to a
slightly lighter/darker variant to maintain contrast), and if needed tweak
.experimental-badge background-color (reduce opacity or darken) so the badge
remains accessible; ensure you test the new values meet 4.5:1 for small text.
🧹 Nitpick comments (1)
website/src/components/Experimental/index.css (1)
1-52: Consider CSS custom properties for color management.The orange theme colors are hardcoded across multiple selectors. Using CSS variables would make theme updates easier and reduce repetition.
🔎 Example refactor with CSS custom properties
+:root { + --experimental-primary: #ff9800; + --experimental-dark: #e65100; + --experimental-bg: rgba(255, 152, 0, 0.15); + --experimental-border: rgba(255, 152, 0, 0.4); +} + +[data-theme='dark'] { + --experimental-primary: #ffa726; + --experimental-dark: #ffb74d; + --experimental-bg: rgba(255, 152, 0, 0.2); + --experimental-border: rgba(255, 152, 0, 0.5); +} + .experimental-badge { display: inline-flex; align-items: center; gap: 0.5rem; padding: 0.5rem 1rem; margin-bottom: 1.5rem; border-radius: 8px; - background-color: rgba(255, 152, 0, 0.15); - border: 1px solid rgba(255, 152, 0, 0.4); + background-color: var(--experimental-bg); + border: 1px solid var(--experimental-border); font-size: 0.9rem; } .experimental-icon { font-size: 1.2rem; } .experimental-text { display: flex; flex-direction: column; line-height: 1.3; } .experimental-text strong { - color: #e65100; + color: var(--experimental-dark); } .experimental-text a { font-size: 0.8rem; - color: #ff9800; + color: var(--experimental-primary); } .experimental-text a:hover { - color: #e65100; + color: var(--experimental-dark); text-decoration: underline; } - -[data-theme='dark'] .experimental-badge { - background-color: rgba(255, 152, 0, 0.2); - border-color: rgba(255, 152, 0, 0.5); -} - -[data-theme='dark'] .experimental-text strong { - color: #ffb74d; -} - -[data-theme='dark'] .experimental-text a { - color: #ffa726; -} - -[data-theme='dark'] .experimental-text a:hover { - color: #ffb74d; -}
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (16)
website/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/cli/commands/terraform/source/source.mdxwebsite/docs/cli/commands/terraform/workdir/workdir.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/configuration/auth/providers.mdxwebsite/docs/cli/configuration/devcontainer.mdxwebsite/docs/community/experimental-features.mdxwebsite/docs/components/terraform/backend-provisioning.mdxwebsite/docs/stacks/generate.mdxwebsite/docs/stacks/locals.mdxwebsite/docs/stacks/name.mdxwebsite/src/components/Experimental/index.csswebsite/src/components/Experimental/index.tsxwebsite/src/components/FirstReleased/index.csswebsite/src/components/FirstReleased/index.tsx
🧰 Additional context used
📓 Path-based instructions (2)
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/src/components/FirstReleased/index.csswebsite/docs/stacks/name.mdxwebsite/docs/cli/commands/terraform/source/source.mdxwebsite/docs/stacks/locals.mdxwebsite/docs/community/experimental-features.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/src/components/FirstReleased/index.tsxwebsite/src/components/Experimental/index.tsxwebsite/docs/cli/configuration/auth/providers.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/cli/configuration/devcontainer.mdxwebsite/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/components/terraform/backend-provisioning.mdxwebsite/src/components/Experimental/index.csswebsite/docs/cli/commands/terraform/workdir/workdir.mdxwebsite/docs/stacks/generate.mdx
website/docs/cli/commands/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in
<dl>format, and Examples section
Files:
website/docs/cli/commands/terraform/source/source.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/cli/commands/terraform/workdir/workdir.mdx
🧠 Learnings (12)
📓 Common learnings
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to website/docs/cli/commands/**/*.mdx : All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in `<dl>` format, and Examples section
📚 Learning: 2025-09-24T20:45:40.401Z
Learnt from: Benbentwo
Repo: cloudposse/atmos PR: 1475
File: tests/fixtures/scenarios/atmos-auth/stacks/deploy/nonprod.yaml:3-4
Timestamp: 2025-09-24T20:45:40.401Z
Learning: In Atmos stack files, the correct syntax for importing other stack files is `import:` (singular), not `imports:` (plural). All stack files in the Atmos codebase consistently use `import:` followed by a list of paths to import.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1149
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:7-7
Timestamp: 2025-03-18T12:26:25.329Z
Learning: In the Atmos project, typos or inconsistencies in test snapshot files (such as "terrafrom" instead of "terraform") may be intentional as they capture the exact output of commands and should not be flagged as issues requiring correction.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 797
File: pkg/list/atmos.yaml:213-214
Timestamp: 2024-11-25T17:17:15.703Z
Learning: The file `pkg/list/atmos.yaml` is primarily intended for testing purposes.
Applied to files:
website/docs/stacks/name.mdxwebsite/docs/cli/configuration/devcontainer.mdx
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 810
File: examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml:28-32
Timestamp: 2024-12-01T00:33:20.298Z
Learning: In `examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml`, `!exec atmos terraform output` is used in examples to demonstrate its usage, even though `!terraform.output` is the recommended approach according to the documentation.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2025-09-10T21:17:55.273Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/http_client_test.go:3-10
Timestamp: 2025-09-10T21:17:55.273Z
Learning: In the cloudposse/atmos repository, imports should never be changed as per samtholiya's coding guidelines.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2024-10-31T01:22:09.586Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 737
File: examples/demo-vendoring/vendor.d/vendor1.yaml:10-11
Timestamp: 2024-10-31T01:22:09.586Z
Learning: In `examples/demo-vendoring/vendor.d/vendor1.yaml`, when specifying the source for the `ipinfo` component, it's acceptable to use `main` as the version reference if pinning to a specific version is not practical.
Applied to files:
website/docs/cli/commands/terraform/source/source.mdx
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to website/docs/cli/commands/**/*.mdx : All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in `<dl>` format, and Examples section
Applied to files:
website/docs/community/experimental-features.mdxwebsite/docs/cli/commands/toolchain/usage.mdx
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to website/blog/*.mdx : PRs labeled `minor` or `major` MUST include a blog post at `website/blog/YYYY-MM-DD-feature-name.mdx` with YAML frontmatter, using only tags defined in `website/blog/tags.yml`
Applied to files:
website/docs/community/experimental-features.mdx
📚 Learning: 2025-10-14T01:54:48.410Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1498
File: website/src/components/Screengrabs/atmos-completion--help.html:2-7
Timestamp: 2025-10-14T01:54:48.410Z
Learning: Screengrab HTML files in website/src/components/Screengrabs/ are generated from actual Atmos CLI output converted to HTML. The ANSI-art headers and formatting in these files are intentional and reflect the real CLI user experience, so they should not be suggested for removal or modification.
Applied to files:
website/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/stacks/generate.mdx
📚 Learning: 2025-09-07T17:38:17.619Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/src/components/Screengrabs/demo-stacks/deploy-dev.html:28-37
Timestamp: 2025-09-07T17:38:17.619Z
Learning: Screengrab files in the CloudPosse/atmos repository are programmatically generated and should be ignored during code reviews. Do not provide suggestions or comments on files in screengrab directories or screengrab-related HTML files.
Applied to files:
website/docs/cli/commands/list/list-affected.mdx
📚 Learning: 2025-09-07T17:38:40.486Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/src/components/Screengrabs/demo-stacks/deploy-staging.html:28-37
Timestamp: 2025-09-07T17:38:40.486Z
Learning: Files in website/src/components/Screengrabs/ directories are programmatically generated and should not be manually edited or reviewed for code suggestions.
Applied to files:
website/docs/cli/commands/devcontainer/devcontainer.mdx
🪛 LanguageTool
website/docs/community/experimental-features.mdx
[typographical] ~16-~16: Consider using typographic quotation marks here.
Context: ...xtreme circumstances. ## What "Experimental" Means Features marked as experimental:...
(EN_QUOTES)
[style] ~20-~20: To form a complete sentence, be sure to include a subject.
Context: ... Features marked as experimental: - May not be fully functional - Some docume...
(MISSING_IT_THERE)
[typographical] ~64-~64: To join two clauses or introduce examples, consider using an em dash.
Context: ...| ## Related - Community - Get involved with the Atmos community - ...
(DASH_RULE)
[typographical] ~65-~65: To join two clauses or introduce examples, consider using an em dash.
Context: ...tmos community - Changelog - View recent changes and releases
(DASH_RULE)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (26)
website/docs/cli/configuration/devcontainer.mdx (1)
10-10: LGTM! Clean implementation of the experimental feature badge.The import and placement are consistent with the broader PR pattern. Positioning the badge after the intro and before the main content gives users immediate visibility into the feature's maturity status.
Also applies to: 18-19
website/docs/stacks/generate.mdx (1)
11-11: LGTM! Consistent experimental feature marking.The implementation matches the established pattern across the PR. Good placement for user awareness.
Also applies to: 19-20
website/docs/cli/commands/list/list-affected.mdx (1)
11-11: LGTM! Proper experimental marking on CLI command.The badge placement works well before the screengrab, maintaining the required CLI documentation structure while adding the experimental transparency.
Also applies to: 17-18
website/docs/cli/commands/devcontainer/devcontainer.mdx (1)
10-10: LGTM! Experimental badge properly integrated.Clean implementation that preserves the existing documentation flow. The badge appears at the right moment for user context.
Also applies to: 23-24
website/docs/cli/configuration/auth/providers.mdx (1)
12-12: LGTM! Consistent experimental feature transparency.The implementation follows the established pattern perfectly. All five files in this review maintain consistent placement and structure for the experimental badge, which provides a cohesive user experience across the documentation.
Also applies to: 20-21
website/docs/stacks/locals.mdx (1)
11-11: LGTM! Clean integration of the Experimental badge.The import and placement after the Intro block are consistent with the broader documentation pattern across this PR.
Also applies to: 17-17
website/docs/cli/commands/terraform/workdir/workdir.mdx (1)
9-9: LGTM! Experimental badge integrated correctly.The component is properly imported and rendered after the Intro block. All required CLI documentation sections remain intact.
Also applies to: 19-19
website/docs/cli/commands/terraform/source/source.mdx (1)
9-9: LGTM! Consistent implementation.The Experimental badge follows the same pattern as other documentation pages in this PR, with appropriate placement after the Intro block.
Also applies to: 19-19
website/docs/stacks/name.mdx (1)
11-11: LGTM! Experimental badge properly integrated.The component import and placement are consistent with the pattern established across all documentation pages in this PR.
Also applies to: 19-19
website/docs/cli/commands/toolchain/usage.mdx (1)
13-13: LGTM! Experimental badge correctly implemented.The component is properly imported and rendered in the standard location after the Intro block. All required CLI documentation sections are preserved.
Also applies to: 21-21
website/docs/community/experimental-features.mdx (4)
1-9: LGTM!Frontmatter and imports are properly configured for Docusaurus.
10-42: Well-structured documentation.The content clearly explains experimental features, how to provide feedback, and graduation criteria. The messaging appropriately sets user expectations.
44-61: Comprehensive feature catalog.The table provides a clear overview of all experimental features with appropriate links to their documentation.
62-65: LGTM!Related links are appropriate and properly formatted.
website/src/components/Experimental/index.tsx (3)
1-7: LGTM!Imports and interface are properly structured with clear typing.
9-12: Good accessibility implementation.The dynamic aria-label properly describes the badge context based on whether a specific feature is named.
14-22: Accessible and semantic structure.The badge uses appropriate ARIA attributes and provides a clear visual indicator with contextual link.
website/src/components/FirstReleased/index.css (3)
1-16: Clean badge styling.Base styles use appropriate sizing, spacing, and transparency for flexible placement.
18-21: LGTM!Hover state provides subtle visual feedback while maintaining badge appearance.
23-30: Proper dark theme support.Dark theme overrides use appropriate lighter colors for better contrast.
website/src/components/FirstReleased/index.tsx (3)
1-8: LGTM!Imports and interface are properly structured with helpful documentation comments.
10-12: Good defensive normalization.Ensures version always displays with 'v' prefix regardless of input format.
14-25: Clean implementation.Changelog path logic and link structure provide flexible version tracking with good user experience.
website/docs/components/terraform/backend-provisioning.mdx (2)
10-10: Consistent experimental marking.Import and component placement follow the established pattern across documentation pages.
Also applies to: 17-18
22-22: LGTM!Adding the CLI reference to related documentation improves discoverability.
website/src/components/Experimental/index.css (1)
1-36: Solid structure and layout.The base styling uses modern CSS patterns effectively—flexbox for alignment, rgba for transparency, and clear separation of concerns. The component should render cleanly.
- Add ui.Experimental() toast function for CLI notifications - Add experimental_warnings config option (default: true) - Add experimental badge to roadmap milestones and featured cards - Add ExperimentalFeaturesList component for /experimental page - Add experimental tag support in changelog timeline - Move experimental-features.mdx to /experimental with dynamic content - Add "Experimental Features" link to roadmap page - Mark experimental features in roadmap.js with experimental: true - Use subtle gray color for experimental notifications 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
Important Cloud Posse Engineering Team Review RequiredThis pull request modifies files that require Cloud Posse's review. Please be patient, and a core maintainer will review your changes. To expedite this process, reach out to us on Slack in the |
When experimental_warnings is set to false, still log a debug message indicating that an experimental feature is being used. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
website/src/components/Experimental/index.css (1)
1-52: Consider using CSS custom properties for colors.The colors are hardcoded throughout. If the project uses CSS custom properties or design tokens elsewhere, consider defining these orange values as variables for consistency and easier maintenance.
💡 Example refactor with CSS variables
+:root { + --experimental-orange-light: #ff9800; + --experimental-orange-dark: #e65100; + --experimental-orange-bg: rgba(255, 152, 0, 0.15); + --experimental-orange-border: rgba(255, 152, 0, 0.4); +} + +[data-theme='dark'] { + --experimental-orange-light: #ffa726; + --experimental-orange-dark: #ffb74d; + --experimental-orange-bg: rgba(255, 152, 0, 0.2); + --experimental-orange-border: rgba(255, 152, 0, 0.5); +} + .experimental-badge { display: inline-flex; align-items: center; gap: 0.5rem; padding: 0.5rem 1rem; margin-bottom: 1.5rem; border-radius: 8px; - background-color: rgba(255, 152, 0, 0.15); - border: 1px solid rgba(255, 152, 0, 0.4); + background-color: var(--experimental-orange-bg); + border: 1px solid var(--experimental-orange-border); font-size: 0.9rem; } .experimental-text strong { - color: #e65100; + color: var(--experimental-orange-dark); } .experimental-text a { font-size: 0.8rem; - color: #ff9800; + color: var(--experimental-orange-light); }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (16)
website/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/cli/commands/terraform/source/source.mdxwebsite/docs/cli/commands/terraform/workdir/workdir.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/configuration/auth/providers.mdxwebsite/docs/cli/configuration/devcontainer.mdxwebsite/docs/community/experimental-features.mdxwebsite/docs/components/terraform/backend-provisioning.mdxwebsite/docs/stacks/generate.mdxwebsite/docs/stacks/locals.mdxwebsite/docs/stacks/name.mdxwebsite/src/components/Experimental/index.csswebsite/src/components/Experimental/index.tsxwebsite/src/components/FirstReleased/index.csswebsite/src/components/FirstReleased/index.tsx
🧰 Additional context used
📓 Path-based instructions (2)
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/docs/cli/configuration/auth/providers.mdxwebsite/docs/cli/configuration/devcontainer.mdxwebsite/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/commands/terraform/source/source.mdxwebsite/docs/cli/commands/terraform/workdir/workdir.mdxwebsite/src/components/FirstReleased/index.tsxwebsite/docs/community/experimental-features.mdxwebsite/src/components/Experimental/index.tsxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/stacks/name.mdxwebsite/docs/components/terraform/backend-provisioning.mdxwebsite/docs/stacks/locals.mdxwebsite/src/components/Experimental/index.csswebsite/src/components/FirstReleased/index.csswebsite/docs/stacks/generate.mdx
website/docs/cli/commands/**/*.mdx
📄 CodeRabbit inference engine (CLAUDE.md)
All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in
<dl>format, and Examples section
Files:
website/docs/cli/commands/devcontainer/devcontainer.mdxwebsite/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/commands/terraform/source/source.mdxwebsite/docs/cli/commands/terraform/workdir/workdir.mdxwebsite/docs/cli/commands/list/list-affected.mdx
🧠 Learnings (12)
📓 Common learnings
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: docs/prd/tool-dependencies-integration.md:58-64
Timestamp: 2025-12-13T06:07:37.766Z
Learning: cloudposse/atmos: For PRD docs (docs/prd/*.md), markdownlint issues like MD040/MD010/MD034 can be handled in a separate documentation cleanup commit and should not block the current PR.
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 797
File: pkg/list/atmos.yaml:213-214
Timestamp: 2024-11-25T17:17:15.703Z
Learning: The file `pkg/list/atmos.yaml` is primarily intended for testing purposes.
Applied to files:
website/docs/cli/configuration/devcontainer.mdxwebsite/docs/stacks/name.mdx
📚 Learning: 2025-09-07T17:38:40.486Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/src/components/Screengrabs/demo-stacks/deploy-staging.html:28-37
Timestamp: 2025-09-07T17:38:40.486Z
Learning: Files in website/src/components/Screengrabs/ directories are programmatically generated and should not be manually edited or reviewed for code suggestions.
Applied to files:
website/docs/cli/commands/devcontainer/devcontainer.mdx
📚 Learning: 2025-10-14T01:54:48.410Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1498
File: website/src/components/Screengrabs/atmos-completion--help.html:2-7
Timestamp: 2025-10-14T01:54:48.410Z
Learning: Screengrab HTML files in website/src/components/Screengrabs/ are generated from actual Atmos CLI output converted to HTML. The ANSI-art headers and formatting in these files are intentional and reflect the real CLI user experience, so they should not be suggested for removal or modification.
Applied to files:
website/docs/cli/commands/toolchain/usage.mdxwebsite/docs/cli/commands/list/list-affected.mdxwebsite/docs/stacks/generate.mdx
📚 Learning: 2024-10-31T01:22:09.586Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 737
File: examples/demo-vendoring/vendor.d/vendor1.yaml:10-11
Timestamp: 2024-10-31T01:22:09.586Z
Learning: In `examples/demo-vendoring/vendor.d/vendor1.yaml`, when specifying the source for the `ipinfo` component, it's acceptable to use `main` as the version reference if pinning to a specific version is not practical.
Applied to files:
website/docs/cli/commands/terraform/source/source.mdx
📚 Learning: 2025-09-13T16:39:20.007Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: cmd/markdown/atmos_toolchain_aliases.md:2-4
Timestamp: 2025-09-13T16:39:20.007Z
Learning: In the cloudposse/atmos repository, CLI documentation files in cmd/markdown/ follow a specific format that uses " $ atmos command" (with leading space and dollar sign prompt) in code blocks. This is the established project convention and should not be changed to comply with standard markdownlint rules MD040 and MD014.
Applied to files:
website/docs/cli/commands/list/list-affected.mdx
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to website/docs/cli/commands/**/*.mdx : All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in `<dl>` format, and Examples section
Applied to files:
website/docs/cli/commands/list/list-affected.mdx
📚 Learning: 2025-09-07T17:38:17.619Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/src/components/Screengrabs/demo-stacks/deploy-dev.html:28-37
Timestamp: 2025-09-07T17:38:17.619Z
Learning: Screengrab files in the CloudPosse/atmos repository are programmatically generated and should be ignored during code reviews. Do not provide suggestions or comments on files in screengrab directories or screengrab-related HTML files.
Applied to files:
website/docs/cli/commands/list/list-affected.mdx
📚 Learning: 2025-09-24T20:45:40.401Z
Learnt from: Benbentwo
Repo: cloudposse/atmos PR: 1475
File: tests/fixtures/scenarios/atmos-auth/stacks/deploy/nonprod.yaml:3-4
Timestamp: 2025-09-24T20:45:40.401Z
Learning: In Atmos stack files, the correct syntax for importing other stack files is `import:` (singular), not `imports:` (plural). All stack files in the Atmos codebase consistently use `import:` followed by a list of paths to import.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1149
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:7-7
Timestamp: 2025-03-18T12:26:25.329Z
Learning: In the Atmos project, typos or inconsistencies in test snapshot files (such as "terrafrom" instead of "terraform") may be intentional as they capture the exact output of commands and should not be flagged as issues requiring correction.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 810
File: examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml:28-32
Timestamp: 2024-12-01T00:33:20.298Z
Learning: In `examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml`, `!exec atmos terraform output` is used in examples to demonstrate its usage, even though `!terraform.output` is the recommended approach according to the documentation.
Applied to files:
website/docs/stacks/name.mdx
📚 Learning: 2025-09-10T21:17:55.273Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/http_client_test.go:3-10
Timestamp: 2025-09-10T21:17:55.273Z
Learning: In the cloudposse/atmos repository, imports should never be changed as per samtholiya's coding guidelines.
Applied to files:
website/docs/stacks/name.mdx
🪛 LanguageTool
website/docs/community/experimental-features.mdx
[typographical] ~16-~16: Consider using typographic quotation marks here.
Context: ...xtreme circumstances. ## What "Experimental" Means Features marked as experimental:...
(EN_QUOTES)
[style] ~20-~20: To form a complete sentence, be sure to include a subject.
Context: ... Features marked as experimental: - May not be fully functional - Some docume...
(MISSING_IT_THERE)
[typographical] ~64-~64: To join two clauses or introduce examples, consider using an em dash.
Context: ...| ## Related - Community - Get involved with the Atmos community - ...
(DASH_RULE)
[typographical] ~65-~65: To join two clauses or introduce examples, consider using an em dash.
Context: ...tmos community - Changelog - View recent changes and releases
(DASH_RULE)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (16)
website/docs/cli/configuration/devcontainer.mdx (1)
10-10: Clean integration of the Experimental badge.The import and placement after the
<Intro>component is consistent with the pattern across all documentation pages in this PR.Also applies to: 18-18
website/docs/cli/commands/terraform/workdir/workdir.mdx (1)
9-9: LGTM!The Experimental component is properly imported and rendered. The blank lines around the component enhance readability.
Also applies to: 19-20
website/docs/cli/commands/toolchain/usage.mdx (1)
13-13: Proper implementation.The Experimental badge is correctly integrated into the toolchain documentation following the established pattern.
Also applies to: 21-22
website/docs/stacks/name.mdx (1)
11-11: Looks good.The Experimental component integration follows the same clean pattern used throughout this PR.
Also applies to: 19-20
website/docs/cli/configuration/auth/providers.mdx (1)
12-12: Consistent implementation.The Experimental badge is properly integrated, maintaining consistency with the other documentation pages in this PR.
Also applies to: 20-21
website/docs/cli/commands/list/list-affected.mdx (1)
11-11: LGTM!The Experimental component import and usage follow a clean pattern. The placement after the Intro section is logical and provides clear visibility into feature maturity without disrupting the documentation flow.
Also applies to: 17-18
website/docs/stacks/generate.mdx (1)
11-11: LGTM!Consistent implementation of the Experimental badge. The placement maintains good documentation structure.
Also applies to: 19-20
website/docs/cli/commands/devcontainer/devcontainer.mdx (1)
10-10: LGTM!The Experimental component integration follows the established pattern and fits naturally into the documentation structure.
Also applies to: 23-24
website/docs/cli/commands/terraform/source/source.mdx (1)
9-9: LGTM!Clean integration of the Experimental badge, consistent with the other documentation pages.
Also applies to: 19-20
website/docs/components/terraform/backend-provisioning.mdx (2)
10-10: LGTM!The Experimental component is properly integrated, maintaining consistency across the documentation.
Also applies to: 17-18
22-22: Nice addition!Adding the CLI reference link to
atmos terraform backendimproves documentation discoverability and helps users navigate to related commands.website/src/components/FirstReleased/index.css (1)
1-30: Solid styling with proper dark mode support.The CSS is clean and well-organized. The use of inline-flex for layout, rgba colors for theme consistency, smooth transitions, and comprehensive dark mode variants shows good attention to detail.
website/docs/community/experimental-features.mdx (1)
1-65: Excellent documentation that sets clear expectations.This page effectively communicates what experimental means, provides multiple feedback channels, defines graduation criteria, and catalogs current experimental features. The structure is logical and the content is comprehensive.
website/src/components/Experimental/index.tsx (1)
1-25: Well-implemented component with strong accessibility.The component properly uses TypeScript for type safety, includes appropriate ARIA attributes (role="status" and dynamic aria-label), and has a clean, focused implementation. The optional feature prop for contextual aria-labels is a nice touch.
website/src/components/FirstReleased/index.tsx (1)
1-28: Clean implementation with sensible defaults.The version normalization ensures consistent display format, and the changelog path logic appropriately falls back to the main changelog when a specific slug isn't provided. The title attribute enhances accessibility with helpful tooltip text.
website/docs/stacks/locals.mdx (1)
11-11: Appropriate placement of experimental indicator.The import and placement of the Experimental badge effectively marks this feature as experimental without disrupting the existing documentation flow.
Also applies to: 17-18
- Add reusable ui.Badge() function for styled terminal badges - Show EXPERIMENTAL badge at top of experimental command --help - Show EXPERIMENTAL badge next to experimental subcommands in parent help - Skip badge on subcommands when parent is already experimental (avoid repetition) - Mark list affected subcommand as experimental - Group experimental features by initiative on website - Add "Help Us Prioritize" CTA section to experimental features page - Add sentinel errors for experimental command handling 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
Warning This PR exceeds the recommended limit of 1,000 lines.Large PRs are difficult to review and may be rejected due to their size. Please verify that this PR does not address multiple issues. |
- Use darker orange shades for light theme text (#d97706, #b45309) to meet WCAG AA 4.5:1 contrast requirement for small text - Add focus-visible styles for keyboard navigation accessibility - Dark theme already meets contrast requirements 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
The roadmap marks toolchain as experimental but the command provider returned false for IsExperimental(). Now aligned with roadmap. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
💥 This pull request now has conflicts. Could you fix it @osterman? 🙏 |
…-features Resolve conflict in .claude/agents/flag-handler.md by keeping expanded documentation from main (additional PRDs and reference implementations).
…-features Resolve conflict in pkg/ui/formatter_test.go by keeping both sets of tests: - New TestTrimLeftSpaces tests from main (markdown offset fix) - Our experimental feature tests (Badge, Experimental, ClearLine, etc.)
Update golden snapshots to include [EXPERIMENTAL] badges for: - atmos toolchain - atmos devcontainer - atmos terraform backend - atmos terraform workdir The experimental feature controls PR added visual badges to help output, requiring snapshot updates. Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@tests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.golden`:
- Around line 4-5: The golden snapshot was edited manually; instead regenerate
the snapshot using the test snapshot update flow for the failing test
(TestCLICommands_atmos_toolchain_info_--help) rather than editing the file by
hand—run the project's snapshot regeneration command (e.g., use the
-regenerate-snapshots flag or your test-runner's update-snapshots option) to
produce an updated snapshot and commit that regenerated output.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
tests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_help_flag_works.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
✅ Files skipped from review due to trivial changes (1)
- tests/snapshots/TestCLICommands_help_flag_works.stdout.golden
🧰 Additional context used
📓 Path-based instructions (1)
tests/snapshots/**/*
📄 CodeRabbit inference engine (CLAUDE.md)
Never manually edit golden snapshot files - always use
-regenerate-snapshotsflag when updating test output
Files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
🧠 Learnings (18)
📓 Common learnings
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: docs/prd/tool-dependencies-integration.md:58-64
Timestamp: 2025-12-13T06:07:37.766Z
Learning: cloudposse/atmos: For PRD docs (docs/prd/*.md), markdownlint issues like MD040/MD010/MD034 can be handled in a separate documentation cleanup commit and should not block the current PR.
📚 Learning: 2024-12-07T16:16:13.038Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 825
File: internal/exec/helmfile_generate_varfile.go:28-31
Timestamp: 2024-12-07T16:16:13.038Z
Learning: In `internal/exec/helmfile_generate_varfile.go`, the `--help` command (`./atmos helmfile generate varfile --help`) works correctly without requiring stack configurations, and the only change needed was to make `ProcessCommandLineArgs` exportable by capitalizing its name.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-01-19T15:49:15.593Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 955
File: tests/snapshots/TestCLICommands_atmos_validate_editorconfig_--help.stdout.golden:0-0
Timestamp: 2025-01-19T15:49:15.593Z
Learning: In future commits, the help text for Atmos CLI commands should be limited to only show component and stack parameters for commands that actually use them. This applies to the example usage section in command help text.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain XDG compliance implementation is complete with GetXDGCacheDir() and GetXDGTempCacheDir() functions in toolchain/xdg_cache.go, updated installer.go and toolchain_clean.go to use these helpers, and changed cache paths from ~/.cache/tools-cache to ${XDG_CACHE_HOME}/atmos-toolchain (or ~/.cache/atmos-toolchain when XDG_CACHE_HOME is not set).
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-09-13T16:39:20.007Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: cmd/markdown/atmos_toolchain_aliases.md:2-4
Timestamp: 2025-09-13T16:39:20.007Z
Learning: In the cloudposse/atmos repository, CLI documentation files in cmd/markdown/ follow a specific format that uses " $ atmos command" (with leading space and dollar sign prompt) in code blocks. This is the established project convention and should not be changed to comply with standard markdownlint rules MD040 and MD014.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-10-07T00:25:16.333Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1498
File: website/src/components/Screengrabs/atmos-terraform-metadata--help.html:25-55
Timestamp: 2025-10-07T00:25:16.333Z
Learning: In Atmos CLI, subcommands inherit flags from their parent commands via Cobra's command inheritance. For example, `atmos terraform metadata --help` shows `--affected` and related flags inherited from the parent `terraform` command (defined in cmd/terraform.go), even though the metadata subcommand doesn't explicitly define these flags. This is expected Cobra behavior and auto-generated help screengrabs accurately reflect this inheritance.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain has been updated to follow XDG Base Directory Specification with helper functions GetXDGCacheDir() and GetXDGTempCacheDir() in toolchain/xdg_cache.go, using XDG_CACHE_HOME when set and falling back to ~/.cache/atmos-toolchain, making it consistent with atmos core's XDG compliance.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1149
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:7-7
Timestamp: 2025-03-18T12:26:25.329Z
Learning: In the Atmos project, typos or inconsistencies in test snapshot files (such as "terrafrom" instead of "terraform") may be intentional as they capture the exact output of commands and should not be flagged as issues requiring correction.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-09-05T14:57:37.360Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 1448
File: cmd/ansible.go:26-28
Timestamp: 2025-09-05T14:57:37.360Z
Learning: The Atmos codebase uses a consistent pattern for commands that delegate to external tools: `PersistentFlags().Bool("", false, doubleDashHint)` where doubleDashHint provides help text about using double dashes to separate Atmos options from native command arguments. This pattern is used across terraform, packer, helmfile, atlantis, aws, and ansible commands.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-02-18T13:13:11.497Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1068
File: tests/snapshots/TestCLICommands_atmos_terraform_help.stdout.golden:59-64
Timestamp: 2025-02-18T13:13:11.497Z
Learning: For Atmos CLI help text, angle brackets in command examples and flag descriptions should be escaped using HTML entities (e.g., `<component>`) rather than converted to backticks or other markdown formatting.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2025-02-14T23:12:38.030Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1061
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:8-8
Timestamp: 2025-02-14T23:12:38.030Z
Learning: Test snapshots in the Atmos project, particularly for dry run scenarios, may be updated during the development process, and temporary inconsistencies in their content should not be flagged as issues.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.goldentests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 797
File: pkg/list/atmos.yaml:213-214
Timestamp: 2024-11-25T17:17:15.703Z
Learning: The file `pkg/list/atmos.yaml` is primarily intended for testing purposes.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.golden
📚 Learning: 2024-12-07T16:19:01.683Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 825
File: internal/exec/terraform.go:30-30
Timestamp: 2024-12-07T16:19:01.683Z
Learning: In `internal/exec/terraform.go`, skipping stack validation when help flags are present is not necessary.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
📚 Learning: 2025-06-23T02:14:30.937Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1327
File: cmd/terraform.go:111-117
Timestamp: 2025-06-23T02:14:30.937Z
Learning: In cmd/terraform.go, flags for the DescribeAffected function are added dynamically at runtime when info.Affected is true. This is intentional to avoid exposing internal flags like "file", "format", "verbose", "include-spacelift-admin-stacks", "include-settings", and "upload" in the terraform command interface, while still providing them for the shared DescribeAffected function used by both `atmos describe affected` and `atmos terraform apply --affected`.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
📚 Learning: 2025-10-10T23:51:36.597Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1599
File: internal/exec/terraform.go:394-402
Timestamp: 2025-10-10T23:51:36.597Z
Learning: In Atmos (internal/exec/terraform.go), when adding OpenTofu-specific flags like `--var-file` for `init`, do not gate them based on command name (e.g., checking if `info.Command == "tofu"` or `info.Command == "opentofu"`) because command names don't reliably indicate the actual binary being executed (symlinks, aliases). Instead, document the OpenTofu requirement in code comments and documentation, trusting users who enable the feature (e.g., `PassVars`) to ensure their terraform command points to an OpenTofu binary.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
📚 Learning: 2025-01-09T22:37:01.004Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 914
File: cmd/terraform_commands.go:260-265
Timestamp: 2025-01-09T22:37:01.004Z
Learning: In the terraform commands implementation (cmd/terraform_commands.go), the direct use of `os.Args[2:]` for argument handling is intentionally preserved to avoid extensive refactoring. While it could be improved to use cobra's argument parsing, such changes should be handled in a dedicated PR to maintain focus and minimize risk.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
📚 Learning: 2024-12-01T00:33:20.298Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 810
File: examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml:28-32
Timestamp: 2024-12-01T00:33:20.298Z
Learning: In `examples/tests/stacks/catalog/terraform/template-functions-test2/defaults.yaml`, `!exec atmos terraform output` is used in examples to demonstrate its usage, even though `!terraform.output` is the recommended approach according to the documentation.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
📚 Learning: 2025-02-19T05:50:35.853Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1068
File: tests/snapshots/TestCLICommands_atmos_terraform_apply_--help.stdout.golden:0-0
Timestamp: 2025-02-19T05:50:35.853Z
Learning: Backtick formatting should only be applied to flag descriptions in Go source files, not in golden test files (test snapshots) as they are meant to capture the raw command output.
Applied to files:
tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Acceptance Tests (macos)
- GitHub Check: Acceptance Tests (windows)
- GitHub Check: Acceptance Tests (linux)
- GitHub Check: Summary
🔇 Additional comments (3)
tests/snapshots/TestCLICommands_atmos_toolchain_--help.stdout.golden (1)
4-6: Confirm snapshot was regenerated via tooling.Snapshot files shouldn’t be hand-edited—please confirm this update was produced with the
-regenerate-snapshotsflag.tests/snapshots/TestCLICommands_atmos_toolchain_install_--help.stdout.golden (1)
4-5: Looks good!The
[EXPERIMENTAL]tag addition properly reflects the new experimental feature labeling for the toolchain install command. This aligns well with the PR's goal of adding transparency around experimental features.Just confirming this snapshot was regenerated using the
-regenerate-snapshotsflag rather than manually edited, per the project conventions.tests/snapshots/TestCLICommands_terraform_help_shows_stack_flag.stdout.golden (1)
30-64: Snapshot reflects experimental markers correctly.The updated AVAILABLE COMMANDS section now shows
[EXPERIMENTAL]suffixes onbackendandworkdircommands, matching the PR's goal of adding transparency for experimental features. The formatting and alignment look consistent across all entries.As a reminder, per coding guidelines, if any adjustments are needed, regenerate this file using the
-regenerate-snapshotsflag rather than editing manually.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
tests/snapshots/TestCLICommands_atmos_toolchain_info_--help.stdout.golden
Show resolved
Hide resolved
- PRD experimental commands list updated - PRD subcommand-level section updated - Documentation error messages match actual output - Experimental() function now includes feature name - findExperimentalParent() returns correct parent names - Toolchain command calls parent's PersistentPreRun
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
`@tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden`:
- Around line 1-3: The snapshot file for test
TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
was manually edited; regenerate the snapshot using the project's snapshot tool
(run the test snapshot generation with the -regenerate-snapshots flag) so the
output reflects the actual CLI run, then commit the regenerated snapshot instead
of making manual edits.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (17)
cmd/internal/registry_test.gocmd/root.gocmd/root_helpers_test.gocmd/toolchain/toolchain.godocs/prd/experimental-features-system.mdpkg/ui/formatter.gopkg/ui/formatter_test.gotests/snapshots/TestCLICommands_atmos_toolchain_info_http_type_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_non-existent_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_yaml_output.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_registry_search.stderr.goldenwebsite/docs/cli/configuration/settings/experimental.mdxwebsite/docs/experimental.mdx
✅ Files skipped from review due to trivial changes (4)
- tests/snapshots/TestCLICommands_atmos_toolchain_registry_search.stderr.golden
- tests/snapshots/TestCLICommands_atmos_toolchain_info_non-existent_tool.stderr.golden
- tests/snapshots/TestCLICommands_atmos_toolchain_info_http_type_tool.stderr.golden
- tests/snapshots/TestCLICommands_atmos_toolchain_info_yaml_output.stderr.golden
🚧 Files skipped from review as they are similar to previous changes (2)
- cmd/root.go
- pkg/ui/formatter_test.go
🧰 Additional context used
📓 Path-based instructions (8)
tests/snapshots/**/*
📄 CodeRabbit inference engine (CLAUDE.md)
Never manually edit golden snapshot files - always use
-regenerate-snapshotsflag when updating test output
Files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
**/*.go
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
**/*.go: Use Viper for managing configuration, environment variables, and flags in CLI commands
Use interfaces for external dependencies to facilitate mocking and consider using testify/mock for creating mock implementations
All code must pass golangci-lint checks
Follow Go's error handling idioms: use meaningful error messages, wrap errors with context usingfmt.Errorf("context: %w", err), and consider using custom error types for domain-specific errors
Follow standard Go coding style: usegofmtandgoimportsto format code, prefer short descriptive variable names, use kebab-case for command-line flags, and snake_case for environment variables
Document all exported functions, types, and methods following Go's documentation conventions
Document complex logic with inline comments in Go code
Support configuration via files, environment variables, and flags following the precedence order: flags > environment variables > config file > defaults
Provide clear error messages to users, include troubleshooting hints when appropriate, and log detailed errors for debugging
**/*.go: All comments must end with periods (enforced bygodotlinter) in Go code
Organize imports into three groups separated by blank lines, sorted alphabetically: Go stdlib, 3rd-party (NOT cloudposse/atmos), then Atmos packages with maintained aliases (cfg,log,u,errUtils)
All errors MUST be wrapped using static errors defined inerrors/errors.go- useerrors.Joinfor combining errors,fmt.Errorfwith%wfor context, anderrors.Is()for error checking
Never manually create mocks - usego.uber.org/mock/mockgenwith//go:generatedirectives in Go code
Keep files small and focused - under 600 lines with one cmd/impl per file, co-locate tests, never use//revive:disable:file-length-limit
Use colors frompkg/ui/theme/colors.gofor all UI theming in Go code
Code must be compatible with Linux, macOS, and Windows - use SDKs over binaries, usefilepath.Join()instead of h...
Files:
pkg/ui/formatter.gocmd/internal/registry_test.gocmd/toolchain/toolchain.gocmd/root_helpers_test.go
**/{pkg,internal,cmd}/**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
Add
defer perf.Track(atmosConfig, "pkg.FuncName")()plus blank line to all public functions, usingnilif no atmosConfig param - exceptions: trivial getters/setters, command constructors, simple factories, functions delegating to tracked functions
Files:
pkg/ui/formatter.gocmd/internal/registry_test.gocmd/toolchain/toolchain.gocmd/root_helpers_test.go
cmd/**/*.go
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
cmd/**/*.go: Use Cobra's recommended command structure with a root command and subcommands, implementing each command in a separate file undercmd/directory
Provide comprehensive help text for all commands and flags, include examples in command help, and follow Go's documentation conventions in Cobra command definitions
Provide meaningful feedback to users and include progress indicators for long-running operations in CLI commands
Files:
cmd/internal/registry_test.gocmd/toolchain/toolchain.gocmd/root_helpers_test.go
**/*_test.go
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
**/*_test.go: Every new feature must include comprehensive unit tests targeting >80% code coverage for all packages
Use table-driven tests for testing multiple scenarios in Go
Include integration tests for command flows and test CLI end-to-end when possible with test fixturesPrefer unit tests with mocks over integration tests - use interfaces and dependency injection for testability, generate mocks with
go.uber.org/mock/mockgen, use table-driven tests, target >80% coverage
Files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
cmd/**/*_test.go
📄 CodeRabbit inference engine (CLAUDE.md)
Always use
cmd.NewTestKit(t)for cmd tests to auto-clean RootCmd state
Files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
docs/prd/**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Place all Product Requirement Documents (PRDs) in
docs/prd/using kebab-case filenames
Files:
docs/prd/experimental-features-system.md
website/**
📄 CodeRabbit inference engine (.cursor/rules/atmos-rules.mdc)
website/**: Update website documentation in thewebsite/directory when adding new features, ensure consistency between CLI help text and website documentation, and follow the website's documentation structure and style
Keep website code in thewebsite/directory, follow the existing website architecture and style, and test website changes locally before committing
Keep CLI documentation and website documentation in sync and document new features on the website with examples and use cases
Files:
website/docs/cli/configuration/settings/experimental.mdxwebsite/docs/experimental.mdx
🧠 Learnings (58)
📓 Common learnings
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: docs/prd/tool-dependencies-integration.md:58-64
Timestamp: 2025-12-13T06:07:37.766Z
Learning: cloudposse/atmos: For PRD docs (docs/prd/*.md), markdownlint issues like MD040/MD010/MD034 can be handled in a separate documentation cleanup commit and should not block the current PR.
📚 Learning: 2025-03-18T12:26:25.329Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1149
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:7-7
Timestamp: 2025-03-18T12:26:25.329Z
Learning: In the Atmos project, typos or inconsistencies in test snapshot files (such as "terrafrom" instead of "terraform") may be intentional as they capture the exact output of commands and should not be flagged as issues requiring correction.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain XDG compliance implementation is complete with GetXDGCacheDir() and GetXDGTempCacheDir() functions in toolchain/xdg_cache.go, updated installer.go and toolchain_clean.go to use these helpers, and changed cache paths from ~/.cache/tools-cache to ${XDG_CACHE_HOME}/atmos-toolchain (or ~/.cache/atmos-toolchain when XDG_CACHE_HOME is not set).
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldencmd/toolchain/toolchain.gowebsite/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: The atmos toolchain has been updated to follow XDG Base Directory Specification with helper functions GetXDGCacheDir() and GetXDGTempCacheDir() in toolchain/xdg_cache.go, using XDG_CACHE_HOME when set and falling back to ~/.cache/atmos-toolchain, making it consistent with atmos core's XDG compliance.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
📚 Learning: 2025-02-14T23:12:38.030Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 1061
File: tests/snapshots/TestCLICommands_atmos_vendor_pull_ssh.stderr.golden:8-8
Timestamp: 2025-02-14T23:12:38.030Z
Learning: Test snapshots in the Atmos project, particularly for dry run scenarios, may be updated during the development process, and temporary inconsistencies in their content should not be flagged as issues.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
📚 Learning: 2025-12-13T06:10:13.688Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: errors/errors.go:184-203
Timestamp: 2025-12-13T06:10:13.688Z
Learning: cloudposse/atmos: For toolchain work, duplicate/unused error sentinels in errors/errors.go should be cleaned up in a separate refactor PR and not block feature PRs; canonical toolchain sentinels live under toolchain/registry with re-exports in toolchain/errors.go.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldencmd/toolchain/toolchain.gowebsite/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-11-01T20:24:29.557Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1714
File: NOTICE:0-0
Timestamp: 2025-11-01T20:24:29.557Z
Learning: In the cloudposse/atmos repository, the NOTICE file is programmatically generated and should not be manually edited. Issues with dependency license URLs in NOTICE will be resolved when upstream package metadata is corrected.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
📚 Learning: 2025-09-13T16:39:20.007Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: cmd/markdown/atmos_toolchain_aliases.md:2-4
Timestamp: 2025-09-13T16:39:20.007Z
Learning: In the cloudposse/atmos repository, CLI documentation files in cmd/markdown/ follow a specific format that uses " $ atmos command" (with leading space and dollar sign prompt) in code blocks. This is the established project convention and should not be changed to comply with standard markdownlint rules MD040 and MD014.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldenwebsite/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: XDG Base Directory Specification compliance implementation for atmos toolchain is complete: created toolchain/xdg_cache.go with GetXDGCacheDir() and GetXDGTempCacheDir() functions, updated toolchain/installer.go and cmd/toolchain_clean.go to use these XDG helpers, and changed all cache paths from hardcoded ~/.cache/tools-cache to XDG-compliant ${XDG_CACHE_HOME}/atmos-toolchain (or ~/.cache/atmos-toolchain fallback).
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldencmd/toolchain/toolchain.gowebsite/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-09-08T01:25:44.958Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1466
File: website/docs/cli/commands/toolchain/usage.mdx:117-121
Timestamp: 2025-09-08T01:25:44.958Z
Learning: Final XDG Base Directory Specification implementation for atmos toolchain is complete and verified: toolchain/xdg_cache.go provides GetXDGCacheDir() and GetXDGTempCacheDir() functions, all hardcoded ~/.cache/tools-cache paths have been replaced with XDG-compliant paths using ${XDG_CACHE_HOME}/atmos-toolchain (or ~/.cache/atmos-toolchain fallback), and tests have been updated to expect the new path structure.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.golden
📚 Learning: 2024-11-25T17:17:15.703Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 797
File: pkg/list/atmos.yaml:213-214
Timestamp: 2024-11-25T17:17:15.703Z
Learning: The file `pkg/list/atmos.yaml` is primarily intended for testing purposes.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
📚 Learning: 2025-09-27T20:50:20.564Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1533
File: pkg/config/load.go:585-637
Timestamp: 2025-09-27T20:50:20.564Z
Learning: In the cloudposse/atmos repository, command merging prioritizes precedence over display ordering. Help commands are displayed lexicographically regardless of internal array order, so the mergeCommandArrays function focuses on ensuring the correct precedence chain (top-level file wins) rather than maintaining specific display order.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
📚 Learning: 2025-11-09T19:06:58.470Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1752
File: pkg/profile/list/formatter_table.go:27-29
Timestamp: 2025-11-09T19:06:58.470Z
Learning: In the cloudposse/atmos repository, performance tracking with `defer perf.Track()` is enforced on all functions via linting, including high-frequency utility functions, formatters, and renderers. This is a repository-wide policy to maintain consistency and avoid making case-by-case judgment calls about which functions should have profiling.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.golden
📚 Learning: 2024-11-12T13:06:56.194Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 768
File: website/docs/cheatsheets/vendoring.mdx:70-70
Timestamp: 2024-11-12T13:06:56.194Z
Learning: In `atmos vendor pull --everything`, the `--everything` flag uses the TTY for TUI but is not interactive.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.golden
📚 Learning: 2025-01-19T15:49:15.593Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 955
File: tests/snapshots/TestCLICommands_atmos_validate_editorconfig_--help.stdout.golden:0-0
Timestamp: 2025-01-19T15:49:15.593Z
Learning: In future commits, the help text for Atmos CLI commands should be limited to only show component and stack parameters for commands that actually use them. This applies to the example usage section in command help text.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.golden
📚 Learning: 2025-10-10T23:51:36.597Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1599
File: internal/exec/terraform.go:394-402
Timestamp: 2025-10-10T23:51:36.597Z
Learning: In Atmos (internal/exec/terraform.go), when adding OpenTofu-specific flags like `--var-file` for `init`, do not gate them based on command name (e.g., checking if `info.Command == "tofu"` or `info.Command == "opentofu"`) because command names don't reliably indicate the actual binary being executed (symlinks, aliases). Instead, document the OpenTofu requirement in code comments and documentation, trusting users who enable the feature (e.g., `PassVars`) to ensure their terraform command points to an OpenTofu binary.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.goldenwebsite/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-12-13T04:37:25.223Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: cmd/root.go:0-0
Timestamp: 2025-12-13T04:37:25.223Z
Learning: In Atmos cmd/root.go Execute(), after cfg.InitCliConfig, we must call both toolchainCmd.SetAtmosConfig(&atmosConfig) and toolchain.SetAtmosConfig(&atmosConfig) so the CLI wrapper and the toolchain package receive configuration; missing either can cause nil-pointer panics in toolchain path resolution.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldentests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldencmd/toolchain/toolchain.go
📚 Learning: 2025-01-30T19:30:59.120Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 959
File: cmd/workflow.go:74-74
Timestamp: 2025-01-30T19:30:59.120Z
Learning: Error handling for `cmd.Usage()` is not required in the Atmos CLI codebase, as confirmed by the maintainer.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldencmd/root_helpers_test.go
📚 Learning: 2025-05-30T03:21:37.197Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1274
File: go.mod:63-63
Timestamp: 2025-05-30T03:21:37.197Z
Learning: The redis dependency (github.com/redis/go-redis/v9) in the atmos project is only used in tests, not in production code.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
📚 Learning: 2025-11-10T23:23:39.771Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: toolchain/registry/aqua/aqua_test.go:417-442
Timestamp: 2025-11-10T23:23:39.771Z
Learning: In Atmos toolchain AquaRegistry, tests should not hit real GitHub. Use the options pattern via WithGitHubBaseURL to inject an httptest server URL and make GetLatestVersion/GetAvailableVersions deterministic.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.goldencmd/toolchain/toolchain.go
📚 Learning: 2025-01-17T00:18:57.769Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 944
File: go.mod:206-206
Timestamp: 2025-01-17T00:18:57.769Z
Learning: For indirect dependencies with license compliance issues in the cloudposse/atmos repository, the team prefers to handle them in follow-up PRs rather than blocking the current changes, as these issues often require deeper investigation of the dependency tree.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
📚 Learning: 2024-10-31T19:25:41.298Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 727
File: internal/exec/terraform_clean.go:233-235
Timestamp: 2024-10-31T19:25:41.298Z
Learning: When specifying color values in functions like `confirmDeleteTerraformLocal` in `internal/exec/terraform_clean.go`, avoid hardcoding color values. Instead, use predefined color constants or allow customization through configuration settings to improve accessibility and user experience across different terminals and themes.
Applied to files:
pkg/ui/formatter.gocmd/root_helpers_test.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to **/*.go : Use colors from `pkg/ui/theme/colors.go` for all UI theming in Go code
Applied to files:
pkg/ui/formatter.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Use `ui.Write/Writef/Writeln()` and `ui.Success/Error/Warning/Info()` for human messages to stderr in Go commands
Applied to files:
pkg/ui/formatter.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Never use `fmt.Fprintf(os.Stdout/Stderr, ...)` or `fmt.Println()` for output - use `data.*` or `ui.*` functions instead
Applied to files:
pkg/ui/formatter.go
📚 Learning: 2025-12-21T04:10:29.030Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1891
File: internal/exec/describe_affected.go:468-468
Timestamp: 2025-12-21T04:10:29.030Z
Learning: In Go, package-level declarations (constants, variables, types, and functions) are visible to all files in the same package without imports. During reviews in cloudposse/atmos (and similar Go codebases), before suggesting to declare a new identifier, first check if it already exists in another file of the same package. If it exists, you can avoid adding a new declaration; if not, proceed with a proper package-level declaration.
Applied to files:
pkg/ui/formatter.gocmd/internal/registry_test.gocmd/toolchain/toolchain.gocmd/root_helpers_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Include integration tests for command flows and test CLI end-to-end when possible with test fixtures
Applied to files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Follow multi-provider registry pattern: define interface, implement per provider, register implementations, generate mocks - see `pkg/store/` example
Applied to files:
cmd/internal/registry_test.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to **/*_test.go : Prefer unit tests with mocks over integration tests - use interfaces and dependency injection for testability, generate mocks with `go.uber.org/mock/mockgen`, use table-driven tests, target >80% coverage
Applied to files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
📚 Learning: 2025-02-18T13:18:53.146Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1068
File: cmd/vendor_pull.go:31-31
Timestamp: 2025-02-18T13:18:53.146Z
Learning: Error checking is not required for cobra.Command.RegisterFlagCompletionFunc calls as these are static configurations done at init time.
Applied to files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
📚 Learning: 2025-12-10T18:32:43.260Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1808
File: cmd/terraform/backend/backend_delete_test.go:9-23
Timestamp: 2025-12-10T18:32:43.260Z
Learning: In cmd subpackages, tests should avoid using NewTestKit(t) unless tests actually interact with RootCmd (e.g., execute commands via RootCmd or modify RootCmd state). For structural tests that only verify command structure/flags without touching RootCmd, TestKit cleanup is unnecessary.
Applied to files:
cmd/internal/registry_test.gocmd/root_helpers_test.go
📚 Learning: 2025-12-13T04:37:40.435Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: cmd/toolchain/get.go:23-40
Timestamp: 2025-12-13T04:37:40.435Z
Learning: In Go CLI command files using Cobra, constrain the subcommand to accept at most one positional argument (MaximumNArgs(1)) so it supports both listing all items (zero args) and fetching a specific item (one arg). Define and parse flags with a standard parser (e.g., flags.NewStandardParser()) and avoid binding flags to Viper (no viper.BindEnv/BindPFlag). This promotes explicit argument handling and predictable flag behavior across command files.
Applied to files:
cmd/internal/registry_test.gocmd/toolchain/toolchain.gocmd/root_helpers_test.go
📚 Learning: 2025-02-03T05:57:18.407Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 959
File: cmd/cmd_utils.go:121-148
Timestamp: 2025-02-03T05:57:18.407Z
Learning: The Atmos CLI should fail fast (exit) when encountering configuration errors, including command alias configuration issues, to prevent undefined behavior. Use LogErrorAndExit instead of returning errors in such cases.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden
📚 Learning: 2025-09-13T18:06:07.674Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1466
File: toolchain/list.go:39-42
Timestamp: 2025-09-13T18:06:07.674Z
Learning: In the cloudposse/atmos repository, for UI messages in the toolchain package, use utils.PrintfMessageToTUI instead of log.Error or fmt.Fprintln(os.Stderr, ...). Import pkg/utils with alias "u" to follow the established pattern.
Applied to files:
tests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.goldencmd/toolchain/toolchain.go
📚 Learning: 2024-12-11T18:40:12.808Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 844
File: cmd/helmfile.go:37-37
Timestamp: 2024-12-11T18:40:12.808Z
Learning: In the atmos project, `cliConfig` is initialized within the `cmd` package in `root.go` and can be used in other command files.
Applied to files:
cmd/toolchain/toolchain.go
📚 Learning: 2025-11-10T03:03:31.505Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 0
File: :0-0
Timestamp: 2025-11-10T03:03:31.505Z
Learning: In the Atmos codebase, commands using the `StandardParser` flag pattern (from pkg/flags) do NOT need explicit `viper.BindPFlag()` calls in their code. The StandardParser encapsulates flag binding internally: flags are registered via `parser.RegisterFlags(cmd)` in init(), and bound via `parser.BindFlagsToViper(cmd, v)` in RunE, which internally calls viper.BindPFlag for each flag. This pattern is used throughout Atmos (e.g., cmd/toolchain/get.go, cmd/toolchain/info.go, cmd/toolchain/install.go, cmd/toolchain/path.go). Do not flag missing viper.BindPFlag calls when StandardParser is used.
Applied to files:
cmd/toolchain/toolchain.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to cmd/**/*.go : Use Cobra's recommended command structure with a root command and subcommands, implementing each command in a separate file under `cmd/` directory
Applied to files:
cmd/toolchain/toolchain.gocmd/root_helpers_test.go
📚 Learning: 2025-09-05T14:57:37.360Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 1448
File: cmd/ansible.go:26-28
Timestamp: 2025-09-05T14:57:37.360Z
Learning: The Atmos codebase uses a consistent pattern for commands that delegate to external tools: `PersistentFlags().Bool("", false, doubleDashHint)` where doubleDashHint provides help text about using double dashes to separate Atmos options from native command arguments. This pattern is used across terraform, packer, helmfile, atlantis, aws, and ansible commands.
Applied to files:
cmd/toolchain/toolchain.go
📚 Learning: 2024-12-11T18:46:02.483Z
Learnt from: Listener430
Repo: cloudposse/atmos PR: 844
File: cmd/terraform.go:39-39
Timestamp: 2024-12-11T18:46:02.483Z
Learning: `cliConfig` is initialized in `cmd/root.go` and can be used across the `cmd` package.
Applied to files:
cmd/toolchain/toolchain.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to cmd/**/*.go : Provide comprehensive help text for all commands and flags, include examples in command help, and follow Go's documentation conventions in Cobra command definitions
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Every new feature must include comprehensive unit tests targeting >80% code coverage for all packages
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to **/*.go : Keep files small and focused - under 600 lines with one cmd/impl per file, co-locate tests, never use `//revive:disable:file-length-limit`
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to cmd/**/*_test.go : Always use `cmd.NewTestKit(t)` for cmd tests to auto-clean RootCmd state
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to cmd/**/*.go : Provide meaningful feedback to users and include progress indicators for long-running operations in CLI commands
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2024-11-01T14:45:32.417Z
Learnt from: RoseSecurity
Repo: cloudposse/atmos PR: 757
File: cmd/docs.go:52-54
Timestamp: 2024-11-01T14:45:32.417Z
Learning: In `cmd/docs.go`, capping the terminal width at 120 columns is considered acceptable and preferred after testing.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-02-03T06:00:11.419Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 959
File: cmd/describe_config.go:20-20
Timestamp: 2025-02-03T06:00:11.419Z
Learning: Commands should use `PrintErrorMarkdownAndExit` with empty title and suggestion (`"", err, ""`) for general error handling. Specific titles like "Invalid Usage" or "File Not Found" should only be used for validation or specific error scenarios.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-24T17:35:37.209Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: .cursor/rules/atmos-rules.mdc:0-0
Timestamp: 2025-11-24T17:35:37.209Z
Learning: Applies to **/*_test.go : Use table-driven tests for testing multiple scenarios in Go
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2024-10-23T21:36:40.262Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 740
File: cmd/cmd_utils.go:340-359
Timestamp: 2024-10-23T21:36:40.262Z
Learning: In the Go codebase for Atmos, when reviewing functions like `checkAtmosConfig` in `cmd/cmd_utils.go`, avoid suggesting refactoring to return errors instead of calling `os.Exit` if such changes would significantly increase the scope due to the need to update multiple call sites.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-05-23T19:51:47.091Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1255
File: cmd/describe_affected_test.go:15-15
Timestamp: 2025-05-23T19:51:47.091Z
Learning: The atmos codebase has a custom extension to *testing.T that provides a Chdir method, allowing test functions to call t.Chdir() to change working directories during tests. This is used consistently across test files in the codebase.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-06-07T19:28:21.289Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1266
File: cmd/describe_affected.go:0-0
Timestamp: 2025-06-07T19:28:21.289Z
Learning: In the Atmos codebase, using panic for unsupported flag types in flag processing functions like setDescribeAffectedFlagValueInCliArgs is the expected behavior rather than returning errors. This pattern is preferred for developer errors when unsupported types are added to the flagsKeyValue map.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-08-15T14:43:41.030Z
Learnt from: aknysh
Repo: cloudposse/atmos PR: 1352
File: pkg/store/artifactory_store_test.go:108-113
Timestamp: 2025-08-15T14:43:41.030Z
Learning: In test files for the atmos project, it's acceptable to ignore errors from os.Setenv/Unsetenv operations during test environment setup and teardown, as these are controlled test scenarios.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-05-23T19:51:47.091Z
Learnt from: samtholiya
Repo: cloudposse/atmos PR: 1255
File: cmd/describe_affected_test.go:15-15
Timestamp: 2025-05-23T19:51:47.091Z
Learning: In the atmos codebase, t.Chdir() is a valid method call on *testing.T objects and works correctly for changing directories in tests. This is implemented through custom testing framework extensions and is used consistently throughout the test suite.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-11T03:47:45.878Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: toolchain/add_test.go:67-77
Timestamp: 2025-11-11T03:47:45.878Z
Learning: In the cloudposse/atmos codebase, tests should prefer t.Setenv for environment variable setup/teardown instead of os.Setenv/Unsetenv to ensure test-scoped isolation.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-11T03:47:59.576Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: toolchain/which_test.go:166-223
Timestamp: 2025-11-11T03:47:59.576Z
Learning: In the cloudposse/atmos repo, tests that manipulate environment variables should use testing.T.Setenv for automatic setup/teardown instead of os.Setenv/Unsetenv.
Applied to files:
cmd/root_helpers_test.go
📚 Learning: 2025-11-08T19:56:18.660Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1697
File: internal/exec/oci_utils.go:0-0
Timestamp: 2025-11-08T19:56:18.660Z
Learning: In the Atmos codebase, when a function receives an `*schema.AtmosConfiguration` parameter, it should read configuration values from `atmosConfig.Settings` fields rather than using direct `os.Getenv()` or `viper.GetString()` calls. The Atmos pattern is: viper.BindEnv in cmd/root.go binds environment variables → Viper unmarshals into atmosConfig.Settings via mapstructure → business logic reads from the Settings struct. This provides centralized config management, respects precedence, and enables testability. Example: `atmosConfig.Settings.AtmosGithubToken` instead of `os.Getenv("ATMOS_GITHUB_TOKEN")` in functions like `getGHCRAuth` in internal/exec/oci_utils.go.
Applied to files:
docs/prd/experimental-features-system.md
📚 Learning: 2025-12-13T06:07:34.794Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: docs/prd/tool-dependencies-integration.md:58-64
Timestamp: 2025-12-13T06:07:34.794Z
Learning: For docs in the cloudposse/atmos repository under docs/prd/, markdownlint issues MD040, MD010, and MD034 should be deferred to a separate documentation cleanup commit and must not block the current PR. If needed, address these issues in a follow-up PR dedicated to documentation improvements.
Applied to files:
docs/prd/experimental-features-system.md
📚 Learning: 2026-01-04T00:55:21.720Z
Learnt from: CR
Repo: cloudposse/atmos PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-04T00:55:21.720Z
Learning: Applies to website/docs/cli/commands/**/*.mdx : All CLI command documentation MUST include: frontmatter, Intro component, Screengrab, Usage section, Arguments/Flags in `<dl>` format, and Examples section
Applied to files:
website/docs/cli/configuration/settings/experimental.mdx
📚 Learning: 2025-12-13T06:07:37.766Z
Learnt from: osterman
Repo: cloudposse/atmos PR: 1686
File: docs/prd/tool-dependencies-integration.md:58-64
Timestamp: 2025-12-13T06:07:37.766Z
Learning: cloudposse/atmos: For PRD docs (docs/prd/*.md), markdownlint issues like MD040/MD010/MD034 can be handled in a separate documentation cleanup commit and should not block the current PR.
Applied to files:
website/docs/experimental.mdx
🧬 Code graph analysis (2)
pkg/ui/formatter.go (1)
pkg/ui/theme/icons.go (1)
IconExperimental(13-13)
cmd/internal/registry_test.go (3)
pkg/runner/runner.go (1)
Run(74-107)pkg/ui/formatter.go (1)
Reset(73-80)cmd/internal/registry.go (4)
Reset(266-271)Register(50-61)IsCommandExperimental(218-224)RegisterAll(85-189)
🪛 LanguageTool
docs/prd/experimental-features-system.md
[style] ~181-~181: Using four (or more) nouns in a row may decrease readability.
Context: ...-------------| | atmos devcontainer | Development container lifecycle management | | atmos toolchain | Tool version ma...
(FOUR_NN)
[typographical] ~235-~235: To join two clauses or introduce examples, consider using an em dash.
Context: ...patible ## Testing 1. silence mode - Verify no output, command executes 2. **...
(DASH_RULE)
[typographical] ~236-~236: To join two clauses or introduce examples, consider using an em dash.
Context: ...ut, command executes 2. disable mode - Verify error returned, command does not ...
(DASH_RULE)
[typographical] ~237-~237: To join two clauses or introduce examples, consider using an em dash.
Context: ...ommand does not execute 3. warn mode - Verify warning shown, command executes 4...
(DASH_RULE)
[typographical] ~238-~238: To join two clauses or introduce examples, consider using an em dash.
Context: ...hown, command executes 4. error mode - Verify warning shown, error returned 5. ...
(DASH_RULE)
[typographical] ~239-~239: To join two clauses or introduce examples, consider using an em dash.
Context: ...eturned 5. Non-experimental commands - Verify unaffected by settings ## Relate...
(DASH_RULE)
[typographical] ~243-~243: To join two clauses or introduce examples, consider using an em dash.
Context: ...ry Pattern](command-registry-pattern.md) - How commands register with Atmos - [Erro...
(DASH_RULE)
[typographical] ~244-~244: To join two clauses or introduce examples, consider using an em dash.
Context: ...ng Strategy](error-handling-strategy.md) - How errors are formatted and returned
(DASH_RULE)
website/docs/cli/configuration/settings/experimental.mdx
[style] ~139-~139: Using four (or more) nouns in a row may decrease readability.
Context: ... Devcontainers | atmos devcontainer | Development container lifecycle management | | Toolchain | atmos toolchain | Too...
(FOUR_NN)
[typographical] ~187-~187: To join two clauses or introduce examples, consider using an em dash.
Context: ...- Experimental Features - What "experimental" means and how to pro...
(DASH_RULE)
[typographical] ~187-~187: Consider using typographic quotation marks here.
Context: ...imental Features](/experimental) - What "experimental" means and how to provide feedback - [Se...
(EN_QUOTES)
[typographical] ~188-~188: To join two clauses or introduce examples, consider using an em dash.
Context: ... Settings - Overview of all settings - [Devcontainer...
(DASH_RULE)
[typographical] ~189-~189: To join two clauses or introduce examples, consider using an em dash.
Context: ...vcontainers](/cli/commands/devcontainer) - Experimental devcontainer support
(DASH_RULE)
website/docs/experimental.mdx
[typographical] ~18-~18: Consider using typographic quotation marks here.
Context: ...xtreme circumstances. ## What "Experimental" Means Features marked as experimental:...
(EN_QUOTES)
[style] ~22-~22: To form a complete sentence, be sure to include a subject.
Context: ... Features marked as experimental: - May not be fully functional - Some docume...
(MISSING_IT_THERE)
[typographical] ~22-~22: To join two clauses or introduce examples, consider using an em dash.
Context: ...ntal: - May not be fully functional - Some documented functionality may not ye...
(DASH_RULE)
[typographical] ~23-~23: To join two clauses or introduce examples, consider using an em dash.
Context: ...ented - Are under active development - Features are being refined and validated...
(DASH_RULE)
[typographical] ~24-~24: To join two clauses or introduce examples, consider using an em dash.
Context: ...feedback - May have breaking changes - APIs or behavior might change without fo...
(DASH_RULE)
[typographical] ~25-~25: To join two clauses or introduce examples, consider using an em dash.
Context: ... May not have undergone extensive QA - Testing coverage may be limited, and edg...
(DASH_RULE)
[typographical] ~26-~26: To join two clauses or introduce examples, consider using an em dash.
Context: ...nded for critical production workflows** - Use at your own risk until they graduate...
(DASH_RULE)
[style] ~90-~90: Consider using polite language here.
Context: ... feature working really well for you? Let us know! Your feedback helps us prioritize wh...
(INSERT_PLEASE)
[typographical] ~98-~98: To join two clauses or introduce examples, consider using an em dash.
Context: ...lack) ## Related - Roadmap - View our product roadmap - [Changelog](/...
(DASH_RULE)
[typographical] ~99-~99: To join two clauses or introduce examples, consider using an em dash.
Context: ...roduct roadmap - Changelog - View recent changes and releases
(DASH_RULE)
🪛 markdownlint-cli2 (0.18.1)
docs/prd/experimental-features-system.md
81-81: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
171-171: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Acceptance Tests (windows)
- GitHub Check: Acceptance Tests (linux)
- GitHub Check: Summary
🔇 Additional comments (36)
cmd/root_helpers_test.go (10)
851-891: Solid coverage for color profile conversion.Table-driven tests cover all terminal color profile mappings including the unknown/default case. This aligns well with the experimental feature rendering needs.
893-1021: Comprehensive experimental parent detection tests.Good coverage of the two-pass approach documented in the comment. Tests include nil command, non-experimental, annotation-based, parent inheritance, deeply nested hierarchies, and edge cases like
experimental: "false"annotation.One observation: the "deeply nested" test expects
"parent"(nearest experimental ancestor), which matches the function's documented behavior of finding the "nearest" experimental parent.
1023-1063: Good edge case coverage for--use-versionparsing.Tests cover both
--use-version=valueand--use-version valueformats, plus the edge case of trailing--use-versionwithout a value.
1065-1125: Flag description builder tests look solid.Covers various default value scenarios: empty, string, false boolean, zero integer, and empty array. Each case verifies the expected content in the rendered description.
1127-1164: Wrapped line rendering tests are adequate.Tests empty, single, and multiple line scenarios with proper indent handling.
1166-1219: Viper sync tests cover the key scenarios.Tests profile slice flag, identity string flag, and unchanged flags. Each test properly resets viper state.
1221-1275: Early color profile configuration tests are reasonable.Covers
NO_COLORenv var,--no-colorflag, and--force-colorflag scenarios. Tests verify no panic occurs, which is appropriate for this configuration step.
1277-1374: Flag name formatting tests are thorough.Good coverage of bool flags (with/without shorthand), string/int flags, and the
stringSlice→stringstype transformation. The alignment spacing (-v, --verbosevs--help) is properly tested.
1376-1438: Terminal width and flag rendering tests provide basic coverage.
TestGetTerminalWidthverifies bounds (positive and ≤120).TestCalculateMaxFlagWidthverifies hidden flags are excluded.TestRenderFlagsNilFlagSetis a good defensive test.
1440-1547: Experimental mode handling tests are well-structured.Good use of
NewTestKit(t)per coding guidelines. Tests cover all four modes:silence,disable,warn,error, plus empty default. The exit-via-panic pattern for testingos.Exitpaths is clean.Minor note: the test properly cleans up with
defer RootCmd.RemoveCommand(testCmd)to avoid polluting other tests.cmd/internal/registry_test.go (6)
53-56: Good addition ofIsExperimental()to mock provider.Returning
falseas the default makes the mock behave like a standard non-experimental command.
580-588: Clean mock implementation for experimental providers.Embedding
mockCommandProviderand overriding onlyIsExperimental()keeps the test code DRY.
589-653: Thorough tests formarkCommandExperimental.Covers single command, nil annotations, existing annotations, and recursive marking of nested subcommands. The test at line 634 verifying all four commands (
parent,child1,child2,grandchild) are marked is particularly valuable.
655-666: Useful recursive helper for test assertions.
findCommandByNamecleanly traverses the command tree. Keeping it in the test file rather than exporting it is appropriate.
668-722:IsCommandExperimentaltests cover the key paths.Non-existent command, non-experimental provider, and experimental provider scenarios are all verified. Each test case properly calls
Reset()in setup.
724-772: Integration test forRegisterAllmarking behavior.This ties everything together: verifies regular commands aren't marked, experimental commands are marked, and subcommands inherit the experimental annotation. Good end-to-end verification of the registry flow.
pkg/ui/formatter.go (4)
336-355: LGTM!Clean implementation following the established pattern. Good documentation and proper error propagation from
getFormatter().
522-534: LGTM!Color support check correctly implemented. Graceful fallback to
[text]format when colors unavailable.
902-915: LGTM!Good use of
theme.IconExperimentalconstant. The conditional message formatting handles both named and anonymous experimental features cleanly. Error discarding fromtoastMarkdownis consistent with other semantic formatting methods.
389-414: Theme styling and fallbacks look good.ExperimentalBadge is properly defined in
pkg/ui/theme/styles.goand uses theme colors (yellow background, dark foreground) as intended. Documentation comments are complete and follow Go conventions, imports are properly organized, and the fallback behavior handles missing formatters correctly.tests/snapshots/TestCLICommands_atmos_toolchain_install_non-existent_tool.stderr.golden (2)
1-3: New experimental feature notices look good.The telemetry and experimental feature warnings align with the PR's goal of adding transparency for experimental features. These lines are clearly generated output captured by the snapshot.
4-6: Themailto:prefix is from output rendering, not code.The "Install failed" message in
toolchain/install.gois formatted correctly. Themailto:prefix appears when the CLI output is rendered (likely a markdown renderer interpreting the@symbol as an email pattern). This isn't a source code bug. The snapshot file correctly captures the actual CLI output, so no manual edits are needed—regenerate with-regenerate-snapshotsif display changes are required.tests/snapshots/TestCLICommands_atmos_toolchain_info_tar.gz_format_tool.stderr.golden (1)
1-3: LGTM!Snapshot correctly captures the new telemetry and experimental feature notices. This aligns with the broader PR changes marking
toolchainas experimental.website/docs/cli/configuration/settings/experimental.mdx (4)
1-36: Well-structured documentation.Clear introduction of the experimental feature system with proper frontmatter and component imports. The configuration example is concise and accurate.
38-111: Comprehensive mode documentation.Each behavior mode is clearly explained with configuration examples and expected output. The default mode (
warn) is properly highlighted.
149-189: Practical use case examples.Good guidance for development, CI/CD, and production environments. The mode recommendations are sensible.
133-147: The experimental features table is complete and accurate. All 5 documented features exist in the codebase and properly marked as experimental (either viaIsExperimental()methods for Toolchain and Devcontainers, or Cobra annotations for Backend Provisioning, Workdir Management, and Affected Components).cmd/toolchain/toolchain.go (2)
39-47: Good defensive initialization.Calling root's
PersistentPreRunensures experimental mode handling runs properly. The comment explainingcmd.Root()vscmd.Parent()is helpful.
188-192: LGTM!Clean
IsExperimental()implementation marking the toolchain command as experimental. Consistent with other command providers in this PR.tests/snapshots/TestCLICommands_atmos_toolchain_info_raw_format_tool.stderr.golden (1)
1-3: LGTM!Snapshot correctly captures telemetry and experimental notices. Consistent with other toolchain snapshots.
docs/prd/experimental-features-system.md (4)
1-58: Solid PRD structure.Clear problem statement, design principles, and configuration documentation. The behavior modes table is a good reference.
59-125: Clear architecture documentation.The execution flow diagram effectively communicates the mode handling logic. Interface extension is well-documented.
127-211: Good implementation guidance.The distinction between top-level command
IsExperimental()and subcommand Cobra annotations is clearly explained.
241-244: Both referenced documents exist indocs/prd/and follow the kebab-case naming requirement.website/docs/experimental.mdx (2)
1-45: Clear, user-friendly framing.
Nice structure and messaging; the intro and definition set expectations well.
58-86: Notification and mode documentation is accurate. All details align with the CLI implementation—the example message text, four modes (silence, warn, error, disable), environment variable ATMOS_EXPERIMENTAL, and default "warn" setting all match the codebase. No sync issues found.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
tests/snapshots/TestCLICommands_atmos_toolchain_info_shows_atmos-inline_registry.stderr.golden
Show resolved
Hide resolved
|
Warning Release Documentation RequiredThis PR is labeled
|
what
<Experimental />badge component for marking features as experimental<FirstReleased />badge component for version trackingATMOS_EXPERIMENTALenvironment variable andsettings.experimentalconfigterraform backend,terraform workdir, andtoolchaincommands as experimentalwhy
Provide users with clear visibility into feature maturity to set expectations.
Experimental features may change APIs, need community feedback, or lack stability
guarantees. This change aligns with the project's commitment to transparency.
Users can now control how experimental features behave:
silence- Run without notificationwarn- Show notification, continue (default)error- Show notification, exit with errordisable- Block experimental commands entirelyreferences
Summary by CodeRabbit
New Features
Documentation
Configuration
✏️ Tip: You can customize this high-level summary in your review settings.