sync

.kilocode/rules/architect-mode-rules.md

@@ -0,0 +1,26 @@
+## Brief overview
+Ensures Architect mode focuses on planning and design without making direct code edits. Guides collaboration between Architect and Code modes.
+
+## Mode-specific Instructions
+- Architect mode must only create implementation plans and documentation
+- All code/file changes must be delegated to Code mode via switch_mode
+- Use update_todo_list for task tracking instead of direct implementation
+
+## Development Workflow
+- Generate detailed technical specifications in Architect mode
+- Use read_file and list_code_definition_names for context gathering
+- Create comprehensive todo lists with update_todo_list
+- Transition to Code mode via switch_mode for implementation
+
+## Collaboration Guidelines
+- Architect and Code modes should maintain separate responsibilities
+- Architectural plans must include:
+  - File structure diagrams
+  - API specifications
+  - Data flow documentation
+- Code mode implementations must reference architectural docs
+
+## Enforcement Rules
+- Block apply_diff/write_to_file usage in Architect mode
+- Require switch_mode to Code for any code modifications
+- Automatic todo list validation against architectural specs

.kilocode/rules/git-workflow.md

@@ -0,0 +1,45 @@
+## Brief overview
+Git workflow rules for projects with Git repositories, ensuring secure handling of sensitive data and proper version control practices.
+
+## Git repository setup
+- Ensure `.gitignore` exists in the project root when the directory is a Git repository
+- Verify `.gitignore` includes patterns for sensitive files and data directories
+- Check that `.git` directory exists to confirm Git repository status
+
+## Sensitive file protection
+- Always include `.env` files in `.gitignore` to prevent password/token exposure
+- Ensure `data/` directories are ignored to prevent data file commits
+- Add patterns for database files: `*.db`, `*.sqlite`, `*.sqlite3`
+- Include common sensitive file patterns:
+  - `.env.local`
+  - `.env.production`
+  - `config/secrets.json`
+  - `*.key`
+  - `*.pem`
+
+## Pre-change workflow
+- Before starting any new changes, ensure current state is committed
+- Run `git status` to check for uncommitted changes
+- Commit all pending changes with descriptive messages
+- Push commits to remote repository before starting new work
+- Use `git add . && git commit -m "WIP: save state before [feature/change]"` for work-in-progress saves
+
+## Post-completion workflow
+- When a task is finished, commit all changes with meaningful commit messages
+- Use conventional commit format: `type(scope): description`
+- Examples:
+  - `feat(auth): add Garmin Connect integration`
+  - `fix(data): handle missing activity files`
+  - `docs(readme): update setup instructions`
+- Push commits immediately after committing: `git push origin [branch-name]`
+
+## Branch management
+- Create feature branches for new work: `git checkout -b feature/description`
+- Keep main/master branch clean and deployable
+- Use descriptive branch names that reflect the task
+- Delete merged branches to keep repository clean
+
+## Verification steps
+- After each commit, verify with `git log --oneline -5`
+- Before pushing, run `git status` to confirm clean working directory
+- Check remote repository to ensure pushes were successful

.kilocode/rules/go-garth-rules.md

@@ -0,0 +1,20 @@
+## Brief overview
+Project-specific rules for go-garth development. Provides implementation guidelines with Python reference and credential handling requirements.
+
+## Project Context
+- Reference Python implementation in 'ReferenceCode' directory when debugging issues:
+  - `garth/` for core functionality patterns
+  - `python-garminconnect/` for API integration examples
+
+## Development Workflow
+- Restrict all file modifications to `go-garth/` directory subtree
+
+## Security Guidelines
+- Always store credentials in root `.env` file
+- Never hardcode credentials in source files
+- Ensure `.gitignore` includes `.env` to prevent accidental commits
+
+## Code Standards
+- Follow Go standard naming conventions (camelCase for variables)
+- Document public methods with GoDoc-style comments
+- Write table-driven tests for critical functionality

.kilocode/rules/memory-bank/architecture.md

