Add channel delivery descriptor registry

[Aaronontheweb]

Summary

• Adds shared channel descriptor, delivery target, runtime snapshot, and registry contracts.
• Registers descriptor-backed Slack, Discord, Mattermost, and TUI channel metadata while excluding trigger sources and daemon infrastructure.
• Keeps descriptors truthful to implemented behavior, including deferred Discord proactive DM output and Discord/Mattermost file egress.
• Adds runtime snapshot providers and makes daemon runtime status enumerate registry snapshots while preserving connector wire fields.
• Updates the OpenSpec task list for completed POC work and remaining follow-ups.

Validation

• dotnet test src/Netclaw.Actors.Tests/ --filter Channel
• dotnet test src/Netclaw.Daemon.Tests/
• openspec validate standardize-channel-delivery-contracts --type change
• dotnet slopwatch analyze
• pwsh ./scripts/Add-FileHeaders.ps1 -Verify
• git diff --check

[Aaronontheweb]

Reviewed the spec.md - working on the others next

[Aaronontheweb]

agree with this though

[Aaronontheweb]

The design is murky - should not treat reminders and webhooks as co-equals with Slack et al

[Aaronontheweb]

Channel Tool / Capability Matrix

Scope note: this PR has validated descriptor/status behavior and non-live channel-tool registration alignment. It has not validated live Slack/Discord/Mattermost connectivity or live outbound delivery.

Current Channel-Specific Tools

Channel	Tool	Capability	Supported	Security-reviewed?
Slack	send_slack_message	Send message, proactive thread, channel post, DM when AllowDirectMessages is enabled	Yes	Yes, code-level registration/alignment; not live-tested
Slack	lookup_slack_user	User lookup	Yes	Yes, code-level registration/alignment; not live-tested
Discord	send_discord_message	Send message, proactive thread, channel post	Yes	Yes, code-level registration/alignment; not live-tested
Mattermost	send_mattermost_message	Send message, proactive thread, channel post, DM when AllowDirectMessages is enabled	Yes	Yes, code-level registration/alignment; not live-tested
Mattermost	lookup_mattermost_user	User lookup	Yes	Yes, code-level registration/alignment; not live-tested
TUI	none	Local interactive messages/approvals/status surface	Descriptor/status only	Existing local surface; no channel-tool review
SignalR	none	Infrastructure transport	Not registered as output channel	Guardrail-tested
Headless	none	Infrastructure/client mode	Not registered as output channel	Guardrail-tested
Reminder	none	Scheduling infrastructure	Not registered as output channel	Guardrail-tested
Webhook	none	Ingress/infrastructure	Not registered as output channel	Guardrail-tested

Planned Standard Tools / Follow-Ups

Channel	Planned Tool	Capability	Supported	Security-reviewed?
Slack	send_channel_message	Standardized send via channel key, destination, text, optional thread/root	Planned; current tool is send_slack_message	Not yet
Slack	lookup_channel_user	Standardized user lookup	Planned; current tool is lookup_slack_user	Not yet
Slack	lookup_channel_destination	Standardized channel/room lookup	Planned	Not yet
Discord	send_channel_message	Standardized send via channel key, destination, text, optional thread/root	Planned; current tool is send_discord_message	Not yet
Discord	lookup_channel_user	Standardized user lookup	Planned only if Discord lookup is implemented	Not yet
Discord	lookup_channel_destination	Standardized channel lookup	Planned	Not yet
Discord	DM send path	User lookup -> DM delivery target -> send_channel_message	Not supported yet	Not yet
Discord	file output/upload	File egress / file attachment	Not supported yet	Not yet
Mattermost	send_channel_message	Standardized send via channel key, destination, text, optional thread/root	Planned; current tool is send_mattermost_message	Not yet
Mattermost	lookup_channel_user	Standardized user lookup	Planned; current tool is lookup_mattermost_user	Not yet
Mattermost	lookup_channel_destination	Standardized channel/room lookup	Planned	Not yet
Mattermost	file output/upload	File egress / file attachment	Not supported yet	Not yet
All channels	output renderer contract	Semantic output effects, optional/required effect handling	Planned	Not yet
Discord	processing indicator output	Native typing indicator through semantic output path	Planned	Not yet
Slack	processing indicator output	Future equivalent if supported	Future/planned concept only	Not yet
Mattermost	processing indicator output	Future equivalent if supported	Future/planned concept only	Not yet
TUI	processing indicator output	Spinner/status line through semantic output path	Planned	Not yet

OpenSpec Coverage

Yes, the planned work is captured in the OpenSpec change, with one distinction:

• Normative spec coverage exists for standardized channel delivery intents, address resolution, and semantic output effects in openspec/changes/standardize-channel-delivery-contracts/specs/netclaw-input-adapters/spec.md.
• Exact planned tool names (send_channel_message, lookup_channel_user, lookup_channel_destination) are captured in design.md and tasks.md for the same OpenSpec change.
• Parked follow-ups are explicitly tracked in tasks.md: Discord DM output, Discord/Mattermost file output, channel address resolvers, standardized tool renaming/mapping, system skill/eval updates, and semantic processing-indicator rendering.

Key task references:

• 4.7: Discord proactive DM output before advertising Discord DM capability.
• 4.8: Discord file output before advertising Discord file egress/attachment capability.
• 4.9: Mattermost file output before advertising Mattermost file egress/attachment capability.
• 7.1-7.7: standard address resolver and per-channel lookup wiring.
• 8.1-8.6: standard LLM-facing channel tool names/schemas and DM workflow.
• 9.1-9.3: semantic output renderer and processing-indicator output path.

This PR should not claim those planned tools are implemented; it only establishes the descriptor/status foundation and validates current tool registration alignment.

[Aaronontheweb]

Live local binary-swap validation completed on commit 542e1618.

Checks:

• netclaw --version reports netclaw 0.23.0 (commit 542e161, built 2026-06-06T20:42:53Z) before daemon restart.
• Live daemon was restarted manually as a detached process and reports PID 1619066.
• netclaw status --json reports overall healthy and build commit 542e161.
• Runtime connector list is descriptor-backed and includes discord, mattermost, slack, tui, plus MCP connectors.
• Disabled remote connectors report explicit disabled messages for Discord and Mattermost.
• Slack and TUI report healthy in the live install.
• netclaw doctor passes daemon-dependent checks; remaining warning is the pre-existing MCP approval-profile warning for browser_playwright.

No live Slack delivery smoke was performed, and no Slack messages were sent.

[Aaronontheweb]

Manual live validation update: Slack-thread approval flow was exercised with real approvals, and the user reports it is working correctly.

This covers the remaining live manual gap for approval UX on the swapped local daemon build 542e1618. No live Discord or Mattermost delivery validation was performed for this PR.

[Aaronontheweb]

Manual live validation complete on swapped local daemon build 542e1618.

Per user validation, the following live UX checks passed:

• netclaw status human-readable output looked sane.
• Slack/TUI reported healthy and Discord/Mattermost disabled.
• No SignalR/headless/reminder/webhook entries appeared as output connectors.
• Slack inbound thread prompt/reply behavior worked normally.
• Real approval flow worked in Slack thread context.
• Non-tool prompt flow worked without unnecessary approval.
• MCP/tool-backed flow worked under the current approval profile.

No live Discord or Mattermost delivery validation was performed for this PR.