docs/reference/architecture.md (1)

191-193: Split into one sentence per line.

Line 193 contains two sentences on the same line. Per the documentation style guide, each sentence should be on its own line to make diffs more readable.

📝 Suggested fix

 | `SLACK_BOT_TOKEN` | Slack bot token (`xoxb-...`) you provide before `nemoclaw onboard`. Stored as an OpenShell provider; never passed directly to the sandbox. |
 | `SLACK_APP_TOKEN` | Slack app-level token (`xapp-...`) required for Socket Mode. Stored alongside `SLACK_BOT_TOKEN` during onboarding. |
-| `SLACK_ALLOWED_CHANNELS` | Comma-separated Slack channel IDs to allowlist (e.g. `C012AB3CD,C987ZY6XW`). Baked into the sandbox image at build time. When unset, no channels are allowed by default. |
+| `SLACK_ALLOWED_CHANNELS` | Comma-separated Slack channel IDs to allowlist (e.g. `C012AB3CD,C987ZY6XW`). Baked into the sandbox image at build time. |

Note: For markdown tables, the "one sentence per line" rule is often relaxed since table cells are inherently single-line. If this is intentional for table formatting, this can be ignored.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/reference/architecture.md` around lines 191 - 193, The table row for
`SLACK_ALLOWED_CHANNELS` contains two sentences on the same line; split that
cell into two sentences on separate lines so each sentence is its own line in
the markdown source (update the `SLACK_ALLOWED_CHANNELS` table cell text to
break after "Baked into the sandbox image at build time." and move "When unset,
no channels are allowed by default." to the next line) to satisfy the
one-sentence-per-line rule for diffs.

src/lib/onboard.ts (1)

2508-2517: Type annotation in @ts-nocheck file.

Line 2511 uses a TypeScript type annotation (const slackAllowedChannels: string[] = []), but the file has // @ts-nocheck`` at the top. While syntactically valid, this is inconsistent with the rest of the file which uses plain JavaScript variable declarations. Consider removing the type annotation for consistency:

-  const slackAllowedChannels: string[] = [];
+  const slackAllowedChannels = [];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 2508 - 2517, Remove the TypeScript-specific
type annotation from the slackAllowedChannels declaration to match the file's //
`@ts-nocheck` JavaScript style: change the declaration for slackAllowedChannels
(used alongside enabledTokenEnvKeys and process.env.SLACK_ALLOWED_CHANNELS) to a
plain JS declaration (e.g., const slackAllowedChannels = []) and leave the rest
of the logic (splitting, trimming, filtering, and pushing ids) unchanged.

docs/deployment/set-up-slack-bridge.md (3)

107-113: Missing "Next Steps" section.

Per the documentation style guide, pages should include a "Next Steps" section at the bottom linking to related pages. Consider adding links to related content such as other messaging bridges (Telegram, Discord) or policy preset documentation.

 - Gateway logs inside the sandbox: `openshell sandbox connect <sandbox-name>` then `tail -f /tmp/gateway.log`.
+
+## Next Steps
+
+- [Set Up Telegram Bridge](set-up-telegram-bridge.md) — configure Telegram messaging.
+- [Set Up Discord Bridge](set-up-discord-bridge.md) — configure Discord messaging.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/deployment/set-up-slack-bridge.md` around lines 107 - 113, Add a "Next
Steps" section after the "Confirm Delivery" paragraph that links to related
messaging bridge docs (e.g., Telegram and Discord bridge setup) and to the
policy preset documentation; reference the existing terms in this page
(SLACK_ALLOWED_CHANNELS, the 'slack' policy preset, and the openshell sandbox
troubleshooting command like openshell sandbox connect <sandbox-name>
/tmp/gateway.log) so readers can navigate from confirmation to other bridge
guides and to the policy preset reference.

---

25-25: One sentence per line.

This line contains two sentences. Per the style guide, each sentence should be on its own line to make diffs more readable.

-NemoClaw supports Slack via Socket Mode — a persistent WebSocket connection that does not require a public URL or inbound firewall rules. The bot and app tokens are stored by OpenShell as secure providers; the sandbox receives placeholder values, not the raw secrets.
+NemoClaw supports Slack via Socket Mode — a persistent WebSocket connection that does not require a public URL or inbound firewall rules.
+The bot and app tokens are stored by OpenShell as secure providers; the sandbox receives placeholder values, not the raw secrets.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/deployment/set-up-slack-bridge.md` at line 25, The sentence "NemoClaw
supports Slack via Socket Mode — a persistent WebSocket connection that does not
require a public URL or inbound firewall rules. The bot and app tokens are
stored by OpenShell as secure providers; the sandbox receives placeholder
values, not the raw secrets." contains two sentences on one line; split them
into two lines so each sentence is its own line in the docs file (update the
line containing the text shown above and ensure the first sentence ends after
"inbound firewall rules." and the second sentence "The bot and app tokens..."
starts on the next line).

---

89-89: One sentence per line.

Split this into separate lines for better diff readability:

-Channel entries in `/sandbox/.openclaw/openclaw.json` are fixed at image build time. Landlock keeps that path read-only at runtime, so you cannot patch messaging config inside a running sandbox.
+Channel entries in `/sandbox/.openclaw/openclaw.json` are fixed at image build time.
+Landlock keeps that path read-only at runtime, so you cannot patch messaging config inside a running sandbox.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/deployment/set-up-slack-bridge.md` at line 89, The paragraph "Channel
entries in `/sandbox/.openclaw/openclaw.json` are fixed at image build time.
Landlock keeps that path read-only at runtime, so you cannot patch messaging
config inside a running sandbox." should be split into separate lines so each
sentence is on its own line; edit the markdown so the first line is "Channel
entries in `/sandbox/.openclaw/openclaw.json` are fixed at image build time."
and the next line is "Landlock keeps that path read-only at runtime, so you
cannot patch messaging config inside a running sandbox."

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/lib/onboard.ts (2)

