Update V2 docs for unified helper API

Replace all references to removed functions (startActivity, startChild,
awaitSignal, awaitWithTimeout, parallel) with their unified equivalents.
Add timer sugar documentation. V1 versioned docs untouched.

Ref: zorporation/durable-workflow#278

Author: durable-workflow-ops

docs/constraints/structural-limits.md

@@ -15,7 +15,7 @@ Structural limits cap the resource consumption of a single workflow run. When an
 | `pending_timer_count` | 2,000 | Pending timers open simultaneously |
 | `pending_signal_count` | 5,000 | Unprocessed signals pending simultaneously |
 | `pending_update_count` | 500 | Unresolved updates pending simultaneously |
-| `command_batch_size` | 1,000 | Items in a single parallel fan-out (`all()` / `parallel()`) |
+| `command_batch_size` | 1,000 | Items in a single parallel fan-out (`all()`) |
 | `payload_size_bytes` | 2 MiB | Serialized size of a single argument payload |
 | `memo_size_bytes` | 256 KiB | Serialized size of non-indexed memo metadata |
 | `search_attribute_size_bytes` | 40 KiB | Serialized size of indexed search-attribute metadata |
@@ -80,7 +80,7 @@ This protects against patterns like unbounded parallel fan-out loops that accumu
 // This will fail if $items exceeds the pending_activity_count limit
 $calls = [];
 foreach ($items as $item) {
-    $calls[] = startActivity(ProcessItemActivity::class, $item);
+    $calls[] = fn () => activity(ProcessItemActivity::class, $item);
 }
 return all($calls); // Also checked against command_batch_size
 ```
@@ -91,7 +91,7 @@ To handle large batches within the limits, process items in bounded chunks:
 foreach (array_chunk($items, 500) as $chunk) {
     $calls = [];
     foreach ($chunk as $item) {
-        $calls[] = startActivity(ProcessItemActivity::class, $item);
+        $calls[] = fn () => activity(ProcessItemActivity::class, $item);
     }
     all($calls);
 }
@@ -116,7 +116,7 @@ if ($result->rejected()) {
 
 ### Command batch size
 
-The `all()` and `parallel()` functions check the total number of leaf operations in a single fan-out group against `command_batch_size`. This is checked before any individual activities or children are scheduled, so the run fails cleanly rather than partially scheduling a batch.
+The `all()` function checks the total number of leaf operations in a single fan-out group against `command_batch_size`. This is checked before any individual activities or children are scheduled, so the run fails cleanly rather than partially scheduling a batch.
 
 ### Payload size
 
@@ -156,7 +156,7 @@ This catches runaway loops that create unbounded events in a single task without
 foreach (array_chunk($items, 500) as $chunk) {
     $calls = [];
     foreach ($chunk as $item) {
-        $calls[] = startActivity(ProcessItemActivity::class, $item);
+        $calls[] = fn () => activity(ProcessItemActivity::class, $item);
     }
     all($calls);  // Each chunk is a separate task execution
 }

docs/defining-workflows/activities.md

@@ -77,17 +77,19 @@ $result = activity(
 );
 ```
 
-The same pattern works with `startActivity()` for async activity calls:
+The same pattern works with closures inside `all()` for parallel activity calls:
 
 ```php
-use function Workflow\V2\startActivity;
+use function Workflow\V2\all;
 use Workflow\V2\Support\ActivityOptions;
 
-$handle = startActivity(
-    MyActivity::class,
-    new ActivityOptions(queue: 'batch'),
-    $name,
-);
+$results = all([
+    fn () => activity(
+        MyActivity::class,
+        new ActivityOptions(queue: 'batch'),
+        $name,
+    ),
+]);
 ```
 
 ### Available options

docs/features/child-workflows.md

@@ -44,28 +44,28 @@ final class ParentWorkflow extends Workflow
 - Parent workflows can signal the current child through that handle with `signal()`, `signalWithArguments()`, or method-call sugar such as `$this->child()?->approvedBy('Taylor')`.
 - Query replay keeps those handles read-only, while inline update application can still use the handle to emit a real child signal exactly once.
 - Waterline exposes that relationship in detail views through lineage (`parents` / `continuedWorkflows`), child wait rows in `waits`, and typed child entries in `timeline`.
