Knowder Library Development Rules

You are helping develop "Knowder" - a lightweight JavaScript library for displaying engaging facts during loading states. The primary goal is to transform user frustration during loading into engagement while maintaining exceptional performance.

Core Principles (NON-NEGOTIABLE)

1. Bundle Size Supremacy

2. Performance First

3. Developer Experience Excellence

Technical Constraints

Code Style & Patterns

DOM Manipulation Rules

Animation Guidelines

File Organization

```

src/

├── core/

│ ├── factLoader.js # Main API class

│ ├── factStorage.js # Data management

│ └── display.js # DOM/animation engine

├── data/

│ └── defaultFacts.js # Default fact database

└── index.js # Public API exports

```

Development Workflow

Testing Requirements

Code Quality Gates

1. All tests must pass

2. Bundle size must be <5KB gzipped

3. ESLint must pass with zero warnings

4. No console.log statements in production code

5. Proper JSDoc documentation for all public APIs

Git Commit Guidelines

API Design Rules

Public API Surface

```javascript

// Main methods (keep to 3 maximum)

Knowder.init(options) // Initialize with config

Knowder.start(category) // Start displaying facts

Knowder.stop() // Stop and cleanup

// Utility methods (minimal)

Knowder.addFacts(category, facts) // Add custom facts

Knowder.getCategories() // List categories

```

Configuration Schema

Error Handling Strategy

Content Guidelines

Default Facts Criteria

Fact Quality Standards

Browser Support Strategy

Supported Browsers

Feature Detection

Build & Distribution Rules

Build Process

Quality Assurance

Documentation Standards

Code Documentation

User Documentation

Code Review Checklist

When suggesting or reviewing code, always verify:

Critical Questions

1. "Does this add unnecessary bytes to the bundle?"

2. "Could this impact performance negatively?"

3. "Is this the simplest possible solution?"

4. "Does this maintain backward compatibility?"

5. "Is this accessible to all users?"

Emergency Protocols

If Bundle Size Exceeds Limit

1. STOP all development

2. Analyze what caused the increase

3. Remove/optimize offending code

4. Consider if feature is essential

5. Document decision rationale

If Performance Regresses

1. Identify the performance bottleneck

2. Use browser dev tools to profile

3. Optimize the critical path

4. Add performance test to prevent regression

5. Update performance documentation

Success Metrics to Track

Technical Metrics

User Experience Metrics

Remember

Every decision should be evaluated through the lens of performance, simplicity, and developer experience. When in doubt, choose the solution that maintains the smallest bundle size and clearest API.