0d7458c6f3
Setup deliberately avoids the sqlite3 CLI (`setup/verify.ts:5` calls this out: "Uses better-sqlite3 directly (no sqlite3 CLI)") and never installs or probes for the binary. Despite that, 13 skills shelled out to `sqlite3 ...` directly, breaking on hosts where the CLI isn't preinstalled — the same root cause as #2191 but spread across the skill surface. Add `scripts/q.ts`, a ~30-LOC wrapper over the `better-sqlite3` dep that setup already installs and verifies. Default output matches `sqlite3 -list` (pipe-separated, no header) so existing skill text reads identically — only the binary changes. SELECT/WITH queries go through `db.prepare().all()`; everything else (INSERT/UPDATE/DELETE, including compound statements) goes through `db.exec()`. Migrate every in-tree caller: - 17 hardcoded invocations across 8 SKILL.md files (init-first-agent, add-deltachat, add-signal, add-emacs, add-whatsapp, add-ollama-provider, debug, add-parallel) plus add-deltachat/VERIFY.md. - `manage-channels/SKILL.md` shows canonical SQL but never prescribed a tool, so the assistant defaulted to `sqlite3` and silently failed. Add a one-line wrapper hint above the SQL block. - `migrate-v2.sh` schema/count probes (was the original #2191 case). Replace `.tables` with `SELECT name FROM sqlite_master`. - Document the wrapper convention in root `CLAUDE.md` under "Central DB". Add `scripts/q.test.ts` with 6 vitest cases covering both modes, NULL rendering, empty-result, compound mutations, and arg validation. Wire `scripts/**/*.test.ts` into `vitest.config.ts`. Out of scope (flagged for follow-up): - `debug` and `add-parallel` still reference the v1-only path `store/messages.db`. Routing through the wrapper now produces a cleaner "no such file" error, but the surrounding sections are v1-era throughout — a v1-content cleanup is its own PR. - `cleanup-sessions.sh` is being addressed in #1889 (different style, hard-fail rather than wrap); left untouched here to avoid stepping on that author's work. Closes #2191. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
55 lines
1.5 KiB
Markdown
55 lines
1.5 KiB
Markdown
# Verify DeltaChat
|
|
|
|
## 1. Check the adapter started
|
|
|
|
```bash
|
|
grep "Channel adapter started.*deltachat" logs/nanoclaw.log | tail -1
|
|
```
|
|
|
|
Expected: `Channel adapter started { channel: 'deltachat', type: 'deltachat' }`
|
|
|
|
## 2. Check IMAP/SMTP connectivity
|
|
|
|
Replace with your provider's hostnames from `.env`:
|
|
|
|
```bash
|
|
DC_IMAP=$(grep '^DC_IMAP_HOST=' .env | cut -d= -f2)
|
|
DC_SMTP=$(grep '^DC_SMTP_HOST=' .env | cut -d= -f2)
|
|
|
|
bash -c "echo >/dev/tcp/$DC_IMAP/993" && echo "IMAP open" || echo "IMAP blocked"
|
|
bash -c "echo >/dev/tcp/$DC_SMTP/587" && echo "SMTP open" || echo "SMTP blocked"
|
|
```
|
|
|
|
## 3. End-to-end message test
|
|
|
|
1. Open DeltaChat on your device
|
|
2. Add the bot email address as a contact
|
|
3. Send a message
|
|
4. The bot should respond within a few seconds
|
|
|
|
If nothing arrives, check:
|
|
|
|
```bash
|
|
grep "DeltaChat" logs/nanoclaw.log | tail -20
|
|
grep "DeltaChat" logs/nanoclaw.error.log | tail -10
|
|
```
|
|
|
|
## 4. Check messaging group was created
|
|
|
|
```bash
|
|
pnpm exec tsx scripts/q.ts data/v2.db \
|
|
"SELECT id, platform_id, name FROM messaging_groups WHERE channel_type='deltachat' ORDER BY created_at DESC LIMIT 5"
|
|
```
|
|
|
|
If a row appears, the inbound routing is working. If not, the adapter isn't receiving the message — check logs for `DeltaChat: error handling incoming message`.
|
|
|
|
## 5. Verify user access
|
|
|
|
If the message arrived but the agent didn't respond, the sender may not have access:
|
|
|
|
```bash
|
|
pnpm exec tsx scripts/q.ts data/v2.db "SELECT id, display_name FROM users WHERE id LIKE 'deltachat:%'"
|
|
```
|
|
|
|
Grant access as shown in the SKILL.md "Grant user access" section.
|