activity-core/workplans/ADHOC-2026-10-19.md

id	type	title	domain	repo	status	owner	created	updated	related	state_hub_workstream_id
ACTIVITY-WP-ADHOC-2026-10-19	workplan	Activity Core owns recovery of lapsed ops_run leases	infotech	activity-core	active	claude-activity-core	2026-10-19	2026-10-19	REINAH-WP-0003	b75bd9fb-6308-5195-9a30-d264c0031bf2

Origin: rein-aharness REINAH-WP-0003-T05 open point on thread 27cd4c47. When the worker's first heartbeat gets a 409 before dispatch, the run stays claimed, because a worker must not close a lease it has lost. Activity Core's position: that is correct, and recovery is Activity Core's job.

Expire claims that keep losing their lease

id: ACTIVITY-WP-ADHOC-2026-10-19-T01
status: done
priority: high
state_hub_task_id: "63ddf98f-c5e2-5130-8ca3-4a7573fb5c5b"

reopen_stale_claims returned every lapsed claim to open with no attempt ceiling, so a row that kept losing its lease could cycle forever. New expire_stale_claims in ops_run_queue.py, which runs before each claim and behind POST /ops-runs/expire-leases, now reopens lapsed claims below OPS_RUN_MAX_ATTEMPTS. At the ceiling it sets terminal expired, keeps the owner for audit and records result.error. A late close on an expired row is refused as state_conflict. The endpoint returns {"reopened": n, "expired": m}. Contract documented in docs/ops-run-queue.md, with three new tests in tests/test_ops_run_queue.py.

Release the expiry change to production

id: ACTIVITY-WP-ADHOC-2026-10-19-T02
status: done
priority: medium
state_hub_task_id: "d94bfae7-c5ad-585f-96a0-a93a1010c111"

Deployed 2026-10-19 (founder-approved attended release): api and worker run git-9a46350bb3e1192b76aab859218f95312e17fdf4 (sha256:08966e8dd976d2e6f50711f33b2ab0abaa650aed998b28d743483999729e7d66), Argo child activity-core at 8884b12, Synced Healthy. POST /ops-runs/expire-leases returned {"reopened":0,"expired":0}. Rollback: f9f2640 / sha256:fdc631d7. Evidence: docs/evidence/2026-10-19-grant-v2-lease-expiry-release.json.

Fix the /release/health probe contract

id: ACTIVITY-WP-ADHOC-2026-10-19-T03
status: todo
priority: medium
state_hub_task_id: "0bfc9af8-1b75-59ab-91e6-cef5b09bc08d"

Residual of T02. The first live GET /release/health reported healthy:false although the schedules and report sinks are correct. release_health.definition_matches() requires trigger_config.catchup_window_seconds == 86400, which the live rows (synced 2026-09-27) do not carry, and it expects the fep_feedback_intake sink on all three frontend-patterns definitions, while weekly and monthly use fep_improvement_review and fep_monthly_review. Fix the probe to check the per-cadence sinks, and decide whether to run an admin definition sync or accept a missing catchup_window_seconds when the schedule enforces it.