# SkyView Project Guidelines

## Documentation Requirements
- We should always have an up to date document describing our architecture and features
- Include links to any external resources we've used  
- We should also always have an up to date README describing the project
- Shell scripts should be validated with shellcheck
- Always make sure the code is well documented with explanations for why and how a particular solution is selected

## Development Principles
- An overarching principle with all code is KISS, Keep It Simple Stupid
- We do not want to create code that is more complicated than necessary
- When changing code, always make sure to update any relevant tests
- Use proper error handling - aviation applications need reliability

## SkyView-Specific Guidelines

### Architecture & Design
- Multi-source ADS-B data fusion is the core feature - prioritize signal strength-based conflict resolution
- Embedded resources (SQLite ICAO database, static assets) over external dependencies
- Low-latency performance is critical - optimize for fast WebSocket updates
- Support concurrent aircraft tracking (100+ aircraft should work smoothly)

### Code Organization
- Keep Go packages focused: beast parsing, modes decoding, merger, server, clients
- Frontend should be modular: separate managers for aircraft, map, UI, websockets
- Database operations should be fast (use indexes, avoid N+1 queries)

### Performance Considerations
- Beast binary parsing must handle high message rates (1000+ msg/sec per source)
- WebSocket broadcasting should not block on slow clients
- Memory usage should be bounded (configurable history limits)
- CPU usage should remain low during normal operation

### Documentation Maintenance
- Always update docs/ARCHITECTURE.md when changing system design
- README.md should stay current with features and usage
- External resources (ICAO docs, ADS-B standards) should be linked in documentation
- Country database updates should be straightforward (replace SQLite file)