reverse-diagrams 1.3.4__tar.gz → 1.3.5__tar.gz

{reverse_diagrams-1.3.4 → reverse_diagrams-1.3.5}/.github/workflows/publish-to-test-pypi.yml

@@ -10,7 +10,7 @@ jobs:
     steps:
     - uses: actions/checkout@v4
     - name: Set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: "3.x"
     - name: Install pypa/build
@@ -22,7 +22,7 @@ jobs:
     - name: Build a binary wheel and a source tarball
       run: python3 -m build
     - name: Store the distribution packages
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
@@ -42,7 +42,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
@@ -63,12 +63,12 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
     - name: Sign the dists with Sigstore
-      uses: sigstore/gh-action-sigstore-python@v1.2.3
+      uses: sigstore/gh-action-sigstore-python@v2.1.1
       with:
         inputs: >-
           ./dist/*.tar.gz
@@ -107,7 +107,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/

{reverse_diagrams-1.3.4 → reverse_diagrams-1.3.5}/.gitignore

@@ -252,3 +252,32 @@ cython_debug/
 #.idea/
 
 # End of https://www.toptal.com/developers/gitignore/api/python,pycharm+all
+
+# Project-specific ignores
+# Test files
+test.py
+test2.py
+test3.py
+testdata.txt
+
+# Generated diagrams folder (exclude entire folder)
+diagrams/
+
+# Terminal history files
+*terminal*history*
+CUserswalejAppDataLocalJetBrainsPyCharm*
+
+# Cast files (asciinema recordings)
+*.cast
+
+# Temporary summary files (keep only essential docs)
+README_UPDATE_SUMMARY.md
+LOG_LEVEL_CHANGES_SUMMARY.md
+IMPLEMENTATION_STATUS_UPDATE.md
+FINAL_STATUS_SUMMARY.md
+
+# Temporary files
+*.tmp
+*.bak
+*.swp
+*~

reverse_diagrams-1.3.5/.kiro/specs/tag-based-filtering/design.md

@@ -0,0 +1,258 @@
+# Design Document: Tag-Based Filtering
+
+## Overview
+
+The tag-based filtering feature extends Reverse Diagrams with the capability to filter AWS resources based on their tags, enabling users to create focused architecture diagrams. This feature integrates seamlessly with the existing plugin architecture and provides flexible filtering options for different use cases.
+
+## Architecture
+
+### High-Level Architecture
+
+```mermaid
+graph TB
+    CLI[CLI Interface] --> FilterParser[Tag Filter Parser]
+    FilterParser --> FilterEngine[Tag Filter Engine]
+    FilterEngine --> PluginManager[Plugin Manager]
+    PluginManager --> Plugin1[Organizations Plugin]
+    PluginManager --> Plugin2[EC2 Plugin]
+    PluginManager --> Plugin3[Identity Center Plugin]
+    
+    FilterEngine --> PresetManager[Preset Manager]
+    PresetManager --> ConfigStore[Configuration Storage]
+    
+    Plugin1 --> AWSOrg[AWS Organizations API]
+    Plugin2 --> AWSEC2[AWS EC2 API]
+    Plugin3 --> AWSSSO[AWS SSO API]
+    
+    FilterEngine --> DiagramGenerator[Diagram Generator]
+    DiagramGenerator --> Output[Filtered Diagrams]
+```
+
+### Component Interaction Flow
+
+1. **CLI Parsing**: User provides tag filter options via command line
+2. **Filter Parsing**: Tag filter parser validates and structures filter criteria
+3. **Filter Engine**: Coordinates filtering across all plugins
+4. **Plugin Integration**: Each plugin applies filters during data collection
+5. **Relationship Preservation**: Maintains resource relationships after filtering
+6. **Diagram Generation**: Creates diagrams with only filtered resources
+
+## Components and Interfaces
+
+### 1. Tag Filter Engine (`src/filters/tag_filter_engine.py`)
+
+**Purpose**: Central coordinator for all tag filtering operations
+
+**Key Methods**:
+- `apply_filters(resources, filters)`: Apply tag filters to resource collections
+- `validate_filters(filters)`: Validate filter syntax and logic
+- `combine_filters(include_filters, exclude_filters, logic)`: Combine multiple filters
+- `preserve_relationships(filtered_resources)`: Maintain resource relationships
+
+**Interface**:
+```python
+class TagFilterEngine:
+    def apply_filters(self, resources: List[Dict], filters: TagFilterSet) -> List[Dict]
+    def validate_filters(self, filters: TagFilterSet) -> ValidationResult
+    def combine_filters(self, include: List[TagFilter], exclude: List[TagFilter], logic: str) -> TagFilterSet
+    def preserve_relationships(self, resources: List[Dict]) -> List[Dict]
+```
+
+### 2. Tag Filter Parser (`src/filters/tag_filter_parser.py`)
+
+**Purpose**: Parse and validate CLI tag filter arguments
+
+**Key Methods**:
+- `parse_cli_args(args)`: Parse CLI arguments into structured filters
+- `parse_tag_expression(expression)`: Parse individual tag expressions
+- `validate_syntax(expression)`: Validate tag filter syntax
+
+**Interface**:
+```python
+class TagFilterParser:
+    def parse_cli_args(self, args: argparse.Namespace) -> TagFilterSet
+    def parse_tag_expression(self, expression: str) -> TagFilter
+    def validate_syntax(self, expression: str) -> bool
+```
+
+### 3. Plugin Filter Interface (`src/plugins/base.py` extension)
+
+**Purpose**: Standardized interface for plugins to support tag filtering
+
+**Extended Methods**:
+- `supports_tag_filtering()`: Declare tag filtering capability
+- `apply_tag_filters(filters)`: Apply filters during data collection
+- `get_resource_tags(resource)`: Extract tags from AWS resources
+
+**Interface Extension**:
+```python
+class AWSServicePlugin:
+    def supports_tag_filtering(self) -> bool
+    def apply_tag_filters(self, filters: TagFilterSet) -> None
+    def get_resource_tags(self, resource: Dict) -> Dict[str, str]
+    def filter_resources_by_tags(self, resources: List[Dict], filters: TagFilterSet) -> List[Dict]
+```
+
+### 4. Preset Manager (`src/filters/preset_manager.py`)
+
+**Purpose**: Manage saved tag filter configurations
+
+**Key Methods**:
+- `save_preset(name, filters)`: Save filter configuration as preset
+- `load_preset(name)`: Load saved filter configuration
+- `list_presets()`: List available presets
+- `delete_preset(name)`: Remove saved preset
+
+**Interface**:
+```python
+class PresetManager:
+    def save_preset(self, name: str, filters: TagFilterSet) -> bool
+    def load_preset(self, name: str) -> TagFilterSet
+    def list_presets(self) -> List[str]
+    def delete_preset(self, name: str) -> bool
+```
+
+## Data Models
+
+### TagFilter
+```python
+@dataclass
+class TagFilter:
+    key: str
+    value: Optional[str] = None  # None for key-only filters
+    operator: str = "equals"  # equals, exists, not_equals, not_exists
+    
+    def matches(self, resource_tags: Dict[str, str]) -> bool:
+        """Check if this filter matches the given resource tags"""
+```
+
+### TagFilterSet
+```python
+@dataclass
+class TagFilterSet:
+    include_filters: List[TagFilter]
+    exclude_filters: List[TagFilter]
+    logic: str = "AND"  # AND, OR
+    service_specific: Dict[str, List[TagFilter]] = field(default_factory=dict)
+    
+    def apply_to_resource(self, resource: Dict, service: str) -> bool:
+        """Determine if resource should be included based on filters"""
+```
+
+### FilterResult
+```python
+@dataclass
+class FilterResult:
+    included_resources: List[Dict]
+    excluded_resources: List[Dict]
+    filter_stats: Dict[str, int]
+    warnings: List[str]
+```
+
+## Correctness Properties
+
+*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
+
+### Property Reflection
+
+After reviewing all properties identified in the prework, several can be combined or consolidated:
+- Properties 2.2 and 2.3 (AND/OR logic) can be combined into a single comprehensive logical operations property
+- Properties 3.1, 3.3, and 4.1 (service-specific filtering) can be combined into a service isolation property
+- Properties 5.2-5.7 (CLI parsing) can be combined into a comprehensive CLI parsing property
+- Properties 8.1-8.4 (preset management) can be combined into a preset operations property
+
+### Core Filtering Properties
+
+**Property 1: Tag Filter Matching**
+*For any* AWS resource with tags and any tag filter, the filter matching logic should correctly identify whether the resource matches the filter criteria based on key-value or key-only matching rules
+**Validates: Requirements 1.1, 1.2, 1.3**
+
+**Property 2: Logical Operations Consistency**
+*For any* set of tag filters with AND or OR logic, the filtering system should include resources that match all filters (AND) or any filter (OR) consistently across all resource types
+**Validates: Requirements 2.1, 2.2, 2.3**
+
+**Property 3: Include-Exclude Filter Precedence**
+*For any* combination of include and exclude filters, the system should first apply include filters then remove resources matching exclude filters, ensuring correct precedence
+**Validates: Requirements 2.4**
+
+**Property 4: Service Isolation in Filtering**
+*For any* service-specific tag filter, only the specified services should have filters applied while other services include all their resources
+**Validates: Requirements 3.1, 3.3, 4.1**
+
+**Property 5: Relationship Preservation**
+*For any* set of filtered resources, all relationships between the remaining resources should be preserved in the final diagram
+**Validates: Requirements 1.5, 4.4**
+
+**Property 6: Filter Validation**
+*For any* tag filter input, the validation system should correctly identify valid and invalid filter syntax and provide appropriate error messages
+**Validates: Requirements 2.5, 6.1, 6.4**
+
+**Property 7: CLI Argument Parsing**
+*For any* valid CLI tag filter arguments, the parser should correctly extract and structure the filter criteria into the appropriate data models
+**Validates: Requirements 5.2, 5.3, 5.4, 5.5, 5.6, 5.7**
+
+**Property 8: Performance Optimization**
+*For any* tag filtering operation, filters should be applied during data collection phase to minimize API calls and processing overhead
+**Validates: Requirements 7.1, 7.2, 7.3**
+
+**Property 9: Preset Operations**
+*For any* preset save/load operation, the configuration should be stored and retrieved correctly with all filter settings preserved
+**Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.5**
+
+**Property 10: Plugin Interface Consistency**
+*For any* plugin that supports tag filtering, the filtering behavior should be consistent with the standardized interface across all plugins
+**Validates: Requirements 10.1, 10.2, 10.3, 10.4, 10.5**
+
+**Property 11: Empty Result Handling**
+*For any* tag filter that matches no resources, the system should generate appropriate warnings and empty diagrams without errors
+**Validates: Requirements 1.4, 6.2**
+
+**Property 12: Graceful Service Degradation**
+*For any* service that doesn't support tags, the filtering system should include all resources from that service and provide appropriate user feedback
+**Validates: Requirements 3.5, 6.3**
+
+## Error Handling
+
+### Filter Validation Errors
+- **Invalid Syntax**: Clear error messages with examples of correct syntax
+- **Conflicting Options**: Guidance on resolving conflicting filter combinations
+- **Missing Required Parameters**: Specific information about required filter components
+
+### Runtime Errors
+- **No Matching Resources**: Warning messages with applied filter details
+- **Broken Relationships**: Warnings about orphaned resources in diagrams
+- **Service Limitations**: Informational messages about services that don't support tags
+
+### Performance Considerations
+- **Large Resource Sets**: Progress indicators for long-running filter operations
+- **API Rate Limits**: Graceful handling of AWS API throttling during filtered data collection
+- **Memory Usage**: Efficient filtering algorithms for large resource collections
+
+## Testing Strategy
+
+### Unit Tests
+- Tag filter parsing and validation
+- Individual filter matching logic
+- CLI argument processing
+- Preset save/load operations
+- Error handling scenarios
+
+### Property-Based Tests
+- **Filter Matching Consistency**: Test filter matching across various resource and tag combinations (minimum 100 iterations)
+- **Logical Operations**: Verify AND/OR logic works correctly with random filter sets (minimum 100 iterations)
+- **Relationship Preservation**: Ensure filtered resources maintain correct relationships (minimum 100 iterations)
+- **CLI Parsing**: Test CLI argument parsing with various input combinations (minimum 100 iterations)
+
+Each property test will be tagged with: **Feature: tag-based-filtering, Property {number}: {property_text}**
+
+### Integration Tests
+- End-to-end filtering with real AWS resource data
+- Multi-service filtering scenarios
+- Plugin integration with filtering capabilities
+- Performance testing with large resource sets
+
+### Edge Case Tests
+- Empty filter results
+- Services without tag support
+- Complex filter combinations
+- Invalid filter syntax handling

reverse_diagrams-1.3.5/.kiro/specs/tag-based-filtering/requirements.md

@@ -0,0 +1,139 @@
+# Requirements Document
+
+## Introduction
+
+This specification defines tag-based filtering functionality for Reverse Diagrams, enabling users to create focused architecture diagrams by filtering AWS resources based on their tags. This feature addresses the need to generate diagrams for specific environments, applications, or organizational units without the noise of unrelated resources.
+
+## Glossary
+
+- **Tag_Filter**: A key-value pair or key-only filter used to match AWS resource tags
+- **Resource_Filter**: A filtering mechanism that includes or excludes AWS resources based on tag criteria
+- **Diagram_Scope**: The subset of AWS resources included in a generated diagram after applying filters
+- **Tag_Strategy**: The approach used for filtering (include-only, exclude, or mixed filtering)
+- **Plugin_Filter**: A filter applied at the plugin level to control which resources are collected and processed
+- **Account_Filter**: A filter that applies tag-based filtering across all AWS services within an account
+- **Service_Filter**: A filter that applies tag-based filtering to specific AWS services (e.g., EC2 only)
+
+## Requirements
+
+### Requirement 1: Basic Tag Filtering
+
+**User Story:** As a DevOps engineer, I want to filter AWS resources by tags, so that I can create diagrams showing only resources relevant to specific environments or applications.
+
+#### Acceptance Criteria
+
+1. WHEN a user specifies tag filters via CLI, THE System SHALL collect only resources matching those tag criteria
+2. WHEN a user provides key-value tag filters (e.g., Environment=Production), THE System SHALL match resources with exact key-value pairs
+3. WHEN a user provides key-only tag filters (e.g., Environment), THE System SHALL match resources that have the specified tag key regardless of value
+4. WHEN no resources match the specified tag filters, THE System SHALL generate an empty diagram with appropriate messaging
+5. WHEN tag filters are applied, THE System SHALL preserve all relationships between filtered resources
+
+### Requirement 2: Multiple Tag Filter Support
+
+**User Story:** As a cloud architect, I want to apply multiple tag filters simultaneously, so that I can create highly specific diagrams for complex filtering scenarios.
+
+#### Acceptance Criteria
+
+1. WHEN a user specifies multiple tag filters, THE System SHALL support both AND and OR logical operations
+2. WHEN using AND logic (default), THE System SHALL include only resources matching ALL specified tag filters
+3. WHEN using OR logic, THE System SHALL include resources matching ANY of the specified tag filters
+4. WHEN combining include and exclude filters, THE System SHALL first apply include filters then remove resources matching exclude filters
+5. WHEN tag filter logic is specified, THE System SHALL validate the logical operators and provide clear error messages for invalid combinations
+
+### Requirement 3: Service-Specific Tag Filtering
+
+**User Story:** As a system administrator, I want to apply tag filters to specific AWS services, so that I can create focused diagrams for particular service types while including all resources from other services.
+
+#### Acceptance Criteria
+
+1. WHEN a user specifies service-specific tag filters, THE System SHALL apply filters only to the specified AWS services
+2. WHEN using the EC2 plugin with tag filters, THE System SHALL filter EC2 instances, VPCs, subnets, and security groups based on their respective tags
+3. WHEN using service-specific filters, THE System SHALL include all resources from non-filtered services in the diagram
+4. WHEN service-specific filters are combined with global filters, THE System SHALL apply both filter sets appropriately
+5. WHEN a service doesn't support tags, THE System SHALL ignore tag filters for that service and include all resources
+
+### Requirement 4: Account-Wide Tag Filtering
+
+**User Story:** As an enterprise architect, I want to apply tag filters across all AWS services in an account, so that I can create comprehensive diagrams filtered by organizational or project criteria.
+
+#### Acceptance Criteria
+
+1. WHEN a user specifies account-wide tag filters, THE System SHALL apply the same filter criteria to all supported AWS services
+2. WHEN using Organizations plugin with tag filters, THE System SHALL filter accounts based on account-level tags
+3. WHEN using Identity Center plugin with tag filters, THE System SHALL filter permission sets and assignments based on their tags where applicable
+4. WHEN account-wide filters are applied, THE System SHALL maintain service relationships even when some services have no matching resources
+5. WHEN combining account-wide and service-specific filters, THE System SHALL apply the most restrictive filter for each service
+
+### Requirement 5: CLI Tag Filter Interface
+
+**User Story:** As a user, I want intuitive CLI options for specifying tag filters, so that I can easily create filtered diagrams without complex syntax.
+
+#### Acceptance Criteria
+
+1. WHEN a user wants to specify tag filters, THE System SHALL provide clear CLI options for tag filtering
+2. WHEN using key-value filters, THE System SHALL accept format like `--tag Environment=Production`
+3. WHEN using key-only filters, THE System SHALL accept format like `--tag-key Environment`
+4. WHEN specifying multiple filters, THE System SHALL allow multiple `--tag` and `--tag-key` options
+5. WHEN specifying logical operations, THE System SHALL provide `--tag-logic` option with values `AND` or `OR`
+6. WHEN specifying exclude filters, THE System SHALL provide `--exclude-tag` and `--exclude-tag-key` options
+7. WHEN using service-specific filters, THE System SHALL provide `--service-tag` option with service name and tag criteria
+
+### Requirement 6: Tag Filter Validation and Error Handling
+
+**User Story:** As a user, I want clear feedback when my tag filters are invalid or produce no results, so that I can correct my filtering criteria.
+
+#### Acceptance Criteria
+
+1. WHEN tag filter syntax is invalid, THE System SHALL provide clear error messages with examples of correct syntax
+2. WHEN tag filters produce no matching resources, THE System SHALL display a warning message listing the applied filters
+3. WHEN tag filters are applied but some services don't support tags, THE System SHALL log informational messages about which services were not filtered
+4. WHEN conflicting filter options are specified, THE System SHALL validate the combination and provide guidance on resolution
+5. WHEN tag filters result in broken relationships, THE System SHALL warn about orphaned resources in the diagram
+
+### Requirement 7: Tag Filter Performance and Optimization
+
+**User Story:** As a user working with large AWS environments, I want tag filtering to be performant, so that I can generate filtered diagrams efficiently even with thousands of resources.
+
+#### Acceptance Criteria
+
+1. WHEN tag filters are specified, THE System SHALL apply filters during data collection to minimize API calls
+2. WHEN using pagination with tag filters, THE System SHALL leverage AWS API filtering capabilities where available
+3. WHEN tag filters are applied, THE System SHALL cache tag information to avoid redundant API calls
+4. WHEN processing large resource sets, THE System SHALL provide progress indicators for tag filtering operations
+5. WHEN tag filtering is complete, THE System SHALL report the number of resources filtered and included
+
+### Requirement 8: Tag Filter Configuration and Presets
+
+**User Story:** As a team lead, I want to save and reuse common tag filter configurations, so that my team can consistently generate diagrams with standardized filtering criteria.
+
+#### Acceptance Criteria
+
+1. WHEN a user wants to save tag filter configurations, THE System SHALL provide options to save filter presets
+2. WHEN using saved presets, THE System SHALL allow loading predefined tag filter combinations by name
+3. WHEN managing presets, THE System SHALL provide options to list, create, update, and delete saved configurations
+4. WHEN presets are used, THE System SHALL allow overriding specific filters while maintaining the preset base
+5. WHEN sharing presets, THE System SHALL store configurations in a format that can be version controlled and shared across teams
+
+### Requirement 9: Tag Filter Documentation and Examples
+
+**User Story:** As a new user, I want comprehensive documentation and examples for tag filtering, so that I can quickly learn how to create filtered diagrams for my use cases.
+
+#### Acceptance Criteria
+
+1. WHEN a user requests help for tag filtering, THE System SHALL provide comprehensive CLI help with examples
+2. WHEN documentation is accessed, THE System SHALL include common use case examples for different filtering scenarios
+3. WHEN examples are provided, THE System SHALL cover single service filtering, multi-service filtering, and account-wide filtering
+4. WHEN advanced features are documented, THE System SHALL explain logical operators, exclude filters, and preset management
+5. WHEN troubleshooting information is needed, THE System SHALL provide guidance for common filtering issues and solutions
+
+### Requirement 10: Integration with Existing Plugin Architecture
+
+**User Story:** As a developer, I want tag filtering to integrate seamlessly with the existing plugin architecture, so that all current and future plugins can benefit from filtering capabilities.
+
+#### Acceptance Criteria
+
+1. WHEN plugins collect data, THE System SHALL provide a standardized interface for applying tag filters
+2. WHEN new plugins are developed, THE System SHALL allow plugins to declare their tag filtering capabilities
+3. WHEN tag filters are applied, THE System SHALL ensure consistent behavior across all plugins
+4. WHEN plugins don't support tag filtering, THE System SHALL gracefully handle the limitation and inform users
+5. WHEN plugin-specific tag filtering is needed, THE System SHALL provide extension points for custom filtering logic

reverse_diagrams-1.3.5/.kiro/specs/tag-based-filtering/tasks.md

@@ -0,0 +1,191 @@
+# Implementation Plan: Tag-Based Filtering
+
+## Overview
+
+This implementation plan breaks down the tag-based filtering feature into discrete coding tasks that build incrementally. Each task focuses on specific functionality while ensuring integration with the existing plugin architecture.
+
+## Tasks
+
+- [ ] 1. Create core tag filtering data models and utilities
+  - Create `TagFilter`, `TagFilterSet`, and `FilterResult` data classes
+  - Implement tag matching logic for key-value and key-only filters
+  - Add validation methods for filter syntax and combinations
+  - _Requirements: 1.1, 1.2, 1.3, 2.5_
+
+- [ ] 1.1 Write property test for tag filter matching
+  - **Property 1: Tag Filter Matching**
+  - **Validates: Requirements 1.1, 1.2, 1.3**
+
+- [ ] 2. Implement Tag Filter Parser for CLI integration
+  - Create `TagFilterParser` class to parse CLI arguments
+  - Support `--tag`, `--tag-key`, `--exclude-tag`, `--exclude-tag-key` options
+  - Add `--tag-logic` option for AND/OR operations
+  - Add `--service-tag` option for service-specific filtering
+  - _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7_
+
+- [ ] 2.1 Write property test for CLI argument parsing
+  - **Property 7: CLI Argument Parsing**
+  - **Validates: Requirements 5.2, 5.3, 5.4, 5.5, 5.6, 5.7**
+
+- [ ] 3. Create Tag Filter Engine as central coordinator
+  - Implement `TagFilterEngine` class with core filtering logic
+  - Add methods for applying filters to resource collections
+  - Implement logical operations (AND/OR) for multiple filters
+  - Add include/exclude filter precedence handling
+  - _Requirements: 2.1, 2.2, 2.3, 2.4_
+
+- [ ] 3.1 Write property test for logical operations consistency
+  - **Property 2: Logical Operations Consistency**
+  - **Validates: Requirements 2.1, 2.2, 2.3**
+
+- [ ] 3.2 Write property test for include-exclude filter precedence
+  - **Property 3: Include-Exclude Filter Precedence**
+  - **Validates: Requirements 2.4**
+
+- [ ] 4. Extend plugin base class with tag filtering interface
+  - Add `supports_tag_filtering()` method to `AWSServicePlugin`
+  - Add `apply_tag_filters()` method for filter application
+  - Add `get_resource_tags()` method for tag extraction
+  - Add `filter_resources_by_tags()` method for resource filtering
+  - _Requirements: 10.1, 10.2_
+
+- [ ] 4.1 Write property test for plugin interface consistency
+  - **Property 10: Plugin Interface Consistency**
+  - **Validates: Requirements 10.1, 10.2, 10.3, 10.4, 10.5**
+
+- [ ] 5. Implement tag filtering in EC2 plugin
+  - Add tag filtering support to EC2Plugin class
+  - Filter EC2 instances, VPCs, subnets, and security groups by tags
+  - Implement service-specific filtering logic
+  - Preserve relationships between filtered EC2 resources
+  - _Requirements: 3.2, 3.4_
+
+- [ ] 5.1 Write property test for service isolation in filtering
+  - **Property 4: Service Isolation in Filtering**
+  - **Validates: Requirements 3.1, 3.3, 4.1**
+
+- [ ] 5.2 Write property test for relationship preservation
+  - **Property 5: Relationship Preservation**
+  - **Validates: Requirements 1.5, 4.4**
+
+- [ ] 6. Implement tag filtering in Organizations plugin
+  - Add tag filtering support to OrganizationsPlugin class
+  - Filter accounts based on account-level tags
+  - Handle organizational units with tag-based account filtering
+  - Maintain organization hierarchy after filtering
+  - _Requirements: 4.2_
+
+- [ ] 7. Implement tag filtering in Identity Center plugin
+  - Add tag filtering support to IdentityCenterPlugin class
+  - Filter permission sets and assignments based on tags where applicable
+  - Handle cases where Identity Center resources may not have tags
+  - _Requirements: 4.3_
+
+- [ ] 7.1 Write property test for graceful service degradation
+  - **Property 12: Graceful Service Degradation**
+  - **Validates: Requirements 3.5, 6.3**
+
+- [ ] 8. Create Preset Manager for saved configurations
+  - Implement `PresetManager` class for filter configuration management
+  - Add methods to save, load, list, and delete filter presets
+  - Store presets in JSON format for version control compatibility
+  - Support preset overrides while maintaining base configuration
+  - _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
+
+- [ ] 8.1 Write property test for preset operations
+  - **Property 9: Preset Operations**
+  - **Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.5**
+
+- [ ] 9. Integrate tag filtering with CLI interface
+  - Update `reverse_diagrams.py` to support tag filtering arguments
+  - Add argument parsing for all tag filter options
+  - Integrate TagFilterEngine with plugin execution
+  - Add validation and error handling for filter arguments
+  - _Requirements: 5.1, 6.1, 6.4_
+
+- [ ] 9.1 Write property test for filter validation
+  - **Property 6: Filter Validation**
+  - **Validates: Requirements 2.5, 6.1, 6.4**
+
+- [ ] 10. Implement performance optimizations
+  - Apply filters during data collection phase to minimize API calls
+  - Leverage AWS API filtering capabilities where available
+  - Add caching for tag information to avoid redundant calls
+  - Implement progress tracking for long-running filter operations
+  - _Requirements: 7.1, 7.2, 7.3, 7.4_
+
+- [ ] 10.1 Write property test for performance optimization
+  - **Property 8: Performance Optimization**
+  - **Validates: Requirements 7.1, 7.2, 7.3**
+
+- [ ] 11. Add comprehensive error handling and user feedback
+  - Implement validation for conflicting filter options
+  - Add warnings for empty filter results with applied filter details
+  - Add informational messages for services that don't support tags
+  - Add warnings for broken relationships in filtered diagrams
+  - _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
+
+- [ ] 11.1 Write property test for empty result handling
+  - **Property 11: Empty Result Handling**
+  - **Validates: Requirements 1.4, 6.2**
+
+- [ ] 12. Create comprehensive documentation and help
+  - Add CLI help text with examples for all tag filtering options
+  - Create documentation covering common use cases and scenarios
+  - Add troubleshooting guide for common filtering issues
+  - Include examples for single service, multi-service, and account-wide filtering
+  - _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5_
+
+- [ ] 13. Checkpoint - Ensure all tests pass
+  - Ensure all tests pass, ask the user if questions arise.
+
+- [ ] 14. Integration testing and final validation
+  - Test end-to-end filtering scenarios with multiple services
+  - Validate performance with large resource sets
+  - Test preset management functionality
+  - Verify backward compatibility with existing functionality
+  - _Requirements: All requirements validation_
+
+- [ ] 14.1 Write integration tests for multi-service filtering
+  - Test filtering across Organizations, EC2, and Identity Center plugins
+  - Verify consistent behavior and relationship preservation
+
+- [ ] 15. Final checkpoint - Ensure all tests pass
+  - Ensure all tests pass, ask the user if questions arise.
+
+## Notes
+
+- All tasks are required for comprehensive implementation from the start
+- Each task references specific requirements for traceability
+- Checkpoints ensure incremental validation
+- Property tests validate universal correctness properties with minimum 100 iterations
+- Unit tests validate specific examples and edge cases
+- Integration tests ensure end-to-end functionality
+- The implementation builds incrementally from core models to full integration
+
+## CLI Usage Examples
+
+After implementation, users will be able to use tag filtering like this:
+
+```bash
+# Filter EC2 resources by environment tag
+reverse_diagrams --plugin ec2 --tag Environment=Production -r us-east-1
+
+# Filter all services by multiple tags with AND logic
+reverse_diagrams -o -i --tag Environment=Production --tag Team=DevOps -r us-east-1
+
+# Filter with OR logic
+reverse_diagrams --plugin ec2 --tag Environment=Production --tag Environment=Staging --tag-logic OR -r us-east-1
+
+# Service-specific filtering
+reverse_diagrams -o -i --service-tag ec2 Environment=Production -r us-east-1
+
+# Exclude specific tags
+reverse_diagrams --plugin ec2 --tag Environment=Production --exclude-tag Status=Deprecated -r us-east-1
+
+# Use saved presets
+reverse_diagrams --preset production-env -r us-east-1
+
+# Key-only filtering
+reverse_diagrams --plugin ec2 --tag-key CostCenter -r us-east-1
+```