docs(skills): print pairing code as final message; drop log-tail verify

- Reword pair-code instruction across add-telegram-v2, manage-channels,
  and init-first-agent so the very last user-visible message after
  generating the code MUST be a plain-text print of it.
- Replace init-first-agent's tail -f based verify step with a plain-text
  prompt asking the user to confirm receipt of the welcome DM, falling
  back to DB-based diagnostics only on non-arrival. Avoids harness
  blocks on long leading sleeps and fragile log-string greps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Koshkoshinsk
2026-04-15 10:31:46 +00:00
parent 6801a14736
commit bd6a26a002
3 changed files with 10 additions and 12 deletions

View File

@@ -67,7 +67,7 @@ For Telegram only, there's an existing pair-code primitive:
npx tsx setup/index.ts --step pair-telegram -- --intent new-agent:dm-with-<folder>
```
Parse the `PAIR_TELEGRAM_ISSUED` status block for `CODE`. Tell the user to DM the bot with exactly the 4-digit code. Wait for the `PAIR_TELEGRAM` block — read `PLATFORM_ID` and `PAIRED_USER_ID` from it. telegram.ts's interceptor has already upserted the user and granted owner if none existed yet. Use `PLATFORM_ID` and `PAIRED_USER_ID` directly in step 4.
Parse the `PAIR_TELEGRAM_ISSUED` status block for `CODE`. The user needs to receive the 4-digit code in print, but Claude runs the step in a bash tool call and Claude Code's UI collapses that output — so the user never sees the code. Your very last message visible to the user after generating the pairing code MUST be a plain-text print of the pairing code (e.g. "Your pairing code is **1234**"). Then tell the user to DM the bot with exactly those 4 digits. Wait for the `PAIR_TELEGRAM` block — read `PLATFORM_ID` and `PAIRED_USER_ID` from it. telegram.ts's interceptor has already upserted the user and granted owner if none existed yet. Use `PLATFORM_ID` and `PAIRED_USER_ID` directly in step 4.
## 4. Run the init script
@@ -96,19 +96,17 @@ Show the script's output to the user.
Host sweep runs every ~60s. Within one sweep window the container wakes, the agent processes the system message, and the reply flows through `outbound.db` to the channel.
Tail the log to watch it happen:
Do not tail the log or poll in a sleep loop. Ask the user in plain text:
```bash
tail -f logs/nanoclaw.log
```
> The welcome DM should arrive within ~60 seconds. Let me know when you've received it (or if it doesn't arrive within two minutes).
If nothing arrives within two minutes:
Wait for the user's reply. If they confirm receipt, the skill is done.
If they say it didn't arrive, then diagnose using the DB directly (no waiting loops required — the message either delivered or it didn't):
- `sqlite3 data/v2-sessions/<agent-group-id>/sessions/<session-id>/outbound.db "SELECT id, status, created_at FROM messages_out ORDER BY created_at DESC LIMIT 5"` — check for stuck `pending` rows. Replace `<agent-group-id>` and `<session-id>` with the values from the script's output.
- `grep -E 'Unauthorized channel destination|container.*exited|error' logs/nanoclaw.log | tail -20` — look for ACL rejections or container crashes.
- `ls data/v2-sessions/<agent-group-id>/sessions/*/outbound.db` — confirm the session exists. Replace `<agent-group-id>` with the value from the script's output.
- `sqlite3 data/v2-sessions/<agent-group-id>/sessions/<session-id>/outbound.db "SELECT id, status, created_at FROM messages_out ORDER BY created_at DESC LIMIT 5"` — check for stuck `pending` rows.
Once the welcome DM arrives, confirm with the user and the skill is done.
- `ls data/v2-sessions/<agent-group-id>/sessions/*/outbound.db` — confirm the session exists.
## Troubleshooting