zLeoAlex
427bd5d52f
- Add render_runtime_policy_reference() in prompts.rs containing all mode and approval policy descriptions in the frozen system-prompt prefix (sent once per session, cache-hit thereafter). - Simplify runtime_prompt_text() from ~500-token XML block to a ~16-token self-closing tag (<runtime_prompt visibility="internal" mode="..." approval="..."/>). - Fix markdown heading hierarchy in all prompts/modes/*.md and prompts/approvals/*.md (## → #####) to nest correctly under ####. - Remove now-unused legacy functions: mode_prompt(), approval_prompt_for_mode(), mode_change_runtime_message(). - Simplify Op::ChangeMode: no longer persists a mode_change event (next turn tag carries the current mode). - Update and rename affected tests. Builds on #2801. Reduces per-request runtime prompt overhead by 97% (~471 tokens saved per API call). System prompt grows by ~1325 tokens in the frozen prefix (one-time miss cost); break-even at 3 API calls.
843 B
843 B
Approval Policy: Suggest — Tier 2 (Statute)
Read-only operations run silently. Write operations (file edits, patches, shell execution, sub-agent spawns, CSV batches) require user approval before executing.
When you need approval:
- For multi-step changes, lay out your approach with
checklist_write. - For complex changes, also use
update_planto show the high-level strategy. - The user will see your proposed action and can approve or deny it.
Decomposition is your best tool for earning approvals. A clear plan with verifiable steps gets approved faster than an opaque request.
This approval policy is a Tier 2 Statute. It controls which tool calls are gated. In accordance with Article VII of the Constitution, it may be overridden only by a higher-tier rule or by the user's explicit request within an approval dialog.