activity_notification 2.3.3 → 2.4.0

data/ai-curated-specs/issues/172/tasks.md

@@ -0,0 +1,326 @@
+# Implementation Plan
+
+## Problem 1: Mongoid ORM Compatibility Issue with ID Array Filtering
+
+### Issue Description
+The bulk destroy functionality works correctly with ActiveRecord ORM but fails with Mongoid ORM. Specifically, the test case `context 'with ids options'` in `spec/concerns/apis/notification_api_spec.rb` is failing.
+
+**Location**: `lib/activity_notification/apis/notification_api.rb` line 440
+**Problematic Code**: 
+```ruby
+target_notifications = target_notifications.where(id: options[:ids])
+```
+
+### Root Cause Analysis
+The issue stems from different query syntax requirements between ActiveRecord and Mongoid when filtering by an array of IDs:
+
+1. **ActiveRecord**: Uses `where(id: [1, 2, 3])` which automatically translates to SQL `WHERE id IN (1, 2, 3)`
+2. **Mongoid**: Requires explicit `$in` operator syntax for array matching: `where(id: { '$in' => [1, 2, 3] })`
+
+### Current Implementation Problem
+The current implementation uses ActiveRecord syntax:
+```ruby
+target_notifications = target_notifications.where(id: options[:ids])
+```
+
+This works for ActiveRecord but fails for Mongoid because Mongoid doesn't automatically interpret an array as an `$in` operation.
+
+### Expected Behavior
+- When `options[:ids]` contains `[notification1.id, notification2.id]`, only notifications with those specific IDs should be destroyed
+- The filtering should work consistently across both ActiveRecord and Mongoid ORMs
+- Other filter options should still be applied in combination with ID filtering
+
+### Test Case Analysis
+The failing test:
+```ruby
+it "destroys notifications with specified IDs only" do
+  notification_to_destroy = @user_1.notifications.first
+  described_class.destroy_all_of(@user_1, { ids: [notification_to_destroy.id] })
+  expect(@user_1.notifications.count).to eq(1)
+  expect(@user_1.notifications.first).not_to eq(notification_to_destroy)
+end
+```
+
+This test expects that when an array of IDs is provided, only those specific notifications are destroyed.
+
+### Solution Strategy
+Implement ORM-specific ID filtering logic that:
+
+1. **Detection**: Check the current ORM configuration using `ActivityNotification.config.orm`
+2. **ActiveRecord Path**: Use existing `where(id: options[:ids])` syntax
+3. **Mongoid Path**: Use `where(id: { '$in' => options[:ids] })` syntax
+4. **Dynamoid Path**: Use `where(‘id.in‘: options[:ids])` syntax
+
+### Implementation Plan
+1. **Conditional Logic**: Add ORM detection in the `destroy_all_of` method
+2. **Mongoid Syntax**: Use `{ '$in' => options[:ids] }` for Mongoid
+3. **Backward Compatibility**: Ensure ActiveRecord continues to work as before
+4. **Testing**: Verify both ORMs work correctly with the new implementation
+
+### Code Changes Required
+**File**: `lib/activity_notification/apis/notification_api.rb`
+**Method**: `destroy_all_of` (around line 440)
+
+Replace:
+```ruby
+if options[:ids].present?
+  target_notifications = target_notifications.where(id: options[:ids])
+end
+```
+
+With ORM-specific logic:
+```ruby
+if options[:ids].present?
+  case ActivityNotification.config.orm
+  when :mongoid
+    target_notifications = target_notifications.where(id: { '$in' => options[:ids] })
+  when :dynamoid
+    target_notifications = target_notifications.where('id.in': options[:ids])
+  else # :active_record
+    target_notifications = target_notifications.where(id: options[:ids])
+  end
+end
+```
+
+### Testing Requirements
+1. **Unit Tests**: Ensure the method works with both ActiveRecord and Mongoid
+2. **Integration Tests**: Verify the complete destroy_all functionality
+3. **Regression Tests**: Ensure existing functionality remains intact
+
+### Risk Assessment
+- **Low Risk**: The change is isolated to the ID filtering logic
+- **Backward Compatible**: ActiveRecord behavior remains unchanged
+- **Well-Tested**: Existing test suite will catch any regressions
+
+### Future Considerations
+- Consider extracting ORM-specific query logic into a helper method if more similar cases arise
+- Document the ORM differences for future developers
+- Consider adding similar logic to other methods that might have the same issue
+
+---
+
+## Problem 2: Add IDs Parameter to open_all API
+
+### Issue Description
+Enhance the `open_all_of` method to support the `ids` parameter functionality, similar to the implementation in `destroy_all_of`. This will allow users to open specific notifications by providing an array of notification IDs.
+
+### Current State Analysis
+
+#### Existing open_all_of Method
+**Location**: `lib/activity_notification/apis/notification_api.rb` (around line 415)
+
+**Current Implementation**:
+```ruby
+def open_all_of(target, options = {})
+  opened_at = options[:opened_at] || Time.current
+  target_unopened_notifications = target.notifications.unopened_only.filtered_by_options(options)
+  opened_notifications = target_unopened_notifications.to_a.map { |n| n.opened_at = opened_at; n }
+  target_unopened_notifications.update_all(opened_at: opened_at)
+  opened_notifications
+end
+```
+
+**Current Parameters**:
+- `opened_at`: Time to set to opened_at of the notification record
+- `filtered_by_type`: Notifiable type for filter
+- `filtered_by_group`: Group instance for filter
+- `filtered_by_group_type`: Group type for filter, valid with :filtered_by_group_id
+- `filtered_by_group_id`: Group instance id for filter, valid with :filtered_by_group_type
+- `filtered_by_key`: Key of the notification for filter
+- `later_than`: ISO 8601 format time to filter notification index later than specified time
+- `earlier_than`: ISO 8601 format time to filter notification index earlier than specified time
+
+### Proposed Enhancement
+
+#### Add IDs Parameter Support
+Add support for the `ids` parameter to allow opening specific notifications by their IDs, following the same pattern as `destroy_all_of`.
+
+#### Updated Method Signature
+```ruby
+# @option options [Array] :ids (nil) Array of specific notification IDs to open
+def open_all_of(target, options = {})
+```
+
+### Implementation Strategy
+1. **Reuse existing pattern**: Follow the same ORM-specific ID filtering logic implemented in `destroy_all_of`
+2. **Maintain backward compatibility**: Ensure existing functionality remains unchanged
+3. **Consistent behavior**: Apply ID filtering after other filters, similar to destroy_all_of
+
+### Code Changes Required
+
+#### 1. Update Method Documentation
+**File**: `lib/activity_notification/apis/notification_api.rb`
+
+Add the `ids` parameter to the method documentation:
+```ruby
+# @option options [Array] :ids (nil) Array of specific notification IDs to open
+```
+
+#### 2. Add ID Filtering Logic
+Insert the same ORM-specific ID filtering logic used in `destroy_all_of`:
+
+```ruby
+def open_all_of(target, options = {})
+  opened_at = options[:opened_at] || Time.current
+  target_unopened_notifications = target.notifications.unopened_only.filtered_by_options(options)
+  
+  # Add ID filtering logic (same as destroy_all_of)
+  if options[:ids].present?
+    # :nocov:
+    case ActivityNotification.config.orm
+    when :mongoid
+      target_unopened_notifications = target_unopened_notifications.where(id: { '$in' => options[:ids] })
+    when :dynamoid
+      target_unopened_notifications = target_unopened_notifications.where('id.in': options[:ids])
+    else # :active_record
+      target_unopened_notifications = target_unopened_notifications.where(id: options[:ids])
+    end
+    # :nocov:
+  end
+  
+  opened_notifications = target_unopened_notifications.to_a.map { |n| n.opened_at = opened_at; n }
+  target_unopened_notifications.update_all(opened_at: opened_at)
+  opened_notifications
+end
+```
+
+#### 3. Update Controller Actions
+The controller actions that use `open_all_of` should be updated to accept and pass through the `ids` parameter:
+
+**Files to Update**:
+- `app/controllers/activity_notification/notifications_controller.rb`
+- `app/controllers/activity_notification/notifications_api_controller.rb`
+
+**Parameter Addition**:
+```ruby
+# Add :ids to permitted parameters
+params.permit(:ids => [])
+```
+
+#### 4. Update API Documentation
+**File**: `lib/activity_notification/controllers/concerns/swagger/notifications_api.rb`
+
+Add `ids` parameter to the Swagger documentation for the open_all endpoint:
+```ruby
+parameter do
+  key :name, :ids
+  key :in, :query
+  key :description, 'Array of specific notification IDs to open'
+  key :required, false
+  key :type, :array
+  items do
+    key :type, :string
+  end
+end
+```
+
+### Testing Requirements
+
+#### 1. Add Test Cases
+**File**: `spec/concerns/apis/notification_api_spec.rb`
+
+Add test cases similar to the `destroy_all_of` tests:
+
+```ruby
+context 'with ids options' do
+  it "opens notifications with specified IDs only" do
+    notification_to_open = @user_1.notifications.first
+    described_class.open_all_of(@user_1, { ids: [notification_to_open.id] })
+    expect(@user_1.notifications.unopened_only.count).to eq(1)
+    expect(@user_1.notifications.opened_only!.count).to eq(1)
+    expect(@user_1.notifications.opened_only!.first).to eq(notification_to_open)
+  end
+
+  it "applies other filter options when ids are specified" do
+    notification_to_open = @user_1.notifications.first
+    described_class.open_all_of(@user_1, { 
+      ids: [notification_to_open.id], 
+      filtered_by_key: 'non_existent_key' 
+    })
+    expect(@user_1.notifications.unopened_only.count).to eq(2)
+    expect(@user_1.notifications.opened_only!.count).to eq(0)
+  end
+
+  it "only opens unopened notifications even when opened notification IDs are provided" do
+    # First open one notification
+    notification_to_open = @user_1.notifications.first
+    notification_to_open.open!
+    
+    # Try to open it again using ids parameter
+    described_class.open_all_of(@user_1, { ids: [notification_to_open.id] })
+    
+    # Should not affect the count since it was already opened
+    expect(@user_1.notifications.unopened_only.count).to eq(1)
+    expect(@user_1.notifications.opened_only!.count).to eq(1)
+  end
+end
+```
+
+#### 2. Update Controller Tests
+**File**: `spec/controllers/notifications_api_controller_shared_examples.rb`
+
+Add test cases for the API controller to ensure the `ids` parameter is properly handled:
+
+```ruby
+context 'with ids parameter' do
+  it "opens only specified notifications" do
+    notification_to_open = @user.notifications.first
+    post open_all_notification_path(@user), params: { ids: [notification_to_open.id] }
+    expect(response).to have_http_status(200)
+    expect(@user.notifications.unopened_only.count).to eq(1)
+    expect(@user.notifications.opened_only!.count).to eq(1)
+  end
+end
+```
+
+### Benefits
+
+#### 1. Consistency
+- Provides consistent API between `open_all_of` and `destroy_all_of` methods
+- Both methods now support the same filtering options including `ids`
+
+#### 2. Flexibility
+- Allows precise control over which notifications to open
+- Enables batch operations on specific notifications
+- Supports complex filtering combinations
+
+#### 3. Performance
+- Efficient database operations using bulk updates
+- Reduces the need for multiple individual open operations
+
+#### 4. User Experience
+- Provides the functionality requested in the original issue
+- Enables building more sophisticated notification management UIs
+
+### Implementation Considerations
+
+#### 1. Backward Compatibility
+- All existing functionality remains unchanged
+- New `ids` parameter is optional
+- Existing tests should continue to pass
+
+#### 2. ORM Compatibility
+- Uses the same ORM-specific logic as `destroy_all_of`
+- Tested across ActiveRecord, Mongoid, and Dynamoid
+
+#### 3. Security
+- ID filtering is applied after target validation
+- Only notifications belonging to the specified target can be opened
+- Follows existing security patterns
+
+#### 4. Error Handling
+- Invalid IDs are silently ignored (consistent with existing behavior)
+- Non-existent notifications don't cause errors
+- Maintains existing error handling patterns
+
+### Risk Assessment
+- **Low Risk**: Follows established patterns from `destroy_all_of`
+- **Backward Compatible**: ActiveRecord behavior remains unchanged
+- **Well-Tested**: Existing test suite will catch any regressions
+
+### Implementation Timeline
+1. **Phase 1**: Update `open_all_of` method with ID filtering logic
+2. **Phase 2**: Add comprehensive test cases
+3. **Phase 3**: Update controller actions and API documentation
+4. **Phase 4**: Update controller tests and integration tests
+5. **Phase 5**: Documentation updates and final testing