@@ -0,0 +1,27 @@
+# System Architecture
+
+## Overview
+The Garth client library follows a layered architecture with clear separation between:
+- API Client Layer
+- Data Models Layer
+- Stats Endpoints Layer
+- Utilities Layer
+
+## Key Components
+- **Client**: Handles authentication, session management, and HTTP requests
+- **Data Models**: Represent Garmin API responses (e.g., DailyBodyBatteryStress)
+- **Stats**: Implement endpoints for different metrics (steps, stress, etc.)
+- **Test Utilities**: Mock implementations for testing
+
+## Data Flow
+1. User authenticates via `client.Login()`
+2. Session tokens are stored in `Client` struct
+3. Stats requests are made through `stats.Stats.List()` method
+4. Responses are parsed into data models
+5. Sessions can be saved/loaded using `SaveSession()`/`LoadSession()`
+
+## Critical Paths
+- Authentication: `garth/sso/sso.go`
+- API Requests: `garth/client/client.go`
+- Stats Implementation: `garth/stats/base.go`
+- Data Models: `garth/types/types.go`

.kilocode/rules/memory-bank/brief.md

@@ -0,0 +1,19 @@
+# Project Brief
+
+**Project Name**: Garth - Garmin Connect API Client  
+**Core Functionality**: 
+- Authentication with Garmin Connect
+- Retrieval of health/fitness data (steps, stress, hydration, sleep, HRV)
+- Session management
+- Error handling
+
+**Scope**:
+- Go client library for Garmin Connect API
+- Support for daily and weekly stats
+- Session persistence
+- Mock client for testing
+
+**Out of Scope**:
+- User interface
+- Data storage/visualization
+- Third-party integrations

.kilocode/rules/memory-bank/coding-style.md

@@ -0,0 +1,97 @@
+# Go Coding Style Guide
+
+## Code Organization & Structure
+
+**Logical Segmentation**
+- One concept per file (e.g., handlers, models, services).
+- Keep functions under 20-30 lines when possible.
+- Use meaningful package names that reflect functionality.
+- Group related types and functions together.
+
+**Interface Design**
+- Prefer small, focused interfaces (1-3 methods).
+- Define interfaces where they're used, not where they're implemented.
+- Use composition over inheritance.
+
+## Conciseness Rules
+
+**Variable & Function Naming**
+- Use short names in small scopes (`i`, `err`, `ctx`).
+- Longer names for broader scopes (`userRepository`, `configManager`).
+- Omit obvious type information (`users []User` not `userList []User`).
+
+**Error Handling**
+```go
+// Prefer early returns
+if err != nil {
+    return err
+}
+// over nested if-else blocks
+```
+
+**Type Declarations**
+- Use type inference: `users := []User{}` not `var users []User = []User{}`.
+- Combine related variable declarations: `var (name string; age int)`.
+
+## Go Idioms for Conciseness
+
+**Zero Values**
+- Leverage Go's zero values instead of explicit initialization.
+- Use `var buf bytes.Buffer` instead of `buf := bytes.Buffer{}`.
+
+**Struct Initialization**
+```go
+// Prefer struct literals with field names
+user := User{Name: name, Email: email}
+// over multiple assignments
+```
+
+**Method Receivers**
+- Use pointer receivers for modification or large structs.
+- Use value receivers for small, immutable data.
+
+**Channel Operations**
+- Use `select` with `default` for non-blocking operations.
+- Prefer `range` over explicit channel reads.
+
+## Context Reduction Strategies
+
+**Function Signatures**
+- Group related parameters into structs.
+- Use functional options pattern for complex configurations.
+- Return early and often to reduce nesting.
+
+**Constants and Enums**
+```go
+const (
+    StatusPending = iota
+    StatusApproved
+    StatusRejected
+)
+```
+
+**Embed Common Patterns**
+- Use `sync.Once` for lazy initialization.
+- Embed `sync.Mutex` in structs needing synchronization.
+- Use `context.Context` as first parameter in functions.
+
+## File Organization Rules
+
+**Package Structure**
+```
+/cmd          - main applications
+/internal     - private code
+/pkg          - public libraries
+/api          - API definitions
+```
+
+**Import Grouping**
+1. Standard library
+2. Third-party packages  
+3. Local packages
+(Separate groups with blank lines)
+
+**Testing**
+- Place tests in same package with `_test.go` suffix.
+- Use table-driven tests for multiple scenarios.
+- Keep test functions focused and named clearly.

.kilocode/rules/memory-bank/context.md

@@ -0,0 +1,18 @@
+# Project Context
+
+## Current Work Focus
+- Fixing syntax errors and test failures
+- Implementing mock client for testing
+- Refactoring HTTP client interfaces
+- Improving test coverage
+
+## Recent Changes
+- Fixed syntax error in [`garth/integration_test.go`](garth/integration_test.go:168) by removing extra closing brace
+- Created [`garth/testutils/mock_client.go`](garth/testutils/mock_client.go) for simulating API failures
+- Added [`garth/client/http_client.go`](garth/client/http_client.go) to define HTTPClient interface
+
+## Next Steps
+- Complete mock client implementation
+- Update stats package to use HTTPClient interface
+- Fix remaining test failures
+- Add more integration tests for data endpoints

