Feature Discussion

[peterjthomson]

Ledger Strategic Directions Exploration

This document explores six potential feature directions, evaluating feasibility, architecture impact, and implementation approach based on Ledger's current codebase.---

Current Architecture Summary

graph TB
    subgraph Renderer["Renderer (React)"]
        CommitPanel[CommitCreatePanel]
        PRPanel[PRDetailPanel]
        WorktreePanel[WorktreeDetailPanel]
    end
    
    subgraph Main["Main Process (Node.js)"]
        GitService[git-service.ts]
        Settings[settings-service.ts]
        IPC[IPC Handlers]
    end
    
    subgraph External["External"]
        Git[git / simple-git]
        GH[gh CLI]
    end
    
    Renderer -->|IPC| Main
    GitService --> Git
    GitService --> GH

Loading

Key integration points for AI/automation:

• CommitCreatePanel.tsx - Commit message input, branch creation, PR creation
• PRDetailPanel.tsx - Already has AI comment detection/filtering
• git-service.ts - All git operations, ~3300 lines
• settings-service.ts - Persistent JSON config

---

Direction 1: AI Embedded Everywhere (Haiku/Light Models)

Vision: Make Ledger feel "magical" with contextual AI assistance - commit message suggestions, commit explanations, diff summaries.Effort: Medium | Impact: High | Complexity: Low-Medium

Where AI Would Integrate

| Feature | Location | Model Use ||---------|----------|-----------|| Commit message suggestions | CommitCreatePanel | Analyze staged diff, suggest message || "What does this commit do?" | DiffPanel / git graph | Summarize changes in plain English || Branch name suggestions | CommitCreatePanel | Generate from commit context || PR description drafts | PR creation flow | Summarize branch changes || Conflict resolution hints | Merge conflicts | Explain conflicts simply |

Proposed Architecture

graph LR
    subgraph Main["Main Process"]
        AIService[ai-service.ts]
        GitService[git-service.ts]
    end
    
    subgraph Providers["AI Providers"]
        Haiku[Claude Haiku]
        Local[Local/Ollama]
    end
    
    Renderer -->|"suggestCommitMessage(diff)"| AIService
    AIService -->|API| Providers
    AIService -->|cache| Cache[(LRU Cache)]

Loading

New files needed:

• lib/main/ai-service.ts - AI provider abstraction
• Settings extension for API key storage (encrypted)

Key design decisions:

1. Default off, opt-in - User enables in settings with API key
2. Haiku-first - Fast, cheap, good enough for summaries
3. Graceful degradation - Falls back to manual if API fails
4. Caching - Cache summaries by commit hash to avoid re-calling

---

Direction 2: Pre-coding Workflow Integration (Notion/Linear)

Vision: Sync tickets from project management tools, link branches to tickets, see task context while coding.Effort: High | Impact: Medium-High | Complexity: High

Potential Integrations

| Service | Use Case | API Complexity ||---------|----------|----------------|| Linear | Link branches to issues, auto-update status | OAuth + GraphQL || Notion | Link to task pages, pull context | OAuth + REST || GitHub Issues | Already accessible via gh | Low - use existing CLI || Jira | Enterprise workflow | Complex OAuth |

Architecture Sketch

graph TB
    subgraph Integrations["Integration Services"]
        Linear[linear-service.ts]
        Notion[notion-service.ts]
        GitHub[gh CLI - existing]
    end
    
    subgraph UI["Ticket Panel"]
        TicketList[TicketList.tsx]
        TicketDetail[TicketDetail.tsx]
    end
    
    Settings -->|API keys| Integrations
    Integrations -->|fetch tickets| UI
    BranchList -->|"linked ticket"| TicketDetail

Loading

Challenges:

• OAuth flows in Electron (redirect handling)
• Multiple provider configuration
• Keeping sync up-to-date
• Mapping branch names to tickets (conventions or manual linking)

Recommendation: Start with GitHub Issues (already have gh CLI) before external services.---

Direction 3: Advanced AI with Model Choice

Vision: Power users can select their preferred model - Claude Opus for complex tasks, GPT-4o, local Ollama, etc.Effort: Medium | Impact: Medium | Complexity: Medium

Model Provider Architecture

// lib/main/ai-service.ts
interface AIProvider {
  id: string;
  name: string;
  requiresKey: boolean;
  models: string[];
  complete(prompt: string, model?: string): Promise<string>;
}

// Implementations
class AnthropicProvider implements AIProvider { ... }
class OpenAIProvider implements AIProvider { ... }
class OllamaProvider implements AIProvider { ... }

Settings UI Extension

Would extend existing settings infrastructure in settings-service.ts:

interface Settings {
  // Existing...
  ai?: {
    enabled: boolean;
    provider: 'anthropic' | 'openai' | 'ollama' | 'custom';
    model: string;
    apiKey?: string; // encrypted
    endpoint?: string; // for custom/ollama
  };
}

Trade-off: More flexibility vs. more configuration complexity. Consider a "just works" default (Haiku with built-in key for basic features) with power-user overrides.---

Direction 4: Agent Dispatcher (SDK Integration)

Vision: Dispatch coding agents to worktrees, track their work, manage multiple agents.Effort: High | Impact: High | Complexity: High

Current Agent Detection

Ledger already detects agent worktrees (from electron.d.ts):

export type WorktreeAgent = 'cursor' | 'claude' | 'conductor' | 'gemini' | 'junie' | 'unknown' | 'working-folder'

