ticket: use base32 project record ids

2026-06-09 22:10:47 +09:00
parent 0803bc3725
commit 4203988d74
798 changed files with 477 additions and 105 deletions
@@ -0,0 +1,30 @@
+# Decision: narrow plugin permissions to host authorities
+
+Plugin/Feature permission should mean user-approved host authority, not every contribution the feature declares.
+
+Purpose:
+
+- Explain to the user what dangerous host authority a plugin receives.
+- Ensure sandboxed/external plugin code is not given APIs or handles for unapproved actions.
+- Keep registry contribution integrity separate from authority grants.
+
+Revised model:
+
+- Contributions are descriptor/digest-locked declarations:
+  - Tools
+  - Hooks
+  - BackgroundTasks
+  - Service providers
+- Host authorities are user-approved sandbox/object-capability grants:
+  - filesystem access
+  - network access
+  - secret refs
+  - model-visible durable notification/history append
+  - Pod management façade access where exposed
+  - store/state access such as Memory/WorkItem or persistent plugin state where applicable
+
+Tool/Hook/BackgroundTask/ServiceProvider declarations should be shown during install and locked by plugin descriptor/package digest. If they change, the plugin requires re-approval. They do not need separate `ContributeTool`, `ContributeHook`, `RunBackgroundTask`, or `ProvideService` authority variants.
+
+Service consumption is also not a blanket authority by itself. A service requirement is resolved by the host; the authority question depends on what host authority the service handle exposes. Service handles should be narrowed or authority-bound so acquiring one broad service handle cannot become an authority escalation path.
+
+Tool execution remains governed by the existing per-call tool permission / PreToolCall path. Feature authority grants do not replace manifest/tool permissions.