# Explain the Architecture of a Django Codebase Yes. An agent reads a Django codebase and returns architecture.md with the request path, data model, jobs and a diagram, citing files. [Run this on Rush](https://cloud.getrush.ai/run/architecture-overview/django/), in a Project that has your repository. ## What the agent does The agent maps the tree before it writes a sentence. In a project shaped like netbox-community/netbox, pyproject.toml names the project netbox and requires Python >=3.12, and requirements.txt pins Django==6.1.2, django-rq==4.2.0, rq==2.12.0, redis==8.1.0 and strawberry-graphql-django==0.93.0. The installable code lives under netbox/. The Django apps there are account, circuits, core, dcim, extras, ipam, tenancy, users, virtualization, vpn and wireless, plus utilities. netbox/netbox/wsgi.py sets DJANGO_SETTINGS_MODULE to netbox.settings and calls get_wsgi_application, then loads the URL resolver at import so a bad URLconf fails the worker at boot. That file is the entry the document starts from. The request it traces is a device page, because that is the object's own docstring of the product. dcim/models/devices.py defines Device as a subclass of PrimaryModel, with ContactsMixin, ImageAttachmentsMixin, RenderConfigMixin, ConfigContextModel and TrackingModelMixin. The docstring says a Device is hardware in a Rack, with a DeviceType, a DeviceRole and a site. The UI route is in dcim/urls.py: path devices/ and path devices// through get_model_urls. The API route is dcim/api/urls.py registering devices on a router, served by DeviceViewSet in dcim/api/views.py, which mixes in ConfigContextQuerySetMixin and NetBoxModelViewSet. Root wiring is netbox/netbox/urls.py: dcim/ and api/dcim/ are included from there, and graphql/ is NetBoxGraphQLView. The document follows one GET from urls.py to the view to Device.objects, and it names each file. Background work is RQ, not a second queue the agent invents. netbox/netbox/jobs.py defines JobRunner and the system_job decorator, imports rq.timeouts.JobTimeoutException, and records logs on a core.models.Job. netbox/netbox/constants.py sets RQ_QUEUE_DEFAULT to default and RQ_QUEUE_HIGH to high. The document lists those queues, says a system job is a JobRunner registered with an interval in minutes, and points at jobs.py for the traceback stripping that uses the install root. It does not describe Celery. Plugins are the include of plugin_patterns at plugins/ in urls.py, and the optional extras in pyproject.toml such as ldap, saml2 and s3. The document says they are off unless configuration enables them. It writes architecture.md only. No migration, no settings change, no commit. If a dependency is missing and the app cannot boot, the document is written from the files above and says the process was not started. A Mermaid diagram shows the browser hitting wsgi.py, the URL include for dcim, DeviceViewSet, the Device model, and a side arrow into an RQ queue. Every box names a path that exists in the tree. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "claude", "input": "Read this Django repository and write architecture.md. Cover the main apps and what each owns, the path of one typical request from the WSGI entry to the database, the data model for that request, background jobs, and a Mermaid diagram. Cite a file path for every claim. In a tree shaped like netbox-community/netbox, start at netbox/netbox/wsgi.py and netbox/netbox/urls.py, trace a device through dcim/urls.py and dcim/api/views.py DeviceViewSet to dcim/models/devices.py, and describe RQ from netbox/netbox/jobs.py and the queue names in netbox/netbox/constants.py. Do not change code. If you cannot boot the app, say so and write from the source.", "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token. 2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox. 3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory. ## What comes back What comes back is architecture.md as an artifact on the session. The session lists it with a name and a mime type, and a url on api.prix.dev that downloads that file with no key for an hour, until url_expires_at. Reading the session again returns a fresh url. GET /o/{org}/sessions/{id}/artifacts/architecture.md with the key also returns it. The result text may summarize the document. The file is the thing you keep. The document has a section per app under netbox/, a traced request for Device from wsgi.py through urls.py to DeviceViewSet and the model, a data-model section that quotes the mixins on the Device class, a jobs section that names the default and high RQ queues and JobRunner, and one Mermaid diagram whose nodes are file paths. Claims that are not tied to a path are not in the file. There is no pull request, because the prompt says not to change code. A reviewer checks three citations against the tree: Django==6.1.2 in requirements.txt, the Device class bases in dcim/models/devices.py, and RQ_QUEUE_HIGH in constants.py. A diagram that draws Celery, or a section that describes an app directory that is not in the tree, is sent back as a follow-up on the same session. The sandbox is still there for that follow-up. ## Run it on every new repository When your server learns a repository was created, POST this body to https://api.prix.dev/o/{org}/sessions with that repository in resources. Each repository gets its own architecture.md. The Rush GitHub App must be installed on it. An Idempotency-Key of the repository id keeps a repeated webhook from writing two documents for the same tree. Set webhook_url on the key so run.completed arrives with session_url. Download architecture.md from the session's artifacts list before the hour on url_expires_at, or call the artifacts route with the key, which does not depend on that hour. A key runs at most max_concurrent sessions at once, 4 by default, and further creates return 429. ## Why run it on Rush? Reading NetBox far enough to say how a device reaches the database means opening wsgi.py, urls.py, the dcim API view and jobs.py, and holding the queue names in your head while you write. The agent does that in a sandbox with its own clone, and the transcript shows which files it opened. Your checkout is not littered with a half-written notes file. The artifact is a file with paths a teammate can click, and the transcript is the record of the reads behind those paths. You can start the same request on several repositories at once. Each session returns its own architecture.md, and a follow-up on a parked sandbox can ask for the IPAM path without cloning again. ## Frequently asked questions ### Does it have to boot NetBox? The prompt says to write from source when the app cannot start. Django 6.1.2, Redis and a database are what a real boot needs, and a missing one is stated in the document rather than papered over. The request path is taken from urls.py and the view modules, which do not require a running server to cite. ### Will it open a pull request? No. The prompt forbids code changes, and this page's result is the file. architecture.md is an artifact on the session, not a commit. If you want the document in the repository, say so in a follow-up and the agent can open a pull request on the same sandbox. ### Does the diagram replace the file citations? No. The Mermaid diagram is one section. Every box names a path, and the prose cites the same paths. A diagram with no paths is not what the prompt asks for. The reviewer check is to open two of those paths and see the symbol the document names. ### GraphQL and REST are both in the tree. Which request does it trace? One request, the device UI and its REST view, because DeviceViewSet and dcim/urls.py are a single object with a docstring. graphql/ and strawberry-graphql-django are named as a second surface in the components section, not traced step by step, unless you ask for that path in a follow-up. ### How do I get the file after the run? The session's artifacts array includes architecture.md with a url that works without the API key until url_expires_at, about an hour. GET /o/{org}/sessions/{id}/artifacts/architecture.md with the key works after that. The webhook's result field includes the final answer only up to 16 KiB, so the file is the artifact, not the webhook body.