Brand sdk integration

.stitch/rules/bigger-picture-description-rules.md

@@ -0,0 +1,19 @@
+---
+name: Bigger Picture Description Rules
+description: Guidelines for explaining how code works in context
+alwaysApply: false
+---
+
+When a user asks how a certain part of the code works:
+
+## 1. Describe what the code does in isolation
+
+Explain the functionality of the code without considering its interactions with other parts of the codebase.
+
+## 2. Describe interactions with other parts of the codebase
+
+If the code interacts with other parts of the codebase, describe how the code is imported and used in other parts of the codebase.
+
+## 3. Include parent function for clarity
+
+When describing each use-case, include the parent function for clarity.

.stitch/rules/colors.md

@@ -0,0 +1,63 @@
+---
+name: Extension Color Themes
+description: Guidelines for using theme colors in GUI components
+alwaysApply: false
+globs: "gui/**/*.tsx"
+---
+
+When adding colors to components, use tailwind color classes.
+Do NOT use explicit colors like text-gray-400. Instead, use theme colors.
+
+## Available theme colors
+
+### Normal text
+
+- `foreground`, `description`, `description-muted`
+
+### Other text, icons, etc
+
+- `success`, `warning`, `error`, `accent`, `link`
+
+### General components
+
+- `background`, `border`, `border-focus`
+
+### Specific components
+
+#### Button
+
+- `primary`, `primary-foreground`, `primary-hover`
+- `secondary`, `secondary-foreground`, `secondary-hover`
+
+#### Input
+
+- `input`, `input-foreground`, `input-border`, `input-placeholder`
+
+#### Badge
+
+- `badge`, `badge-foreground`
+
+#### List/Dropdown items
+
+- `list-hover`, `list-active`, `list-active-foreground`
+
+#### Code Editor
+
+- `editor`, `editor-foreground`
+
+## Usage examples
+
+Any of these colors can be used in tailwind classes:
+
+- `bg-primary`
+- `text-success`
+- `border-error`
+- `hover:bg-list-hover`
+
+## Excluded colors
+
+The following less-used colors are excluded from this guide:
+
+- Command (only used by tip-tap): `command`, `command-foreground`, `command-border`, `command-border-focus`
+- Find widget colors: `find-match`, `find-match-selected`
+- `table-oddRow`

.stitch/rules/continue-specificity.md

@@ -0,0 +1,9 @@
+---
+globs: /**/*.
+description: General questions about code completion should be answered specific to Continue
+---
+
+# Continue Specificity
+
+- In chat mode, if the user asks generally about code completion or developer tools, answer specifically regarding Continue and not other similar software.
+- Keep all suggestions and comments concentrated on Continue, unless the user asks otherwise. If the user does this, answer with no particular specificity to Continue.

.stitch/rules/css-units.md

@@ -0,0 +1,5 @@
+---
+globs: "gui/**/*.tsx"
+---
+
+You should try to use the `rem` CSS unit whenever possible for scalability instead of `px`.

.stitch/rules/dev-data-guide.md