.kilocode/rules/memory-bank/product.md

@@ -0,0 +1,27 @@
+# Product Description
+
+## Why this project exists
+Garth provides a Go client library for interacting with Garmin Connect API, enabling developers to:
+- Access personal fitness data programmatically
+- Build custom health tracking applications
+- Integrate Garmin data with other systems
+
+## Problems it solves
+- Simplifies authentication with Garmin's complex SSO system
+- Provides structured access to health metrics (steps, sleep, stress, etc.)
+- Handles session persistence and token management
+- Abstracts API complexities behind a clean Go interface
+
+## How it should work
+1. Users authenticate with their Garmin credentials
+2. The client manages session tokens automatically
+3. Developers can request daily/weekly metrics through simple method calls
+4. Data is returned as structured Go types
+5. Sessions can be saved/loaded for persistent access
+
+## User Experience Goals
+- Minimal setup required
+- Intuitive method names matching Garmin's metrics
+- Clear error handling and documentation
+- Support for both individual data points and bulk retrieval
+- Mock client for testing without live API calls

.kilocode/rules/memory-bank/tech.md

@@ -0,0 +1,27 @@
+# Technologies and Development Setup
+
+## Core Technologies
+- **Language**: Go (Golang)
+- **Package Manager**: Go Modules (go.mod)
+- **HTTP Client**: net/http with custom enhancements
+- **Testing**: Standard testing package
+
+## Development Setup
+1. Install Go (version 1.20+)
+2. Clone the repository
+3. Run `go mod tidy` to install dependencies
+4. Set up Garmin credentials in environment variables or session file
+
+## Technical Constraints
+- Requires Garmin Connect account for integration tests
+- Limited to Garmin's public API endpoints
+- No official SDK support from Garmin
+
+## Dependencies
+- Standard library packages only
+- No external dependencies beyond Go standard library
+
+## Tool Usage Patterns
+- Use `go test` for running unit tests
+- Use `go test -short` to skip integration tests
+- Use `go build` to build the package

.kilocode/rules/memorybank.md

