recomputeNextRuns() is called by ensureLoaded(forceReload) which runs
inside onTimer() before runDueJobs(). When the timer fires at (or just
after) the exact trigger time, recomputeNextRuns would call
computeNextRunAtMs(job, now) which advances nextRunAtMs to the *next*
occurrence. By the time runDueJobs() checks 'now >= nextRunAtMs', the
slot has already been advanced — the job is silently skipped.

Fix: in recomputeNextRuns, if a job's nextRunAtMs is in the past (due),
it has no runningAtMs (not currently executing), and lastRunAtMs is
before the current slot (hasn't been executed for this occurrence),
preserve the existing nextRunAtMs so runDueJobs can fire it.

This is a TOCTOU race that affects all recurring schedule types (cron
expressions, every-interval) when the timer callback runs at or just
after the scheduled time.

Adds 5 unit tests for recomputeNextRuns covering:
- Due job with no prior execution (preserved)
- Timer fires slightly late (preserved)
- Job already executed for slot (advances)
- Job not yet due (unchanged)
- Currently-running job (advances)

fix(cron): preserve nextRunAtMs for due-but-unexecuted recurring jobs

Add 6 new plugin hooks that give plugins full visibility into the agent
loop internals, enabling security/provenance, compliance, cost management,
and A/B testing plugins without modifying core data models.

New hooks:
- before_llm_call: see/modify full context before each LLM API call
- after_llm_call: intercept/filter tool calls after LLM response
- context_assembled: observe assembled context with source metadata
- loop_iteration_start/end: track agent loop recursion
- before_response_emit: final gate before response delivery

Based on RFC-PROVENANCE-HOOKS.md from openclaw-vestige.

Emit the 6 new plugin hooks from the agent loop:
- before_llm_call: wraps streamFn to intercept every LLM API call,
  allowing plugins to inspect/modify context, filter tools, or block
- after_llm_call: emitted at message_end with tool call extraction
- context_assembled: emitted on first LLM call of each turn
- loop_iteration_start/end: emitted via turn_start/turn_end events
- before_response_emit: emitted after prompt completes, before return

Uses streamFn wrapping pattern (same as cache trace + payload logger)
and AgentEvent subscription for lifecycle tracking.

Comprehensive tests for all 6 new agent loop observability hooks:
- hooks.extended.test.ts: unit tests for hook runners (dispatch,
  merge, block, error handling, priority ordering)
- hook-stream-wrapper.test.ts: integration tests for streamFn wrapper
  (context_assembled fires once, before_llm_call fires every call,
  context modification, tool filtering, blocking, error resilience)

TypeScript strictness: CustomMessage<unknown> lacks index signature,
so direct casts to Record<string, unknown> fail. Cast through unknown
first as the canonical workaround.

Add senderId, senderName, senderIsOwner, groupId, and spawnedBy to
PluginHookAgentContext. These fields are already available in the run
params but were not forwarded to plugin hooks.

This enables plugins to classify initial trust based on who sent the
message and what channel it came from:
  - senderIsOwner=true in DM → trust: owner
  - senderIsOwner=false → trust: external or shared
  - groupId set → group chat context (may contain external messages)
  - spawnedBy set → sub-agent session
  - messageProvider=undefined → system event (cron, heartbeat)

…all sites

The hookAgentCtx construction in attempt.ts already read these fields from
params, but three runner call sites weren't forwarding them:
- agent-runner-execution.ts (main reply)
- agent-runner-memory.ts (memory flush)
- followup-runner.ts (followup runs)

This caused senderIsOwner to always be undefined in plugin hooks,
making initial trust classification fall through to 'untrusted'.

…through all call sites

The FollowupRun.run type was missing senderIsOwner and spawnedBy,
causing TypeScript errors when forwarding these fields to
runEmbeddedPiAgent. Added them to queue/types.ts.

…und messages

Previously, the before_response_emit hook result was only checked for
block/blockReason. The content field was ignored, making content
modification impossible for plugins.

Now when a plugin returns modified content, it is applied to both the
messagesSnapshot and the active session messages so the delivery pipeline
picks up the change. This enables use cases like the provenance plugin's
developerMode taint headers.

Feature/extended security hooks

…lper

- Make latencyMs, pendingToolResults, newMessagesAdded optional (were hardcoded 0)
- Extract before_response_emit into hook-response-emit.ts (eliminates unsafe casts)
- Add 11 tests for extracted helper
- All 46 hook tests pass

refactor(hooks): clean up phantom fields and extract response-emit he…

Resolve 4 conflicts:
- hooks.ts: Import both our extended hooks and upstream's new hooks
- discord.ts: Keep resolveTarget, add upstream's silent param
- jobs.ts: Accept upstream's walkSchedulableJobs refactor (our TOCTOU
  guard is redundant since maintenance func only sets missing nextRunAtMs)
- attempt.ts: Keep hookAgentCtx with extended sender fields, add sessionId,
  integrate compaction timeout snapshot, keep hookEventUnsub + safer unsubscribe

Resolve 7 conflicts:
- followup-runner.ts, queue/types.ts: keep spawnedBy field (ours)
- agent-runner-execution.ts: adopt main's buildEmbeddedRunContexts/
  buildEmbeddedRunBaseParams refactor, preserve spawnedBy
