workon 2.1.2 → 3.0.0

package/commands/registry.js

@@ -1,196 +0,0 @@
-const fs = require('fs');
-const path = require('path');
-
-/**
- * Command Registry for auto-discovery and management of commands
- * Scans the commands directory and provides unified access to all commands
- */
-class CommandRegistry {
-    constructor() {
-        this._commands = new Map();
-        this._initialized = false;
-    }
-
-    /**
-     * Initialize the registry by discovering all commands
-     */
-    async initialize() {
-        if (this._initialized) return;
-
-        await this._discoverCommands();
-        this._initialized = true;
-    }
-
-    /**
-     * Discover commands from the commands directory
-     * @private
-     */
-    async _discoverCommands() {
-        const commandsDir = path.join(__dirname);
-        
-        // Discover core commands
-        await this._discoverCommandsInDirectory(path.join(commandsDir, 'core'));
-        
-        // Discover extension commands
-        await this._discoverCommandsInDirectory(path.join(commandsDir, 'extensions'));
-    }
-
-    /**
-     * Discover commands in a specific directory
-     * @param {string} dir - Directory to scan
-     * @private
-     */
-    async _discoverCommandsInDirectory(dir) {
-        if (!fs.existsSync(dir)) return;
-
-        const entries = fs.readdirSync(dir, { withFileTypes: true });
-        
-        for (const entry of entries) {
-            if (entry.isDirectory()) {
-                const commandDir = path.join(dir, entry.name);
-                const indexFile = path.join(commandDir, 'index.js');
-                
-                if (fs.existsSync(indexFile)) {
-                    try {
-                        const CommandClass = require(indexFile);
-                        
-                        // Validate command structure
-                        if (this._isValidCommand(CommandClass)) {
-                            const metadata = CommandClass.metadata;
-                            this._commands.set(metadata.name, CommandClass);
-                        } else {
-                            console.error(`Invalid command structure in ${indexFile}`);
-                        }
-                    } catch (error) {
-                        console.error(`Failed to load command from ${indexFile}:`, error.message);
-                    }
-                }
-            }
-        }
-    }
-
-    /**
-     * Validate if a class is a proper command
-     * @param {Function} CommandClass - Command class to validate
-     * @returns {boolean}
-     * @private
-     */
-    _isValidCommand(CommandClass) {
-        try {
-            // Check if it has required static properties
-            const metadata = CommandClass.metadata;
-            return metadata && 
-                   typeof metadata.name === 'string' && 
-                   typeof metadata.displayName === 'string' &&
-                   typeof CommandClass.validation === 'object' &&
-                   typeof CommandClass.configuration === 'object' &&
-                   typeof CommandClass.processing === 'object';
-        } catch (error) {
-            return false;
-        }
-    }
-
-    /**
-     * Get all valid event names from discovered commands
-     * @returns {string[]}
-     */
-    getValidEventNames() {
-        this._ensureInitialized();
-        return Array.from(this._commands.keys());
-    }
-
-    /**
-     * Get command by name
-     * @param {string} name - Command name
-     * @returns {Function|null} Command class or null if not found
-     */
-    getCommandByName(name) {
-        this._ensureInitialized();
-        return this._commands.get(name) || null;
-    }
-
-    /**
-     * Get all commands for management UI
-     * @returns {Array<Object>} Array of command info objects
-     */
-    getCommandsForManageUI() {
-        this._ensureInitialized();
-        
-        const commands = [];
-        for (const [name, CommandClass] of this._commands) {
-            const metadata = CommandClass.metadata;
-            commands.push({
-                name: metadata.displayName,
-                value: name,
-                description: metadata.description
-            });
-        }
-        
-        return commands.sort((a, b) => a.name.localeCompare(b.name));
-    }
-
-    /**
-     * Get commands that support tmux integration
-     * @returns {Array<Object>} Array of commands with tmux support
-     */
-    getTmuxEnabledCommands() {
-        this._ensureInitialized();
-        
-        const tmuxCommands = [];
-        for (const [name, CommandClass] of this._commands) {
-            if (CommandClass.tmux) {
-                tmuxCommands.push({
-                    name,
-                    command: CommandClass,
-                    priority: CommandClass.tmux.getLayoutPriority ? CommandClass.tmux.getLayoutPriority() : 0
-                });
-            }
-        }
-        
-        return tmuxCommands.sort((a, b) => b.priority - a.priority);
-    }
-
-    /**
-     * Get all available commands with their metadata
-     * @returns {Array<Object>} Array of command metadata
-     */
-    getAllCommands() {
-        this._ensureInitialized();
-        
-        const commands = [];
-        for (const [name, CommandClass] of this._commands) {
-            commands.push({
-                name,
-                metadata: CommandClass.metadata,
-                hasValidation: !!CommandClass.validation,
-                hasConfiguration: !!CommandClass.configuration,
-                hasProcessing: !!CommandClass.processing,
-                hasTmux: !!CommandClass.tmux,
-                hasHelp: !!CommandClass.help
-            });
-        }
-        
-        return commands;
-    }
-
-    /**
-     * Ensure registry is initialized
-     * @private
-     */
-    _ensureInitialized() {
-        if (!this._initialized) {
-            throw new Error('CommandRegistry must be initialized before use. Call initialize() first.');
-        }
-    }
-
-    /**
-     * Clear the registry (useful for testing)
-     */
-    clear() {
-        this._commands.clear();
-        this._initialized = false;
-    }
-}
-
-// Export singleton instance
-module.exports = new CommandRegistry();

