Files
nanoclaw/.claude/skills/manage-channels/SKILL.md
gavrielc 0d3326aae5 feat(v2): user-level privilege model + cold DM infra + init-first-agent skill
Replaces the agent-group-centric "main group" concept with user-level
privileges and adds the cold-DM infrastructure needed for proactive
outbound messaging (pairing, approvals, welcome flows).

Privilege model
- New tables: users, user_roles (owner global-only; admin global or
  scoped to an agent_group), agent_group_members (explicit non-
  privileged access; admin/owner imply membership), user_dms (cold-DM
  resolution cache).
- Removed agent_groups.is_admin, messaging_groups.admin_user_id. Replaced
  with messaging_groups.unknown_sender_policy (strict | request_approval
  | public) for per-chat unknown-sender gating.
- src/access.ts: canAccessAgentGroup, pickApprover, pickApprovalDelivery.
- src/router.ts: access gate on every inbound, honoring
  unknown_sender_policy for unknown senders.
- src/channels/telegram.ts: pairing interceptor upserts the paired user
  and promotes them to owner if hasAnyOwner() is false (first-pair-wins).

Cold DM infrastructure
- ChannelAdapter.openDM?(handle) — optional method. Chat-SDK-bridge wires
  it to chat.openDM() for resolution-required channels (Discord, Slack,
  Teams, Webex, gChat); direct-addressable channels (Telegram, WhatsApp,
  iMessage, Matrix, Resend) fall through to the handle directly.
- src/user-dm.ts: ensureUserDm(userId) — resolves + caches via user_dms.

Approval routing
- onecli-approvals + delivery use pickApprover + pickApprovalDelivery:
  scoped admins → global admins → owners (dedup), first reachable via
  ensureUserDm, same-channel-kind tie-break. Approvals land in the
  approver's DM, not the origin chat.

Delivery fixes
- delivery.ts ACL rejection now throws instead of returning undefined —
  the outer loop previously marked rejected messages as delivered.
- Implicit-origin allow: session.messaging_group_id === target skips the
  destination check.