- agent-runner-memory.ts: adopt main's helper refactor
- attempt.ts: keep our hookAgentCtx (richer than main's hookAgentId),
  adopt main's resolvePromptBuildHookResult, keep both our
  before_response_emit hook AND main's prompt-error entry
- discord outbound: keep our resolveTarget with session fallback,
  adopt main's webhook identity + threadId support
- server-startup.ts: take main's imports (gmail-watcher-lifecycle,
  session-dirs, write-lock)

When a channel config has top-level tokens (botToken/appToken/token)
AND named accounts in the accounts section, the default account was
excluded from listAccountIds. This meant the default account's provider
never started — only named accounts did.

This caused Slack to silently stop responding when a second Slack app
was added as a named account (e.g., accounts.tank), because the primary
bot's socket connection was never established.

Fix: check if the base channel config has its own tokens, and if so,
include DEFAULT_ACCOUNT_ID alongside named accounts.

These fields were defined in RunEmbeddedPiAgentParams and populated by
callers (agent-runner-execution, followup-runner) but never forwarded
from run.ts to runEmbeddedAttempt(). This meant plugin hooks (including
provenance) always received senderId=undefined and senderName=undefined,
making trustedSenderIds classification dead code.

Also adds the fields to CompactEmbeddedPiSessionParams so compaction
preserves sender identity for plugin hooks.

Adds sessionKey to PluginHookMessageContext so plugins can correlate
outbound messages with their originating session. This enables the
provenance plugin to inject taint headers on messages sent via the
message tool (not just native response emit).

… start thread

…articipant

fix(slack): implicit thread mention when bot participated but did not…

… start thread

Previously, the implicit thread mention logic only triggered when
parent_user_id matched the bot's user ID (i.e., the bot authored the
parent message). This meant that when a user @mentioned the bot in a
channel and the bot replied in a thread, subsequent thread replies
without @mention were silently dropped.

Now uses a two-tier check:
1. Check if a thread session exists (cheap file read) — covers
   subsequent turns after the first thread exchange.
2. If no session, check Slack API conversations.replies for bot
   participation — covers the first follow-up where the bot replied
   but no thread session was created (bot's own reply is dropped as
   a self-message).

Both checks are gated on requireMention being true to avoid unnecessary
API calls in channels that don't require mentions.

Adds three tests:
- Thread reply processed when bot has existing thread session
- Thread reply processed when bot replied but no thread session exists (API fallback)
- Thread reply skipped when bot never participated and requireMention=true

…ation

Heartbeats set Provider='heartbeat' but OriginatingChannel='discord'
(the delivery channel). resolveOriginMessageProvider prefers
OriginatingChannel, so messageProvider becomes 'discord' — hiding
the true origin from security plugins.

Add sourceProvider field that preserves the original Provider value
(e.g. 'heartbeat', 'cron-event', 'exec-event') through the full
chain: get-reply-run → run params → attempt hookCtx → followup runner.

Security plugins can now check sourceProvider to distinguish internal
system messages from real user messages on the same channel.

All browser server routes that operate on a specific tab now consistently
include `url: tab.url` in their JSON response. Previously only snapshot,
screenshot, pdf, click, resize, and evaluate included the page URL —
other act kinds (type, press, hover, drag, select, fill, wait, etc.)
and console omitted it.

Consistent URL metadata in tool responses enables security plugins and
future OpenClaw features to track which page a browser action targeted,
improving auditability and enabling per-domain policy decisions without
requiring a separate tab-info query.

The withRouteTabContext wrapper now automatically injects the resolved
tab's targetId and current page URL into every successful JSON response
(ok: true).  Existing explicit values are preserved — the wrapper only
fills in missing fields.

This ensures all browser actions that target a specific tab consistently
surface page metadata without requiring each route handler to manually
include it.  Security plugins and audit tooling can rely on
result.details.url to know which page was acted upon, enabling
per-domain policy decisions and improved observability.

The pattern generalizes: any tool framework that resolves an indirect
reference (like a tab ID) to a concrete resource (like a URL) can
adopt the same wrapper approach to surface resolved metadata.

…RL changes from Chrome extension

Part A (core wrapper): withRouteTabContext now queries the actual page URL
via Playwright's page.url() instead of relying solely on the relay's cached
tab.url. This corrects stale URL metadata when users navigate in the browser
without triggering a relay cache refresh.

Part B (Chrome extension): Add chrome.tabs.onUpdated listener that pushes
Target.targetInfoChanged to the relay when a connected tab's URL changes.
This handles same-site navigations and pushState changes where the debugger
stays attached and the detach/re-attach cycle never fires.

- Remove 21 console.log('[inbound-timing]') dev profiling statements
- Fix hook test: update priority-based assertions to registration-order (FIFO)
- Remove stale priority fields from test registrations
- Downgrade hot-path log.info to log.debug in hook-response-emit
- Replace IIFE with plain let/if in hook-stream-wrapper tool filtering
- Remove redundant FIFO comment in triggerInternalHook
- Fix lint: remove unused imports (beforeEach, isCronSessionKey), use unknown cast