feat: vendor permission system source

2026-08-28 08:35:57 +00:00 · 2026-08-19 14:35:19 +08:00
parent 198584daf8
commit 410c50a3e5
809 changed files with 157793 additions and 139 deletions
@@ -0,0 +1,40 @@
+---
+issue: 51
+issue_title: "Generalize session approvals to all permission surfaces with wildcard patterns"
+---
+
+# Retro: #51 — Generalize session approvals to all permission surfaces with wildcard patterns
+
+## Final Retrospective (2026-05-04T23:36Z)
+
+### Session summary
+
+Implemented generalized session approvals across all permission surfaces (bash, mcp, skill, tools) in 6 commits released as v4.3.0.
+The work added a `pattern-suggest` module, extended `checkPermission` session evaluation to all surface branches, wired the gate with `sessionApproval` pass-through, made the dialog label dynamic, and threaded `sessionLabel` through the full prompt chain. 44 new tests (754 → 798), all green, no breaking changes.
+
+### Observations
+
+#### What went well
+
+- TDD cycle was clean across all 5 steps — every step went red→green on first implementation attempt with no rework.
+- The existing `evaluate()` engine handled cross-surface session rules without modification; the work was purely additive at the `checkPermission` and handler layers.
+- The `suggestSessionPattern` design as pure functions with no IO made step 1 trivially testable.
+
+#### What caused friction (agent side)
+
+- `missing-context` — The plan's "Module-Level Changes" listed `tool-call.ts`, `permission-gate.ts`, `permission-dialog.ts`, and `permission-prompts.ts` for step 5, but the actual `sessionLabel` threading required changes to `src/handlers/types.ts`, `src/forwarded-permissions/polling.ts`, and `src/runtime.ts` (the full callback chain).
+  I had to trace the chain at implementation time: `deps.promptPermission` → `runtime.promptPermission` → `confirmPermission` → `requestPermissionDecisionFromUi`.
+  Impact: ~5 extra read/grep calls to map the chain before writing code.
+  No rework, but added friction.
+- `missing-context` — First `Edit` attempt on `tests/handlers/tool-call.test.ts` failed with "Found 2 occurrences" because the file had two identical closing sequences (`expect(result).toEqual({});\n  });\n});\n`).
+  Impact: one failed tool call, immediate retry with wider context.
+  Self-identified.
+
+#### What caused friction (user side)
+
+- No significant friction from the user side.
+  The plan was well-specified and the session flow was smooth.
+
+### Changes made
+
+1. Added planning guidance to `AGENTS.md` (Testing section): plans must list every file in callback/threading chains, not just entry and exit points.