insertr/TODO.md

# Insertr Development TODO

## 🔍 Architecture Analysis Complete (Dec 2024)

**Key Discovery**: The architecture is already 90% complete and brilliantly designed! The missing piece is not LocalStorage persistence, but the **HTTP server application** that implements the API contract both clients expect.

## ✅ What's Already Built & Working

### **Complete Foundation**
- ✅ **Go Content Client** - Full REST API client with all CRUD operations (`internal/content/client.go`)
- ✅ **JavaScript API Client** - Browser client with same API endpoints (`lib/src/core/api-client.js`)
- ✅ **Content Types** - Well-defined data structures (`ContentItem`, `ContentResponse`)
- ✅ **Mock Backend** - Working development server with realistic test data
- ✅ **Build-Time Enhancement** - Content injection from database → HTML during builds
- ✅ **Authentication System** - Complete auth flow ready for server integration
- ✅ **Professional Editor** - Modal forms, validation, smart field detection

### **Architecture Philosophy Preserved**
- ✅ **"Tailwind of CMS"** - Zero configuration, build-time optimization
- ✅ **Framework Agnostic** - Works with any static site generator  
- ✅ **Performance First** - Regular visitors get pure static HTML
- ✅ **Editor Progressive Enhancement** - Editing assets only load when needed

## 🚨 **CRITICAL MISSING PIECE**

### **HTTP Server Application** (90% of work remaining)
The CLI client and JavaScript client both expect a server at `/api/content/*`, but **no server exists**!

**Required API Endpoints**:
```
GET  /api/content/{id}?site_id={site}           # Get single content
GET  /api/content?site_id={site}                # Get all content for site  
GET  /api/content/bulk?site_id={site}&ids[]=... # Bulk get content
PUT  /api/content/{id}                          # Update existing content
POST /api/content                               # Create new content
```

**Current State**: Both clients make HTTP calls to these endpoints, but they 404 because no server implements them.

## 🎯 **Immediate Implementation Plan**

### **🔴 Phase 1: HTTP Server (CRITICAL)**
**Goal**: Build the missing server application that implements the API contract

#### 1.1 **Go HTTP Server** ⭐ **HIGHEST PRIORITY**
- [ ] **REST API Server** - Implement all 5 required endpoints
- [ ] **Database Layer** - SQLite for development, PostgreSQL for production
- [ ] **Authentication Middleware** - JWT/OAuth integration
- [ ] **CORS & Security** - Proper headers for browser integration
- [ ] **Content Validation** - Input sanitization and type checking

#### 1.2 **Integration Testing**
- [ ] **CLI Client Integration** - Test all CLI commands work with real server
- [ ] **JavaScript Client Integration** - Test browser editor saves to real server
- [ ] **End-to-End Workflow** - Edit → Save → Build → Deploy cycle

### **🟡 Phase 2: Production Polish (IMPORTANT)**

#### 2.1 **Client-Side Enhancements**
- [ ] **Editor-Server Integration** - Wire up `handleSave` to use `ApiClient` 
- [ ] **Optimistic Updates** - Show immediate feedback, sync in background
- [ ] **Offline Support** - LocalStorage cache + sync when online
- [ ] **Loading States** - Professional feedback during saves

#### 2.2 **Deployment Pipeline**
- [ ] **Build Triggers** - Auto-rebuild sites when content changes
- [ ] **Multi-Site Support** - Handle multiple domains/site IDs
- [ ] **CDN Integration** - Host insertr.js library on CDN
- [ ] **Database Migrations** - Schema versioning and updates

### **🟢 Phase 3: Advanced Features (NICE-TO-HAVE)**

#### 3.1 **Content Management Enhancements**
- [ ] **Content Versioning** - Track edit history and allow rollbacks
- [ ] **Content Validation** - Advanced validation rules per content type
- [ ] **Markdown Enhancements** - Live preview, toolbar, syntax highlighting  
- [ ] **Media Management** - Image upload and asset management

#### 3.2 **Developer Experience**
- [ ] **Development Tools** - Better debugging and development workflow
- [ ] **Configuration API** - Extensible field type system
- [ ] **Testing Suite** - Comprehensive test coverage
- [ ] **Documentation** - API reference and integration guides

