General Development Guidelines

Task-First Development (CRITICAL)

  • MUST use tasks for all regular commands - See command-execution.md for details
  • If you regularly execute a command, it MUST be in a Taskfile
  • Adding commands to Taskfiles means complexities can be reused and time saved
  • Before running any command, check if a task exists: task --list

Package Management

  • Use Homebrew to install packages on macOS

Infrastructure as Code

  • All infrastructure is code - Manual changes to k8s resources must be reflected back in code
  • If scripting is necessary in Kubernetes resources (like AnalysisTemplates), it should be in separate Python/shell files and included via ConfigMaps, not embedded inline in YAML
  • Do not introduce unnecessary complexity by supporting “backwards compatibility” when a component is solely within this repo (e.g., helm ingress)
    • Support the new feature, keep it simple, and migrate any existing uses to the new structure

Communication Standards

  • Always include full URLs when referencing PRs, issues, or actions - Never mention “PR #43” without the link (e.g., https://github.com/owner/repo/pull/43)
  • This applies to GitHub PRs, issues, action runs, and any other web-linkable resources
  • The user should be able to click through to any referenced resource without having to look it up

Documentation Standards

  • Do not create unnecessary .md files
  • Useful information should either be in:
    • The appropriate spec (requirements.md, design.md, tasks.md)
    • The appropriate README.md
  • Keep documentation close to the code it describes

Spec Management

  • Don’t create new spec folders without confirming - New requirements are often part of an existing spec
  • When reviewing new requirements:
    • Ensure existing requirements for the spec are understood
    • Modify existing requirements where applicable rather than adding new ones
    • Only change requirements if the outcomes themselves are changing
  • Requirements should be generic and focus on outcomes - Do not include implementation-specific details
  • Any component we write a spec for should consider how it’s tested

Testing Standards

  • Code must NOT include mock data, except in unit tests
  • See testing-standards.md for comprehensive testing guidelines

Lab Environment

  • The lab k8s cluster is managed by Proxmox
  • Should be regularly tested by:
    1. Reverting to a clean state
    2. Before ArgoCD is installed
    3. Running the init task: task seed:_init