docs: organize workflow examples by pattern

dapr/ext/rag/AGENTS.md

@@ -217,7 +217,7 @@ without one document's failure discarding its siblings' outcomes.
 
 **History size**: after each batch, the orchestrator calls `ctx.continue_as_new(...)` with a small,
 flat cursor state (`_IngestionState`) rather than accumulating the manifest or every batch's
-results in workflow history -- the same pattern `examples/workflow/monitor.py` uses for an eternal
+results in workflow history -- the same pattern `examples/workflow/monitor/monitor.py` uses for an eternal
 polling workflow. History size per generation stays bounded regardless of total corpus size.
 
 **Dataclasses, not pydantic, across the activity boundary.** `dapr.ext.workflow`'s automatic

dapr/ext/rag/pipeline.py

@@ -36,7 +36,7 @@
 # orchestrator calls `ctx.continue_as_new(...)` with a small, flat "cursor"
 # state (`_IngestionState`) rather than accumulating the manifest or every
 # batch's results in workflow history, so history size stays bounded
-# regardless of corpus size (see `examples/workflow/monitor.py` for the same
+# regardless of corpus size (see `examples/workflow/monitor/monitor.py` for the same
 # continue_as_new pattern applied to an eternal polling workflow).
 
 from __future__ import annotations

dapr/ext/workflow/AGENTS.md

@@ -205,12 +205,12 @@ Two example directories exercise workflows:
 
 - **`examples/workflow/`** — primary, comprehensive examples:
   - `simple.py` — activities, retries, child workflows, external events, pause/resume
-  - `task_chaining.py` — sequential activity chaining with error handling
-  - `fan_out_fan_in.py` — parallel execution with `when_all()`
-  - `human_approval.py` — external event waiting with timeouts
-  - `monitor.py` — eternal polling workflow with `continue_as_new()`
-  - `child_workflow.py` — child workflow orchestration
-  - `cross-app1.py`, `cross-app2.py`, `cross-app3.py` — cross-app calls
+  - `task-chaining/task_chaining.py` — sequential activity chaining with error handling
+  - `fan-out-fan-in/fan_out_fan_in.py` — parallel execution with `when_all()`
+  - `human-interaction/human_approval.py` — external event waiting with timeouts
+  - `monitor/monitor.py` — eternal polling workflow with `continue_as_new()`
+  - `child-workflow/child_workflow.py` — child workflow orchestration
+  - `multi-app/multi-app1.py`, `multi-app/multi-app2.py`, `multi-app/multi-app3.py` — cross-app calls
   - `versioning.py` — workflow versioning with `is_patched()`
   - `simple_aio_client.py` — async client variant
   - `async_activities.py` — `async def` activities (fan-out/fan-in with simulated I/O, configurable payload sizes)

examples/AGENTS.md

@@ -98,7 +98,7 @@ Common component types used in examples: `state.redis`, `pubsub.redis`, `lock.re
 |---------|---------|-------------|----------------|
 | `workflow` | Multiple standalone scripts | `dapr[workflow]` | No |
 
-The `workflow` example includes: `simple.py`, `task_chaining.py`, `fan_out_fan_in.py`, `human_approval.py`, `monitor.py`, `child_workflow.py`, `cross-app1/2/3.py`, `versioning.py`, `simple_aio_client.py`.
+The `workflow` example includes standalone feature examples such as `simple.py`, `simple_aio_client.py`, and `versioning.py`, plus pattern directories: `task-chaining/`, `fan-out-fan-in/`, `human-interaction/`, `monitor/`, `child-workflow/`, and `multi-app/`. Each pattern directory has its own README.
 
 ### Secrets, configuration, locks
 | Example | Pattern | SDK packages | Has components |

examples/rag/reconciliation_workflow.py

@@ -31,7 +31,7 @@
 `ctx.create_timer(...)` / `ctx.wait_for_external_event(...)` pattern inside an
 actual Dapr Workflow instead (one durable "quiet window" orchestration per
 prefix, restarting its timer on every new external event, matching
-`examples/workflow/human_approval.py`'s wait-with-timeout shape) so exactly
+`examples/workflow/human-interaction/human_approval.py`'s wait-with-timeout shape) so exactly
 one reconciliation fires regardless of replica count. Noted here rather than
 implemented, to keep this example's scope matched to its single-process
 demo. For the same reason, a process crash between accumulating a pending