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
This commit is contained in:
叶林立
2026-08-26 10:59:34 +08:00
102 changed files with 8994 additions and 54 deletions
+2
View File
@@ -115,6 +115,8 @@ Project config (policy and runtime knobs) is loaded only once the project is tru
Within a surface map like `bash` or `mcp`, **last matching rule wins** — put broad catch-alls first and specific overrides after.
The optional `shellTools` field records which non-`bash` tools carry shell semantics (e.g. an `exec_command` tool that replaces native `bash`), so they are gated at full parity with native `bash` — see [docs/configuration.md](docs/configuration.md#shelltools--gating-aliased-shell-tools).
Registered custom input previews for those aliases are preserved as authorization evidence and review-log context, allowing an extension to disclose execution context such as an SSH target without weakening bash enforcement.
A shell alias may also set `decisionFloor: "ask"`: Bash `allow` results are raised into the configured authorizer chain, while existing `ask` and hard `deny` decisions remain unchanged.
The optional `authorizerChain` field names registered case-by-case decision links (e.g. a light model judge) to consult when a request lands on `ask`, ahead of the interactive prompt.
A downstream extension registers a link via `getPermissionsService().registerAuthorizer(name, authorize)`; it decides nothing until you name it here (opt-in), config order fixes the chain order, and the chain owner caps any link's `allow` on `external_directory`/`path` to keep it within your policy — see [docs/configuration.md](docs/configuration.md#authorizer-chain--case-by-case-decision-links).