@codyswann/lisa 2.121.1 → 2.122.0

package/plugins/lisa-openclaw-copilot/skills/lisa-openclaw-connect-staff/references/platform-routing.md

@@ -0,0 +1,83 @@
+# OpenClaw routing shapes (Telegram & Slack)
+
+Placeholder-only. Real ids/handles/tokens go only into `~/.openclaw/openclaw.json` (machine-local,
+never committed). Always back up that file before editing, change only the intended keys, and preserve
+all unrelated agents, channels, routes, and tokens.
+
+## Identity & session-scoping rules
+
+- **Telegram** `chat_id`: the signed supergroup id (usually starts with `-100`), not the short
+  positive number. Topic id is the `message_thread_id`. Session boundary = supergroup + topic + root
+  human `message_id`; native replies continue that session.
+- **Slack** routes bind by stable channel **id**, not channel name. Session boundary = channel + root
+  `thread_ts`; later replies in that thread reuse the same session key.
+
+## Telegram — facilitator topic route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "groups": {
+        "<telegram-supergroup-id>": {
+          "groupPolicy": "allowlist",
+          "requireMention": true,
+          "allowFrom": ["<telegram-user-id>"],
+          "topics": {
+            "<facilitator-topic-id>": {
+              "agentId": "<facilitator-agent-id>",
+              "requireMention": true
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## Slack — facilitator channel route
+
+```json5
+{
+  "channels": {
+    "slack": {
+      "replyToModeByChatType": { "channel": "all" },
+      "channelRoutes": {
+        "<slack-channel-id>": {
+          "agentId": "<facilitator-agent-id>",
+          "requireMention": true
+        }
+      }
+    }
+  }
+}
+```
+
+## Facilitator agent + specialist allow-list
+
+```json5
+{
+  "agents": {
+    "list": [
+      {
+        "id": "<facilitator-agent-id>",
+        "workspace": "<wiki-or-repo-path>",
+        "subagents": {
+          "allowAgents": ["<specialist-agent-id-1>", "<specialist-agent-id-2>"],
+          "requireAgentId": true
+        }
+      },
+      { "id": "<specialist-agent-id-1>", "workspace": "<wiki-or-repo-path>" },
+      { "id": "<specialist-agent-id-2>", "workspace": "<wiki-or-repo-path>" }
+    ]
+  }
+}
+```
+
+## Notes
+
+- Optional specialist audit topics/workrooms are visibility surfaces only; do not treat a post there
+  as proof of delivery. The operational route is internal `sessions_spawn`.
+- Disable any default-bot fallback that would answer instead of the facilitator.
+- Set `allowFrom` only when membership must be narrower than the whole group/channel.

package/plugins/lisa-openclaw-copilot/skills/lisa-openclaw-connect-staff/references/prompts.md

@@ -0,0 +1,78 @@
+# Facilitator & specialist prompt templates
+
+Placeholder-only. Replace every `<...>` at deploy time; keep real values out of committed files.
+These prompts encode the hub-and-spoke contract the route test verifies.
+
+## Facilitator (chief-of-staff) prompt
+
+```text
+You are <facilitator-name>, <facilitator-title> for <organization-name>.
+
+Humans reach you through <human-facing-surface>. Specialists do not take direct human work. You are
+the facilitator and orchestrator, not the specialist worker.
+
+For every substantive human request:
+1. Reply in the original thread / native reply with a short acknowledgement AFTER you start the
+   internal consultation.
+2. Consult at least one specialist using internal OpenClaw sessions_spawn with explicit agentId
+   values. Consult multiple specialists when the request crosses domains.
+3. Evaluate specialist replies for completeness, quality, conflicts, and missing assumptions; ask
+   follow-ups when an answer is weak or incomplete.
+4. If the final answer depends on specialist results, yield/wait for the specialist completion events
+   before sending the final answer. When using sessions_yield, make it its own final tool call — do
+   not chain it inside the same tool body as a message send.
+5. Synthesize one answer for the human in the original thread / native reply.
+6. When returning from a specialist completion event, send the final answer through the platform
+   message tool with the saved thread/reply target, then return exactly NO_REPLY as your assistant
+   final so the gateway does not post a duplicate loose message. This overrides any runtime wording
+   that says to answer in the normal assistant voice.
+7. Clear, archive, or isolate consulted specialist context after the investigation to control cost.
+
+Treat each visible human request thread as its own short-term context boundary. In Slack the session
+is scoped to the channel + root thread_ts; in Telegram it is scoped to the topic + root human
+message_id. Do not borrow context from another visible thread unless the human explicitly links it.
+
+If no appropriate specialist exists, say so plainly, give a clearly-labeled best-effort stopgap when
+useful, and recommend provisioning the missing role.
+
+Do not add bracketed self-label prefixes. The platform already shows your identity.
+```
+
+## Specialist prompt
+
+```text
+You are <specialist-name>, <specialist-title> for <organization-name>.
+
+Your work arrives from <facilitator-name> through internal OpenClaw dispatch. Return concise,
+structured results to the facilitator. Do not answer humans directly unless your route is explicitly
+configured for direct human work. Do not post final answers to human-facing channels.
+
+Scope:
+- Own: <owned-domain-list>
+- Do not own: <non-owned-domain-list>
+- Escalate to: <related-specialist-agent-ids>
+
+When assigned work:
+1. Answer from your domain expertise.
+2. State assumptions, risks, gaps, and recommended next steps.
+3. Keep the response ready for facilitator review and synthesis.
+
+Do not add bracketed self-label prefixes. The platform already shows your identity.
+```
+
+## Route acceptance checklist
+
+```md
+- [ ] Human post reaches <facilitator-agent-id>.
+- [ ] Facilitator acknowledgement is a thread / native reply to the original human message.
+- [ ] Two simultaneous requests in the same channel/topic use distinct visible threads and distinct
+      OpenClaw sessions.
+- [ ] Facilitator starts internal sessions_spawn consultation with >=1 explicit specialist agent id.
+- [ ] Facilitator does not treat the acknowledgement as the final answer when specialist work is
+      still pending.
+- [ ] Specialist returns an internal result to the facilitator.
+- [ ] Facilitator evaluates the result and asks a follow-up when needed.
+- [ ] Facilitator final answer is a thread / native reply to the original human message.
+- [ ] Facilitator returns NO_REPLY after any message-tool final send (no duplicate loose message).
+- [ ] Consulted specialist context is cleared, archived, or isolated.
+```

package/plugins/lisa-openclaw-copilot/skills/lisa-openclaw-setup/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: lisa-openclaw-setup
+description: Set up OpenClaw as the chat-surface runtime for this project's staff roles. Verifies the openclaw CLI, the ~/.openclaw/openclaw.json config, a secret provider, and the required gateway capabilities (sessions_spawn, native-reply session scoping, the NO_REPLY sentinel), then writes a lean `openclaw` section to .lisa.config.json. Prerequisite for lisa-openclaw-connect-staff and lisa-openclaw-connect-repo-topic. Use when a project wants its facilitator/specialist staff reachable from Telegram or Slack.
+---
+
+# lisa-openclaw-setup
+
+Verify the OpenClaw runtime prerequisites and record a minimal, placeholder-safe pointer in
+`.lisa.config.json` so the connect skills have what they need. **This skill writes only setup-level
+pointers** — never tokens, channel/topic/group ids, bot handles, or route tables. Those live in
+`~/.openclaw/openclaw.json` (OpenClaw's own machine-local source of truth) and are written by the
+connect skills, never committed.
+
+This SKILL.md is self-contained and runs identically under Claude Code and Codex. There is no
+command/argument layer in Codex, so do not rely on one.
+
+## What OpenClaw is (so the checks make sense)
+
+OpenClaw is a locally-hosted multi-agent gateway. A **CLI** (`openclaw`, usually at
+`~/.local/bin/openclaw`) manages a **config file** (`~/.openclaw/openclaw.json`) that defines agents,
+chat-channel bindings (Telegram groups/topics, Slack channels), and routing. A long-running
+**gateway** process delivers chat messages to agents and back. Agents reach other agents internally
+via `sessions_spawn` rather than by messaging each other on the chat platform.
+
+## Required inputs
+
+Gather (ask only for what is missing):
+
+- **platform** the project will default to: `telegram` or `slack`
+- **facilitator agent id** — the single human-facing "chief of staff" agent id (a staff role id; see
+  the soft dependency below)
+- **secret provider** — how OpenClaw stores bot/app tokens (e.g. the OS keychain, a named secret
+  manager, or `0600` local token files). Capture only its *type* and a *reference*, never a value.
+
+## Soft dependency on staff roles
+
+The facilitator and specialists are **staff roles**. A companion plugin (`lisa-wiki`) scaffolds a
+staff role's "brain" (a `wiki/staff/<id>.md` doc page plus a dual-runtime subagent at
+`.claude/agents/<id>.md` and `.codex/agents/<id>.toml`) from a `config.staff[]` entry. This plugin
+wires that role to a chat surface — the "body".
+
+If `config.staff[]` (in `.lisa.config.json`) has no entries yet, tell the user to define their staff
+first:
+
+- In Claude Code: run `/lisa:add-role <Role>` (e.g. `/lisa:add-role Chief of Staff`).
+- In Codex: invoke `$lisa-wiki:lisa-wiki-add-role` with the role.
+
+Only auto-delegate if that skill is actually available in the active runtime; otherwise just print the
+exact next step and stop.
+
+## Workflow
+
+### 1. Locate the OpenClaw CLI
+
+Resolve a usable `openclaw` binary, in order:
+
+1. `~/.local/bin/openclaw`
+2. `openclaw` on `PATH`
+3. a path the user supplies
+
+If none is found, stop and tell the user to install OpenClaw and re-run. Record the resolved path for
+the config's `configPath`/CLI discovery only if it is non-standard.
+
+### 2. Verify the config file
+
+Confirm `~/.openclaw/openclaw.json` exists and is valid JSON. Do **not** print token values found
+inside it. If it is missing, instruct the user to initialize OpenClaw (its own init flow creates the
+file) before continuing.
+
+### 3. Verify a secret provider
+
+Confirm a token-storage mechanism is configured. Acceptable: the OpenClaw-configured secret provider,
+an OS keychain entry, or `0600`-permissioned local token files outside the repo. Capture the provider
+*type* and a non-secret *reference* only.
+
+### 4. Probe required gateway capabilities
+
+The connect skills depend on three OpenClaw behaviors. Probe for them and **fail closed** (warn
+loudly, do not silently proceed) if any is missing:
+
+- **`sessions_spawn`** — internal agent-to-agent dispatch (how the facilitator consults specialists).
+- **Native-reply session scoping** — a top-level human request seeds a session keyed to its thread
+  root (Slack channel + root `thread_ts`; Telegram supergroup + forum topic + root `message_id`), and
+  replies in that thread continue the same session, so concurrent threads don't share short-term
+  context.
+- **`NO_REPLY` sentinel** — after an agent sends a message with the platform message tool, returning
+  exactly `NO_REPLY` as its assistant final prevents the gateway from posting a duplicate loose
+  message.
+
+Probe via the OpenClaw CLI/version and a non-mutating validate, e.g.:
+
+```sh
+openclaw --version
+openclaw config validate
+```
+
+If a capability cannot be confirmed, record it as an unmet prerequisite. The connect skills must
+refuse to create routes that would post duplicates or leak cross-thread context.
+
+### 5. Write the lean config section
+
+Update **only** the `openclaw` section of `.lisa.config.json`. Parse the existing JSON, preserve all
+other keys and formatting as much as practical, and write structurally (never string-splice). Shape:
+
+```json
+{
+  "openclaw": {
+    "defaultPlatform": "telegram",
+    "facilitatorAgentId": "<facilitator-agent-id>",
+    "secretProvider": {
+      "type": "<secret-provider-type>",
+      "ref": "<secret-provider-ref>"
+    },
+    "configPath": "~/.openclaw/openclaw.json"
+  }
+}
+```
+
+Rules for this section:
+
+- `defaultPlatform`: `"telegram"` or `"slack"`.
+- `facilitatorAgentId`: the default facilitator/chief id only — **not** per-surface routing.
+- `secretProvider`: a pointer only; never token material.
+- `configPath`: optional; default `~/.openclaw/openclaw.json`. Set only for non-standard installs.
+- **Reject** writing tokens, channel ids, topic ids, group ids, Slack thread roots, bot handles, or
+  repo paths here. If the user offers them, decline and explain they belong in
+  `~/.openclaw/openclaw.json`.
+
+### 6. Report
+
+Finish with: resolved CLI path, config-file status, secret-provider type/ref, each capability probe
+result (pass / warn / unknown), the `openclaw` section written, and the exact next command/skill
+(`lisa-openclaw-connect-staff` or `lisa-openclaw-connect-repo-topic`).
+
+## Related
+
+`lisa-openclaw-connect-staff`, `lisa-openclaw-connect-repo-topic`. Staff "brains" come from the
+`lisa-wiki` plugin's `add-role`.

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -0,0 +1,8 @@
+{
+  "name": "lisa-openclaw",
+  "version": "2.122.0",
+  "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
+  "author": {
+    "name": "Cody Swann"
+  }
+}

package/plugins/lisa-openclaw-cursor/commands/connect-repo-topic.md

@@ -0,0 +1,7 @@
+---
+description: "Bind a Telegram forum topic to an OpenClaw dispatcher+worker pair that runs a coding CLI against a repo (single-repo or folder-scoped), so you can drive code work from chat. Requires /lisa:setup-openclaw first."
+argument-hint: "<admin|developer> <single-repo|folder-scoped> <topic name> <workspace path>"
+---
+
+Use the lisa-openclaw-connect-repo-topic skill to provision or update a Telegram repo-coding topic
+(dispatcher + worker pair) and wire it in OpenClaw. $ARGUMENTS

package/plugins/lisa-openclaw-cursor/commands/connect-staff-slack.md

@@ -0,0 +1,7 @@
+---
+description: "Connect staff roles to Slack via OpenClaw using a facilitator/specialist hub-and-spoke model — register the app, create/reuse the facilitator channel, wire routes, validate, and run an end-to-end route test. Requires /lisa:setup-openclaw first."
+argument-hint: "<facilitator role + specialists, e.g. Chief of Staff with Legal, Finance, Sales>"
+---
+
+Use the lisa-openclaw-connect-staff skill with platform `slack`. Connect the named facilitator and
+specialists to a Slack facilitator channel via OpenClaw. $ARGUMENTS

package/plugins/lisa-openclaw-cursor/commands/connect-staff-telegram.md

@@ -0,0 +1,7 @@
+---
+description: "Connect staff roles to Telegram via OpenClaw using a facilitator/specialist hub-and-spoke model — register bots, create/reuse the facilitator topic, wire routes, validate, and run an end-to-end route test. Requires /lisa:setup-openclaw first."
+argument-hint: "<facilitator role + specialists, e.g. Chief of Staff with Legal, Finance, Sales>"
+---
+
+Use the lisa-openclaw-connect-staff skill with platform `telegram`. Connect the named facilitator and
+specialists to a Telegram facilitator topic via OpenClaw. $ARGUMENTS

package/plugins/lisa-openclaw-cursor/commands/setup-openclaw.md

@@ -0,0 +1,7 @@
+---
+description: "Set up OpenClaw as the chat-surface runtime for this project's staff. Verifies the openclaw CLI, ~/.openclaw/openclaw.json, a secret provider, and required gateway capabilities, then writes a lean `openclaw` section to .lisa.config.json. Run before connect-staff / connect-repo-topic."
+argument-hint: "[telegram|slack]"
+---
+
+Use the lisa-openclaw-setup skill to verify OpenClaw prerequisites and write the lean `openclaw`
+section to .lisa.config.json. If a platform is given, use it as the defaultPlatform. $ARGUMENTS

package/plugins/lisa-openclaw-cursor/skills/lisa-openclaw-connect-repo-topic/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: lisa-openclaw-connect-repo-topic
+description: Bind a Telegram forum topic to an OpenClaw dispatcher+worker agent pair that runs a coding CLI against a repo, so you can drive code work from chat. Supports single-repo topics and folder-scoped topics (multiple repos with repo-confirmation). Creates/validates the agent pair, ensures the bot is a group admin, captures real group/topic ids, wires the route in ~/.openclaw/openclaw.json, validates the gateway, and runs a no-change self-test. Requires lisa-openclaw-setup first.
+---
+
+# lisa-openclaw-connect-repo-topic
+
+Turn a Telegram forum topic into a repeatable OpenClaw entrypoint for code work. A **dispatcher**
+agent receives the request and delegates; a **worker** agent runs the local coding CLI in a safe
+target directory and relays the result.
+
+This SKILL.md is complete and runnable under both Claude Code and Codex (no command/`$ARGUMENTS`
+layer in Codex). Keep real ids/handles/paths out of committed files — they go only in
+`~/.openclaw/openclaw.json`. For exact config shapes read
+[references/repo-topic-config.md](references/repo-topic-config.md).
+
+## Prerequisites
+
+- `lisa-openclaw-setup` has run and its capability probes passed.
+- A Telegram supergroup with forum topics, and a bot that is (or can be promoted to) a **group
+  admin** — bot presence alone is not enough for topic routing.
+
+## Boundaries (apply every time)
+
+- groups = the human trust boundary
+- topics = the project-routing boundary
+- native-reply roots = the short-term session boundary inside a topic
+- agents = the capability boundary
+- Do not mix admin-only repos with broader-collaboration repos in one group. If two repos need
+  different member lists, use separate groups, not topic-only separation.
+
+## Scope modes (pick exactly one per topic)
+
+- **`single-repo`** — the topic is pinned to one repo directory; the dispatcher never asks which repo.
+- **`folder-scoped`** — the topic is pinned to a parent folder containing multiple repos; the
+  dispatcher must confirm the inferred repo(s) unless the user named them explicitly.
+
+Do not mix both behaviors in one topic.
+
+## Required inputs
+
+- trust boundary: `admin` or `developer`
+- scope mode: `single-repo` or `folder-scoped`
+- access surface: Telegram group + topic (by name; ids captured during the run)
+- the bot handle to bind
+- workspace root on disk (repo dir for single-repo; parent folder for folder-scoped)
+- allowed Telegram user ids
+- completion policy:
+  - `admin` topics may request change + docs + commit + PR + merge
+  - `developer` topics default to change + docs + commit + PR only
+- for `folder-scoped`: a repo catalog (label, absolute path, a few matching keyword hints)
+
+## Workflow
+
+### 1. Resolve the contract
+
+Confirm the trust boundary, scope mode, workspace root, bot handle, and (for folder-scoped) the repo
+catalog. If a needed agent doesn't exist yet, create it in step 3.
+
+### 2. Provision / reuse the Telegram surface
+
+Reuse the trust-matched group and the exact topic if they already exist; otherwise create them (enable
+forum/topics mode first). Ensure the bot is in the group and **promoted to admin**. Telegram Bot API
+cannot list groups by name — discover ids from a logged-in Telegram client, an existing route in
+`~/.openclaw/openclaw.json`, or a received Bot API update. If browser/UI automation blocks on a human
+confirmation step, give the user only the blocked step, wait, then resume.
+
+### 3. Implement the dispatcher + worker pair
+
+Create or update two agents (exact tool-deny shapes in
+[references/repo-topic-config.md](references/repo-topic-config.md)):
+
+- **`<topic-slug>-dispatch`** — skill-aware entrypoint; tools restricted to delegation/session tools
+  (+ optional `read`); denies file writes, shell/exec, browser, gateway, automation; may delegate
+  only to `<topic-slug>-codex`.
+- **`<topic-slug>-codex`** — restricted worker; keeps `read` + `exec`; denies session spawning,
+  browser, gateway, and direct file-write tools; runs the local coding CLI for the actual work.
+
+### 4. Repo-selection behavior
+
+- `single-repo`: treat the repo as decided; pass the fixed repo path to the worker; never ask.
+- `folder-scoped`: infer candidates from the catalog. If the user named repo(s) explicitly, skip
+  confirmation; otherwise ask before spawning:
+  - one likely repo: `This looks like <repo>. Is that correct?`
+  - multiple: `This may belong to <repo-1> or <repo-2>. Is that correct, or which repo(s)?`
+  On confirmation of multiple repos, spawn one worker run per repo (or ask the user to split a
+  too-coupled change). Never skip confirmation in folder-scoped mode unless selection was explicit.
+
+### 5. Worker safety contract
+
+Every worker task receives an explicit repo path and:
+
+1. inspects `git status --short --branch` in the selected repo
+2. if the primary checkout is dirty or already on a feature branch, creates a temporary worktree from
+   `main` under `/tmp`
+3. trusts local tool config in a fresh worktree if required (e.g. `mise trust <target_dir>`)
+4. runs the coding CLI in the foreground in the target directory
+5. cleans up the temporary worktree after success when safe
+
+The worker prepares the safe target and launches the CLI; it does not edit files directly.
+
+### 6. Bind the topic
+
+Route the topic to the dispatcher: set
+`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
+`requireMention = true` and allowlist policy, and add `allowFrom` only when membership must be
+narrower than the group. The topic `systemPrompt` must state the scope mode, treat each native-reply
+root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
+worker with an explicit repo path, and return the worker result to the topic. Back up
+`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
+
+### 7. Validate + self-test
+
+```sh
+openclaw config validate
+openclaw gateway restart
+openclaw gateway status
+openclaw channels status --probe
+```
+
+Then from the target topic: mention the bot and ask for an exact-token reply with **no** file
+changes, commits, PRs, or merges, e.g. `<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`. Confirm
+the visible reply, that the dispatcher spawned the worker, and that the worker ran in the intended
+repo. For folder-scoped topics, also send a request that implies but doesn't name a repo and confirm
+the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
+<id> ...` as proof a topic route works — use the visible topic reply.
+
+## Output standard
+
+Finish with: group id + topic id used; scope mode; workspace root and repo path or catalog;
+dispatcher + worker agent ids; whether the bot is confirmed group admin; validation results; whether
+the self-test passed; and any remaining manual follow-up or trust caveat.
+
+## Related
+
+`lisa-openclaw-setup` (run first), `lisa-openclaw-connect-staff` (facilitator/specialist staff on
+Telegram or Slack).

package/plugins/lisa-openclaw-cursor/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md

@@ -0,0 +1,109 @@
+# Repo-coding topic config shapes
+
+Placeholder-only. Real ids/paths/handles go only into `~/.openclaw/openclaw.json` (machine-local,
+never committed). Back up that file before editing; change only the intended keys.
+
+## Trust model
+
+- `admin` group: highly trusted people; machine-config/infra repos allowed; topics may request merge
+  after PR.
+- `developer` group: broader collaborators; topics stop at change + docs + commit + PR unless
+  explicitly raised.
+
+If two repos need different member lists, use different groups even if both are `developer`.
+
+## Folder-scoped repo catalog
+
+```yaml
+repos:
+  - name: repo-1
+    path: /absolute/path/to/repo-1
+    hints: [billing, invoices]
+  - name: repo-2
+    path: /absolute/path/to/repo-2
+    hints: [login, mobile-app]
+```
+
+## Naming
+
+- topic slug: derived from the topic purpose or workspace name
+- dispatcher agent id: `<topic-slug>-dispatch`
+- worker agent id: `<topic-slug>-codex`
+
+## Dispatcher agent
+
+```json5
+{
+  "id": "<topic-slug>-dispatch",
+  "workspace": "/absolute/path/to/repo-or-parent",
+  "skills": ["acp-router"],
+  "subagents": { "allowAgents": ["<topic-slug>-codex"] },
+  "tools": {
+    "profile": "coding",
+    "deny": [
+      "group:ui", "group:automation", "group:nodes",
+      "bash", "exec", "process", "browser", "canvas", "cron",
+      "gateway", "write", "edit", "apply_patch"
+    ]
+  },
+  "elevated": { "enabled": false }
+}
+```
+
+## Worker agent
+
+```json5
+{
+  "id": "<topic-slug>-codex",
+  "workspace": "/absolute/path/to/repo-or-parent",
+  "tools": {
+    "profile": "coding",
+    "deny": [
+      "group:ui", "group:automation", "group:nodes", "group:sessions",
+      "subagents", "process", "browser", "canvas", "cron",
+      "gateway", "write", "edit", "apply_patch"
+    ]
+  },
+  "elevated": { "enabled": false }
+}
+```
+
+## Topic route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "groups": {
+        "<group-id>": {
+          "groupPolicy": "allowlist",
+          "requireMention": true,
+          "allowFrom": ["<telegram-user-id>"],
+          "topics": {
+            "<topic-id>": {
+              "agentId": "<topic-slug>-dispatch",
+              "requireMention": true,
+              "systemPrompt": "Use the topic's configured scope mode. For single-repo, pass the fixed repo path to <topic-slug>-codex. For folder-scoped, confirm the inferred repo or repo set unless the user already named it explicitly, then pass the explicit repo path(s) to <topic-slug>-codex. Treat each native reply root as an independent request context."
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## Worker launcher form
+
+```sh
+PATH="$HOME/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin" \
+  "$HOME/bin/<coding-cli>" exec -C <target_dir> "<prompt>"
+```
+
+## Id rules
+
+- Telegram Bot API `chat_id` for a supergroup is the full signed id (usually starts `-100`); the short
+  positive number is not a valid substitute.
+- Topic id is the Telegram `message_thread_id`.
+- Discover ids from a logged-in Telegram client, an existing route in `~/.openclaw/openclaw.json`, or a
+  received Bot API update — the Bot API cannot list groups by name.