fix(cron): honor profile wrap_response during delivery

[mzkarami]

Summary

• read cron.wrap_response from a cron job's runtime profile during delivery
• preserve scheduler-profile storage/output behavior by scoping only the delivery config lookup
• add regression coverage for profile jobs delivering raw output when their profile sets wrap_response: false

Notes

• This branch also includes two small test/catalog sync updates matching the current upstream CI regression tracked by fix(tests): repair GUI and model catalog CI regressions #36215 so the fork PR can run green against today's main.
• If fix(tests): repair GUI and model catalog CI regressions #36215 merges first, I can drop that second commit and keep this PR to the cron fix only.

Test Plan

• uv run --extra dev pytest tests/cron/test_cron_profile.py tests/cron/test_scheduler.py::TestDeliverResultWrapping tests/hermes_cli/test_gui_command.py tests/hermes_cli/test_model_catalog.py::TestManifestMatchesInRepoLists::test_in_repo_lists_match_manifest -q
• uv run --extra dev ruff check cron/scheduler.py tests/cron/test_cron_profile.py tests/hermes_cli/test_gui_command.py
• git diff --check
• Fork PR CI: fix(cron): honor profile wrap_response during delivery mzkarami/hermes-agent#3 is green

Refs #36248
Refs #36215

[tonydwb]

Review: APPROVE ✅

This is a clean, focused fix for a real bug in cron delivery.

The Problem

When a cron job runs under a different Hermes profile (via job.profile), run_job() uses _job_profile_context() to temporarily switch to that profile. However, _deliver_result() calls load_config() after the profile context has been restored, so it reads cron.wrap_response from the scheduler's config instead of the job's runtime profile config. This means profile-scoped jobs that set wrap_response: false get wrapped output they didn't ask for.

The Fix

Wrap the load_config() call inside _deliver_result() with _job_profile_context(job.get("id", "?"), job.get("profile")): — the same context manager already used by run_job(). This is a 1-line addition (+ 1 indent) in production code. Minimal, correct, no side effects.

Edge Cases Handled

• No profile on job: _job_profile_context yields None immediately → load_config() uses scheduler profile as before. Zero behavioral change for non-profile jobs.
• Exception during load: Already caught by the existing try/except block; wrap_response defaults to True (safe).
• Missing profile: _job_profile_context logs a warning, yields None → falls back to scheduler config. Safe.

Tests

42 lines of new test coverage verifying:

• Separate scheduler config (wrap_response: true) and profile config (wrap_response: false)
• After delivery, content is NOT wrapped (clean output matches)
• Environment is properly restored after delivery

The test uses the existing isolated_cron_profile_home fixture and proper mocking.

Ancillary Changes

• Two small test fixture additions in test_gui_command.py — aligning with upstream main changes (mentioned in PR body as CI compatibility fixes)
• Model catalog timestamp/version bump — harmless data sync

Verdict

Approve. This is a textbook bug fix: clear problem, minimal change, proper test, backward compatible, well-documented. No security concerns or pipe-to-interpreter patterns.

[tonydwb]

Code Review Summary

Verdict: Approved

Context

Fix for cron jobs: _deliver_result() should read cron.wrap_response from the job's runtime profile config, not the scheduler profile. This is a targeted 5-line change in cron/scheduler.py.

Review

• Correctness: Wraps load_config() in _job_profile_context() so delivery reads the job's profile config. Correct scoping — delivery is the only affected path.
• Testing: New regression test verifies the fix end-to-end with mocked delivery. GUI test patches keep CI green.
• Code quality: Minimal diff, clear intent, no edge cases exposed.

---

Reviewed by Hermes Agent

[iamfoz]

Nice fix. I've just opened #37736, which adds a per-job wrap_response override on top of this. They compose cleanly into a precedence chain: per-job (mine) > profile (this PR) > global default. My per-job None case falls through to the same global read you are correcting here, so once this merges I will rebase so the inherited value resolves from the job's profile. Flagging it so the relationship is clear to anyone reviewing either one.

[teknium1]

Thanks for the focused regression coverage. This branch predates a deliberate cron-profile design change on current main.

Problems

• The added _job_profile_context(...) call is no longer available. Commit 7d8d000b1921cb1c14aa137a41bd96203992e2c0 removed per-job cron profiles, including that helper and tests/cron/test_cron_profile.py.
• On HEAD, _deliver_result() still catches configuration-lookup exceptions at cron/scheduler.py:1446-1450; therefore a literal salvage would swallow the missing-helper NameError and leave wrapping enabled.

Suggested changes

• Please re-scope only if a mismatch reproduces under the current active-profile model. Current cron execution resolves its active profile dynamically at cron/scheduler.py:543-552, and delivery reads config at cron/scheduler.py:1447-1448.

This is an automated hermes-sweeper review.

[mzkarami]

Closing this because the affected per-job cron-profile path was removed from current main, including _job_profile_context() and tests/cron/test_cron_profile.py. The original report in #36248 was also closed after the behavior was traced to duplicate YAML keys, while current active-profile delivery already reads cron.wrap_response from the active configuration. The earlier approvals were valid for the old architecture, but the patch is no longer applicable. Thanks to everyone who reviewed and discussed it.