Development Workflow Rules
File: docs/rules-development-workflow.md
Purpose: Define how to work with the urbalurba-infrastructure codebase, including file operations, command execution, and project standards
Target Audience: All contributors and AI assistants working with the repository
Last Updated: October 3, 2025
⚠️ CRITICAL: All paths in this document and throughout the project are relative to the repository root unless explicitly stated otherwise.
Repository Root: /Users/terje.christensen/learn/redcross-public/urbalurba-infrastructure/
Rules
There are many rules to follow read docs/rules-readme.md for an overview. Or just all docs/rules-*.md
Path Convention
When paths are referenced anywhere in this project:
✅ Correct: manifests/030-prometheus-config.yaml
✅ Correct: ansible/playbooks/030-setup-prometheus.yml
✅ Correct: docs/rules-development-workflow.md
❌ Wrong: /Users/terje.christensen/learn/redcross-public/urbalurba-infrastructure/manifests/030-prometheus-config.yaml
Exception: Absolute paths are only used when referring to external locations or when explicitly needed for clarity.
Two Development Workflows
Depending on who is working (AI assistant vs. human developer), there are different workflows:
Workflow A: Claude Code (AI Assistant)
Used when: Claude Code AI assistant is performing tasks
Characteristics:
- Claude operates directly on the Mac host filesystem
- No manual file synchronization required
- Faster iteration and immediate feedback
Operations:
-
File Operations (Read/Write/Edit)
Claude writes directly to:
/Users/terje.christensen/learn/redcross-public/urbalurba-infrastructure/
Examples:
- Create: manifests/036-grafana-sovdev-verification.yaml
- Edit: ansible/playbooks/030-setup-prometheus.yml
- Read: docs/rules-development-workflow.md -
kubectl Commands (Direct on Mac)
kubectl get pods -n monitoring
kubectl apply -f manifests/036-grafana-sovdev-verification.yaml
kubectl logs -n monitoring -l app=grafana -
Ansible Playbooks (Via provision-host container)
docker exec provision-host bash -c "cd /mnt/urbalurbadisk/provision-host/kubernetes/11-monitoring/not-in-use && ./01-setup-prometheus.sh rancher-desktop" -
Verification (Multiple methods)
- kubectl on Mac
- File reads on Mac
- Container commands when needed
- Direct curl/API calls from Mac
Advantages:
- ✅ No manual sync step
- ✅ Immediate feedback
- ✅ All changes in git repository
- ✅ Can iterate quickly
Limitations:
- Ansible playbooks must still run in provision-host container
- Some Ansible tasks require container context
Workflow B: Manual (Human Developer)
Used when: Human developer is working directly with files and commands
Characteristics:
- Manual file synchronization required
- Work done both on Mac and in provision-host container
- More explicit control over each step
Step-by-Step Process:
1. Edit Files on Mac
# Work in repository root
cd /Users/terje.christensen/learn/redcross-public/urbalurba-infrastructure
# Edit files with your editor
vim manifests/030-prometheus-config.yaml
code ansible/playbooks/030-setup-prometheus.yml
2. Sync Files to provision-host Container
# CRITICAL: Run after ANY file change
./copy2provisionhost.sh
This copies changed files from Mac to /mnt/urbalurbadisk/ in the provision-host container.
3. Execute Scripts in provision-host Container
# Enter container
docker exec -it provision-host bash
# You'll be at: ansible@lima-rancher-desktop:/mnt/urbalurbadisk
# Navigate to scripts directory
cd provision-host/kubernetes/11-monitoring/not-in-use
# Run setup scripts
./01-setup-prometheus.sh rancher-desktop
4. Verify with kubectl (Mac or Container)
# On Mac
kubectl get pods -n monitoring
# Or in container
kubectl get pods -n monitoring
5. Update Documentation and Sync Again
# On Mac
vim docs/rules-development-workflow.md
# Sync changes
./copy2provisionhost.sh
Common Mistake:
❌ Editing files and forgetting to run ./copy2provisionhost.sh
✅ Always sync after every file change
Directory Structure
Mac Host:
/Users/terje.christensen/learn/redcross-public/urbalurba-infrastructure/
├── manifests/ # Kubernetes manifests (Helm values, ConfigMaps, IngressRoutes)
├── ansible/
│ └── playbooks/ # Ansible playbooks for automation