Droid Control

Automate terminals and browsers. Three routing decisions, then atoms guide you the rest of the way.

Ground rules

1. Real apps, real environments. Non-deterministic behavior (LLM responses, network latency, variable output) is expected. Handle it with wait / wait-idle. Never substitute fixtures or mocked data.
2. Commit to execution. Once you've chosen a driver, run the plan. If something fails mid-run, recover and retry -- don't re-evaluate the approach.
3. Atoms are self-contained. Load one and follow its mechanics. No cross-referencing needed.
4. tctl is the ONLY way to launch recorded sessions. tctl manages recording by wrapping asciinema rec around the PTY — raw tuistory has no recording capability and never will. Never call tuistory launch directly; unknown flags crash tuistory-relay. Always resolve TCTL to its absolute filesystem path before use, especially when delegating to workers (they don't inherit ${DROID_PLUGIN_ROOT}).
5. Isolate every run. Multiple droids may be filming simultaneously on the same machine. Session names and output paths share a global namespace (/tmp/tctl-sessions/). At the start of every workflow, generate a run ID (RUN_ID=$(date +%s)-$$ or similar) and use it as a prefix for all session names and a scoped temp directory for all output files:

   RUN_ID="$(date +%s)-$$"
   RUN_DIR="$(mktemp -d /tmp/droid-run-${RUN_ID}-XXXXXX)"
   # Session names: -s ${RUN_ID}-before, -s ${RUN_ID}-after
   # Output paths: ${RUN_DIR}/before.cast, ${RUN_DIR}/after.cast
   

   Never use bare session names like -s demo, -s before, -s after — they will collide with concurrent runs.