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. Explicit image and snapshot placeholders 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 uses a fixed snapshot mount deliberately. It can prove one bounded run after acceptance; it is not a recurring publication handoff. Before enabling the daily schedule, add the owned pre-run publication/handoff within native Activity Core orchestration, or a reviewed serialized mount update with consumers quiescent. A static stale snapshot fails the freshness gate; never refresh its timestamp. The worker image's packaged Repo Manager version is still the earlier freshness CLI pin; the exporter is a publisher-side prerequisite, not falsely claimed installed there.

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.