# 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/` 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 `/` and `/inputs/.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.