@@ -1,5 +1,5 @@
 Add experimental `temporalio.contrib.streams` so Activities and clients can append ordered records to a Workflow's stream in Redis, and outside readers can follow it from a cursor. The `temporalio-streams` crate runs the store and the reader rules in process, so every SDK reads the same records.
 A Workflow publishes to its own stream with `stream_producer`. The Worker sends each live activation's records with `PublishWorkflowTask` before it completes the activation, so readers see them while the Workflow Task runs and nothing goes to History. If the store fails the append, the Workflow Task fails with `StreamOutputNotAppended`. A topic the store reports closed drops its records with a warning and counts `workflow_stream_output_dropped`.
 A Workflow's producer attempt is `(prefix << 16) | retry`, where `prefix` is the WorkflowTaskStarted event id of the run's last completed Workflow Task and `retry` counts that task's reruns since, from 1. So a read reports `SUPERSEDED` only for a rerun of the same task. `SupersessionTracker` tells a reader which earlier records each `SUPERSEDED` withdraws.
-A Local Activity publishes to its Workflow's stream with `activity_handle`, under a producer identity that survives its reruns.
+A Local Activity publishes to its Workflow's stream with `stream_producer`, under a producer identity that survives its reruns. Its attempt comes from the Workflow Task facts its Workflow stamps on the call, with no server call, and a reader withdraws its records when that task never completed.
 A read of a Workflow that Temporal doesn't know yet answers empty for `owner_start_grace` (60 seconds unless set), so a reader can start before its owner.
@@ -91,7 +91,7 @@ url = "2.2"
 # makes it use the submodule's crates, so the bridge sees one `Connection` type.
 [dependencies.temporalio-streams]
 git = "https://github.com/moetemp/sdk-streams"
-rev = "a08e6f32ccdebc64a8d208ac9aa1b1549e85479c"
+rev = "02ef7af32246475e209980bb87e11f72923c7801"
 default-features = false
 features = ["envconfig", "redis"]
 
 
@@ -132,29 +132,37 @@ an identity of its own:
   plugin's Worker interceptor stamps the number on each call in a header, so
   it stays the same across reruns, and across a retry that backs off longer
   than `local_retry_threshold`, which gets a new Activity id.
-- **Attempt.** Before the first append, the producer asks the server for
-  the run's History length `h` and the pending Workflow Task's attempt `t`.
-  With the Local Activity's attempt `a`, it writes attempt
-  `(h * 100_000 + t) * 10_000 + a`. Each rerun runs in a later Workflow Task
-  attempt, so the attempt grows, and readers see `SUPERSEDED` before the
-  rerun's records. A retry inside one attempt is written once, as for any
-  producer.
+- **Attempt.** The interceptor also stamps the Workflow Task facts of the
+  activation that schedules the call. Core takes them from History. The
+  task attempt is `prefix << 16 | retry`, the same value the Workflow's own
+  records use. With the Local Activity's attempt `a`, the producer writes
+  attempt `task attempt << 14 | min(a, 16383)`. Each rerun runs in a later
+  Workflow Task attempt, so the attempt grows, and readers see `SUPERSEDED`
+  before the rerun's records. A retry inside one attempt is written once, as
+  for any producer.
+- **Failed tasks.** The records carry the started event id of the call's
+  Workflow Task attempt and the run's last completed tasks, as the
+  Workflow's records do. If that task fails and its retry doesn't run the
+  call again, the next record of the run on the topic shows that the task
+  never completed. Readers then see `SUPERSEDED` for the call's records.
+
+The attempt needs no server call, so the first record goes out at once. The
+stream runtime's owner check describes the Workflow, but it caches the
+answer per owner run, so the run's Local Activities share it.
 
 Known limits:
 
-- **One describe call.** Each Local Activity attempt makes one
-  `DescribeWorkflowExecution` call before its first append, so its first
-  record waits one round trip to the server. Later appends make no call. The
-  stream runtime's owner check also describes the Workflow, but it caches
-  the answer per owner run for a minute, so the run's Local Activities share
-  it.
-- **Describe permission.** The Worker's identity needs permission to
-  describe the Workflow (`DescribeWorkflowExecution` on its namespace), both
-  for the attempt and for the stream runtime's owner check. Without it, the
-  first append fails.
-- **Attempt range.** A Local Activity past attempt 9,999, or in a Workflow
-  Task past attempt 99,999, raises `StreamUnsupportedError` on its first
-  append.
+- **Old failed tasks.** Each record lists only the run's last eight
+  completed tasks. If more than seven tasks complete before the next record
+  on the topic, the reader can't prove the call's task failed, and its
+  records stand.
+- **Rerun after a heartbeat.** If the Workflow Task completed as a
+  heartbeat while the call ran and a later task fails, the rerun schedules
+  the call again while it replays. It gets the first run's task facts, so
+  its first attempt writes the same producer attempt. The same content is
+  taken as a resend. Other content is refused with `StreamProducerError`,
+  which fails that Local Activity attempt, and the local retry writes a
+  higher attempt that supersedes the first run.
 
 ## Streams owned by a standalone Activity
 
 
