Class: Pikuri::Tool::Confirmer
- Inherits:
-
Object
- Object
- Pikuri::Tool::Confirmer
- Defined in:
- lib/pikuri/tool/confirmer.rb
Overview
Port for asking the user to confirm a potentially destructive tool operation — currently Bash (every command) and Write (overwrite of an existing file with non-identical content). Subclass and implement #confirm?.
Why a Boolean return
v1 returns true or false. Two paths-not-taken worth recording so a future reader knows the design space was considered:
-
Richer return (
:once/:always/:reject) — rejected because it creates decision fatigue, and the long-term answer is to make confirmations rare rather than smart (sandboxing, agentic destructiveness analysis). -
Agentic destructive-or-not classifier — deferred to v2.
The intended escape from confirmation prompts today is sandboxing (docker / dev-container) plus the --yolo flag on bin/pikuri-code (which wires AUTO_APPROVE instead of TERMINAL).
Seam discipline
Tools that need confirmation take a Confirmer via constructor and invoke #confirm? with a fully-composed prompt String. Tools do not call gets / puts directly — same lesson as listeners, keep IO at the seam so a future TUI / web client can plug a different implementation in without touching tool code.
Direct Known Subclasses
Defined Under Namespace
Classes: AutoApprove, Terminal
Constant Summary collapse
- TERMINAL =
Shared singleton instance of Terminal. Stateless; reusable across tools and sub-agents.
Terminal.new
- AUTO_APPROVE =
Shared singleton instance of AutoApprove.
AutoApprove.new
Instance Method Summary collapse
-
#confirm?(prompt:) ⇒ Boolean
trueiff approved.
Instance Method Details
#confirm?(prompt:) ⇒ Boolean
Returns true iff approved.
39 40 41 |
# File 'lib/pikuri/tool/confirmer.rb', line 39 def confirm?(prompt:) raise NotImplementedError, "#{self.class}#confirm? must be implemented" end |