diff --git a/memory/docs/features/manage_rules/refactoring_plan.md b/memory/docs/features/manage_rules/archive_refactoring_plan.md similarity index 100% rename from memory/docs/features/manage_rules/refactoring_plan.md rename to memory/docs/features/manage_rules/archive_refactoring_plan.md diff --git a/memory/docs/features/manage_rules/historical_task_plan.md b/memory/docs/features/manage_rules/historical_task_plan.md new file mode 100644 index 0000000..f517a91 --- /dev/null +++ b/memory/docs/features/manage_rules/historical_task_plan.md @@ -0,0 +1,77 @@ +# Refactoring Task Plan (As Executed) + +## 🎯 Goal + +This document breaks down the work performed during the internal refactoring of the `rulebook-ai` core and CLI components. The objective was to improve code modularity, maintainability, and extensibility by separating declarative assistant specifications from the file-generation engine. + +This plan is a historical record of the tasks completed, based on the final design in the [Refactoring Plan](./refactoring_plan.md). + +--- + +### Phase 1: Separate Specification from Logic + +**Description:** This phase focused on creating a purely data-driven architecture, separating the "what" (the assistant spec) from the "how" (the generation engine). + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| +| **1.1** | Define the `AssistantSpec` dataclass in a new `assistants.py` file. | P0 | Completed | - | +| **1.2** | Create the `SUPPORTED_ASSISTANTS` list in `assistants.py` as the single source of truth. | P0 | Completed | 1.1 | +| **1.3** | Refactor `RuleManager` in `core.py` into a generic engine that interprets `AssistantSpec` data. | P0 | Completed | 1.2 | +| **1.4** | Implement private generation strategies (`_strategy_flatten_and_number`, etc.) in `RuleManager`. | P0 | Completed | 1.3 | +| **1.5** | Refactor public methods (`install`, `sync`, `clean_rules`) to be data-driven and compliant with the design spec. | P0 | Completed | 1.4 | + +### Phase 2: Simplify and Automate the CLI + +**Description:** This phase refactored the command-line interface to be dynamically generated from the single source of truth, eliminating hardcoded logic. + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| +| **2.1** | Refactor `cli.py` to dynamically generate assistant flags (e.g., `--cursor`) from `SUPPORTED_ASSISTANTS`. | P1 | Completed | 1.2 | +| **2.2** | Simplify `handle_install` and `handle_sync` to pass the list of selected assistants to `RuleManager`. | P1 | Completed | 1.4, 2.1 | + +### Phase 3: Verification and Documentation + +**Description:** This final phase ensured that the refactoring was correct, robust, and fully documented. + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| +| **3.1** | Manually test CLI commands to confirm compliance and identify bugs in the new logic. | P0 | Completed | 1.5, 2.2 | +| **3.2** | Run the full automated test suite (`pytest`) to identify all regressions. | P0 | Completed | 3.1 | +| **3.3** | Fix all failing integration tests in `test_cli_commands.py` and other files to align with the new CLI behavior. | P0 | Completed | 3.2 | +| **3.4** | Rewrite the unit tests in `test_rule_manager_unit.py` to validate the new core generation strategies. | P0 | Completed | 3.3 | +| **3.5** | Update the public design spec (`manage_rules_script_design.md`) to include the new assistant-selection features. | P1 | Completed | 3.4 | + +### Enhancement: Additional Assistant Support + +**Description:** Post-refactor improvements that expand assistant coverage and strengthen file cleanup. + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:------------|:-----------|:-------|:-------------| +| **E1** | Define Claude Code, Codex CLI, and Gemini CLI assistants with dedicated rule file paths. | P1 | Completed | 3.5 | +| **E2** | Handle cleanup of assistant files and empty parent directories generically. | P1 | Completed | E1 | +| **E3** | Extend CLI and integration tests for new assistant flags. | P1 | Completed | E1 | +| **E4** | Document new assistant support in design spec, CLI flows, README, and task plan. | P1 | Completed | E3 | +| **E5** | Add `bug-report` CLI command linking to the issue tracker. | P3 | Completed | - | + +### Enhancement: Kilo Code and Warp Support + +**Description:** Added support for the Kilo Code and Warp assistants, which required refactoring the generation logic to handle mode-based subdirectories. + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:------------|:-----------|:-------|:-------------| +| **E6** | Add `kilocode` and `warp` to `assistants.py` and introduce the `has_modes` flag to `AssistantSpec`. | P1 | Completed | E4 | +| **E7** | Refactor `RuleManager._generate_for_assistant` to use the `has_modes` flag for mode-based generation. | P1 | Completed | E6 | +| **E8** | Update unit and integration tests to verify the new mode-based logic and assistant support. | P1 | Completed | E7 | +| **E9** | Enhance integration tests to check for multiple sub-modes and files within them. | P2 | Completed | E8 | +| **E10** | Update design documents to reflect Kilo Code and Warp support. | P2 | Completed | E7 | + +### Enhancement: Ratings & Reviews Command + +**Description:** Introduced a utility command that directs users to the project's Ratings & Reviews wiki for rule sets. + +| Task ID | Description | Importance | Status | Dependencies | +|:--------|:------------|:-----------|:-------|:-------------| +| **E11** | Add `rate-ruleset` CLI command linking to the ratings wiki. | P3 | Completed | - | +| **E12** | Update design docs and tests for ratings command. | P3 | Completed | E11 | +| **E13** | Surface ratings wiki link in `list-rules` output. | P3 | Completed | E11 | +| **E14** | Update docs and tests for ratings link in `list-rules`. | P3 | Completed | E13 | diff --git a/memory/docs/features/manage_rules/implementation_design.md b/memory/docs/features/manage_rules/implementation_design.md new file mode 100644 index 0000000..c9a2122 --- /dev/null +++ b/memory/docs/features/manage_rules/implementation_design.md @@ -0,0 +1,24 @@ +# Implementation Design: Rulebook-AI CLI + +## 1. High-Level Goal & Architecture + +The `rulebook-ai` CLI is designed to be maintainable and extensible. The core implementation follows a clean **separation of concerns**, splitting the logic into two distinct parts: + +1. **A declarative configuration (`assistants.py`)**: This file defines the *specification* for each AI assistant—what they expect to find on the filesystem—using a pure, data-only `AssistantSpec` class. It is the single source of truth for all assistant-specific information. +2. **A generic engine (`core.py`)**: The `RuleManager` class acts as a generic engine that reads the assistant specifications and performs the necessary file operations (copying, cleaning, generating rules). It contains all the logic for *how* to generate rules based on the specifications. + +This architecture makes adding a new assistant a simple matter of adding a new entry to the configuration file, without touching the core engine logic. + +## 2. Code Structure + +- **`src/rulebook_ai/cli.py`**: Handles command-line argument parsing using Python's `argparse` library. It dynamically generates CLI flags (e.g., `--cursor`, `--cline`) from the `SUPPORTED_ASSISTANTS` list in `assistants.py`. It then calls the appropriate methods in the `RuleManager`. +- **`src/rulebook_ai/core.py`**: Contains the `RuleManager` class, which implements the main business logic for the `install`, `sync`, `clean-rules`, and `clean-all` commands. +- **`src/rulebook_ai/assistants.py`**: Contains the `AssistantSpec` dataclass and the `SUPPORTED_ASSISTANTS` list, which provides the specifications for all supported AI assistants. + +## 3. Core Implementation Notes + +- **Path Handling:** The implementation must use robust path handling to manage files and directories across different operating systems. +- **User Feedback:** The CLI should provide clear and concise feedback to the user for all operations. +- **Hardcoded Constants:** Directory names for the framework components (e.g., `rule_sets` in the source repo, `project_rules`, `memory`, `tools` in the target repo) are hardcoded as constants within the script for simplicity and reliability. +- **Parent Directory Creation:** Helper functions that write files (e.g., for `copilot-instructions.md` or `GEMINI.md`) must ensure that the parent directories (`.github/`, `.gemini/`) are created if they do not exist. +- **Extensibility for Assistants:** The `AssistantSpec` is designed to be extensible. For example, the `has_modes` flag was added to support assistants like Kilo Code and Roo Code, which use subdirectories for different modes. The `RuleManager`'s generation logic was extended to interpret this flag. diff --git a/memory/docs/features/manage_rules/manage_rules_script_design.md b/memory/docs/features/manage_rules/manage_rules_script_design.md deleted file mode 100644 index fc2e8d2..0000000 --- a/memory/docs/features/manage_rules/manage_rules_script_design.md +++ /dev/null @@ -1,97 +0,0 @@ -**1. Overview** - -This document outlines the design for a new Python script, `src/manage_rules.py`. This script provides a command-line interface for installing, synchronizing, and cleaning AI assistant rule sets, project memory banks, and supporting tools within target project repositories. It uses fixed directory names for simplicity: `project_rules/` (for rule sources), `memory/` (for project context), and `tools/` (for utilities) in the target repository. - -**2. Core Concepts** - -1. **Source Repository (Framework):** The central repository containing master rule sets (from `rule_sets/`), master memory bank starter documents (from `memory_starters/`), master tool starters (from `tool_starters/`), and the `manage_rules.py` script itself. -2. **Target Repo:** Any project repository where the framework is installed. -3. **Target Project Rules Directory:** A folder named **`project_rules/`** *created inside* the Target Repo during installation. It holds project-specific rule files, copied from a chosen set in the Source Repository. **This folder is considered temporary by `clean-rules` but can be version-controlled if desired for manual restoration between `clean-rules` and `install` operations.** -4. **Target Memory Bank Directory:** A folder named **`memory/`** *created inside* the Target Repo during installation, holding project-specific memory documents, populated from the Source Repository's `memory_starters/`. **This folder should be version controlled within the Target Repo.** -5. **Target Tools Directory:** A folder named **`tools/`** *created inside* the Target Repo during installation, holding utility scripts or configurations, populated from the Source Repository's `tool_starters/`. **This folder should be version controlled within the Target Repo.** -6. **Target Platform Rules:** The generated, platform-specific rule directories/files (e.g., `.clinerules/`, `.cursor/rules/`, `.roo/`, `.kilocode/`, `.windsurf/rules/`, `WARP.md`, `.github/copilot-instructions.md`, `CLAUDE.md`, `AGENTS.md`, `.gemini/GEMINI.md`) created *inside* the Target Repo by the `sync` command using `project_rules/` as input. **These folders/files should be added to the Target Repo's `.gitignore` file.** - -**3. Features & Advantages** - -* **Project-Specific Customization:** Enables each target repository to maintain its own tailored project memory bank and utility tools based on common starting templates. Rule sets can be easily swapped or refreshed. -* **Simplified Maintenance:** Developers manage and customize memory documents and tools directly within their project's context (`memory/`, `tools/`). Rule sets (`project_rules/`) are managed by the script and can be easily cleaned and re-installed. -* **Clear Project Context:** The `memory/` and `tools/` folders serve as the persistent, version-controlled core for project-specific AI guidance. -* **Reusability:** The Source Repository acts as a factory for bootstrapping framework components. -* **Cleanliness:** Keeps generated platform-specific rules (`.clinerules/`, etc.) out of the target repository's version control. -* **Simplified Workflow:** Provides clear `install`, `sync`, `clean-rules`, and `clean-all` commands. -* **Focused Cleaning:** `clean-rules` removes rule-related artifacts (generated rules and `project_rules/`), leaving core project memory (`memory/`) and tools untouched. `clean-all` provides a complete removal option. - -**4. Specification: `manage_rules.py` Commands** - -* **`install [--rule-set ] [--cursor] [--cline] [--roo] [--kilocode] [--warp] [--windsurf] [--copilot] [--claude-code] [--codex-cli] [--gemini-cli] [--all]`** - * **Action:** - 1. Copies the specified rule set (default: `light-spec`) from the Source Repository's `rule_sets/` directory into `/project_rules/`. If `project_rules/` already exists, it will be overwritten or cleared first to ensure a fresh copy of the chosen rule set. *(A warning should be issued if overwriting)*. - 2. Copies the content of the Source Repository's `memory_starters/` directory into `/memory/`. If `memory/` exists, new starter files from the source will be copied if they don't exist in the target; existing files in the target `memory/` will **not** be overwritten. - 3. Copies the content of the Source Repository's `tool_starters/` directory into `/tools/`. If `tools/` exists, new starter files/subdirectories from the source will be copied if they don't exist in the target; existing files/subdirectories in the target `tools/` will **not** be overwritten. - 4. Copies `env.example` and `requirements.txt` from the Source Repository's root to `/env.example` and `/requirements.txt`. If `env.example` / `requirements.txt` already exists in the target, it will **not** be overwritten. - 5. Immediately runs the `sync` logic for the selected assistants. **If no assistant flags are provided, it defaults to generating rules for ALL supported assistants.** - * **Output:** Prints progress messages. Suggests adding generated platform rule directories/files (including `.github/copilot-instructions.md`, `CLAUDE.md`, `AGENTS.md`, `.gemini/GEMINI.md`, `WARP.md`) to `.gitignore`. Recommends committing `memory/`, `tools/`, `env.example`, and `requirements.txt` to version control. Informs the user that `project_rules/` will be managed by the script (and removed by `clean-rules`). - -* **`sync [--cursor] [--cline] [--roo] [--kilocode] [--warp] [--windsurf] [--copilot] [--claude-code] [--codex-cli] [--gemini-cli] [--all]`** - * **Action:** Reads rules from `/project_rules/`. For each selected assistant, it deletes the existing Target Platform Rules and regenerates them. **If no assistant flags are provided, it defaults to syncing ALL supported assistants.** - * **Use Case:** Run after manually modifying files within `/project_rules/` to update the generated rules for one, some, or all assistants. - * **Output:** Prints progress messages. - -* **`clean-rules `** - * **Action:** - 1. Removes the generated Target Platform Rules directories/files (e.g., `.clinerules/`, `.cursor/rules/`, `.roo/`, `.kilocode/`, `.windsurf/rules/`, `WARP.md`, `.github/copilot-instructions.md`, `CLAUDE.md`, `AGENTS.md`, `.gemini/GEMINI.md`) from ``. If a rule file is the only file in its directory, the directory may also be removed. - 2. Removes the **`project_rules/`** directory itself from ``. - 3. The `memory/` and `tools/` directories are **NOT** removed. - * **Use Case:** Remove all rule-related files (both generated and their sources) to allow for a fresh `install` of a different rule set or to revert to a clean state without rules, while preserving the project memory bank and tools. - * **Output:** Prints progress messages, clearly indicating which rule-related items were removed. - -* **`clean-all `** - * **Action:** Removes all framework components from ``: - 1. The generated Target Platform Rules directories/files (including the `.github/` or `.gemini/` directories if they were created/managed by this script). - 2. The `project_rules/` directory. - 3. The `memory/` directory. - 4. The `tools/` directory. The `env.example` and `requirements.txt` file (environment for tools). - * **Important:** This command **MUST prompt for user confirmation** before proceeding, clearly stating that `memory/`, `tools/`, `env.example`, and `requirements.txt` (which may contain user customizations) will be deleted. - * **Use Case:** Completely uninstall all components of the framework from the target repository. - * **Output:** Prints progress messages. Includes a prominent warning and confirmation prompt before deletion, and a summary of what was removed. - -* **`list-rules`** - * **Action:** Scans the Source Repository's `rule_sets/` directory. It lists all subdirectories found within `rule_sets/`, as each subdirectory represents an available rule set. - * **Use Case:** Allows users to quickly see which rule sets are available for installation without needing to manually inspect the `rule_sets/` directory in the source framework. - * **Output:** Prints a header like "Available rule sets:" followed by the name of each discovered rule set, one per line. If no rule sets are found, it prints an appropriate message. The command also shows a link to the Ratings & Reviews wiki so users can read or leave feedback. - -* **`bug-report`** - * **Action:** Prints the GitHub issue tracker URL and attempts to open it in the user's default browser. - * **Use Case:** Provides a quick way for users to report problems with the tool. - * **Output:** Shows the issue tracker link. - -* **`rate-ruleset`** - * **Action:** Prints the ratings and reviews wiki URL and attempts to open it in the user's default browser. - * **Use Case:** Directs users to rate existing rule sets or read community feedback. - * **Output:** Shows the ratings and reviews link. - -**5. Implementation Notes** - -* Use Python's `argparse` library. -* Adapt file processing logic from `copy_rules.py`. -* Implement robust path handling and error checking. -* Provide clear user feedback. -* `install`: Ensure non-destructive copying for `memory/`, `tools/`, `env.example`, and `requirements.txt`. Ensure `project_rules/` is freshly populated from the chosen rule set (e.g., clear and copy, or overwrite with warning). -* `clean-all`: **Must** include a user confirmation step. -* Directory names for framework components (e.g., `rule_sets` in source, `project_rules`, `memory`, `tools` in target, `memory_starters`, `tool_starters` in source) will be hardcoded as constants within the script. -* The `concatenate_ordered_files` helper function should ensure parent directories for the destination file are created (e.g., `.github/` for `copilot-instructions.md`, `.gemini/` for `GEMINI.md`). -* Cleanup logic for `clean-rules` and `clean-all` should attempt to remove the `.github/` and `.gemini/` directories if their respective rule files were the only files managed by this script within them and the directories become empty. - -**6. Initial Documentation Approach (Task 6.a)** - -1. Document usage of `manage_rules.py` (commands, the `--rule-set` option for `install`). -2. Explain the fixed directory structure: - * **Source Repository:** `rule_sets/` (contains selectable rule configurations), `memory_starters/` (initial content for memory bank), `tool_starters/` (initial content for tools). - * **Target Repository:** `project_rules/` (active rule sources, managed by the script), `memory/` (persistent project context), and `tools/` (persistent utilities). -3. State that customization of project context is done by editing files in `memory/` and `tools/` in the target repository. -4. Explain that `project_rules/` is populated by `install` (from a chosen rule set) and removed by `clean-rules`. Advanced users *could* modify it before running `sync` but should be aware it's not preserved by `clean-rules`. -5. Document behaviors of `clean-rules` (removes generated rules and `project_rules/`) and `clean-all` (removes everything, with confirmation). -6. Explain how `install` handles pre-existing `memory/` and `tools/` directories (non-overwriting, only adds new starter files). -7. Document support for GitHub Copilot, Claude Code, Codex CLI, Gemini CLI, Kilo Code, and Warp. -8. Defer detailed guides on writing custom rules (beyond choosing a rule set via `install`) for later. -9. **Note:** This script now assumes compatibility with Windsurf versions that use the `.windsurf/rules/` structure for loading workspace rules. Users on older versions may need to update Windsurf. \ No newline at end of file diff --git a/memory/docs/features/manage_rules/spec.md b/memory/docs/features/manage_rules/spec.md new file mode 100644 index 0000000..371676e --- /dev/null +++ b/memory/docs/features/manage_rules/spec.md @@ -0,0 +1,69 @@ +# Specification: Rulebook-AI CLI + +**1. Overview** + +This document outlines the specification for the `rulebook-ai` command-line interface. This script provides commands for installing, synchronizing, and cleaning AI assistant rule sets, project memory banks, and supporting tools within target project repositories. It uses fixed directory names for simplicity: `project_rules/` (for rule sources), `memory/` (for project context), and `tools/` (for utilities) in the target repository. + +**2. Core Concepts** + +1. **Source Repository (Framework):** The central repository containing master rule sets (from `rule_sets/`), master memory bank starter documents (from `memory_starters/`), and master tool starters (from `tool_starters/`). +2. **Target Repo:** Any project repository where the framework is installed. +3. **Target Project Rules Directory:** A folder named **`project_rules/`** *created inside* the Target Repo during installation. It holds project-specific rule files, copied from a chosen set in the Source Repository. **This folder is considered temporary and is removed by `clean-rules`.** +4. **Target Memory Bank Directory:** A folder named **`memory/`** *created inside* the Target Repo during installation, holding project-specific memory documents. **This folder should be version controlled within the Target Repo.** +5. **Target Tools Directory:** A folder named **`tools/`** *created inside* the Target Repo during installation, holding utility scripts or configurations. **This folder should be version controlled within the Target Repo.** +6. **Target Platform Rules:** The generated, platform-specific rule directories/files (e.g., `.clinerules/`, `.cursor/rules/`, `WARP.md`, etc.) created *inside* the Target Repo by the `sync` command. **These folders/files should be added to the Target Repo's `.gitignore` file.** + +**3. Features & Advantages** + +* **Project-Specific Customization:** Enables each target repository to maintain its own tailored project memory bank and utility tools. +* **Simplified Maintenance:** Rule sets (`project_rules/`) are managed by the script and can be easily cleaned and re-installed. +* **Clear Project Context:** The `memory/` and `tools/` folders serve as the persistent, version-controlled core for project-specific AI guidance. +* **Cleanliness:** Keeps generated platform-specific rules out of the target repository's version control. +* **Focused Cleaning:** `clean-rules` removes rule-related artifacts, leaving core project memory (`memory/`) and tools untouched. `clean-all` provides a complete removal option. + +**4. CLI Commands** + +* **`install [--rule-set ] [--cursor] [--cline] [--roo] [--kilocode] [--warp] [--windsurf] [--copilot] [--claude-code] [--codex-cli] [--gemini-cli] [--all]`** + * **Action:** Installs and configures the framework components in a target repository. + 1. Copies the specified rule set (default: `light-spec`) into `/project_rules/`. + 2. Copies starter files from the framework's `memory_starters/` into `/memory/`. + 3. Copies starter tools from the framework's `tool_starters/` into `/tools/`. + 4. Copies `env.example` and `requirements.txt` to the target repository. + 5. Immediately runs the `sync` logic for the selected assistants. If no assistant flags are provided, it defaults to ALL supported assistants. + * **Behavior:** + * The `project_rules/` directory is treated as ephemeral. If it already exists, it will be cleared and overwritten to ensure a fresh copy of the chosen rule set. + * The `memory/`, `tools/`, `env.example`, and `requirements.txt` are treated as persistent. The install operation is **non-destructive**; it will only add new starter files and will **not** overwrite any existing files in these locations. + * **Output:** Prints progress messages and recommends which files to commit versus which to add to `.gitignore`. + +* **`sync [--cursor] [--cline] [--roo] [--kilocode] [--warp] [--windsurf] [--copilot] [--claude-code] [--codex-cli] [--gemini-cli] [--all]`** + * **Action:** Reads rules from `/project_rules/` and regenerates the platform-specific rules for the selected assistants. If no assistants are specified, it syncs for ALL. + * **Use Case:** Run after manually modifying files within `/project_rules/` to apply the changes. + * **Output:** Prints progress messages. + +* **`clean-rules `** + * **Action:** + 1. Removes all generated Target Platform Rules (e.g., `.clinerules/`, `.cursor/rules/`, etc.). + 2. Removes the `project_rules/` directory. + * **Behavior:** + * The `memory/` and `tools/` directories are **NOT** removed. + * If a rule file is the only item within a directory (e.g., `.github/copilot-instructions.md`), the parent directory (`.github/`) will also be removed. + * **Use Case:** Revert to a clean state without rules, while preserving the project memory bank and tools. + * **Output:** Prints progress messages. + +* **`clean-all `** + * **Action:** Removes **all** framework components from the target repository, including generated rules, `project_rules/`, `memory/`, `tools/`, `env.example`, and `requirements.txt`. + * **Behavior:** + * This is a destructive operation. The command **MUST prompt for user confirmation** before proceeding. + * Like `clean-rules`, it will remove parent directories (e.g., `.github/`) if they become empty after the rule files within them are removed. + * **Use Case:** Completely uninstall all components of the framework from the target repository. + * **Output:** Prints a prominent warning, a confirmation prompt, and a summary of what was removed. + +* **`list-rules`** + * **Action:** Lists all available rule sets from the Source Repository's `rule_sets/` directory. + * **Output:** Prints a list of available rule sets and a link to the Ratings & Reviews wiki. + +* **`bug-report`** + * **Action:** Prints the GitHub issue tracker URL and attempts to open it in the user's default browser. + +* **`rate-ruleset`** + * **Action:** Prints the ratings and reviews wiki URL and attempts to open it in the user's default browser. diff --git a/memory/docs/features/manage_rules/task_plan.md b/memory/docs/features/manage_rules/task_plan.md index f517a91..a76932a 100644 --- a/memory/docs/features/manage_rules/task_plan.md +++ b/memory/docs/features/manage_rules/task_plan.md @@ -1,77 +1,14 @@ -# Refactoring Task Plan (As Executed) +# Task Plan: Manage Rules Feature ## 🎯 Goal -This document breaks down the work performed during the internal refactoring of the `rulebook-ai` core and CLI components. The objective was to improve code modularity, maintainability, and extensibility by separating declarative assistant specifications from the file-generation engine. - -This plan is a historical record of the tasks completed, based on the final design in the [Refactoring Plan](./refactoring_plan.md). +This document tracks the development tasks for the "Manage Rules" feature of the `rulebook-ai` CLI. --- -### Phase 1: Separate Specification from Logic - -**Description:** This phase focused on creating a purely data-driven architecture, separating the "what" (the assistant spec) from the "how" (the generation engine). +### General Tasks | Task ID | Description | Importance | Status | Dependencies | |:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| -| **1.1** | Define the `AssistantSpec` dataclass in a new `assistants.py` file. | P0 | Completed | - | -| **1.2** | Create the `SUPPORTED_ASSISTANTS` list in `assistants.py` as the single source of truth. | P0 | Completed | 1.1 | -| **1.3** | Refactor `RuleManager` in `core.py` into a generic engine that interprets `AssistantSpec` data. | P0 | Completed | 1.2 | -| **1.4** | Implement private generation strategies (`_strategy_flatten_and_number`, etc.) in `RuleManager`. | P0 | Completed | 1.3 | -| **1.5** | Refactor public methods (`install`, `sync`, `clean_rules`) to be data-driven and compliant with the design spec. | P0 | Completed | 1.4 | - -### Phase 2: Simplify and Automate the CLI - -**Description:** This phase refactored the command-line interface to be dynamically generated from the single source of truth, eliminating hardcoded logic. - -| Task ID | Description | Importance | Status | Dependencies | -|:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| -| **2.1** | Refactor `cli.py` to dynamically generate assistant flags (e.g., `--cursor`) from `SUPPORTED_ASSISTANTS`. | P1 | Completed | 1.2 | -| **2.2** | Simplify `handle_install` and `handle_sync` to pass the list of selected assistants to `RuleManager`. | P1 | Completed | 1.4, 2.1 | - -### Phase 3: Verification and Documentation - -**Description:** This final phase ensured that the refactoring was correct, robust, and fully documented. - -| Task ID | Description | Importance | Status | Dependencies | -|:--------|:-----------------------------------------------------------------------------------------|:-----------|:------------|:------------------| -| **3.1** | Manually test CLI commands to confirm compliance and identify bugs in the new logic. | P0 | Completed | 1.5, 2.2 | -| **3.2** | Run the full automated test suite (`pytest`) to identify all regressions. | P0 | Completed | 3.1 | -| **3.3** | Fix all failing integration tests in `test_cli_commands.py` and other files to align with the new CLI behavior. | P0 | Completed | 3.2 | -| **3.4** | Rewrite the unit tests in `test_rule_manager_unit.py` to validate the new core generation strategies. | P0 | Completed | 3.3 | -| **3.5** | Update the public design spec (`manage_rules_script_design.md`) to include the new assistant-selection features. | P1 | Completed | 3.4 | - -### Enhancement: Additional Assistant Support - -**Description:** Post-refactor improvements that expand assistant coverage and strengthen file cleanup. - -| Task ID | Description | Importance | Status | Dependencies | -|:--------|:------------|:-----------|:-------|:-------------| -| **E1** | Define Claude Code, Codex CLI, and Gemini CLI assistants with dedicated rule file paths. | P1 | Completed | 3.5 | -| **E2** | Handle cleanup of assistant files and empty parent directories generically. | P1 | Completed | E1 | -| **E3** | Extend CLI and integration tests for new assistant flags. | P1 | Completed | E1 | -| **E4** | Document new assistant support in design spec, CLI flows, README, and task plan. | P1 | Completed | E3 | -| **E5** | Add `bug-report` CLI command linking to the issue tracker. | P3 | Completed | - | - -### Enhancement: Kilo Code and Warp Support - -**Description:** Added support for the Kilo Code and Warp assistants, which required refactoring the generation logic to handle mode-based subdirectories. - -| Task ID | Description | Importance | Status | Dependencies | -|:--------|:------------|:-----------|:-------|:-------------| -| **E6** | Add `kilocode` and `warp` to `assistants.py` and introduce the `has_modes` flag to `AssistantSpec`. | P1 | Completed | E4 | -| **E7** | Refactor `RuleManager._generate_for_assistant` to use the `has_modes` flag for mode-based generation. | P1 | Completed | E6 | -| **E8** | Update unit and integration tests to verify the new mode-based logic and assistant support. | P1 | Completed | E7 | -| **E9** | Enhance integration tests to check for multiple sub-modes and files within them. | P2 | Completed | E8 | -| **E10** | Update design documents to reflect Kilo Code and Warp support. | P2 | Completed | E7 | - -### Enhancement: Ratings & Reviews Command - -**Description:** Introduced a utility command that directs users to the project's Ratings & Reviews wiki for rule sets. - -| Task ID | Description | Importance | Status | Dependencies | -|:--------|:------------|:-----------|:-------|:-------------| -| **E11** | Add `rate-ruleset` CLI command linking to the ratings wiki. | P3 | Completed | - | -| **E12** | Update design docs and tests for ratings command. | P3 | Completed | E11 | -| **E13** | Surface ratings wiki link in `list-rules` output. | P3 | Completed | E11 | -| **E14** | Update docs and tests for ratings link in `list-rules`. | P3 | Completed | E13 | +| **T1** | Refactor the feature documentation to separate the specification, implementation, and task planning. | P1 | Completed | - | +| **T2** | *(Placeholder for next feature enhancement or bug fix)* | P_ | To Do | - |