Confirm schedule create/delete with inline Telegram buttons

.claude/commands/pnpm-update.md

@@ -0,0 +1,112 @@
+---
+description: Triage outdated pnpm packages, research what each upgrade entails, then update the approved set
+allowed-tools: Bash(pnpm outdated:*), Bash(pnpm up:*), Bash(pnpm typecheck:*), Bash(pnpm lint:*), Bash(pnpm test:*), Bash(pnpm build:*), Bash(git status:*), Bash(git diff:*), Bash(cat:*), Bash(jq:*), Read, WebSearch, WebFetch
+argument-hint: [--dev | --prod]
+---
+
+Survey outdated packages in this pnpm workspace, research what each update is, propose a targeted upgrade plan, get my confirmation, then run the update. Do NOT commit.
+
+Arguments: `$ARGUMENTS` — optional. Pass `--dev` or `--prod` through to `pnpm outdated` to scope the check.
+
+## 1. Pre-flight
+
+1. `git status --porcelain` — if there are uncommitted changes touching `package.json` or `pnpm-lock.yaml`, STOP and tell me to commit or stash first. Other unrelated WIP is fine but warn me.
+2. Confirm this is a pnpm workspace by reading `pnpm-workspace.yaml` (or at least `package.json` with `packageManager: pnpm@*`). If not, stop.
+
+## 2. Survey
+
+Run:
+
+```
+pnpm outdated -r --format json $ARGUMENTS
+```
+
+If the output is empty / `{}`, say "Everything is up to date." and stop.
+
+Parse the JSON. For each entry capture: package name, current version, latest version, type (`dependencies` / `devDependencies`), and which workspace(s) it appears in.
+
+Classify the bump for each package:
+
+- **patch** — `x.y.Z` only changed
+- **minor** — `x.Y.z` changed (and major matches)
+- **major** — `X.y.z` changed
+- **prerelease / weird** — anything else (e.g. `0.x` minor bumps, which are effectively major in semver)
+
+Treat `0.x` minor bumps as major-equivalent (breaking by convention).
+
+## 3. Research
+
+For each **major** and **prerelease/weird** entry, look up release notes before classifying:
+
+- Try `WebSearch` for `<package> <new-version> release notes` or `<package> changelog <new-version>`.
+- If the package has a known repo, prefer `WebFetch` on `https://github.com/<owner>/<repo>/releases/tag/v<new-version>` or the repo's `CHANGELOG.md`.
+- Cap research at ~3 lookups per package; summarize in one line per package.
+
+For **patch** and **minor** entries, do not research — assume safe unless the name is a well-known framework where minor bumps are routinely breaking (e.g. eslint configs, type-only packages tied to a runtime). Use judgment, note exceptions explicitly.
+
+## 4. Triage table
+
+Print one table, grouped by bump class (patch first, then minor, then major):
+
+```
+PACKAGE                 CURRENT → LATEST    CLASS   RECOMMEND   NOTES
+<name>                  1.2.3 → 1.2.7       patch   update      —
+<name>                  4.5.0 → 5.0.0       major   review      drops Node 18; new ESM-only export
+<name>                  0.3.1 → 0.4.0       major   hold        breaking type changes, see CHANGELOG
+```
+
+Recommendation rules:
+
+- `update` — safe to bump now (patch / minor with no known issues).
+- `review` — major bump, but release notes look manageable. Worth doing in this pass with awareness.
+- `hold` — major bump with breaking changes that need code edits before updating. Do NOT include in the upgrade command this round.
+
+If you researched a package, the `NOTES` cell must reflect what you actually found. Don't say "see changelog" — summarize the breaking change in ≤ 80 chars.
+
+## 5. Plan
+
+Below the table, print the exact command that would run, with packages from rows recommended `update` or `review`:
+
+```
+pnpm up --latest -r <pkg1> <pkg2> ...
+```
+
+If the list is empty (only `hold` rows), say so and stop — nothing to upgrade automatically.
+
+**Gate.** Ask exactly: `Run this update? (yes / edit / cancel)`. Wait for my reply.
+
+- `yes` → proceed.
+- `edit` → let me reclassify rows (e.g. "move <pkg> to hold", "add <pkg> back in"), then re-show the command and re-confirm.
+- `cancel` → stop without running anything.
+
+## 6. Apply (only after gate = yes)
+
+1. Run the confirmed `pnpm up --latest -r <pkgs...>` command.
+2. If pnpm errors out, STOP and show the error — do not retry blindly.
+3. Run validation, but only scripts that exist in the root `package.json`:
+   ```
+   pnpm typecheck
+   pnpm lint
+   pnpm test
+   pnpm build
+   ```
+   Skip any script that isn't defined. Show pass/fail for each.
+4. Show `git diff --stat package.json '**/package.json' pnpm-lock.yaml` so I can see what moved.
+
+## 7. Summary
+
+Print:
+
+- `Updated: <N>   Held: <N>   Validation: <ok|failed>`
+- The exact list of packages that were upgraded, with `old → new` versions.
+- If validation failed, the failing script name. Do NOT try to "fix" the failure in this command — that's a separate task.
+
+Do NOT commit. Do NOT push. Leave the working tree dirty for me to review and commit manually (or via `/commit`).
+
+## Hard rules
+
+- Never run `pnpm up` before the gate is confirmed.
+- Never include `hold` packages in the upgrade command, even if they're in the same workspace.
+- Never edit source code to "fix" a breaking change in this command — flag it and stop.
+- Never commit or push.
+- Never use `--no-verify` or skip validation. If validation fails, surface it.

