Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/docs/components/ansible.mdx`:
- Line 72: Update the sentence "Command line flags take precedence over stack
manifest settings:" to hyphenate "command-line" (i.e., change it to
"Command-line flags take precedence over stack manifest settings:") to fix the
minor grammar issue in the ansible.mdx content.
- Around line 28-32: The docs show "command: ansible" but the ansible playbook
flow delegates to the ansible-playbook binary; update the example and any
schema/defaults to "command: ansible-playbook" to match the actual delegated
binary used by the playbook runner (verify references such as the ansible
playbook handler in code like AnsiblePlaybook, any ansible.go execution strings,
and the other docs file command.mdx) so examples and defaults align with the
real binary.

In `@website/docs/stacks/command.mdx`:
- Around line 165-172: The docs currently imply ansible.command in
_defaults.yaml applies to all Ansible invocations but the code path that runs
playbooks hardcodes the binary name (the playbook execution in executor.go that
invokes "ansible-playbook"), so update the documentation to state that
ansible.command only affects non-playbook subcommands and does not change the
binary used for atmos ansible playbook; advise two practical remedies: set
ansible.command to the full path of the ansible-playbook binary (e.g.,
/opt/venv/bin/ansible-playbook), or use a wrapper/symlink inside the virtualenv
to expose ansible-playbook at the expected name, or note that changing the
playbook behavior requires modifying the playbook invocation in executor.go to
use the configured ansible.command.

In `@website/docs/stacks/components/ansible.mdx`:
- Around line 196-200: Update the example and/or explanatory text around the
`<context>-<component>.ansible.vars.yaml` naming line to clarify that
`<context>` is the full Atmos context string (e.g., `acme-plat-prod-us-east-1`),
not just the short stack name; either change the example
`prod-webserver.ansible.vars.yaml` to a representative one like
`acme-plat-prod-us-east-1-webserver.ansible.vars.yaml` or add a parenthetical
explaining what `<context>` resolves to, and ensure the doc line referencing
`<context>-<component>.ansible.vars.yaml` is updated accordingly.

---

Nitpick comments:
In `@website/docs/cli/configuration/components/ansible.mdx`:
- Around line 68-87: The "Example Configuration" section duplicates the earlier
"Configuration" YAML for the ansible component; remove the duplicate YAML block
under the "Example Configuration" heading or replace it with a more
realistic/extended example. Locate the ansible component YAML (the block showing
components: ansible: command: ansible base_path: components/ansible) and either
delete the repeated block or expand it to show additional realistic keys (e.g.,
env vars, inventory path, extra_args) and adjust the subsequent example commands
(the atmos ansible playbook/version snippets) to match the extended example.
Ensure only one authoritative configuration example for the ansible component
remains and the headings remain consistent.

In `@website/docs/components/ansible.mdx`:
- Around line 1-6: The Ansible docs frontmatter is missing the SEO/tooltip
`description` field; add a `description: "..."` entry to the MDX frontmatter
block at the top of ansible.mdx (alongside title, sidebar_position,
sidebar_label, id) with a short summary of the page (a one-sentence description)
so it matches other component docs like components.mdx and enables consistent
SEO and sidebar tooltips.

In `@website/docs/stacks/components/ansible.mdx`:
- Line 11: Remove the unused import of the EmbedFile component by deleting the
line that imports EmbedFile (the "import EmbedFile from
'@site/src/components/EmbedFile'" statement) since no <EmbedFile> element is
used in the document; if you intended to embed a file, instead add the
corresponding <EmbedFile .../> usage where required, otherwise simply remove the
import to clean up the module.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/exec/describe_component.go`:
- Around line 447-459: The code currently only falls back to Ansible when Packer
returns errUtils.ErrInvalidComponent; change the gate so any Packer failure will
attempt the Ansible path. In the block around tryProcessWithComponentType use
baseParams (baseParams.configAndStacksInfo/result and baseParams.componentType =
cfg.AnsibleComponentType) and call tryProcessWithComponentType(&baseParams)
regardless of whether errors.Is(err, errUtils.ErrInvalidComponent) (i.e., remove
or invert that conditional); keep the existing handling that on an Ansible error
you set result.ComponentSection[cfg.ComponentTypeSectionName] = "" and return
the error.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@internal/exec/describe_stacks_test.go`:
- Around line 226-243: Test is missing an assertion for the dev component's
app_port; add a call to u.EvaluateYqExpression(&atmosConfig, stacksMap,
".dev.components.ansible.hello-world.vars.app_port"), assert the error is nil,
and assert the returned value equals the expected dev port (e.g. 80) using the
same pattern as the existing dev and prod assertions to mirror the prod app_port
check.