kodu 1.1.13 → 1.1.15

package/openspec/AGENTS.md

@@ -1,456 +0,0 @@
-# OpenSpec Instructions
-
-Instructions for AI coding assistants using OpenSpec for spec-driven development.
-
-## TL;DR Quick Checklist
-
-- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search)
-- Decide scope: new capability vs modify existing capability
-- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`)
-- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability
-- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement
-- Validate: `openspec validate [change-id] --strict --no-interactive` and fix issues
-- Request approval: Do not start implementation until proposal is approved
-
-## Three-Stage Workflow
-
-### Stage 1: Creating Changes
-Create proposal when you need to:
-- Add features or functionality
-- Make breaking changes (API, schema)
-- Change architecture or patterns  
-- Optimize performance (changes behavior)
-- Update security patterns
-
-Triggers (examples):
-- "Help me create a change proposal"
-- "Help me plan a change"
-- "Help me create a proposal"
-- "I want to create a spec proposal"
-- "I want to create a spec"
-
-Loose matching guidance:
-- Contains one of: `proposal`, `change`, `spec`
-- With one of: `create`, `plan`, `make`, `start`, `help`
-
-Skip proposal for:
-- Bug fixes (restore intended behavior)
-- Typos, formatting, comments
-- Dependency updates (non-breaking)
-- Configuration changes
-- Tests for existing behavior
-
-**Workflow**
-1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context.
-2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes/<id>/`.
-3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement.
-4. Run `openspec validate <id> --strict --no-interactive` and resolve any issues before sharing the proposal.
-
-### Stage 2: Implementing Changes
-Track these steps as TODOs and complete them one by one.
-1. **Read proposal.md** - Understand what's being built
-2. **Read design.md** (if exists) - Review technical decisions
-3. **Read tasks.md** - Get implementation checklist
-4. **Implement tasks sequentially** - Complete in order
-5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses
-6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality
-7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved
-
-### Stage 3: Archiving Changes
-After deployment, create separate PR to:
-- Move `changes/[name]/` → `changes/archive/YYYY-MM-DD-[name]/`
-- Update `specs/` if capabilities changed
-- Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes (always pass the change ID explicitly)
-- Run `openspec validate --strict --no-interactive` to confirm the archived change passes checks
-
-## Before Any Task
-
-**Context Checklist:**
-- [ ] Read relevant specs in `specs/[capability]/spec.md`
-- [ ] Check pending changes in `changes/` for conflicts
-- [ ] Read `openspec/project.md` for conventions
-- [ ] Run `openspec list` to see active changes
-- [ ] Run `openspec list --specs` to see existing capabilities
-
-**Before Creating Specs:**
-- Always check if capability already exists
-- Prefer modifying existing specs over creating duplicates
-- Use `openspec show [spec]` to review current state
-- If request is ambiguous, ask 1–2 clarifying questions before scaffolding
-
-### Search Guidance
-- Enumerate specs: `openspec spec list --long` (or `--json` for scripts)
-- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available)
-- Show details:
-  - Spec: `openspec show <spec-id> --type spec` (use `--json` for filters)
-  - Change: `openspec show <change-id> --json --deltas-only`
-- Full-text search (use ripgrep): `rg -n "Requirement:|Scenario:" openspec/specs`
-
-## Quick Start
-
-### CLI Commands
-
-```bash
-# Essential commands
-openspec list                  # List active changes
-openspec list --specs          # List specifications
-openspec show [item]           # Display change or spec
-openspec validate [item]       # Validate changes or specs
-openspec archive <change-id> [--yes|-y]   # Archive after deployment (add --yes for non-interactive runs)
-
-# Project management
-openspec init [path]           # Initialize OpenSpec
-openspec update [path]         # Update instruction files
-
-# Interactive mode
-openspec show                  # Prompts for selection
-openspec validate              # Bulk validation mode
-
-# Debugging
-openspec show [change] --json --deltas-only
-openspec validate [change] --strict --no-interactive
-```
-
-### Command Flags
-
-- `--json` - Machine-readable output
-- `--type change|spec` - Disambiguate items
-- `--strict` - Comprehensive validation
-- `--no-interactive` - Disable prompts
-- `--skip-specs` - Archive without spec updates
-- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive)
-
-## Directory Structure
-
-```
-openspec/
-├── project.md              # Project conventions
-├── specs/                  # Current truth - what IS built
-│   └── [capability]/       # Single focused capability
-│       ├── spec.md         # Requirements and scenarios
-│       └── design.md       # Technical patterns
-├── changes/                # Proposals - what SHOULD change
-│   ├── [change-name]/
-│   │   ├── proposal.md     # Why, what, impact
-│   │   ├── tasks.md        # Implementation checklist
-│   │   ├── design.md       # Technical decisions (optional; see criteria)
-│   │   └── specs/          # Delta changes
-│   │       └── [capability]/
-│   │           └── spec.md # ADDED/MODIFIED/REMOVED
-│   └── archive/            # Completed changes
-```
-
-## Creating Change Proposals
-
-### Decision Tree
-
-```
-New request?
-├─ Bug fix restoring spec behavior? → Fix directly
-├─ Typo/format/comment? → Fix directly  
-├─ New feature/capability? → Create proposal
-├─ Breaking change? → Create proposal
-├─ Architecture change? → Create proposal
-└─ Unclear? → Create proposal (safer)
-```
-
-### Proposal Structure
-
-1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique)
-
-2. **Write proposal.md:**
-```markdown
-# Change: [Brief description of change]
-
-## Why
-[1-2 sentences on problem/opportunity]
-
-## What Changes
-- [Bullet list of changes]
-- [Mark breaking changes with **BREAKING**]
-
-## Impact
-- Affected specs: [list capabilities]
-- Affected code: [key files/systems]
-```
-
-3. **Create spec deltas:** `specs/[capability]/spec.md`
-```markdown
-## ADDED Requirements
-### Requirement: New Feature
-The system SHALL provide...
-
-#### Scenario: Success case
-- **WHEN** user performs action
-- **THEN** expected result
-
-## MODIFIED Requirements
-### Requirement: Existing Feature
-[Complete modified requirement]
-
-## REMOVED Requirements
-### Requirement: Old Feature
-**Reason**: [Why removing]
-**Migration**: [How to handle]
-```
-If multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs/<capability>/spec.md`—one per capability.
-
-4. **Create tasks.md:**
-```markdown
-## 1. Implementation
-- [ ] 1.1 Create database schema
-- [ ] 1.2 Implement API endpoint
-- [ ] 1.3 Add frontend component
-- [ ] 1.4 Write tests
-```
-
-5. **Create design.md when needed:**
-Create `design.md` if any of the following apply; otherwise omit it:
-- Cross-cutting change (multiple services/modules) or a new architectural pattern
-- New external dependency or significant data model changes
-- Security, performance, or migration complexity
-- Ambiguity that benefits from technical decisions before coding
-
-Minimal `design.md` skeleton:
-```markdown
-## Context
-[Background, constraints, stakeholders]
-
-## Goals / Non-Goals
-- Goals: [...]
-- Non-Goals: [...]
-
-## Decisions
-- Decision: [What and why]
-- Alternatives considered: [Options + rationale]
-
-## Risks / Trade-offs
-- [Risk] → Mitigation
-
-## Migration Plan
-[Steps, rollback]
-
-## Open Questions
-- [...]
-```
-
-## Spec File Format
-
-### Critical: Scenario Formatting
-
-**CORRECT** (use #### headers):
-```markdown
-#### Scenario: User login success
-- **WHEN** valid credentials provided
-- **THEN** return JWT token
-```
-
-**WRONG** (don't use bullets or bold):
-```markdown
-- **Scenario: User login**  ❌
-**Scenario**: User login     ❌
-### Scenario: User login      ❌
-```
-
-Every requirement MUST have at least one scenario.
-
-### Requirement Wording
-- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)
-
-### Delta Operations
-
-- `## ADDED Requirements` - New capabilities
-- `## MODIFIED Requirements` - Changed behavior
-- `## REMOVED Requirements` - Deprecated features
-- `## RENAMED Requirements` - Name changes
-
-Headers matched with `trim(header)` - whitespace ignored.
-
-#### When to use ADDED vs MODIFIED
-- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding "Slash Command Configuration") rather than altering the semantics of an existing requirement.
-- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.
-- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.
-
-Common pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren’t explicitly changing the existing requirement, add a new requirement under ADDED instead.
-
-Authoring a MODIFIED requirement correctly:
-1) Locate the existing requirement in `openspec/specs/<capability>/spec.md`.
-2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios).
-3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior.
-4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`.
-
-Example for RENAMED:
-```markdown
-## RENAMED Requirements
-- FROM: `### Requirement: Login`
-- TO: `### Requirement: User Authentication`
-```
-
-## Troubleshooting
-
-### Common Errors
-
-**"Change must have at least one delta"**
-- Check `changes/[name]/specs/` exists with .md files
-- Verify files have operation prefixes (## ADDED Requirements)
-
-**"Requirement must have at least one scenario"**
-- Check scenarios use `#### Scenario:` format (4 hashtags)
-- Don't use bullet points or bold for scenario headers
-
-**Silent scenario parsing failures**
-- Exact format required: `#### Scenario: Name`
-- Debug with: `openspec show [change] --json --deltas-only`
-
-### Validation Tips
-
-```bash
-# Always use strict mode for comprehensive checks
-openspec validate [change] --strict --no-interactive
-
-# Debug delta parsing
-openspec show [change] --json | jq '.deltas'
-
-# Check specific requirement
-openspec show [spec] --json -r 1
-```
-
-## Happy Path Script
-
-```bash
-# 1) Explore current state
-openspec spec list --long
-openspec list
-# Optional full-text search:
-# rg -n "Requirement:|Scenario:" openspec/specs
-# rg -n "^#|Requirement:" openspec/changes
-
-# 2) Choose change id and scaffold
-CHANGE=add-two-factor-auth
-mkdir -p openspec/changes/$CHANGE/{specs/auth}
-printf "## Why\n...\n\n## What Changes\n- ...\n\n## Impact\n- ...\n" > openspec/changes/$CHANGE/proposal.md
-printf "## 1. Implementation\n- [ ] 1.1 ...\n" > openspec/changes/$CHANGE/tasks.md
-
-# 3) Add deltas (example)
-cat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'
-## ADDED Requirements
-### Requirement: Two-Factor Authentication
-Users MUST provide a second factor during login.
-
-#### Scenario: OTP required
-- **WHEN** valid credentials are provided
-- **THEN** an OTP challenge is required
-EOF
-
-# 4) Validate
-openspec validate $CHANGE --strict --no-interactive
-```
-
-## Multi-Capability Example
-
-```
-openspec/changes/add-2fa-notify/
-├── proposal.md
-├── tasks.md
-└── specs/
-    ├── auth/
-    │   └── spec.md   # ADDED: Two-Factor Authentication
-    └── notifications/
-        └── spec.md   # ADDED: OTP email notification
-```
-
-auth/spec.md
-```markdown
-## ADDED Requirements
-### Requirement: Two-Factor Authentication
-...
-```
-
-notifications/spec.md
-```markdown
-## ADDED Requirements
-### Requirement: OTP Email Notification
-...
-```
-
-## Best Practices
-
-### Simplicity First
-- Default to <100 lines of new code
-- Single-file implementations until proven insufficient
-- Avoid frameworks without clear justification
-- Choose boring, proven patterns
-
-### Complexity Triggers
-Only add complexity with:
-- Performance data showing current solution too slow
-- Concrete scale requirements (>1000 users, >100MB data)
-- Multiple proven use cases requiring abstraction
-
-### Clear References
-- Use `file.ts:42` format for code locations
-- Reference specs as `specs/auth/spec.md`
-- Link related changes and PRs
-
-### Capability Naming
-- Use verb-noun: `user-auth`, `payment-capture`
-- Single purpose per capability
-- 10-minute understandability rule
-- Split if description needs "AND"
-
-### Change ID Naming
-- Use kebab-case, short and descriptive: `add-two-factor-auth`
-- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-`
-- Ensure uniqueness; if taken, append `-2`, `-3`, etc.
-
-## Tool Selection Guide
-
-| Task | Tool | Why |
-|------|------|-----|
-| Find files by pattern | Glob | Fast pattern matching |
-| Search code content | Grep | Optimized regex search |
-| Read specific files | Read | Direct file access |
-| Explore unknown scope | Task | Multi-step investigation |
-
-## Error Recovery
-
-### Change Conflicts
-1. Run `openspec list` to see active changes
-2. Check for overlapping specs
-3. Coordinate with change owners
-4. Consider combining proposals
-
-### Validation Failures
-1. Run with `--strict` flag
-2. Check JSON output for details
-3. Verify spec file format
-4. Ensure scenarios properly formatted
-
-### Missing Context
-1. Read project.md first
-2. Check related specs
-3. Review recent archives
-4. Ask for clarification
-
-## Quick Reference
-
-### Stage Indicators
-- `changes/` - Proposed, not yet built
-- `specs/` - Built and deployed
-- `archive/` - Completed changes
-
-### File Purposes
-- `proposal.md` - Why and what
-- `tasks.md` - Implementation steps
-- `design.md` - Technical decisions
-- `spec.md` - Requirements and behavior
-
-### CLI Essentials
-```bash
-openspec list              # What's in progress?
-openspec show [item]       # View details
-openspec validate --strict --no-interactive  # Is it correct?
-openspec archive <change-id> [--yes|-y]  # Mark complete (add --yes for automation)
-```
-
-Remember: Specs are truth. Changes are proposals. Keep them in sync.

package/openspec/changes/archive/2026-01-26-translate-project-to-english/design.md

@@ -1,30 +0,0 @@
-## Context
-The Kodu CLI project currently uses mixed languages with Russian prompts and error messages. This creates inconsistency and limits international adoption. The project needs comprehensive translation to English while maintaining functionality.
-
-## Goals / Non-Goals
-- Goals: Complete translation of all user-facing text to English
-- Goals: Maintain all existing functionality
-- Goals: Ensure consistency across all prompts and messages
-- Non-Goals: Translate code comments (keep technical comments)
-- Non-Goals: Change project structure or architecture
-
-## Decisions
-- Decision: Translate all user-facing strings to English
-- Decision: Keep technical code comments in original form for developer context
-- Decision: Maintain existing prompt structure and variable substitution
-- Alternatives considered: Keep bilingual support (rejected for complexity)
-
-## Risks / Trade-offs
-- Breaking change for existing Russian-speaking users
-- Risk of translation errors affecting prompt quality
-- Trade-off: Better international adoption vs current user base disruption
-
-## Migration Plan
-- Translate all files systematically
-- Test each command individually
-- Update documentation
-- Release with migration guide
-
-## Open Questions
-- How to handle existing Russian user configurations?
-- Should we provide fallback support for Russian prompts?

package/openspec/changes/archive/2026-01-26-translate-project-to-english/proposal.md

@@ -1,17 +0,0 @@
-# Change: Translate all project content from Russian to English
-
-## Why
-The project currently contains mixed language content with Russian text in prompts, error messages, specifications, and user-facing strings. This creates inconsistency and limits the project's accessibility to international contributors and users.
-
-## What Changes
-- Translate all Russian prompts in `src/core/config/default-prompts.ts`
-- Translate all Russian prompt templates in `.kodu/prompts/` directory
-- Translate Russian specifications in `openspec/specs/cleaner/spec.md`
-- Translate Russian error messages and user-facing strings in command files
-- Update all Russian comments and documentation to English
-- **BREAKING**: Changes all user-facing text from Russian to English
-
-## Impact
-- Affected specs: cleaner, ai, config, ui
-- Affected code: All command files, configuration services, prompt templates
-- User experience: All CLI output and prompts will be in English

package/openspec/changes/archive/2026-01-26-translate-project-to-english/specs/ai/spec.md

@@ -1,26 +0,0 @@
-## ADDED Requirements
-### Requirement: English Review Prompts
-The AI service SHALL provide English-language review prompts for bug, style, and security analysis modes.
-
-#### Scenario: Bug review in English
-- **WHEN** `kodu review --mode bug` is executed
-- **THEN** the AI receives an English prompt asking it to act as a strict code reviewer and find potential bugs, logical errors, and regressions
-
-#### Scenario: Style review in English
-- **WHEN** `kodu review --mode style` is executed
-- **THEN** the AI receives an English prompt asking it to check readability, consistency, formatting, and naming
-
-#### Scenario: Security review in English
-- **WHEN** `kodu review --mode security` is executed
-- **THEN** the AI receives an English prompt asking it to find vulnerabilities, secret leaks, and improper permission checks
-
-### Requirement: English Error Messages
-The AI service SHALL provide English error messages for API key validation and model configuration.
-
-#### Scenario: Missing API key in English
-- **WHEN** AI command is executed without API key
-- **THEN** the system displays English error message about missing API key and setup instructions
-
-#### Scenario: Invalid model format in English
-- **WHEN** model configuration is invalid
-- **THEN** the system displays English error message about expected model format

package/openspec/changes/archive/2026-01-26-translate-project-to-english/specs/cleaner/spec.md

@@ -1,26 +0,0 @@
-## MODIFIED Requirements
-### Requirement: Comment Recognition
-The `clean` command SHALL detect and remove any form of comments in files (`//`, `/* ... */`, HTML `<!-- ... -->`, etc.), except for constructs covered by `keepJSDoc` or custom/system whitelist. HTML `<!-- ... -->` should only be removed in `.html`/`.htm` files, so that lines with similar regular expressions or literals in TypeScript/JavaScript remain untouched. Removal SHALL occur without distorting surrounding code and be reflected in `--dry-run` previews.
-
-#### Scenario: Remove multi-line `/* ... */` blocks
-- **WHEN** `kodu clean` runs on a TS/JS file containing a `/* ... */` block that is not marked as JSDoc or not in the whitelist
-- **THEN** the block is removed, surrounding code remains syntactically correct, and `--dry-run` shows this range without applying changes
-
-#### Scenario: Remove HTML comments inside templates
-- **WHEN** `kodu clean` runs on a template file (`.html` or `.htm`) with comments of the form `<!-- ... -->`
-- **THEN** HTML comments are removed, template structure is preserved, and output/generation does not contain extra whitespace lines
-
-#### Scenario: HTML comment in TypeScript literal remains untouched
-- **WHEN** `kodu clean` runs on a TS/JS file where a pattern `` `<!--[\s\S]*?-->` `` appears inside a string or regular expression
-- **THEN** the text remains unchanged because HTML parsing is limited to `.html`/`.htm` files only
-
-### Requirement: Clean Only Changed Files
-The `clean` command SHALL accept a `--changed` flag (short form `-c`) that switches the operation to process only those files where Git has detected changes. Extension rules continue to apply, and output is lost if no files match the filter. Switching to `--dry-run` remains possible, it only changes the message without actual writing.
-
-#### Scenario: Clean changes in `--changed` mode
-- **WHEN** `kodu clean --changed` runs in a repository with changed TypeScript/HTML files
-- **THEN** the command removes comments only from changed files, others are skipped, and the count of affected files/comments reflects only this selection
-
-#### Scenario: `--changed` mode with no current files
-- **WHEN** `kodu clean --changed` runs but Git produces no changed file with suitable extension
-- **THEN** the command makes no changes and outputs warning `No changed files to clean.`, and the spinner stops without executing `cleaner.cleanFiles`

