omgkit 2.13.0 → 2.15.0

package/plugin/workflows/event-driven/replay-testing.md

@@ -0,0 +1,186 @@
+---
+description: Test event-driven systems by replaying production events
+triggers:
+  - manual
+  - test:replay
+agents:
+  - tester
+  - data-engineer
+---
+
+# Replay Testing Workflow
+
+Test system behavior by replaying historical events.
+
+## Prerequisites
+- [ ] Event store with historical data
+- [ ] Isolated test environment
+- [ ] Anonymization requirements defined
+
+## Phase 1: Event Preparation
+
+### Step 1.1: Select Events for Replay
+```yaml
+agent: data-engineer
+action: query
+criteria:
+  - Time range
+  - Event types
+  - Specific scenarios
+  - Edge cases
+sources:
+  - Event store
+  - Kafka topics (with retention)
+  - Dead letter queues
+```
+
+### Step 1.2: Anonymize Events
+```yaml
+agent: data-engineer
+action: transform
+anonymization:
+  - PII fields: hash or fake
+  - Financial data: obfuscate
+  - IDs: maintain referential integrity
+  - Timestamps: optional offset
+```
+
+### Step 1.3: Create Event Dataset
+```yaml
+agent: data-engineer
+action: export
+format:
+  - JSON Lines
+  - Avro files
+  - Parquet
+outputs:
+  - event_dataset
+  - metadata (counts, types, time range)
+```
+
+## Phase 2: Environment Setup
+
+### Step 2.1: Provision Test Environment
+```yaml
+agent: tester
+action: setup
+components:
+  - Service under test
+  - Dependencies (mocked or real)
+  - Database (clean state)
+  - Message broker
+isolation:
+  - Network isolation
+  - No production access
+  - Clean state between runs
+```
+
+### Step 2.2: Configure Replay Infrastructure
+```yaml
+agent: tester
+action: configure
+replay_tools:
+  - Kafka replay consumer
+  - Custom replay script
+  - Event sourcing replay
+settings:
+  - Replay speed (1x, 10x, max)
+  - Ordering guarantees
+  - Pause/resume capability
+```
+
+## Phase 3: Replay Execution
+
+### Step 3.1: Baseline Replay
+```yaml
+agent: tester
+action: replay
+mode: baseline
+purpose: Establish expected behavior
+capture:
+  - Final state
+  - Processing metrics
+  - Error counts
+```
+
+### Step 3.2: Modified Replay
+```yaml
+agent: tester
+action: replay
+mode: comparison
+with_changes:
+  - New code version
+  - Modified configuration
+  - Different event order
+capture:
+  - State differences
+  - Performance differences
+  - New errors
+```
+
+## Phase 4: Analysis
+
+### Step 4.1: State Comparison
+```yaml
+agent: tester
+action: compare
+aspects:
+  - Database state diff
+  - Emitted events diff
+  - Side effects diff
+  - Error handling diff
+tools:
+  - Database diff tools
+  - Event comparison scripts
+  - State snapshot comparison
+```
+
+### Step 4.2: Performance Analysis
+```yaml
+agent: tester
+action: analyze
+metrics:
+  - Processing throughput
+  - Latency distribution
+  - Resource usage
+  - Error rates
+```
+
+### Step 4.3: Issue Identification
+```yaml
+agent: tester
+action: identify
+issues:
+  - State inconsistencies
+  - Missing events
+  - Processing errors
+  - Performance regressions
+```
+
+## Phase 5: Reporting
+
+### Step 5.1: Generate Report
+```yaml
+agent: tester
+action: report
+contents:
+  - Replay summary
+  - State comparison results
+  - Performance metrics
+  - Identified issues
+  - Recommendations
+```
+
+## Outputs
+- [ ] Anonymized event dataset
+- [ ] Replay configuration
+- [ ] Baseline results
+- [ ] Comparison report
+- [ ] Issue list
+
+## Quality Gates
+- Events properly anonymized
+- Replay environment isolated
+- Baseline established
+- Differences explained
+- No data leakage

package/plugin/workflows/event-driven/saga-implementation.md

