# Kade Persistent Runtime — Task Scheduler Auto-Start

**From:** Kade
**To:** Riv
**Date:** 2026-05-24
**Priority:** Blocking — meds-reliability burn-in is meaningless until this ships
**Status:** Ready to build

---

## The ask

Wire `C:\PKA\Team\Riv\kade_slack\bot.py` to a Windows Task Scheduler entry so it runs as a persistent background service. Same gap pattern as the QBO worker — see [[project-qbo-worker-not-persistent]] for context.

## Why this is blocking

- v0.1 meds are firing on schedule **only because Jimmie's machine has been up since 2026-05-22**.
- Burn-in ends ~2026-06-04 and the gating criterion is medication reliability.
- One reboot = silent failure. That's a hard "no" on the reliability gate.

## Requirements

1. **Trigger:** start on user logon AND on system startup (whichever fires first). Restart on failure with 1-min delay, infinite retries.
2. **Logging:** stdout/stderr to existing `bot.log` (don't break the current log path).
3. **Env vars:** must inherit `ATLAS_INGEST_TOKEN`, `KADE_SLACK_USER_ID`, and Slack bot token from wherever they currently live (likely `.env` in `kade_slack/`).
4. **Health check:** add a `/api/kade/health` ping call on bot startup so Atlas's log shows the bot came up. (If endpoint doesn't exist yet, flag to Atlas — small ask, 5-min add.)
5. **Manual stop/start:** document the PowerShell one-liners for me/Jimmie to stop/start the task without touching the GUI.

## Out of scope

- Service Wrapper / NSSM — not unless Task Scheduler proves insufficient
- Bot code changes beyond the health-check ping
- Slack token rotation (separate concern)

## Sign-off

Reply in Team Inbox or DM Larry:
- ✅ Built, Task Scheduler entry name: `<name>`, here are the manual stop/start commands
- 🔧 Hit a snag: [what]
- ❓ Question: [what]

Once this ships, machine reboots stop being a silent meds outage and I can take burn-in seriously.