-- `Workflow\V2\all()` can group child workflows by themselves or alongside `activity(...)` calls from the same parent step when you build the barrier with `startChild()` and `startActivity()`.
-- Child-only `all([...startChild(...)])` barriers, nested `parallel([...])` child groups, and mixed `startChild(...)` plus `startActivity(...)` barriers return results in the original nested array shape once every member of the group completes successfully.
+- `Workflow\V2\all()` can group child workflows by themselves or alongside `activity(...)` calls from the same parent step when you build the barrier with closures such as `fn () => child(...)` and `fn () => activity(...)`.
+- Child-only `all([fn () => child(...)])` barriers, nested child groups, and mixed `fn () => child(...)` plus `fn () => activity(...)` barriers return results in the original nested array shape once every member of the group completes successfully.
 - In any barrier that includes children, the parent wakes immediately on the first failed, cancelled, or terminated child, but successful child closures do not wake the parent until the last successful member in every enclosing group closes.
 - If several barrier members have already closed unsuccessfully by the time the parent replays, the parent-visible failure is selected by earliest recorded close time and then by the lower barrier leaf index for exact timestamp ties.
 - Once that selected child close has already been thrown into the parent step, later sibling closures stay sibling history only; they do not replace the chosen throwable or reopen the parent run.
 
 ## Parallel Child Barrier
 
-Import the helpers with `use function Workflow\V2\all;` and `use function Workflow\V2\startChild;` when you want one parent step to wait on several child workflows together.
+Import the helpers with `use function Workflow\V2\all;` and `use function Workflow\V2\child;` when you want one parent step to wait on several child workflows together.
 
 ```php
 use function Workflow\V2\all;
-use function Workflow\V2\startChild;
+use function Workflow\V2\child;
 use Workflow\V2\Workflow;
 
 final class ParentWorkflow extends Workflow
 {
     public function handle(): array
     {
         $children = all([
-            startChild(FirstChildWorkflow::class),
-            startChild(SecondChildWorkflow::class),
+            fn () => child(FirstChildWorkflow::class),
+            fn () => child(SecondChildWorkflow::class),
         ]);
 
         return $children;
@@ -113,7 +113,7 @@ final class ParentWorkflow extends Workflow
 
 - `$this->child()` returns the latest visible child handle or `null`.
 - `$this->children()` returns every visible handle in workflow-step order.
-- During `all([...startChild(...)])` barriers, those handles appear in the same step order as the child calls inside the barrier, and `$this->child()` returns the last visible one.
+- During `all([fn () => child(...)])` barriers, those handles appear in the same step order as the child calls inside the barrier, and `$this->child()` returns the last visible one.
 - A handle's `runId()` follows the newest parent-recorded `ChildRunStarted` in that child invocation chain, so a parent waiting on a child that used `continueAsNew()` still sees the latest child run id without losing the original `callId()`.
 
 ## Handle Availability
@@ -153,7 +153,7 @@ When a parent workflow closes — whether by completing, failing, timing out, be
 
 ### Setting the policy
 
-Pass a `ChildWorkflowOptions` as the first argument to `child()` or `startChild()`:
+Pass a `ChildWorkflowOptions` as the first argument to `child()`:
 
 ```php
 use function Workflow\V2\child;
@@ -174,11 +174,11 @@ final class ParentWorkflow extends Workflow
 }
 ```
 
-The same pattern works with `startChild()` for parallel barriers:
+The same pattern works with closures inside `all()` for parallel barriers:
 
 ```php
 use function Workflow\V2\all;
-use function Workflow\V2\startChild;
+use function Workflow\V2\child;
 use Workflow\V2\Enums\ParentClosePolicy;
 use Workflow\V2\Support\ChildWorkflowOptions;
 