## 💡 **Key Architectural Insights**

### **Why This Architecture is Brilliant**
1. **Performance First**: Regular visitors get pure static HTML with zero CMS overhead
2. **Separation of Concerns**: Content editing completely separate from site performance  
3. **Build-Time Optimization**: Database content gets "baked into" static HTML during builds
4. **Progressive Enhancement**: Sites work without JavaScript, editing enhances with JavaScript
5. **Framework Agnostic**: Works with Hugo, Next.js, Jekyll, Gatsby, vanilla HTML, etc.

### **Production Flow**
```
Content Edits → HTTP API Server → Database
                     ↓
Static Site Build ← CLI Enhancement ← Database Content
                     ↓  
              Enhanced HTML → CDN/Deploy
```

### **Current Working Flow** 
```
✅ Browser Editor → (404) Missing Server → ❌
✅ CLI Enhancement ← Mock Data ← ✅
✅ Static HTML Generation ← ✅
```

**Gap**: The HTTP server that connects editor saves to database storage.

## 🗂️ **Next Steps: Server Implementation**

### **✅ Implemented - Unified Binary Architecture**
```
✅ COMPLETED: All server functionality integrated into unified binary
cmd/
├── serve.go                             # Runtime API server command
└── enhance.go                          # Build-time enhancement command
internal/
├── api/                                # HTTP handlers and middleware
├── db/                                 # Multi-database layer with sqlc
└── content/                            # Content management logic
```

### **Files to Modify**
- `lib/src/core/editor.js:91` - Wire up `ApiClient` to `handleSave` method
- `README.md` - Add server setup instructions
- `docker-compose.yml` - Add server for development stack

## 🎯 **Success Criteria**

### **Phase 1 Complete When**:
- ✅ HTTP server running on `localhost:8080` (or configurable port)
- ✅ All 5 API endpoints returning proper JSON responses
- ✅ JavaScript editor successfully saves edits to database
- ✅ CLI enhancement pulls latest content from database
- ✅ Full edit → save → build → view cycle working end-to-end

### **Production Ready When**:
- ✅ Multi-site support with proper site isolation
- ✅ Authentication and authorization working
- ✅ Database migrations and backup strategy
- ✅ CDN hosting for insertr.js library
- ✅ Deployment documentation and examples

## Current Architecture Status

### ✅ **What's Working Well**
- **CLI Parser**: Detects 41+ elements across demo site, generates stable IDs
- **Authentication System**: Professional login/edit mode toggle with visual states
- **Form System**: Dynamic modal forms with smart field detection
- **Build Pipeline**: Automated library building and copying to demo site
- **Development Experience**: Hot reload with Air integration

### 🔍 **Investigation Results**
- **File Analysis**: All legacy code removed, clean single implementation
- **Integration Testing**: CLI ↔ Library integration works seamlessly  
- **Demo Site**: Both index.html and about.html use modern library correctly
- **Content Detection**: CLI successfully identifies text/markdown/link content types

## Immediate Next Steps

### 🎯 **Priority 1: Content Persistence** 
**Goal**: Make edits survive page reload
- Create `lib/src/core/content-manager.js` for LocalStorage operations
- Integrate with existing form system for automatic save/restore
- Add change tracking and storage management

### 🎯 **Priority 2: Server Application**
**Goal**: Backend API for real content storage
- Design REST API for content CRUD operations
- Add authentication integration (OAuth/JWT)
- Consider database choice (SQLite for simplicity vs PostgreSQL for production)

---

## 🏁 **Ready to Build**

The analysis is complete. The architecture is sound and 90% implemented. 

**Next Action**: Create the HTTP server application that implements the API contract both clients expect.

This will immediately unlock:
- ✅ Real content persistence (not just LocalStorage)
- ✅ Multi-user editing capabilities  
- ✅ Production-ready content management
- ✅ Full integration between browser editor and CLI enhancement

*Let's build the missing server!*

## 🏗️ **Database Schema Architecture Decision** (Sept 2025)