.claude/commands/review-plan.md

@@ -0,0 +1,84 @@
+---
+description: Codex-powered thorough review of a plan or design document — finds holes, hidden assumptions, and bugs in the plan itself
+argument-hint: "[--wait|--background] [path/to/plan.md]"
+allowed-tools: Read, Write, Bash(node:*), Bash(ls:*), AskUserQuestion
+---
+
+Run a thorough adversarial Codex review of a plan or design document. The plan has NOT been implemented yet — Codex's job is to stress-test the plan itself, not produce code.
+
+Raw slash-command arguments:
+`$ARGUMENTS`
+
+Core constraint:
+
+- This command is review-only.
+- Do not fix issues, apply patches, or suggest you are about to make changes.
+- Your only job is to run Codex and return its output verbatim.
+
+Locating the plan:
+
+1. If the arguments include a path that looks like a file (e.g. `docs/plan.md`, `./plan.md`, an absolute path), resolve it relative to the current working directory and use that file as the review target. Verify it exists with `Read` before invoking Codex.
+2. If no path is given, take the most recent plan you (Claude) produced in this conversation, write its full markdown to `/tmp/review-plan-<unix-ts>.md` with the `Write` tool, and use that file as the review target. Do not summarize or trim — write it verbatim.
+3. If you cannot locate a plan in either place, ask the user where the plan lives. Do not proceed without a target.
+
+Execution mode rules:
+
+- If the arguments include `--wait`, run in the foreground without asking.
+- If the arguments include `--background`, run as a background Bash task without asking.
+- Otherwise, recommend foreground (`--wait`) — plan reviews are usually small and fast. Use `AskUserQuestion` exactly once with two options, recommended first:
+  - `Wait for results (Recommended)`
+  - `Run in background`
+
+Resolving the Codex companion:
+
+- The codex plugin lives under `~/.claude/plugins/cache/openai-codex/codex/<version>/scripts/codex-companion.mjs`. Resolve the latest version dynamically:
+
+```bash
+COMPANION="$(ls -1d "$HOME"/.claude/plugins/cache/openai-codex/codex/*/scripts/codex-companion.mjs 2>/dev/null | sort -V | tail -1)"
+```
+
+- If `$COMPANION` is empty, tell the user to run `/codex:setup` and stop.
+
+Building the prompt:
+
+- Use the heredoc below verbatim, substituting `<PATH>` with the absolute path to the plan file.
+- Do NOT pass `--write`. This is read-only review — Codex must not modify any files.
+- Do NOT pass `--resume-last`. Each plan review is a fresh Codex thread.
+
+Foreground flow:
+
+```bash
+node "$COMPANION" task "$(cat <<'EOF'
+You are reviewing a plan / design document. The plan is for a coding change that has NOT been implemented yet — your job is to stress-test the plan itself, not produce code or modify files.
+
+Read the file at <PATH> first. Then review the plan adversarially for:
+
+- Hidden assumptions and where they break under real conditions.
+- Missing steps, gaps, or hand-waving in the design.
+- Ordering / dependency issues (e.g. migration vs deploy ordering, type changes that break callers, schema changes that aren't backward-compatible).
+- Race conditions and concurrency bugs implied by the proposed runtime behavior.
+- Security gaps (auth, input validation, replay, token spoofing, IDOR, allowlist bypass).
+- Backwards-compatibility, rollback, and data-migration risks.
+- Edge cases and failure modes the plan does not address (timeouts, partial failures, retries, idempotency).
+- Test coverage gaps — both what's listed and what's silently missing.
+- Vague language that hides ambiguity ("handle gracefully", "as needed", "if necessary", "etc").
+- Scope or effort that looks unrealistic for the risk implied.
+- External-system contracts (APIs, webhooks) the plan relies on without verifying.
+
+Rules:
+- If the plan is sound, say so explicitly and stop. Do not invent issues to look thorough.
+- If you find issues, list them ordered by severity (Critical / High / Medium / Low). For each issue: cite the section of the plan it relates to, describe the concrete failure mode, and give a one-line fix or open question.
+- End with a short verdict: "Ship as-is", "Ship after fixing the Critical/High items", or "Re-plan".
+- Do not write code. Do not modify any files. Output one review only.
+EOF
+)"
+```
+
+Background flow:
+
+- Same command, launched via `Bash` with `run_in_background: true`. After launching, tell the user: "Codex plan review started in the background. Check `/codex:status` for progress."
+
+Output rules:
+
+- Foreground: return the stdout of `codex-companion` verbatim — no commentary before or after, no paraphrasing.
+- Do not fix any issues Codex raises in the same turn. The user will follow up if they want changes.

apps/operator/README.md

@@ -31,7 +31,7 @@ Run commands from the repo root unless noted otherwise.
 - The webhook body is limited to 64 KiB and validated against the Telegram update schema
 - Messages from the allowed Telegram chat are forwarded to OpenAI
 - The assistant can create, list, and delete scheduled reminders through tool calls
-- Schedule creation and deletion require a `YES` confirmation reply within two minutes
+- Schedule creation and deletion require confirmation within two minutes via inline ✅/❌ buttons (typing `YES` still works as a fallback)
 - A cron trigger runs every minute and executes due reminders and web monitors from D1
 - Monitor schedules scrape a URL, analyze the content with OpenAI, and notify only when the condition matches
 

apps/operator/migrations/0004_minor_rictor.sql

@@ -0,0 +1 @@
+ALTER TABLE `pending_actions` ADD `token` text;