resolve_effective_policy is implemented with tests but unreachable — is this abandoned scaffolding or still planned?

[dmitriikeler]

While reviewing the hook system for a production deployment, I noticed that crates/tools/src/policy.rs L106-L185 contains a function resolve_effective_policy that looks like an unfinished feature. Before I make assumptions about it in our own setup, I wanted to ask whether it's still the intended direction or abandoned scaffolding.

What it looks like

The function computes a layered ToolPolicy for a given PolicyContext { agent_id, provider, channel, group_id, sender_id, sandboxed }, merging allow/deny rules from six layers (in the function's documented order):

1. Global — tools.policy
2. Per-provider — tools.providers.<provider>.policy
3. Per-agent — agents.list[i].tools.policy
4. Per-channel-group — channels.<ch>.groups.<gid>.tools.policy
5. Per-sender-in-group — channels.<ch>.groups.<gid>.tools.bySender.<sender>
6. Sandbox — tools.exec.sandbox.tools

Deny accumulates across layers; allow is replaced by later layers unless empty. It has full unit test coverage at crates/tools/src/policy.rs L257-L302, covering global / per-provider / deny-wins / prefix-pattern / merge behavior.

This is exactly the shape of policy system you'd want for per-channel and per-sender tool gating — the use case that motivated me to read this code in the first place.

Why I think it's unreachable today

Two problems:

1. No runtime callers. I grep'd the entire workspace. resolve_effective_policy is only referenced by its own unit tests. The actual runtime tool-filtering path at crates/chat/src/lib.rs L1373-L1406 uses a much simpler function (effective_tool_policy) that reads only the global config.tools.policy.allow/deny — layers 2 through 6 are never consulted in production.

2. Schema drift. The function takes &serde_json::Value and walks JSON pointers like /agents/list[i]/tools/policy and /channels/<ch>/groups/<gid>/tools/policy. But the current MoltisConfig schema doesn't have those shapes:

• AgentsConfig at crates/config/src/schema.rs L252-L258 exposes presets: HashMap<String, AgentPreset> — there is no agents.list array, so layer 3's pointer never resolves.
• ChannelsConfig.telegram / .discord / etc. at L1388-L1407 are HashMap<String, serde_json::Value> — opaque untyped blobs with no groups.tools.policy or groups.tools.bySender fields in the schema, so layers 4 and 5 never resolve.

In other words: even if something did call resolve_effective_policy today, only layers 1, 2, and 6 could ever match anything. Layers 3-5 — the interesting ones — are dead in both senses: no callers, and no config shape to read from.

My question

Is this still the intended direction?

• If yes — per-channel-group and per-sender tool policy is still on the roadmap — then it'd be great to know roughly what schema shape you'd want (typed GroupToolPolicy nested in ChannelsConfig? A separate [policies] section? Something else?). That would let folks like me plan around it rather than building a parallel mechanism in shell hooks that you'll later obsolete. I'd also be curious whether it's waiting on something specific (a refactor that hasn't landed, a design decision you're still sitting on, etc).

• If no — this was explored and descoped — then it's probably worth deleting resolve_effective_policy, PolicyContext, and the associated tests so future readers don't mistake the scaffolding for intent. I'd be happy to hear "we're not doing this, use a BeforeToolCall hook" as an answer; it'd unblock our design decision in the other direction.

Either answer helps. I just don't want to write 300 lines of shell-hook plumbing for a use case you're about to support natively, nor do I want to wait for a feature that's not coming.

Context for why I'm asking

I'm setting up a MOLTIS-based autonomous agent that handles messages from multiple channels with varying trust levels (direct DMs from known users, group chats with mixed membership, cron-triggered runs that fetch external content). Per-channel and per-sender tool gating is the natural defense-in-depth layer I want. The BeforeToolCall hook gives me enforcement but no context about where the session came from — that's filed separately as #640 — and having resolve_effective_policy native would make the whole thing first-class instead of a shell-hook custom job.

Related issues I've filed in the same review pass: #631 (Whisper STT config), #632 (empty voice transcription), #633 (Discord attachments), #638 (ToolResultPersist not dispatched), #639 (MessageReceived read-only), #640 (channel metadata in hook payloads). They're all small, all complete scaffolding that already exists in the codebase. This one is the only architectural question — hence the Discussion rather than an Issue.

[penso]

This is now implemented in #677. Here's what landed:

The answer is: yes, this is still the intended direction — and it's now wired up.

resolve_effective_policy has been refactored from raw JSON pointer walks to typed MoltisConfig, connected to the runtime at all 4 apply_runtime_tool_filters call sites, and extended to 6 layers:

#	Layer	Config path
1	Global	[tools.policy]
2	Per-provider	[providers.<name>.policy]
3	Per-agent preset	[agents.presets.<id>.tools]
4	Per-channel group	[channels.<type>.<account>.tools.groups.<chat_type>]
5	Per-sender	...groups.<chat_type>.by_sender.<sender_id>
6	Sandbox	[tools.exec.sandbox.tools_policy]

The schema drift you identified is fixed — layer 3 now reads from agents.presets (not agents.list), and layers 4-5 use typed GroupToolPolicy / ChannelToolPolicyOverride structs with a tool_policy_for_account() helper that deserializes the tools sub-key from the channel account JSON on demand.

For your multi-channel use case with varying trust levels, you can now do:

# Restrict group chats
[channels.telegram.my-bot.tools.groups.group]
deny = ["exec", "browser"]

# Trust a specific sender in groups
[channels.telegram.my-bot.tools.groups.group.by_sender."123456"]
allow = ["*"]

# DMs get full access (no restrictions needed — layers 4-5 only match when group_id matches)

sender_id is now threaded through ChannelMessageMeta from peer_id in all 6 channel handlers (Telegram, Discord, Slack, MS Teams, WhatsApp, Matrix), and flows into both PolicyContext for tool filtering and ChannelBinding for hook payloads — which partially addresses #640 as well.

Full docs at docs/src/tool-policy.md in the PR.