2513-2522: Minor style inconsistency: explicit type annotation.

Line 2516 uses TypeScript type annotation const slackAllowedChannels: string[] = []; while the rest of the file (under // @ts-nocheck``) avoids explicit type annotations. This works but is stylistically inconsistent.

♻️ Optional: remove explicit type annotation for consistency

-  const slackAllowedChannels: string[] = [];
+  const slackAllowedChannels = [];

Otherwise, the logic is correct — it properly parses the comma-separated channel IDs, filters empty strings, and only populates when both Slack is enabled and channels are specified.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 2513 - 2522, Remove the explicit TypeScript
type annotation on the slackAllowedChannels declaration to match the file's
style (the code under // `@ts-nocheck` avoids explicit types); locate the const
slackAllowedChannels declaration and change it from a typed declaration to an
untyped one (leaving the rest of the logic that checks
enabledTokenEnvKeys.has("SLACK_BOT_TOKEN") and parses
process.env.SLACK_ALLOWED_CHANNELS intact).

---

762-764: Consider importing encodeDockerJsonArg from web-search.ts instead of duplicating it.

This function is already exported from src/lib/web-search.ts (line 10-12). The local copy creates a maintenance burden — if the encoding logic ever needs to change, both copies must be updated.

♻️ Suggested refactor

 const webSearch = require("./web-search");
+const { encodeDockerJsonArg } = webSearch;
 
-function encodeDockerJsonArg(value) {
-  return Buffer.from(JSON.stringify(value || {}), "utf8").toString("base64");
-}

Alternatively, if you prefer to keep imports at the top unchanged, you can reference it via the existing import:

// Replace calls to encodeDockerJsonArg(...) with:
webSearch.encodeDockerJsonArg(...)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 762 - 764, Duplicate encodeDockerJsonArg
implementation in onboard.ts should be removed and the existing exported
function from src/lib/web-search.ts reused; replace local function usage with
the imported encodeDockerJsonArg (or call it via the existing webSearch import
if present) so there’s a single source of truth for encodeDockerJsonArg and
avoid duplicated encoding logic.

.agents/skills/nemoclaw-user-deploy-remote/SKILL.md (1)

1-293: ⚠️ Potential issue | 🟠 Major

Regenerate this skill file from docs/ instead of editing it directly.

This file path is under .agents/skills/nemoclaw-user-*/*.md, so direct edits should be replaced by generated output from the docs source to avoid drift.

As per coding guidelines, ".agents/skills/nemoclaw-user-/.md: Never edit .agents/skills/nemoclaw-user-*/*.md directly; regenerate skills from docs/ source".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.agents/skills/nemoclaw-user-deploy-remote/SKILL.md around lines 1 - 293,
This skill markdown was edited directly under
.agents/skills/nemoclaw-user-deploy-remote/SKILL.md but must be regenerated from
the canonical docs source; revert this file and regenerate the skill from docs/
(update the source docs entry that defines the "nemoclaw-user-deploy-remote"
skill or the "NemoClaw User Deploy Remote" document, then run the docs→skills
generation step) so the generated SKILL.md matches the docs source and avoids
direct edits in .agents/skills/nemoclaw-user-*/*.md.

src/lib/onboard.ts (1)

3659-3676: Consider extracting channel-specific follow-up prompts.

This adds another nested special case inside an already stateful prompt loop. Pulling Slack/Discord extras into per-channel handlers would make future channel additions safer and keep this flow closer to the repo's complexity target. As per coding guidelines, "Limit cyclomatic complexity to 20 in JavaScript/TypeScript files, with target of 15".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 3659 - 3676, The channel-specific app-token
prompt block increases cyclomatic complexity and nests special cases inside the
main onboarding loop; extract this logic into a dedicated per-channel handler
(e.g., a function like handleChannelAppToken(channel) or a channelHandlers map
keyed by channel name) that encapsulates the behavior around getMessagingToken,
prompt/normalizeCredentialValue, saveCredential, and setting process.env, and
move any Slack/Discord-specific extras into their own handlers; then replace the
inline block in the loop with a single call to that handler (pass ch,
ch.appTokenEnvKey, ch.appTokenHelp, ch.appTokenLabel, ch.name) so the loop stays
simple and future channels can add custom flows without increasing the main
function's complexity.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Dockerfile (1)

138-138: ⚠️ Potential issue | 🟠 Major

Only write appToken when the app-token provider is actually wired in.

Line 138 still bakes openshell:resolve:env:SLACK_APP_TOKEN into every Slack config, but src/lib/onboard.ts only creates the SLACK_APP_TOKEN provider when that token already exists. Fresh Slack sandboxes can still end up with an unresolvable secret reference.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Dockerfile` at line 138, The Dockerfile currently unconditionally injects the
unresolved secret reference via
_ch_cfg['slack']['accounts']['default'].update({'appToken':
'openshell:resolve:env:SLACK_APP_TOKEN'}), which can produce an unresolvable
secret for fresh sandboxes; change this to only add the appToken entry when the
SLACK_APP_TOKEN provider will actually be created (the logic in
src/lib/onboard.ts). Concretely, guard or conditionalize the update so it only
runs if the SLACK_APP_TOKEN provider/flag (or an env check like presence of
SLACK_APP_TOKEN) is present, leaving the slack.accounts.default config untouched
otherwise. Ensure you reference and use the same signal that onboard.ts uses to
decide wiring the provider so configs remain consistent.

src/lib/onboard.ts (1)

2569-2590: Consider extracting messaging-config assembly out of createSandbox().

This adds another provider-specific branch to an already very large function. Pulling the messagingAllowedIds / discordGuilds / slackAllowedChannels harvesting into a helper would make the flow easier to reason about and keep it closer to the repo's complexity target.

As per coding guidelines, "Limit cyclomatic complexity to 20 in JavaScript/TypeScript files, with target of 15".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 2569 - 2590, The createSandbox() function is
getting large and includes provider-specific harvesting of messagingAllowedIds,
discordGuilds, and slackAllowedChannels; extract that logic into a new helper
(e.g., assembleMessagingConfig or buildMessagingChannels) that accepts the
inputs used inside createSandbox (env, enabledTokenEnvKeys, etc.) and returns an
object { messagingAllowedIds, discordGuilds, slackAllowedChannels,
activeMessagingChannels } (or individual values); replace the inlined code in
createSandbox() with a single call to that helper and pass the returned values
into patchStagedDockerfile and other call sites, ensuring all referenced symbols
(messagingAllowedIds, discordGuilds, slackAllowedChannels, createSandbox,
patchStagedDockerfile) still compile and tests cover the refactor.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/lib/onboard.ts (2)

3709-3713: ⚠️ Potential issue | 🟡 Minor

The new "channel" allowlist mode still reuses DM/pairing copy.

setupMessagingChannels() only special-cases "guild", so Slack still prints "allowed IDs already set", "user ID saved", and "manual pairing" messaging for this path. That makes the new channel allowlist flow read like DM pairing instead of channel gating.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 3709 - 3713, setupMessagingChannels
currently only treats allowIdsMode "guild" as a special case, so when
allowIdsMode is "channel" the code reuses DM/pairing messages like "allowed IDs
already set", "user ID saved", and "manual pairing"; update
setupMessagingChannels to detect allowIdsMode === "channel" and provide
channel-specific messaging and flow (e.g., replace user/DM/pairing text with
channel-focused text such as "channel IDs already set", "channel ID saved", and
instructions for manual channel gating) ensuring any branches that reference
allowIdsMode or the labels "Slack Channel IDs (optional allowlist)" use the new
channel-specific strings and logic.

---

3705-3708: ⚠️ Potential issue | 🟠 Major

Slack can still be enabled without SLACK_APP_TOKEN.

These new fields are only metadata right now: setupMessagingChannels() never prompts for ch.appTokenEnvKey, and createSandbox() still enables Slack from SLACK_BOT_TOKEN alone. First-time onboarding can therefore finish with a Slack bridge that cannot connect in Socket Mode.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/onboard.ts` around lines 3705 - 3708, The new Slack app token
metadata (ch.appTokenEnvKey / "SLACK_APP_TOKEN") is only descriptive right now,
so onboarding can finish with Slack enabled but missing the App-Level token
required for Socket Mode: update setupMessagingChannels() to prompt for and save
ch.appTokenEnvKey when the user selects Slack and chooses Socket Mode (or when
Socket Mode is required), and update createSandbox() to validate presence of
both SLACK_BOT_TOKEN and SLACK_APP_TOKEN before enabling Socket Mode (or fall
back to disabling Socket Mode and log/warn clearly); ensure references to
ch.appTokenEnvKey, SLACK_APP_TOKEN and SLACK_BOT_TOKEN are used for the presence
check so the sandbox isn't created in a broken state.