Pup - the AI's own browser

@@ -1103,10 +1103,20 @@ DURABLY that breaks.** Measured all three forms on this container: | `export` then N calls inside ONE shell invocation | yes, all N | that invocation only | | `'{"caller":{"aiThread":"<name>"}}'` or flat `'{"aiThread":"<name>"}'` in args | yes | that call | +**Why an export CANNOT clobber a sibling thread (John's follow-up, worth understanding so you don't+over-correct):** a process's environment is COPIED INTO IT at spawn, never shared. Each AI thread's shell+is its own process, so 20 threads can each export a different `ADOM_AI_THREAD` in the same instant and+none can see or overwrite another's — demonstrated with three concurrent subshells: A exported `thread-A`+and saw `thread-A`, B exported `thread-B` and saw `thread-B`, C never exported and saw empty. (Stricter+still: an export does not even survive into the next tool call of the SAME thread.)++So the ONLY thing 20 threads can actually clobber is **shared state on disk** — i.e. exactly one file,+`~/.bashrc`. That was the whole bug, and nothing else.+ **Prefer the PREFIX form for ad-hoc calls** — thread-accurate, zero shared state, and less invasive than-restructuring a verb's JSON to add a `caller` object. Use `export` at the top of a multi-command script-(ship.sh does this: one invocation, one identity). **Never in a shared profile**, which is the only thing-that was actually wrong. Do not over-claim this as an AD design flaw: AD accepts env-var OR args, which is+restructuring a verb's JSON to add a `caller` object. `export` at the top of a multi-command script is+equally safe (ship.sh does this: one invocation, one identity, per-process isolation). **Never in a shared+profile**, which is the only thing that was actually wrong. Do not over-claim this as an AD design flaw: AD accepts env-var OR args, which is flexible enough; the defect is the doc's "set it once per session / strictly better" advice, since on a persistent multi-thread container the natural way to satisfy that is a profile edit.