updates to use custom status instead of notifications

Author: kendallroden

README.md

@@ -113,16 +113,16 @@ POST http://localhost:3008/returns
 All workflows use descriptive activity names for clear dashboard visualization:
 
 **Bulk Processing:**
-- `announce_bulk_order_started` → `announce_child_workflow_spawned` → `announce_waiting_for_children`
-- `announce_item_success` / `announce_item_failure` → `announce_bulk_order_completed`
+- `bulk_order_started` → `child_workflow_spawned` → `waiting_for_children`
+- `item_success` / `item_failure` → `bulk_order_completed`
 
 **Returns Processing:**
-- `announce_return_request_received` → `announce_return_validation_started` → `announce_return_approval_required`
-- `announce_defective_return_started` / `announce_standard_refund_processing` / `announce_expedited_parallel_processing`
+- `return_request_received` → `return_validation_started` → `return_approval_required`
+- `defective_return_started` / `standard_refund_processing` / `expedited_parallel_processing`
 
 **Chaos Engineering:**
-- `announce_failure_injection_started` → `execute_retry_policy_test` → `execute_circuit_breaker_test`
-- `announce_external_event_starvation_started` → `announce_child_workflow_zombie_detected`
+- `failure_injection_started` → `execute_retry_policy_test` → `execute_circuit_breaker_test`
+- `external_event_starvation_started` → `child_workflow_zombie_detected`
 
 ### Circuit Breaker Monitoring
 Real-time circuit breaker status available at:

bulk-demo.http

@@ -39,9 +39,7 @@ Content-Type: application/json
 {
   "customer": "alice",
   "items": [
-    {"item": "apple", "quantity": 2, "price": 50.0},
-    {"item": "orange", "quantity": 1, "price": 75.0},
-    {"item": "pear", "quantity": 3, "price": 30.0}
+    {"item": "apple", "quantity": 2, "price": 50.0}
   ]
 }
 
@@ -137,68 +135,3 @@ GET http://localhost:3007/bulk-orders/{{mixed_bulk_instance_id}}
 @single_bulk_instance_id = {{single_item_bulk.response.body.instance_id}}
 
 GET http://localhost:3007/bulk-orders/{{single_bulk_instance_id}}
-
-### =============================================
-### BULK ORDER WORKFLOW DEMONSTRATION POINTS
-### =============================================
-###
-### 🎯 KEY FEATURES TO HIGHLIGHT:
-###
-### 1. PARENT-CHILD WORKFLOW ORCHESTRATION:
-###    - Single bulk order creates multiple child workflows
-###    - Each item processed independently with parallel execution
-###    - Parent workflow coordinates and tracks all children
-###    - Clear activity names for workflow visualization
-###
-### 2. ADVANCED ACTIVITY NAMING:
-###    - announce_bulk_order_started: Clear workflow initiation
-###    - announce_child_workflow_spawned: Track child creation
-###    - announce_waiting_for_children: Parent coordination point
-###    - announce_item_success/failure: Individual outcomes
-###    - announce_inventory_reserved: Business logic completion
-###    - announce_payment_processing: Payment stage identification
-###    - announce_shipping_scheduled: Final fulfillment step
-###
-### 3. REAL-TIME MONITORING:
-###    - Live notifications with [BULK] prefix in UI
-###    - Parent and child workflow status tracking
-###    - Progress updates for each processing stage
-###    - Failure isolation between child workflows
-###
-### 4. APPROVAL WORKFLOW INTEGRATION:
-###    - Automatic approval detection for high-value items
-###    - External event handling for manager approvals
-###    - Individual item approval within bulk orders
-###    - Timeout handling for pending approvals
-###
-### 5. PARALLEL PROCESSING BENEFITS:
-###    - Multiple items processed simultaneously
-###    - Inventory reservation coordination
-###    - Payment processing optimization
-###    - Shipping schedule coordination
-###
-### 6. FAILURE HANDLING:
-###    - Graceful handling of partial bulk order failures
-###    - Individual item failure isolation
-###    - Compensation patterns for failed items
-###    - Parent workflow status aggregation
-###
-### 7. SCALABILITY DEMONSTRATION:
-###    - Bulk orders of varying sizes (1-10+ items)
-###    - Mixed-value scenarios with differential processing
-###    - Resource efficient child workflow spawning
-###    - Coordinated completion handling
-###
-### =============================================
-### 🚀 DEMO EXECUTION GUIDE:
-###
-### TIMING: Execute requests with 10-15 second delays for observation
-### MONITORING: Keep notifications UI (localhost:8080) open during demo
-### OBSERVATION: Watch for parent workflow coordination messages
-### ANALYSIS: Use workflow IDs to trace parent-child relationships
-### APPROVAL: Use actual child workflow IDs from bulk order responses
-###
-### EXPECTED DEMO DURATION: 5-10 minutes for complete demonstration
-### CONCURRENT PROCESSING: Child workflows execute in parallel
-### NOTIFICATION RATE: Expect 5-15 events per bulk order
-### =============================================

dapr.yaml

@@ -16,10 +16,6 @@ apps:
     appPort: 3003
     appDirPath: ./services/payments
     command: ["python3", "app.py"]
-  - appID: notifications
-    appPort: 8080
-    appDirPath: ./services/notifications
-    command: ["npm", "run", "dev"]
   - appID: shipping
     appPort: 3004
     appDirPath: ./services/shipping

return-demo.http

@@ -249,13 +249,13 @@ GET http://localhost:3008/returns/{{concurrent_defective_id}}
 ###    - External event integration with timeouts and fallbacks
 ###
 ### 2. ADVANCED ACTIVITY NAMING:
-###    - announce_return_request_received: Clear workflow entry point
-###    - announce_return_validation_started: Eligibility checking phase
-###    - announce_return_approval_required: High-value return detection
-###    - announce_return_child_workflow_spawned: Type-specific processing
-###    - announce_defective_return_started: Defective item workflow
-###    - announce_standard_refund_processing: Standard return path
-###    - announce_expedited_parallel_processing: Fast-track processing
+###    - return_request_received: Clear workflow entry point
+###    - return_validation_started: Eligibility checking phase
+###    - return_approval_required: High-value return detection
+###    - return_child_workflow_spawned: Type-specific processing
+###    - defective_return_started: Defective item workflow
+###    - standard_refund_processing: Standard return path
+###    - expedited_parallel_processing: Fast-track processing
 ###
 ### 3. DYNAMIC CHILD WORKFLOWS BY RETURN TYPE:
 ###    - DEFECTIVE: Full refund, no restocking (disposal path)