Modularize processors

README.md

@@ -9,7 +9,7 @@
 
 A TypeScript-based workflow system for managing document templates and collections. Automate your job applications, blog posts, and other document workflows with customizable templates and status tracking.
 
-**Status:** v1.0.0 Release Candidate - Job application workflow is fully functional and tested.
+**Status:** v1.0.0 Release Candidate - Job application and presentation workflows are fully functional and tested.
 
 ## 🎯 What It Does
 
@@ -41,7 +41,8 @@ And if you're using Git to track your repository (recommended!) you can commit c
 - 🔄 **Status tracking** - Move collections through workflow stages (active → submitted → interview → offered)
 - 📁 **Project-specific customization** - Override templates and workflows per project
 - 🌐 **Web scraping** - Automatically fetch job descriptions from URLs
-- 📦 **Document formatting** - Convert markdown to DOCX, HTML, PDF via pandoc
+- 📦 **Modular document processing** - Pluggable processors for different content types (Mermaid, PlantUML, Emoji)
+- 🔧 **Smart converters** - Workflow-specific processing (clean documents for jobs, rich diagrams for presentations)
 - 🔧 **Repository-agnostic** - Works from any directory, like git
 
 ### Job Application Workflow (Fully Implemented)
@@ -54,13 +55,45 @@ And if you're using Git to track your repository (recommended!) you can commit c
 - **Update metadata:** `wf update job collection_id --url "https://new-url"`
 - **Migration tool:** `wf migrate` (from legacy bash-based system)
 
+### Presentation Workflow (New!)
+
+- **Create presentations:** `wf create presentation "My Presentation Title"`
+- **Mermaid diagrams:** Automatic processing of `mermaid:name` code blocks
+- **Rich formatting:** Convert to PPTX with embedded diagrams
+- **Status tracking:** Draft → review → published
+- **Asset management:** Auto-generated images in `assets/` directory
+
+Example Mermaid block:
+
+````markdown
+```mermaid:architecture {align=center, width=90%}
+graph TB
+    Frontend --> Backend
+    Backend --> Database
+```
+````
+
 ### Template System
 
 - **Inheritance:** Project templates override system defaults
 - **Variables:** `{{user.name}}`, `{{company}}`, `{{role}}`, `{{date}}`, etc.
 - **Multiple variants:** Default, mobile-focused, frontend-specific templates
 - **Flexible:** Add your own templates and variables
 
+### Processor System
+
+- **Modular Processing:** Each workflow specifies which processors to use
+- **Job Applications:** Clean documents with no special processing
+- **Presentations:** Rich diagrams with Mermaid, PlantUML support
+- **Extensible:** Add custom processors for your specific needs
+
+Available processors:
+
+- 🧩 **Mermaid** - Generate diagrams from code blocks
+- 🌱 **PlantUML** - Create UML diagrams and flowcharts
+- 😀 **Emoji** - Convert shortcodes to Unicode emoji
+- 🔌 **Custom** - Build your own processors
+
 ## 🚀 Quick Start
 
 ### Prerequisites

TODO.md

@@ -6,11 +6,12 @@
 
 ### Documentation & Polish
 
-- [ ] **Update README.md**
-  - [ ] Reflect current working features accurately
-  - [ ] Remove references to unimplemented features
+- [x] **Update README.md**
+  - [x] Reflect current working features accurately
+  - [x] Added processor system documentation
+  - [x] Added presentation workflow documentation
   - [ ] Add clear installation instructions
-  - [ ] Include realistic examples and use cases
+  - [x] Include realistic examples and use cases
 
 - [ ] **Create Release Documentation**
   - [ ] Write CHANGELOG.md for v1.0.0
@@ -66,11 +67,13 @@
 - ✅ **CLI Commands**
   - `wf init` - Initialize project with workflows
   - `wf create job` - Create job applications with templates
+  - `wf create presentation` - Create presentations with Mermaid support
   - `wf status` - Update collection status (active → submitted → interview → etc.)
   - `wf list` - List collections with filtering
-  - `wf format` - Convert markdown to DOCX via pandoc
+  - `wf format` - Convert markdown to DOCX/PPTX with smart processor selection
   - `wf add` - Add items (like interview notes) to existing collections
   - `wf update` - Update collection metadata and scrape URLs
+  - `wf commit` - Git commit with proper handling of moved files
   - `wf migrate` - Migrate from legacy bash-based system
 
 - ✅ **Template System**
@@ -79,6 +82,14 @@
   - Template inheritance (project → system fallback)
   - Support for multiple template variants
 