data/ai-curated-specs/issues/188/design.md

@@ -0,0 +1,227 @@
+# Design Document
+
+## Overview
+
+This design outlines the approach for upgrading activity_notification's Dynamoid dependency from v3.1.0 to v3.11.0. The upgrade involves updating namespace references, method signatures, and class hierarchies that have changed between these versions, while maintaining backward compatibility and preparing useful enhancements for upstream contribution to Dynamoid.
+
+## Architecture
+
+### Current Architecture
+- **Dynamoid Extension**: `lib/activity_notification/orm/dynamoid/extension.rb` contains monkey patches extending Dynamoid v3.1.0
+- **ORM Integration**: `lib/activity_notification/orm/dynamoid.rb` provides ActivityNotification-specific query methods
+- **Dependency Management**: Gemspec pins Dynamoid to exactly v3.1.0
+
+### Target Architecture
+- **Updated Extension**: Refactored extension file compatible with Dynamoid v3.11.0 namespaces
+- **Backward Compatibility**: Maintained API surface for existing applications
+- **Upstream Preparation**: Clean, well-documented code ready for Dynamoid contribution
+- **Flexible Dependency**: Version range allowing v3.11.0+ while preventing breaking v4.0 changes
+
+## Components and Interfaces
+
+### 1. Gemspec Update
+**File**: `activity_notification.gemspec`
+**Changes**:
+- Update Dynamoid dependency from development dependency `'3.1.0'` to runtime dependency `'>= 3.11.0', '< 4.0'`
+- Change dependency type from `add_development_dependency` to `add_dependency` for production use
+- Ensure compatibility with Rails version constraints
+
+### 2. Extension Module Refactoring
+**File**: `lib/activity_notification/orm/dynamoid/extension.rb`
+
+#### 2.1 Critical Namespace Changes
+Based on analysis of Dynamoid v3.1.0 vs v3.11.0:
+
+**Query and Scan Class Locations**:
+- **v3.1.0**: `Dynamoid::AdapterPlugin::Query` and `Dynamoid::AdapterPlugin::Scan`
+- **v3.11.0**: `Dynamoid::AdapterPlugin::AwsSdkV3::Query` and `Dynamoid::AdapterPlugin::AwsSdkV3::Scan`
+
+**Method Signature Changes**:
+- **v3.1.0**: `Query.new(client, table, opts = {})`
+- **v3.11.0**: `Query.new(client, table, key_conditions, non_key_conditions, options)`
+
+#### 2.2 Removed Constants and Methods
+**Constants removed in v3.11.0**:
+- `FIELD_MAP` - Used for condition mapping
+- `RANGE_MAP` - Used for range condition mapping
+- `attribute_value_list()` method - No longer exists
+
+**New Architecture in v3.11.0**:
+- Uses `FilterExpressionConvertor` for building filter expressions
+- Uses expression attribute names and values instead of legacy condition format
+- Middleware pattern for handling backoff, limits, and pagination
+
+#### 2.3 Class Hierarchy Updates Required
+- Update inheritance from `::Dynamoid::AdapterPlugin::Query` to `::Dynamoid::AdapterPlugin::AwsSdkV3::Query`
+- Update inheritance from `::Dynamoid::AdapterPlugin::Scan` to `::Dynamoid::AdapterPlugin::AwsSdkV3::Scan`
+- Remove references to `FIELD_MAP`, `RANGE_MAP`, and `attribute_value_list()`
+- Adapt to new filter expression format
+
+### 3. Core Functionality Preservation
+**Methods to Maintain**:
+- `none()` - Returns empty result set
+- `limit()` - Aliases to `record_limit()`
+- `exists?()` - Checks if records exist
+- `update_all()` - Batch update operations
+- `serializable_hash()` - Array serialization
+- Null/not_null operators for query filtering
+- Uniqueness validation support
+
+### 4. Upstream Contribution Preparation
+**Target Methods for Contribution**:
+- `Chain#none` - Useful empty result pattern
+- `Chain#limit` - More intuitive alias for `record_limit`
+- `Chain#exists?` - Common query pattern
+- `Chain#update_all` - Batch operations
+- Null operator extensions - Enhanced query capabilities
+- Uniqueness validator - Common validation need
+
+## Data Models
+
+### Extension Points
+```ruby
+# Current structure (v3.1.0)
+module Dynamoid
+  module Criteria
+    class Chain
+      # Extension methods work with @query hash
+    end
+  end
+  
+  module AdapterPlugin
+    class AwsSdkV3
+      class Query < ::Dynamoid::AdapterPlugin::Query
+        # Uses FIELD_MAP, RANGE_MAP, attribute_value_list
+        def query_filter
+          # Legacy condition format
+        end
+      end
+    end
+  end
+end
+
+# Target structure (v3.11.0) - CONFIRMED
+module Dynamoid
+  module Criteria
+    class Chain
+      # Extension methods work with @where_conditions object
+      # Uses KeyFieldsDetector and WhereConditions classes
+    end
+  end
+  
+  module AdapterPlugin
+    class AwsSdkV3
+      class Query < ::Dynamoid::AdapterPlugin::AwsSdkV3::Query  # CHANGED NAMESPACE
+        # Uses FilterExpressionConvertor instead of FIELD_MAP
+        # No more query_filter method - uses filter_expression
+        def initialize(client, table, key_conditions, non_key_conditions, options)
+          # CHANGED SIGNATURE
+        end
+      end
+    end
+  end
+end
+```
+
+### Critical Breaking Changes
+1. **Query/Scan inheritance path changed**: `::Dynamoid::AdapterPlugin::Query` → `::Dynamoid::AdapterPlugin::AwsSdkV3::Query`
+2. **Constructor signature changed**: Single options hash → separate key/non-key conditions + options
+3. **Filter building changed**: `FIELD_MAP`/`RANGE_MAP` → `FilterExpressionConvertor`
+4. **Method removal**: `attribute_value_list()`, `query_filter()`, `scan_filter()` methods removed
+
+### Configuration Changes
+- No breaking changes to ActivityNotification configuration
+- Maintain existing API for `acts_as_notification_target`, `acts_as_notifiable`, etc.
+- Preserve all existing query method signatures
+
+## Error Handling
+
+### Migration Strategy
+1. **Gradual Rollout**: Support version range to allow gradual adoption
+2. **Fallback Mechanisms**: Detect Dynamoid version and use appropriate code paths if needed
+3. **Clear Error Messages**: Provide helpful errors if incompatible versions are used
+
+### Exception Handling
+- **NameError**: Handle missing classes/modules gracefully
+- **NoMethodError**: Provide fallbacks for changed method signatures
+- **ArgumentError**: Handle parameter changes in Dynamoid methods
+
+### Validation
+- Runtime checks for critical Dynamoid functionality
+- Test coverage for all supported Dynamoid versions
+- Integration tests with real DynamoDB operations
+
+## Testing Strategy
+
+### Unit Tests
+- Test all extension methods with Dynamoid v3.11.0
+- Verify namespace resolution works correctly
+- Test error handling for edge cases
+
+### Integration Tests
+- Full ActivityNotification workflow with DynamoDB
+- Performance regression testing
+- Memory usage validation
+
+### Compatibility Tests
+- Test with multiple Dynamoid versions in range
+- Verify no breaking changes for existing applications
+- Test upgrade path from v3.1.0 to v3.11.0
+
+### Upstream Preparation Tests
+- Isolated tests for each method proposed for contribution
+- Documentation examples that work standalone
+- Performance benchmarks for contributed methods
+
+## Implementation Phases
+
+### Phase 1: Research and Analysis ✅ COMPLETED
+- ✅ Compare Dynamoid v3.1.0 vs v3.11.0 source code
+- ✅ Identify all namespace and method signature changes
+- ✅ Create compatibility matrix
+
+**Key Findings**:
+- Query/Scan classes moved from `AdapterPlugin::` to `AdapterPlugin::AwsSdkV3::`
+- Constructor signatures completely changed
+- FIELD_MAP/RANGE_MAP constants removed
+- Filter building now uses FilterExpressionConvertor
+- Legacy query_filter/scan_filter methods removed
+
+### Phase 2: Core Updates
+- Update gemspec dependency
+- Refactor extension.rb for new namespaces
+- Maintain existing functionality
+
+### Phase 3: Testing and Validation
+- Update test suite for new Dynamoid version
+- Run comprehensive integration tests using `AN_ORM=dynamoid bundle exec rspec`
+- Fix failing tests to ensure all Dynamoid-related functionality works
+- Performance validation
+- Verify all existing test scenarios pass with new Dynamoid version
+
+### Phase 4: Upstream Preparation
+- Extract reusable methods into separate modules
+- Create documentation and examples
+- Prepare pull requests for Dynamoid project
+
+### Phase 5: Documentation and Release
+- Update CHANGELOG with breaking changes
+- Update README with version requirements
+- Release new version with proper semantic versioning
+
+## Risk Mitigation
+
+### Breaking Changes
+- Use version range to prevent automatic v4.0 adoption
+- Provide clear upgrade documentation
+- Maintain backward compatibility where possible
+
+### Performance Impact
+- Benchmark critical query operations
+- Monitor memory usage changes
+- Test with large datasets
+
+### Upstream Contribution Risks
+- Prepare contributions as optional enhancements
+- Ensure activity_notification works without upstream acceptance
+- Maintain local implementations as fallbacks