**Issue**: Inlined SQLite schema in `database.go` creates multiple sources of truth, same problem we just solved with model duplication.

### **Recommended Solutions** (in order of preference):

#### **🎯 Option 1: Schema-as-Query Pattern** ⭐ **RECOMMENDED**
```
db/queries/
├── content.sql          # CRUD queries
├── versions.sql         # Version control queries  
├── schema_setup.sql     # Schema initialization as named query
└── indexes_setup.sql    # Index creation as named query
```

**Benefits**:
- ✅ Single source of truth (schema files)
- ✅ sqlc generates type-safe setup functions  
- ✅ Consistent with existing sqlc workflow
- ✅ Database-agnostic parameter syntax (`sqlc.arg()`)

**Implementation**:
```sql
-- name: InitializeSchema :exec
CREATE TABLE IF NOT EXISTS content (...);
CREATE TABLE IF NOT EXISTS content_versions (...);

-- name: CreateIndexes :exec  
CREATE INDEX IF NOT EXISTS idx_content_site_id ON content(site_id);
```

#### **🔧 Option 2: Migration Tool Integration**
- Use `goose`, `golang-migrate`, or `dbmate`
- sqlc natively supports parsing migration directories
- Professional database management with up/down migrations
- **Trade-off**: Additional dependency and complexity

#### **🗂️ Option 3: Embedded Schema Files**
- Use `go:embed` to read schema files at compile time
- Keep schema in separate `.sql` files
- **Trade-off**: Not processed by sqlc, less type safety

**✅ COMPLETED**: Implemented Option 1 (Schema-as-Query) with important discovery:

**sqlc Limitations Discovered**:
- ✅ sqlc generates functions for `CREATE TABLE` and `ALTER TABLE` statements
- ❌ sqlc does **NOT** generate functions for `CREATE INDEX` or `CREATE TRIGGER` statements  
- 🔧 **Solution**: Handle table creation via sqlc-generated functions, handle indexes/triggers manually in Go initialization code

**Final Implementation**:
- `db/*/setup.sql` - Contains table creation queries (sqlc generates type-safe functions)
- `internal/db/database.go` - Manual index/trigger creation using raw SQL
- **Best Practice**: Use sqlc for what it supports, manual SQL for what it doesn't

## 🔄 **Editor Cache Architecture & Content State Management** (Dec 2024)

### **Current Architecture Issues Identified**

**Problem**: Conflict between preview system and content persistence after save operations.

**Root Cause**: The unified Editor system was designed with preview-first architecture:
- `originalContent` stores DOM state when editing begins
- `clearPreview()` always restores to `originalContent` 
- This creates race condition: `applyContent()` → `clearPreview()` → content reverted

### **✅ Implemented Solution: Post-Save Baseline Update**

**Strategy**: After successful save, update the stored `originalContent` to match the new saved state.

**Implementation** (`lib/src/ui/Editor.js`):
```js
// In save handler:
context.applyContent(content);        // Apply new content to DOM
context.updateOriginalContent();      // Update baseline to match current DOM  
this.previewer.clearPreview();        // Clear preview (won't revert since baseline matches)
```

**Benefits**:
- ✅ Content persists after save operations
- ✅ Future cancellations restore to saved state, not pre-edit state
- ✅ Maintains clean preview functionality
- ✅ No breaking changes to existing architecture

### **Future Considerations: Draft System Architecture**

**Current State Management**:
- **Browser Cache**: DOM elements store current content state
- **Server Cache**: Database stores persisted content
- **No Intermediate Cache**: Edits are either preview (temporary) or saved (permanent)

**Potential Draft System Design**:

#### **Option 1: LocalStorage Drafts**
```js
// Auto-save drafts locally during editing
const draftKey = `insertr_draft_${contentId}_${siteId}`;
localStorage.setItem(draftKey, JSON.stringify({
    content: currentContent,
    timestamp: Date.now(),
    originalContent: baseline
}));
```

**Benefits**: Offline support, immediate feedback, no server load
**Drawbacks**: Per-browser, no cross-device sync, storage limits

