Hallucinate hella cursor rules

This commit is contained in:
2025-10-10 20:07:44 +02:00
parent c199b3337a
commit 101138716f
5 changed files with 136 additions and 0 deletions

View File

@@ -0,0 +1,31 @@
---
globs: *.go
description: Code quality and consistency standards
---
# Code Quality Standards
## General Principles
- Keep functions focused and single-purpose
- Use descriptive variable and function names
- Add comprehensive logging for debugging
- Handle errors gracefully with proper context
## Specific Rules
- Never use `fmt.Printf` or `fmt.Println` - always use the logger
- Avoid redundant log lines right next to each other
- Use `logger.Warning()` not `logger.Warn()`
- Include character names and operation context in log messages
- Use high-level database methods, not raw GORM calls
## Code Organization
- Keep SSO logic in [esi_sso.go](mdc:esi_sso.go)
- Keep database abstraction in [db.go](mdc:db.go)
- Main application logic in [main.go](mdc:main.go)
- Use interfaces for database operations to enable testing
## Error Handling
- Always log errors with sufficient context
- Don't swallow errors silently
- Provide meaningful error messages to users
- Handle network timeouts and API failures gracefully

View File

@@ -0,0 +1,23 @@
---
globs: *.go
description: Database abstraction layer conventions
---
# Database Abstraction Standards
## High-Level Interface
The [db.go](mdc:db.go) file provides a high-level database interface. Always use these methods instead of raw GORM calls:
- `GetTokenForCharacter(characterName string) (*Token, error)`
- `SaveTokenForCharacter(token *Token) error`
- `AutoMigrate(dst ...interface{}) error`
## Never Use Raw GORM
- Don't call `s.db.DB().Where(...)` directly
- Don't call `s.db.DB().Save(...)` directly
- Always use the abstracted methods in the DB interface
## Database Operations
- All database operations should be logged with appropriate context
- Include character names in log messages for database operations
- Handle errors gracefully and log them with context

View File

@@ -0,0 +1,31 @@
---
globs: esi_sso.go
description: EVE SSO interface and implementation standards
---
# EVE SSO Interface Standards
## Core Interface
The SSO system provides a simple interface:
```go
token, err := sso.GetToken(ctx, "CharacterName")
```
## Key Principles
- Use character NAMES, not IDs (nobody knows character IDs)
- Handle all SSO complexity behind the scenes
- Automatic token refresh when expired
- Automatic re-authentication when refresh fails
- Store tokens in database for persistence
## Implementation Details
- [esi_sso.go](mdc:esi_sso.go) contains the SSO implementation
- Uses PKCE for secure OAuth2 flow
- Implements proper callback handling with HTTP server
- Includes comprehensive logging for debugging
- Handles token exchange and refresh automatically
## Error Handling
- Always log errors with context (character name, operation)
- Provide clear error messages for authentication failures
- Handle network timeouts and API errors gracefully

View File

@@ -0,0 +1,27 @@
---
alwaysApply: true
description: Go EVE PI project structure and conventions
---
# Go EVE PI Project Structure
This is a Go project for EVE Online PI (Planetary Interaction) management with SSO authentication.
## Key Files
- [main.go](mdc:main.go) - Main entry point, loads configuration from .env file
- [esi_sso.go](mdc:esi_sso.go) - EVE SSO authentication implementation
- [db.go](mdc:db.go) - Database abstraction layer with high-level methods
## Project Conventions
- Uses `logger "git.site.quack-lab.dev/dave/cylogger"` for all logging
- Database operations use high-level methods like `GetTokenForCharacter()` and `SaveTokenForCharacter()`
- SSO interface: `GetToken(ctx, characterName)` returns access token for character
- Configuration loaded from .env file (ESI_CLIENT_ID, ESI_REDIRECT_URI, ESI_SCOPES, DB_PATH)
## Logging Standards
- Use `logger.Info()` for important business events
- Use `logger.Debug()` for detailed debugging information
- Use `logger.Warning()` for warning conditions
- Use `logger.Error()` for error conditions
- Never use `fmt.Printf` - always use the logger
- Avoid redundant log lines right next to each other

View File

@@ -0,0 +1,24 @@
---
globs: *.go
description: Go logging standards and conventions
---
# Go Logging Standards
## Always Use cylogger
- Import: `logger "git.site.quack-lab.dev/dave/cylogger"`
- Never use `fmt.Printf`, `fmt.Println`, or standard `log` package
- All output must go through the logger system
## Logging Levels
- `logger.Debug()` - Detailed debugging info, internal state
- `logger.Info()` - Important business events, user-facing messages
- `logger.Warning()` - Warning conditions (not `logger.Warn()`)
- `logger.Error()` - Error conditions, failures
## Best Practices
- Include context in log messages (character names, operation details)
- Use structured logging with format strings: `logger.Info("Operation completed for %s", name)`
- Avoid redundant log lines right next to each other
- Log at appropriate levels - don't spam with unnecessary debug logs
- Always log errors with context about what operation failed