@@ -0,0 +1,200 @@
+---
+alwaysApply: false
+---
+
+# Continue Development Data (Dev Data) Guide
+
+## Overview
+
+Development data (dev data) captures detailed information about how developers interact with LLM-aided development tools. Unlike basic telemetry, dev data includes lots of details into the complete software development workflow, including code context, user interactions, and development patterns.
+
+## Core Architecture
+
+### Primary Implementation Files
+
+- **`/core/data/log.ts`**: Main `DataLogger` class - singleton for event logging and remote transmission
+- **`/packages/config-yaml/src/schemas/data/`**: Schema definitions for all event types
+
+### Storage Locations
+
+- **Default storage**: `~/.continue/dev_data/`
+- **Event files**: `~/.continue/dev_data/{version}/{eventName}.jsonl`
+
+## Event Types and Schemas
+
+### Core Event Types
+
+1. **`tokensGenerated`**: LLM token usage tracking
+2. **`autocomplete`**: Code completion interactions
+3. **`chatInteraction`**: Chat-based development assistance
+4. **`editInteraction`**: Code editing sessions
+5. **`editOutcome`**: Results of edit operations
+6. **`nextEditOutcome`**: Next Edit feature outcomes
+7. **`chatFeedback`**: User feedback on AI responses
+8. **`toolUsage`**: Tool interaction statistics
+9. **`quickEdit`**: Quick edit functionality usage
+
+### Schema Versioning
+
+- **Version 0.1.0**: Initial schema implementation
+- **Version 0.2.0**: Current schema with expanded fields and metadata
+- **Schema files**: Located in `/packages/config-yaml/src/schemas/data/`
+
+### Base Schema Structure
+
+All events inherit from a base schema (`/packages/config-yaml/src/schemas/data/base.ts`):
+
+```typescript
+{
+  eventName: string,
+  schema: string,
+  timestamp: string,
+  userId: string,
+  userAgent: string,
+  selectedProfileId: string
+}
+```
+
+## Key Integration Points
+
+### Autocomplete System
+
+- **File**: `/core/autocomplete/util/AutocompleteLoggingService.ts`
+- **Purpose**: Tracks code completion acceptance/rejection, timing, and cache hits
+- **Integration**: Called from autocomplete engine when completions are shown/accepted
+
+### Chat Interface
+
+- **Integration**: Chat interactions logged through `DataLogger.logDevData()`
+- **Data**: Includes prompts, responses, context, and user feedback
+- **Privacy**: Can be configured to exclude code content
+
+### Edit Features
+
+- **Files**: `/extensions/vscode/src/extension/EditOutcomeTracker.ts`, `/core/nextEdit/NextEditLoggingService.ts`
+- **Purpose**: Track edit suggestions, acceptance rates, and outcomes
+- **Integration**: Embedded in edit workflow to capture user decisions
+
+### LLM Token Tracking
+
+- **File**: `/core/llm/index.ts`
+- **Purpose**: Track token usage across all LLM providers
+- **Storage**: SQLite database for efficient querying and reporting
+
+## Configuration and Customization
+
+### Configuration Structure
+
+Dev data is configured through `data` blocks in your Continue config:
+
+```yaml
+data:
+  - name: "Local Development Data"
+    destination: "file:///Users/developer/.continue/dev_data"
+    schema: "0.2.0"
+    level: "all"
+    events: ["autocomplete", "chatInteraction", "editOutcome"]
+
+  - name: "Team Analytics"
+    destination: "https://analytics.yourcompany.com/api/events"
+    schema: "0.2.0"
+    level: "noCode"
+    apiKey: "your-api-key-here"
+    events: ["tokensGenerated", "toolUsage"]
+```
+
+### Configuration Options
+
+- **`destination`**: Where to send data (`file://` for local, `http://`/`https://` for remote)
+- **`schema`**: Schema version to use (`"0.1.0"` or `"0.2.0"`)
+- **`level`**: Data detail level (`"all"` includes code, `"noCode"` excludes code content)
+- **`events`**: Array of event types to collect
+- **`apiKey`**: Authentication for remote endpoints
+
+### Privacy Controls
+
+- **`"all"` level**: Includes code content (prefixes, suffixes, completions)
+- **`"noCode"` level**: Excludes code content, only metadata and metrics
+- **Local-first**: Data is always stored locally, remote transmission is optional
+
+## Making Changes to Dev Data
+
+### Adding New Event Types
+
+1. **Create schema**: Add new event schema in `/packages/config-yaml/src/schemas/data/`
+2. **Update index**: Add to schema aggregator in `/packages/config-yaml/src/schemas/data/index.ts`
+3. **Implement logging**: Add logging calls in relevant service files
+4. **Update version**: Consider schema version bump if breaking changes
+
+### Modifying Existing Events
+
+1. **Schema changes**: Update schema files in `/packages/config-yaml/src/schemas/data/`
+2. **Backward compatibility**: Ensure changes don't break existing data consumers
+3. **Version management**: Increment schema version for breaking changes
+4. **Test thoroughly**: Validate schema changes with existing data
+
+### Adding New Logging Points
+
+1. **Import DataLogger**: `import { DataLogger } from "core/data/log"`
+2. **Log events**: Call `DataLogger.getInstance().logDevData(eventName, data)`
+3. **Follow patterns**: Use existing logging services as examples
+4. **Validate data**: Ensure logged data matches schema requirements
+
+### Debugging Dev Data Issues
+
+1. **Check local storage**: Verify files are being created in `~/.continue/dev_data/`
+2. **Validate schemas**: Ensure event data matches expected schema format
+3. **Review configuration**: Check `data` blocks in Continue config
+4. **Test endpoints**: Verify remote endpoints are reachable and accepting data
+
+## Best Practices
+
+### When Adding New Events
+
+- Follow existing naming conventions for event types
+- Include sufficient context for analysis without oversharing sensitive data
+- Consider privacy implications and respect user configuration levels
+- Add appropriate error handling and logging
+
+### When Modifying Schemas
+
+- Maintain backward compatibility when possible
+- Document schema changes thoroughly
+- Consider impact on existing data consumers
+- Test with real development data
+
+### When Integrating Logging
+
+- Use the singleton pattern: `DataLogger.getInstance()`
+- Log events at appropriate points in user workflow
+- Respect user privacy settings and configuration
+- Handle errors gracefully without disrupting user experience
+
+## Common Patterns
+
+### Service-Based Logging
+
+Most dev data logging follows a service pattern:
+
+```typescript
+export class FeatureLoggingService {
+  private dataLogger = DataLogger.getInstance();
+
+  logFeatureUsage(data: FeatureUsageData) {
+    this.dataLogger.logDevData("featureUsage", data);
+  }
+}
+```
+
+### Event-Driven Logging
+
+Events are typically logged at key interaction points:
+
+```typescript
+// When user accepts autocomplete
+onAutocompleteAccepted(completion: CompletionData) {
+  AutocompleteLoggingService.getInstance().logAutocompleteAccepted(completion);
+}
+```
+
+This guide provides the foundation for understanding and working with Continue's dev data system. Always prioritize user privacy and follow established patterns when making changes.

.stitch/rules/documentation-description-rule.md

@@ -0,0 +1,8 @@
+---
+globs: docs/**/*.{md,mdx}
+description: This rule applies to all documentation files to ensure consistent
+  SEO optimization and improve discoverability. It helps users and search
+  engines understand the content of each page before reading it.
+---
+
+Every file in the docs folder must include a 'description' field in its frontmatter that accurately summarizes the content of the page in 100-160 characters. The description should be concise, keyword-rich, and explain what users will learn or accomplish from the page.