@codyswann/lisa 4.85.0 → 4.86.0

package/plugins/lisa-cdk-devin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.85.0",
+  "version": "4.86.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-devin/.devin-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.85.0",
+  "version": "4.86.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.85.0",
+  "version": "4.86.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/commands/lisa/session-manager.md

@@ -1,5 +1,5 @@
 ---
-description: "Run the local session manager: one dispatch-and-relay cycle (the /loop prompt), or start, stop or show the tmux-hosted manager. Dispatches Ready work items to fresh background worker sessions and relays their questions over the project's Telegram bot. Claude Code only; configure it with /lisa:setup:session-manager."
+description: "Run the local session manager: one dispatch-and-relay cycle (the /loop prompt), or start, stop or show the tmux-hosted manager. Dispatches Ready work items to fresh background worker sessions and relays their questions over the project's Telegram bot when one is configured (Telegram is optional). Claude Code only; configure it with /lisa:setup:session-manager."
 allowed-tools: ["Skill"]
 argument-hint: "[cycle|start|stop|status]"
 ---

package/plugins/lisa-copilot/commands/lisa/setup/session-manager.md

@@ -1,5 +1,5 @@
 ---
-description: "Set up the local session manager for this project: write the sessionManager config block, store the project's own Telegram bot token, check the Telegram plugin scope, seed the runbook, start the manager in tmux, walk through pairing, and run doctor's session-manager check."
+description: "Set up the local session manager for this project: write the sessionManager config block, optionally set up Telegram notifications (store the project's own bot token in its secrets provider, migrating any plaintext token file, check the plugin scope, walk through pairing; skipped with no channel, the default), seed the runbook, start the manager in tmux, and run doctor's session-manager check."
 allowed-tools: ["Skill"]
 ---
 

package/plugins/lisa-copilot/rules/reference/config-resolution.md

@@ -280,7 +280,7 @@ fi
 | `health.schedule` | no | `off` | Health cadence contract: `off`, `daily`, or `weekly`. `lisa sync` populates the default with `_lisaSync.populated` provenance and rejects values outside this closed vocabulary. Runtime results live only at the gitignored `.lisa/health/latest.json`, never in either config file. |
 | `usage` | no | — | Optional token/cost pricing metadata consumed by the `usage-accounting` rule. Missing pricing never blocks a lifecycle flow; Lisa records token counts with `estimated_cost: null` when no trustworthy price source is configured. |
 | `wiki` | no | — | Wiki location for the `wiki-knowledge-source` rule. Omit for a local in-repo wiki (`wiki/`). See **Wiki source** below. |
-| `sessionManager` | no | — (opt-in) | Local session manager: polls the Ready queue, runs each item in a fresh background Claude Code session, and relays questions over a per-project Telegram bot. Absent means the manager is not used; `lisa sync` never populates it. Written by `/lisa:setup:session-manager`. See **Session manager (`sessionManager`)** below. |
+| `sessionManager` | no | — (opt-in) | Local session manager: polls the Ready queue, runs each item in a fresh background Claude Code session, and relays questions over a per-project Telegram bot when one is configured (optional). Absent means the manager is not used; `lisa sync` never populates it. Written by `/lisa:setup:session-manager`. See **Session manager (`sessionManager`)** below. |
 
 ### Host rules (`.agents/rules/`)
 
