feat: refactored and tweaked model descriptions / schema to use fewer tokens at launch (average reduction per field description: 60-80%) without sacrificing tool effectiveness

Disabled secondary tools by default (for new installations), updated README.md with instructions on how to enable these in .env
run-server.sh now displays disabled / enabled tools (when DISABLED_TOOLS is set)
This commit is contained in:
Fahad
2025-08-22 09:23:59 +04:00
parent 6921616db3
commit 4b202f5d1d
31 changed files with 409 additions and 609 deletions

View File

@@ -36,85 +36,40 @@ logger = logging.getLogger(__name__)
# Tool-specific field descriptions for security audit workflow
SECAUDIT_WORKFLOW_FIELD_DESCRIPTIONS = {
"step": (
"Describe what you're currently investigating for security audit by thinking deeply about security "
"implications, threat vectors, and protection mechanisms. In step 1, clearly state your security "
"audit plan and begin forming a systematic approach after identifying the application type, "
"technology stack, and relevant security requirements. You must begin by passing the file path "
"for the initial code you are about to audit in relevant_files. CRITICAL: Follow the OWASP Top 10 "
"systematic checklist, examine authentication/authorization mechanisms, analyze input validation "
"and data handling, assess dependency vulnerabilities, and evaluate infrastructure security. "
"Consider not only obvious vulnerabilities but also subtle security gaps, configuration issues, "
"design flaws, and compliance requirements. Map out the attack surface, understand the threat "
"landscape, and identify areas requiring deeper security analysis. In all later steps, continue "
"exploring with precision: trace security dependencies, verify security assumptions, and adapt "
"your understanding as you uncover security evidence."
),
"step_number": (
"The index of the current step in the security audit sequence, beginning at 1. Each step should "
"build upon or revise the previous one."
),
"total_steps": (
"Your current estimate for how many steps will be needed to complete the security audit. "
"Adjust and increase as new security findings emerge."
),
"next_step_required": (
"Set to true if you plan to continue the investigation with another step. False means you believe "
"the security audit analysis is complete and ALL threats have been uncovered, ready for expert validation."
"Audit plan. Step 1: State strategy. Later: Report findings. "
"MANDATORY: Systematic approach (OWASP Top 10, auth, validation). Use 'relevant_files'. NO large code."
),
"step_number": "Current step in audit sequence (starts at 1).",
"total_steps": "Estimated steps for audit. Adjust as findings emerge.",
"next_step_required": ("True to continue. False when ALL threats uncovered, ready for validation."),
"findings": (
"Summarize everything discovered in this step about security aspects of the code being audited. "
"Include analysis of security vulnerabilities, authentication/authorization issues, input validation "
"gaps, encryption weaknesses, configuration problems, and compliance concerns. Be specific and avoid "
"vague language—document what you now know about the security posture and how it affects your "
"assessment. IMPORTANT: Document both positive security findings (proper implementations, good "
"security practices) and concerns (vulnerabilities, security gaps, compliance issues). In later "
"steps, confirm or update past findings with additional evidence."
),
"files_checked": (
"List all files (as absolute paths, do not clip or shrink file names) examined during the security "
"audit investigation so far. Include even files ruled out or found to be unrelated, as this tracks "
"your exploration path."
"Discoveries: vulnerabilities, auth issues, validation gaps, compliance. "
"Document positives and concerns. Update past findings."
),
"files_checked": "All files examined (absolute paths). Include ruled-out files.",
"relevant_files": (
"For when this is the first step, please pass absolute file paths of relevant code to audit (do not clip "
"file paths). When used for the final step, this contains a subset of files_checked (as full absolute paths) "
"that contain code directly relevant to the security audit or contain significant security issues, patterns, "
"or examples worth highlighting. Only list those that are directly tied to important security findings, "
"vulnerabilities, authentication issues, or security architectural decisions. This could include "
"authentication modules, input validation files, configuration files, or files with notable security patterns."
"Step 1: Files to audit (absolute paths). " "Final: Files with security issues, auth modules, config files."
),
"relevant_context": (
"List methods, functions, classes, or modules that are central to the security audit findings, in the "
"format 'ClassName.methodName', 'functionName', or 'module.ClassName'. Prioritize those that contain "
"security vulnerabilities, demonstrate security patterns, show authentication/authorization logic, or "
"represent key security architectural decisions."
"Security-critical methods/classes: 'ClassName.methodName'. "
"Focus on vulnerabilities, auth logic, security patterns."
),
"issues_found": (
"List of security issues identified during the investigation. Each issue should be a dictionary with "
"'severity' (critical, high, medium, low) and 'description' fields. Include security vulnerabilities, "
"authentication bypasses, authorization flaws, injection vulnerabilities, cryptographic weaknesses, "
"configuration issues, compliance gaps, etc."
"Security issues as dict: 'severity' (critical/high/medium/low), 'description'. "
"Include vulnerabilities, auth flaws, injection, crypto weakness, config issues."
),
"confidence": (
"Indicate your current confidence in the security audit assessment. Use: 'exploring' (starting analysis), "
"'low' (early investigation), 'medium' (some evidence gathered), 'high' (strong evidence), "
"'very_high' (very strong evidence), 'almost_certain' (nearly complete audit), 'certain' "
"(100% confidence - security audit is thoroughly complete and all significant security issues are identified with no need for external model validation). "
"Do NOT use 'certain' unless the security audit is comprehensively complete, use 'very_high' or 'almost_certain' instead if not 100% sure. "
"Using 'certain' means you have complete confidence locally and prevents external model validation."
),
"backtrack_from_step": (
"If an earlier finding or assessment needs to be revised or discarded, specify the step number from which "
"to start over. Use this to acknowledge investigative dead ends and correct the course."
"exploring/low/medium/high/very_high/almost_certain/certain. "
"CRITICAL: 'certain' PREVENTS external validation."
),
"backtrack_from_step": "Step number to backtrack from if revision needed.",
"images": (
"Optional list of absolute paths to architecture diagrams, security models, threat models, or visual "
"references that help with security audit context. Only include if they materially assist understanding "
"or assessment of security posture."
"Optional: Architecture diagrams, security models, threat models (absolute paths). "
"Only if assists security assessment."
),
"security_scope": (
"Define the security scope and application context (web app, mobile app, API, enterprise system, "
"cloud service). Include technology stack, user types, data sensitivity, and threat landscape. "
"Security context (web/mobile/API/enterprise/cloud). "
"Include stack, user types, data sensitivity, threat landscape. "
"This helps focus the security assessment appropriately."
),
"threat_level": (