@@ -0,0 +1,167 @@
+# Memory Bank
+
+I am an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.
+
+When I start a task, I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization.
+
+## Memory Bank Structure
+
+The Memory Bank consists of core files and optional context files, all in Markdown format.
+
+### Core Files (Required)
+1. `brief.md`
+   This file is created and maintained manually by the developer. Don't edit this file directly but suggest to user to update it if it can be improved.
+   - Foundation document that shapes all other files
+   - Created at project start if it doesn't exist
+   - Defines core requirements and goals
+   - Source of truth for project scope
+
+2. `product.md`
+   - Why this project exists
+   - Problems it solves
+   - How it should work
+   - User experience goals
+
+3. `context.md`
+   This file should be short and factual, not creative or speculative.
+   - Current work focus
+   - Recent changes
+   - Next steps
+
+4. `architecture.md`
+   - System architecture
+   - Source Code paths
+   - Key technical decisions
+   - Design patterns in use
+   - Component relationships
+   - Critical implementation paths
+
+5. `tech.md`
+   - Technologies used
+   - Development setup
+   - Technical constraints
+   - Dependencies
+   - Tool usage patterns
+
+### Additional Files
+Create additional files/folders within memory-bank/ when they help organize:
+- `tasks.md` - Documentation of repetitive tasks and their workflows
+- Complex feature documentation
+- Integration specifications
+- API documentation
+- Testing strategies
+- Deployment procedures
+
+## Core workflows
+
+### Memory Bank Initialization
+
+The initialization step is CRITICALLY IMPORTANT and must be done with extreme thoroughness as it defines all future effectiveness of the Memory Bank. This is the foundation upon which all future interactions will be built.
+
+When user requests initialization of the memory bank (command `initialize memory bank`), I'll perform an exhaustive analysis of the project, including:
+- All source code files and their relationships
+- Configuration files and build system setup
+- Project structure and organization patterns
+- Documentation and comments
+- Dependencies and external integrations
+- Testing frameworks and patterns
+
+I must be extremely thorough during initialization, spending extra time and effort to build a comprehensive understanding of the project. A high-quality initialization will dramatically improve all future interactions, while a rushed or incomplete initialization will permanently limit my effectiveness.
+
+After initialization, I will ask the user to read through the memory bank files and verify product description, used technologies and other information. I should provide a summary of what I've understood about the project to help the user verify the accuracy of the memory bank files. I should encourage the user to correct any misunderstandings or add missing information, as this will significantly improve future interactions.
+
+### Memory Bank Update
+
+Memory Bank updates occur when:
+1. Discovering new project patterns
+2. After implementing significant changes
+3. When user explicitly requests with the phrase **update memory bank** (MUST review ALL files)
+4. When context needs clarification
+
+If I notice significant changes that should be preserved but the user hasn't explicitly requested an update, I should suggest: "Would you like me to update the memory bank to reflect these changes?"
+
+To execute Memory Bank update, I will:
+
+1. Review ALL project files
+2. Document current state
+3. Document Insights & Patterns
+4. If requested with additional context (e.g., "update memory bank using information from @/Makefile"), focus special attention on that source
+
+Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on context.md as it tracks current state.
+
+### Add Task
+
+When user completes a repetitive task (like adding support for a new model version) and wants to document it for future reference, they can request: **add task** or **store this as a task**.
+
+This workflow is designed for repetitive tasks that follow similar patterns and require editing the same files. Examples include:
+- Adding support for new AI model versions
+- Implementing new API endpoints following established patterns
+- Adding new features that follow existing architecture
+
+Tasks are stored in the file `tasks.md` in the memory bank folder. The file is optional and can be empty. The file can store many tasks. 
+
+To execute Add Task workflow:
+
+1. Create or update `tasks.md` in the memory bank folder
+2. Document the task with:
+   - Task name and description
+   - Files that need to be modified
+   - Step-by-step workflow followed
+   - Important considerations or gotchas
+   - Example of the completed implementation
+3. Include any context that was discovered during task execution but wasn't previously documented
+
+Example task entry:
+```markdown
+## Add New Model Support
+**Last performed:** [date]
+**Files to modify:**
+- `/providers/gemini.md` - Add model to documentation
+- `/src/providers/gemini-config.ts` - Add model configuration
+- `/src/constants/models.ts` - Add to model list
+- `/tests/providers/gemini.test.ts` - Add test cases
+
+**Steps:**
+1. Add model configuration with proper token limits
+2. Update documentation with model capabilities
+3. Add to constants file for UI display
+4. Write tests for new model configuration
+
+**Important notes:**
+- Check Google's documentation for exact token limits
+- Ensure backward compatibility with existing configurations
+- Test with actual API calls before committing
+```
+
+### Regular Task Execution
+
+In the beginning of EVERY task I MUST read ALL memory bank files - this is not optional. 
+
+The memory bank files are located in `.kilocode/rules/memory-bank` folder. If the folder doesn't exist or is empty, I will warn user about potential issues with the memory bank. I will include `[Memory Bank: Active]` at the beginning of my response if I successfully read the memory bank files, or `[Memory Bank: Missing]` if the folder doesn't exist or is empty. If memory bank is missing, I will warn the user about potential issues and suggest initialization. I should briefly summarize my understanding of the project to confirm alignment with the user's expectations, like:
+
+"[Memory Bank: Active] I understand we're building a React inventory system with barcode scanning. Currently implementing the scanner component that needs to work with the backend API."
+
+When starting a task that matches a documented task in `tasks.md`, I should mention this and follow the documented workflow to ensure no steps are missed.
+
+If the task was repetitive and might be needed again, I should suggest: "Would you like me to add this task to the memory bank for future reference?"
+
+In the end of the task, when it seems to be completed, I will update `context.md` accordingly. If the change seems significant, I will suggest to the user: "Would you like me to update memory bank to reflect these changes?" I will not suggest updates for minor changes.
+
+## Context Window Management
+
+When the context window fills up during an extended session:
+1. I should suggest updating the memory bank to preserve the current state
+2. Recommend starting a fresh conversation/task
+3. In the new conversation, I will automatically load the memory bank files to maintain continuity
+
+## Technical Implementation
+
+Memory Bank is built on Kilo Code's Custom Rules feature, with files stored as standard markdown documents that both the user and I can access.
+
+## Important Notes
+
+REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
+
+If I detect inconsistencies between memory bank files, I should prioritize brief.md and note any discrepancies to the user.
+
+IMPORTANT: I MUST read ALL memory bank files at the start of EVERY task - this is not optional. The memory bank files are located in `.kilocode/rules/memory-bank` folder.