activity-core/k8s/custodian-release

Existing-worker Custodian delivery candidate

User selected the existing Activity Core worker. This directory prepares that choice; it is not referenced by active k8s/gitops/kustomization.yaml. Neither schedule is enabled. The patch adds no CPU/memory request or separate process. The source Dockerfile now embeds the four fixed owner scripts and checks their actual bytes during build. Source pin is in commands/manifest.json; do not infer deployed bytes from Git HEAD. A new image digest is required.

worker-patch.yaml is a strategic-merge review artifact preserving existing env, volumes and resources. It reuses actcore-ops-artefacts with two narrowly scoped subPaths: private state and a selected immutable snapshot. The explicit image placeholder must be replaced with real accepted evidence. Do not apply this file directly. Review its merged diff and render through owner GitOps after source/image acceptance. No Kubernetes resources were read or changed here.

input-policy.json holds tunable defaults: 2-hour Forge observation age, 5-minute clock tolerance, exact 15-repo set, 64MiB snapshot bound, recommended 35-day daily and 13-bundle weekly retention. Retention settings are policy for owner review, not an installed pruning job. Referenced evidence must survive pruning. Consumer admission enforces observation age, clock tolerance, scope, hashes and size; it ignores the exporter's unverified observation claim and instead requires independent existing Repo Manager receipts for each pinned commit. A recent forge_head_matches_last_success noop is valid re-observation; an old commit can remain current. Applied/reconciled rows must bind expected/derived/projected commits. Receipt files are trusted protected owner evidence, not signed proofs.

Concrete publisher contract

Repo Manager commit 3e2726f adds offline python -m repo_manager.fleet_snapshot; its docs/custodian-fleet-input-contract.md defines input request, publication and recommended ownership. It does not fetch objects or establish remote freshness. Export selected verified Forge commits from the existing approved repository object stores, retain the complete matching receipt rows as a JSON array, and copy the completed immutable tree to custodian/snapshots/<id> on the claim. Only workplans/decisions are admitted. Do not fetch credentials into the worker.

The candidate mounts the snapshot parent read-only. Each run reads one regular inputs/current.json descriptor under private state with schema activity-core.custodian-snapshot-selection.v1, snapshot_id, manifest_sha256, and receipts_sha256. It selects only <snapshot-root>/<snapshot_id> and <state>/inputs/<snapshot_id>.receipts.json, validates both digests and then the full freshness/content contract. Snapshot IDs permit no traversal or symlinks. The receiver must finish and retain both artifacts, then atomically replace the regular descriptor file. A run keeps its selected immutable paths; subsequent runs see the next descriptor without a Deployment change. Never alter selected artifacts or prune snapshots referenced by in-flight runs.

Descriptor selection is implemented locally; remote capture/transport is not. The packaged Repo Manager version remains the earlier freshness CLI pin; the new targeted refresh/export source is a publisher-side prerequisite, not falsely claimed installed in that image. See publisher-access-delta.md for the exact existing producer and proposed network/data-access change.

Required preflight and verification

1. Review/build the new Activity Core image and verify actual installed package and scripts in it. Run python /app/scripts/verify_custodian_bundle.py --root /opt/custodian-commands --expected-revision 60d893af1bf77f457504b64ff1c9ffb5c6ae6579. Expected manifest SHA-256: 8fddc3e90fe90992de2369cb4354ee43d9d25352e958ee371a702dc974f1df1f. Inspect the installed activity_core.custodian_inputs and operations module hashes against this reviewed build too; old editable installs are insufficient.
2. Verify current shared-claim capacity, backups and ownership before populating any input/state. Precreate custodian/state and required children owned by UID1000, mode0700; never change the entire claim. Measure actual snapshot footprint against retention before accepting this existing claim. Insufficient capacity is a source/storage prerequisite; do not silently increase spending.
3. Freeze a complete snapshot plus its independent fresh receipt JSON and the weekly owner request/real collector inputs. Mount the snapshot read-only; protect state inputs from concurrent writers. Verify every manifest hash and owner receipt at runtime. Owner-approved source publication expands readable work-record scope to the explicit repos only; it grants no secret/credential access and should be reviewed as that exact data-access delta.
4. Confirm existing direct Hub admission for decision GET/resolve, message POST and progress sink. Source URL alone proves neither authorization nor delivery. Keep configured recipients and owner accountability. No edge-relay queued result can substitute for a central message ID.
5. Review resulting Deployment diff, current CPU/headroom and rollout policy. No added requests are proposed. Existing rolling surge still needs current headroom; verify available capacity rather than assuming this source's empty requests justify extra capacity. Keep schedules disabled/paused throughout.
6. Offline fixture tests precede any separately reviewed bounded real run. Verify missing/stale snapshot rejection before subprocess and collect operation, report, sink and owner acknowledgment evidence. First unattended proof remains an acceptance task, not a source-test result.

Existing standing authorization can cover non-destructive owner deployment when the reviewed diff, dry-run, rollback, abort owner and receipt are concrete. This packet does not invent a blanket new founder gate. Changes to access scope, credentials, public publication or spending limits retain their own authority requirements; root reviews this exact candidate before deployment.

Rollback restores prior image and mount/env source through GitOps, keeps schedules paused, and preserves state/checkpoints/old bundles and snapshots. Daily Hub writes cannot be undone by rollback. Inspect delivery checkpoints before retries. The Activity Core runtime owner is the proposed abort/recovery owner; identify the actual operator in the deployment receipt before applying.