Follow-up for the helix4u easy-fix salvage batch:
- route remaining context-engine quiet-mode output through
  _should_emit_quiet_tool_messages() so non-CLI/library callers stay
  silent consistently
- drop the extra senderAliases computation from WhatsApp allowlist-drop
  logging and remove the now-unused import

This keeps the batch scoped to the intended fixes while avoiding
leaked quiet-mode output and unnecessary duplicate work in the bridge.

Extends the existing cron script hook with a wake gate ported from
nanoclaw NousResearch#1232. When a cron job's pre-check Python script (already
sandboxed to HERMES_HOME/scripts/) writes a JSON line like
```json
{"wakeAgent": false}
```
on its last stdout line, `run_job()` returns the SILENT marker and
skips the agent entirely — no LLM call, no delivery, no tokens spent.
Useful for frequent polls (every 1-5 min) that only need to wake the
agent when something has genuinely changed.

Any other script output (non-JSON, missing key, non-dict, `wakeAgent: true`,
truthy/falsy non-False values) behaves as before: stdout is injected
as context and the agent runs normally. Strict `False` is required
to skip — avoids accidental gating from arbitrary JSON.

Refactor:
- New pure helper `_parse_wake_gate(script_output)` in cron/scheduler.py
- `_build_job_prompt` accepts optional `prerun_script` tuple so the
  script runs exactly once per job (run_job runs it for the gate check,
  reuses the output for prompt injection)
- `run_job` short-circuits with SILENT_MARKER when gate fires

Script failures (success=False) still cannot trigger the gate — the
failure is reported as context to the agent as before.

This replaces the approach in closed PR NousResearch#3837, which inlined bash
scripts via tempfile and lost the path-traversal/scripts-dir sandbox
that main's impl has. The wake-gate idea (the one net-new capability)
is ported on top of the existing sandboxed Python-script model.

Tests:
- 11 pure unit tests for _parse_wake_gate (empty, whitespace, non-JSON,
  non-dict JSON, missing key, truthy/falsy non-False, multi-line,
  trailing blanks, non-last-line JSON)