package/demo-colon-syntax.js

@@ -1,57 +0,0 @@
-#!/usr/bin/env node
-
-console.log(`
-🎯 COLON SYNTAX FEATURE DEMONSTRATION
-=====================================
-
-The new colon syntax allows selective command execution for projects:
-
-📋 SYNTAX:
-  workon <project>              # Execute all configured commands  
-  workon <project>:<command>    # Execute single command
-  workon <project>:<cmd1,cmd2>  # Execute multiple commands
-  workon <project>:help         # Show available commands
-
-✨ KEY FEATURES:
-  
-  1. BACKWARD COMPATIBLE
-     workon my-project          # Still works exactly as before
-  
-  2. SELECTIVE EXECUTION  
-     workon my-project:cwd      # Just change directory
-     workon my-project:claude   # Just open Claude
-     
-  3. SMART DEPENDENCIES
-     workon my-project:claude   # Auto-adds 'cwd' dependency
-     workon my-project:npm      # Auto-adds 'cwd' dependency
-     
-  4. MULTIPLE COMMANDS
-     workon my-project:cwd,claude,npm    # Custom combinations
-     
-  5. PROJECT HELP
-     workon my-project:help     # Show what commands are available
-     
-  6. ERROR VALIDATION
-     workon my-project:invalid  # Clear error messages
-     
-  7. SHELL MODE SUPPORT
-     workon my-project:cwd --shell       # Works with all flags
-
-🏗️ IMPLEMENTATION HIGHLIGHTS:
-
-  • Zero switchit changes needed - uses existing parameter parsing
-  • Simple string split logic: project.split(':')  
-  • Integrates perfectly with Command-Centric Architecture
-  • Smart layout detection works with any command combination
-  • Comprehensive validation and dependency resolution
-
-🎉 BENEFITS:
-
-  • Faster startup for individual commands
-  • Flexible workflow matching  
-  • Resource efficiency
-  • Better testing and debugging
-  • Foundation for future features (aliases, profiles, etc.)
-
-This feature transforms workon from "all-or-nothing" to "pick-what-you-need"!
-`);

package/docs/adr/001-command-centric-architecture.md