@@ -716,6 +716,11 @@ have a `.lisa.config.json` and their own `.git` (written as `"root": "."`).
 }
 ```
 
+Telegram is optional. `"notify": { "provider": "none" }`, or no `notify` key at all, runs the
+manager with no notification channel: no bot token, Telegram plugin or pairing, and questions wait
+in the manager's ledger (`status` shows them). Setup writes `{ "provider": "none" }` unless the
+operator chooses Telegram (`init-config --notify telegram`).
+
 | Key | Required | Default | Notes |
 |-----|----------|---------|-------|
 | `sessionManager.name` | **yes** | — | Manager session name: lowercase letters, digits, `-` or `_`, at most 64 characters. It names the tmux session and the session workers `SendMessage` to. Setup writes `<project>-manager`. |
@@ -731,20 +736,47 @@ have a `.lisa.config.json` and their own `.git` (written as `"root": "."`).
 | `sessionManager.stall.noOutputMinutes` | no | `60` | A live worker with no new output for this long counts as stalled (zero or positive). |
 | `sessionManager.stall.maxAttempts` | no | `3` | Fresh sessions per item before it moves to the configured `blocked` role (a positive integer). |
 | `sessionManager.stall.requestionHours` | no | `4` | How long an unanswered worker question waits before the manager asks again (zero or positive). |
-| `sessionManager.notify.provider` | no | `telegram` | Only `telegram` is implemented. |
-| `sessionManager.notify.stateDir` | **yes** | — | This project's own Telegram state dir. Never the shared default `~/.claude/channels/telegram`, because one bot per state dir is how projects stay isolated. Setup writes `~/.claude/channels/telegram-<project>`. |
+| `sessionManager.notify.provider` | no | `none` | `none` (no notification channel) or `telegram`. Absent, like an absent `notify` block, means `none`. Any other value fails validation. |
+| `sessionManager.notify.stateDir` | **yes** with `telegram`; must be absent otherwise | — | This project's own Telegram state dir. A `stateDir` without the `telegram` provider fails validation, because no bot would use it. Never the shared default `~/.claude/channels/telegram`, because one bot per state dir is how projects stay isolated. Setup writes `~/.claude/channels/telegram-<project>`. |
 | `sessionManager.trustedAuthorIds` | no | — | Optional list of **stable tracker user ids**, as strings: the GitHub numeric user id (`gh api users/<login> --jq .id`), the Jira `accountId`, or the Linear user id. Not logins or display names: matching compares ids, so a login silently matches no one and excludes every item. When set, the manager takes only items authored by these people. |
 | `sessionManager.operatorIds` | no | — | Optional, non-empty list of the people the manager works for, as tracker user ids matched against the **assignee** the same way "me" is: the GitHub **login**, the Jira `accountId`, or the Linear user id, spelled exactly as the tracker API returns it (matching is case-sensitive, so look the OPERATOR up rather than typing from memory: `gh api users/<operator-login> --jq .login` returns the canonical GitHub spelling. Do not use `gh api user`, which returns whoever the credential belongs to — the agent account, when that is the case this key exists for). Dispatch order is assigned to an operator, then to "me" (the tracker credential's identity), then unassigned; items assigned to anyone else are skipped. Set it whenever the tracker credential is not the operator's own (an agent account), or the operator's Ready items are never dispatched. |
 | `sessionManager.backlogPickup` | no | `false` | Opt-in lowest dispatch tier. When the Ready queue is exhausted and capacity remains, the manager considers backlog items (open leaves in no lifecycle role) with the Ready exclusions plus any unfinished blocker; each one that passes the tracker validator (all gates, including the stateless-pickup dry-run) is assigned to the first `operatorIds` entry, moved to Ready in one write, read back and dispatched. A failed validation is cached against the item's `updatedAt`, so it is re-judged only after the item changes. Requires `operatorIds`. |
 
-- **Non-secret only.** The bot token lives in `<stateDir>/.env` (directory 0700, file 0600),
-  written by setup. A credential-named field or a token-shaped value anywhere in this block is a
-  validation error.
+- **Non-secret only.** A credential-named field or a token-shaped value anywhere in this block is a
+  validation error. With Telegram, where the bot token lives follows the project's `secrets` block
+  (`lisa-secrets-access`):
+  - **A secrets provider is configured** (`secrets.provider` set and not `env`): the token is the
+    provider secret `TELEGRAM_BOT_TOKEN_<NAME>`, where `<NAME>` is `sessionManager.name`
+    upper-snaked (`lisa-1a2b-manager` → `TELEGRAM_BOT_TOKEN_LISA_1A2B_MANAGER`). There is no config
+    key for it. `store-token` writes it (migrating, then deleting, any plaintext `<stateDir>/.env`);
+    `start` reads it once and passes it to the manager's tmux session only. When `secrets.require`
+    is declared it must list that name. A plaintext `<stateDir>/.env` left beside a provider stops
+    `start` (exit 2) with the `store-token` command that migrates it, and doctor warns about it.
+  - **No provider**: the token lives in `<stateDir>/.env` (directory 0700, file 0600), written by
+    setup, and doctor warns that it is plaintext.
 - **Local over global, per key.** `.lisa.config.local.json` overrides `.lisa.config.json` key by key
   (for example, a smaller `capacity.maxWorkers` on one machine); arrays such as `hints` are
   replaced, not merged. Built-in defaults fill whatever neither file sets.
 - **Workflow roles are not here.** Ready, claimed and blocked come from the existing tracker
-  workflow config, through the single role resolver, like every other lifecycle flow.
+  workflow config, through the single role resolver, like every other lifecycle flow. When an item
+  needs a human, the manager marks it with the tracker's human-needed label
+  (`github.labels.build.human_needed`, `jira.labels.human_needed`,
+  `linear.labels.build.human_needed`, else the tracker's default), or with the `blocked` role when
+  no label resolves, and moves an `exhausted` item to the `blocked` role; `mark-plan` resolves
+  both, so neither name is ever hard-coded.
+- **Who may answer on the item.** A reply on a human-needed item is taken as the answer only from
+  `sessionManager.operatorIds` or `trustedAuthorIds`, matched on stable ids (GitHub login or
+  numeric id, Jira `accountId`, Linear user id; never a display name or email), and never from a
+  machine comment, which is excluded first, whoever wrote it: one starting with a Lisa or Claude
+  tag such as `[lisa-…]` or `[claude-sync]`, holding `[lisa-` or `<!-- lisa:`, saying "Written by
+  Claude", carrying the agent-attribution footer, or whose id the manager recorded as its own
+  (`ledger marked --comment-id`). Quoted (`>`) lines are ignored when testing those markers, so a
+  quote reply is still an answer. The answer must follow the question comment the manager
+  recorded last by id, or, with no recorded id, the latest comment that starts with the question
+  marker and is by an allowed answerer. With neither list set, nothing on the item is read
+  (`item-answer` reports `no-answerers-configured`): there is no fallback to the tracker
+  credential's identity, because the workers and the manager post as it. The operator then answers
+  with the `answerCommand` that `status` lists. Set `operatorIds` even in a single-user setup.
 - **Shape check.** `validateSessionManager` in
   `lisa-secrets-access/scripts/validate-config.mjs` runs as part of `validateConfig`, so
   `/lisa:doctor` reports a malformed block.

package/plugins/lisa-copilot/skills/lisa-secrets-access/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-secrets-access
-description: "Vendor-neutral access layer for secrets. Every skill and script that needs an API key MUST resolve it through this skill rather than reading a keychain, an .env file, or a provider CLI directly. Models two independent axes — the provider a secret lives in (Bitwarden, 1Password, AWS Secrets Manager, Doppler, Vault) and the surface the code runs on (local, GitHub Actions, Codex Cloud) — resolving environment first, then a materialized file where the surface has one, then the provider by exact key name. Enforces one store per secret, fails closed on duplicate names, reads usage metadata from the provider's own note field, and never writes. Rotating credentials route through the separate rotate-secret writer, and copying one into a second store (Bitwarden → GitHub Actions) routes through the separate sync-secret-to-ci propagator."
+description: "Vendor-neutral access layer for secrets. Every skill and script that needs an API key MUST resolve it through this skill rather than reading a keychain, an .env file, or a provider CLI directly. Models two independent axes — the provider a secret lives in (Bitwarden, 1Password, AWS Secrets Manager, Doppler, Vault) and the surface the code runs on (local, GitHub Actions, Codex Cloud) — resolving environment first, then a materialized file where the surface has one, then the provider by exact key name. Enforces one store per secret, fails closed on duplicate names, reads usage metadata from the provider's own note field, and never writes. Rotating credentials route through the separate rotate-secret writer, and copying one into a second store (Bitwarden → GitHub Actions) routes through the separate sync-secret-to-ci propagator; the session manager's Telegram bot token is stored through its own store-token, which uses this skill's provider write path."
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
 
@@ -273,6 +273,8 @@ No create, no update, no rotate. Writing secrets or their notes requires an auth
 
 The two writers are siblings, not modes: `rotate-secret.mjs` replaces a value **at its source**, and `sync-secret-to-ci.mjs` copies one **into a second store** without touching the source. Each needs an authority the resolver must not hold, so each is its own program with its own declaration list.
 
+A third, narrow writer lives outside this skill: the session manager's `store-token` (`lisa-session-manager/scripts/token-store.mjs`) stores the Telegram bot token as `TELEGRAM_BOT_TOKEN_<NAME>` through `providers.mjs` `createSecret` (a new record) or `writeSecret` (`--replace`), then reads it back through the ordinary provider view and compares hashes before deleting the plaintext file it replaces. It writes that one name only, and only when an operator runs it. `createSecret` is Bitwarden-only; on any other provider the operator creates the secret and `store-token` verifies it. Like `bws secret edit`, `bws secret create` (2.1.0) takes the value as a positional argument and its help offers no stdin or file option, so the value is in argv for the life of that one call: the same documented exception, confined the same way (no shell, `--output none`, and a failure message that never repeats the command line).
+
 ## Rotating credentials
 
 A **consumable** credential is one where using it can invalidate the stored copy: an OAuth refresh token the issuer replaces on every exchange, a short-lived session, a single-use enrollment token. The defining property is not "OAuth" — it is that a successful use makes the value on record wrong.
@@ -366,9 +368,9 @@ Values never enter that process, so its output cannot leak one even if logged.
 
 ## Provider dispatch
 
-| Provider | Read | Write (rotation only) |
+| Provider | Read | Write (rotation, and the session manager's `store-token`) |
 | --- | --- | --- |
-| `bitwarden` | `bws secret list --output json` → index by `key` | `bws secret edit`; temporary `create`/`delete` for AWS publication coordination |
+| `bitwarden` | `bws secret list --output json` → index by `key` | `bws secret edit`; `bws secret create <KEY> <VALUE> <PROJECT_ID> --output none` for `store-token` (`createSecret`); temporary `create`/`delete` for AWS publication coordination |
 | `doppler` | `doppler secrets download --no-file --format json` | not implemented |
 | `env` | environment only; the provider is the environment | n/a |
 | `1password` | `op read "op://<vault>/<name>/credential"` | not implemented |

package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/providers.mjs

@@ -701,6 +701,72 @@ export function rawByKey(cfg, key) {
   return matches[0] ?? null;
 }
 
+/** A provider error that names a rate limit (HTTP 429). */
+const RATE_LIMITED = /\b429\b|too many requests|rate.?limit/i;
+
+/**
+ * Run a provider CLI whose argv carries a secret value, and never let that
+ * argv reach an error message.
+ *
+ * `execFileSync` puts the whole command line in its error (`Command failed:
+ * bws secret create KEY <value> ...`), so a failed write would print the very
+ * value it was writing. The rethrown error keeps only what a caller needs to
+ * act on: the operation, the exit status and whether the provider
+ * rate-limited the call. Every other error (a missing binary's
+ * `spawnSync bws ENOENT`, a deadline {@link run} already reworded) is
+ * rebuilt too, keeping only its message (with the value redacted) and its
+ * `code`/`errno`/`syscall`/`status`/`signal`: Node's spawn errors also carry
+ * `spawnargs`, the full argv, value included, which a caller that logs or
+ * serializes the error would publish.
+ * @param {string} bin Executable name.
+ * @param {string[]} args Arguments, one of them a secret value.
+ * @param {NodeJS.ProcessEnv} env Environment for the child.
+ * @param {string} operation What the call was doing, in operator words.
+ * @param {string} value The secret value in `args`, redacted from any error.
+ * @returns {string} Captured stdout.
+ */
+function runWithValue(bin, args, env, operation, value) {
+  try {
+    return run(bin, args, env, operation);
+  } catch (error) {
+    // Node's "Command failed: <command line>" error carries argv in its text.
+    if (!String(error?.message ?? "").startsWith("Command failed")) {
+      throw withoutArgv(error, value);
+    }
+    const why = RATE_LIMITED.test(String(error.stderr ?? ""))
+      ? "the provider rate-limited the request (429 Too Many Requests)"
+      : "the provider refused the request or could not be reached";
+    throw new Error(
+      `${operation} failed (exit ${error.status ?? error.signal}): ${why}. ` +
+        `The command's own output is withheld because its arguments carry ` +
+        `the secret value.`
+    );
+  }
+}
+
+/** The fields of a spawn error that carry no argv, output or value. */
+const SAFE_ERROR_FIELDS = ["code", "errno", "syscall", "status", "signal"];
+
+/**
+ * A copy of a child-process error with no argv on it: a fresh Error whose
+ * message has `value` redacted, and only {@link SAFE_ERROR_FIELDS}. Drops
+ * `spawnargs`, `cmd`, `path`, `stdout`, `stderr` and `output`.
+ * @param {unknown} error What the call threw.
+ * @param {string} value The secret value to redact.
+ * @returns {Error} The rebuilt error.
+ */
+function withoutArgv(error, value) {
+  const text = String(error?.message ?? error);
+  const message = value ? text.split(String(value)).join("<redacted>") : text;
+  const safe = Object.fromEntries(
+    SAFE_ERROR_FIELDS.filter(key => error?.[key] !== undefined).map(key => [
+      key,
+      error[key],
+    ])
+  );
+  return Object.assign(new Error(message), safe);
+}
+
 /**
  * Write a replacement value back to the provider.
  *
@@ -709,7 +775,8 @@ export function rawByKey(cfg, key) {
  * Bitwarden CLI exposes no stdin path for an edit, so this is a documented
  * exception rather than an oversight: it is confined to the one operation that
  * cannot be expressed otherwise, and `execFileSync` at least keeps the value
- * out of a shell and therefore out of shell history.
+ * out of a shell and therefore out of shell history. A failure is reported
+ * through {@link runWithValue}, so the value never reaches the error either.
  * @param {object} cfg Resolved configuration.
  * @param {string} id Provider-side identifier for the secret.
  * @param {string} value Replacement value.
@@ -718,11 +785,12 @@ export function writeSecret(cfg, id, value) {
   const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
-    run(
+    runWithValue(
       "bws",
       ["secret", "edit", id, "--value", value],
       env,
-      "updating a secret in Bitwarden"
+      "updating a secret in Bitwarden",
+      value
     );
     return;
   }
@@ -732,6 +800,56 @@ export function writeSecret(cfg, id, value) {
   );
 }
 
+/**
+ * Create one new secret in the provider.
+ *
+ * The one caller is the session manager's `store-token` (#4555), which moves
+ * the Telegram bot token out of a plaintext file and into the vault, then
+ * reads it back to prove the write before deleting the file. It never
+ * replaces an existing record: that is {@link writeSecret}'s job.
+ *
+ * The value is a positional argument, the same documented exception as
+ * {@link writeSecret}: `bws secret create` (2.1.0) takes `<KEY> <VALUE>
+ * <PROJECT_ID>` and its help lists no stdin or file option for the value, so
+ * there is no way to keep it out of argv. `execFileSync` keeps it out of a
+ * shell, `--output none` keeps the created record (value included) off
+ * stdout, and {@link runWithValue} keeps it out of any error.
+ *
+ * Bitwarden only. Other providers fail with a message naming where to add
+ * one; until then the operator creates the secret in the vault themselves.
+ * @param {object} cfg Resolved configuration.
+ * @param {{name: string, value: string, projectId: string, note?: string}}
+ *   secret Exact key, value, target provider project and usage note.
+ */
+export function createSecret(cfg, { name, value, projectId, note }) {
+  if (!ENV_KEY.test(name)) {
+    throw new Error(`secret name is not an environment variable name: ${name}`);
+  }
+  if (cfg.provider === "bitwarden") {
+    runWithValue(
+      "bws",
+      [
+        "secret",
+        "create",
+        name,
+        value,
+        projectId,
+        ...(note ? ["--note", note] : []),
+        "--output",
+        "none",
+      ],
+      providerEnv(cfg),
+      "creating a secret in Bitwarden",
+      value
+    );
+    return;
+  }
+  throw new Error(
+    `provider "${cfg.provider}" has no create implemented.\n` +
+      `Create the secret in the provider yourself, or add one in providers.mjs.`
+  );
+}
+
 /**
  * Create one provider-issued publication contender in the target project.
  *

package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/validate-config.mjs

@@ -664,12 +664,19 @@ const STALL_RULES = {
   requestionHours: [n => n >= 0, "zero or a positive number"],
 };
 
+/** Notification providers `sessionManager.notify.provider` accepts. */
+const NOTIFY_PROVIDERS = ["none", "telegram"];
+
 /**
  * Validate `sessionManager.notify`.
  *
- * `stateDir` is required rather than defaulted here: the default dir is shared
- * by every project, and a shared dir is exactly how one project's bot gets
- * taken over by another's session.
+ * A notification channel is optional (#4555): an absent block, an absent
+ * provider and `"none"` all mean the manager runs with no channel, and then
+ * there is no state dir to name. A `stateDir` without the telegram provider is
+ * refused rather than ignored, because it means the operator believes a bot is
+ * attached when none will be. For telegram, `stateDir` is required rather than
+ * defaulted here: the default dir is shared by every project, and a shared dir
+ * is exactly how one project's bot gets taken over by another's session.
  * @param {unknown} notify The declared value.
  * @returns {string[]} Problems found.
  */