@@ -0,0 +1,206 @@
+---
+description: Implement distributed transactions using saga pattern
+triggers:
+  - manual
+  - transaction:distributed
+agents:
+  - architect
+  - fullstack-developer
+  - tester
+---
+
+# Saga Implementation Workflow
+
+Implement distributed transactions with compensation.
+
+## Prerequisites
+- [ ] Business process requiring multi-service transaction
+- [ ] Services identified for participation
+- [ ] Failure scenarios documented
+
+## Phase 1: Saga Design
+
+### Step 1.1: Choose Saga Type
+```yaml
+agent: architect
+action: design
+types:
+  choreography:
+    pros:
+      - Simple, loosely coupled
+      - No central coordinator
+    cons:
+      - Hard to track flow
+      - Difficult to debug
+    use_when: Simple, few participants
+  orchestration:
+    pros:
+      - Clear flow visibility
+      - Easier debugging
+      - Centralized logic
+    cons:
+      - Single point of failure
+      - More complexity
+    use_when: Complex, many participants
+```
+
+### Step 1.2: Define Saga Steps
+```yaml
+agent: architect
+action: define
+steps:
+  - name: step_name
+    service: service_name
+    action: forward_action
+    compensation: rollback_action
+    timeout: duration
+    retries: count
+example:
+  - name: ReserveInventory
+    service: inventory
+    action: reserve
+    compensation: releaseReservation
+  - name: ProcessPayment
+    service: payment
+    action: charge
+    compensation: refund
+  - name: ConfirmOrder
+    service: order
+    action: confirm
+    compensation: cancel
+```
+
+## Phase 2: Implementation - Choreography
+
+### Step 2.1: Define Events
+```yaml
+agent: fullstack-developer
+action: define
+events:
+  - forward_events:
+      - InventoryReserved
+      - PaymentProcessed
+      - OrderConfirmed
+  - compensation_events:
+      - InventoryReleased
+      - PaymentRefunded
+      - OrderCancelled
+  - failure_events:
+      - InventoryReservationFailed
+      - PaymentFailed
+```
+
+### Step 2.2: Implement Event Handlers
+```yaml
+agent: fullstack-developer
+action: implement
+per_service:
+  - Listen for trigger event
+  - Execute local transaction
+  - Publish result event
+  - Handle compensation trigger
+```
+
+## Phase 3: Implementation - Orchestration
+
+### Step 3.1: Create Orchestrator
+```yaml
+agent: fullstack-developer
+action: implement
+components:
+  - Saga definition (steps, compensations)
+  - State machine
+  - Step executor
+  - Compensation executor
+patterns:
+  - Process Manager
+  - State machine
+```
+
+### Step 3.2: Implement Saga State
+```yaml
+agent: fullstack-developer
+action: implement
+state_management:
+  - Saga instance ID
+  - Current step
+  - Completed steps
+  - Compensation state
+  - Payload data
+persistence:
+  - Database
+  - Event store
+```
+
+## Phase 4: Error Handling
+
+### Step 4.1: Implement Retries
+```yaml
+agent: fullstack-developer
+action: implement
+retry_strategy:
+  - Exponential backoff
+  - Max retries
+  - Idempotency keys
+  - Dead letter handling
+```
+
+### Step 4.2: Implement Timeouts
+```yaml
+agent: fullstack-developer
+action: implement
+timeout_handling:
+  - Per-step timeouts
+  - Overall saga timeout
+  - Timeout triggers compensation
+```
+
+### Step 4.3: Implement Compensation
+```yaml
+agent: fullstack-developer
+action: implement
+compensation_rules:
+  - Execute in reverse order
+  - Handle partial failures
+  - Idempotent compensations
+  - Report final status
+```
+
+## Phase 5: Testing
+
+### Step 5.1: Unit Test Steps
+```yaml
+agent: tester
+action: test
+coverage:
+  - Forward action success
+  - Forward action failure
+  - Compensation action
+  - Idempotency
+```
+
+### Step 5.2: Integration Test Saga
+```yaml
+agent: tester
+action: test
+scenarios:
+  - Happy path completion
+  - Failure at each step
+  - Timeout handling
+  - Concurrent sagas
+  - Recovery after crash
+```
+
+## Outputs
+- [ ] Saga definition
+- [ ] Orchestrator/event handlers
+- [ ] Compensation logic
+- [ ] State persistence
+- [ ] Test suite
+
+## Quality Gates
+- All steps have compensations
+- Idempotency verified
+- Timeout handling tested
+- State recovery works
+- Concurrent execution safe

package/plugin/workflows/event-driven/schema-evolution.md