package/openspec/changes/archive/2026-01-26-translate-project-to-english/specs/config/spec.md

@@ -1,22 +0,0 @@
-## MODIFIED Requirements
-### Requirement: English Configuration Validation
-The configuration service SHALL provide English error messages for missing or invalid configuration files.
-
-#### Scenario: Missing configuration file in English
-- **WHEN** `kodu.json` is not found
-- **THEN** the system displays English error message suggesting to run `kodu init`
-
-#### Scenario: Invalid configuration in English
-- **WHEN** `kodu.json` contains validation errors
-- **THEN** the system displays English error messages for each validation issue
-
-### Requirement: English Prompt Loading
-The prompt service SHALL provide English error messages for missing or invalid prompt templates.
-
-#### Scenario: Missing prompt template in English
-- **WHEN** a prompt template file is not found
-- **THEN** the system displays English error message with expected file paths
-
-#### Scenario: Invalid prompt file in English
-- **WHEN** a prompt file path is invalid
-- **THEN** the system displays English error message about file not found

package/openspec/changes/archive/2026-01-26-translate-project-to-english/specs/ui/spec.md

@@ -1,33 +0,0 @@
-## ADDED Requirements
-### Requirement: English CLI Commands
-All CLI commands SHALL provide English descriptions, option help text, and user-facing messages.
-
-#### Scenario: English command descriptions
-- **WHEN** users run `kodu --help` or command-specific help
-- **THEN** all command descriptions and option help text are in English
-
-#### Scenario: English command output
-- **WHEN** users execute any kodu command
-- **THEN** all progress messages, spinners, and results are in English
-
-### Requirement: English Error Handling
-All error messages and warnings SHALL be displayed in English.
-
-#### Scenario: English error messages
-- **WHEN** an error occurs during command execution
-- **THEN** the error message is in English with clear guidance
-
-#### Scenario: English warning messages
-- **WHEN** a warning is displayed (e.g., missing staged changes)
-- **THEN** the warning message is in English
-
-### Requirement: English Interactive Prompts
-All interactive prompts and user dialogs SHALL be in English.
-
-#### Scenario: English confirmation prompts
-- **WHEN** a command requires user confirmation
-- **THEN** the prompt text is in English
-
-#### Scenario: English input prompts
-- **WHEN** a command requires user input
-- **THEN** the prompt text and validation messages are in English

