fix: report immediate cron run status for depleted repeat jobs

[kibooncoll]

Summary

• Fixes manual cronjob run status reporting for repeat-limited jobs that are removed after execution.
• Adds an opt-in structured run_one_job(..., return_result=True) status snapshot for immediate-run callers.
• Preserves the default bool return behavior for scheduler callers.

Root cause

_execute_job_now previously computed execution_success by re-reading last_status from the job store after run_one_job completed.

For finite repeat jobs, mark_job_run can remove the job record as soon as the repeat limit is depleted. In the repeat=1 case, a successful run could therefore lose its post-run job record before _execute_job_now re-read it, causing the tool response to report execution_success: false even though the run output artifact showed success.

Fix

• Extend cron.scheduler.run_one_job with return_result=True to return a structured snapshot containing processed, success, status, error, and delivery_error.
• Keep the historical default bool return when return_result is omitted.
• Update tools.cronjob_tools._execute_job_now to use the structured snapshot when available.
• Retain the old post-run get_job() path as a back-compat fallback.

Tests

Command run:

• scripts/run_tests.sh tests/tools/test_cronjob_run_immediate.py tests/cron/test_run_one_job.py -v

Result:

• 16 tests passed
• 0 failed

Additional syntax check:

• python -m py_compile tools/cronjob_tools.py cron/scheduler.py tests/tools/test_cronjob_run_immediate.py tests/cron/test_run_one_job.py
• py_compile_ok

Runtime verification

Fresh patched-runtime verification covered the repeat=1 no-agent cases:

• success job 011c67e09485 -> execution_success: true
• fail job ad625b6487e7 -> execution_success: false
• empty stdout job 05102215b538 -> execution_success: true

Output artifacts:

• /home/deco/.hermes/cron/output/011c67e09485/2026-07-03_20-10-57.md
• /home/deco/.hermes/cron/output/ad625b6487e7/2026-07-03_20-10-57.md
• /home/deco/.hermes/cron/output/05102215b538/2026-07-03_20-10-57.md

Caveats

• Already-running Hermes processes may need restart/module reload before patched behavior appears in the in-process cronjob tool.
• The active session's already-loaded tool process previously showed stale false mapping, while a fresh Python process validated the patched source behavior.

Non-goals

• No scheduler persistence redesign.
• No repeat-limit semantic changes.
• No output saving or delivery flow changes.
• No recurring cron job creation.
• No CI auto-fix or merge in this task.

[natehale]

Independent rediscovery of this bug — came across it during live testing of #18565 and opened #63570 before finding yours. Closed #63570 as a duplicate.

Your approach is the better fix — capturing structured status at the source is more robust than inferring from job absence (which is what our simpler fix did). Happy to help get this merged if a review is needed.

[teknium1]

Thanks for tracing this to the status read after terminal-job removal. The current main still has that exact sequence: tools/cronjob_tools.py:639-647 calls run_one_job() and then derives success from get_job(), while cron/jobs.py:1524-1529 removes a finite-repeat record before that read.

Problems

• tests/tools/test_cronjob_run_immediate.py:62 mocks both run_one_job and get_job, so the new cases do not exercise the real mark_job_run() deletion path that triggers the bug.

Suggested changes

• Add a temp-HERMES_HOME integration regression using a real repeat=1 job and the actual run_one_job/mark_job_run chain; assert a removed successful job reports execution_success: true.

Automated hermes-sweeper review.

[teknium1]

This mocks both run_one_job and the post-run get_job() absence, so it cannot verify the actual mark_job_run() auto-deletion path that caused the regression. Please add one temp-HERMES_HOME integration case that leaves run_one_job, mark_job_run, and get_job real.