Implement bounded release runtime and durable native health sampler

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade

docs/evidence/2026-10-11-release-runtime/caller-bindings-observation.json

@@ -0,0 +1,10 @@
+{
+  "schema_version": "activity-core-release-caller-metadata/v1",
+  "serviceaccounts": [
+    "activity-core-eso",
+    "default"
+  ],
+  "bindings": [],
+  "secret_read": false,
+  "native_mutation": false
+}

docs/evidence/2026-10-11-release-runtime/principal-observation.json

@@ -0,0 +1,7 @@
+{
+  "schema_version": "activity-core-release-principal-observation/v1",
+  "estate_cluster_uid_verified": true,
+  "dedicated_serviceaccount_present": false,
+  "secret_read": false,
+  "native_mutation": false
+}

docs/evidence/2026-10-11-release-runtime/validation.json

@@ -0,0 +1,36 @@
+{
+  "schema_version": "activity-core-release-runtime-preparation/v1",
+  "task": "ACTIVITY-WP-0041-T03",
+  "prepared_at": "2026-10-11T21:19:23.517339+00:00",
+  "scope": "ACTIVITY-WP-0041-image-only-v1",
+  "tests": {
+    "command": "PYTHONPATH=src python -m pytest tests/test_gitops_release.py tests/test_release_broker.py tests/test_release_transport.py tests/test_release_dispatch.py tests/test_release_health.py tests/test_release_sampler.py tests/test_release_runtime.py -q",
+    "passed": 113
+  },
+  "native_acceptance": false,
+  "native_mutation": false,
+  "secret_read": false,
+  "fixture_keys_are_authority": false,
+  "source_bootstrap_starts_soak": false,
+  "native_required": [
+    "dedicated authenticated principal",
+    "exclusive Git/Kubernetes credential custody",
+    "independent signed issuer/owner acceptance",
+    "deployed continuous observer",
+    "Temporal registration",
+    "normal release and failed health rollback",
+    "revocation and denials"
+  ],
+  "coordination": {
+    "case_id": "ACT41-release-custody-2026-10-11",
+    "scenario_type": "cross_owner_wait",
+    "state": "waiting",
+    "beneficiary_workplan_id": "ACTIVITY-WP-0041",
+    "beneficiary_task_id": "ACTIVITY-WP-0041-T03",
+    "obligor_repo": "railiance-platform",
+    "obligor_intake_id": "RPF-IN-0011",
+    "blocked_on": "message-from:railiance-platform",
+    "reason": "independent owner preparation; awaiting exact owner task binding; no circular RPF48 dependency",
+    "central_projection": "not yet published"
+  }
+}

docs/release-broker.md

@@ -1,7 +1,8 @@
 # Image-only release broker core
 
 ACTIVITY-WP-0041-T03 owns this implementation. **Not activated in production.**
-The modules are not wired to a production API, worker, schedule or credential source.
+The source now includes a read-only API invariant route, sampler and explicit dedicated
+worker entrypoint. They are not deployed or wired to production custody or trusted issuers.
 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.
@@ -50,8 +51,8 @@ production credentials and live Git/ArgoCD rollback are **not** proven by these
 ## Still required before activation
 
 1. Admit and exercise the implemented transport adapter against an isolated
-   authenticated Git/Kubernetes environment. Supply the actual bounded report/schedule
-   invariant probe, pinned cluster UID and immutable credential/context configuration.
+   authenticated Git/Kubernetes environment. Deploy and verify the supplied bounded report/schedule invariant probe,
+   pinned cluster UID and immutable credential/context configuration.
    Verify the real authorization denials and restart behavior; simulated Kubernetes
    responses do not prove those. A generic repository-write token is not path enforcement.
 2. Admit the dedicated principal and credential custody through the owner lane.
@@ -89,8 +90,8 @@ Kubernetes JSON patches compare resourceVersion and spec before setting the fixe
 sync operation. Existing foreign operations are never overwritten. Root sync selects
 only activity-core; child sync never prunes. Health checks require exact revision,
 Synced/Healthy and all three deployments ready at their observed generations, plus
-a mandatory report/schedule invariant probe. That trusted callback must itself use
-bounded I/O; no production probe is supplied or implied by the fixture implementation.
+a mandatory report/schedule invariant probe. The concrete callback is `release_sampler.Probe`, with bounded fixed reads and
+the source-defined API invariant route. Its deployment remains unproven.
 Polling windows are bounded, with individual command timeout overhead possible.
 
 `release_observer.HealthObserver` records samples durably. It requires consecutive
@@ -102,8 +103,8 @@ not a claim that every instant between samples was observed. Two distant healthy
 snapshots cannot establish the interval. New observers start from their first actual
 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, production Temporal registration and isolated
+The new source entrypoints are described in [release-runtime-owner-handoff.md](release-runtime-owner-handoff.md).
+Trusted signer custody, deployed 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.
 
@@ -138,5 +139,10 @@ of delivery acknowledgements. The sink can fan out to approved evidence destinat
 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.
