Add workspace context (IDENTITY.md, AGENTS.md, etc.) to gateway webhook
and WhatsApp message handlers by using chat_with_system() with a
build_system_prompt()-generated system prompt instead of simple_chat().
This aligns gateway behavior with other channels (Telegram, Discord, etc.)
and the agent loop, which all pass system prompts via structured
ChatMessage::system() or chat_with_system().
Changes:
- handle_webhook: build system prompt and use chat_with_system()
- handle_whatsapp_message: build system prompt and use chat_with_system()
Risk: Low - uses existing build_system_prompt() function, no new dependencies
Rollback: Revert commit removes system prompt enrichment
Add comprehensive e2e test coverage for chat_with_history and RAG
enrichment pipeline:
- RecordingProvider mock that captures all messages sent to the provider
- StaticMemoryLoader mock that simulates RAG context injection
- e2e_multi_turn_history_fidelity: verifies growing history across 3 turns
- e2e_memory_enrichment_injects_context: verifies RAG context prepended
- e2e_multi_turn_with_memory_enrichment: combined multi-turn + enrichment
- e2e_empty_memory_context_passthrough: verifies no corruption on empty RAG
- e2e_live_openai_codex_multi_turn (#[ignore]): real API call verifying
the model recalls facts from prior messages via chat_with_history
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The OpenAI Responses API requires assistant messages to use content type
"output_text" while user messages use "input_text". The prior implementation
used "input_text" for both roles, causing 400 errors on multi-turn history.
Extract build_responses_input() helper for testability and add 3 unit tests
covering role→content-type mapping, default instructions, and unknown roles.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Both providers only implemented chat_with_system, so the default
chat_with_history trait method was discarding all conversation history
except the last user message. This caused the Telegram bot to lose
context between messages.
Changes:
- OpenAiCodexProvider: extract send_responses_request helper, add
chat_with_history that maps full ChatMessage history to ResponsesInput
- GeminiProvider: extract send_generate_content helper, add
chat_with_history that maps ChatMessage history to Gemini Content
(with assistant→model role mapping)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the non-functional OpenAI-compatible stub with a purpose-built
Bedrock provider that implements AWS SigV4 signing from first principles
using hmac/sha2/hex crates — no AWS SDK dependency.
Key capabilities:
- SigV4 authentication (AKSK + optional session token)
- Converse API with native tool calling support
- Prompt caching via cachePoint heuristics
- Proper URI encoding for model IDs containing colons
- Resilient response parsing with unknown block type fallback
Also updates:
- Factory wiring and credential resolution bypass for AKSK auth
- Onboard wizard with Bedrock-specific model selection and guidance
- Provider reference docs with auth, region, and model ID details
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add optional thread_ts field to ChannelMessage and SendMessage for
platform-specific threading (e.g. Slack threads, Discord threads).
- ChannelMessage.thread_ts captures incoming thread context
- SendMessage.thread_ts propagates thread context to replies
- SendMessage::in_thread() builder for fluent API
- Slack: send with thread_ts, capture ts from incoming messages
- All reply paths in runtime preserve thread context via in_thread()
- All other channels initialize thread_ts: None (forward-compatible)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Feishu WebSocket server sends native WS Ping frames as keep-alive probes.
ZeroClaw correctly replied with Pong but did not update last_recv, so the
heartbeat watchdog (WS_HEARTBEAT_TIMEOUT = 300s) triggered a forced
reconnect every 5 minutes even when the connection was healthy.
Two fixes:
- WsMsg::Ping: update last_recv before sending Pong
- WsMsg::Pong: handle explicitly and update last_recv (was silently
swallowed by the wildcard arm)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Fallback providers in create_resilient_provider_with_options() were
created via create_provider_with_options() which passed the primary
provider's api_key as credential_override. This caused
resolve_provider_credential() to short-circuit on the override and
never check the fallback provider's own env var (e.g. DEEPSEEK_API_KEY
for a deepseek fallback), resulting in auth failures (401) when the
primary and fallback use different API services.
Switch to create_provider_with_url(fallback, None, None) so each
fallback resolves its own credential via provider-specific env vars.
This also enables custom: URL prefixes (e.g.
custom:http://host.docker.internal:1234/v1) to work as fallback
entries, which was previously impossible through the options path.
Add three focused tests covering independent credential resolution,
custom URL fallbacks, and mixed fallback chains.
Three related agent UX issues found during MiniMax channel testing:
1. DateTimeSection injected only timezone, not the actual date/time.
Models have no reliable way to know the current date from training
data alone, causing wrong or hallucinated dates in responses.
Fix: include full timestamp (YYYY-MM-DD HH:MM:SS TZ) in the prompt.
2. The `date` shell command was absent from the security policy
allowed_commands default list. When a model tried to call
shell("date") to get the current time, it received a policy
rejection and told the user it was "blocked by security policy".
Fix: add "date" to the default allowed_commands list. The command
is read-only, side-effect-free, and carries no security risk.
3. (Context) The datetime prompt fix makes the date command fallback
largely unnecessary, but the allowlist addition ensures the tool
works correctly if models choose to call it anyway.
Non-goals:
- Not changing the autonomy model or risk classification
- Not adding new config keys
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
MiniMax API rejects role: system in the messages array with error
2013 (invalid message role: system). In channel mode, the history
builder prepends a system message and optionally appends a second
one for delivery instructions, causing 400 errors on every channel
turn.
Additionally, MiniMax reasoning models embed chain-of-thought in
the content field as <think>...</think> blocks rather than using
the separate reasoning_content field, causing raw thinking output
to leak into user-visible responses.
Changes:
- Add merge_system_into_user flag to OpenAiCompatibleProvider;
when set, all system messages are concatenated and prepended to
the first user message before sending to the API
- Add new_merge_system_into_user() constructor used by MiniMax
- Add strip_think_tags() helper that removes <think>...</think>
blocks from response content before returning to the caller
- Apply strip_think_tags in effective_content() and
effective_content_optional() so all non-streaming paths are covered
- Update MiniMax factory registration to use new_merge_system_into_user
- Fix pre-existing rustfmt violation on apply_auth_header call
All other providers continue to use the default path unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add a `config schema` subcommand that dumps the full configuration
schema as JSON Schema (draft 2020-12) to stdout. This enables
downstream consumers (like PankoAgent) to programmatically validate
configs, generate forms, and stay in sync with zeroclaw's evolving
config surface without hand-maintaining copies of the schema.
- Add schemars 1.2 dependency and derive JsonSchema on all config
structs/enums (schema.rs, policy.rs, email_channel.rs)
- Add `Config` subcommand group with `Schema` sub-command
- Output is valid JSON Schema with $defs for all 56 config types
