# Slide authoring and presentation tool
- Should run with no backend server required
- Data should be stored in indexdb in the browser
- leverage existing react and npm libraries

# Features
- Create new presentation
- Select theme for presentation
- Add slides to presentation and select layout for each slide based on the selected theme and it's layouts
- Add text to slide in theme layout "slots"
- Add images to slide in theme layout "slots"
- Add presentation notes to slide
- Present slides in a full screen mode


# Themes
- Themes should be baked into the app, but should be customizable
- Themes should be selectable when creating a new presentation
- Themes should be applied to all slides in the presentation
- Themes should be able to be updated after the presentation is created and presentations will be updated to reflect the new theme
- Themes should allow multiple layouts for slides that are selectable when creating a new slide
- Themes should allow for custom CSS to be applied to the presentation
- Themes should allow for custom fonts to be applied to the presentation
- Themes should allow for custom colors to be applied to the presentation
- Themes should allow for custom images to be applied to the presentation
- Themes should allow for "master slides" that have content that slide authors cannot override or change

# ROADMAP
- [x] build themeing system creating initial default theme
- [x] build theme selection system
- [ ] build theme browsing module
- [ ] build presentation creation system
- [ ] build slide creation system
- [ ] build slide authoring system
- [ ] build presentation system

# CURRENT FOCUS
## determine structure and approach for theming system
- [x] it should be flexible and allow for custom themes to be created using only html templates and css
- [x] themes and templates should be very close to native html and css so that they can be easily created and modified
- 

# Code Standards
- Strongly prefer convention over configuration versus configuration over convention
- Use React for the UI, but allow for other libraries if needed and try to keep as close to html/js/css as possible
- Use functional components and hooks
- Use TypeScript for type safety, but allow for JavaScript in some cases
- **No inline styles** - All styling should be in CSS files with semantic class names
- Theme structure should be simple and easy to understand for someone familiar with  html and ccss
- Theme structure should not repeat the same information in multiple places
- Theme structure should be flexible and allow for custom themes to be created using only html templates and css
- Metadata for themes should be stored as comments in the html and css files

# General Claude Guidelines
- Don't run npm commands, just tell me what to run and I'll run them myself
- generally tsx files should be used for React components and they should be less than 200 lines of code
- if a file I should be warned when I ask for a code audit
- if a function or method is more than 50 lines of code, I should be warned

# Architecture
## Themes
- Themes should be stored in a directory structure under public directory that allows for easy access and modification by browser
- Themes should be stored in a directory structure that allows for easy access

- don't try to run command to restart, just tell me the command when necessary
- Add to memory.  Just tell me to run build, I'll paste in results, don't try to run the command
- Add to memory. I want to make sure this approach is generally followed
- remember to always use introspection when browsing themes and details

# CSS & Component Architecture Guidelines

## Modal Components
- **Follow existing Modal.tsx pattern** - Use simple overlay → content structure
- **Single flex container** for centering - Don't nest multiple flex containers competing for layout
- **Proper click handling** - Use `event.target === event.currentTarget` for overlay clicks
- **Existing UI patterns** - Check components/ui/ folder before creating new modal patterns

## Slide Rendering & Aspect Ratios
- **Reuse established selectors** - `.slide-preview-wrapper .slide-container.aspect-X-X` pattern is proven
- **Don't duplicate aspect ratio CSS** - Always extend existing aspect ratio classes, never recreate
- **Theme CSS inheritance** - Theme CSS is loaded globally in SlideEditor, modals inherit this automatically  
- **Check SlideEditor CSS** - Before creating slide display components, see how SlideEditor handles aspect ratios

## CSS Architecture Principles  
- **NEVER duplicate CSS** - Search for existing classes before writing new ones
- **Avoid nested flex competitions** - Don't create competing flex containers at different levels
- **Use semantic class hierarchies** - `.parent-context .slide-container.modifier` pattern works well
- **Simplify before adding complexity** - Start with minimal structure, add layers only when needed

## Component Reuse Checks
- **Search existing components** - Use Grep to find similar patterns before coding
- **Check shared/ folders** - Look for reusable UI components first
- **Extend, don't recreate** - Build on existing patterns rather than starting fresh
- **Test integration early** - Verify new components work with existing theme/CSS systems

# Referenced Coding Standards Files
**Always consult these project standards before coding:**

## IMPORT_STANDARDS.md
- **NEVER use barrel files** for component imports (violates Vite best practices)
- **ALWAYS use direct file imports** with explicit .tsx extensions
- **Example**: `import { Component } from './components/Component.tsx'` ✅
- **Avoid**: `import { Component } from './components'` ❌
- Performance: Direct imports enable Vite tree shaking and faster module resolution

## ERROR_HANDLING_STANDARDS.md
- **Consistent async patterns** with try/catch/finally and proper loading states
- **Replace browser dialogs** - Use AlertDialog/ConfirmDialog instead of alert()/confirm()
- **Standard error types**: User errors (recoverable), System errors (technical), Critical errors (unrecoverable)
- **useAsyncOperation hook pattern** for consistent error/loading state management
- **Error boundaries** required for component-level error handling

## REACT19_IMPLEMENTATION.md
- **Use Actions for form handling** - Replace manual state management with useActionState
- **useOptimistic for theme previews** - Implement optimistic updates for better UX
- **Modern Context syntax** - Use direct Context rendering instead of Provider wrapper
- **Error boundaries with Actions** - Implement proper error handling for React 19 patterns

# Workflow Reminders
- **Check all .md standards** before starting any component work
- **Use direct imports** with .tsx extensions per IMPORT_STANDARDS.md
- **Implement proper error handling** per ERROR_HANDLING_STANDARDS.md
- **Consider React 19 patterns** per REACT19_IMPLEMENTATION.md for new features