Generic Rule-Based Automation Framework

Замовник: AI | Опубліковано: 29.12.2025

CONFIDENTIAL PROJECT BRIEF (GENERIC RULE-BASED AUTOMATION FRAMEWORK) IMPORTANT NOTE FOR FREELANCER You are being hired only to build the framework (body). All intelligence, rules, business logic, strategies, and monetization will be injected later by the owner. Do NOT assume or embed any specific business domain. --- 1. PROJECT GOAL Build a professional, modular, rule-based automation agent framework that can: Execute browser-based workflows Communicate like a human (Telegram + Voice) Recover from errors safely Follow externally defined rules Escalate decisions for approval Run reliably on low-end hardware This is NOT a single-business bot. This is a reusable automation framework. -- 2. HARDWARE & DEPLOYMENT CONSTRAINTS (MANDATORY) The framework must work stably on: CPU: Intel i3 RAM: 8 GB GPU: None OS: Linux (self-hosted) Runtime: Docker / Docker Compose Browser: Single persistent browser instance LLM: Small local model support (3B–7B range) Design must avoid crash loops and auto-throttle under load. -- 3. CORE DESIGN PRINCIPLES (NON-NEGOTIABLE) Deterministic (rules > AI) Modular (isolated responsibilities) Safety-first Self-healing (controlled) Human-in-the-loop for risk Config-driven, not hardcoded No cloud dependency by default Owner retains full control --- 4. REQUIRED MODULES (FRAMEWORK SCOPE) 4.1 Supervisor / Orchestrator Central brain Controls execution order Schedules tasks Enforces rate limits & throttling Prevents infinite loops Coordinates all modules --- 4.2 Browser Automation Layer Single persistent browser JSON-defined actions only Screenshot on every failure DOM snapshot capture Retry with backoff No captcha bypass No parallel browser spawning --- 4.3 Business Rules Engine Reads from external config (rules.json) Versioned & auditable Hot-reload capable Agent must never invent rules Owner can update rules without code changes --- 4.4 Workflow Engine Converts intent → stepwise workflow Branching & conditional logic Idempotency protection Planning vs Execution separation Sandbox / dry-run support --- 4.5 Auto-Fix & Recovery Layer Detects: selector failures navigation issues timeouts Attempts safe recovery Logs fixes Stops after defined limits Never retries same failure endlessly --- 4.6 Safety & Anti-Loop Authority (CRITICAL) Single authority for: retry pause freeze shutdown escalation Hard retry caps Decision hash to block repeat loops No module can override safety freeze --- 4.7 Health Monitoring CPU / RAM / queue depth Graceful degradation Auto-slowdown instead of crash Disk usage guard --- 4.8 Communication — Telegram Human-like responses Hinglish support Short messages (max 3–4 lines) Approval requests Status updates No spam behavior Rate limited --- 4.9 Voice Call Framework (NO BUSINESS LOGIC) Incoming & outgoing calls Voice persona support (male / female) Calm, human tone Only for: support approval escalation Quiet hours enforcement No cold calling Telephony API pluggable (Twilio / Exotel / SIP) --- 4.10 Memory Store (Technical Only) Workflow state Selector history Error attempts No business intelligence by default Prunable / bounded --- 4.11 Logging & Audit Structured logs Traceable workflows Timestamped actions Error evidence (screenshots) Append-only style preferred --- 5. SECURITY CONSTRAINTS The framework must explicitly block: OTP handling Identity collection Direct payment execution Price mutation Illegal scraping Unapproved irreversible actions All high-risk actions must expose approval hooks. --- 6. COMMUNICATION BEHAVIOR Default language: Hinglish Tone: Human, calm, assistant-like Not robotic Not verbose Confidence without arrogance --- 7. WHAT NOT TO BUILD (VERY IMPORTANT) Do NOT include: Any specific business logic Marketing strategies Monetization rules Growth assumptions Domain-specific code Dashboards with revenue KPIs Framework only. -- 8. DELIVERABLES Expert must provide: 1. Modular codebase 2. Dockerized setup (single-click run) 3. Clear module boundaries 4. Config-driven behavior 5. Documentation: Architecture How to inject rules Safety & recovery design 6. Basic test & sanity checks 7. Clean handover -- 9. HANDOVER & OWNERSHIP No ongoing dependency on expert No hardcoded secrets Owner can extend independently Framework reusable for multiple use cases --- 10. ACCEPTANCE CRITERIA Runs stable on low hardware Infinite loops structurally impossible Clear separation: Framework (expert) Intelligence (owner) Telegram responses working Safety authority enforceable -- 11. QUOTATION REQUEST Please share: Total development cost Timeline What is included / excluded Post-handover support (optional) --- CONFIDENTIALITY This brief is framework-only. Any attempt to infer business intent is out of scope. --- FINAL LINE FOR FREELANCER > This is not a demo bot. This is a serious, rule-based automation framework where the brain will be added later by the owner. Thank you.