34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
# Workspace Conventions
|
|
|
|
These conventions apply to all work in this workspace. Read the specialized
|
|
policy for the work being performed as well:
|
|
|
|
- Read [the Ansible house style](ansible.md) before designing, implementing,
|
|
or reviewing Ansible roles or collections, including their configuration
|
|
interfaces.
|
|
- Read [the testing house style](testing.md) before creating, changing,
|
|
reviewing, or auditing tests.
|
|
- Read [the planning policy](planning.md) before preparing or managing a
|
|
feature roadmap, implementation plan, or active work stream.
|
|
|
|
## Workspace-Wide Conventions
|
|
|
|
- Confirm the target repository before editing; never treat this directory as
|
|
a monorepo.
|
|
- Inspect the relevant upstream application before designing or changing its
|
|
Ansible role.
|
|
- Keep standalone application roles independently usable. Cross-application
|
|
policy belongs in `ansible-role-dnd-pipeline` and is exposed to consumers as
|
|
`rakestraw.dnd.pipeline`.
|
|
- Prefer codebase-memory graph tools for code discovery. Use text/file search
|
|
for documentation, configuration, literals, or when the graph is
|
|
insufficient.
|
|
- Preserve unrelated and pre-existing working-tree changes in every
|
|
repository.
|
|
- Never place credentials or secret values in plans, examples, inventory, or
|
|
tests.
|
|
- Validate changes in the repository that owns them and report the commands
|
|
run.
|
|
- Do not duplicate an application contract in workspace documentation when a
|
|
link and a concise deployment consequence are sufficient.
|