Backend changes:
- Updated parser to treat <span> elements as markdown by default
- Changed span content type detection from ContentText to ContentMarkdown
- Spans now support **bold**, *italic*, and [links](url) formatting
Frontend changes:
- Updated content type detection to match backend behavior
- Frontend now treats spans as markdown elements for consistent processing
- Editor preview behavior now matches server-side enhancement
Benefits:
- <span class='highlight'>**bold** text</span> now processes markdown correctly
- Inline elements maintain all styling while supporting rich formatting
- Complete frontend/backend consistency for span element handling
- Expands markdown support to common inline wrapper elements
Tested and verified:
- Span elements preserve all classes, IDs, and styles
- Bold, italic, and link formatting works in span elements
- Content type properly detected as 'markdown' in both systems
- Problem: Element ID collisions between similar elements (logo h1 vs hero h1)
causing content to be injected into wrong elements
- Root cause: Enhancer used naive tag+class matching instead of parser's
sophisticated semantic analysis for element identification
Systematic solution:
- Enhanced parser architecture with exported utilities (GetClasses, ContainsClass)
- Added FindElementInDocument() with content-based semantic matching
- Replaced naive findAndInjectNodes() with parser-based element matching
- Removed code duplication between parser and enhancer packages
Backend improvements:
- Moved ID generation to backend for single source of truth
- Added ElementContext struct for frontend-backend communication
- Updated API handlers to support context-based content ID generation
Frontend improvements:
- Enhanced getElementMetadata() to extract semantic context
- Updated save flow to handle both enhanced and non-enhanced elements
- Improved API client to use backend-generated content IDs
Result:
- Unique content IDs: navbar-logo-200530 vs hero-title-a1de7b
- Precise element matching using content validation
- Single source of truth for DOM utilities in parser package
- Eliminated 40+ lines of duplicate code while fixing core bug
🏗️ **Major Architecture Refactoring: Separate CLI + Server → Unified Binary**
**Key Changes:**
✅ **Unified Binary**: Single 'insertr' binary with subcommands (enhance, serve)
✅ **Preserved Database Architecture**: Maintained sophisticated sqlc multi-DB setup
✅ **Smart Configuration**: Viper + YAML config with CLI flag precedence
✅ **Updated Build System**: Unified justfile, Air, and npm scripts
**Command Structure:**
- `insertr enhance [input-dir]` - Build-time content injection
- `insertr serve` - HTTP API server (dev + production modes)
- `insertr --config insertr.yaml` - YAML configuration support
**Architecture Benefits:**
- **Shared Database Layer**: Single source of truth for content models
- **Flexible Workflows**: Local DB for dev, remote API for production
- **Simple Deployment**: One binary for all use cases
- **Better UX**: Consistent configuration across build and runtime
**Preserved Features:**
- Multi-database support (SQLite + PostgreSQL)
- sqlc code generation and type safety
- Version control system with rollback
- Professional API endpoints
- Content enhancement pipeline
**Development Workflow:**
- `just dev` - Full-stack development (API server + demo site)
- `just serve` - API server only
- `just enhance` - Build-time content injection
- `air` - Hot reload unified binary
**Migration:** Consolidated insertr-cli/ and insertr-server/ → unified root structure