@@ -187,8 +187,8 @@ $cancelOptions = new ChildWorkflowOptions(
 );
 
 $results = all([
-    startChild(FirstChild::class, $cancelOptions),
-    startChild(SecondChild::class, $cancelOptions, 'arg'),
+    fn () => child(FirstChild::class, $cancelOptions),
+    fn () => child(SecondChild::class, $cancelOptions, 'arg'),
 ]);
 ```
 
@@ -220,6 +220,6 @@ Waterline shows the `parent_close_policy` in:
 
 The current surface does not include:
 
-- built-in bounded-concurrency helpers beyond the current `all([...startChild(...)])`, `all([...startActivity(...)])`, and mixed `all([...startChild(...), startActivity(...)])` barriers
+- built-in bounded-concurrency helpers beyond the current `all([fn () => child(...)])`, `all([fn () => activity(...)])`, and mixed `all([fn () => child(...), fn () => activity(...)])` barriers
 
-In other words, durable child handles are supported for already-reached child steps, but it does not yet include higher-level launch-handle or bounded-concurrency APIs beyond today's `child(...)`, `startChild()`, and `all([...])` surface.
+In other words, durable child handles are supported for already-reached child steps, but it does not yet include higher-level launch-handle or bounded-concurrency APIs beyond today's `child(...)` and `all([...])` surface.

docs/features/concurrency.md

@@ -6,9 +6,9 @@ import ConcurrencySimulator from '@site/src/components/ConcurrencySimulator';
 
 # Concurrency
 
-In `Workflow\V2`, named workflows use straight-line helpers inside an ordinary `handle()` method: `activity()`, `awaitSignal()`, `timer()`, `sideEffect()`, `getVersion()`, and the other single-step helpers suspend directly under the hood instead of forcing `yield` into every workflow body. Named v2 workflows are straight-line only, so do not `yield` from the workflow body.
+In `Workflow\V2`, named workflows use straight-line helpers inside an ordinary `handle()` method: `activity()`, `signal()`, `timer()`, `sideEffect()`, `getVersion()`, and the other single-step helpers suspend directly under the hood instead of forcing `yield` into every workflow body. Named v2 workflows are straight-line only, so do not `yield` from the workflow body.
 
-Parallel barriers still suspend as one durable workflow step through `all([...])`. In straight-line workflows, build those barriers with explicit launch helpers such as `startActivity()`, `startChild()`, and `parallel([...])` so the runtime can see the full barrier tree before the workflow suspends. Results still come back in the original nested array shape, while Waterline keeps each durable leaf wait visible and uses `parallel_group_path` to show which outer and inner barriers that leaf belongs to.
+Parallel barriers still suspend as one durable workflow step through `all([...])`. In straight-line workflows, build those barriers with closures such as `fn () => activity(...)` and `fn () => child(...)` so the runtime can see the full barrier tree before the workflow suspends. Results still come back in the original nested array shape, while Waterline keeps each durable leaf wait visible and uses `parallel_group_path` to show which outer and inner barriers that leaf belongs to.
 
 ## Series
 
@@ -46,17 +46,17 @@ class MyWorkflow extends Workflow
 This example will execute 3 activities in parallel, waiting for the completion of all activities and collecting the results.
 
 ```php
-use function Workflow\V2\{all, startActivity};
+use function Workflow\V2\{all, activity};
 use Workflow\V2\Workflow;
 
 class MyWorkflow extends Workflow
 {
     public function handle()
     {
         return all([
-            startActivity(MyActivity1::class),
-            startActivity(MyActivity2::class),
-            startActivity(MyActivity3::class),
+            fn () => activity(MyActivity1::class),
+            fn () => activity(MyActivity2::class),
+            fn () => activity(MyActivity3::class),
         ]);
     }
 }
@@ -72,25 +72,25 @@ class MyWorkflow extends Workflow
   title="Parallel Execution Simulator"
 />
 
-The main difference between the serial example and the parallel execution example is where suspension happens. In the serial example, each `activity()` call suspends and resumes the workflow directly. In the parallel example, the `startActivity()` builders describe the whole barrier first and `all()` suspends once for the whole group, so every member can run in parallel before the workflow resumes.
+The main difference between the serial example and the parallel execution example is where suspension happens. In the serial example, each `activity()` call suspends and resumes the workflow directly. In the parallel example, the closures describe the whole barrier first and `all()` suspends once for the whole group, so every member can run in parallel before the workflow resumes.
 
 ## Nested Barriers
 
 Nested `all([...])` groups let one workflow step express a tree of durable fan-out and fan-in work. The runtime schedules every activity or child workflow as a durable leaf sequence, records the leaf's full `parallel_group_path`, waits until every enclosing barrier can make progress, and then rebuilds the original nested result shape before resuming the workflow body. During replay, an activity or child leaf from an `all([...])` step must still match that recorded group path; typed leaf history that has no group metadata is treated as incompatible older preview history instead of being guessed into the current barrier.
 
 ```php
-use function Workflow\V2\{all, parallel, startActivity};
+use function Workflow\V2\{all, activity};
 use Workflow\V2\Workflow;
 
 final class NestedWorkflow extends Workflow
 {
     public function handle(): array
     {
         return all([
-            startActivity(BuildSummary::class),
-            parallel([
-                startActivity(BuildInvoice::class),
-                startActivity(BuildShipment::class),
+            fn () => activity(BuildSummary::class),
+            fn () => all([
+                fn () => activity(BuildInvoice::class),
+                fn () => activity(BuildShipment::class),
             ]),
         ]);
     }
@@ -101,7 +101,7 @@ In that example, Waterline exposes three open leaf waits, not one synthetic "nes
 
 ## Async Callback
 
-`async(...)` runs a serializable callback as a durable child workflow with the system type `durable-workflow.async`. Async callbacks use the same straight-line-only helper contract as named v2 workflows, so `activity()`, `awaitSignal()`, `timer()`, `sideEffect()`, and the other single-step helpers suspend directly inside the callback body without forcing `yield`.
+`async(...)` runs a serializable callback as a durable child workflow with the system type `durable-workflow.async`. Async callbacks use the same straight-line-only helper contract as named v2 workflows, so `activity()`, `signal()`, `timer()`, `sideEffect()`, and the other single-step helpers suspend directly inside the callback body without forcing `yield`.
 
 ```php
 use function Workflow\V2\{activity, async};