+- ✅ **Processor System**
+  - Modular processor architecture with registry
+  - Workflow-specific processor configuration
+  - Mermaid diagram processing with PNG/SVG output
+  - Emoji shortcode conversion
+  - PlantUML diagram support
+  - Smart processor selection (none for jobs, mermaid for presentations)
+
 - ✅ **Web Scraping**
   - Reliable fallback chain: wget → curl → native HTTP
   - URL scraping for job descriptions

docs/adr/003-processor-modularization.md

@@ -0,0 +1,99 @@
+# ADR-003: Processor Modularization Architecture
+
+## Status
+
+Accepted
+
+## Context
+
+The markdown-workflow system needs to support different types of content processing for different workflows:
+
+- **Job applications** need clean, minimal formatting without special processing
+- **Presentations** need rich diagram processing with Mermaid, PlantUML, and other visual elements
+- **Blog posts** might need emoji processing, image optimization, and other content enhancements
+- **Future workflows** might need custom processors for specific content types
+
+The original system applied all processing to all content types, which was inefficient and could introduce unwanted artifacts in simple documents. A modular processor system is needed to:
+
+1. Allow workflows to specify which processors they need
+2. Keep job applications clean and professional
+3. Enable rich processing for presentations and visual content
+4. Provide an extensible architecture for future processors
+5. Maintain clear separation of concerns between converters and processors
+
+## Decision
+
+We will implement a **modular processor architecture** with the following components:
+
+### 1. Base Processor System
+
+- `BaseProcessor` abstract class defining the processor interface
+- `ProcessorRegistry` for registering and managing processors
+- `ProcessingContext` for passing context between processors
+- Support for ordered processor execution
+
+### 2. Workflow-Specific Configuration
+
+- Each workflow can specify which processors to enable in their YAML definition
+- Processors can be configured with workflow-specific parameters
+- Default processor selection based on converter type (e.g., presentations default to Mermaid)
+
+### 3. Available Processors
+
+- **MermaidProcessor**: Generate PNG/SVG diagrams from `mermaid:name` code blocks
+- **EmojiProcessor**: Convert emoji shortcodes to Unicode characters
+- **PlantUMLProcessor**: Create UML diagrams and flowcharts
+- **Custom processors**: Extensible architecture for future needs
+
+### 4. Smart Converter Integration
+
+- `PandocConverter`: Uses specified processors for basic document conversion
+- `PresentationConverter`: Optimized for presentation workflows with rich diagram processing
+- Converters handle processor orchestration and asset management
+
+### 5. Workflow Configuration Example
+
+```yaml
+# Job workflow - clean documents, no processors
+actions:
+  - name: "format"
+    converter: "pandoc"
+    formats: ["docx"]
+    # No processors specified = clean documents
+
+# Presentation workflow - rich diagrams
+actions:
+  - name: "format"
+    converter: "presentation"
+    formats: ["pptx"]
+    processors:
+      - name: "mermaid"
+        enabled: true
+        config:
+          output_format: "png"
+          theme: "default"
+```
+
+## Consequences
+
+### Positive
+
+- **Workflow-appropriate processing**: Job applications remain clean, presentations get rich diagrams
+- **Performance**: Only necessary processors run for each workflow type
+- **Extensibility**: Easy to add new processors for future needs
+- **Clear separation**: Processors focus on content transformation, converters handle orchestration
+- **Configuration flexibility**: Each workflow can customize processor behavior
+
+### Negative
+
+- **Increased complexity**: More moving parts in the system architecture
+- **Configuration overhead**: Each workflow must specify its processor needs
+- **Testing complexity**: Need to test processor combinations and configurations
+
+### Mitigated Risks
+
+- **Default behavior**: Workflows get sensible defaults (e.g., presentations auto-enable Mermaid)
+- **Graceful fallback**: System works even if processors fail or are unavailable
+- **Clear documentation**: Processor system is well-documented with examples
+
+This architecture enables the system to scale from simple document workflows to complex content processing while maintaining clean separation of concerns and workflow-appropriate behavior.

docs/adr/README.md

@@ -48,6 +48,8 @@ Each ADR should follow this structure:
 | Number | Title                                                               | Status   |
 | ------ | ------------------------------------------------------------------- | -------- |
 | 001    | [Workflow Engine Architecture](001-workflow-engine-architecture.md) | Accepted |
+| 002    | [Simplicity Over Completeness](002-simplicity-over-completeness.md) | Accepted |
+| 003    | [Processor Modularization](003-processor-modularization.md)         | Accepted |
 
 ## Creating New ADRs