@@ -677,31 +684,42 @@ function validateNotify(notify) {
   if (notify !== undefined && !isPlainObject(notify)) {
     return ["sessionManager.notify must be an object"];
   }
-  const provider = notify?.provider;
-  const stateDir = notify?.stateDir;
-  return [
-    ...(provider === undefined || provider === "telegram"
-      ? []
-      : [
-          `sessionManager.notify.provider ${JSON.stringify(provider)} is not ` +
-            `supported. Only "telegram" is implemented.`,
-        ]),
-    ...(typeof stateDir === "string" && stateDir.trim() !== ""
-      ? []
-      : [
-          `sessionManager.notify.stateDir is missing. Each project needs its ` +
-            `own Telegram state dir, such as ` +
-            `"~/.claude/channels/telegram-<project>".`,
-        ]),
-  ];
+  const provider = notify?.provider ?? "none";
+  if (!NOTIFY_PROVIDERS.includes(provider)) {
+    return [
+      `sessionManager.notify.provider ${JSON.stringify(provider)} is not ` +
+        `supported. Use "none" (no notification channel) or "telegram".`,
+    ];
+  }
+  const hasStateDir = notify?.stateDir !== undefined;
+  const stateDirOk =
+    typeof notify?.stateDir === "string" && notify.stateDir.trim() !== "";
+  if (provider === "none") {
+    return hasStateDir
+      ? [
+          `sessionManager.notify.stateDir is set, but notify.provider is not ` +
+            `"telegram", so no bot would use it. Set notify.provider to ` +
+            `"telegram", or remove notify.stateDir.`,
+        ]
+      : [];
+  }
+  return stateDirOk
+    ? []
+    : [
+        `sessionManager.notify.stateDir is missing. Each project needs its ` +
+          `own Telegram state dir, such as ` +
+          `"~/.claude/channels/telegram-<project>".`,
+      ];
 }
 
 /**
  * Walk the block for anything that looks like a credential.
  *
  * Config is committed, and this block configures a bot that grants shell
- * access over chat. The token belongs in the state dir's dotenv file (mode
- * 0600), so a token here is both leaked and unused. The value is never echoed.
+ * access over chat. The token belongs in the project's secrets provider
+ * (#4555; the state dir's 0600 dotenv file only when no provider is
+ * configured), so a token here is both leaked and unused. The value is never
+ * echoed.
  * @param {unknown} value Subtree.
  * @param {string} path Dotted path so far.
  * @returns {string[]} Problems found.
@@ -710,8 +728,10 @@ function findCredentials(value, path) {
   if (typeof value === "string") {
     return TOKEN_VALUE.test(value.trim())
       ? [
-          `${path} looks like a bot token. Tokens never go in config; ` +
-            `/lisa:setup:session-manager stores it in the state dir.`,
+          `${path} looks like a bot token. Tokens never go in config: ` +
+            `remove it, and store the token in the project's secrets ` +
+            `provider with session-manager.mjs store-token ` +
+            `(/lisa:setup:session-manager runs it).`,
         ]
       : [];
   }
@@ -723,8 +743,9 @@ function findCredentials(value, path) {
     CREDENTIAL_KEY.test(key)
       ? [
           `${path}.${key} names a credential. Tokens and secrets never go in ` +
-            `config; /lisa:setup:session-manager stores the bot token in the ` +
-            `state dir.`,
+            `config: remove it, and keep the bot token in the project's ` +
+            `secrets provider (session-manager.mjs store-token, run by ` +
+            `/lisa:setup:session-manager).`,
         ]
       : findCredentials(child, `${path}.${key}`)
   );