#### **Option 2: Server-Side Drafts**
```js
// Auto-save drafts to server with special draft flag
PUT /api/content/{id}/draft
{
    "value": "Draft content...",
    "type": "markdown",
    "is_draft": true
}
```

**Benefits**: Cross-device sync, unlimited storage, collaborative editing potential
**Drawbacks**: Server complexity, authentication requirements, network dependency

#### **Option 3: Hybrid Draft System**
- **LocalStorage**: Immediate draft saving during typing
- **Server Sync**: Periodic sync of drafts (every 30s or on significant changes)
- **Conflict Resolution**: Handle cases where server content changed while editing draft

### **Cache Invalidation Strategy**

**Current Behavior**:
- Content is cached in DOM until page reload
- No automatic refresh when content changes on server
- No awareness of multi-user editing scenarios

**Recommended Enhancements**:

#### **Option A: Manual Refresh Strategy**
- Add "Refresh Content" button to editor interface
- Check server content before editing (warn if changed)
- Simple conflict resolution (server wins vs local wins vs merge)

#### **Option B: Polling Strategy**  
- Poll server every N minutes for content changes
- Show notification if content was updated by others
- Allow user to choose: keep editing, reload, or merge

#### **Option C: WebSocket Strategy**
- Real-time content change notifications
- Live collaborative editing indicators
- Automatic conflict resolution

### **Implementation Priority**

**Phase 1** (Immediate): ✅ **COMPLETED**
- Fix content persistence after save (baseline update approach)

**Phase 2** (Short-term): 
- Add LocalStorage draft auto-save during editing
- Implement draft recovery on page reload
- Basic conflict detection (server timestamp vs local timestamp)

**Phase 3** (Long-term):
- Server-side draft support
- Real-time collaboration features
- Advanced conflict resolution

### **Design Principles for Draft System**

1. **Progressive Enhancement**: Site works without drafts, drafts enhance UX
2. **Data Safety**: Never lose user content, even in edge cases
3. **Performance First**: Drafts shouldn't impact site loading for regular visitors
4. **Conflict Transparency**: Always show user what's happening with their content
5. **Graceful Degradation**: Fallback to basic editing if draft system fails

**Note**: Current architecture already supports foundation for all these enhancements through the unified Editor system and API client pattern.

## 🏗️ **Server-Hosted Static Sites Implementation** (Sept 2025)

### **✅ COMPLETED: Unified Binary HTTP Server**
The HTTP server has been successfully implemented and is production-ready:
- ✅ **Full REST API** - All content CRUD operations (`internal/api/handlers.go`)
- ✅ **Multi-Database Support** - SQLite + PostgreSQL with sqlc-generated queries
- ✅ **Authentication System** - JWT + mock tokens, ready for authentik integration
- ✅ **Bulk Operations** - Efficient bulk content retrieval (`injector.go:56-96`)
- ✅ **Content Enhancement** - Build-time content injection from database

### **🎯 NEW PRIORITY: Server-Hosted File Enhancement**

**Goal**: Enable real-time content updates for server-hosted static sites through database-driven file enhancement.

**Architecture**: Database as source of truth → Content changes → File updates → Immediate deployment

### **Phase 1: Core File Enhancement System**
- [ ] **Extend enhancer.go** - Add `EnhanceInPlace()` method for in-place file modification
- [ ] **Site Manager** - Create registration system for static site paths
- [ ] **Handler Integration** - Hook file enhancement into `UpdateContent()` API calls
- [ ] **Configuration Extension** - Add sites configuration to `insertr.yaml`

**Files to modify**:
- `internal/content/enhancer.go` - Add in-place enhancement methods
- `internal/api/handlers.go:225` - Integrate file enhancement trigger
- `insertr.yaml` - Add sites configuration section
- `cmd/serve.go` - Initialize site manager in server

### **Phase 2: Multi-Site Server Management**
- [ ] **CLI Site Commands** - `insertr sites register/list/enhance`
- [ ] **File Backup System** - Backup original files before enhancement
- [ ] **Error Handling** - Graceful file permission and disk space handling
- [ ] **Performance Optimization** - Selective file updates, change detection