- createMessagingGroupAgent auto-creates the companion agent_destinations
  row (normalized local_name from the messaging group's name, collision-
  broken within the agent's namespace).

Container
- container-runner.ts: /workspace/global always read-only; drops
  NANOCLAW_IS_ADMIN; adds NANOCLAW_ADMIN_USER_IDS (owners + global admins
  + scoped admins for this agent group). Agent-runner poll-loop gates
  slash commands against that set.

New skill: /init-first-agent
- Walks the operator through standing up the first agent for a channel:
  channel pick → identity lookup (reads each channel SKILL.md's
  ## Channel Info > how-to-find-id) → DM platform_id resolution (direct-
  addressable, cold-DM via "user DMs bot first + sqlite lookup", or
  Telegram pair-code fallback) → run scripts/init-first-agent.ts →
  verify via tail of nanoclaw.log.
- scripts/init-first-agent.ts: parameterized helper that upserts the
  user + grants owner (if none), creates dm-with-<display-name> agent
  group + initGroupFilesystem, reuses/creates the DM messaging_group,
  wires it (auto-creates destination), resolves the session, and writes
  a kind:'chat' / sender:'system' welcome message into inbound.db. Host
  sweep wakes the container and the agent DMs the operator via the
  normal delivery path.

/manage-channels rewrite
- Drops --is-main / --jid / main-vs-non-main isolation references.
- First-channel flow delegates to /init-first-agent.
- Explains createMessagingGroupAgent auto-creates destinations.
- Adds a privileged-users show section.

setup/
- register.ts: drop --is-main, --jid, --local-name, --trigger
  requiresTrigger defaults; call initGroupFilesystem; normalize to
  v2 schema (no is_admin, no admin_user_id, sets unknown_sender_policy
  'strict'); let createMessagingGroupAgent handle the destination row.
- pair-telegram.ts: emit PAIRED_USER_ID (namespaced "telegram:<id>")
  instead of ADMIN_USER_ID; update header comment.
- register.test.ts deleted — was v1-only, tested a registered_groups
  table that no longer exists.

Docs
- v2-architecture-diagram.{md,html}: ER diagram updated to drop
  is_admin/admin_user_id, add unknown_sender_policy, and include
  users/user_roles/agent_group_members/user_dms.
- v2-architecture-draft.md: approval-routing paragraph rewritten for
  pickApprover/pickApprovalDelivery/ensureUserDm; SQL schema block
  updated; admin-verification paragraph references
  NANOCLAW_ADMIN_USER_IDS.
- v2-setup-wiring.md: entity-model sketch rewritten.
- v2-checklist.md: marked privilege refactor / container filtering /
  approval routing / unknown-sender gating done; removed obsolete
  admin_user_id and main-vs-non-main items.

Scripts
- scripts/init-first-agent.ts (new) replaces scripts/welcome-owner-dm.ts
  (removed; welcome-owner was a Discord-specific one-off).
- test-v2-host.ts, test-v2-channel-e2e.ts, seed-discord.ts: drop
  is_admin + admin_user_id, use unknown_sender_policy.

Tests
- src/access.test.ts (new): 14 tests for canAccessAgentGroup, role
  helpers, pickApprover, ensureUserDm, pickApprovalDelivery.
- src/db/db-v2.test.ts: adds 3 tests for the auto-created
  agent_destinations row (normalized name, no duplicates, collision
  break within an agent group).
- host-core.test.ts, channel-registry.test.ts: updated fixtures to
  use unknown_sender_policy: 'public' where the test exercises routing
  rather than the access gate.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-15 00:03:51 +03:00

5.4 KiB
Raw Blame History

name, description
name description
manage-channels Wire channels to agent groups, manage isolation levels, add new channel groups. Use after adding a channel, during setup, or standalone to reconfigure.

Manage Channels

Wire messaging channels to agent groups. See docs/v2-isolation-model.md for the full isolation model.

Privilege is a user-level concept, not a channel-level one (see src/db/user-roles.ts, src/access.ts). There is no "main channel" / "main group" — any user can be granted owner or admin (global or scoped to an agent group) via grantRole(), and messages from unknown senders are gated per-messaging-group by unknown_sender_policy (strict | request_approval | public).

Assess Current State

Read the v2 central DB (data/v2.db) — query agent_groups, messaging_groups, messaging_group_agents, users, and user_roles tables. Also check .env for channel tokens and src/channels/index.ts for uncommented imports.

Categorize channels as: wired (has DB entities + messaging_group_agents row), configured but unwired (has credentials + barrel import, no DB entities), or not configured.

If the instance has no owner yet (SELECT COUNT(*) FROM user_roles WHERE role='owner' AND agent_group_id IS NULL returns 0), tell the user they should run /init-first-agent first — it stands up the first agent group, promotes the operator to owner, and verifies delivery end-to-end by having the agent DM them. Then return here for any additional channels/groups.

First Channel (No Agent Groups Exist)

Delegate to /init-first-agent. It handles: channel choice, operator identity lookup, DM platform id resolution (with cold-DM or pair-code fallback), agent group creation, wiring, and the welcome DM. Return here afterward for any additional channels.

Wire New Channel

For each unwired channel:

  1. Read its SKILL.md ## Channel Info for terminology, how-to-find-id, typical-use, and default-isolation
  2. Ask for the platform ID using the platform's terminology
  3. Ask the isolation question (see below)
  4. Register with the appropriate flags

Isolation Question

Present a multiple-choice with a contextual recommendation. The three options:

  • Same conversation (--session-mode "agent-shared" + existing folder) — all messages land in one session. Recommend for webhook + chat combos (GitHub + Slack).
  • Same agent, separate conversations (--session-mode "shared" + existing folder) — shared workspace/memory, independent threads. Recommend for same user across platforms.
  • Separate agent (new --folder) — full isolation. Recommend when different people are involved.

Use the channel's typical-use and default-isolation fields to pick the recommendation. Offer to explain more if the user is unsure — reference docs/v2-isolation-model.md for the detailed explanation.

Register Command

npx tsx setup/index.ts --step register -- \
  --platform-id "<id>" --name "<name>" \
  --folder "<folder>" --channel "<type>" \
  --session-mode "<shared|agent-shared|per-thread>" \
  --assistant-name "<name>"

The register step creates the agent group (reusing it if the folder already exists), the messaging group, and the wiring row. createMessagingGroupAgent auto-creates the companion agent_destinations row so the agent can address the channel by name — no separate destination step needed.

For separate agents, also ask for a folder name and optionally a different assistant name.

Add Channel Group

When adding another group/chat on an already-configured platform (e.g. a second Telegram group):

  1. Telegram: ask the isolation question first to determine intent (wire-to:<folder> for an existing agent, new-agent:<folder> for a fresh one). Run npx tsx setup/index.ts --step pair-telegram -- --intent <intent>, show the CODE, and tell the user to post @<botname> CODE in the target group (or DM the bot for a private chat). Wait for the PAIR_TELEGRAM block. The inbound interceptor has already created the messaging_groups row with unknown_sender_policy = 'strict' and upserted the paired user — register only needs to add the wiring:

    npx tsx setup/index.ts --step register -- \
      --platform-id "<PLATFORM_ID>" --name "<group-name>" \
      --folder "<folder>" --channel "telegram" \
      --session-mode "<shared|agent-shared|per-thread>" \
      --assistant-name "<name>"
    
  2. Other channels: read the channel's SKILL.md ## Channel Info for terminology and how-to-find-id. Ask for the new group/chat ID, ask the isolation question, then register. No package or credential changes needed.

Change Wiring

  1. Show current wiring (agent_groups × messaging_group_agents)
  2. Ask which channel to move and to which agent group
  3. Delete the old messaging_group_agents entry, create a new one
  4. Note: existing sessions stay with the old agent group; new messages route to the new one. The agent_destinations row created for the old wiring is NOT automatically removed — if you want the old agent to stop seeing the channel as a named target, delete it from agent_destinations manually.

Show Configuration

Display a readable summary showing:

  • Agent groups with their wired channels (from messaging_group_agents)
  • Configured-but-unwired channels (credentials present, no DB entities)
  • Unconfigured channels
  • Privileged users: SELECT user_id, role, agent_group_id FROM user_roles ORDER BY role='owner' DESC