+`release_runtime` binds the actual transport, durable sanitized SQLite audit sink,
+immutable private custody files and independent public-key registry to this worker.
+It verifies the actual Kubernetes username and eleven allow/deny boundaries before
+starting. `release_sampler --watch` supplies 60-second durable observations, without
+backfill. Continuous deployment, native Git identity/custody, independent signed
+owner acceptance and authenticated deployment/rollback proof remain prerequisites.
+A trusted configuration file does not itself establish those facts.

docs/release-runtime-owner-handoff.md

@@ -0,0 +1,80 @@
+# Bounded release runtime owner handoff
+
+ACTIVITY-WP-0041-T03 implements the existing D2-authorized image-only scope
+`ACTIVITY-WP-0041-image-only-v1`. This source preparation does not request another
+founder decision and does not activate release authority. Platform custody remains
+independent preparation, tracked by RPF-IN-0011 rather than the dependent RPF48 gate.
+
+The fixed target is `system:serviceaccount:activity-core:activity-core-release-broker`
+on cluster UID `a553c742-0115-43d4-99a4-a5ca56fe0786`, estate IP `92.205.62.239`.
+The current native metadata observation found only `default` and `activity-core-eso`
+service accounts and no matching namespace/ArgoCD role bindings. The ESO account
+has unrelated secret projection custody and is not an interchangeable release actor.
+These observations do not attest ClusterRoleBinding absence or authenticate as a
+workload. No Secret read or credential value is part of this record.
+
+## Executable source
+
+`GET /release/health` checks the three source-defined frontend-patterns definitions,
+exact deterministic report sinks, cron/calendar schedule semantics, actual Temporal
+workflow/action arguments, queue, pause state, overlap and catch-up policy. It reads
+only the fixed definition IDs and schedule IDs; it never updates either subsystem.
+Its 15-second probe deadline and sanitized boolean result bound failures.
+
+`python -m activity_core.release_sampler --database OWNER_PRIVATE_LEDGER
+--receipt OWNER_RECEIPT --watch` polls fixed estate/Application/deployment/service
+metadata and that API route every 60 seconds. Gaps beyond 90 seconds, unavailability,
+revision changes or backwards clocks invalidate continuous observation. A fresh
+ledger starts now. Prior sync timestamps and two snapshots cannot manufacture a
+24-hour receipt. Source-only preparation does not start this observer.
+
+`python -m activity_core.release_runtime --configuration OWNER_PRIVATE_CONFIGURATION`
+starts the existing dedicated Temporal release dispatcher. The deployment-owned
+configuration requires schema `activity-core-release-runtime/v1`, `enabled: true`,
+principal `activity-core-release-broker`, exact cluster UID, private owned
+`state_directory`, `kubeconfig`, `git_config`, and `receipt_trust`. Every trust entry
+contains an independently admitted public key, principal and role set; all four
+build/review/health/retention roles are required. No private signing key or caller
+supplied credential is accepted. Config/custody drift or disabling stops subsequent
+calls. Inherited Git/Kubernetes overrides and SSH agent credentials are excluded.
+
+At startup, the actual credential must report the exact Kubernetes username and
+pass four fixed Application allow checks plus seven negative boundary checks.
+The unchanged broker then verifies five-minute signed receipts, image-only source
+and CI bounds, retention and continuous health. Git publication changes only the
+fixed child targetRevision with compare-and-swap; root synchronization selects that
+one child and child pruning stays false. Temporal input is only an already-admitted
+release ID. Durable private SQLite audit delivery is idempotent and sanitized.
+A configuration flag or fixture key does not establish native owner acceptance.
+
+## Platform preparation and acceptance
+
+Under the existing accepted scope, Platform supplies the dedicated workload identity,
+credential route and independently operated issuer custody. Fixed allowed operations
+are read-only estate/runtime metadata plus the reviewed broker's Git one-field
+publication and exact two-Application operations. Repository write credentials alone
+cannot enforce a field boundary; keep them exclusively behind this broker and prove
+real wrong-path, wrong-application, direct deployment, secret-read, RBAC, exec and
+revocation denials. Do not reuse workstation admin or ESO credentials. The runtime
+checks Kubernetes identity, but native Git push identity and custody require owner
+acceptance evidence before deployment.
+
+Acceptance must bind exact source/runtime digests, principal/credential custody,
+independent issuers, observer process and durable ledger, real Temporal registration,
+one normal release and one failed-health rollback, restart/concurrency/denial and
+revocation receipts. The separately admitted signed owner acceptance must use the
+existing ACTIVITY-WP-0041-T03 scope and expire within five minutes. Platform's
+`docs/activity-core-release-admission.md` and readiness gate define this contract.
+No evidence is self-signed by this worker. RPF-WP-0036-T03 covers backup freshness,
+so it is not a substitute release-custody dependency.
+
+Abort owner is activity-core for a candidate/invariant/dispatch failure and
+railiance-platform for custody/authentication or native Git/Argo admission failure.
+Stop before publication when identity, source or admission is uncertain. After
+publication, preserve the durable release row; the admitted broker reverses the
+one-field pin to its retained rollback revision and performs the same targeted,
+non-pruning sync. Failed rollback retains its active slot for recovery. No direct
+Deployment or broad root operation is a recovery shortcut. Disabling configuration
+halts new work; actual credential revocation and worker shutdown remain Platform
+operations. Attended admin login is orange only when a reviewed native custody
+command requires it; none has been scheduled or executed in this preparation.