Agent Dispatcher Architecture

graph TB
    subgraph Ledger["Ledger"]
        Dispatcher[AgentDispatcher]
        WorktreeManager[WorktreeManager]
        UI[Agent Control Panel]
    end
    
    subgraph Agents["Agent SDKs"]
        Claude[Claude Code SDK]
        Cursor[Cursor Agent API]
        Aider[Aider CLI]
    end
    
    subgraph Worktrees["Worktrees"]
        WT1[agent-1/]
        WT2[agent-2/]
        WT3[agent-3/]
    end
    
    UI -->|"dispatch task"| Dispatcher
    Dispatcher -->|"create"| WorktreeManager
    WorktreeManager --> Worktrees
    Dispatcher -->|"invoke"| Agents
    Agents -->|"work in"| Worktrees

Loading

New Capabilities Needed

1. Task dispatch - Send prompt + context to agent
2. Progress monitoring - Track agent work (file changes, terminal output)
3. Result collection - Diff review when agent completes
4. Multi-agent coordination - Multiple agents on different tasks

SDKs to consider:

• Claude Code SDK (when available)
• Aider (CLI-based, easy to wrap)
• Custom MCP tool servers

---

Direction 5: Running Worktrees (Dev Environment)

Vision: Each worktree can have running processes - test runners, dev servers, containerized environments.Effort: High | Impact: Very High | Complexity: High

Process Management Architecture

graph TB
    subgraph WorktreeEnv["Worktree Environment"]
        Detection[Environment Detection]
        Runners[Runner Registry]
        Processes[Process Manager]
    end
    
    subgraph Detected["Auto-detected"]
        Laravel[Laravel Herd]
        Node[Node/npm/pnpm]
        Rails[Rails/bundle]
        Electron[Electron-vite]
        Docker[Docker Compose]
    end
    
    Detection -->|"detect stack"| Detected
    Runners -->|"available commands"| UI
    Processes -->|"start/stop"| Runners

Loading

Environment Detection

interface WorktreeEnvironment {
  worktreePath: string;
  detected: {
    type: 'laravel' | 'node' | 'rails' | 'electron' | 'docker' | 'unknown';
    packageManager?: 'npm' | 'pnpm' | 'yarn' | 'composer' | 'bundle';
    scripts?: Record<string, string>; // from package.json, etc.
    dockerCompose?: boolean;
    herdSite?: string; // Laravel Herd integration
  };
  runningProcesses: Process[];
}

UI Concept

Each worktree card could show:

• Detected stack icon (Laravel, Node, etc.)
• Quick-run buttons (test, dev, build)
• Running process indicators
• Terminal output preview

Integration with Laravel Herd:

• Detect Herd sites via ~/.config/herd/config.json
• Link to open in browser
• Show PHP/Node version

---

Direction 6: Code Review Control (Bot Review Integration)

Vision: Extract bot reviews (CodeRabbit, Copilot, etc.) into dedicated UI, dispatch reviews, co-mingle with local analysis.Effort: Medium | Impact: Medium-High | Complexity: Medium

Current State

PRDetailPanel already has AI detection:

const AI_AUTHORS = ['copilot', 'github-actions', 'dependabot', 'renovate', 'coderabbit', 'vercel', 'netlify', 'codecov']

And filtering UI with "Show AI comments" toggle.

Enhanced Architecture

graph TB
    subgraph Sources["Review Sources"]
        GitHub[GitHub PR Reviews]
        CodeRabbit[CodeRabbit API]
        Local[Local Analysis]
    end
    
    subgraph ReviewPanel["Review Control Panel"]
        BotReviews[Bot Reviews Tab]
        HumanReviews[Human Reviews Tab]
        LocalInsights[Local Insights Tab]
        Actions[Review Actions]
    end
    
    Sources -->|"aggregate"| ReviewPanel
    Actions -->|"dispatch"| CodeRabbit
    Actions -->|"comment"| GitHub

Loading

New Features

1. Dedicated bot review panel - Separate from human conversation
2. CodeRabbit dispatch - Trigger review on demand
3. Review summary - AI-powered summary of all review comments
4. Review checklist - Track which suggestions were addressed
5. Local static analysis - ESLint, type errors shown inline

CodeRabbit Integration

// lib/main/coderabbit-service.ts
async function triggerCodeRabbitReview(prNumber: number): Promise<void> {
  // Option 1: Comment trigger (@coderabbitai review)
  await commentOnPR(prNumber, '@coderabbitai review');
  
  // Option 2: Direct API (if available)
  // await codeRabbitAPI.requestReview(repo, prNumber);
}

---

Recommended Priority

Based on effort/impact ratio and building blocks:| Priority | Direction | Rationale ||----------|-----------|-----------|| 1 | AI Embedded (Haiku) | Low complexity, high delight, enables other features || 2 | Code Review Control | Builds on existing PR UI, clear user value || 3 | Running Worktrees | High value for power users, complex but self-contained || 4 | Model Choice | Natural extension of #1 once AI service exists || 5 | Agent Dispatcher | Depends on external SDK maturity || 6 | Workflow Integration | High complexity, requires OAuth infrastructure |---

Questions to Clarify Direction

1. AI integration approach: Built-in API key (simpler, cost to you) vs. BYOK only (no cost, more friction)?
2. Running worktrees scope: Full containerization (complex) vs. process runner only (simpler)?