Complete release dispatch groundwork and mark remaining work blocked

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e429-436c-73f1-9144-bac4336c06e8

docs/release-broker.md

@@ -1,7 +1,7 @@
 # Image-only release broker core
 
 ACTIVITY-WP-0041-T03 owns this implementation. **Not activated in production.**
-The new modules are not wired to an API, worker, schedule or credential source.
+The modules are not wired to a production API, worker, schedule or credential source.
 Construction requires `admitted=True` from trusted deployment configuration; that
 switch is a local guard, not proof that an identity has actually been admitted.
 The current deployed revision is unchanged, so this code does not restart soak.
@@ -62,8 +62,8 @@ production credentials and live Git/ArgoCD rollback are **not** proven by these
    custody/rotation. The observer must measure continuous health; it must not
    manufacture a 24-hour interval from two snapshots. Preserve signing public
    keys for audit and protect the ledger from producer writes.
-4. Connect the durable dispatcher through activity-core/Temporal and sanitized
-   evidence sinks. Prove authenticated transport failure, concurrency with other
+4. Deploy/register the implemented Temporal dispatcher and supply its bounded,
+   idempotent sanitized evidence sink. Prove authenticated transport failure, concurrency with other
    publishers, restart, denial and rollback in an isolated deployment environment.
    Then finish the production observation gate and enable the bounded scope.
 
@@ -103,6 +103,40 @@ snapshots cannot establish the interval. New observers start from their first ac
 sample; they do not backfill the earlier deployment timestamp.
 
 Neither module is connected to a production schedule, endpoint or credential source.
-Trusted signer custody, real invariant probes, Temporal dispatch and isolated
+Trusted signer custody, real invariant probes, production Temporal registration and isolated
 Kubernetes authorization/rollback tests remain required before activation. Production
 revision and the deployment observation clock are unchanged by this source-only work.
+
+## Temporal dispatch and durable audit delivery
+
+`release_dispatch.ReleaseDispatchWorkflow` resumes an already-admitted release ID.
+`ReleaseActivities` binds its broker, backend factory and audit sink at trusted worker
+construction; Temporal inputs cannot supply manifests, keys, transport configuration
+or an admission flag. `release_worker` constructs a separate
+`activity-core-release-tq` worker, which the admitted deployment must explicitly run.
+It does not modify the ordinary orchestrator worker or start a workflow/schedule.
+Use a stable workflow ID such as `activity-core-release:<ledger release ID>` when
+starting it. Broker serialization remains authoritative even with duplicate dispatch.
+
+Adapter calls run outside the workflow and resume from the durable ledger after
+activity retry or restart. Failed rollback keeps the release slot and is retried
+with durable timers; continue-as-new bounds workflow history. Temporal receives
+sanitized errors rather than raw transport exceptions. Disabling the broker's
+trusted admission setting prevents subsequent activity calls; operational revocation
+still requires the admitted worker/credential lifecycle, not a workflow input.
+
+The transition ledger is also the audit outbox. Acknowledgements are persisted only
+after the configured sink returns. Delivery is at least once with stable event IDs;
+the sink must durably upsert those IDs and use bounded I/O. It receives only release
+ID, phase, time, candidate/rollback commits and the fixed application name. Sink
+credentials, signed envelopes and transport output never enter these events.
+Nonterminal sink failure retains pending events and permits recovery to proceed;
+terminal workflow completion waits for acknowledged audit delivery. One ledger is
+bound to one logical audit sink; changing sinks requires an explicit replay/migration
+of delivery acknowledgements. The sink can fan out to approved evidence destinations.
+
+Tests exercise the real ledger through the activities and validate Temporal sandbox
+construction, with in-memory transports/sinks and orchestration stubs. This does not
+prove a deployed Temporal server, real Kubernetes authorization or production sinks.
+Continuous observer scheduling, actual sink adapters, admission credentials and
+authenticated deployment proof remain activation prerequisites in T03.