grim-sudo/busqueda

1. Top-level deployment: this repo is built to run as a single Docker container. The runtime boundary is one Linux container with Nginx on port 80, a Flask backend in Python 3, and an internal Gitea simulation on port 3000. There is no separate database, message queue, or external SaaS dependency.

2. Request ingress and routing: all browser traffic enters through Nginx. Nginx serves the compiled frontend assets and forwards application requests to the Flask API. The frontend is built during image creation, so the final container does not need Node.js at runtime.

3. Frontend subsystem: the UI is a Vite + React + TypeScript app under frontend/. It is a small client-side dashboard with three visible pieces: SearchPanel, ServiceTable, and StatusBar. The UI is responsible for calling backend endpoints and rendering service registry/status data; it does not do server-side rendering.

4. Backend API subsystem: backend/app.py is the main Flask application. It exposes:

- GET /api/status for basic application metadata,

- GET /api/health for container health and internal IP visibility,

- GET /api/services for the full registry dataset, protected by an X-Api-Key,

- POST /search for service search.

This backend is the central business-logic layer for the app.

5. Data model / registry source: the service inventory appears to come from backend-local code, primarily fake_services.py and configuration in config.py. The backend acts as the authoritative source for service registry content that the frontend displays.

6. Static asset delivery: the frontend bundle and public assets are served as static files, likely through the Flask/Nginx combination rather than a separate CDN or app server. That means the browser talks to one origin for both UI and API, simplifying the diagram to a single user-facing entry point.

7. Internal simulation service: backend/gitea_sim.py represents an internal Gitea-like service used for the lab theme. It is not a full external dependency; it exists inside the container boundary to simulate a developer repository exposure and to support the challenge narrative around leaked implementation details.

8. Startup and orchestration: entrypoint.sh is the container bootstrap layer. It coordinates startup of the web stack and any initialization needed for the runtime environment, while backend/scripts/system_check.py suggests an internal diagnostic or readiness-check path.

9. Configuration boundaries: backend/config.py and backend/nginx.conf are the main operational configuration points. They define runtime behavior such as service addresses, proxy behavior, and environment-sensitive values like the embedded container IP or flag defaults mentioned in the README.

10. Security-relevant architecture: the repo intentionally contains an exposed .git directory served as static content and a vulnerable /search path that uses templating on user input. Those are not separate subsystems, but they are important boundaries in the architecture because they bridge the public web tier to privileged backend behavior.

11. Overall data flow: browser → Nginx → Flask API → registry data / simulated internal services. The frontend consumes status and service data, while the search path accepts user-supplied formatting parameters that are processed server-side. The internal Gitea simulation and exposed repo metadata act as supporting sources for the lab’s intended workflow.

12. Operational shape: this is best diagrammed as a monolith-in-a-container with a proxy front end, a single Python application backend, and a compiled SPA frontend. The main architectural separation is between public web ingress, application logic, and internal simulation/debug artifacts rather than between multiple deployable services.