@@ -14,9 +14,9 @@
 runs of a chain. A standalone Activity has no scheduling Workflow. It owns a
 stream of its own and writes it as ``<Activity id>@<Activity run id>``. A
 Local Activity writes as ``__temporal_local_<call number>@<scheduling run id>``,
-with an attempt that grows across its reruns (see ``_local_activity``). Its
-attempt doesn't fit the Activity form's 32 bits, so it writes as a named
-producer.
+with an attempt that grows across its reruns and the task facts its Workflow
+stamped (see ``_local_activity``). Its attempt doesn't fit the Activity form's
+32 bits, so it writes as a named producer.
 
 Any process holding a client reaches a Workflow's stream by Workflow id and
 writes with a producer id and attempt of its own.
@@ -131,11 +131,7 @@ def producer_id(self) -> str:
 
     @property
     def attempt(self) -> int:
-        """The attempt this producer writes.
-
-        In a Local Activity it is 0 until the first append asks the server
-        for it.
-        """
+        """The attempt this producer writes."""
         return self._attempt
 
     async def append(self, *values: T) -> Cursor:
@@ -223,8 +219,6 @@ async def join(self, *, name: str, until: Cursor | None = None) -> Cursor:
     async def _write(
         self, kind: RecordKind, values: Any, link: StreamLink | None = None
     ) -> Cursor:
-        if self._local_call is not None:
-            self._attempt = await self._local_call.attempt(self._handle._client)
         converter = self._handle._converter
         wires = [
             to_wire(
@@ -251,6 +245,13 @@ async def _write(
             request.named.CopyFrom(
                 NamedProducer(producer_id=self._producer_id, attempt=self._attempt)
             )
+            if self._local_call is not None:
+                request.named.task_started_event_id = (
+                    self._local_call.task_started_event_id
+                )
+                request.named.completed_started_event_ids.extend(
+                    self._local_call.completed_started_event_ids
+                )
         service = await self._handle._plugin._service_for(self._handle._client)
         response = await call(service.append(request))
         self._sequence += len(wires)
@@ -768,12 +769,14 @@ def producer(
 
         In a Local Activity the producer id is
         ``__temporal_local_<call number>@<scheduling run id>``, where the number counts
-        the run's Local Activity calls in order. Before the first append the
-        producer asks the server for the run's History length ``h`` and the
-        pending Workflow Task's attempt ``t``, and with the Local Activity's
-        attempt ``a`` writes attempt ``(h * 100_000 + t) * 10_000 + a``. So a
+        the run's Local Activity calls in order. The attempt is ``task attempt
+        << 14 | min(a, 16383)``. The task attempt is ``prefix << 16 | retry``
+        of the Workflow Task that scheduled the call, as the Workflow's own
+        records write it, and ``a`` is the Local Activity's attempt. So a
         rerun after a Worker crash or a failed Workflow Task, and a local
-        retry, each write a higher attempt.
+        retry, each write a higher attempt. The records carry the task's
+        started event id and the run's last completed tasks, so a reader
+        withdraws them when the task never completed.
 
         Every call in one attempt returns the same producer for a topic, so
         two parts of the Activity that each ask for it number their records
@@ -788,7 +791,7 @@ def producer(
                     self._inner,
                     name,
                     f"{local_call.producer_id_prefix}@{identity.run_id}",
-                    0,
+                    local_call.attempt(identity.attempt),
                     local_call=local_call,
                 )
             else:
@@ -840,17 +843,17 @@ def activity_handle(
 
     A Local Activity writes the Workflow's stream too, while the Workflow
     Task that runs it is still open. Its attempt is not durable, so the
-    store plugin's Worker interceptor numbers each call for a producer id
-    that survives a rerun, and its first append asks the server for an
-    attempt that grows across reruns. See :meth:`ActivityStreamHandle.producer`.
+    store plugin's Worker interceptor stamps each call with a number for a
+    producer id that survives a rerun, and with the facts of its Workflow
+    Task for an attempt that grows across reruns. See
+    :meth:`ActivityStreamHandle.producer`.
 
     Raises:
         StreamUnsupportedError: A standalone Activity got no run id from
             the server, or asked for ``scope="workflow"``. A Local Activity
             asked for ``scope="activity"``, since it has no server state
             that could end its stream. Or it is a Local Activity that the
-            Worker's stream interceptor did not number. Its first append
-            raises it when its History or attempts are too long to encode.
+            Worker's stream interceptor did not stamp.
         ValueError: ``scope`` is not ``"activity"``, ``"workflow"`` or
             ``None``, or no stream store is registered on the Worker's
             client.