📝 docs: mark monitoring and logging scenarios as @nice_to_have

features/BDD_TAGS.md

@@ -18,6 +18,7 @@ Used to categorize tests by importance:
 - `@critical` - Critical path tests that must always pass
 - `@basic` - Basic functionality tests
 - `@advanced` - Advanced or edge case scenarios
+- `@nice_to_have` - Optional features that would be nice to have but aren't critical
 
 ### Component Tags
 Used to categorize tests by system component:
@@ -32,6 +33,24 @@ Used to exclude tests from execution:
 - `@todo` - Tests with pending step implementations
 - `@skip` - Tests that should be skipped entirely
 
+### Nice-to-Have Tag
+
+The `@nice_to_have` tag is used to mark scenarios that test optional features or enhancements. These are features that would be beneficial to have but aren't critical for the core functionality of the system.
+
+**Usage:**
+- Add `@nice_to_have` to scenarios testing optional features
+- These scenarios are typically excluded from critical path testing
+- Useful for marking "stretch goal" functionality
+
+**Example:**
+```gherkin
+@nice_to_have @greet
+Scenario: Greeting with custom formatting options
+  Given the server is running
+  When I request a greeting with bold formatting
+  Then the response should contain HTML bold tags
+```
+
 ### Work In Progress Tag
 Used to override exclusions for active development:
 - `@wip` - Work In Progress - overrides exclusion tags to allow focused development
@@ -206,6 +225,7 @@ Feature: Health Endpoint
 | `@critical` | Critical path | `@critical` on essential scenarios |
 | `@basic` | Basic functionality | `@basic` on standard scenarios |
 | `@advanced` | Advanced scenarios | `@advanced` on edge cases |
+| `@nice_to_have` | Optional features | `@nice_to_have` on stretch goal scenarios |
 | `@auth` | Authentication | `@auth` on auth features |
 | `@config` | Configuration | `@config` on config scenarios |
 | `@api` | API endpoints | `@api` on endpoint tests |

features/jwt/jwt_secret_retention.feature

@@ -89,7 +89,7 @@ Feature: JWT Secret Retention Policy
     Then I should receive configuration validation error
     And the error should mention "retention_factor must be ≥ 1.0"
 
-  @todo
+  @todo @nice_to_have
   Scenario: Metrics for secret retention
     Given I have enabled Prometheus metrics
     When the cleanup job removes expired secrets
@@ -97,7 +97,7 @@ Feature: JWT Secret Retention Policy
     And I should see "jwt_secrets_active_count" metric decrease
     And I should see "jwt_secret_retention_duration_seconds" histogram update
 
-  @todo
+  @todo @nice_to_have
   Scenario: Log masking for security
     Given I add a new JWT secret "super-secret-key-123456"
     When the cleanup job runs
@@ -151,7 +151,7 @@ Feature: JWT Secret Retention Policy
     And existing secrets should be reevaluated
     And cleanup should use new retention periods
 
-  @todo
+  @todo @nice_to_have
   Scenario: Audit trail for secret operations
     Given I enable audit logging
     When I add a new JWT secret
@@ -176,7 +176,7 @@ Feature: JWT Secret Retention Policy
     And new tokens should use the emergency secret
     And cleanup should remove compromised secrets
   
-  @todo
+  @todo @nice_to_have
   Scenario: Monitoring and alerting
     Given I have monitoring configured
     When the cleanup job fails repeatedly