- Remove obsolete cmd/auto_enhance.go command (replaced by unified enhance)
- Implement EnhanceInPlace method using unified pipeline
- Remove generated demo files from git tracking
- Verify all functionality works after cleanup:
* go build successful
* enhance command working correctly
* unified pipeline (discovery → ID generation → content injection) verified
* clean command structure (only enhance, serve, restore commands)
The codebase is now clean with no legacy auto-enhance references or stub implementations. All functionality consolidated into the unified Discoverer + Enhancer architecture.
- Rename AutoEnhancer to Discoverer with clear element discovery focus
- Implement unified enhancement pipeline in Enhancer:
* Phase 1: Element Discovery (configurable, respects existing insertr classes)
* Phase 2: ID Generation via engine
* Phase 3: Content Injection via engine
- Add EnhancementConfig and DiscoveryConfig for flexible configuration
- Update all method names and references (discoverNode, DiscoveryResult, etc.)
- Support both manual class insertion and automatic discovery
- Maintain single enhance command interface while providing unified internal pipeline
- Update all constructors to use new configuration-based approach
This establishes the clean Discoverer + Enhancer architecture discussed, with discovery as configurable first phase and enhancement as unified pipeline.
- Move all ContentItem, ContentClient, ContentResponse types to engine/types.go as single source of truth
- Remove duplicate type definitions from content/types.go
- Update all imports across codebase to use engine types
- Enhance engine to extract existing data-content-id from HTML markup
- Simplify frontend to always send html_markup, let server handle ID extraction/generation
- Fix contentId reference errors in frontend error handling
- Add getAttribute helper method to engine for ID extraction
- Add GetAllContent method to engine.DatabaseClient
- Update enhancer to use engine.ContentClient interface
- All builds and API endpoints verified working
This resolves the 400 Bad Request errors and creates a unified architecture where the server is the single source of truth for all ID generation and content type management.
Database Structure Cleanup:
- Move all SQL files from ./db/ to ./internal/db/
- Update sqlc.yaml to use new paths (preserving schema+setup.sql hack)
- Consolidate database-related code in single directory
- Remove empty ./db/ directory
Injector Migration:
- Move injector.go from content package to engine package
- Update ContentClient interface to return map instead of slice for GetBulkContent
- Update database client implementation to match interface
- Remove injector dependency from enhancer (stub implementation)
Demo-Site Consolidation:
- Move demo-site to test-sites/demo-site for better organization
- Update build scripts to use new demo-site location
- Maintain all functionality while improving project structure
This continues the unified architecture consolidation by moving core content
processing logic to the engine and organizing related files properly.
- Remove internal/parser package and all legacy ID generation logic
- Update enhancer and auto_enhancer to use unified engine functions
- Migrate utility functions (FindViableChildren, HasEditableContent) to engine
- Create stub enhancer implementation that uses unified engine architecture
- Ensure all enhancement workflows now go through single unified system
- Remove parser dependencies and consolidate content processing logic
This completes the cleanup phase - all components now use unified engine
instead of fragmented ID generation systems.
Critical fixes:
- Fixed HTML injection to preserve original element attributes, classes, and styling
- Updated markdown processor to generate inline content instead of wrapped paragraphs
- Enhanced content type handling: database type now takes precedence over parser detection
- Eliminated nested <p> tags issue that was causing invalid HTML
Key improvements:
- Elements like <p class='lead insertr' style='color: blue;'> now maintain all attributes
- Markdown **bold**, *italic*, [links](url) inject as inline formatted content
- Database content type (markdown/text/link) overrides parser auto-detection
- Clean HTML output without structural corruption
Before: <p class='lead'><p>**bold**</p></p> (broken)
After: <p class='lead'>**bold text**</p> (clean)
Server remains source of truth for markdown processing with zero runtime overhead.
Backend implementation:
- Add goldmark dependency for markdown processing
- Create MarkdownProcessor with minimal config (bold, italic, links only)
- Update content injector with HTML injection capabilities
- Add injectHTMLContent() for safe DOM manipulation
- Server now converts **bold**, *italic*, [links](url) to HTML during enhancement
Frontend alignment:
- Restrict marked.js to match server capabilities
- Disable unsupported features (headings, lists, code blocks, tables)
- Update turndown rules to prevent unsupported markdown generation
- Frontend editor preview now matches server output exactly
Server as source of truth:
- Build-time markdown→HTML conversion during enhancement
- Zero runtime overhead for end users
- Consistent formatting between editor preview and final output
- Raw markdown stored in database, HTML served to visitors
Tested features:
- **bold** → <strong>bold</strong> ✅
- *italic* → <em>italic</em> ✅
- [text](url) → <a href="url">text</a> ✅
- 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
- Add SiteManager for registering and managing static sites with file-based enhancement
- Implement EnhanceInPlace method for in-place file modification using database content
- Integrate automatic file enhancement triggers in UpdateContent API handler
- Add comprehensive site configuration support in insertr.yaml with auto-enhancement
- Extend serve command to automatically register and manage configured sites
- Add backup system for original files before enhancement
- Support multi-site hosting with individual auto-enhancement settings
- Update documentation for server-hosted enhancement workflow
This enables real-time content deployment where database content changes
immediately update static files without requiring rebuilds or redeployment.
The database remains the single source of truth while maintaining static
file performance benefits.
🏗️ **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
