sanil-23andClaude Opus 4.6
235b12b9bf
Adds focused unit tests for the per-agent scoping helper landed in
commit 4b and runs `cargo fmt` across the files touched by this PR.
Why scoping unit tests, not full integration tests:
`resolve_target_agent` is async and reads `Config::load_or_init().await`
which does a real disk read every call (no cache, verified at
`config/schema/load.rs:409`). Mocking that requires either spinning up
a full workspace under a temp dir with a config.toml containing the
right `onboarding_completed` value, or adding a test-only injection
point on the public Config API. Both are tractable but invasive
enough to belong in their own follow-up PR. The end-to-end dispatch
path is already covered by the existing channel integration tests
(`dispatch_routes_through_agent_run_turn_bus_handler` etc.) which
exercise the full bus roundtrip with the new fields populated, and
which still pass after the new resolver landed (it gracefully falls
back to `AgentScoping::unscoped()` when no orchestrator definition
is registered in the test environment).
Pure-function unit tests for `build_visible_tool_set` cover the
branching logic that does the actual scoping work: how the named
whitelist + extras union is built, how Wildcard scope is preserved,
how duplicates are de-duplicated, etc. That's the part most likely
to drift in future changes, so it's the part most worth fencing
with focused tests.
Tests added (all in `src/openhuman/channels/runtime/dispatch.rs` under
the new `scoping_tests` module):
* `wildcard_scope_yields_none_filter` — `ToolScope::Wildcard` must
produce `None` regardless of whether extras are present, so
skills_agent / morning_briefing keep their full skill-category
catalogue.
* `named_scope_without_extras_returns_named_only` — the welcome
agent's path: 2 named tools, no delegation, exactly 2 entries in
the visibility whitelist.
* `named_scope_with_extras_returns_union` — the orchestrator's path:
3 direct named tools + 3 synthesised extras (research,
delegate_gmail, delegate_github) → 6 entries.
* `empty_named_with_extras_returns_extras_only` — guards a future
"delegation-only" agent layout where the agent has no direct tools
of its own, just spawns subagents.
* `empty_named_with_no_extras_returns_empty_set` — guards the
distinction between `None` (no filter, all visible) and
`Some(empty)` (filter active, nothing matches). Important because
the prompt loop's `is_visible` check treats them differently.
* `duplicate_names_across_named_and_extras_are_deduplicated` — the
HashSet handles collisions automatically, but the test pins that
behaviour so a future migration to `Vec<String>` (which would
silently double-count) gets caught.
* `agent_scoping_unscoped_has_no_filter_or_extras` — pins the
safe-fallback constructor's contract. Used when the registry is
uninitialised or the target agent is missing — every field must
default to "no scoping" so the channel turn falls back to legacy
unfiltered behaviour rather than crashing.
Plus `cargo fmt` run across the 6 files modified by this PR. No
behavioural changes.
Final test status across all commits 2-6 in this PR:
* agent::harness::definition: 10/10 ✅ (4 new for Subagents schema)
* agent::harness::tool_loop: 8/8 ✅
* agent::harness::tests: 3/3 ✅
* tools::orchestrator_tools: 5/5 ✅ (5 new)
* channels::*: 599/599 ✅ (incl. dispatch integration)
* channels::runtime::dispatch::scoping_tests: 7/7 ✅ (7 new)
* context::debug_dump: 11/11 ✅ (1 replaced + 1 new)
* Total agent module: 323/324 (one pre-existing Windows path
failure in `self_healing::tool_maker_prompt_includes_command`
confirmed identical against upstream/main baseline)
Pre-existing Windows-environment test failures NOT caused by this PR
and out of scope (all confirmed identical on upstream baseline; CI on
Linux is unaffected):
* self_healing::tool_maker_prompt_includes_command (PathBuf separator)
* cron::scheduler::run_job_command_success / _failure (Unix shell)
* composio::trigger_history::archives_triggers_in_daily_jsonl... (path)
* local_ai::paths::target_paths_preserve_absolute_overrides (path)
* security::policy::checklist_root_path_blocked (POSIX absolute)
* security::policy::checklist_workspace_only_blocks_all_absolute (POSIX)
* tools::implementations::browser::screenshot::screenshot_command_
contains_output_path (browser binary lookup)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
OpenHuman
The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.
Discord • Reddit • X/Twitter • Docs
"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion
Early Beta — Under active development. Expect rough edges.
To install or get started, either download from the website over at tinyhumans.ai/openhuman or run
# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
What is OpenHuman?
OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:
-
Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.
-
One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.
-
Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.
-
Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.
-
Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.
-
Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.
Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.
OpenHuman vs other agents
High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.
| Claude Code/Cowork | OpenClaw | Hermes Agent | OpenHuman | |
|---|---|---|---|---|
| Open-source: Is the codebase open to review? | 🚫 Proprietary client | ✅ MIT License | ✅ MIT License | ✅ GNU License |
| Simple: Is it simple to get started? | ✅ Simple Desktop App + CLI | ⚠️ Terminal first and often complex | ⚠️ Terminal first and often complex | ✅ Simple, Clean UI/UX. Get started within minutes |
| Cost: How expensive is to run? | ⚠️ Subscription + add-on tool/API costs | ⚠️ Tied to models & hosting you choose | ⚠️ Tied to models & hosting you choose | ✅ Cost optimized with the option to run many things locally for free |
| Memory & Knowledge Base (KB): Does the agent know you and your world? | ✅ Built-in memory; mostly chat/session scoped | ⚠️ Has a local memory but often needs plugins for richer behavior | ✅ Self-learning / task loops (typical) | 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts |
| API spagetti: How complex is it to hook mulitple features together? | 🚫 Claude bill + often extra keys for MCP/tools | 🚫 BYOK / multi-vendor common | 🚫 Multiple providers common | ✅ One account get access to many bundled platform APIs |
| Extensibility: Can you add rich features into it? | ✅ MCP (different model than sandboxed skills) | ✅ Plugin Architecture (SKILL.md) | ✅ Plugin Architecture (SKILL.md) | 🚀 Rich Skills with ability to have realtime updates, local DB & more |
| Desktop integrations: Can it integrate into your desktop completely? | ⚠️ Desktop app & access to folders | ⚠️ Often lighter native surface | ⚠️ Often lighter native surface | ✅ STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more |
Contributors Hall of Fame
Show some love and end up in the hall of fame