Adom Bridge

@@ -0,0 +1,115 @@+# Caller identity: knowing which AI tab is driving your machine++If you use Adom Desktop the way most people do, you have something like twenty AI+conversation tabs open at once, all pointed at the same PC. One is fetching parts, one is+reviewing a board, one is cleaning up a downloads folder, and several are idle.++Until now they all looked the same. An approval toast said an AI wanted to run a shell+command, and the Activity Log was one undifferentiated stream. If a tab went off the+rails, there was no way to tell which one.++As of v1.9.180, every command that reaches your desktop over the relay has to say who is+asking.++## What you get++Two pieces of information now ride along with every relayed command:++- **Thread name**: the name of the AI conversation, for example "chip-fetcher tab 3".+- **Container name**: which cloud container it is running in, for example "galliaApril".++Alongside those, gated commands (the ones that ask your permission) also carry a+**reason**: a one-line, plain-language explanation of why the AI wants to do this+particular thing. Identity is set once per conversation. The reason is written fresh for+every single call.++## In the Activity Log++Every command line in the Activity Log now names its source:++```+thread "chip-fetcher tab 3" in galliaApril — reason: checking whether the gerber zip finished downloading+```++Scanning the log tells you at a glance which conversation has been busy, and what it+thought it was doing.++## In the approval toast++Windows notifications have a dedicated attribution slot: a separated, greyed line under+the main content. Adom Desktop puts the thread and container there, so the toast reads+roughly like this:++```+  Adom Desktop: approval needed++  run_script wants to run a bash script.+  The AI says: checking whether the gerber zip finished downloading++  chip-fetcher tab 3 · galliaApril+  ────────────────────────────────────+  [ Approve 1 hr ]  [ Approve 24 hr ]  [ Deny ]+```++So before you click anything, you can see three things: what is being asked, why the AI+says it needs it, and which of your tabs is asking. The same information appears in the+in-window approval dialog if you prefer to grant permission there.++Toasts sent by an AI through `notify_user` pick up the same attribution automatically,+so a notification from a background thread is labelled without the AI doing anything+extra.++## The honest caveat: thread names are self-reported++This is worth understanding clearly.++The **thread name is chosen by the AI itself**. Adom Desktop records it and displays it,+but it cannot verify it. It is a label, not a credential. Nothing in the system grants+or denies permission based on a thread name, and you should not treat one as proof of+anything.++The **container name is different**. Adom Desktop knows the verified container from the+authenticated relay connection, independently of anything the AI claims. When the+self-reported container and the verified one disagree, both are shown so the discrepancy+is visible rather than silently resolved.++The short version: caller identity is for **visibility**, not security. Your actual+security boundary is the transport itself (an authenticated relay connection, plus the+permission prompts you answer). Self-reported is fine for the job it does: these are your+own tabs in your own containers, and the problem being solved is telling them apart.++## Bridges can use it too++Adom Desktop passes the caller information along to bridges (the components that drive+KiCad, Fusion, a browser, and so on) with every request it relays. A bridge can use that+to log activity per thread, to label a window it opens with the conversation that owns+it, or to arbitrate when two threads want the same resource at the same time.++So over time you should expect the "which tab did this?" answer to show up in more+places than just the Activity Log and the toast.++## One place it changes behaviour++Killing a bridge affects every conversation using it, so it now gets a small guard. If+other threads have been active in the last five minutes, the first attempt to kill a+bridge is refused, and the refusal **names those threads**. The AI has to explicitly+confirm before proceeding.++This is not a permission prompt for you. It is a speed bump for the AI, so that a tab+does not casually restart a bridge that another one of your conversations is in the+middle of using.++## What an AI has to do++Nothing you need to manage, but useful to recognise if you are reading along.++A conversation names itself once at the start of a session, usually by setting an+environment variable, after which the identity is attached to every command+automatically. If it does not, the first relayed command is refused with a message+explaining exactly what to set. Local callers are exempt, because they are already+trusted by how they connect: Hydrogen Desktop, a bridge calling back into Adom Desktop,+and the command line tool running on your own machine.++The one thing worth doing yourself: if a thread names itself something unhelpful (a+random identifier, or just "agent"), tell it what you call that conversation. That name+is what you will read on every approval toast it sends you.