| name | workshop-bot-log-check |
| description | Read the workshop_bot log (`apps/workshop_bot/logs/workshop.log`) for the last N hours and report a concise health snapshot — persona presence, scheduler activity, anomalies (errors/warnings worth attention). Replaces the persistent Monitor task; designed to run on a schedule every couple hours but also useful ad-hoc when something looks off. |
| user-invocable | true |
| allowed-tools | ["Bash","Read"] |
/workshop-bot-log-check — Periodic workshop_bot health snapshot
Look at the workshop_bot log file and report on what's been happening. The default window is the last 2 hours (matching the scheduled cadence) — if Jamie asks for a different window ("today", "since 12:00", "last 6h") interpret it and adjust.
The log lives at /Users/otto/Projects/studio-thing/apps/workshop_bot/logs/workshop.log. It's a tail-friendly text file — never load the whole thing; always grep / awk a window.
Procedure
1. Bound the window
Default window = last 2 hours. Compute the cutoff timestamp as YYYY-MM-DD HH:MM (one cron interval back from now). Filter log lines whose leading timestamp is ≥ cutoff. A simple awk recipe:
CUTOFF=$(date -v-2H +"%Y-%m-%d %H:%M")
LOG=/Users/otto/Projects/studio-thing/apps/workshop_bot/logs/workshop.log
awk -v c="$CUTOFF" '$0 >= c' "$LOG" > /tmp/wb_window.log
(On Linux, date -d "2 hours ago" instead of date -v-2H.)
All subsequent greps run against /tmp/wb_window.log.
2. Bot lifecycle + git SHA
Find the most recent startup audit. The shape is one line like:
INFO workshop.bot | startup audit:
**workshop-bot online** — `<sha>` (dirty?)
✓ **Eddy** — #editorial · #workshop · #chatter
✓ **Linky** — #research · #workshop · #chatter
✓ **Marky** — #promotion · #workshop · #chatter
✓ **Patty** — #supporters · #workshop · #chatter
If there's a startup audit in the window, note the SHA + when. If there are multiple restarts, note the count.
If you see stop requested; closing clients... without a matching startup audit later, that's an anomaly — the bot is down. Surface it.
grep -E "startup audit|stop requested" /tmp/wb_window.log
3. Persona presence
Each persona logs <Name> online as ... when it joins Discord. Count one per persona in the window. If all four (Eddy, Linky, Marky, Patty) have an online line and the most-recent activity matches each persona's expected cadence, presence is healthy.
grep -E "INFO workshop.persona \| (Eddy|Linky|Marky|Patty) online" /tmp/wb_window.log
4. Scheduler activity
The scheduler logs firing <job> then <job> ok (or error). Five recurring jobs to expect:
| job | expected cadence |
|---|
update-draft-daily | daily 17:00 CT (one fire/day) |
linky-pinboard-scan | every 3h 07:00–22:00 CT (so 1–2 fires per 2-hour window during the day) |
linky-feedbin-ingest | hourly at :35 (2 fires per 2-hour window) |
marky-daily-metrics | daily 19:00 CT (one fire/day) |
follow-up-sweep | hourly at :23 (2 fires per 2-hour window) |
Pull the fire→ok pairs and a one-line job-result for each:
grep -E "workshop\.scheduler(\.handlers)? \|" /tmp/wb_window.log
Look for:
- A job that fired but never logged
ok → it's stuck or it crashed (check for tracebacks after the firing).
- An hourly-cadence job that didn't fire at all in a 2-hour window → scheduler isn't pumping.
5. Job results worth noting
The handler-line message often carries useful information:
content_job pinboard-scan -> ok=True: Linky: posted N card(s) — note the card countcontent_job feedbin-ingest -> ok=True: feedbin-ingest: <N> new toread bookmark(s) — flag when N > 0content_job daily-metrics -> ok=True: Marky posted a daily-metrics report — confirms Marky rancontent_job promotion-prep -> ok=True: … — Marky's promotion drafts (only after put-to-bed)content_job follow-up-sweep -> ok=True: (nothing due) — typical; only surface when something fired
6. Anomalies — what to look for
These warrant explicit callout in the report:
- Any
ERROR line — workshop.* errors are real bugs.
WARNING lines worth surfacing — cadence violations (pinboard: standard/all/recent called X.Xs after previous call), feed-pull failures (popular feed pull failed), shard drops (gateway dropped; will re-login), couldn't pin warnings.- Tracebacks — any line starting with
Traceback (most recent call last): and the immediately-following frames.
- Repeated warnings — if
popular feed pull failed shows up 2+ times in the window, that's an outage, not a blip.
- A
couldn't pin <kind> card — the bot doesn't have Pin Messages permission in some channel.
grep -E "ERROR|WARNING|Traceback|^ File " /tmp/wb_window.log
Group identical warnings (same logger + same suffix) so the report doesn't repeat the same message ten times — say "popular feed pull failed (4×)" instead.
7. Format the report
Output a tight markdown block. Lead with the verdict — ✅ if clean, ⚠️ if something needs attention. Skip empty sections.
## workshop_bot · last <window>
**<✅ All clear | ⚠️ N items worth attention>** · <git sha> · personas: <eddy / linky / marky / patty all online | X offline>
### Schedule
- <jobs fired with outcomes; ok→one-liner each>
### Activity
- pinboard-scan: <total cards posted across firings>
- feedbin-ingest: <total new items filed>
- <anything else worth a single line>
### Anomalies (only if any)
- ⚠️ <one line per anomaly, with timestamp + log excerpt if useful>
Keep it to 10-20 lines max. If everything is clean, the whole report should be 5-8 lines: a one-line verdict + the schedule + activity counts.
8. When to recommend action
The report is observational by default. Recommend action only when:
- The bot is down (most recent
stop requested with no subsequent startup audit) → suggest checking apps/workshop_bot/scripts/admin.sh status.
- An error keeps recurring (the same Python exception 3+ times in the window) → suggest looking at the traceback.
- The
feeds.pinboard.in outage has gone on >12h (popular feed pull failed across 4+ consecutive scans) → Pinboard is broken on their end, but worth being aware.
Otherwise, just report the snapshot and stop. Periodic noise (intermittent shard reconnects, occasional WARNING from third-party libraries) shouldn't drive recommendations — those are normal weather.
When invoked ad-hoc
If Jamie types /workshop-bot-log-check without args, default 2-hour window. If he asks for a different window in natural language ("check the last 6 hours", "what happened today"), use that window instead.
