Implement scoped Git Argo transport and gap-sensitive health observer

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e241-8285-7a63-8c0c-51c9cb824dc3

docs/release-broker.md

@@ -42,19 +42,18 @@ Failed rollback retains the active slot. Retried publication/sync must be
 idempotent, using compare-and-swap and accepting already-at-target as success.
 The adapter must refuse any unexpected third revision rather than overwriting it.
 
-Tests use generated fixture keys and an in-memory adapter. They prove policy and
-state-machine behavior, including restart and failed-health rollback; they are
-**not** proof of production Git/ArgoCD rollback or admitted authority.
+Tests use generated fixture keys, disposable real Git repositories and a simulated
+Kubernetes transport. They prove signed admission, real Git publication/rollback,
+concurrent-writer rejection and lost-push-response recovery. Kubernetes authorization,
+production credentials and live Git/ArgoCD rollback are **not** proven by these fixtures.
 
 ## Still required before activation
 
-1. Implement and verify an authenticated transport adapter that resolves exact
-   source commits, compares rendered manifests to the signed hashes, publishes
-   only the platform child revision field, and runs the fixed selective syncs.
-   Every network operation needs a bounded timeout; health must wait within that
-   bound for the exact revision and verify deployments, report sink and schedules.
-   It must persist/recover the platform commit across lost responses and serialize
-   with other writers. A generic repository-write token is not path enforcement.
+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.
+   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.
    ArgoCD Core has no API-server token lane. Kubernetes Application patch RBAC
    alone cannot restrict fields: keep it behind the reviewed broker boundary.
@@ -70,3 +69,40 @@ state-machine behavior, including restart and failed-health rollback; they are
 
 Platform enforcement contract: `railiance-platform/docs/activity-core-release-admission.md`.
 These requirements remain live work in ACTIVITY-WP-0041-T03 and RPF-WP-0048-T02.
+
+
+## Transport and observer implementation
+
+`release_transport.GitArgoBackend` retrieves both full source commits from the fixed
+activity-core repository and compares parsed manifest hashes with the admitted
+binding. It accepts only the audited static `runtime.yaml` Kustomization; proposed
+source cannot execute a renderer/plugin. Git publication creates a commit changing
+only the platform child revision field. Non-force pushes reject concurrent branch
+advances. After a lost response, remote Git is the durable source of truth: a retry
+accepts already-at-target and selective sync uses the current verified platform tip.
+Unexpected third revisions and unrelated changed paths stop the operation.
+
+The adapter verifies the operator-pinned kube-system namespace UID before Git
+publication or Kubernetes access. Context/credentials must remain immutable during
+its lifetime. Every subprocess is non-shell, with timeouts and sanitized failures.
+Kubernetes JSON patches compare resourceVersion and spec before setting the fixed
+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.
+Polling windows are bounded, with individual command timeout overhead possible.
+
+`release_observer.HealthObserver` records samples durably. It requires consecutive
+healthy samples of one revision with gaps no greater than 90 seconds. Failed samples,
+revision changes and missed samples reset the interval; clock regression durably
+invalidates it. Attestation requires a complete 24-hour sampled interval and a fresh
+last sample, including after restart. This is evidence at a bounded sampling cadence,
+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, Temporal dispatch and isolated
+Kubernetes authorization/rollback tests remain required before activation. Production
+revision and the deployment observation clock are unchanged by this source-only work.