Initial commit: Video Library Manager
- Add core VLM modules (scanner, parser, planner, executor, analysis) - Add CLI with quarantine, reports, rollback, and state management - Add comprehensive test suite - Add project configuration and documentation - Add .gitignore for Python project
This commit is contained in:
windyboy
@@ -0,0 +1 @@
|
||||
{"generationMode": "requirements-first"}
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,236 @@
|
||||
# Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
The Video Library Manager is a personal, semi-automated video library management tool written in Python for long-term use. It operates on video files stored on a FreeNAS system mounted via SMB on Windows 11. This tool provides a safe, transparent workflow to inspect, organize, and gradually clean an existing video library without acting as a downloader or media server.
|
||||
|
||||
The system follows a read-first, human-in-the-loop approach where all irreversible actions require explicit user confirmation. All file operations are expressed as reviewable execution plans, with no permanent deletion in v1 - unwanted files are moved to quarantine instead.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Video_Library_Manager**: The Python-based tool that manages video file organization
|
||||
- **Inventory_Scanner**: Component that discovers and catalogs video files
|
||||
- **Identity_Parser**: Component that extracts logical identity from filenames
|
||||
- **Analysis_Engine**: Component that detects completeness and duplicates, and provides comparison data
|
||||
- **Plan_Generator**: Component that creates structured, reviewable execution plans
|
||||
- **Execution_Engine**: Component that safely executes file operations
|
||||
- **Quarantine_Directory**: A `.quarantine/` subdirectory within the library root where unwanted files are moved
|
||||
- **Dry_Run_Mode**: A simulation mode that shows what would happen without making changes
|
||||
- **Execution_Plan**: A structured, reviewable document describing all file operations to be performed
|
||||
- **Video_File**: A media file with extensions: .mp4, .mkv, .avi, .mov, .wmv, .flv, .webm, .m4v
|
||||
- **Movie**: A standalone video file organized by title and year
|
||||
- **Series**: An episodic TV series with continuous drama format
|
||||
- **Season**: A collection of episodes within a series
|
||||
- **Episode**: A single video file within a season
|
||||
- **Anime**: Japanese animation content (deferred for v1 except inventory scanning)
|
||||
- **Rollback_Log**: A record of all file operations that enables restoration to previous state
|
||||
- **Configuration_File**: A user-editable file containing parsing rules, directory templates, and policies
|
||||
|
||||
## Requirements
|
||||
|
||||
### 1. Inventory Scanning
|
||||
|
||||
**User Story:** As a user, I want to scan my video library to discover all video files and record their metadata, so that I can understand the current state of my collection without making any modifications.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN the user initiates an inventory scan, THE Inventory_Scanner SHALL recursively discover all Video_Files within the specified root directory
|
||||
2. WHEN a Video_File is discovered, THE Inventory_Scanner SHALL record its full path, filename, file size, and modification timestamp
|
||||
3. WHERE ffprobe is available, THE Inventory_Scanner SHALL extract video metadata including resolution, codec, duration, and bitrate
|
||||
4. WHEN scanning completes, THE Inventory_Scanner SHALL generate a structured inventory report in CSV format
|
||||
5. THE Inventory_Scanner SHALL scan all top-level directories including movie, series, anime, and other
|
||||
6. THE Inventory_Scanner SHALL perform read-only operations without modifying any files or directories
|
||||
7. WHEN scanning encounters an inaccessible file or directory, THE Inventory_Scanner SHALL log the error and continue scanning remaining files
|
||||
8. THE Inventory_Scanner SHALL save the inventory report to disk for later use
|
||||
|
||||
### 2. Identity Parsing for Movies
|
||||
|
||||
**User Story:** As a user, I want the system to extract movie titles and years from filenames, so that I can organize my movie collection into a predictable structure.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN a Video_File is located in the movie directory, THE Identity_Parser SHALL extract the movie title and release year from the filename
|
||||
2. THE Identity_Parser SHALL handle common filename patterns including "Title (Year)", "Title.Year", "Title - Year", and variations with quality tags
|
||||
3. WHEN a filename contains quality indicators (1080p, BluRay, WEB-DL), THE Identity_Parser SHALL exclude them from the title
|
||||
4. WHEN a filename contains release group tags in brackets or parentheses, THE Identity_Parser SHALL exclude them from the title
|
||||
5. WHEN the Identity_Parser cannot confidently extract a year, THE Identity_Parser SHALL mark the movie as requiring manual review
|
||||
6. THE Identity_Parser SHALL normalize titles by removing extra whitespace and standardizing capitalization
|
||||
7. WHEN multiple Video_Files share the same title and year, THE Identity_Parser SHALL flag them as potential duplicates
|
||||
|
||||
### 3. Identity Parsing for Series
|
||||
|
||||
**User Story:** As a user, I want the system to extract series titles, season numbers, and episode numbers from filenames, so that I can organize my TV series into a consistent structure.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN a Video_File is located in the series directory, THE Identity_Parser SHALL extract the series title, season number, and episode number from the filename
|
||||
2. THE Identity_Parser SHALL recognize common episode patterns including "SXXEYY", "SXXeYY", "SeasonXEpisodeY", and "XXxYY"
|
||||
3. THE Identity_Parser SHALL handle multi-episode files by extracting all episode numbers (e.g., "S01E01-E02")
|
||||
4. WHEN a filename contains quality indicators or release group tags, THE Identity_Parser SHALL exclude them from the series title
|
||||
5. WHEN the Identity_Parser cannot confidently extract season or episode numbers, THE Identity_Parser SHALL mark the file as requiring manual review
|
||||
6. THE Identity_Parser SHALL normalize series titles by removing extra whitespace and standardizing capitalization
|
||||
7. WHEN parsing completes, THE Identity_Parser SHALL group episodes by series title and season number
|
||||
|
||||
### 4. Series Completeness Analysis
|
||||
|
||||
**User Story:** As a user, I want to identify series with episode gaps in my collection, so that I can understand which series have missing episodes.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN analyzing a series, THE Analysis_Engine SHALL detect gaps in episode sequences within each season using heuristic detection
|
||||
2. WHEN a season has episodes numbered 1, 2, 4, 5, THE Analysis_Engine SHALL report episode 3 as missing (gap in range [1, 5])
|
||||
3. THE Analysis_Engine SHALL NOT calculate completeness percentages or determine if seasons are "complete" (v1 limitation: no external metadata)
|
||||
4. WHEN a series has multiple seasons, THE Analysis_Engine SHALL analyze each season independently
|
||||
5. THE Analysis_Engine SHALL generate a completeness report listing all series with detected episode gaps
|
||||
6. THE completeness report SHALL show episodes_found and episodes_missing (gaps in [min, max]) for each season
|
||||
|
||||
### 5. Duplicate Detection
|
||||
|
||||
**User Story:** As a user, I want to identify duplicate or redundant video files, so that I can remove unnecessary copies and save storage space.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN multiple Video_Files have identical titles and years (for movies), THE Analysis_Engine SHALL flag them as potential duplicates
|
||||
2. WHEN multiple Video_Files have identical series titles, season numbers, and episode numbers, THE Analysis_Engine SHALL flag them as potential duplicates
|
||||
3. WHERE file size metadata is available, THE Analysis_Engine SHALL compare file sizes to help identify quality differences
|
||||
4. WHERE video metadata is available, THE Analysis_Engine SHALL compare resolution and codec to help identify quality differences
|
||||
5. THE Analysis_Engine SHALL generate a duplicate report grouping all potential duplicates with their metadata
|
||||
6. THE Analysis_Engine SHALL provide comparison data without automatically recommending which file to keep
|
||||
|
||||
### 6. Execution Plan Generation
|
||||
|
||||
**User Story:** As a user, I want to review a detailed plan of all file operations before they are executed, so that I can verify the changes are correct and safe.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN the user requests organization, THE Plan_Generator SHALL create an Execution_Plan containing all proposed file operations
|
||||
2. THE Execution_Plan SHALL specify operation type (rename, move, quarantine, no-op) for each Video_File
|
||||
3. WHEN a movie should be organized, THE Execution_Plan SHALL specify moving it to "movie/Title (Year)/" directory structure
|
||||
4. WHEN a series episode should be organized, THE Execution_Plan SHALL specify moving it to "series/Title/Season XX/" directory structure with "SXXEYY.ext" filename
|
||||
5. THE Execution_Plan SHALL preserve the original top-level directory structure (movie, series, anime, other)
|
||||
6. THE Execution_Plan SHALL include source path, destination path, and operation type for each file
|
||||
7. THE Plan_Generator SHALL output the Execution_Plan in JSON format for both human readability and machine processing
|
||||
8. WHEN generating plans, THE Plan_Generator SHALL detect potential conflicts (destination file already exists) and mark them for user review
|
||||
9. THE Execution_Plan SHALL be editable by the user before execution
|
||||
|
||||
### 7. Safe File Operations
|
||||
|
||||
**User Story:** As a user, I want all file operations to be executed safely with dry-run support and explicit confirmation, so that I can prevent accidental data loss.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. THE Execution_Engine SHALL support Dry_Run_Mode that simulates operations without making changes
|
||||
2. WHEN executing in Dry_Run_Mode, THE Execution_Engine SHALL log all operations that would be performed
|
||||
3. WHEN executing file operations, THE Execution_Engine SHALL require explicit user confirmation before proceeding
|
||||
4. WHEN moving or renaming files, THE Execution_Engine SHALL create destination directories if they do not exist
|
||||
5. The Execution_Engine SHALL report the conflict and skip the affected operation without halting other planned operations.
|
||||
6. THE Execution_Engine SHALL log all file operations with timestamps, source paths, destination paths, and operation results
|
||||
7. WHEN any operation fails, THE Execution_Engine SHALL log the error and continue with remaining operations
|
||||
8. THE Execution_Engine SHALL generate an execution summary showing successful operations, failed operations, and skipped operations
|
||||
|
||||
### 8. Quarantine Operations
|
||||
|
||||
**User Story:** As a user, I want to safely isolate unwanted files in a quarantine directory, so that I can review them before permanent deletion.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN the user marks files for quarantine, THE Execution_Engine SHALL move them to a Quarantine_Directory within the library root
|
||||
2. THE Quarantine_Directory SHALL be located at `<library_root>/.quarantine/`
|
||||
3. THE Execution_Engine SHALL preserve the relative directory structure within the Quarantine_Directory
|
||||
4. WHEN moving files to quarantine, THE Execution_Engine SHALL record the original location in a quarantine manifest file
|
||||
5. THE quarantine manifest SHALL be stored as JSON and include original path, quarantine path, timestamp, and optional reason
|
||||
6. WHEN a quarantined file already exists at the destination, THE Execution_Engine SHALL append a numeric suffix to avoid overwriting
|
||||
7. THE Execution_Engine SHALL support listing all quarantined files with their original locations
|
||||
8. THE Execution_Engine SHALL prevent permanent deletion of files in v1
|
||||
|
||||
### 9. Rollback Operations
|
||||
|
||||
**User Story:** As a user, I want to undo file operations and restore files to their original locations, so that I can recover from mistakes.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN file operations are executed, THE Execution_Engine SHALL create a Rollback_Log containing all operations performed
|
||||
2. THE Rollback_Log SHALL include operation type, source path, destination path, and timestamp for each operation
|
||||
3. WHEN the user initiates a rollback, THE Execution_Engine SHALL restore files to their original locations based on the Rollback_Log
|
||||
4. WHEN rolling back quarantine operations, THE Execution_Engine SHALL move files from Quarantine_Directory back to their original locations
|
||||
5. WHEN rolling back move operations, THE Execution_Engine SHALL move files from destination back to source
|
||||
6. WHEN rolling back rename operations, THE Execution_Engine SHALL rename files back to their original names
|
||||
7. IF a rollback operation fails, THE Execution_Engine SHALL log the error and continue with remaining rollback operations
|
||||
8. THE Execution_Engine SHALL generate a rollback summary showing successful rollbacks, failed rollbacks, and skipped operations
|
||||
|
||||
### 10. Configuration Management
|
||||
|
||||
**User Story:** As a user, I want to configure parsing rules, directory templates, and policies, so that I can customize the tool to my preferences.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. THE Video_Library_Manager SHALL load configuration from a Configuration_File
|
||||
2. THE Configuration_File SHALL specify video file extensions to recognize
|
||||
3. THE Configuration_File SHALL specify directory templates for movies and series
|
||||
4. THE Configuration_File SHALL specify the library root path
|
||||
5. Parsing patterns for movie titles and series episodes are hardcoded in v1 (not user-configurable)
|
||||
6. WHEN the Configuration_File is missing, THE Video_Library_Manager SHALL create a default Configuration_File
|
||||
7. WHEN the Configuration_File contains invalid syntax, THE Video_Library_Manager SHALL report the error and use default values
|
||||
8. THE Video_Library_Manager SHALL validate configuration values and report errors for invalid settings
|
||||
|
||||
### 11. Reporting and Visualization
|
||||
|
||||
**User Story:** As a user, I want to view comprehensive reports about my video library, so that I can understand its current state and make informed decisions.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. THE Video_Library_Manager SHALL generate an inventory report listing all discovered Video_Files with metadata
|
||||
2. THE Video_Library_Manager SHALL generate a completeness report showing incomplete series with missing episodes
|
||||
3. THE Video_Library_Manager SHALL generate a duplicate report grouping potential duplicates with quality comparisons
|
||||
4. THE Video_Library_Manager SHALL generate a summary report with total file count, total size, and category breakdown
|
||||
5. THE Video_Library_Manager SHALL support exporting reports in CSV format for programmatic access
|
||||
6. THE Video_Library_Manager SHALL support exporting reports in JSON format for programmatic access
|
||||
7. THE Video_Library_Manager SHALL support exporting reports in human-readable text format
|
||||
8. WHEN generating reports, THE Video_Library_Manager SHALL include generation timestamp and library root path
|
||||
|
||||
### 12. Anime Inventory Support
|
||||
|
||||
**User Story:** As a user, I want anime files to be included in inventory scans, so that I have a complete view of my library even though anime organization is deferred.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN scanning the anime directory, THE Inventory_Scanner SHALL discover and catalog all Video_Files
|
||||
2. THE Inventory_Scanner SHALL record the same metadata for anime files as for other video files
|
||||
3. THE Identity_Parser SHALL skip parsing logic for anime files in v1
|
||||
4. THE Analysis_Engine SHALL skip completeness and duplicate analysis for anime files in v1
|
||||
5. THE Plan_Generator SHALL not generate organization plans for anime files in v1
|
||||
6. THE Video_Library_Manager SHALL include anime files in inventory reports with a flag indicating deferred processing
|
||||
7. THE Video_Library_Manager SHALL preserve the anime directory structure without modifications
|
||||
|
||||
### 13. Error Handling and Logging
|
||||
|
||||
**User Story:** As a user, I want comprehensive error handling and logging, so that I can troubleshoot issues and understand what the tool is doing.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. WHEN any operation encounters an error, THE Video_Library_Manager SHALL log the error with timestamp, operation type, and error details
|
||||
2. THE Video_Library_Manager SHALL continue processing remaining operations after encountering non-fatal errors
|
||||
3. WHEN encountering file system errors (permission denied, file not found), THE Video_Library_Manager SHALL log the error and skip the affected file
|
||||
4. WHEN encountering parsing errors, THE Video_Library_Manager SHALL log the error and mark the file for manual review
|
||||
5. THE Video_Library_Manager SHALL support configurable log levels (DEBUG, INFO, WARNING, ERROR)
|
||||
6. THE Video_Library_Manager SHALL write logs to both console output and a log file
|
||||
7. WHEN the log file exceeds 10MB, THE Video_Library_Manager SHALL rotate the log file
|
||||
|
||||
### 14. Command-Line Interface
|
||||
|
||||
**User Story:** As a user, I want a clear command-line interface to interact with the tool, so that I can easily perform all operations. In v1, the CLI SHALL expose only the minimal commands required to complete the end-to-end workflow. Other commands may exist internally but are not required to be user-facing.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
1. THE Video_Library_Manager SHALL provide a command-line interface with subcommands for each major operation
|
||||
2. THE Video_Library_Manager SHALL support a "scan" command to perform inventory scanning
|
||||
3. THE Video_Library_Manager SHALL support a "parse" command to perform identity parsing
|
||||
4. THE Video_Library_Manager SHALL support an "analyze" command to perform completeness and duplicate analysis
|
||||
5. THE Video_Library_Manager SHALL support a "plan" command to generate execution plans
|
||||
6. THE Video_Library_Manager SHALL support an "execute" command to execute plans with dry-run and confirmation options
|
||||
7. THE Video_Library_Manager SHALL support a "quarantine" command to manage quarantined files
|
||||
8. THE Video_Library_Manager SHALL support a "rollback" command to undo operations
|
||||
9. THE Video_Library_Manager SHALL support a "report" command to generate and export reports
|
||||
|
||||
10. THE Video_Library_Manager SHALL display help text for each command with usage examples
|
||||
11. WHEN the user provides invalid arguments, THE Video_Library_Manager SHALL display an error message and usage help
|
||||
@@ -0,0 +1,546 @@
|
||||
# Implementation Plan: Video Library Manager
|
||||
|
||||
## Overview
|
||||
|
||||
The Video Library Manager is a Python-based CLI tool for managing personal video collections with a safety-first, human-in-the-loop approach. This implementation plan breaks down the design into discrete coding tasks that build incrementally toward a complete, tested system.
|
||||
|
||||
**Implementation Approach**: Bottom-up development starting with core data structures, then components, CLI interface, and finally integration testing.
|
||||
|
||||
**Testing Strategy**: Dual approach using both unit tests (specific examples, edge cases) and property-based tests (universal properties across inputs). Property tests validate the 57 correctness properties defined in the design document.
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Project Foundation
|
||||
|
||||
- [x] 1.1 Set up Python project structure
|
||||
- Create package structure: `src/vlm/` with `__init__.py`
|
||||
- Create `pyproject.toml` with project metadata and dependencies
|
||||
- Use `uv` for Python package management
|
||||
- Add dependencies: Click, PyYAML, ffmpeg-python, pytest, hypothesis
|
||||
- Create application data directory structure: `~/.vlm/` with subdirectories for logs, plans, rollback
|
||||
- _Requirements: 10.1_
|
||||
|
||||
- [x] 1.2 Implement Configuration Manager
|
||||
- Define `Config` dataclass with all configuration fields
|
||||
- Implement `load_config(path: Path) -> Config` with YAML parsing
|
||||
- Implement `create_default_config(path: Path) -> Config` to generate default config
|
||||
- Implement `validate_config(config: Config) -> list[str]` for validation
|
||||
- Handle missing config files by creating defaults
|
||||
- Handle invalid YAML syntax with error reporting and fallback to defaults
|
||||
- _Requirements: 10.1-10.8_
|
||||
|
||||
- [ ]* 1.3 Write property tests for Configuration Manager
|
||||
- **Property 38: Configuration validation** - For any configuration with invalid values, validation SHALL detect and report errors
|
||||
- **Property 39: Default configuration validity** - For any missing configuration file, creating default SHALL produce valid configuration
|
||||
- **Property 40: Configuration error handling** - For any configuration with invalid YAML syntax, system SHALL report error and use defaults
|
||||
- _Requirements: 10.6, 10.7, 10.8_
|
||||
|
||||
- [x] 1.4 Implement logging infrastructure
|
||||
- Configure Python logging module with configurable log levels (DEBUG, INFO, WARNING, ERROR)
|
||||
- Set up dual output: console (INFO+) and file (DEBUG+)
|
||||
- Include timestamps, operation type, file paths in all log entries
|
||||
- Implement log rotation at 10MB threshold
|
||||
- _Requirements: 13.1-13.7_
|
||||
|
||||
- [ ]* 1.5 Write property tests for logging
|
||||
- **Property 49: Error logging** - For any operation with error, log SHALL contain timestamp, operation type, and error details
|
||||
- **Property 52: Log output** - For any logged message, message SHALL appear in console (if level permits) and log file
|
||||
- **Property 53: Log rotation** - For any log file exceeding 10MB, system SHALL rotate the log file
|
||||
- _Requirements: 13.1, 13.6, 13.7_
|
||||
|
||||
### 2. Core Data Structures
|
||||
|
||||
- [x] 2.1 Define video file and identity data structures
|
||||
- Create `VideoFile` dataclass: path, filename, size_bytes, modified_timestamp, category, optional metadata (resolution, codec, duration, bitrate)
|
||||
- Create `MovieIdentity` dataclass: title, year, confidence, needs_review, original_filename
|
||||
- Create `SeriesIdentity` dataclass: title, season, episodes, confidence, needs_review, original_filename
|
||||
- _Requirements: 1.2, 2.1, 3.1_
|
||||
|
||||
- [x] 2.2 Define execution and operation data structures
|
||||
- Create `FileOperation` dataclass: operation_type, source_path, destination_path, reason, has_conflict, conflict_reason
|
||||
- Create `ExecutionPlan` dataclass: plan_id, created_at, operations, summary
|
||||
- Create `OperationResult` dataclass: operation, success, error_message, executed_at
|
||||
- Create `RollbackLog` dataclass: log_id, execution_plan_id, executed_at, operations
|
||||
- _Requirements: 6.1, 7.6, 9.1_
|
||||
|
||||
- [x] 2.3 Define quarantine and state data structures
|
||||
- Create `QuarantineEntry` dataclass: original_path, quarantine_path, quarantined_at, reason, size_bytes, category
|
||||
- Create `QuarantineManifest` dataclass: entries
|
||||
- Create `FileState` dataclass: file_path, status, reason, updated_at
|
||||
- Create `StateStore` dataclass: states (dict), version, last_updated
|
||||
- _Requirements: 8.4, State Store design_
|
||||
|
||||
### 3. Inventory Scanner
|
||||
|
||||
- [x] 3.1 Implement core scanning functionality
|
||||
- Implement recursive directory scanning using `os.scandir()`
|
||||
- Filter files by configured video extensions
|
||||
- Record file metadata: path, filename, size, modification timestamp
|
||||
- Categorize files based on directory structure (movie/series/anime/other)
|
||||
- Handle inaccessible files gracefully: log error and continue scanning
|
||||
- _Requirements: 1.1, 1.2, 1.7_
|
||||
|
||||
- [x] 3.2 Add video metadata extraction
|
||||
- Implement optional ffprobe integration for video metadata
|
||||
- Extract resolution, codec, duration, bitrate when ffprobe available
|
||||
- Handle ffprobe failures gracefully with non-blocking fallback
|
||||
- _Requirements: 1.3_
|
||||
|
||||
- [x] 3.3 Implement inventory report generation
|
||||
- Generate CSV inventory report with all file metadata (primary format)
|
||||
- Implement CSV schema: path, filename, size_bytes, modified_timestamp, category, resolution, codec, duration_seconds, bitrate_kbps
|
||||
- Support JSON export as optional format
|
||||
- Include generation timestamp and library root in reports
|
||||
- _Requirements: 1.4, 1.8, 11.1, 11.5, 11.6, 11.8_
|
||||
|
||||
- [ ]* 3.4 Write property tests for Inventory Scanner
|
||||
- **Property 1: Scan completeness** - For any directory tree, scanning SHALL discover all and only files matching configured extensions
|
||||
- **Property 2: Scan idempotence** - For any directory tree, multiple scans SHALL produce identical results
|
||||
- **Property 3: Scan safety** - For any directory tree, scanning SHALL never modify files or directories
|
||||
- **Property 4: Scan resilience** - For any directory tree with inaccessible files, scanning SHALL discover all accessible files and continue
|
||||
- **Property 47: Anime inventory inclusion** - For any video files in anime directory, scanning SHALL discover and catalog them
|
||||
- _Requirements: 1.1, 1.2, 1.6, 1.7, 12.1, 12.2_
|
||||
|
||||
- [ ]* 3.5 Write unit tests for Inventory Scanner
|
||||
- Test scanning with various directory structures
|
||||
- Test file extension filtering
|
||||
- Test metadata extraction with and without ffprobe
|
||||
- Test error handling for inaccessible files
|
||||
- Test CSV and JSON report generation
|
||||
- _Requirements: 1.1-1.8_
|
||||
|
||||
### 4. Identity Parser
|
||||
|
||||
- [x] 4.1 Implement movie identity parsing
|
||||
- Parse patterns: "Title (Year)", "Title.Year", "Title - Year", "Title Year"
|
||||
- Extract title and year with confidence scoring
|
||||
- Implement quality tag removal: 1080p, 720p, 4K, BluRay, WEB-DL, HDTV, etc.
|
||||
- Implement release group tag removal: [RARBG], (YTS), etc.
|
||||
- Implement title normalization: remove extra whitespace, standardize capitalization
|
||||
- Flag files without extractable year as needs_review
|
||||
- _Requirements: 2.1-2.6_
|
||||
|
||||
- [x] 4.2 Implement series identity parsing
|
||||
- Parse patterns: "SXXEYY", "SXXeYY", "SeasonXEpisodeY", "XXxYY"
|
||||
- Extract series title, season number, episode numbers
|
||||
- Handle multi-episode files: extract all episode numbers (e.g., S01E01-E02)
|
||||
- Remove quality tags and release groups from series titles
|
||||
- Normalize series titles
|
||||
- Flag files with season=None or episodes=[] as needs_review (v1 constraint: these files excluded from organization plans)
|
||||
- _Requirements: 3.1-3.6_
|
||||
|
||||
- [x] 4.3 Implement episode grouping
|
||||
- Group parsed episodes by normalized series title and season number
|
||||
- _Requirements: 3.7_
|
||||
|
||||
- [x] 4.4 Write property tests for Identity Parser
|
||||
- **Property 5: Movie parsing** - For any filename matching common movie patterns, parser SHALL extract title and year
|
||||
- **Property 6: Series parsing** - For any filename matching common series patterns, parser SHALL extract series title, season, and episodes
|
||||
- **Property 7: Title normalization idempotence** - For any title string, normalizing multiple times SHALL produce same result
|
||||
- **Property 8: Ambiguous filename flagging** - For any filename where season/episode cannot be extracted, parser SHALL mark as needs_review
|
||||
- **Property 9: Episode grouping** - For any set of parsed episodes, grouping SHALL place episodes with identical normalized titles and seasons in same group
|
||||
- **Property 51: Parsing error handling** - For any filename that cannot be parsed, system SHALL log error and mark file for review
|
||||
- _Requirements: 2.1, 2.2, 2.5, 2.6, 3.1, 3.2, 3.5, 3.6, 3.7, 13.4_
|
||||
|
||||
- [x] 4.5 Write unit tests for Identity Parser
|
||||
- Test various movie filename patterns with different quality tags
|
||||
- Test various series filename patterns including multi-episode files
|
||||
- Test title normalization edge cases
|
||||
- Test ambiguous filename detection
|
||||
- Test episode grouping logic
|
||||
- _Requirements: 2.1-2.7, 3.1-3.7_
|
||||
|
||||
### 5. Analysis Engine
|
||||
|
||||
- [x] 5.1 Implement series completeness analysis
|
||||
- Group episodes by series title and season
|
||||
- For each season, find min and max episode numbers
|
||||
- Detect gaps in episode sequence [min, max] using heuristic detection
|
||||
- Generate completeness report showing episodes_found and episodes_missing (gaps only)
|
||||
- Do NOT calculate percentages or "complete" status (v1 constraint: no external metadata, heuristic gap detection only)
|
||||
- _Requirements: 4.1-4.6_
|
||||
|
||||
- [x] 5.2 Implement duplicate detection
|
||||
- Group files by normalized identity (title+year for movies, title+season+episode for series)
|
||||
- For groups with multiple files, flag as potential duplicates
|
||||
- Extract quality comparison data: file size, resolution, codec
|
||||
- Present comparison data without automatic recommendations
|
||||
- _Requirements: 5.1-5.6_
|
||||
|
||||
- [x] 5.3 Implement report generation
|
||||
- Generate completeness report (text/JSON) with series and detected gaps
|
||||
- Generate duplicate report (text/JSON) with quality comparisons
|
||||
- Generate summary report (text) with total files, size, category breakdown, files needing review
|
||||
- Include generation timestamp and library root in all reports
|
||||
- _Requirements: 11.2-11.4, 11.7, 11.8_
|
||||
|
||||
- [x] 5.4 Write property tests for Analysis Engine
|
||||
- **Property 10: Gap detection** - For any set of episodes within season, analysis SHALL detect missing episode numbers in range [min, max]
|
||||
- **Property 11: Multi-season independence** - For any series with multiple seasons, gap detection of one season SHALL not affect others
|
||||
- **Property 12: Duplicate detection for movies** - For any set of movies with identical normalized titles and years, all SHALL be grouped as duplicates
|
||||
- **Property 13: Duplicate detection for series** - For any set of series files with identical normalized titles, seasons, and episodes, all SHALL be grouped as duplicates
|
||||
- **Property 14: Duplicate quality comparison** - For any duplicate group, comparison data SHALL include available metadata for each file
|
||||
- **Property 42: Completeness report** - For any set of analyzed series, completeness report SHALL include all series with detected gaps
|
||||
- **Property 43: Duplicate report grouping** - For any set of detected duplicates, duplicate report SHALL group files by identity with comparison data
|
||||
- **Property 44: Summary report accuracy** - For any scanned library, summary report SHALL contain accurate counts and sizes
|
||||
- _Requirements: 4.1, 4.2, 4.4, 5.1, 5.2, 5.3, 11.2, 11.3, 11.4_
|
||||
|
||||
- [x] 5.5 Write unit tests for Analysis Engine
|
||||
- Test gap detection with various episode sequences
|
||||
- Test multi-season analysis
|
||||
- Test duplicate detection for movies and series
|
||||
- Test quality comparison data extraction
|
||||
- Test report generation in different formats
|
||||
- _Requirements: 4.1-4.6, 5.1-5.6, 11.2-11.4_
|
||||
|
||||
### 6. Plan Generator
|
||||
|
||||
- [x] 6.1 Implement plan generation logic
|
||||
- For each parsed identity, determine target directory using config templates
|
||||
- Apply movie template: "movie/{title} ({year})/"
|
||||
- Apply series template: "series/{title}/Season {season:02d}/"
|
||||
- Apply filename templates for movies and series
|
||||
- Create move/rename operations for movies and series with valid identities
|
||||
- Generate no-op operations for anime, other, and series files with season=None or episodes=[] (v1 constraint: flagged for manual review)
|
||||
- Preserve category boundaries (no cross-category moves)
|
||||
- _Requirements: 6.1-6.5, 12.5_
|
||||
|
||||
- [x] 6.2 Implement conflict detection
|
||||
- Check if destination file already exists for each operation
|
||||
- Mark operations with conflicts: set has_conflict=True and conflict_reason
|
||||
- _Requirements: 6.8_
|
||||
|
||||
- [x] 6.3 Implement plan serialization
|
||||
- Save execution plan to JSON format (human-readable and editable)
|
||||
- Include plan_id (UUID), created_at timestamp, operations list, summary
|
||||
- _Requirements: 6.6, 6.7_
|
||||
|
||||
- [ ]* 6.4 Write property tests for Plan Generator
|
||||
- **Property 15: Plan operation completeness** - For any set of video files with parsed identities, execution plan SHALL contain exactly one operation per file
|
||||
- **Property 16: Movie template consistency** - For any movie identity, applying templates SHALL always produce same destination path
|
||||
- **Property 17: Series template consistency** - For any series episode identity, applying templates SHALL always produce same destination path
|
||||
- **Property 18: Category boundary preservation** - For any file in category directory, execution plan SHALL specify destination within same category
|
||||
- **Property 19: Destination path uniqueness** - For any execution plan, no two operations SHALL specify same destination unless marked as conflict
|
||||
- **Property 20: Conflict detection** - For any execution plan where destination file exists, operation SHALL be marked as conflict
|
||||
- **Property 21: Plan JSON validity** - For any generated execution plan, output SHALL be valid JSON
|
||||
- **Property 48: Anime processing deferral** - For any anime files, execution plans SHALL contain only no-op operations
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.7, 6.8, 12.3, 12.4, 12.5_
|
||||
|
||||
- [ ]* 6.5 Write unit tests for Plan Generator
|
||||
- Test plan generation for various movie and series identities
|
||||
- Test template application with different configurations
|
||||
- Test no-op generation for anime and ambiguous files
|
||||
- Test conflict detection scenarios
|
||||
- Test JSON serialization and deserialization
|
||||
- _Requirements: 6.1-6.9_
|
||||
|
||||
### 7. Execution Engine
|
||||
|
||||
- [x] 7.1 Implement execution mode handling
|
||||
- Support mode parameter: "dry-run" (default) or "execute"
|
||||
- In dry-run mode: simulate operations and log what would happen without making changes
|
||||
- In execute mode: perform actual file operations
|
||||
- Require --confirm flag for execute mode (v1 constraint: safety-first approach)
|
||||
- _Requirements: 7.1, 7.2_
|
||||
|
||||
- [x] 7.2 Implement file operation execution
|
||||
- Create destination directories if they don't exist
|
||||
- Handle conflicts: skip operation and report (don't halt other operations, v1 constraint)
|
||||
- Execute move/rename operations for each FileOperation
|
||||
- Log all operations with timestamps, paths, and results
|
||||
- Continue processing after non-fatal errors
|
||||
- _Requirements: 7.4, 7.5, 7.6, 7.7_
|
||||
|
||||
- [x] 7.3 Implement execution summary and rollback log
|
||||
- Generate execution summary with counts: successful, failed, skipped operations
|
||||
- Save rollback log in execute mode only (not in dry-run)
|
||||
- Include operation type, source, destination, timestamp for each operation
|
||||
- _Requirements: 7.8, 9.1, 9.2_
|
||||
|
||||
- [ ]* 7.4 Write property tests for Execution Engine
|
||||
- **Property 22: Execution mode safety** - For any execution plan, mode="dry-run" SHALL never modify files
|
||||
- **Property 23: Directory creation** - For any file operation with destination in non-existent directory, executing SHALL create necessary parent directories
|
||||
- **Property 24: Conflict handling** - For any execution plan with conflicts, executing SHALL skip conflicted operations and continue processing
|
||||
- **Property 25: Operation logging** - For any executed operation, log SHALL contain timestamp, operation type, paths, and result
|
||||
- **Property 26: Execution summary** - For any execution, summary SHALL contain accurate counts of successful, failed, and skipped operations
|
||||
- **Property 50: Error resilience** - For any operation sequence with non-fatal errors, system SHALL log errors and continue processing
|
||||
- _Requirements: 7.1, 7.2, 7.4, 7.5, 7.6, 7.7, 7.8, 13.2, 13.3_
|
||||
|
||||
- [ ]* 7.5 Write unit tests for Execution Engine
|
||||
- Test dry-run mode (no file modifications)
|
||||
- Test execute mode with actual file operations
|
||||
- Test directory creation
|
||||
- Test conflict handling
|
||||
- Test error handling and resilience
|
||||
- Test execution summary generation
|
||||
- Test rollback log creation
|
||||
- _Requirements: 7.1-7.8_
|
||||
|
||||
### 8. Rollback Functionality
|
||||
|
||||
- [x] 8.1 Implement rollback execution
|
||||
- Load rollback log from JSON
|
||||
- Reverse operation list (LIFO order for best-effort restoration)
|
||||
- For each operation: attempt to move destination back to source
|
||||
- Handle rollback failures gracefully: log error and continue
|
||||
- Generate rollback summary with counts: successful, failed, skipped
|
||||
- _Requirements: 9.1-9.8_
|
||||
|
||||
- [ ]* 8.2 Write property tests for rollback
|
||||
- **Property 27: Rollback best-effort** - For any successful execution, rolling back SHALL attempt to restore all files to original locations
|
||||
- **Property 28: Rollback idempotence** - For any rollback log, executing rollback multiple times SHALL produce same final state
|
||||
- **Property 29: Rollback resilience** - For any rollback with failures, process SHALL log errors and continue processing
|
||||
- **Property 30: Rollback summary** - For any rollback execution, summary SHALL contain accurate counts of successful, failed, and skipped operations
|
||||
- _Requirements: 9.1, 9.2, 9.7, 9.8_
|
||||
|
||||
- [ ]* 8.3 Write unit tests for rollback
|
||||
- Test rollback of move operations
|
||||
- Test rollback of rename operations
|
||||
- Test rollback failure handling
|
||||
- Test rollback summary generation
|
||||
- Test rollback idempotence
|
||||
- _Requirements: 9.1-9.8_
|
||||
|
||||
### 9. Quarantine Manager
|
||||
|
||||
- [x] 9.1 Implement quarantine operations
|
||||
- Verify file is in movie or series category (reject anime/other with error)
|
||||
- Determine relative path from category root
|
||||
- Construct quarantine path: `<category_root>/.quarantine/<relative_path>`
|
||||
- Handle destination conflicts: append numeric suffix (_1, _2, etc.)
|
||||
- Move file to category-specific quarantine directory
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.6_
|
||||
|
||||
- [x] 9.2 Implement quarantine manifest management
|
||||
- Update category-specific manifest.json with quarantine entry
|
||||
- Include original_path, quarantine_path, timestamp, reason, size_bytes, category
|
||||
- Save manifest to `<category_root>/.quarantine/manifest.json`
|
||||
- _Requirements: 8.4, 8.5_
|
||||
|
||||
- [x] 9.3 Implement quarantine listing and restoration
|
||||
- List quarantined files from category manifests, optionally filtered by category
|
||||
- Restore files from quarantine to original locations (best-effort)
|
||||
- _Requirements: 8.7_
|
||||
|
||||
- [ ]* 9.4 Write property tests for Quarantine Manager
|
||||
- **Property 31: Quarantine location** - For any movie or series file marked for quarantine, file SHALL be moved to `<category_root>/.quarantine/`
|
||||
- **Property 32: Quarantine category restriction** - For any file in anime or other categories, quarantine operations SHALL be rejected with error
|
||||
- **Property 33: Quarantine manifest** - For any quarantined file, category-specific manifest SHALL contain original path, quarantine path, timestamp, and category
|
||||
- **Property 34: Quarantine conflict handling** - For any file being quarantined where destination exists, system SHALL append numeric suffix
|
||||
- **Property 35: Quarantine listing** - For any set of quarantined files, listing SHALL return all entries from category manifests, optionally filtered by category
|
||||
- **Property 36: Quarantine restore** - For any quarantined file, restoring SHALL attempt to move file back to original location
|
||||
- **Property 37: No permanent deletion in v1** - For any file operation in v1, system SHALL never permanently delete files
|
||||
- _Requirements: 8.1, 8.2, 8.4, 8.5, 8.6, 8.7, 8.8_
|
||||
|
||||
- [ ]* 9.5 Write unit tests for Quarantine Manager
|
||||
- Test quarantine operations for movie and series files
|
||||
- Test category restriction enforcement
|
||||
- Test manifest creation and updates
|
||||
- Test conflict handling with numeric suffixes
|
||||
- Test listing and restoration
|
||||
- _Requirements: 8.1-8.8_
|
||||
|
||||
### 10. State Store
|
||||
|
||||
- [x] 10.1 Implement State Store operations
|
||||
- Implement `load_state(path: Path) -> StateStore` to load from JSON
|
||||
- Implement `save_state(store: StateStore, path: Path)` to save to JSON
|
||||
- Implement `get_file_state(file_path: Path) -> Optional[FileState]` for path-based lookup
|
||||
- Implement `set_file_state(file_path: Path, status: str, reason: Optional[str])` with idempotent updates and timestamp
|
||||
- Implement `query_by_status(status: str) -> list[FileState]` to filter by status
|
||||
- Implement `clear_state(file_path: Path)` to remove file state
|
||||
- Validate status values: "reviewed", "ignored", "planned", "executed", "quarantined"
|
||||
- _State Store design_
|
||||
|
||||
- [ ]* 10.2 Write property tests for State Store
|
||||
- **Property 54: State persistence** - For any state store saved to disk, loading SHALL produce equivalent StateStore with all file states preserved
|
||||
- **Property 55: State query** - For any status value, querying SHALL return all files with that status
|
||||
- **Property 56: State update** - For any file path, setting state SHALL update store and subsequent queries return new status
|
||||
- **Property 57: State JSON validity** - For any state store, saving SHALL produce valid JSON
|
||||
- _State Store design_
|
||||
|
||||
- [ ]* 10.3 Write unit tests for State Store
|
||||
- Test state loading and saving
|
||||
- Test state queries by status
|
||||
- Test state updates and idempotence
|
||||
- Test state clearing
|
||||
- Test status validation
|
||||
- _State Store design_
|
||||
|
||||
### 11. Report Generator
|
||||
|
||||
- [x] 11.1 Implement report generation
|
||||
- Generate inventory report in CSV/JSON formats with all file metadata
|
||||
- Generate completeness report in text/JSON formats with series gaps
|
||||
- Generate duplicate report in text/JSON formats with quality comparisons
|
||||
- Generate summary report in text format with library statistics
|
||||
- Include generation timestamp and library root in all reports
|
||||
- _Requirements: 11.1-11.8_
|
||||
|
||||
- [ ]* 11.2 Write property tests for Report Generator
|
||||
- **Property 41: Inventory report completeness** - For any set of scanned video files, inventory report SHALL include entry for each file
|
||||
- **Property 45: Report format validity** - For any report, output SHALL be valid in specified format (CSV, JSON, or text)
|
||||
- **Property 46: Report metadata** - For any generated report, report SHALL include generation timestamp and library root
|
||||
- _Requirements: 11.1, 11.5, 11.6, 11.7, 11.8_
|
||||
|
||||
- [ ]* 11.3 Write unit tests for Report Generator
|
||||
- Test inventory report generation in CSV and JSON
|
||||
- Test completeness report generation
|
||||
- Test duplicate report generation
|
||||
- Test summary report generation
|
||||
- Test report metadata inclusion
|
||||
- _Requirements: 11.1-11.8_
|
||||
|
||||
### 12. CLI Interface
|
||||
|
||||
- [x] 12.1 Set up CLI framework
|
||||
- Set up Click CLI with main entry point
|
||||
- Implement global options: --config, --log-level
|
||||
- Add help text for main command
|
||||
- Implement error handling for invalid arguments
|
||||
- _Requirements: 14.1, 14.10, 14.11_
|
||||
|
||||
- [x] 12.2 Implement scan command
|
||||
- `vlm scan [--output inventory.csv]`
|
||||
- Wire to Inventory Scanner
|
||||
- Display progress and summary
|
||||
- _Requirements: 14.2_
|
||||
|
||||
- [x] 12.3 Implement parse command
|
||||
- `vlm parse [--input inventory.csv] [--output identities.json]`
|
||||
- Wire to Identity Parser
|
||||
- Display parsing statistics
|
||||
- _Requirements: 14.3_
|
||||
|
||||
- [x] 12.4 Implement analyze command
|
||||
- `vlm analyze [--input identities.json] [--output analysis.json]`
|
||||
- Wire to Analysis Engine
|
||||
- Display analysis summary
|
||||
- _Requirements: 14.4_
|
||||
|
||||
- [x] 12.5 Implement plan command
|
||||
- `vlm plan [--input identities.json] [--output plan.json]`
|
||||
- Wire to Plan Generator
|
||||
- Display plan summary with operation counts
|
||||
- _Requirements: 14.5_
|
||||
|
||||
- [x] 12.6 Implement execute command
|
||||
- `vlm execute [--plan plan.json] [--confirm]`
|
||||
- Wire to Execution Engine
|
||||
- Default to dry-run mode, require --confirm for actual execution
|
||||
- Display execution progress and summary
|
||||
- _Requirements: 14.6_
|
||||
|
||||
- [x] 12.7 Implement quarantine commands
|
||||
- `vlm quarantine list [--category movie|series]`
|
||||
- `vlm quarantine add <file> [--reason "duplicate"]`
|
||||
- `vlm quarantine restore <file>`
|
||||
- Wire to Quarantine Manager
|
||||
- _Requirements: 14.7_
|
||||
|
||||
- [x] 12.8 Implement rollback command
|
||||
- `vlm rollback [--log rollback.json]`
|
||||
- Wire to rollback functionality
|
||||
- Display rollback progress and summary
|
||||
- _Requirements: 14.8_
|
||||
|
||||
- [x] 12.9 Implement report commands
|
||||
- `vlm report inventory [--format csv|json|text]`
|
||||
- `vlm report completeness [--format text|json]`
|
||||
- `vlm report duplicates [--format text|json]`
|
||||
- `vlm report summary`
|
||||
- Wire to Report Generator
|
||||
- _Requirements: 14.9_
|
||||
|
||||
- [x] 12.10 Implement state commands
|
||||
- `vlm state show <file>`
|
||||
- `vlm state set <file> --status reviewed [--reason "checked manually"]`
|
||||
- `vlm state query --status ignored`
|
||||
- `vlm state clear <file>`
|
||||
- Wire to State Store
|
||||
- _Requirements: 14.9_
|
||||
|
||||
- [x] 12.11 Implement config commands
|
||||
- `vlm config init`
|
||||
- `vlm config show`
|
||||
- `vlm config validate`
|
||||
- Wire to Configuration Manager
|
||||
- _Requirements: 14.9_
|
||||
|
||||
- [ ]* 12.12 Write integration tests for CLI
|
||||
- Test each command with various options
|
||||
- Test error handling for invalid arguments
|
||||
- Test help text display
|
||||
- Test end-to-end workflow through CLI
|
||||
- _Requirements: 14.1-14.11_
|
||||
|
||||
### 13. Integration and Polish
|
||||
|
||||
- [ ] 13.1 End-to-end integration testing
|
||||
- Test complete workflow: scan → parse → analyze → plan → execute (dry-run) → execute (confirm) → rollback
|
||||
- Test with real-world filename patterns and directory structures
|
||||
- Test error scenarios: inaccessible files, invalid configs, conflicts
|
||||
- Test quarantine operations end-to-end
|
||||
- Test state management throughout workflow
|
||||
- Verify all reports generate correctly with accurate data
|
||||
- _All requirements_
|
||||
|
||||
- [ ] 13.2 Error handling validation
|
||||
- Test parsing errors with ambiguous filenames
|
||||
- Test file system errors (permissions, disk full, network issues)
|
||||
- Test configuration errors
|
||||
- Verify error logging and resilience
|
||||
- _Requirements: 13.1-13.7_
|
||||
|
||||
- [ ] 13.3 Documentation
|
||||
- Write README with installation instructions
|
||||
- Document typical workflow with examples
|
||||
- Add usage examples for all CLI commands
|
||||
- Document configuration options
|
||||
- Document v1 constraints and limitations
|
||||
- _Requirements: 14.10_
|
||||
|
||||
- [ ] 13.4 Final checkpoint
|
||||
- Ensure all tests pass (unit, property-based, integration)
|
||||
- Verify all 57 correctness properties are validated
|
||||
- Review code for security considerations (path validation, filename sanitization)
|
||||
- Verify logging is comprehensive and useful
|
||||
- Test with large library (performance validation)
|
||||
- Ask user if any questions or issues arise
|
||||
|
||||
## Notes
|
||||
|
||||
### Testing Approach
|
||||
|
||||
- **Property-based tests** (marked with `*`): Validate universal correctness properties using Hypothesis with minimum 100 iterations per test. Each test references a specific property from the design document.
|
||||
- **Unit tests** (marked with `*`): Test specific examples, edge cases, and error conditions for each component.
|
||||
- **Integration tests**: Validate end-to-end workflows and component interactions.
|
||||
|
||||
### Task Dependencies
|
||||
|
||||
Tasks are ordered to build incrementally:
|
||||
|
||||
1. Foundation (config, logging, data structures)
|
||||
2. Core components (scanner, parser, analysis)
|
||||
3. Execution components (plan, execute, rollback)
|
||||
4. Supporting features (quarantine, state, reports)
|
||||
5. CLI interface
|
||||
6. Integration and polish
|
||||
|
||||
### v1 Constraints
|
||||
|
||||
- **Quarantine**: Category-level only (movie/.quarantine/, series/.quarantine/), anime/other rejected
|
||||
- **Completeness**: Heuristic gap detection only, no percentages or "complete" status
|
||||
- **Parsing**: Hardcoded patterns, not user-configurable
|
||||
- **Anime**: Inventory only, no organization
|
||||
- **Deletion**: Quarantine only, no permanent deletion
|
||||
- **State Store**: Simple path-based indexing, no fingerprint or move tracking
|
||||
- **Execution**: Defaults to dry-run, requires --confirm for actual changes
|
||||
- **Rollback**: Best-effort, not guaranteed restoration
|
||||
|
||||
### Property-Based Testing Configuration
|
||||
|
||||
- **Framework**: Hypothesis (Python PBT library)
|
||||
- **Iterations**: Minimum 100 per test
|
||||
- **Tagging**: Each test includes comment: `# Feature: video-library-manager, Property N: [description]`
|
||||
- **Coverage**: All 57 correctness properties from design document
|
||||
Reference in New Issue
Block a user