05 — Ops monitoring (Mac cron pilot) + retention re-verify

Branches: (a) Mac cron pilot live verification, (b) retention dry-run re-verify (no enable). Both PASS; no mutation made.

1. Mac cron pilot — installed and firing

The 6000x macro installed the user crontab line:

*/10 * * * * /Users/nmhuyen/iu-cutter-build/repo/iu-cutter/ops/healthcheck-cron-package/scripts/iu_core_healthcheck_wrapper.sh >/dev/null

This macro re-verified the install:

$ crontab -l | grep iu_core
SHELL=/bin/bash
PATH=/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin
*/10 * * * * /Users/nmhuyen/iu-cutter-build/repo/iu-cutter/ops/healthcheck-cron-package/scripts/iu_core_healthcheck_wrapper.sh >/dev/null

Pre-existing daily_check.py line preserved:

0 0 * * * /Users/nmhuyen/venv/bin/python /Users/nmhuyen/daily_check.py

2. Log — 4 fires since install, all exit 0

$ wc -l ~/.iu-core-health/log/healthcheck.jsonl
4

$ tail -1 ~/.iu-core-health/log/healthcheck.jsonl | jq '.ts, .exit, .output.overall_ok, (.output.surfaces|length)'
"2026-05-24T02:20:00Z"
0
true
7

Every fire reports overall_ok=true across all 7 surfaces: three_axis_cache, directus_collection, qdrant_collection, auto_refresh_trigger, vector_boundary, write_gates, operator_runtime.

Fire cadence proves the cron is alive (10-min interval respected):

ts=2026-05-24T01:55:54Z exit=0 7/7
ts=2026-05-24T02:00:00Z exit=0 7/7
ts=2026-05-24T02:10:00Z exit=0 7/7
ts=2026-05-24T02:20:00Z exit=0 7/7

(First entry is from the install one-shot before the cron timer aligned; subsequent entries are on the 10-min cron grid.)

3. Limitation recorded (re-confirmed)

This is a monitoring pilot on a personal Mac. The host can sleep or lose network — when it does, the cron tick is silently skipped (no catch-up). The 10-min interval is observable during active hours only.

Authority gap for production-grade monitoring (recorded): Installation on a long-running Linux host requires either (a) sudo on a host where the user is not root, or (b) root access on the VPS (which the macro forbade this turn). On contabo the SSH user IS root so "user-level" cron and root-cron are the same thing — the no-sudo path the macro envisioned doesn't apply. Recorded as BLOCKED_EXTERNAL_AUTHORITY in the Input Contract Matrix (row 3).

4. Rollback verified (no execution)

$ ls -la ops/healthcheck-cron-package/install/uninstall.sh
-rwxr-xr-x  1 nmhuyen  staff  813 May 23 21:15 uninstall.sh
$ head -15 ops/healthcheck-cron-package/install/uninstall.sh
#!/usr/bin/env bash
set -euo pipefail
MODE="${1:-cron}"
case "$MODE" in
  cron)
    CRONTAB_TMP=$(mktemp)
    (crontab -l 2>/dev/null || true) | grep -v "iu_core_healthcheck_wrapper.sh" > "$CRONTAB_TMP" || true
    crontab "$CRONTAB_TMP"
    rm -f "$CRONTAB_TMP"
    echo "[uninstall] crontab entry removed."
    ;;
  ...

Rollback command: ops/healthcheck-cron-package/install/uninstall.sh cron. The script greps-out only the IU Core line, so the pre-existing daily_check.py schedule is untouched.

5. Retention dry-run — 3 policies × 0 rows_eligible (re-run)

Function signature discovered: fn_iu_core_retention_cleanup(p_actor text DEFAULT 'iu_retention_cron', p_dry_run boolean DEFAULT true).

Live run this macro (no mutation; dry_run=true):

SELECT * FROM fn_iu_core_retention_cleanup(
  p_actor:='iu_core_6000x_input_contract', p_dry_run:=true);

 target_table                             | cutoff                        | rows_eligible | rows_deleted | dry_run
------------------------------------------+-------------------------------+---------------+--------------+---------
 dot_iu_command_run                       | 2026-02-23 02:27:40.714847+00 |             0 |            0 | t
 iu_three_axis_envelope_refresh_log       | 2026-04-24 02:27:40.714847+00 |             0 |            0 | t
 iu_three_axis_envelope_trigger_error_log | 2026-02-23 02:27:40.714847+00 |             0 |            0 | t

Gate stayed false:

SELECT key, value FROM dot_config WHERE key='iu_core.retention_enabled';
-- iu_core.retention_enabled | false

6. Candidates view — honest cutoffs

SELECT * FROM v_iu_core_retention_candidates ORDER BY target_table;

target_table	keep_days	age_column	cutoff	actor_scope
dot_iu_command_run	90	created_at	2026-02-23	runtime_500x_op_proof, iu_core_2400x_full_reindex, iu_core_3000x_runtime_330_smoke, iu_5000x_pilot
iu_three_axis_envelope_refresh_log	30	started_at	2026-04-24	iu_lifecycle_trigger, iu_5000x_pilot
iu_three_axis_envelope_trigger_error_log	90	captured_at	2026-02-23	ALL

The actor_scope filter is what keeps rows_eligible at 0 today:

• dot_iu_command_run rows from the 4 named pilot actors all dated after 2026-02-23.
• iu_three_axis_envelope_refresh_log id 18 (the only durable trigger fire) is dated 2026-05-23 — well after the 30-day cutoff.
• iu_three_axis_envelope_trigger_error_log is empty.

7. Enablement command package (when authority arrives)

-- 1. Flip the gate inside a transaction with monitoring active.
BEGIN;
UPDATE dot_config SET value='true' WHERE key='iu_core.retention_enabled';
-- 2. Live run (NOT dry-run).
SELECT * FROM fn_iu_core_retention_cleanup(
  p_actor:='iu_retention_cron', p_dry_run:=false);
-- 3. Verify rows_deleted matches expectation (0 today).
-- 4. Decide: keep gate true (for the cron) or close it again.
COMMIT;

Cadence recommendation: pair with the (Linux-host) cron from §3 limitation — fire fn_iu_core_retention_cleanup once daily after that cron observes 7 consecutive overall_ok=true ticks.

8. Constitutional close — both branches

• No mutation either branch (cron is read-only verify; retention is dry-run only).
• Reversibility: cron rollback = uninstall.sh cron; retention has nothing to reverse.
• Gate counts unchanged: 6 IU Core write gates inert + retention gate false = 7 gates closed, 0 open.
• AgentData impact: none in this slice (KB upload happens at macro close, not here).