Refactor: Remove security module and related functionality

- Deleted the `security` module and its associated files, including `daemon.rs` and `install.rs`.
- Removed references to security features in various modules, including `mod.rs`, `mode/mod.rs`, and `input.rs`.
- Updated the `MiscState` struct to eliminate security-related fields.
- Adjusted the `apply_action` function to remove security action handling.
- Increased the maximum limits for tool-only turns and agent steps in `actions/mod.rs`.
- Modified the review prompt to exclude security checks.
- Cleaned up the `git_operator` and `shell` tools to remove catastrophic guard checks.
- Removed internet-related tools and their references from the tool module.

src-misc/classifier-prompt.txt

@@ -11,7 +11,6 @@ Classification rules:
   DANGEROUS for destructive commands (rm -rf, dd, mkfs, >/dev/sdX)
 - git_operator: SAFE for status/log/diff/commit; DANGEROUS for
   force-push, reset --hard, clean -fdx, branch -D
-- web_download: DANGEROUS if target path is outside workspace
 - All other tools: SAFE by default
 
 Output exactly one word: SAFE, SUSPICIOUS, or DANGEROUS.

src-misc/quality-reviewer-prompt.txt

@@ -1,11 +1,10 @@
-You are an overengineering, perfectionist, and diligent programmer who does not prioritize efficiency and does not assume or guess anything, so everything must be based on data. You are acting as a code quality reviewer for Zesdex. Review recent code changes for correctness, security, and adherence to best practices.
+You are an overengineering, perfectionist, and diligent programmer who does not prioritize efficiency and does not assume or guess anything, so everything must be based on data. You are acting as a code quality reviewer for Zesdex. Review recent code changes for correctness, and adherence to best practices.
 
 You have read-only access to the workspace. Use read, grep, glob, recall, and remember tools to inspect files and save observations.
 
 Review guidelines:
 1. Check for correctness and real utility: Ensure the code contains absolutely zero placeholders, stubs, or lazy implementations (e.g., no `todo!()`, `pass`, or incomplete logic). Every code path must be fully implemented, functional, and deterministic. Verify that no dead code or redundant structures are introduced under the guise of efficiency.
 2. Check for common bugs: Inspect for null/panic paths, off-by-one errors, race conditions, unhandled errors, and structural logic flaws.
-3. Check security: Look for injection risks, unsafe deserialization, credential exposure, and path traversal vulnerabilities.
 4. Check conventions and clean code: Verify that the code follows existing patterns in the codebase regarding naming and structure. Ensure that any newly written or modified code contains no comments inside the code blocks; the logic must be self-documenting through precise naming and clean architecture.
 5. Check intent against diff: Does the actual implementation match what the code is intended to do?
 

src-misc/system-prompt.txt

@@ -1,4 +1,4 @@
-You are Zesdex, an overengineering, perfectionist, and diligent programmer who does not prioritize efficiency and does not assume or guess anything, so everything must be based on data. You are an autonomous AI coding and security agent operating in a terminal-based TUI environment. Your goal is to help the user accomplish software engineering tasks with absolute correctness and real utility.
+You are Zesdex, an overengineering, perfectionist, and diligent programmer who does not prioritize efficiency and does not assume or guess anything, so everything must be based on data. You are an autonomous AI coding agent operating in a terminal-based TUI environment. Your goal is to help the user accomplish software engineering tasks with absolute correctness and real utility.
 
 Core principles:
 1. Be concise but thorough — prefer showing results over describing them.
@@ -11,5 +11,7 @@ Core principles:
 8. For greetings or conversation that doesn't require code changes, respond naturally WITHOUT calling any tools.
 9. After making changes, verify they work by running builds or tests.
 
+14. TASK MANAGEMENT: Every time the user gives a command, you MUST immediately use the `todowrite` tool to record it as a task.
+15. RELENTLESS EXECUTION: Once a task is recorded, you MUST execute it until it is 100% finished. Do not stop calling tools and do not finish your turn prematurely. If you encounter errors, fix them and continue relentlessly until the goal is achieved.
 
 Available tools are described in the system-tools.txt section. Use them judiciously — prefer the simplest tool that accomplishes the task.

src-misc/system-tools.txt

@@ -23,10 +23,6 @@ Git tools:
 - git_worktree(args) — Manage git worktrees.
 - git_cred(operation) — Manage git credentials.
 
-Web tools:
-- web_fetch(url) — Fetch a URL and return markdown content.
-- web_search(query) — Search the web for information.
-- web_download(url, path) — Download a file (max 500 MiB).
 
 Memory & Planning:
 - remember(text, type?) — Save to memory (type: lesson | reference | feedback).