- 5 integration tests for run_job wake-gate (skip returns SILENT,
  wake-true passes through, script-runs-only-once, script failure
  doesn't gate, no-script regression)
- Full tests/cron/ suite: 194/194 pass

… streamed text (NousResearch#8124)

When a streaming edit fails mid-stream (flood control, transport error)
and a tool boundary arrives before the fallback threshold is reached,
the pre-boundary tail in `_accumulated` was silently discarded by
`_reset_segment_state`. The user saw a frozen partial message and
missing words on the other side of the tool call.

Flush the undelivered tail as a continuation message before the reset,
computed relative to the last successfully-delivered prefix so we don't
duplicate content the user already saw.

…esearch#12471)

During gateway shutdown, a message arriving while
cancel_background_tasks is mid-await (inside asyncio.gather) spawns
a fresh _process_message_background task via handle_message and adds
it to self._background_tasks.  The original implementation's
_background_tasks.clear() at the end of cancel_background_tasks
dropped the reference; the task ran untracked against a disconnecting
adapter, logged send-failures, and lingered until it completed on
its own.

Fix: wrap the cancel+gather in a bounded loop (MAX_DRAIN_ROUNDS=5).
If new tasks appeared during the gather, cancel them in the next
round.  The .clear() at the end is preserved as a safety net for
any task that appeared after MAX_DRAIN_ROUNDS — but in practice the
drain stabilizes in 1-2 rounds.

Tests: tests/gateway/test_cancel_background_drain.py — 3 cases.
- test_cancel_background_tasks_drains_late_arrivals: spawn M1, start
  cancel, inject M2 during M1's shielded cleanup, verify M2 is
  cancelled.
- test_cancel_background_tasks_handles_no_tasks: no-op path still
  terminates cleanly.
- test_cancel_background_tasks_bounded_rounds: baseline — single
  task cancels in one round, loop terminates.

Regression-guard validated: against the unpatched implementation,
the late-arrival test fails with exactly the expected message
('task leaked').  With the fix it passes.

Blast radius is shutdown-only; the audit classified this as MED.
Shipping because the fix is small and the hygiene is worth it.

While investigating the audit's other MEDs (busy-handler double-ack,
Discord ExecApprovalView double-resolve, UpdatePromptView
double-resolve), I verified all three were false positives — the
check-and-set patterns have no await between them, so they're
atomic on single-threaded asyncio.  No fix needed for those.

…inuation (NousResearch#7183)

When _send_fallback_final() is called with nothing new to deliver
(the visible partial already matches final_text), the last edit may
still show the cursor character because fallback mode was entered
after a failed edit.  Before this fix the early-return path left
_already_sent = True without attempting to strip the cursor, so the
message stayed frozen with a visible ▉ permanently.

Adds a best-effort edit inside the empty-continuation branch to clean
the cursor off the last-sent text.  Harmless when fallback mode
wasn't actually armed or when the cursor isn't present.  If the strip
edit itself fails (flood still active), we return without crashing
and without corrupting _last_sent_text.

Adapted from PR NousResearch#7429 onto current main — the surrounding fallback
block grew the NousResearch#10807 stale-prefix handling since NousResearch#7429 was written,
so the cursor strip lives in the new else-branch where we still
return early.

3 unit tests covering: cursor stripped on empty continuation, no edit
attempted when cursor is not configured, cursor-strip edit failure
handled without crash.

Originally proposed as PR NousResearch#7429.

Follow-up on top of the helix4u NousResearch#6392 cherry-pick:
- reuse one helper for actionable Docker-local file-not-found errors
  across document/image/video/audio local-media send paths
- include /outputs/... alongside /output/... in the container-local
  path hint
- soften the gateway startup warning so it does not imply custom
  host-visible mounts are broken; the warning now targets the specific
  risky pattern of emitting container-local MEDIA paths without an
  explicit export mount
- add focused regressions for /outputs/... and non-document media hint
  coverage

This keeps the salvage aligned with the actual MEDIA delivery problem on
current main while reducing false-positive operator messaging.

Follow-up on top of the helix4u NousResearch#12388 cherry-picks:
- make deferred post-delivery callbacks generation-aware end-to-end so
  stale runs cannot clear callbacks registered by a fresher run for the
  same session
- bind callback ownership to the active session event at run start and
  snapshot that generation inside base adapter processing so later event
  mutation cannot retarget cleanup
- pass run_generation through proxy mode and drop stale proxy streams /
  final results the same way local runs are dropped
- centralize stop/new interrupt cleanup into one helper and replace the
  open-coded branches with shared logic
- unify internal control interrupt reason strings via shared constants
- remove the return from base.py's finally block so cleanup no longer
  swallows cancellation/exception flow
- add focused regressions for generation forwarding, proxy stale
  suppression, and newer-callback preservation

This addresses all review findings from the initial NousResearch#12388 review while
keeping the fix scoped to stale-output/typing-loop interrupt handling.

Built-in → optional-skills/:
  mlops/training/peft         → optional-skills/mlops/peft
  mlops/training/pytorch-fsdp → optional-skills/mlops/pytorch-fsdp
  mlops/models/clip           → optional-skills/mlops/clip
  mlops/models/stable-diffusion → optional-skills/mlops/stable-diffusion
  mlops/models/whisper        → optional-skills/mlops/whisper
  mlops/cloud/modal           → optional-skills/mlops/modal
  mcp/mcporter                → optional-skills/mcp/mcporter

Built-in mlops training kept: axolotl, trl-fine-tuning, unsloth.
Built-in mlops models kept: audiocraft, segment-anything.
Built-in mlops evaluation/research/huggingface-hub/inference all kept.
native-mcp stays built-in (documents the native MCP tool); mcporter was a
redundant alternative CLI.

Also: removed now-empty skills/mlops/cloud/ dir, refreshed
skills/mlops/models/DESCRIPTION.md and skills/mcp/DESCRIPTION.md to match
what's left, and synchronized both catalog pages (skills-catalog.md,
optional-skills-catalog.md).

…ousResearch#12473)

External services can now push plain-text notifications to a user's chat
via the webhook adapter without invoking the agent. Set deliver_only=true
on a route and the rendered prompt template becomes the literal message
body — dispatched directly to the configured target (Telegram, Discord,
Slack, GitHub PR comment, etc.).

Reuses all existing webhook infrastructure: HMAC-SHA256 signature
validation, per-route rate limiting, idempotency cache, body-size limits,
template rendering with dot-notation, home-channel fallback. No new HTTP
server, no new auth scheme, no new port.

Use cases: Supabase/Firebase webhooks → user notifications, monitoring
alert forwarding, inter-agent pings, background job completion alerts.

Changes:
- gateway/platforms/webhook.py: new _direct_deliver() helper + early
  dispatch branch in _handle_webhook when deliver_only=true. Startup
  validation rejects deliver_only with deliver=log.
- hermes_cli/main.py + hermes_cli/webhook.go: --deliver-only flag on
  subscribe; list/show output marks direct-delivery routes.
- website/docs/user-guide/messaging/webhooks.md: new Direct Delivery
  Mode section with config example, CLI example, response codes.
- skills/devops/webhook-subscriptions/SKILL.md: document --deliver-only
  with use cases (bumped to v1.1.0).
- tests/gateway/test_webhook_deliver_only.py: 14 new tests covering
  agent bypass, template rendering, status codes, HMAC still enforced,
  idempotency still applies, rate limit still applies, startup
  validation, and direct-deliver dispatch.

Validation: 78 webhook tests pass (64 existing + 14 new). E2E verified
with real aiohttp server + real urllib POST — agent not invoked, target
adapter.send() called with rendered template, duplicate delivery_id
suppressed.

Closes the gap identified in PR NousResearch#12117 (thanks to @H1an1 / Antenna team)
without adding a second HTTP ingress server.

Adds a maps optional skill with 8 commands, 44 POI categories, and
zero external dependencies. Uses free open data: Nominatim, Overpass
API, OSRM, and TimeAPI.io.

Commands: search, reverse, nearby, distance, directions, timezone,
area, bbox.

Improvements over original PR NousResearch#2015:
- Fixed directory structure (optional-skills/productivity/maps/)
- Fixed distance argparse (--to flag instead of broken dual nargs=+)
- Fixed timezone (TimeAPI.io instead of broken worldtimeapi heuristic)
- Expanded POI categories from 12 to 44
- Added directions command with turn-by-turn OSRM steps
- Added area command (bounding box + dimensions for a named place)
- Added bbox command (POI search within a geographic rectangle)
- Added 23 unit tests
- Improved haversine (atan2 for numerical stability)
- Comprehensive SKILL.md with workflow examples

Co-authored-by: Mibayy <Mibayy@users.noreply.github.com>

Skills are self-contained scripts — they don't need test suites in
the repo.

…skill

find-nearby and the (new) maps optional skill both used OpenStreetMap's
Overpass + Nominatim to answer the same question — 'what's near this
location?' — so shipping both would be duplicate code for overlapping
capability. Consolidate into one active-by-default skill at
skills/productivity/maps/ that is a strict superset of find-nearby.

Moves + deletions:
- optional-skills/productivity/maps/ → skills/productivity/maps/ (active,
  no install step needed)
- skills/leisure/find-nearby/ → DELETED (fully superseded)

Upgrades to maps_client.py so it covers everything find-nearby did:
- Overpass server failover — tries overpass-api.de then
  overpass.kumi.systems so a single-mirror outage doesn't break the skill
  (new overpass_query helper, used by both nearby and bbox)
- nearby now accepts --near "<address>" as a shortcut that auto-geocodes,
  so one command replaces the old 'search → copy coords → nearby' chain
- nearby now accepts --category (repeatable) for multi-type queries in
  one call (e.g. --category restaurant --category bar), results merged
  and deduped by (osm_type, osm_id), sorted by distance, capped at --limit
- Each nearby result now includes maps_url (clickable Google Maps search
  link) and directions_url (Google Maps directions from the search point
  — only when a ref point is known)
- Promoted commonly-useful OSM tags to top-level fields on each result:
  cuisine, hours (opening_hours), phone, website — instead of forcing
  callers to dig into the raw tags dict

SKILL.md:
- Version bumped 1.1.0 → 1.2.0, description rewritten to lead with
  capability surface
- New 'Working With Telegram Location Pins' section replacing
  find-nearby's equivalent workflow
- metadata.hermes.supersedes: [find-nearby] so tooling can flag any
  lingering references to the old skill

External references updated:
- optional-skills/productivity/telephony/SKILL.md — related_skills
  find-nearby → maps
- website/docs/reference/skills-catalog.md — removed the (now-empty)
  'leisure' section, added 'maps' row under productivity
- website/docs/user-guide/features/cron.md — find-nearby example
  usages swapped to maps
- tests/tools/test_cronjob_tools.py, tests/hermes_cli/test_cron.py,
  tests/cron/test_scheduler.py — fixture string values swapped
- cli.py:5290 — /cron help-hint example swapped

Not touched:
- RELEASE_v0.2.0.md — historical record, left intact

E2E-verified live (Nominatim + Overpass, one query each):
- nearby --near "Times Square" --category restaurant --category bar → 3 results,
  sorted by distance, all with maps_url, directions_url, cuisine, phone, website
  where OSM had the tags

All 111 targeted tests pass across tests/cron/, tests/tools/, tests/hermes_cli/.

Adds the Mibayy noreply email to the AUTHOR_MAP so CI attribution checks
pass for the NousResearch#3884 maps skill feat commit (7fa01fa).

…unning (NousResearch#12548)

agent.switch_model() mutates self.model, self.provider, self.base_url,
self.api_key, self.api_mode, and rebuilds self.client / self._anthropic_client
in place.  The worker thread running agent.run_conversation reads those
fields on every iteration.  A concurrent config.set key=model or slash-
worker-mirrored /model / /personality / /prompt / /compress can send an
HTTP request with mismatched model + base_url (or the old client keeps
running against a new endpoint) — 400/404s the user never asked for.

Fix: same pattern as the session.undo / session.compress guards
(PR NousResearch#12416) and the gateway runner's running-agent /model guard (PR
NousResearch#12334).  Reject with 4009 'session busy' when session.running is True.

Two call sites guarded:
- config.set with key=model: primary /model entry point from Ink
- _mirror_slash_side_effects for model / personality / prompt /
  compress: slash-worker passthrough path that applies live-agent
  side effects

Idle sessions still switch models normally — regression guard test
verifies this.

Tests (tests/test_tui_gateway_server.py): 4 new cases.
- test_config_set_model_rejects_while_running
- test_config_set_model_allowed_when_idle (regression guard)
- test_mirror_slash_side_effects_rejects_mutating_commands_while_running
- test_mirror_slash_side_effects_allowed_when_idle (regression guard)

Validated: against unpatched server.py, the two 'rejects_while_running'
tests fail with the exact race they assert against.  With the fix all
4 pass.  Live E2E against the live Python environment confirmed both
guards enforce 4009 / 'session busy' exactly as designed.

Adds two complementary GitHub PR review guides from contest submissions:
- Cron-based PR review agent (from PR NousResearch#5836 by @dieutx) — polls on a
  schedule, no server needed, teaches skills + memory authoring
- Webhook-based PR review (from PR NousResearch#6503 by @gaijinkush) — real-time via
  GitHub webhooks, documents previously undocumented webhook feature
Both guides are cross-linked so users can pick the approach that fits.

Reworks quickstart.md by integrating the best content from PR NousResearch#5744
by @aidil2105:
- Opinionated decision table ('The fastest path')
- Common failure modes table with causes and fixes
- Recovery toolkit sequence
- Session lifecycle verification step
- Better first-chat guidance with example prompts

Slims down installation.md:
- Removes 10-step manual/dev install section (already covered in
  developer-guide/contributing.md)
- Links to Contributing guide for dev setup
- Keeps focused on the automated installer + prerequisites + troubleshooting

…races (NousResearch#12555)

When a user hits /new or /resume before the previous session finishes
initializing, session.close runs while the previous session.create's
_build thread is still constructing the agent.  session.close pops
_sessions[sid] and closes whatever slash_worker it finds (None at that
point — _build hasn't installed it yet), then returns.  _build keeps
running in the background, installs the slash_worker subprocess and
registers an approval-notify callback on a session dict that's now
unreachable via _sessions.  The subprocess leaks until process exit;
the notify callback lingers in the global registry.

Fix: _build now tracks what it allocates (worker, notify_registered)
and checks in its finally block whether _sessions[sid] still points
to the session it's building for.  If not, the build was orphaned by
a racing close, so clean up the subprocess and unregister the notify
ourselves.

tui_gateway/server.py:
- _build reads _sessions.get(sid) safely (returns early if already gone)
- tracks allocated worker + notify registration
- finally checks orphan status and cleans up

Tests (tests/test_tui_gateway_server.py): 2 new cases.
- test_session_create_close_race_does_not_orphan_worker: slow
  _make_agent, close mid-build, verify worker.close() and
  unregister_gateway_notify both fire from the build thread's
  cleanup path.
- test_session_create_no_race_keeps_worker_alive: regression guard —
  happy path does NOT over-eagerly clean up a live worker.

Validated: against the unpatched code, the race test fails with
'orphan worker was not cleaned up — closed_workers=[]'.  Live E2E
against the live Python environment confirmed the cleanup fires
exactly when the race happens.

Two small races in gateway/platforms/discord.py, bundled together
since they're adjacent in the adapter and both narrow in impact.

1. on_message vs _resolve_allowed_usernames (startup window)
   DISCORD_ALLOWED_USERS accepts both numeric IDs and raw usernames.
   At connect-time, _resolve_allowed_usernames walks the bot's guilds
   (fetch_members can take multiple seconds) to swap usernames for IDs.
   on_message can fire during that window; _is_allowed_user compares
   the numeric author.id against a set that may still contain raw
   usernames — legitimate users get silently rejected for a few
   seconds after every reconnect.

   Fix: on_message awaits _ready_event (with a 30s timeout) when it
   isn't already set.  on_ready sets the event after the resolve
   completes.  In steady state this is a no-op (event already set);
   only the startup / reconnect window ever blocks.

2. join_voice_channel check-and-connect
   The existing-connection check at _voice_clients.get() and the
   channel.connect() call straddled an await boundary with no lock.
   Two concurrent /voice channel invocations could both see None and
   both call connect(); discord.py raises ClientException
   ("Already connected") on the loser.  Same race class for leave
   running concurrently with _voice_timeout_handler.

   Fix: per-guild asyncio.Lock (_voice_locks dict with lazy alloc via
   _voice_lock_for).  join_voice_channel and leave_voice_channel both
   run their body under the lock.  Sequential within a guild, still
   fully concurrent across guilds.

Both: LOW severity.  The first only affects username-based allowlists
on fast-follow-up messages at startup; the second is a narrow
exception on simultaneous voice commands.  Bundled so the adapter
gets a single coherent polish pass.

Tests (tests/gateway/test_discord_race_polish.py): 2 regression cases.
- test_concurrent_joins_do_not_double_connect: two concurrent
  join_voice_channel calls on the same guild result in exactly one
  channel.connect() invocation.
- test_on_message_blocks_until_ready_event_set: asserts the expected
  wait pattern is present in on_message (source inspection, since
  full discord.py client setup isn't practical here).

Regression-guard validated: against unpatched gateway/platforms/discord.py
both tests fail.  With the fix they pass.  Full Discord suite (118
tests) green.

…search#12546)

The stdin-read loop in entry.py calls handle_request() inline, so the
five handlers that can block for seconds to minutes
(slash.exec, cli.exec, shell.exec, session.resume, session.branch)
freeze the dispatcher. While one is running, any inbound RPC —
notably approval.respond and session.interrupt — sits unread in the
pipe buffer and lands only after the slow handler returns.

Route only those five onto a small ThreadPoolExecutor; every other
handler stays on the main thread so the fast-path ordering is
unchanged and the audit surface stays small. write_json is already
_stdout_lock-guarded, so concurrent response writes are safe. Pool
size defaults to 4 (overridable via HERMES_TUI_RPC_POOL_WORKERS).

- add _LONG_HANDLERS set + ThreadPoolExecutor + atexit shutdown
- new dispatch(req) function: pool for long handlers, inline for rest
- _run_and_emit wraps pool work in a try/except so a misbehaving
  handler still surfaces as a JSON-RPC error instead of silently
  dying in a worker
- entry.py swaps handle_request → dispatch
- 5 new tests: sync path still inline, long handlers emit via stdout,
  fast handler not blocked behind slow one, handler exceptions map to
  error responses, non-long methods always take the sync path

Manual repro confirms the fix: shell.exec(sleep 3) + terminal.resize
sent back-to-back now returns the resize response at t=0s while the
sleep finishes independently at t=3s. Before, both landed together
at t=3s.

Fixes NousResearch#12546.

…NDLERS

fix/nix

…ersion

The link regex in format_message used [^)]+ for the URL portion, which
  stopped at the first ) character. URLs with nested parentheses (e.g.
  Wikipedia links like Python_(programming_language)) were improperly parsed.

  Use a better regex, which is the same the Slack adapter uses.

… gibberish

The colored ✓/✗ marks in /tools list, /tools enable, and /tools disable
  were showing up as "?[32m✓ enabled?[0m" instead of green and red. The
  colors come out as ANSI escape codes, but the tui eats
  the ESC byte and replaces it with "?" when those codes are printed
  straight to stdout. They need to go through prompt_toolkit's renderer.

  Fix: capture the command's output and re-print each line through
  _cprint(), the same workaround used elsewhere for NousResearch#2262. The capture
  buffer fakes isatty()=True so the color helper still emits escapes
  (StringIO.isatty() is False, which would otherwise strip colors).
  The capture path only runs inside the TUI; standalone CLI and tests
  go straight through to real stdout where colors already work.

…ousResearch#9091, NousResearch#13131

- Fix duplicate 'timezone' import in e2e conftest
- Fix test_text_before_command_not_detected asserting send() is awaited
  when no agent is present in mock setup (text messages don't produce
  command output)

The inline markdown regex matched `_..._` / `__...__` anywhere, so file
paths like `browser_screenshot_ecc1c3feab.png` got mid-path italics.

Require non-word flanking (`(?<!\w)` / `(?!\w)`) on underscore emphasis
so snake_case identifiers and paths render literally, matching the
CommonMark intraword rule. `*` / `**` keep intraword semantics.

The agent emits `MEDIA:<path>` to signal file delivery to the gateway,
and `[[audio_as_voice]]` as a voice-delivery hint. The gateway strips
both before sending to Telegram/Discord/Slack, but the TUI was rendering
them raw through markdown — which is also how the intraword underscore
bug originally surfaced (`browser_screenshot_ecc…`).

At the `Md` layer, detect both sentinels on their own line:
- `MEDIA:<path>` → `▸ <path>` with the path rendered literal and wrapped
  in a `Link` for OSC 8 hyperlink support (absolute paths get a
  `file://` URL, so modern terminals make them click-to-open).
- `[[audio_as_voice]]` → dropped silently; it has no meaning in TUI.

Covers tests for quoted/backticked MEDIA variants, Windows drive paths,
whitespace, and the inline-in-prose case (left untouched — still
protected by the intraword-underscore guard).

…wn-intraword-underscore

fix(tui): markdown — guard intraword underscores + clean protocol sentinels

…tool execution (NousResearch#13205)

When /steer is sent during an API call (model thinking), the steer text
sits in _pending_steer until after the next tool batch — which may never
come if the model returns a final response. In that case the steer is
only delivered as a post-run follow-up, defeating the purpose.

Add a pre-API-call drain at the top of the main loop: before building
api_messages, check _pending_steer and inject into the last tool result
in the messages list. This ensures steers sent during model thinking are
visible on the very next API call.

If no tool result exists yet (first iteration), the steer is restashed
for the post-tool drain to pick up — injecting into a user message would
break role alternation.

Three new tests cover the pre-API-call drain: injection into last tool
result, restash when no tool message exists, and backward scan past
non-tool messages.

Three-layer defense against secrets leaking into compaction summaries:
1. Input redaction: redact_sensitive_text() on message content and tool
   call arguments in _serialize_for_summary() before sending to summarizer
2. Prompt instructions: NEVER include API keys/tokens/passwords in the
   summarizer preamble, template Critical Context section, and focus topic
3. Output redaction: redact_sensitive_text() on the summary output and
   _previous_summary for iterative updates

Reuses existing agent/redact.py patterns (sk-*, ghp_*, key=value, etc).

Cherry-picked from PR NousResearch#9200 by @entropidelic.

Adds a new gateway platform that lets Hermes act as a WhatsApp bot using the
official Meta Cloud Business API. The platform is webhook-only: it expects an
external WhatsApp MCP server to own the Meta Cloud webhook (verify handshake,
HMAC validation, contact tagging, multi-tenant routing) and forward messages
of interest to this gateway via a simple POST.

This complements the existing whatsapp.py adapter (Baileys / WhatsApp Web).
Many users run a number on Meta's official Cloud API and want a TOS-compliant
integration without giving up Hermes; this platform fills that gap.

Forward POST contract:
  POST <PATH> (default /wa)
  X-Webhook-Secret: <shared secret>
  body: {message_id, phone, type, content, ...}

The gateway responds 200 immediately so the MCP's short forward timeout (the
original Meta webhook handler must reply <5 s) is not exceeded by LLM latency;
the actual reply is sent asynchronously by send() via Meta's Graph API.

What's included:
  * gateway/platforms/whatsapp_via_mcp_meta_business_api.py - the adapter
  * gateway/config.py - Platform enum + _apply_env_overrides + _token_env_names
  * gateway/run.py - factory in _create_adapter + auth allowlists
  * agent/prompt_builder.py - PLATFORM_HINTS entry
  * toolsets.py - hermes-whatsapp-via-mcp-meta-business-api toolset
  * cron/scheduler.py - cron platform_map entry
  * tools/send_message_tool.py - send_message routing + standalone _send_*
  * tools/cronjob_tools.py - deliver schema mention
  * hermes_cli/status.py - Messaging Platforms status entry
  * hermes_cli/gateway.py - setup wizard _PLATFORMS entry
  * tests/gateway/test_whatsapp_via_mcp_meta_business_api.py - 25 tests
  * website/docs/user-guide/messaging/whatsapp-via-mcp-meta-business-api.md
  * website/docs/user-guide/messaging/index.md - platform comparison row
  * website/docs/reference/environment-variables.md - env vars table
  * README.md - feature row

Adds a callback_query routing hop that detects the "hitl:" prefix and
delegates to a new _handle_hitl_callback method. All other callbacks
(model picker mp:/mm:/mb/mx/mg:, default) flow unchanged.

The HITL handler:
- Validates identity against TELEGRAM_ALLOWED_USERS env (comma-separated
  user IDs); rejected attempts emit hitl.identity.rejected at warn and
  never write to the resolved file.
- Parses callback_data shape "hitl:<approve|reject>:<request_id>".
- Appends a single-line JSONL record to
  $ELIGIA_HITL_DIR/approvals-resolved.jsonl (default /opt/eligia/data/hitl)
  for the eligia-core langgraph workflow polling to pick up.
- Calls answerCallbackQuery so the inline-keyboard button stops spinning.

This is the multiplex implementation for Change A Phase 2b (eligia-core
docs/openspec-slice-phase5.md). Single Elig_ia_bot now serves both
Hermes conversation (existing) and ELIGIA HITL approvals (new).

The existing _handle_callback_query dispatch was extended with one
early-return branch — no other behavior changes.

Auxiliary _log_hitl_event helper appends structured audit events to
$ELIGIA_HITL_DIR/events.jsonl. Best-effort; logging failures are
swallowed to avoid blocking the callback handler.

Apply-fix-contract spec authority lives in eligia-core via the
.ai-playbook submodule pin v0.7.1 (commit 8d5f68c).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…messages

Adds a regex-based pre-check at the top of _handle_webhook that catches
"aprobar X" / "rechazar X" replies (and Spanish/English variants) from
identity-bound senders and writes the resolution directly to the shared
$ELIGIA_HITL_DIR/approvals-resolved.jsonl file, skipping the LLM.

This is the receive half of Change A Phase 3 (WhatsApp HITL) — the send
half lives in eligia-core/langgraph-aiops/channels/whatsapp.py and POSTs
to Meta Graph API directly.

Architectural notes:
- WhatsApp has no inline keyboards. The envelope body explicitly tells
  the user the exact phrases ("aprobar <id>" / "rechazar <id>"). The
  regex is permissive: aprob*, aprueb*, ✅, ok, sí, dale on the approve
  side; rechaz*, recha*, ❌, no on the reject side. Failed pattern match
  falls through to Hermes' normal LLM handler.
- Identity binding via WA_HITL_ARTURO_E164 (env, comma-separated for
  future multi-signer; single-signer in v1). DISTINCT from the
  conversational WHATSAPP_VIA_MCP_META_BUSINESS_API_ALLOWED_USERS list,
  so an HITL-bound number can be a subset of conversational-allowed.
- Non-bound senders are silently passed to the LLM (not "trying" to
  approve, just chatting normally — no audit-log noise).
- Resolution write at $ELIGIA_HITL_DIR (default /opt/eligia/data/hitl,
  same shared volume Telegram uses) keeps both channels coherent for
  the workflow polling side.
- Ack reply ("✅ Aprobado <id>" / "❌ Rechazado <id>") is sent via the
  existing self.send() so the user gets confirmation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Phase 3b of Change A. Lets the user approve/reject the most recent open
HITL envelope with a single token — no request_id needed — when an open
request exists in $ELIGIA_HITL_DIR/approvals-pending.jsonl within the
24 h staleness window.

## What changed
- Two new bare-token regexes:
    APPROVE: aprob*/aprueb*/✅/ok/si/sí/dale/yes/y/1/👍
    REJECT:  rechaz*/recha*/❌/no/nope/n/0/👎
  They match a *whole-message* token (no id required).
- Bare-token branch added to _try_parse_hitl_intent AFTER the existing
  explicit "verb + id" match. Explicit form still wins when present.
- New helper _find_most_recent_open_request_id() reads pending JSONL,
  filters out already-resolved + stale (>24 h) entries, returns the
  latest open id (or None).
- When bare-token matches but no open request exists, returns None
  → falls through to the LLM. So plain "1" or "no" without HITL context
  remain conversational with Hermes.

## Why
WhatsApp doesn't have inline keyboards. Typing the full request_id
("aprobar wa-smoke-1") feels like a CLI in a chat client. With this
change the user can reply "1" or "ok" and Hermes resolves the most
recent envelope — same UX shape as a Telegram inline-keyboard tap.

## Compatibility
- Existing "verb + id" form unchanged.
- Existing tests for that form continue to pass (still tested in
  eligia-core/tests/test_channels_whatsapp.py — the explicit pattern is
  exercised on the dispatcher side).
- Bare-token path is gated by presence of $ELIGIA_HITL_DIR/approvals-
  pending.jsonl. If the file is absent or empty, behavior is the
  pre-Phase-3b fall-through.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…n IVR convention

Phase 3b iteration. Users mentally read numbered choice lists as
"1) yes / 2) no", not as boolean integers (1/0). Switching the bare
reject regex to recognise "2" instead of "0" so the WhatsApp UX feels
natural ("aprobar = 1, rechazar = 2").

The envelope rendering side (langgraph-aiops/channels/whatsapp.py) now
prints an explicit numbered list:

    Cómo responder:
      1 — aprobar
      2 — rechazar

so the user sees the choice mapping inline; no more guessing "is 1
ok or yes?" before tapping the keyboard.

Companion change in eligia-core: channels/whatsapp.py body format +
test assertion update.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The pre-LLM HITL parser in this WhatsApp adapter was the legacy path
that detected free-form text replies like "aprobar abc-123" / "1" /
"ok" and wrote a resolution to approvals-resolved.jsonl directly.

That path is dead since 2026-05-05: eligia-core landed payload-routes
in waba-mcp (PR #1) + a /webhook/hitl endpoint on aiops (PR NousResearch#126).
WhatsApp HITL approvals now flow as Meta `interactive` button replies
whose `interactive.button_reply.id` starts with `hitl:`. waba-mcp
short-circuits the personal_hermes tag forward when the prefix matches,
sending the click directly to aiops. Hermes never sees those clicks.

Removed:
  - the pre-LLM HITL pre-check in _handle_webhook
  - _try_parse_hitl_intent
  - _find_most_recent_open_request_id
  - _write_hitl_resolution
  - _HITL_APPROVE_RE / _HITL_REJECT_RE / _HITL_BARE_APPROVE_RE / _HITL_BARE_REJECT_RE
  - _HITL_PENDING_STALENESS_HOURS
  - newly-unused imports (re, timedelta, timezone, Path, List)

Why the cleanup matters beyond dead code:
  - Security smell: any free-form text containing "aprobar" stem
    triggered a resolution attempt. Casual chat could fire approvals
    by accident if an in-flight request happened to be open.
  - Identity binding still exists at the channel boundary (waba-mcp
    routing + aiops HMAC) — tighter than env-list match here.

Telegram receive-side (`gateway/platforms/telegram.py`) is UNCHANGED.
That path uses Telegram's native inline keyboard callbacks and is
still the primary HITL channel for cron-style approvals where the
phone might be elsewhere.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>