feat - LSP data layer + confirmationService skeleton （Auto-approve Part 1 )#132
feat - LSP data layer + confirmationService skeleton （Auto-approve Part 1 )#132xinyi-gong wants to merge 3 commits intofeature/auto-approvefrom
Conversation
xinyi-gong
force-pushed
the
tori/auto-approve-task-1
branch
from
43ee7e3 to
320cec3
Compare
| * request should be auto-approved or shown to the user. Currently a no-op skeleton that | ||
| * always requires confirmation; concrete logic will be added in subsequent sub-tasks. | ||
| */ | ||
| public class ConfirmationService { |
There was a problem hiding this comment.
Maybe move this class to core bundle?
There was a problem hiding this comment.
ConfirmationService depends on IPreferenceStore and will hold references to concrete handler implementations (TerminalConfirmationHandler, FileOperationConfirmationHandler, etc.) which live in the ui bundle.
| * @param params the confirmation request parameters from CLS | ||
| * @return the confirmation result (currently always {@link ConfirmationResult#NEEDS_CONFIRMATION}) | ||
| */ | ||
| public ConfirmationResult evaluate(InvokeClientToolConfirmationParams params) { |
There was a problem hiding this comment.
How will this class looks like ultimately? (I'm trying to understand why it is a standalone class, not just a utility)
There was a problem hiding this comment.
It's the central orchestrator for auto-approve. It holds a ToolCategory enum (matching CLS's ToolFunctionalType), a map of category and handler, reads the toolType from CLS confirmation requests to classify and dispatch. It also handles cross-cutting checks like YOLO mode before dispatching. It's a stateful service because handlers will eventually hold session-level memory for "Allow for Session" from the confirmation dialog.
2 participants
No description provided.