@@ -125,7 +125,7 @@ final class CustomerWorkflow extends Workflow
 }
 ```
 
-The parent run sees the callback as a child wait, so command history, lineage, and Waterline detail use the same `child_call_id`, child run id, and child outcome history as an explicit `child(...)` call. The callback is serialized with Laravel's serializable-closure support, so keep it app-local and deployment-local. Use a named `child(SomeWorkflow::class, ...)` call when the work needs a stable public workflow type for cross-service routing or long-lived code evolution. `async(...)` callbacks are now straight-line only in v2, so call helpers like `activity()`, `child()`, `awaitSignal()`, `timer()`, and `all([...])` directly without `yield`.
+The parent run sees the callback as a child wait, so command history, lineage, and Waterline detail use the same `child_call_id`, child run id, and child outcome history as an explicit `child(...)` call. The callback is serialized with Laravel's serializable-closure support, so keep it app-local and deployment-local. Use a named `child(SomeWorkflow::class, ...)` call when the work needs a stable public workflow type for cross-service routing or long-lived code evolution. `async(...)` callbacks are now straight-line only in v2, so call helpers like `activity()`, `child()`, `signal()`, `timer()`, and `all([...])` directly without `yield`.
 
 ## Mixed Activity + Child Barriers
 
@@ -134,16 +134,16 @@ The same `all()` helper can also fan in a mixed group of activities and child wo
 When more than one barrier member has already closed unsuccessfully by the time the parent replays, the parent receives the failure with the earliest recorded close time. If two failures have the same recorded time, the lower barrier leaf index wins, so workflow resume and query replay select the same exception. Later sibling failures do not replace the exception that has already been thrown into the parent step.
 
 ```php
-use function Workflow\V2\{all, startActivity, startChild};
+use function Workflow\V2\{all, activity, child};
 use Workflow\V2\Workflow;
 
 final class OrderWorkflow extends Workflow
 {
     public function handle(): array
     {
         [$charge, $shipment] = all([
-            startActivity(ChargeCustomer::class),
-            startChild(ShipOrderWorkflow::class),
+            fn () => activity(ChargeCustomer::class),
+            fn () => child(ShipOrderWorkflow::class),
         ]);
 
         return compact('charge', 'shipment');
@@ -156,24 +156,24 @@ final class OrderWorkflow extends Workflow
 The current concurrency surface does not yet include:
 
 - launch handles that can be started and awaited separately from `all([...])` barriers or `async(...)`
-- built-in bounded-concurrency helpers beyond explicit nested `all([...])` groups plus `startActivity()` / `startChild()` builders
+- built-in bounded-concurrency helpers beyond explicit nested `all([...])` groups
 
 ## Child Workflows in Parallel
 
-Child workflows can also run in their own `all([...startChild(...)])` barrier. It works the same way as parallel activity execution, but for child workflows: the parent fans out several child runs durably and resumes only when the whole child barrier can make progress.
+Child workflows can also run in their own `all([...])` barrier. It works the same way as parallel activity execution, but for child workflows: the parent fans out several child runs durably and resumes only when the whole child barrier can make progress.
 
 ```php
-use function Workflow\V2\{all, startChild};
+use function Workflow\V2\{all, child};
 use Workflow\V2\Workflow;
 
 final class ParentWorkflow extends Workflow
 {
     public function handle(): array
     {
         return all([
-            startChild(MyChild1::class),
-            startChild(MyChild2::class),
-            startChild(MyChild3::class),
+            fn () => child(MyChild1::class),
+            fn () => child(MyChild2::class),
+            fn () => child(MyChild3::class),
         ]);
     }
 }

docs/features/queries.md

@@ -15,7 +15,7 @@ Queries replay committed history for the current selected run and then invoke th
 ```php
 use Workflow\QueryMethod;
 use Workflow\V2\Workflow;
-use function Workflow\V2\awaitSignal;
+use function Workflow\V2\signal;
 
 final class ApprovalWorkflow extends Workflow
 {
@@ -25,7 +25,7 @@ final class ApprovalWorkflow extends Workflow
     {
         $this->stage = 'waiting-for-approval';
 
-        awaitSignal('approved-by');
+        signal('approved-by');
 
         $this->stage = 'approved';
     }