subbajandyala/stockanalyser

This repository is a small Python stock-screening application centered around a single package, screener, with app.py as the top-level entry point. The codebase is organized more by analysis capability than by UI or service layers.

1. Entry point and orchestration

- app.py is the likely coordinator for running screening jobs or exposing a simple CLI/script workflow.

- It probably pulls together data retrieval, technical analysis, and strategy-specific screeners from the screener package.

2. Domain package: screener/

- The main business logic lives in screener.

- This package appears to represent a stock-analysis domain with reusable technical utilities plus separate screening strategies.

3. Market data / stock universe layer

- screener/stocks.py likely handles stock symbol lists, watchlists, or market universe selection.

- This is the boundary where the app decides which instruments to evaluate before any technical logic runs.

4. Technical-analysis core

- screener/technical.py is the shared indicator/analytics layer.

- It likely computes common series used by multiple screeners, such as moving averages, trend signals, or support/resistance related values.

- This module is the main internal dependency for the strategy modules.

5. Strategy-specific screeners

- screener/ma50_support.py, screener/ma_crossover.py, and screener/ma_retracement.py look like three distinct screening rules built around moving averages.

- Each module likely encapsulates one interpretation of price action:

- 50-day moving average support behavior

- moving-average crossover signals

- retracement relative to a moving-average trend

- This separation suggests a modular strategy design where each screener can be run independently or combined by app.py.

6. News integration

- screener/news.py indicates a second signal source beyond technicals.

- Its role is probably to fetch or summarize headlines and attach qualitative context to a stock scan.

- Architecturally, this is an auxiliary enrichment layer rather than the core decision engine.

7. Data flow through the application

- Typical flow is: select symbols in stocks.py → load/analyze price data in technical.py → apply one or more moving-average screeners → optionally enrich with news.py → return or print results from app.py.

- The main output is likely a ranked or filtered set of candidate stocks rather than persisted state.

8. Package boundary and reuse

- The screener package acts as the internal API boundary for the application.

- Shared technical logic is centralized, while strategy files remain small and purpose-specific, which keeps the architecture easy to extend with more screens.

9. Testing

- The test/ directory shows that analysis logic is intended to be testable as pure Python functions or small units.

- Given the modular layout, tests likely focus on indicator calculations and screener decision rules rather than full end-to-end system behavior.

10. Automation / CI

- .github/workflows/static.yml suggests GitHub Actions is used for automated validation, likely static checks or linting.

- This points to a lightweight, repository-level delivery model with no separate deployment infrastructure visible in the tree.

11. Dependencies and runtime

- requirements.txt indicates a standard Python runtime with external packages for data analysis, technical indicators, or data access.

- The architecture is therefore dependency-light and script/package oriented, not a microservice or web framework architecture.

12. Overall shape

- The system is best described as a modular Python stock-screener:

- one orchestration script,

- one reusable analysis package,

- multiple strategy modules,

- optional news enrichment,

- tests and CI around the core logic.

- An architecture diagram should emphasize the flow from symbol selection to analysis to screening results, with technical.py and the moving-average strategy modules as the central computational core.