adilmunawar/jarvis

1. Overall shape

This is a Python-based personal assistant/JARVIS-style automation system. The repository is organized around a central “brain” that routes user commands into specialized modules for speech, automation, web tasks, vision, and utility features.

2. Primary entry points

jarvis.py appears to be the main runtime entry point described in the README. Supporting top-level scripts like ui.py, demo.py, and co_brain.py likely provide alternate frontends, demos, or coordination logic around the core assistant loop.

3. Core command-routing layer

The Brain/brain.py, Automation/Automation_Brain.py, Time_Operations/brain.py, and Vision/MVbrain.py / Vision/Vbrain.py files suggest a multi-brain architecture: one central orchestration layer plus domain-specific routers. These components likely classify commands and dispatch them to the correct subsystem instead of keeping all logic in one place.

4. Speech input and speech output

Voice interaction is a first-class path. NetHyTechSTT/listen.py handles speech-to-text input, while TextToSpeech/Fast_DF_TTS.py provides text-to-speech output. The presence of files like speech_output.txt, input.txt, and conversation-history logs indicates the assistant also persists spoken/text exchanges for debugging or context.

5. Task automation subsystem

The Automation/ package is the main action layer for controlling the machine and browser. It includes modules for opening apps, tab automation, scrolling, battery checks, YouTube playback, Spotify playback, web opening, and web data fetching. This is the boundary where abstract commands become OS/browser actions.

6. Feature/utility modules

Features/ contains small capability-focused helpers such as volume control, microphone/speaker health checks, battery percentage, IP lookup, jokes, advice, clap detection, and file creation. These are likely invoked by the brain when a command matches a narrow utility task.

7. Web and online integrations

Several folders point to external-service driven features: Real_Time/ for Google search flows, Weather_Check/check_weather.py for weather, and Whatsapp_automation/wa.py for WhatsApp automation. Automation/Play_Music_YT.py, Automation/Youtube_play_back.py, and Spotify-related code show direct dependence on online media platforms.

8. Scheduling and time-based behavior

Time_Operations/ and schedule.txt indicate reminder/alarm/scheduler support. Time_Operations/throw_alert.py likely triggers notifications or alerts based on parsed times, while this subsystem handles deferred actions rather than immediate commands.

9. Vision and image generation

The Vision/ package suggests optional camera/image-based features, separate from voice. TextToImage/gen_image.py indicates the assistant can also generate images from text, which is a distinct capability path from command automation.

10. Data and context persistence

Data/DLG_Data.py, Alam_data.txt, chat_hystory.txt, conv_history.txt, history.txt, and log.txt show local data storage for dialogue, alarms, and logs. This repo appears to rely on flat files rather than a database for conversation state and lightweight memory.

11. External tooling and platform coupling

chromedriver.exe makes browser automation a concrete dependency, likely for Selenium-style control of Chrome. requirements.txt and setup.py define the Python environment, so the architecture is strongly tied to local desktop execution rather than a cloud service.

12. Likely runtime flow

The expected flow is: user speaks or types a command → STT/input layer captures it → the brain/router identifies intent → a specialized module performs the action (system, web, media, reminder, vision, etc.) → TTS or UI returns the result. The repo is therefore best understood as a local, modular desktop assistant with several service-specific adapters behind one command interface.