@@ -1,304 +0,0 @@
-# ADR-001: Command-Centric Architecture
-
-**Status:** Implemented  
-**Date:** 2025-08-07  
-**Deciders:** Israel Roldan  
-
-## Context
-
-The current architecture of the workon CLI has several maintainability issues:
-
-### Current Problems
-
-1. **Scattered Logic**: Command definitions, validation, help text, and processing logic are spread across multiple files
-2. **Manual Maintenance**: Hardcoded lists in multiple locations require updates when adding new commands
-3. **Tight Coupling**: Adding a new command requires touching 4-6 different files
-4. **No Auto-Discovery**: System doesn't automatically detect available commands
-5. **Inconsistent Patterns**: Different commands follow different implementation patterns
-
-### Current Architecture Issues
-
-When adding the NPM command, we had to modify:
-- `lib/validation.js` - Add to valid events list + validation logic
-- `cli/manage.js` - Add to event choices + configuration logic
-- `cli/open.js` - Add event processing logic  
-- `lib/tmux.js` - Add layout management
-- Multiple hardcoded arrays and switch statements
-
-This creates:
-- High cognitive load when adding features
-- Risk of forgetting to update all locations
-- Inconsistent user experience
-- Difficult testing and debugging
-
-## Decision
-
-We will refactor to a **Command-Centric Architecture** where each command is self-contained and owns its complete lifecycle.
-
-## Proposed Architecture
-
-### 1. Directory Structure
-
-```
-commands/
-├── core/                    # Built-in system commands
-│   ├── cwd/
-│   │   ├── index.js        # Main command class
-│   │   ├── processing.js   # Event processing logic
-│   │   └── tmux.js        # Tmux integration
-│   ├── ide/
-│   │   ├── index.js
-│   │   ├── validation.js  # IDE validation logic
-│   │   └── processing.js
-│   └── web/
-│       ├── index.js
-│       ├── validation.js
-│       └── processing.js
-├── extensions/              # Feature-rich commands
-│   ├── claude/
-│   │   ├── index.js
-│   │   ├── validation.js   # Claude config validation
-│   │   ├── configuration.js # Interactive setup
-│   │   ├── processing.js   # Event processing
-│   │   └── tmux.js        # Split terminal logic
-│   └── npm/
-│       ├── index.js
-│       ├── validation.js   # NPM config validation
-│       ├── configuration.js # Interactive setup
-│       ├── processing.js   # Event processing
-│       └── tmux.js        # Multi-pane layouts
-└── registry.js             # Auto-discovery system
-```
-
-### 2. Command Interface
-
-Each command implements a standardized interface:
-
-```javascript
-// commands/extensions/npm/index.js
-class NPMCommand {
-    static metadata = {
-        name: 'npm',
-        displayName: 'Run NPM command',
-        description: 'Execute NPM scripts in project directory',
-        category: 'development',
-        requiresTmux: true,
-        dependencies: ['npm']
-    }
-
-    static validation = {
-        // Command-specific validation
-        validateConfig(config) { /* ... */ }
-    }
-
-    static configuration = {
-        // Interactive setup prompts
-        async configureInteractive() { /* ... */ },
-        getDefaultConfig() { /* ... */ }
-    }
-
-    static processing = {
-        // Event processing
-        async processEvent(context) { /* ... */ },
-        generateShellCommand(context) { /* ... */ }
-    }
-
-    static tmux = {
-        // Tmux layout contributions
-        getLayoutPriority() { return 10; },
-        contributeToLayout(existingCommands) { /* ... */ }
-    }
-
-    static help = {
-        usage: 'npm: <script-name>',
-        examples: [
-            { config: 'npm: "dev"', description: 'Run npm run dev' },
-            { config: 'npm: { command: "test", watch: true }', description: 'Run tests in watch mode' }
-        ]
-    }
-}
-```
-
-### 3. Auto-Discovery System
-
-```javascript
-// commands/registry.js
-class CommandRegistry {
-    static async discoverCommands() {
-        // Scan commands/ directory
-        // Load command classes
-        // Build registry of available commands
-    }
-
-    static getValidEventNames() {
-        // Auto-generate from discovered commands
-    }
-
-    static getCommandByName(name) {
-        // Lookup command instance
-    }
-
-    static getCommandsForManageUI() {
-        // Get display info for interactive management
-    }
-}
-```
-
-### 4. Integration Points
-
-#### Validation System
-```javascript
-// lib/validation.js (simplified)
-class ProjectValidator {
-    validateEvents(events) {
-        const validCommands = CommandRegistry.getValidEventNames();
-        // Delegate to command-specific validation
-        for (const [eventName, config] of Object.entries(events)) {
-            const command = CommandRegistry.getCommandByName(eventName);
-            if (command) {
-                const result = command.validation.validateConfig(config);
-                if (result !== true) return result;
-            }
-        }
-    }
-}
-```
-
-#### Interactive Management
-```javascript
-// cli/manage.js (simplified)
-class manage extends command {
-    async getEventChoices() {
-        return CommandRegistry.getCommandsForManageUI();
-    }
-
-    async configureEvent(eventName) {
-        const command = CommandRegistry.getCommandByName(eventName);
-        return await command.configuration.configureInteractive();
-    }
-}
-```
-
-#### Event Processing
-```javascript
-// cli/open.js (simplified)
-class open extends command {
-    async processEvent(eventName, project, context) {
-        const command = CommandRegistry.getCommandByName(eventName);
-        return await command.processing.processEvent({
-            project,
-            isShellMode: context.isShellMode,
-            shellCommands: context.shellCommands
-        });
-    }
-}
-```
-
-### 5. Tmux Layout System
-
-Commands can contribute to tmux layouts with priority-based composition:
-
-```javascript
-// Smart layout detection
-const enabledCommands = getEnabledCommands(project);
-const tmuxContributors = enabledCommands
-    .filter(cmd => cmd.tmux)
-    .sort((a, b) => b.tmux.getLayoutPriority() - a.tmux.getLayoutPriority());
-
-const layout = tmuxContributors[0].tmux.contributeToLayout(enabledCommands);
-```
-
-## Implementation Plan
-
-### Phase 1: Foundation
-1. Create `commands/` directory structure
-2. Implement `CommandRegistry` with auto-discovery
-3. Create base command interface/abstract class
-4. Add command loading and registration system
-
-### Phase 2: Core Command Migration
-1. Extract `cwd` command to `commands/core/cwd/`
-2. Extract `ide` command to `commands/core/ide/`  
-3. Extract `web` command to `commands/core/web/`
-4. Update validation system to use registry
-
-### Phase 3: Extension Command Migration
-1. Extract `claude` command to `commands/extensions/claude/`
-2. Extract `npm` command to `commands/extensions/npm/`
-3. Update interactive management to use command definitions
-4. Update event processing to use command registry
-
-### Phase 4: Enhanced Features
-1. Add command dependency checking
-2. Implement plugin-like command loading
-3. Add command-specific help system
-4. Add command testing framework
-
-### Phase 5: Advanced Tmux Integration
-1. Implement priority-based layout composition
-2. Add layout conflict resolution
-3. Add custom layout definitions per command
-4. Add layout preview/testing
-
-## Benefits
-
-### For Developers
-- **Single Responsibility**: Each command owns its complete lifecycle
-- **Easy Testing**: Isolated command logic with clear interfaces
-- **Plugin Architecture**: Easy to add/remove commands
-- **Better Organization**: Everything related to a command in one place
-- **Reduced Coupling**: Commands don't need to know about each other
-
-### For Users
-- **Consistent Experience**: All commands follow same patterns
-- **Better Help**: Command-specific documentation and examples
-- **Auto-Discovery**: New commands automatically available
-- **Extensibility**: Easy to add custom commands
-
-### For Maintenance
-- **No More Hardcoded Lists**: Commands auto-register themselves
-- **Easier Debugging**: Clear command boundaries
-- **Simpler Refactoring**: Changes contained within command scope
-- **Better Documentation**: Command documentation co-located with code
-
-## Risks and Mitigations
-
-### Risk: Increased Complexity
-**Mitigation**: Provide clear base classes and documentation. Start with simple commands.
-
-### Risk: Performance Impact
-**Mitigation**: Lazy loading of commands. Cache registry after initial discovery.
-
-### Risk: Breaking Changes
-**Mitigation**: Implement alongside existing system. Gradual migration path.
-
-### Risk: Over-Engineering
-**Mitigation**: Start simple. Add complexity only when needed. Focus on current pain points.
-
-## Success Criteria
-
-1. Adding a new command requires touching only files in that command's directory
-2. Command validation, configuration, and processing logic is co-located
-3. Interactive management automatically discovers and presents new commands
-4. Tmux layouts compose automatically based on enabled commands
-5. Help system provides command-specific guidance
-6. Testing can be done per-command with clear interfaces
-
-## Alternative Considered
-
-### Plugin System with External Commands
-- **Pros**: Ultimate flexibility, true plugin architecture
-- **Cons**: Complexity of plugin loading, versioning, security concerns
-- **Decision**: Too complex for current needs. Start with internal command structure.
-
-### Monolithic Command Classes
-- **Pros**: Single file per command
-- **Cons**: Large files, harder to test specific aspects
-- **Decision**: Multi-file approach provides better separation of concerns.
-
-## References
-
-- Current architecture pain points identified during NPM command implementation
-- Command pattern design principles
-- Plugin architecture best practices
-- CLI framework patterns (e.g., Angular CLI, Vue CLI command structures)