Cross-link Design Patterns and Guides

Design Patterns and Guides moved to sibling top-level sidebar sections
recently and had zero cross-links in either direction. Adds a "Guides"
section to 8 pattern pages pointing to matching worked examples, and
reciprocal links back from those guides' Related resources sections.

Also fixes two stale links to the saga pattern that pointed at an
external site and a thin blurb instead of the in-depth
/design-patterns/saga-pattern page, and renames "Related resources" to
"Related patterns" on the four batch-processing pages for heading
consistency with the rest of the section.

Author: Duncanma

docs/best-practices/error-handling.mdx

@@ -123,7 +123,7 @@ consistent across retries but unique across Workflow Executions.
 ## Implement compensation with the Saga pattern {/* #saga-pattern */}
 
 When a multi-step process fails partway through, previous steps may need to be undone. The
-[Saga pattern](/evaluate/use-cases-design-patterns#saga) coordinates a sequence of operations where each step has a
+[Saga pattern](/design-patterns/saga-pattern) coordinates a sequence of operations where each step has a
 compensating action that reverses its effects. If any step fails, the compensating actions for previously completed
 steps execute in reverse order.
 

docs/design-patterns/approval.mdx

@@ -863,6 +863,10 @@ If the approver's interface needs immediate confirmation that the approval was a
 - [Updatable Timer](/design-patterns/updatable-timer): Extending approval deadlines dynamically.
 - [Saga Pattern](/design-patterns/saga-pattern): Executing compensating actions on rejection.
 
+## Guides
+
+- [Reliable document approvals](/guides/reliable-document-approvals): A complete Python implementation with SLA timers, automatic escalation, resubmission loops, and audit logging.
+
 ## Sample code
 
 **Java**

docs/design-patterns/batch-iterator.mdx

@@ -244,7 +244,7 @@ public class BatchIteratorWorkflowImpl implements BatchIteratorWorkflow {
 - **Passing unnecessary state into `continueAsNew`.** All arguments are serialized and stored in history. Pass only the minimal state needed (offset, counters) — not accumulated result lists or large collections that grow with each page.
 - **Sequential processing bottlenecks.** The default implementation processes one record at a time per page. You can fan out Activities concurrently within a page using the SDK's async primitives for higher per-page throughput — note this increases per-page event count accordingly. If record-set-wide throughput matters more than rate limiting, consider [Sliding Window](/design-patterns/sliding-window) or [MapReduce Tree](/design-patterns/mapreduce-tree).
 
-## Related resources
+## Related patterns
 
 - [Continue-as-New pattern](/design-patterns/continue-as-new) — core concepts for history management via `continueAsNew`
 - [Sliding Window](/design-patterns/sliding-window) — bounded concurrency that progresses at the rate of the fastest processor

docs/design-patterns/continue-as-new.mdx

@@ -414,6 +414,11 @@ You cannot undo Continue-As-New once triggered.
 - **[Child Workflows](/design-patterns/child-workflows)**: Decomposing work into sub-Workflows. Consider Parent Close Policy when combining with Continue-As-New.
 - **[Signal with Start](/design-patterns/signal-with-start)**: Idempotent Workflow start with an initial Signal — use Workflow ID without Run ID to interact with continued executions.
 
+## Guides
+
+- [Track customer loyalty points with durable Workflows](/guides/entity-pattern-loyalty-points): Uses Continue-As-New to keep a long-lived customer loyalty account within Event History limits, including an upgrade path at the Continue-As-New boundary for Worker Versioning.
+- [Player Sessions That Survive Anything](/guides/durable-gaming-sessions): Uses Continue-As-New so a multiplayer game session can run for weeks without unbounded history growth.
+
 ## Sample code
 
 **Java:**

docs/design-patterns/downstream-rate-limiting.mdx

@@ -287,6 +287,10 @@ The concurrency slots (`MaxConcurrentActivityExecutionSize`, `MaxConcurrentWorkf
 - **[Fairness](/design-patterns/fairness)**: Give each tenant an equal throughput share when multiple tenants share capacity.
 - **[Worker-Specific Task Queues](/design-patterns/worker-specific-taskqueue)**: Route Activities to a specific Worker host for resource or data affinity.
 
+## Guides
+
+- [Rate-limit downstream APIs with separate Task Queues](/guides/rate-limit-downstream-apis): A Python walkthrough covering multiple rate-limited APIs (SendGrid, Stripe, OpenAI), 429 handling with `Retry-After`, and backlog draining strategies.
+
 ## References
 
 - **Python** — [`max_task_queue_activities_per_second`](https://python.temporal.io/temporalio.worker.WorkerConfig.html#max_task_queue_activities_per_second) on [`Worker`](https://python.temporal.io/temporalio.worker.Worker.html)

docs/design-patterns/entity-workflow.mdx

@@ -536,6 +536,11 @@ Trade-offs:
 - **[Request-Response via Updates](/design-patterns/request-response-via-updates)**: Synchronous operations with validation.
 - **[Signal with Start](/design-patterns/signal-with-start)**: Idempotent Workflow start with an initial Signal.
 
+## Guides
+
+- [Track customer loyalty points with durable Workflows](/guides/entity-pattern-loyalty-points): A complete Python implementation of this pattern, including tier calculation, Continue-As-New, and Worker Versioning for accounts that span years.
+- [Player Sessions That Survive Anything](/guides/durable-gaming-sessions): Extends the Entity Workflow into an Actor Workflow that executes game actions — joining rooms, resolving combat — rather than only holding state.
+
 ## Sample code
 
 **Python:**

docs/design-patterns/fanout-child-workflows.mdx

@@ -317,7 +317,7 @@ public class RecordBatchWorkflowImpl implements RecordBatchWorkflow {
 - **Passing large lists of IDs.** Workflow inputs are stored in event history. Passing millions of record IDs as a list will blow the history size limit. Use offset + length instead.
 - **Ignoring child failures.** A failed child does not automatically fail the parent unless you await all results. Always await child handles and handle errors explicitly.
 
-## Related resources
+## Related patterns
 
 - [Child Workflows pattern](/design-patterns/child-workflows) — core concepts for parent/child Workflow coordination
 - [Batch Iterator](/design-patterns/batch-iterator) — unbounded record sets with Continue-as-New pagination

docs/design-patterns/mapreduce-tree.mdx

@@ -431,7 +431,7 @@ public class NodeWorkflowImpl implements NodeWorkflow {
 - **History bloat in the Root Workflow.** Each child start and signal received adds events to the Root's history. For very large record sets, consider adding an extra tree level to keep the Root from receiving too many direct signals.
 - **Attempting external/downstream writes from Node Workflows.** Nodes may be retried. Any external write in a Node Workflow will be executed multiple times. Keep all side effects in Leaf Workflows (or Activities called by Leaves).
 
-## Related resources
+## Related patterns
 
 - [Fan-Out with Child Workflows](/design-patterns/fanout-child-workflows) — simpler flat fan-out for smaller record sets
 - [Sliding Window](/design-patterns/sliding-window) — bounded concurrency with rate limiting

docs/design-patterns/non-retryable-errors.mdx

@@ -480,6 +480,10 @@ try {
 - [Resumable Activity](/design-patterns/resumable-activity): Park the Workflow and accept a corrected input via Signal when retries are exhausted.
 - [Error Handling & Retry Patterns](/design-patterns/error-handling-patterns): Overview and decision tree for all retry patterns.
 
+## Guides
+
+- [Recover business processes without restarting](/guides/recover-without-restart): Uses `ApplicationFailure.nonRetryable()` throughout a loan pipeline to distinguish permanent failures that need a human fix from transient ones the default Retry Policy already handles.
+
 ## References
 
 - [Temporal Retry Policies](/encyclopedia/retry-policies)

docs/design-patterns/resumable-activity.mdx

@@ -560,3 +560,7 @@ stateDiagram-v2
 - [Fast/Slow Retries](/design-patterns/fast-slow-retries): Infinite patient retries when the downstream system is temporarily unavailable.
 - [Signal with Start](/design-patterns/signal-with-start): Start the Workflow and send the correction Signal atomically.
 - [Error Handling & Retry Patterns](/design-patterns/error-handling-patterns): Overview and decision tree for all retry patterns.
+
+## Guides
+
+- [Recover business processes without restarting](/guides/recover-without-restart): A `recoverableStep` implementation of this pattern in a six-step loan pipeline, with Search Attribute-based routing so operators can find and fix blocked cases.