data/ai-curated-specs/issues/188/requirements.md

@@ -0,0 +1,78 @@
+# Requirements Document
+
+## Introduction
+
+This feature involves upgrading the activity_notification gem's Dynamoid dependency from the outdated v3.1.0 to the latest v3.11.0. The upgrade requires updating namespace references and method calls that have changed between these versions, while maintaining backward compatibility and ensuring all existing functionality continues to work correctly.
+
+## Requirements
+
+### Requirement 1
+
+**User Story:** As a developer using activity_notification with DynamoDB, I want the gem to support the latest Dynamoid version so that I can benefit from bug fixes, performance improvements, and security updates.
+
+#### Acceptance Criteria
+
+1. WHEN the gemspec is updated THEN the Dynamoid dependency SHALL be changed from development dependency '3.1.0' to runtime dependency '>= 3.11.0', '< 4.0'
+2. WHEN the gem is installed THEN it SHALL successfully resolve dependencies with Dynamoid v3.11.0
+3. WHEN existing applications upgrade THEN they SHALL continue to work without breaking changes
+
+### Requirement 2
+
+**User Story:** As a maintainer of activity_notification, I want to update the Dynamoid extension code to use the correct namespaces and method signatures so that the gem works with the latest Dynamoid version.
+
+#### Acceptance Criteria
+
+1. WHEN the extension file is updated THEN all namespace references SHALL match Dynamoid v3.11.0 structure
+2. WHEN Dynamoid classes are referenced THEN they SHALL use the correct module paths from v3.11.0
+3. WHEN adapter plugin classes are extended THEN they SHALL use the updated class hierarchy from v3.11.0
+4. WHEN the code is executed THEN it SHALL not raise any NameError or NoMethodError exceptions
+
+### Requirement 3
+
+**User Story:** As a developer using activity_notification with DynamoDB, I want all existing functionality to continue working after the Dynamoid upgrade so that my application remains stable.
+
+#### Acceptance Criteria
+
+1. WHEN the none() method is called THEN it SHALL return an empty result set as before
+2. WHEN the limit() method is called THEN it SHALL properly limit query results
+3. WHEN the exists?() method is called THEN it SHALL correctly determine if records exist
+4. WHEN the update_all() method is called THEN it SHALL update all matching records
+5. WHEN null and not_null operators are used THEN they SHALL filter records correctly
+6. WHEN uniqueness validation is performed THEN it SHALL prevent duplicate records
+
+### Requirement 4
+
+**User Story:** As a developer running tests for activity_notification, I want all existing tests to pass with the new Dynamoid version so that I can be confident the upgrade doesn't break functionality.
+
+#### Acceptance Criteria
+
+1. WHEN the test suite is run THEN all Dynamoid-related tests SHALL pass
+2. WHEN integration tests are executed THEN they SHALL work with the new Dynamoid version
+3. WHEN edge cases are tested THEN they SHALL behave consistently with the previous version
+4. WHEN performance tests are run THEN they SHALL show no significant regression
+
+### Requirement 5
+
+**User Story:** As a maintainer of activity_notification, I want to contribute useful enhancements back to the Dynamoid upstream project so that the broader community can benefit from the improvements we've developed.
+
+#### Acceptance Criteria
+
+1. WHEN extension methods are identified as generally useful THEN they SHALL be prepared for upstream contribution
+2. WHEN the none() method implementation is stable THEN it SHALL be proposed as a pull request to Dynamoid
+3. WHEN the limit() method enhancement is validated THEN it SHALL be contributed to Dynamoid upstream
+4. WHEN the exists?() method is proven useful THEN it SHALL be submitted to Dynamoid for inclusion
+5. WHEN the update_all() method is optimized THEN it SHALL be offered as a contribution to Dynamoid
+6. WHEN null/not_null operators are refined THEN they SHALL be proposed for Dynamoid core
+7. WHEN uniqueness validator improvements are made THEN they SHALL be contributed upstream
+
+### Requirement 6
+
+**User Story:** As a developer upgrading activity_notification, I want clear documentation about the Dynamoid version change so that I can understand any potential impacts on my application.
+
+#### Acceptance Criteria
+
+1. WHEN the CHANGELOG is updated THEN it SHALL document the Dynamoid version upgrade
+2. WHEN breaking changes exist THEN they SHALL be clearly documented with migration instructions
+3. WHEN new features are available THEN they SHALL be documented with usage examples
+4. WHEN version compatibility is checked THEN the supported Dynamoid versions SHALL be clearly stated
+5. WHEN upstream contributions are made THEN they SHALL be documented with links to pull requests