activity-core/k8s/custodian-release/RESTART.md

Runtime delivery checkpoint — 2026-10-19

User requested wind-down. No deployment, credential read, network-policy apply or schedule activation occurred. Both daily and weekly definitions stay disabled.

Committed prerequisites: Activity Core fed119a (pinned image bundle, required freshness admission), 3b25aea (immutable descriptor selection); Repo Manager 3e2726f (offline exporter), 510ba0b (targeted freshness).

Latest source preparation adds Repo Manager's opt-in fixed-policy snapshot endpoint and Activity Core's standalone custodian_capture.py receiver. The endpoint defaults disabled, reuses the publisher's existing Forge credential, and accepts no caller repository/ref/path/command. Receiver validates and retains a complete captured bundle before replacing its regular descriptor. It is NOT wired into the daily operation or definition. The deployment candidate therefore does NOT deliver recurring captures yet. No new API or secret is live.

Validation already performed: Repo Manager publisher/capture/freshness/exporter tests: 47 passed (one existing Starlette/httpx deprecation warning). Activity Core receiver + prior focused tests: 79 passed / 1 failed when a second bounded stage was temporarily added. Failure was the owner's explicit one-operation-per- definition contract. That unsupported wiring was removed entirely from registry, activity dispatch, definition and expected registry test. Do not reintroduce it. The four standalone receiver tests passed within that run. Earlier descriptor checkpoint: 76 focused tests passed. See final checkpoint report for the minimal post-removal check. No container build or runtime acceptance is claimed.

Restart work:

1. Inspect clean Git state and actual installed source bytes before promotion. Review endpoint/receiver source and run lint plus focused tests before extending.
2. Preserve the single bounded operation. Integrate capture as a fixed pre-run phase only with a defensible shared timeout: proposed <=45 seconds capture plus <=240 seconds owner command within existing300-second Temporal envelope. Current standalone HTTP client has250-second per-I/O timeout and publisher budget240 seconds; these are NOT suitable for that combined envelope yet.
3. Prove cancellation/deadline behavior. Current endpoint's process-local lock refuses concurrent capture with409 but HTTP disconnect does not cancel its synchronous owner work, and lock state is not durable/across replicas. Define retained in-progress receipt/retry behavior or stop producer work; do not claim this solved. Measure actual15-repo capture completion, fail on partial coverage, never silently widen freshness age/timeouts to hide it.
4. Complete reviewed transport placement. Existing core-hub publisher endpoint has no adopted NetworkPolicy ingress from Activity Core or Hub egress. The precise downstream15-repo private workplan/decision disclosure and port8020/ Hub8000 delta is in publisher-access-delta.md; no live approval is implied. Prepare actual wrapper manifests only after that exact review. Preserve CCR0031 identity/namespace; do not add a worker Forge credential.
5. Receiver requires a writable snapshot path. Current candidate mounts the snapshot parent read-only for commands; it has no receiver write alias/binding. Review a narrow publisher-output mount and verify both paths refer to the same retained store before wiring. Keep private state0700 and immutable names.
6. Update Dockerfile test list if receiver becomes integrated. Current pinned package/descriptor tests are included; standalone receiver test is not yet added to image-stage tests. Rebuild immutable image and verify mounted bytes.
7. Only after source/runtime review: storage capacity/backup, scoped network admission, rollout headroom/rollback/abort owner, then separate first-run and unattended receipts. Retention settings remain recommended policy; no pruning is installed. Weekly collector coverage and acceptance remain separate.

Endpoint fixed payload cap is8MiB (consumer snapshot policy64MiB upper bound), response cap16MiB; neither is a measured production requirement. These fail closed and need owner sizing evidence. Runtime source has no new resource requests.