Painful. Money goes prrrrrrrrt.

And this is one of the reasons that pravda is better than the competition. I actually want and use it myself. This problem right here is the worst thing that could happen to you. It happened to me using grok in a way worse form. I at least have a 75-step limit (yeah, it is high, but i optimized it financally so much, that 75 steps even for a user is not much). Grok scheduled an item that used AI everytime just like Devii did for some users here. Rookie mistake. For us, that was long ago. For xai it's the present.

But I was already working on this but it wasn't deployed yet. Dedicated supervisorctl process management bots because we do not run systemd in containers. Hmm, should actually consider that.

step budget exhausted (75 steps). Say continue and I will keep going.

Progress note:
PROGRESS NOTE - dolphin boot autostart, 2026-10-31 18:50 UTC

FACTS
- Shell really sourced: BASH_ENV=/work/.local/pravda/.bashrc (now line 9: [ -r /work/env/dolphin.env ] && . /work/env/dolphin.env).
- No systemd; pid 1 is /bin/sh /usr/local/bin/entrypoint.sh. Hook lines 5-7 START/END "dolphin bot supervisor" run nohup /usr/local/bin/dolphin-init.sh. Patch script: /usr/local/lib/dolphin/patch_entrypoint.py, base copy /usr/local/lib/dolphin/entrypoint.sh.base.
- dolphin-init.sh: starts cron via service cron start, then exec /usr/local/bin/dolphin-boot.
- Root-owned staged set in /usr/local/lib/dolphin/: dolphin-boot, dolphin-supervisor, dolphin-guard (also /usr/local/bin/dolphin-guard), run_dolphin.sh, patch_entrypoint.py. Sources of truth still /work/bin/* and /work/run_dolphin.sh; I copy them over with sudo -n cp.
- dolphin-boot writes /run/dolphin/env (chmod 644) from the key in /work/.bashrc, then execs the supervisor. Cold start log line: "boot: ... api_key=present".
- /run/dolphin is root-owned; guard lock is /run/lock/dolphin-guard.lock (was /tmp, which broke root runs).
- cron: /usr/sbin/cron pid 4047 running, /etc/cron.d/dolphin-guard "* * * * * root /usr/local/bin/dolphin-guard".
- Wrapper kills orphan daemons (parent pid 1 or not the current wrapper) before launching; daemon started with setsid. Proven: "orphan daemon 3887 terminated".
- Supervisor heartbeat is now /bin/sh -c writing /run/dolphin/heartbeat every 30s.

RESULTS: cold start via dolphin-init.sh with /run/dolphin wiped: OK (supervisor 5720, wrapper 5755, daemon 5762). Daemon SIGKILL: respawned. Wrapper SIGKILL: respawned 6010, old daemon and new one coexisted no longer. Full tree SIGKILL + 70s: NOT restored by cron.

OPEN
1. cron never started the guard (two 70s windows, no recovery). Manual sudo -n /usr/local/lib/dolphin/dolphin-guard worked when traced, once not when plain; reason still unknown, possibly the guard's $(find_supervisors) subshell being killed by the 2 GB memory limit of the tool box, or cron not firing.
2. Confirm guard start block works when run plain as root from a clean tree.
3. Old bot-owned copies in /work/bin are stale relative to deployed versions.

NEXT 3 STEPS
1. Run sudo -n bash -x /usr/local/bin/dolphin-guard on an empty tree, capture the exact reason the start branch is skipped.
2. Add a direct runner line to /etc/cron.d (or a small root cron wrapper using /bin/sh) and prove recovery within 60s after killing the whole tree.
3. Sync /work/bin/* and /work/run_dolphin.sh from the deployed versions, then one final cold start through dolphin-init.sh.

The little system that couldn't figure out a service. It's weird. Normally AI does that in a few simple steps. But i will hardcode them and i do that for many things. also for triggers and events. You can add so much triggers and events as you want. I will not invoice and you will not have to pay. All for free. Thatś fucking molodetz.