Files
wehub-resource-sync fed8b2eed7
Backend release / release (push) Waiting to run
Bandit Security Scan / bandit_scan (push) Waiting to run
Build and push multi-arch DocsGPT Docker image / build (linux/amd64, ubuntu-latest, amd64) (push) Waiting to run
Build and push multi-arch DocsGPT Docker image / build (linux/arm64, ubuntu-24.04-arm, arm64) (push) Waiting to run
Build and push multi-arch DocsGPT Docker image / manifest (push) Blocked by required conditions
Build and push DocsGPT FE Docker image for development / build (linux/amd64, ubuntu-latest, amd64) (push) Waiting to run
Build and push DocsGPT FE Docker image for development / build (linux/arm64, ubuntu-24.04-arm, arm64) (push) Waiting to run
Build and push DocsGPT FE Docker image for development / manifest (push) Blocked by required conditions
Python linting / ruff (push) Waiting to run
Run python tests with pytest / Run tests and count coverage (3.12) (push) Waiting to run
React Widget Build / build (push) Waiting to run
chore: import upstream snapshot with attribution
2026-07-13 13:28:29 +08:00

7.2 KiB

AGENTS.md

  • Read CONTRIBUTING.md before making non-trivial changes.
  • For day-to-day development and feature work, follow the development-environment workflow rather than defaulting to setup.sh / setup.ps1.
  • Avoid using the setup scripts during normal feature work unless the user explicitly asks for them. Users configure .env usually.
  • Try to follow red/green TDD

Check existing dev prerequisites first

For feature work, do not assume the environment needs to be recreated.

  • Check whether the user already has a Python virtual environment such as venv/ or .venv/.
  • Check whether Postgres is already running and reachable via POSTGRES_URI (the canonical user-data store).
  • Check whether Redis is already running.
  • Reuse what is already working. Do not stop or recreate Postgres, Redis, or the Python environment unless the task is environment setup or troubleshooting.

MongoDB is not required for the default install. It is only needed if the user opts into the Mongo vector-store backend (VECTOR_STORE=mongodb) or is running the one-shot scripts/db/backfill.py to migrate existing user data from the legacy Mongo-based install. In those cases, pymongo is available as an optional extra, not a core dependency.

Normal local development commands

Use these commands once the dev prerequisites above are satisfied.

Backend

source .venv/bin/activate  # macOS/Linux
uv pip install -r application/requirements.txt  # or: pip install -r application/requirements.txt

Run the API. For local dev, prefer the ASGI entrypoint under uvicorn — it serves the whole app, matches production, and hot-reloads:

uvicorn application.asgi:asgi_app --host 0.0.0.0 --port 7091 --reload

flask --app application/app.py run --host=0.0.0.0 --port=7091 is a faster inner loop (quick startup, the Werkzeug interactive debugger), but it serves only the WSGI Flask app and omits the routes mounted on the ASGI shell in application/asgi.py:

  • the /mcp FastMCP endpoint, and
  • the native-async SSE reconnect reader GET /api/messages/<id>/events.

Under flask run those paths 404. Chat still works (POST /stream is a Flask route), but a stream interrupted by a disconnect won't auto-resume on reconnect. Use flask run only when you don't need those routes.

Production uses gunicorn -k uvicorn_worker.UvicornWorker against the same application.asgi:asgi_app target; see application/Dockerfile for the full flag set.

Run the Celery worker in a separate terminal (if needed):

celery -A application.app.celery worker -l INFO

On macOS, prefer the solo pool for Celery:

python -m celery -A application.app.celery worker -l INFO --pool=solo

A bare worker (no -Q) consumes every configured queue, so one worker does the whole job — app tasks and document parsing (the read_document tool / workflow native-file parse) alike. Use -Q only to split load: run the main worker with -Q docsgpt and a dedicated (e.g. GPU-enabled) parser worker with -Q parsing for heavy OCR.

Frontend

Install dependencies only when needed, then run the dev server:

cd frontend
npm install --include=dev
npm run dev

Docs site

cd docs
npm install

Python / backend changes validation

ruff check .
python -m pytest

Frontend changes

cd frontend && npm run lint
cd frontend && npm run build

Documentation changes

cd docs && npm run build

If Vale is installed locally and you edited prose, also run:

vale .

Repository map

  • application/: Flask backend, API routes, agent logic, retrieval, parsing, security, storage, Celery worker, and WSGI entrypoints.
  • tests/: backend unit/integration tests and test-only Python dependencies.
  • frontend/: Vite + React + TypeScript application.
  • frontend/src/: main UI code, including components, conversation, hooks, locale, settings, upload, and Redux store wiring in store.ts.
  • docs/: separate documentation site built with Next.js/Nextra.
  • extensions/: integrations and widgets — currently the Chatwoot webhook bridge and the React widget (published to npm as docsgpt). The Discord bot, Slack bot, and Chrome extension have been moved to their own repos under arc53/.
  • deployment/: Docker Compose variants and Kubernetes manifests.

Coding rules

Backend

  • Follow PEP 8 and keep Python line length at or under 120 characters.
  • Use type hints for function arguments and return values.
  • Add Google-style docstrings to new or substantially changed functions and classes.
  • Add or update tests under tests/ for backend behavior changes.
  • Keep changes narrow in api, auth, security, parser, retriever, and storage areas.

Backend Abstractions

  • LLM providers implement a common interface in application/llm/ (add new providers by extending the base class).
  • Vector stores are abstracted in application/vectorstore/.
  • Parsers live in application/parser/ and handle different document formats in the ingestion stage.
  • Agents and tools are in application/agents/ and application/agents/tools/.
  • Celery setup/config lives in application/celery_init.py and application/celeryconfig.py.
  • Settings and env vars are managed via Pydantic in application/core/settings.py.

Frontend

  • Follow the existing ESLint + Prettier setup.
  • Prefer small, reusable functional components and hooks.
  • If shared state must be added, use Redux rather than introducing a new global state library.
  • Avoid broad UI refactors unless the task explicitly asks for them.
  • Do not re-create components if we already have some in the app.

Icons

DocsGPT historically mixed three icon sources: lucide-react, inline SVG components, and .svg assets loaded via <img src=…>. For new code:

  1. Prefer lucide-react for standard UI affordances (close, chevron, search, trash, plus, etc.). It tokenizes via currentColor, ships tree-shaken icons, and the codebase already imports it in 30+ places. <X className="size-4" />, <ChevronDown />, etc.
  2. Use assets/<name>.svg?react when you need a brand-specific or domain illustration that doesn't exist in lucide (the app logo, robot fallback, retry arrow, send arrow, etc.). Always set fill="currentColor" / stroke="currentColor" in the SVG file so consumers can theme via Tailwind text classes.
  3. Avoid <img src={Asset}> for new icons. It blocks currentColor theming and forces dark-variant duplicates (the audit removed several orphan dark/purple/white variants in this branch). The pattern is acceptable for existing call sites — don't bulk-migrate without a reason.

Three pre-existing dark-variant pairs (documentation, no-files, science-spark) are hand-tuned multi-color illustrations, not pure inverts; they keep their -dark companion files until a per-illustration refactor.

PR readiness

Before opening a PR:

  • run the relevant validation commands above
  • confirm backend changes still work end-to-end after ingesting sample data when applicable
  • clearly summarize user-visible behavior changes
  • mention any config, dependency, or deployment implications
  • Ask your user to attach a screenshot or a video to it