Replace informal progress event strings (_thinking, tool.started, etc.)
with a DelegateEvent enum. The callback normalises incoming legacy
strings through _LEGACY_EVENT_MAP. External consumers (gateway SSE,
ACP adapter, CLI) continue to receive legacy string names during the
deprecation window — no consumer changes required.

Raise _DEFAULT_MAX_CONCURRENT_CHILDREN from 3 to 5. Add an absolute cap
of 8 (aligned with OpenClaw's DEFAULT_SUBAGENT_MAX_CONCURRENT) — values
above 8 from config or env are clamped with a warning log.

Update schema description, cli-config.yaml.example, and delegation docs
to reflect the new defaults.

- TestDispatchDelegateTask: verifies acp_command/acp_args forwarding
  and that _dispatch_delegate_task threads messages through
- TestDelegateEventEnum: enum values, legacy map coverage, normalisation
  in the progress callback, unknown event rejection
- TestConcurrencyDefaults: default=5, cap at 8, warning log on clamp,
  env var cap, within-range passthrough
- Fix pre-existing test bug: test_task_index_prefix_in_batch_mode was
  passing tool_name as event_type (wrong signature)
- Update test_constants assertion from 3 to 5

Extract duplicated cap-check logic from _get_max_concurrent_children
into _clamp_concurrency helper. Fix stale "default 3" comment in the
schema. Simplify test_acp_args_forwarded assertion.

… enum members

Add test_progress_callback_normalises_thinking (both _thinking and
reasoning.available), test_progress_callback_tool_completed_is_noop.
Document that TASK_SPAWNED/COMPLETED/FAILED are reserved for M3.
Rename test_progress_callback_normalises_legacy_events for clarity.

Grep found 4 more places still saying "up to 3" — schema description,
tips.py, delegation-patterns.md, overview.md. Updated to match new
default of 5 (max 8).

…tring

The `messages` kwarg was threaded through `_dispatch_delegate_task` into
`delegate_task` but never referenced inside the function body. Readers
(including reviewers) kept assuming parent conversation history was being
forwarded to child agents, which it is not. Remove the dead parameter and
the test that asserted forwarding so the code matches the behavior.

Also rephrase `_dispatch_delegate_task`'s docstring: the consolidation
gives us a single call site, not automatic param forwarding — new schema
fields still need to be added in one place.

delegation.default_toolsets was declared in cli.py's CLI_CONFIG default
dict and documented in cli-config.yaml.example, but never read: none of
tools/delegate_tool.py, _load_config(), or any call site ever looked it
up. The live fallback is the DEFAULT_TOOLSETS module constant at
tools/delegate_tool.py:101, which stays as-is.

hermes_cli/config.py's DEFAULT_CONFIG["delegation"] already omits the
key — this commit aligns cli.py with that.

Adds a regression test in tests/hermes_cli/test_config_drift.py so a
future refactor that re-adds the key without wiring it up to
_load_config() fails loudly.

Part of Initiative 2 / M0.5.

Matches the default-config removal in the preceding commit.
default_toolsets was documented for users to set but was never actually
read at runtime, so showing it in the example config and the delegation
user guide was misleading.

No deprecation note is added: the key was always a no-op, so users who
copied it from the example continue to see no behavior change. Their
config.yaml still parses; the key is just silently unused, same as
before.

Part of Initiative 2 / M0.5.

…config

The prior form of this test asserted on CLI_CONFIG["delegation"] after
importing cli, which only passed by accident of pytest-xdist worker
scheduling. cli._hermes_home is frozen at module import time (cli.py:76),
before the tests/conftest.py autouse HERMES_HOME-isolation fixture can
fire, so CLI_CONFIG ends up populated by deep-merging the contributor's
actual ~/.hermes/config.yaml over the defaults (cli.py:359-366). Any
contributor (like me) who still has the legacy key set in their own
config causes a false failure the moment another test file in the same
xdist worker imports cli at module level.

Asserting on the source of load_cli_config() instead sidesteps all of
that: the test now checks the defaults literal directly and is
independent of user config, HERMES_HOME, import order, and worker
scheduling.

Demonstrated failure mode before this fix:
  pytest tests/hermes_cli/test_config_drift.py \
         tests/hermes_cli/test_skills_hub.py -o addopts=""
  -> FAILED (CLI_CONFIG["delegation"] contained "default_toolsets"
     from the user's ~/.hermes/config.yaml)

Part of Initiative 2 / M0.5.

Introduces the configurable depth cap and global kill switch for the
M3 orchestrator-role feature. No behavior change on defaults:
max_spawn_depth=2 matches the legacy MAX_DEPTH=2 hard-coded value;
orchestrator_enabled=True is a no-op until M3 commit 3 wires up role.

Changes:
- tools/delegate_tool.py: _MIN_SPAWN_DEPTH, _MAX_SPAWN_DEPTH_CAP,
  _get_max_spawn_depth() (clamps to [1, 3] with warning log, mirrors
  existing _clamp_concurrency pattern), _get_orchestrator_enabled()
  with bool/string YAML coercion.  Depth guard at delegate_task
  now reads _get_max_spawn_depth() instead of MAX_DEPTH directly.
  MAX_DEPTH stays as the hardcoded default fallback and test import.
- hermes_cli/config.py: DEFAULT_CONFIG["delegation"] seeds the two
  new keys.  Not seeded in cli.py:CLI_CONFIG — follows the
  delegation.reasoning_effort precedent; cli.py's deep-merge picks
  up user overrides regardless.
- tests/tools/test_delegate.py: TestMaxSpawnDepth (4 cases —
  default, clamp-low, clamp-high, invalid-falls-back).

Wires the 'role' param through schema -> delegate_task() -> dispatch ->
_build_child_agent -> stashed on child. No behavior change yet: Commit 3
adds the toolset re-add + role-aware prompt. Commit 2 verifies the
plumbing reaches the child and the schema description signals the
feature to the parent LLM.

Changes:
- tools/delegate_tool.py:
  - Module-level _normalize_role(r) (near _clamp_concurrency), returns
    'leaf' or 'orchestrator'; unknown strings warn and coerce to 'leaf'.
  - DELEGATE_TASK_SCHEMA: new 'role' property at top level AND per-task
    under tasks[].items.  Top-level description text split into leaf vs
    orchestrator capability statements so the parent LLM discovers that
    role='orchestrator' unlocks nested delegation.
  - delegate_task(): accepts role=Optional[str]; normalises top_role;
    single-task dict at :738 now includes 'role' for batch/single
    uniformity; child-build loop resolves effective_role = normalise(
    t.get('role') or top_role) and forwards to _build_child_agent.
  - _build_child_agent(): accepts role='leaf' kwarg; stashes
    child._delegate_role for introspection (commit 3 will overwrite
    with effective_role post-degrade).
  - Registry handler lambda: forwards role=args.get('role') for the
    Atropos dispatch path (dead for run_agent.py which short-circuits
    to _dispatch_delegate_task).
- run_agent.py:_dispatch_delegate_task: forwards role through to
  tools.delegate_tool.delegate_task.
- tests/tools/test_delegate.py:TestOrchestratorRoleSchema (4 cases —
  default→leaf, explicit orchestrator stashed, nonsense→leaf+warning,
  schema shape assertions for top-level and per-task 'role' properties).

The behavior change. Orchestrator children (role='orchestrator',
allowed by delegation.orchestrator_enabled and child_depth <
max_spawn_depth) retain the 'delegation' toolset and receive a
role-aware system prompt derived from OpenClaw's buildSubagentSystemPrompt
canSpawn branch. Leaf children are unchanged from pre-M3 behavior.

Changes:
- tools/delegate_tool.py:
  - _build_child_agent: role resolution block at the top — computes
    child_depth, max_spawn, orchestrator_ok (kill switch AND depth),
    effective_role (single degrade point).  Toolset re-add appends
    "delegation" when effective_role == 'orchestrator' (runs after the
    existing _strip_blocked_tools branches — unconditional on parent
    toolset membership since orchestrator capability is granted by role
    not inheritance; documented in test_intersection_preserves_delegation_bound).
    child._delegate_role now stashes effective_role (post-degrade).
  - _build_child_system_prompt: new role/max_spawn_depth/child_depth
    kwargs; leaf prompt unchanged; orchestrator appends a spawning
    block with WHEN/WHEN NOT to delegate guidance + literal depth
    note that branches between "children MUST be leaves" (at the
    floor) and "children can themselves be orchestrators" (below it).
    Per-call role model means "can be", not "will be" — orchestrators
    explicitly pass role='orchestrator' for nested delegation.
  - _EXCLUDED_TOOLSET_NAMES: comment explaining the "delegation"
    entry is an advertising exclusion, not a runtime block; the
    role-driven re-add in _build_child_agent overrides it.
- tests/tools/test_delegate.py: TestOrchestratorRoleBehavior (9 cases)
  - Role resolution: _keeps_delegation_at_depth_1,
    _blocked_at_max_spawn_depth, _enabled_false_forces_leaf
  - Prompt content: _leaf_does_not_mention_delegation,
    _orchestrator_mentions_delegation_capability,
    _at_depth_floor_says_children_are_leaves,
    _below_floor_allows_more_nesting
  - Batch + intersection: _batch_mode_per_task_role_override,
    _intersection_preserves_delegation_bound (documents design choice)

Satisfies parent plan §7 item 3 acceptance: parent delegates to an
orchestrator child, which delegates to two leaf grandchildren; results
bubble up correctly.

Mocking strategy (plan §3.6 G3 sketch): single run_agent.AIAgent patch
with a side_effect factory that keys on the child's
ephemeral_system_prompt — orchestrator prompts contain the string
"Orchestrator Role" (see _build_child_system_prompt), leaves don't.
The orchestrator mock's run_conversation recursively calls
delegate_task with tasks=[{goal:...},{goal:...}] to spawn two leaves.
This keeps the whole test in one patch context and avoids depth-indexed
nesting patterns that are fragile.

Also updates test_constants to cover the two new config getters
(_get_max_spawn_depth, _get_orchestrator_enabled) and the two new
bound constants (_MIN_SPAWN_DEPTH=1, _MAX_SPAWN_DEPTH_CAP=3), as
called for by plan §4 Commit 4.

Assertions: MockAgent called exactly 3 times (1 orchestrator + 2
leaves); orchestrator got 'delegation' in its toolset and an
orchestrator prompt; both grandchildren did NOT get 'delegation' and
received leaf prompts.

- cli-config.yaml.example: two commented-out lines in the delegation
  block advertising max_spawn_depth and orchestrator_enabled.
- website/docs/user-guide/features/delegation.md:
  - Replace "Depth Limit" section with "Depth Limit and Nested
    Orchestration": role='leaf' vs 'orchestrator' usage example,
    max_spawn_depth bounds, orchestrator_enabled kill switch, and the
    125-leaf cost warning for max_spawn_depth=3.
  - "Key Properties" bullets updated to reflect opt-in nested
    delegation and to split leaf/orchestrator capability statements.
  - Configuration YAML example: two commented-out lines for the new
    keys, matching the cli-config.yaml.example style.

Pure text; independently revertable.

Addresses the hermes reviewer finding in the M3 PR review
(.multi-agent/review-20260415-173416/reviews/hermes.md §warnings #3):
the Constraints section's "No nesting" bullet was stale against M3.

Replaces with a "Nested delegation is opt-in" bullet that mirrors the
wording already landed in website/docs/user-guide/features/delegation.md
in the M3 docs commit (55aecde).  Covers role='leaf' vs 'orchestrator',
the max_spawn_depth bound, and the orchestrator_enabled kill switch —
matching the feature doc's leaf-vs-orchestrator capability distinction.

…NousResearch#13021)

Replaces the serial for-loop in tick() with ThreadPoolExecutor so all
jobs due in a single tick run concurrently. A slow job no longer blocks
others from executing, fixing silent job skipping (issue NousResearch#9086).

Thread safety:
- Session/delivery env vars migrated from os.environ to ContextVars
  (gateway/session_context.py) so parallel jobs can't clobber each
  other's delivery targets. Each thread gets its own copied context.
- jobs.json read-modify-write cycles (advance_next_run, mark_job_run)
  protected by threading.Lock to prevent concurrent save clobber.
- send_message_tool reads delivery vars via get_session_env() for
  ContextVar-aware resolution with os.environ fallback.

Configuration:
- cron.max_parallel_jobs in config.yaml (null = unbounded, 1 = serial)
- HERMES_CRON_MAX_PARALLEL env var override

Based on PR NousResearch#9169 by @VenomMoth1.

Fixes NousResearch#9086

…in/QQ adapters

Add dm_policy and group_policy to the WhatsApp adapter, bringing parity
with WeCom/Weixin/QQ. Allows independent control of DM and group access:
disable DMs entirely, allowlist specific senders/groups, or keep open.

- dm_policy: open (default) | allowlist | disabled
- group_policy: open (default) | allowlist | disabled
- Config bridging for YAML → env vars
- 22 tests covering all policy combinations

Backward compatible — defaults preserve existing behavior.

Cherry-picked from PR NousResearch#11597 by @MassiveMassimo.
Dropped the run.py group auth bypass (would have skipped user auth
for ALL platforms, not just WhatsApp).

…iders (NousResearch#13152)

Add kimi-k2.6 as the top model in kimi-coding, kimi-coding-cn, and
moonshot static provider lists (models.py, setup.py, main.py).
kimi-k2.5 retained alongside it.

…refix

…providers

Section 3 (user-defined endpoints) added the plain ep_name to seen_slugs
but not the custom:-prefixed slug. Section 4 generates custom:<name> via
custom_provider_slug() and checks seen_slugs — since the prefixed slug
was missing, the same provider appeared twice in /model.

Register custom_provider_slug(display_name).lower() in seen_slugs after
Section 3 emits a provider, so Section 4's dedup correctly suppresses
the duplicate.

Closes NousResearch#12293.
Co-authored-by: bennytimz <bennytimz@users.noreply.github.com>

…search#13157)

Kimi's gateway selects the correct temperature server-side based on the
active mode (thinking -> 1.0, non-thinking -> 0.6).  Sending any
temperature value — even the previously "correct" one — conflicts with
gateway-managed defaults.

Replaces the old approach of forcing specific temperature values (0.6
for non-thinking, 1.0 for thinking) with an OMIT_TEMPERATURE sentinel
that tells all call sites to strip the temperature key from API kwargs
entirely.

Changes:
- agent/auxiliary_client.py: OMIT_TEMPERATURE sentinel, _is_kimi_model()
  prefix check (covers all kimi-* models), _fixed_temperature_for_model()
  returns sentinel for kimi models.  _build_call_kwargs() strips temp.
- run_agent.py: _build_api_kwargs, flush_memories, and summary generation
  paths all handle the sentinel by popping/omitting temperature.
- trajectory_compressor.py: _effective_temperature_for_model returns None
  for kimi (sentinel mapped), direct client calls use kwargs dict to
  conditionally include temperature.
- mini_swe_runner.py: same sentinel handling via wrapper function.
- 6 test files updated: all 'forces temperature X' assertions replaced
  with 'temperature not in kwargs' assertions.

Net: -76 lines (171 added, 247 removed).
Inspired by PR NousResearch#13137 (@kshitijk4poor).

…abled (NousResearch#13162)

When createForumTopic fails with 'not a forum' in a private chat,
the error now tells the user exactly what to do: enable Topics in
the DM chat settings from the Telegram app.

Also adds a Prerequisites callout to the docs explaining this
client-side requirement before the config section.

…tree isolation

Adds a _resolve_path() helper that reads TERMINAL_CWD and uses it as
the base for relative path resolution. Applied to _check_sensitive_path,
read_file_tool, _update_read_timestamp, and _check_file_staleness.

Absolute paths and non-worktree sessions (no TERMINAL_CWD) are
unaffected — falls back to os.getcwd().

Fixes NousResearch#12689.

…search#13169)

# Conflicts:
#	tests/agent/test_subagent_progress.py
#	tools/delegate_tool.py