@@ -0,0 +1,173 @@
+---
+description: Safely evolve event schemas with backward/forward compatibility
+triggers:
+  - manual
+  - schema:change
+agents:
+  - architect
+  - fullstack-developer
+  - tester
+---
+
+# Schema Evolution Workflow
+
+Evolve event schemas without breaking consumers.
+
+## Prerequisites
+- [ ] Schema registry in place
+- [ ] Current schema version documented
+- [ ] Consumer inventory identified
+
+## Phase 1: Change Analysis
+
+### Step 1.1: Classify Schema Change
+```yaml
+agent: architect
+action: analyze
+change_types:
+  - backward_compatible:
+      - Add optional field
+      - Add new event type
+      - Add default value
+  - forward_compatible:
+      - Remove optional field
+      - Ignore unknown fields
+  - breaking:
+      - Remove required field
+      - Change field type
+      - Rename field
+```
+
+### Step 1.2: Impact Assessment
+```yaml
+agent: architect
+action: assess
+considerations:
+  - Affected consumers
+  - Required timeline
+  - Rollback strategy
+  - Data migration needs
+```
+
+## Phase 2: Schema Design
+
+### Step 2.1: Design New Schema Version
+```yaml
+agent: fullstack-developer
+action: design
+formats:
+  - Avro
+  - Protobuf
+  - JSON Schema
+best_practices:
+  - Use optional fields by default
+  - Include schema version field
+  - Document deprecations
+  - Plan for unknown fields
+```
+
+### Step 2.2: Validate Compatibility
+```yaml
+agent: fullstack-developer
+action: validate
+checks:
+  - backward_compatibility_test
+  - forward_compatibility_test
+  - schema_registry_compatibility
+tools:
+  - Confluent Schema Registry
+  - AWS Glue Schema Registry
+```
+
+## Phase 3: Consumer Preparation
+
+### Step 3.1: Update Consumer Code
+```yaml
+agent: fullstack-developer
+action: update
+patterns:
+  - Handle missing optional fields
+  - Ignore unknown fields
+  - Version-aware deserialization
+  - Graceful degradation
+```
+
+### Step 3.2: Deploy Consumer Updates
+```yaml
+agent: fullstack-developer
+action: deploy
+strategy:
+  - Deploy consumers first
+  - Verify backward compatibility
+  - No data loss on old messages
+```
+
+## Phase 4: Producer Update
+
+### Step 4.1: Register New Schema
+```yaml
+agent: fullstack-developer
+action: register
+steps:
+  - Submit to schema registry
+  - Verify compatibility check passes
+  - Document schema version
+```
+
+### Step 4.2: Update Producer Code
+```yaml
+agent: fullstack-developer
+action: update
+requirements:
+  - Use new schema for serialization
+  - Include schema ID in messages
+  - Test with new format
+```
+
+### Step 4.3: Deploy Producer
+```yaml
+agent: fullstack-developer
+action: deploy
+strategy:
+  - Canary deployment
+  - Monitor consumer errors
+  - Verify message processing
+```
+
+## Phase 5: Cleanup (Breaking Changes Only)
+
+### Step 5.1: Migration Period
+```yaml
+agent: architect
+action: monitor
+period: grace_period
+checks:
+  - Old schema messages processed
+  - No consumer errors
+  - All consumers upgraded
+```
+
+### Step 5.2: Deprecate Old Schema
+```yaml
+agent: fullstack-developer
+action: deprecate
+steps:
+  - Mark old schema deprecated
+  - Set deletion date
+  - Notify remaining consumers
+  - Eventually delete
+```
+
+## Outputs
+- [ ] New schema version
+- [ ] Compatibility validation report
+- [ ] Updated consumer code
+- [ ] Updated producer code
+- [ ] Migration documentation
+
+## Quality Gates
+- Schema passes compatibility checks
+- All consumers handle new schema
+- No message processing errors
+- Rollback plan tested
+- Documentation updated

package/plugin/workflows/fullstack/authentication.md

@@ -10,10 +10,10 @@ agents:
   - security-auditor
   - tester
 skills:
-  - oauth
-  - better-auth
-  - owasp
-  - security-hardening
+  - security/oauth
+  - security/better-auth
+  - security/owasp
+  - security/security-hardening
 commands:
   - /planning:plan
   - /dev:feature

package/plugin/workflows/fullstack/full-feature.md

@@ -14,10 +14,10 @@ agents:
   - code-reviewer
   - git-manager
 skills:
-  - writing-plans
-  - database-schema-design
-  - api-architecture
-  - frontend-design
+  - methodology/writing-plans
+  - databases/database-schema-design
+  - backend/api-architecture
+  - frontend/frontend-design
 commands:
   - /planning:plan-detailed
   - /dev:feature