package/openspec/changes/archive/2026-01-26-translate-project-to-english/tasks.md

@@ -1,33 +0,0 @@
-## 1. Translation Preparation
-- [x] 1.1 Inventory all Russian text in the codebase
-- [x] 1.2 Create translation mapping for key terms
-- [x] 1.3 Identify user-facing vs internal strings
-
-## 2. Core Configuration Translation
-- [x] 2.1 Translate `DEFAULT_REVIEW_PROMPTS` in `src/core/config/default-prompts.ts`
-- [x] 2.2 Translate prompt templates in `.kodu/prompts/` directory
-- [x] 2.3 Update configuration schema if needed
-
-## 3. Command Files Translation
-- [x] 3.1 Translate Russian strings in `src/commands/review/review.command.ts`
-- [x] 3.2 Translate Russian strings in `src/commands/commit/commit.command.ts`
-- [x] 3.3 Translate Russian strings in `src/commands/init/init.command.ts`
-- [x] 3.4 Translate Russian strings in `src/commands/pack/pack.command.ts`
-- [x] 3.5 Translate Russian strings in `src/commands/clean/clean.command.ts`
-
-## 4. Service Files Translation
-- [x] 4.1 Translate Russian strings in `src/shared/ai/ai.service.ts`
-- [x] 4.2 Translate Russian strings in `src/core/config/config.service.ts`
-- [x] 4.3 Translate Russian strings in `src/core/config/prompt.service.ts`
-- [x] 4.4 Translate Russian strings in `src/shared/git/git.service.ts`
-
-## 5. Documentation Translation
-- [x] 5.1 Translate `openspec/specs/cleaner/spec.md`
-- [x] 5.2 Update archived changes documentation
-- [x] 5.3 Translate `docs/todo.md`
-- [x] 5.4 Update Russian examples in `AGENTS.md`
-
-## 6. Validation
-- [x] 6.1 Test all commands with English output
-- [x] 6.2 Verify no Russian text remains in user-facing strings
-- [x] 6.3 Run `npm run check` to ensure no breaking changes