Merge branch 'main' of bitbucket.org:siakitem/my-pi

# Conflicts:
#	AGENTS.md
#	README.md
#	package-lock.json
#	package.json
#	pi-tool-search/CHANGELOG.md
#	pi-tool-search/README.md
#	pi-tool-search/docs/dynamic-tool-loading.md
#	pi-tool-search/extensions/bundle-groups.ts
#	pi-tool-search/test/bundle-groups.test.ts

pi-permission-system/docs/configuration.md

@@ -177,12 +177,14 @@ Some extensions replace `bash` with a differently-named tool — for example [`@
 Without a hint, the permission system cannot tell that such a tool is really a shell, so it gates it as a generic extension tool and the bash rules never apply.
 
 `shellTools` records that hint, and an aliased tool is then gated at full parity with native `bash` — command decomposition, wrapper flooring, path and external-directory token gates, and `bash:` rules — with the invoked tool name preserved in the review log.
+If the extension registers a custom input formatter for the aliased tool, its preview is also carried as authorization evidence and persisted in the permission review context. This lets wrappers disclose execution context that is not part of the command itself, such as an SSH target, container, or remote working directory.
 Each key is a tool name; its value maps the tool's input arguments (the keys of the tool call's `arguments` object):
 
 ```jsonc
 {
   "shellTools": {
-    "exec_command": { "commandArgument": "cmd", "workdirArgument": "workdir" }
+    "exec_command": { "commandArgument": "cmd", "workdirArgument": "workdir" },
+    "ssh_bash": { "commandArgument": "command", "decisionFloor": "ask" }
   }
 }
 ```
@@ -191,12 +193,13 @@ Each key is a tool name; its value maps the tool's input arguments (the keys of
 | ----------------- | -------- | ------------------------------------------------------------------------- |
 | `commandArgument` | yes      | The tool's input argument holding the shell command string (e.g. `cmd`).  |
 | `workdirArgument` | no       | The tool's input argument holding the working directory (e.g. `workdir`). |
+| `decisionFloor`   | no       | `"ask"` raises Bash `allow` to `ask`; existing `ask`/`deny` are preserved. |
+
+Use `decisionFloor: "ask"` when the aliased shell crosses an extra trust boundary, such as SSH or container execution. With yolo mode disabled, every otherwise-allowed invocation then reaches the configured authorizer chain unless deterministic Bash, path, or external-directory policy already denies it. Only `"ask"` is accepted; the setting cannot weaken a hard deny.
 
 When `workdirArgument` is set, the tool's working directory is the base the command's relative paths resolve against, and the working directory itself is gated by `external_directory` when it falls outside the session's working directory.
 
-Merge semantics: `shellTools` **shallow-merges by tool name** across global → project.
-A project entry overrides a specific tool's mapping on a key collision but never drops a global entry — so adding a project-scoped alias cannot silently remove enforcement for a tool the global config already covers.
-To change a specific tool's mapping, set that tool's key at the project scope (the alias object is replaced wholesale, not deep-merged).
+Merge semantics: `shellTools` merges by tool name and then by descriptor field across global → project. Project values can replace argument names, but omitting a globally configured `decisionFloor: "ask"` does not remove it. Because no weaker floor value is valid, a project cannot downgrade that global review boundary.
 
 `shellTools` only ever *tightens* enforcement and is inert when the named tool is not registered in the current session.
 Opting a project out of a shell-aliasing extension is a package-disable concern, not a `shellTools` edit.