295 lines
4.1 KiB
Markdown
295 lines
4.1 KiB
Markdown
# `/context/development-context.md`
|
|
|
|
# Development Environment Context
|
|
|
|
This document describes the preferred development workflow, tools, standards, and technology choices used by RDB Solutions Ltd.
|
|
|
|
AI coding assistants, IDE agents, and autonomous development tools should read this file before making recommendations or changes.
|
|
|
|
---
|
|
|
|
# Primary Development Workstation
|
|
|
|
## MacBook Pro (Intel)
|
|
|
|
Primary software development machine.
|
|
|
|
Typical activities:
|
|
|
|
- Application development
|
|
- Repository management
|
|
- Code reviews
|
|
- Testing
|
|
- Infrastructure administration
|
|
- LLM-assisted development
|
|
|
|
---
|
|
|
|
# Source Control
|
|
|
|
## Gitea
|
|
|
|
Primary Git platform.
|
|
|
|
Preferences:
|
|
|
|
- Gitea is the source of truth.
|
|
- Do not assume GitHub is available.
|
|
- Do not recommend GitHub-specific workflows unless explicitly requested.
|
|
- Pull Requests should be used for significant changes.
|
|
- Commit messages should be clear and descriptive.
|
|
|
|
Preferred commit style:
|
|
|
|
```text
|
|
feat: add VM status endpoint
|
|
|
|
fix: correct Jenkins deployment script
|
|
|
|
docs: update infrastructure documentation
|
|
```
|
|
|
|
---
|
|
|
|
# CI/CD
|
|
|
|
## Jenkins
|
|
|
|
Primary automation platform.
|
|
|
|
Current and future responsibilities:
|
|
|
|
- Build applications
|
|
- Run tests
|
|
- Build Docker images
|
|
- Deploy services
|
|
- Run scheduled maintenance tasks
|
|
- Execute agent-generated work after review
|
|
|
|
Preferred pipeline behaviour:
|
|
|
|
1. Pull code from Gitea
|
|
2. Run validation
|
|
3. Run tests
|
|
4. Build artefacts
|
|
5. Deploy to target environment
|
|
|
|
Agents should favour Jenkins automation over manual deployment procedures.
|
|
|
|
---
|
|
|
|
# Containerisation
|
|
|
|
## Docker
|
|
|
|
Preferred deployment format.
|
|
|
|
Goals:
|
|
|
|
- Consistent environments
|
|
- Easier deployment
|
|
- Simpler rollback
|
|
- Portable services
|
|
|
|
When proposing software:
|
|
|
|
Prefer:
|
|
|
|
- Docker Compose
|
|
- Single-container deployments
|
|
- Simple architecture
|
|
|
|
Avoid:
|
|
|
|
- Kubernetes unless there is a clear requirement.
|
|
|
|
---
|
|
|
|
# Database Platforms
|
|
|
|
## PostgreSQL
|
|
|
|
Preferred database platform.
|
|
|
|
Current implementation:
|
|
|
|
- Supabase-hosted PostgreSQL
|
|
|
|
Preferred characteristics:
|
|
|
|
- Relational data model
|
|
- Strong typing
|
|
- Auditable schema changes
|
|
|
|
---
|
|
|
|
# IDEs and Editors
|
|
|
|
Current tools may include:
|
|
|
|
- VS Code
|
|
- Cursor
|
|
- Claude Code
|
|
- OpenWebUI
|
|
- Browser-based assistants
|
|
|
|
Recommendations should remain editor-agnostic where possible.
|
|
|
|
---
|
|
|
|
# Local LLM Infrastructure
|
|
|
|
## Ollama
|
|
|
|
Primary local inference platform.
|
|
|
|
Purpose:
|
|
|
|
- Local coding assistance
|
|
- Experimentation
|
|
- Agent backends
|
|
- Development support
|
|
|
|
## Available Hardware
|
|
|
|
LLM Server:
|
|
|
|
- RTX 5070 Ti
|
|
- 16 GB VRAM
|
|
- 32 GB RAM
|
|
|
|
Agents should assume local inference is available.
|
|
|
|
---
|
|
|
|
# Preferred Models
|
|
|
|
Potential models include:
|
|
|
|
- Qwen Coder
|
|
- Qwen3
|
|
- DeepSeek Coder
|
|
- Future coding-focused local models
|
|
|
|
Model selection should prioritise:
|
|
|
|
1. Code quality
|
|
2. Reasoning ability
|
|
3. Low operational cost
|
|
4. Local execution
|
|
|
|
---
|
|
|
|
# AI-Assisted Development
|
|
|
|
RDB actively uses AI-assisted development.
|
|
|
|
Expected uses:
|
|
|
|
- Code generation
|
|
- Refactoring
|
|
- Documentation
|
|
- Testing
|
|
- Architecture review
|
|
- Infrastructure planning
|
|
|
|
Agents should produce:
|
|
|
|
- Small reviewable changes
|
|
- Clear reasoning
|
|
- Minimal surprises
|
|
|
|
Avoid:
|
|
|
|
- Massive rewrites
|
|
- Unrequested architecture changes
|
|
- Hidden behaviour
|
|
|
|
---
|
|
|
|
# Task Management
|
|
|
|
Preferred approach:
|
|
|
|
Backlog-driven development.
|
|
|
|
Work should be decomposed into:
|
|
|
|
- Small tasks
|
|
- Independent tasks
|
|
- Reviewable tasks
|
|
|
|
Good example:
|
|
|
|
```text
|
|
TASK-001
|
|
Create API endpoint for VM status
|
|
|
|
TASK-002
|
|
Add frontend status widget
|
|
|
|
TASK-003
|
|
Write integration tests
|
|
```
|
|
|
|
Avoid:
|
|
|
|
```text
|
|
Rewrite the entire application
|
|
```
|
|
|
|
---
|
|
|
|
# Documentation Standards
|
|
|
|
Projects should contain:
|
|
|
|
```text
|
|
README.md
|
|
TASKS.md
|
|
ARCHITECTURE.md
|
|
CHANGELOG.md
|
|
/context/
|
|
```
|
|
|
|
Documentation should always be updated when functionality changes.
|
|
|
|
---
|
|
|
|
# Deployment Philosophy
|
|
|
|
Preferred order:
|
|
|
|
Development
|
|
→ Test
|
|
→ Staging
|
|
→ Production
|
|
|
|
Production deployments should be repeatable and automated.
|
|
|
|
Avoid:
|
|
|
|
- Manual server modifications
|
|
- Untracked configuration changes
|
|
- Snowflake servers
|
|
|
|
---
|
|
|
|
# Development Principles
|
|
|
|
Prefer:
|
|
|
|
- Simplicity
|
|
- Maintainability
|
|
- Incremental improvements
|
|
- Clear documentation
|
|
- Automation
|
|
- Reproducibility
|
|
|
|
Avoid:
|
|
|
|
- Unnecessary complexity
|
|
- Vendor lock-in
|
|
- Excessive dependencies
|
|
- Platform-specific assumptions
|