feat(tasks): per-job profile selector — scheduled jobs have no profile association

[nesquena-hermes]

Summary

Scheduled jobs (cron tasks) have no profile association in the UI. There is no way to see which profile a job runs under, and no way to set a profile per job when creating or editing one.

Current behavior

• The "New Job" form has no profile selector field
• The job list does not show which profile each job is associated with
• Jobs inherit whichever profile the WebUI server was started with (set via config.yaml or HERMES_PROFILE env var) — this is not surfaced anywhere in the UI

Expected behavior

• The "New Job" form should include a profile selector, allowing users to choose which profile the job runs under
• The job list should display the profile for each job (at minimum as a small badge or tooltip)
• Editing an existing job should also expose the profile field

Motivation

Users with multiple profiles need control over which profile executes a scheduled job. Without this, there is no way to configure or verify profile assignment from within the UI at all — you have to know to look in config.yaml or env vars.

[nesquena-hermes]

Good feature request — this is a real gap. Cron jobs currently inherit the profile of the server process, which is invisible and uncontrollable from the UI.

What would need to change:

1. Backend: Add a profile field to the cron job data model (tasks.json or equivalent). The job runner would use this field to select the Hermes profile at execution time. If the field is absent (existing jobs), fall back to the current server-default behaviour.

2. API: The POST /api/tasks and PUT /api/tasks/<id> endpoints need to accept and persist the profile field. GET /api/tasks should return it.

3. Frontend — New Job form: Add a profile selector dropdown. The options should be populated from GET /api/profiles (or equivalent), showing available profile names.

4. Frontend — Job list: Show the profile as a small badge next to each job. If no profile is set (legacy jobs), show "default" or the server profile name.

Implementation note: The profile selector should list profiles that actually exist on disk — not a free-text field — to prevent misconfiguration. If the selected profile is later deleted, the job runner should log a warning and fall back gracefully rather than crashing.

Priority: Medium-high for multi-profile users. Low friction for single-profile setups (they'd just always see/select one option).

Leaving open for implementation. This is a full-stack feature (model + API + UI).

[Michaelyklam]

Closeout audit from current origin/master: #617 looks implemented on the WebUI side and close-ready.

Verified coverage:

• Optional per-job profile is present at the API boundary, with legacy jobs returned as profile: null so the UI can label server-default behavior without mutating old stored jobs.
• Create/update paths accept, persist, clear, and validate profile against /api/profiles; unknown profiles are rejected before persistence.
• Tasks UI loads /api/profiles, shows a Profile selector in New/Edit Job, includes profile in create/update payloads, and renders profile badges/detail rows with a server-default tooltip for legacy jobs.
• WebUI manual Run Now resolves the selected execution profile while persisting run output/metadata back to the owning cron store.
• The WebUI change shipped via the v0.51.1 release PR v0.51.1 — 11-PR contributor batch from @Michaelyklam #1681, which absorbed PR feat(tasks): add scheduled job profile selector #1674.
• Automatic scheduler profile support outside this repo is tracked by completed Kanban follow-up t_30634def and upstream Hermes Agent PR fix(cron): honor per-job profile during scheduler runs NousResearch/hermes-agent#19958.

Verification run on current upstream master (4edcb68):

env -u HERMES_CONFIG_PATH -u HERMES_WEBUI_HOST /home/michael/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_issue617_cron_profile_selector.py tests/test_cron_manual_run_persistence.py tests/test_cron_run_job_import.py tests/test_scheduled_jobs_profile_isolation.py tests/test_chinese_locale.py::test_chinese_locale_covers_english_keys tests/test_japanese_locale.py::test_japanese_locale_covers_english_keys tests/test_russian_locale.py::test_russian_locale_covers_english_keys tests/test_spanish_locale.py::test_spanish_locale_covers_english_keys tests/test_sprint3.py::test_skills_list tests/test_sprint3.py::test_skills_list_has_required_fields -q
25 passed in 2.09s

node --check static/panels.js
node --check static/i18n.js
git diff --check

Recommendation: maintainers can close this WebUI issue as shipped; keep the upstream Hermes Agent PR linked for the scheduler-daemon side.

[nesquena-hermes]

Closing as implemented — verified on origin/master:

• _handle_cron_create (api/routes.py:6906-6927) accepts profile via _normalize_cron_profile_value() and persists it via update_job(job["id"], {"profile": profile}).
• _handle_cron_update (api/routes.py:6930-6951) accepts profile updates with the same normalization, distinguishing null (clear) from absent (leave-as-is).
• Cron POST routes (/api/crons/create, /update, /delete, /run, /pause, /resume) all execute inside cron_profile_context() (api/routes.py:4300-4334), so writes go to the TLS-active profile's jobs.json.
• Scheduler-side: install_cron_scheduler_profile_isolation() (api/profiles.py:321) wraps the scheduler so each job runs under cron_profile_context_for_home(_home_for_scheduled_cron_job(job)). Legacy jobs (no profile field) fall back to server-default behavior.
• Frontend: tasks UI loads /api/profiles, shows the Profile selector in New/Edit Job, and renders profile badges/defaults on the job list.

Thanks @Michaelyklam for the closeout audit. If anything regresses, please file a fresh issue with a repro.