### **Phase 3: Production Features**
- [ ] **Authentik Integration** - OIDC authentication for production deployment
- [ ] **Caddy Integration** - Reverse proxy configuration templates
- [ ] **Monitoring & Logging** - Track enhancement operations and errors
- [ ] **Multi-Environment** - Development vs production configuration

### **Implementation Approach: Leverage Existing Architecture**

**Reuse Existing Components**:
- ✅ **Bulk Injection** - `injector.go:56-96` already handles efficient content injection
- ✅ **Multi-Site Support** - `siteID` parameter used throughout API and database
- ✅ **Authentication** - `auth.go:47-67` supports JWT tokens ready for authentik
- ✅ **Content Client Interface** - `types.go:18-28` extensible for new features

**New Components** (minimal additions):
- **Site Manager** - Register static site paths and manage file enhancement
- **In-Place Enhancer** - Extend existing enhancer for file modification
- **Configuration** - Extend YAML config for site registration

### **Target Deployment Architecture**
```
┌─────────────────────────────────────┐
│           Caddy Reverse Proxy        │
├─────────────────┬───────────────────┤
│  Static Sites   │  Insertr Server   │
│  /site1/* ────→ │  :8080/api/*     │
│  /site2/* ────→ │  Authentication   │
│  /admin/* ────→ │  File Enhancement │
└─────────────────┴───────────────────┘
        │                    │
        ▼                    ▼
  ┌─────────────┐    ┌─────────────────┐
  │Static Files │    │   Database +    │
  │/var/www/    │◄───┤   Enhancement   │
  │  site1/     │    │   Engine        │
  │  site2/     │    └─────────────────┘
  └─────────────┘
```

**Content Update Workflow**:
1. Editor makes content change → API call to `/api/content/{id}`
2. Content saved to database (source of truth)
3. File enhancement triggered → Static files updated in-place
4. Changes immediately visible to visitors (served by Caddy)

### **Future CI/CD Integration Features** (Post-Server Implementation)

#### **External Build Trigger System**
- **Webhook Integration**: Trigger external CI/CD pipelines when content changes
- **GitHub Actions Templates**: Pre-built workflows for Hugo, Next.js, Jekyll + Insertr
- **Platform Integrations**: Native Netlify, Vercel, CloudFlare Pages integration
- **Build Status Tracking**: Monitor external build progress and deployment status

#### **Hybrid Deployment Models**
- **File + Pipeline Mode**: Server-hosted sites with optional CI/CD rebuilds
- **Content API Mode**: Headless CMS for external static site generators
- **Multi-Environment**: Staging/production deployment coordination
- **Build Caching**: Intelligent rebuilds based on content vs template changes

#### **Advanced Content Workflows**
- **Scheduled Publishing**: Time-based content activation
- **Content Approval**: Multi-user approval workflows before deployment
- **A/B Testing**: Content variations for different user segments
- **Rollback Integration**: Coordinate content rollbacks with deployment rollbacks

### **Draft System Foundation** (Ready for Extension)

**Current Architecture Supports**:
- ✅ **Bulk Operations** - `injector.go:56-96` efficient for batch content updates
- ✅ **Version Control** - Full version history with rollback capabilities
- ✅ **Content Types** - Extensible type system ready for draft fields

**Future Draft Features**:
- **Server-Side Drafts** - Extend `ContentItem` with `is_draft` field
- **Batch Publishing** - Publish multiple draft items simultaneously
- **Preview Mode** - View sites with draft content before publishing
- **Auto-Save Drafts** - Background saving during editing sessions

### **Benefits of Server-Hosted Approach**

1. **✅ Immediate Deployment** - Content changes are live instantly
2. **✅ Database Source of Truth** - No git-based workflow complexity
3. **✅ Content-Only Updates** - No template rebuilds required
4. **✅ Existing Infrastructure** - Leverages Caddy + authentik setup
5. **✅ Performance** - Static file serving with dynamic content injection
6. **✅ Multi-Site** - Single server manages multiple enhanced sites
7. **✅ Zero Downtime** - Updates don't require site rebuilds or deploys